22kB-Boyutlu Blokzincir — Teknik Bir Referans

“Mina blokzincirinin tamamı yaklaşık 22 kb — sadece birkaç tweet boyutundadır.”

Yukarıdaki ifadeyi analiz etmeden önce burada “blokzincir” ile ne demek istediğimizi açıklayalım:

1. Ortalama bir kullanıcının ilgilendiği anlık durum ile ilgili farklı bölümlerin, açık ve net (yani sadece hashler değil) bir kullanılabilir temsili — örneğin hesap dökümü gibi.
2. Bu durumun gerçek olduğunu güvenilir bir şekilde doğrulamak için bir düğümün ihtiyaç duyduğu veriler.
3. Transfer gerçekleştirebilmek için işlemlerle ilgili bilgileri tüm ağa yayınlama yeteneği.

“Blokzincir” buradaki (1), (2) ve (3) ‘üncü maddelerin tamamını kapsamaktadır.

Bitcoin veya Ethereum gibi diğer ağlarda madenciler, bu ağların mevcut durumunun herhangi bir bölümünü tam olarak doğrulamak için ağdaki işlemlerin (bloklardan oluşan bir zincir şeklinde düzenlenmiş olan) tüm geçmiş kayıtlarına ihtiyaç duyarlar. Bu durum, hesap yada UTXO tabanlı ağların tümü için geçerlidir. Herhangi bir yeni düğüm (veya uzun süredir çevrimdışı olan bir düğüm), ağa bağlanarak güvenli bir şekilde senkronize olmak için kaçırdığı işlem olan tüm blokları indirmek zorunda kalacaktır.

Bitcoin veya Ethereum gibi diğer ağlarda, bir “hafif istemci” kavramı vardır. Bu hafif istemciler, düşük kapasiteli ortamlar için tasarlanmıştır ve kullanıcıların yüksek maliyetli (hem zaman hem de kapladığı alan olarak) bir senkronizasyon işlemi yapmak zorunda kalmadan blokzincirin en son durumundan kendileriyle ilgili bilgileri doğrulamasına / bunlara erişmesine yardımcı olurlar. Bunu, bir bloktan başlığı okuyarak ve aldıkları bloğa göre bakiyenin doğru olduğunu teyid ederek yaparlar. Yani veriyi onlara gönderen tam düğüme güvenerek yaparlar. Bu hafif düğümler, yukarıda tanımladığımız şekliyle “blokzincir” kavramını tam olarak temsil edemezler.

Mina blokzincir yapısını kolayca doğrulanabilir sabit boyutlu bir kriptografik kanıt ile genesis bloktan başlayarak diğer tüm bloklara kadar tamamen değiştiriyor. Bir bloğa karşılık gelen bu kanıtın doğrulanması, mevcut bloğun birkaç blok arkasına kadar tüm işlemlerin doğrulanması anlamına gelir. Doğrulama işleminin kanıtı ve girdileri, ağa bilgisi yayılan en son bloktadır. Yukarıdaki “blokzincir” kavramının tanımı bağlamında “kullanılabilir” terimini içerdiğini not olarak ekleyelim. Bu tanım, Mina gibi özlü bir protokolde, opak hashler dolu bir durumla birleştirilmiş bir kanıttan daha fazlasına ihtiyacımız olduğu anlamına gelir.

Bu doğrulama süreci Mina’nın ağındaki tüm düğümler için geçerlidir. Ağdaki bazı roller, görevlerini yerine getirmek için ekstra bilgiye ihtiyaç duyar, ancak bu yukarıda verdiğimiz tanımın ötesindedir. “Blok üreticisi” düğüm hakkında daha fazla bilgiyi ekte bulabilirsiniz.

Blokzincirin kullanılabilir bir temsili için gerekli veriler

(1) Belirli bir hesabın bakiyelerini kontrol edebilmek ve (2) ağa işlem gönderebilmek istiyoruz. “Konsensüs dışı düğüm” olarak adlandırdığımız bu düğümün, belleğinde saklanması gerekenler yalnızca şunlardır: protokol durumu, hesap, bu hesaba giden merkel yolu, ve doğrulama anahtarı. Buradaki önemli husus, bu güçlü düğümler hafif istemciler değildir. Tam düğümlere eşdeğer güvenliğe sahiptirler.

Yalnızca “konsensüs dışı düğüm” olarak hareket etmek isteyen bir düğüm için bu istemci yazılımı geliştirmesi henüz tamamlanmamıştır. Bu geliştirme mainnet sonrası yol haritamızda yer almaktadır.

Protokol Durumu

Protokol durumu, ağın mevcut durumunun açık bir temsilidir. Defter de dahil olmak üzere çeşitli veri yapılarının hashlerini içerir. Blok üreten düğümler, içindeki durum protokolünü içeren bloklar hakkında bilgiyi dağıtırlar.

Mina’daki bir blok farklı bilgileri de içerir; önceki bloklara dahil edilen işlemler için, yeni işlemleri ve SNARK’ları içeren bir kanıt. Özyinelemeli zk-SNARK’lar, bir doğrulama işlevi ve bir doğrulama anahtarı, tek bir yeni bloğun kanıtı ve durum protokolü aracılığıyla tüm blok dizisini doğrulamamıza imkan verir.

