MINA

Dünya’nın en hafif zinciri, 22 kb, pamuktan hafif zincir, state bloat problemini çözen zincir, gizlilik, sıfır bilgi kanıtları, ölçeklenebilir zincir… Mina tam olarak ne, ve benim Mina’ya olan bakış açım ne?
Çok teknik gitmeyeceğim, bu yazıda sadece bir araştırmacı olarak “derine inmeden” Mina için ne düşündüğümü zihnimde nasıl konumlandırdığımı anlatacağım.
1.1 State Bloat problemi ve Mina:
Her şeyden önce Mina’nın güçlü yanlarından bahsetmek istiyorum. Mina zincirinin asıl ve en önemli sunduğu çözüm: “sınırlanmış zincir boyutu”. Bunun altındaki teknolojiye girmeyeceğim ama basitçe şöyle anlatayım: Normalde bir blok zincire full node yada validatör olarak katılmak için genesis (ilk blok)’tan itibaren bütün verileri indirmek gerekir. Bunun asıl sebebi, herhangi bir kişiye güvenmek zorunda kalmadan ağa katılabilmeni sağlama isteğidir. Kulağa hoş gelse de, ilk bloktan itibaren bütün blokların verilerini indirmek her geçen gün daha zor hale geliyor. Şu anda Ethereum’da full node çalıştırmak için minimum 2tb’lık SSD gerekmekte, bu da kullanıcıların full node çalıştırmasını zorlaştırıyor.

Ethereum Full node veri boyutu. Kaynak: https://etherscan.io/chartsync/chaindefault
Mina Zero Knowledge sayesinde zincirin data boyutunu 22kb ile sınırlı tutuyor. Bu soruna bulunmuş ve “çalışan” ilk çözümlerden biri kendisi. Elbette bu konudaki tek çözüm Mina değil, Statelessness ve State Expiry gibi çözümler bulunuyor. Ayrıca Mina’nın ZK konusundaki bir diğer avantajı da, web’deki (HTTPS) verileri zincirin üstüne “sadece Mina’nın” altyapısını kullanarak kanıtlayabiliyor olması. Bu konuda aklımı kurcalayan şeyler olsa da Ethereum’da bunu yapmak istediğin bir üründe ek olarak ZK kanıtlarıyla sıfırdan geliştirmen gerekirken Mina’nın bunu sana sunması büyük bir avantaj. (Bkz: ZK-Email)