Düğüm yeni durumun geçerli olduğu doğrulamasını yaptıktan sonra, yeni bloğun varolandan daha iyi olup olmadığını bağımsız bir şekilde kontrol edebilir. Ve bu esnada kaynağa güvenmek zorunda kalmadan karşılaştırmayı bilinen en iyi protokol durumu ile yapabilir — eğer yeni blok mevcut olandan daha iyi değilse veya kaydettiğimizin yerine geçemiyorsa bu bilgiyi unutmayı seçebiliriz. Başka bir deyişle, yeni protokol durumlarını takip ederken yalnızca tek bir protokol durumuna bağlı kalmamız yeterlidir.

Hesap

Mina hesap tabanlı bir model kullanır (Ethereum’a benzerdir); bir açık anahtara karşılık gelen bakiye hesap kaydında saklanır. Bir düğüm hesap defterinin tamamını saklamamış olsa dahi, onu kaydetmiş olan başka bir düğümden belirli bir hesap kaydını talep edebilir. (örnek blok üreticisi düğümler -detay için eke bakabilirsiniz)

Bir hesabın Merkel yolu

İlave olarak bir düğüm, herhangi başka bir düğüme güvenmek zorunda kalmadan hesap kaydının geçerli olduğunu doğrulamak için, hesaba giden merkel yolunu da ister. Ortaya çıkan merkle kökü, blokzincir snark’ı tarafından onaylanmış olan defter durumu ile eşleşmelidir.

Boyut Ölçüm Detayları

Mina’daki mutabakat dışı bir düğüm, tüm blokzinciri ve SNARK’lar tarafından güvenli bir şekilde onaylanmış olan defterdeki tüm hesapları, aynen diğer büyük ve maliyetli (senkronizasyon süresi ve kapladığı alan) diğer ağlardaki tam düğümler gibi güvenili bir şekilde doğrulayabilir. (Bitcoin veya Ethereum ağları gibi). Bu verilerin boyutlarının ne kadar olduğuna bakalım:

Burada paylaştığımız her bir veri ile ilgili boyut ampirik olarak ölçülebilir — biz aşağıdakileri (depolanan gerçek ikili veriler) bu kodu kullanarak yaptığımız hesaplamalarla belirledik. Kodu çalıştırdığımızda, aşağıdaki bilgileri aldık (bayt cinsinden):

Hisse Kanıtı boyutu: 7063

Protokol Durum boyutu: 822

Hesap boyutu: 181

Yol boyutu: 741

Toplam boyut (kümülatif): 8807

Bir düğüm ayrıca blokzincir SNARK’larını doğrulamak için bir anahtara ihtiyaç duyar ve onun diskteki boyutuda 2039 bayt’tır.

Sonuç yaklaşık 11kB’tır. Mina’nın kriptografisi, başlangıçta yaptığımız çalışmalar ve incelemede ulaştığımız 22kB’tan sonra çok gelişmiştir- protokol daha verimli hale gelmiştir.

Snark’ı Oluşturulmuş Defter

İşlemlere ait SNARK’ların işlenme şeklinden dolayı blokzincir üzerinde SNARK ile onaylanmış olan defterin en son deftere göre birkaç blok geride olduğunu dikkate almalısınız. (burada ayrıntılı olarak açıklanmıştır). SNARK işçisi düğümler tarafından üretilmiş işlem SNARK’ları ile kanıtlanmış olan bu kayda Snark’ı oluşturulmuş defter diyoruz. Bir bloğa karşılık gelen en son defter (aşamalı- defter), blok üreticileri tarafından işlemler deftere eklenerek açık şekilde doğrulanır ve bunların blokzincirin kanıtı olduğu garanti edilmez.

Sonuç

Amacımız, tüm blokzincirin yalnızca 11kB boyutunda veri kullanılarak temsil edilebileceğini ve doğrulanabileceğini göstermekti. Mina blokzincirinin tamamı yaklaşık 22 kb’dır — hatta daha bile azdır.

Ek: Blok üreten düğümler

Blok üreten düğümler, anlık durumu doğrulamanın ötesinde görevler de yerine getirirler. Blok üreticileri etkin bir şekilde blok üretimi yapabilmek için için son k bloklarının bir zincirini tutarlar (burada k, ouroboros samasika konsensüs algoritmamızdan bir sabittir — ve şu anda 290 olarak ayarlanmıştır). k, bir bloğun final durumunu ifade eder; üzerinde k adet blok bulunan bir bloğun tersine çevrilmesi ihmal edilebilir bir olasılığa sahiptir ve bu nedenle içindeki tüm işlemler sonsuza kadar her zaman onaylanacaktır. Bir blok üreticisi, en iyi zinciri belirlemek ve ondan bloklar üretmek için son k blok içinde meydana gelen tüm çatallanmaları sürdürür. Bir blok üreticisi ayrıca, diğer düğümlerin daha sonra doğrulayabileceği şekilde durum protokolünü oluşturabilmek için deftere dahil olan tüm veri yapılarını da devam ettirir. Daha büyük bir duruma ihtiyaç duyulsa bile, yeni bir blok üreticisi düğüm için en son duruma senkronize olmak demek, k blokzinciri SNARK’larını doğrulamak ve bu k bloklarında gerçekleşen işlemleri uygulamak anlamına gelir.