1.2 Mina & Merkeziyetsiz Blok ve Kanıt Üretim Mekanizması
Ayrıca Mina mimari olarak “Proposer and Builder Separation”i protokolüne ilk yediren zincirdir (Tamamen aynı olmadığının farkındayım). Bu basitçe, bloğu üreten ve onaylan kişinin ayrılmasını öneren bir altyapı. Şu anda Ethereum’da aktif olarak çalışmakta ve MEV probleminin ana aktörü olarak çok tartışılmakta.
Ve hatta Mina’nın PBS dizaynın bir diğer avantajı da Mina’nın ilk merkeziyetsiz kanıt marketi oluşturan zincir olması bence. Şu anda tüm rolluplar merkezi kanıtlayıcılara güveniyor ve yol haritalarında bunu merkeziyetsizleştirme bulunmakta. Mina bunu hali hazırda protokolüne yedirerek bu konudaki “ilkel olsa da” çalışan ve merkeziyetsiz olan tek zincir olarak çalışmakta :)
Şimdi Mina’nın -bana göre- teknik avantajlarını anlattıktan sonra, problemli ve geliştirilmesi gereken; bana göre yanlış tasarım tercihlerini anlatmak isterim. Sonrasında kafamda Mina’yı nereye konumlandırdığımı anlatacağım.
Mina’daki Problemler:
2.1. Ölçeklenebilirlik
Mina’nın sıfır bilgi kanıtlara dayanan altyapısı maalesef bir dezavantajla gelmekte: Son kullanıcı için zincir hala çok kullanışsız. Gerek gerçek hayatta, gerek DeFi gibi senaryolarda hızlı blok süresi sadece bir ihtiyaç değil, gereklilik. Maalesef Mina’da blok süreleri ve işlemlerin onaylanma hızı hala istenen seviyenin çok aşağısında. ProtoKit , Yürütme ortamını Mina’nın dışına taşımak ve Mina’yı sadece kanıt ispatı için kullanmayı amaçlayan bir altyapı olarak burada ilgi çekici duruyor. ProtoKit’in çözemediği bir konu var, ki ona birazdan değineceğim.
2.2. Zincirin Üzerinde Yapabileceklerinizin Kısıtlı Olması:
Mina’nın 22kb’lık altyapısı, büyük bir dezavantajla geliyor. Zincirin üstünde sadece 8 field tutabiliyoruz. Bu yüzden karmaşık uygulamalar (merkeziyetsiz finans, sosyal medya projeleri ve dahası) genellikle verileri zincirin dışında tutuyor.
Bu daha büyük bir problemi beraberinde getiriyor: zincirin dışında tutulan veriler erişilemez olursa, uygulamalar da erişilemez oluyor. Yani uygulamalar canlılığını Mina’dan değil, veriyi tuttuğu yerden alıyor. Bu konu, özellikle DeFi gibi %100 canlılığın gereklilik olduğu uygulamalarda büyük bir sorun teşkil ediyor. Bu yüzden bence en ideal çözüm yeni geliştirilen veri erişilebilirliği katmanları. Canlılık ve verinin erişilebilir olduğunun garantisini verebilmesi için geliştirilen Celestia, Avail, EigenDA gibi zincirlerin Mina’nın bu açığını kapatabileceğini düşünüyorum.
Bu zincirlerde verinin erişilebilir olduğunun, Mina’ya kanıtlanması gerekiyor. Maalesef burada da Mina tarafında kriptografik engeller bulunuyor. Bu yüzden Yunus’la beraber Paris’te Photon Bridge’i geliştirmiş ve LambdaClass hackathonun’da birinci olmuştuk. Bu köprü basitçe Celestia’daki bir verinin erişilebilir olduğunu, Mina’ya kanıtlayan bir altyapı sunuyor.
2.3. Cüzdanların Light Client desteklememesi:
Mina’nın asıl önerdiği şeyin “zinciri 22kb’ta sınırlaması ve herkesin zinciri onaylamasını kolaylaştırması” olduğunu anlatmıştım. Realiteye baktığımızda light client destekleyen tek cüzdan olmadığını görüyoruz. Kullanıcılar açısından; Light Client olmayan bir Mina’nın, 20tb state’i olan Solana’dan farkı olmadığını düşünüyorum. Light Client destekleyen cüzdan yapılarının gelişmesi ve fonlanmasının burada önem arz ettiğini düşünüyorum.
2.4 Evrilen Teknolojiyi Yaklayamamak
Son zamanlarda Rolluplar, Veri Erişilebilirlik katmanları, settlement katmanları ve birçok yeni teknolojinin çıktığını gördük. Bu teknolojiler problemlerini de beraberinde getirdi. Bence Mina burada birçok noktada problem çözücü olarak yer alabilirdi. Hala Ethereum’a açılmamış bir köprü (Nil vakfı tarafından geliştirilen) ve üzerinde app olmayan dümdüz bir zincir olarak yaşamakta. Mina’nın bundan fazlasını yapabileceğini düşünüyorum. Proof aggregation ile (özellikle groth16 ile başlamak yeterli olacaktı) Mina’yı proof verification katmanı yapıp rolluplar arası iletişim için bir settlement katmanı olarak konumlandırmak, yada Mina’nın proof sistemiyle çalışan bir rollup geliştirip (01Labs ve Optimism’in bunun için çalıştığını biliyorum) Mina’ya buradan katkı sunmak da yapılabilecekler arasındaydı.