Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy Ryan Sean Adams and Uma Roy'ın geri bildirimleri ve incelemeleri için özellikle teşekkür ederiz.
Blok zincirinin en güçlü özelliklerinden biri, herhangi bir kişinin kendi bilgisayarında bir Düğüm çalıştırabilmesi ve Blok zincirinin doğruluğunu doğrulayabilmesidir. 9596 PoW, PoS konsensüsü çalıştıran Düğümün, hemen kuralları değiştirme ve yeni kurallara göre Blok üretmeye başlama konusunda anlaşmaları durumunda, tamamen doğrulama yapabilen her Düğüm, zinciri kabul etmeyecektir. Bu komplo grubuna ait olmayan para üreticileri otomatik olarak eski kurallara uygun olan bir on-chain'e toplanacak ve bu zinciri oluşturmaya devam ederken, tamamen doğrulama yapan kullanıcılar bu zincire uyar.
Bu, blok zinciri ile merkezi sistem arasındaki temel farktır. Ancak, bu özelliğin geçerli olması için tam bir doğrulama düğümünü çalıştırmak, yeterli sayıda insan için gerçekten uygulanabilir olmalıdır. Bu hem stakeholder'lar için geçerlidir (çünkü stakeholder'lar zinciri doğrulamazlarsa, protokol kurallarına katkıda bulunmazlar), hem de normal kullanıcılar için geçerlidir. Günümüzde, tüketici dizüstü bilgisayarlarında (bu makale yazılırken kullanılan dizüstü bilgisayar da dahil olmak üzere) tam bir doğrulama düğümünü çalıştırmak mümkün olabilir, ancak bunu başarmak zordur. The Verge, tam doğrulama zincirinin hesaplama maliyetini düşürmeyi ve her cep telefonu cüzdanının, tarayıcı cüzdanının hatta akıllı saatlerin varsayılan olarak doğrulama yapmasını sağlamayı hedefliyor.
The Verge 2023 Yol Haritası
Başlangıçta, "Verge", ETHereum durum depolamanın Verkle ağacına taşınması anlamına geliyordu - daha sıkı kanıtlara izin veren ağaç yapısı, ETHereum bloklarının durumsuz doğrulamasını mümkün kılar. Bir düğüm, bir ETHereum bloğunu doğrulayabilir ve herhangi bir ETHereum durumunu (hesap bakiyesi, akıllı sözleşme kodu, depolama alanı...) diskte depolamadan doğrulama yapabilir, bunun bedeli, bir kanıtı doğrulamak için birkaç yüz KB veri ve ek birkaç yüz milisaniye harcamaktır. Bugün, Verge, ETHereum zincirinin maksimum kaynak verimliliği doğrulamasına odaklanan daha büyük bir vizyonu temsil ediyor, bu sadece durumsuz doğrulama teknolojisini değil, aynı zamanda tüm ETHereum yürütmesini SNARK kullanarak doğrulamayı içeriyor.
SNARK doğrulamasının tam zincir boyunca takip edilmesi dışında, Verkle ağacının en iyi teknoloji olup olmadığıyla ilgili başka bir yeni sorun vardır. Verkle ağacı Kuantum Bilgisayar saldırısına açıktır, bu nedenle mevcut KECCAK Merkle Patricia ağacındaki Verkle ağacını kullanıyorsak, ileride tekrar ağacı değiştirmemiz gerekecektir. Merkle ağacının kendini değiştirme yöntemi, Merkle dallarını atlayan STARK'ı kullanmaktır ve bunu ikili ağaca yerleştirmektir. Tarih boyunca, maliyeti ve teknik karmaşıklığı nedeniyle bu yöntem uygulanabilir görülmemiştir. Ancak son zamanlarda, Starkware'nin bir dizüstü bilgisayarda ckcle STARKs kullanarak saniyede 1.7 milyon Poseidon hash'i kanıtladığını ve GKB gibi teknolojilerin ortaya çıkması nedeniyle daha fazla "geleneksel" hash değerinin kanıt süresinin hızla kısalıyor olduğunu gördük. Bu nedenle, geçen yıl içinde "Verge" daha açık hale geldi ve birkaç olasılığı vardır.
The Verge: Ana Hedef
· Durumsuz istemci: Tamamen doğrulanan istemci ve Düğüm işaretlemesi için gereken depolama alanı birkaç GB'ı aşmamalıdır.
· (Uzun vadeli) Akıllı saatte zinciri tamamen doğrulayın (Konsensüs ve yürütme). Bazı verileri indirin, SNARK'ı doğrulayın, tamamlayın.
Bu bölümde
· Durum Bilgisi Olmayan İstemci: Verkle veya STARKs
· EVM tarafından yürütülen geçerlilik kanıtı
· Konsensüsün geçerlilik kanıtı
Durum Doğrulaması: Verkle veya STARKs
Biz hangi sorunu çözmek istiyoruz?
Şu anda, ETH blok istemcisi, Blokları doğrulamak için yüzlerce gigabayt durum verisini depolamalıdır ve bu miktar her yıl artmaktadır. Orijinal durum verisi yaklaşık olarak her yıl 30 GB artar ve bir istemci, üçlüyü etkin bir şekilde güncellemek için biraz ek veri depolamalıdır.
Bu, tam Ethereum Düğümü'nü çalıştırmak için yeterli olmasa da, Ethereum durumunu hatta yıllarca geçmişini depolamak için yeterli olan büyük sabit disklere sahip olabileceği gerçeğini azaltır: insanlar genellikle birkaç yüz gigabayt depolama alanına sahip bilgisayarlar satın alırlar. Durumun boyutu, Düğümün ilk kez kurulma sürecinde büyük bir sürtünme yaratır: Düğüm, tüm durumu indirmesi gerekmektedir, bu da saatler veya günler sürebilir. Bu çeşitli zincirleme tepkilere yol açar. Örneğin, Düğüm oluşturucusunun Düğüm ayarlarını yükseltme zorluğunu büyük ölçüde artırır. Teknik olarak, bir yükseltmeyi durdurmadan tamamlayabilirsiniz - yeni bir istemci başlatın, senkronize olmasını bekleyin, eski istemciyi kapatın ve Gizli Anahtar'ı aktarın - ancak pratikte bunlar teknik açıdan çok karmaşıktır.
Nasıl çalışır?
Durum doğrulaması, Düğüm'ün Blok'u tüm durumu bilmeksizin doğrulamasına izin veren bir teknolojidir. Bunun yerine, her Blok, (i) erişeceği durumun belirli bir konumundaki değerleri, kodları, bakiyeleri, depolamayı içeren bir tanık içerir; (ii) bu değerlerin doğru olduğunu kanıtlayan şifreleme kanıtı.
Aslında, durum olmadan doğrulama gerçekleştirmek için Ethereum'un durum ağacı yapısını değiştirmeyi gerektirir. Bu, mevcut Merkle Patricia ağacının herhangi bir şifreleme kanıt şemasını uygulamak için son derece kullanışsız olduğu, özellikle en kötü durumda olduğu anlamına gelir. Hem 'orijinal' Merkle dallanması hem de STARK olarak 'paketlenmesi' olasılıkları da böyledir. Temel zorluklar, MPT'nin bazı zayıf noktalarından kaynaklanır:
Bu bir 16-çocuklu bir ağaçtır (yani her Düğümün 16 alt Düğümü vardır). Bu, N büyüklüğündeki bir ağaçta, bir kanıtın ortalama olarak 32*(16-1)log16(N) = 120 log2(N) bayt veya 2^32 öğenin ağacında yaklaşık 3840 bayt gerektirdiği anlamına gelir. İkili ağaçlar için sadece 32*(2-1)log2(N) = 32 log2(N) bayt gereklidir veya yaklaşık 1024 bayt.
Kod Merkle ileştirilmemiştir. Bu, hesap kodunun erişim iznini kanıtlamanın, tüm kodun en fazla 24000 baytını sağlamak gerektiği anlamına gelir.
En kötü senaryoyu aşağıdaki gibi hesaplayabiliriz:
30000000 gas / 2400 (soğuk hesap okuma maliyeti) *（5 * 488 + 24000) = 330000000 bayt
Şube maliyeti biraz azalır (8*480 yerine 5*480) çünkü daha fazla şube olduğunda şubenin üst kısmı tekrarlanır. Ancak o zaman bile, tek bir zaman diliminde indirilecek veri miktarı tamamen gerçekçi değildir. Bunu STARK'larla kapsüllemeye çalışırsak, iki sorunla karşılaşırız: (i) KECCAK, STARK'lara nispeten düşmancadır; (ii) 330 MB veri, STARK'ın KECCAK'ın daha verimli olduğunu kanıtlamasını sağlasak bile, en güçlü tüketici sınıfı donanım dışında herkes için kanıtlanamayabilir, KECCAK yuvarlak işlevine 5 milyon çağrıyı kanıtlamamız gerektiği anlamına gelir.
Eğer on altılık ağacın yerine ikili ağacı doğrudan kullanıp kodu ekstra bir Merkle işlemine tabi tutarsak, en kötü durum yaklaşık olarak 30000000/240032(32-14+8) = 10400000 byte olur (14, 2^14 dallanma için yapılan gereksiz bitlerin çıkarılmasıdır ve 8, kod bloğuna giren kanıtların uzunluğudur). Dikkat edilmesi gereken nokta, her ayrı kod bloğuna erişim için gaz maliyetine değişiklik yapmaktır; EIP-4762 bunu yapar. 10.4 MB'lık bir kapasite çok daha iyi olsa da, bir zaman dilimi içinde indirilen veriler birçok düğüm için hala fazla. Bu nedenle, daha güçlü teknikler sunmamız gerekiyor. Bu konuda, iki önde gelen çözüm var: Verkle ağacı ve STARKed ikili karma ağacı.
Verkle 树
Verkle ağacı, kısa kanıtlar için eliptik eğri tabanlı vektör taahhütlerini kullanır. Kilidinin açılması için, ağacın genişliği ne olursa olsun, her ebeveyn-çocuk ilişkisi için kanıt bölümü sadece 32 bayttır. Kanıt ağacının genişliğini sınırlayan tek kısıtlama, kanıt ağacı çok genişse, kanıtın hesaplama verimliliğinin düşeceğidir. ETHereum için önerilen uygulamanın genişliği 256'dır.
Bu nedenle, tek bir dalın boyutunun 32-1og256(N) = 4 * log2(N) bayta kadar değiştiği kanıtlanmıştır. Bu nedenle, teorik olarak maksimum kanıt boyutu yaklaşık olarak 30000000 / 2400 * 32 * (32 -14 + 8) / 8 = 130000 bayt olabilir (durum bloklarının dağılımı eşit olmadığından, gerçek hesaplama sonuçları biraz farklı olabilir ancak birinci yaklaşım olarak kabul edilebilir).
Ayrıca dikkate alınması gereken bir diğer husus, yukarıdaki tüm örneklerde, bu 'en kötü durum' aslında en kötü durum değildir: Daha kötü bir durum, saldırganın iki Adres'i kasıtlı olarak 'kazması' ve daha uzun ortak bir öneki olan bir ağa sahip olmasını sağlamaktır ve verileri bir Adres'ten okumak için, bu durum en kötü durumun dallanma uzunluğunu 2 katına çıkarabilir. Ancak böyle bir durum olsa bile, Verkle ağacının en kötü durumda ispat uzunluğu 2.6MB'dir, şu anda en kötü durumda olan doğrulama verileriyle neredeyse aynıdır.
Bu önlemi kullanarak başka bir şey yaptık: 'komşu' depolama alanına erişimin maliyetini çok düşük hale getirdik: ya aynı sözleşmenin birçok kod bloğu ya da bitişik depolama yuvası olabilir. EIP-4762, bitişik tanımını sağlayarak komşu erişim için sadece 200 gas ücret alır. Bitişik erişim durumunda, en kötü durumda kanıt boyutu 30000000 / 200 * 32 - 4800800 byte olur, bu hala kabul edilebilir bir aralıktadır. Güvenlik için bu değeri azaltmak istiyorsak, bitişik erişim ücretini biraz artırabiliriz.
STARKed 二进制哈希树
Bu teknolojinin prensibi açıktır: Sadece bir ikili ağaç yapmanız ve bloktaki değerleri kanıtlamanız için en fazla 10,4 MB kanıt almanız gerekmektedir, ardından kanıt yerine STARK kanıtını kullanmanız gerekmektedir. Böylece kanıt yalnızca kanıtlanan verileri içeren, gerçek STARK'tan gelen 100-300 kB sabit maliyetle birlikte olacaktır.
Buradaki ana zorluk, zamanın doğrulanmasıdır. Yukarıdaki temel hesaplamaları yapabiliriz, ancak hesapladığımız şey bayt sayısı değil, karma değeridir. 10.4 MB bir Blok, 330,000 karma değeri anlamına gelir. Bir saldırganın Adres ağacında uzun bir ortak öneki olan kazma olasılığını eklersek, en kötü durumda karma değerleri yaklaşık 660,000 karma değerine ulaşacaktır. Dolayısıyla, saniyede 200,000 karma değerini kanıtlayabilirsek, sorun yok demektir.
Poseidon hash fonksiyonunu kullanan tüketici dizüstü bilgisayarlarında, bu sayılar 01928374656574839201'e ulaştı, ve Poseidon hash fonksiyonu özellikle STARK dostu olarak tasarlanmıştır. Ancak, Poseidon sistemi hala nispeten olgun değil, bu yüzden birçok insan onun güvenliğine güvenmiyor. Bu nedenle, iki gerçek ilerleme yolu vardır:
Poseidon'a hızlı bir şekilde kapsamlı güvenlik analizi yapın ve L1'de dağıtım için yeterince bilgi sahibi olun.
Daha "muhafazakar" bir karma fonksiyonu kullanın, örneğin SHA256 veya BLAKE
Konservatif hash fonksiyonunun kanıtlanması gerekiyorsa, Starkware'in STARK halkası, bu yazı yazılırken yalnızca tüketici dizüstü bilgisayarlarında saniyede 10-30k hash değeri kanıtlayabilir. Ancak, STARK teknolojisi hızla ilerliyor. Bugün bile, GKR temelli teknoloji, bu hızı 100-2O0k aralığına çıkarmayı göstermektedir.
Bloğun dışında tanıklık kullanım örnekleri doğrulama
Blok doğrulamalarının yanı sıra, daha verimli durumsuz doğrulamaya ihtiyaç duyan diğer üç önemli kullanım durumu bulunmaktadır:
· Bellek havuzu: İşlem yayınlandığında, P2P ağındaki düğümler işlemin geçerli olup olmadığını yeniden yayınlamadan önce doğrulamalıdır. Şu anda doğrulama, imza doğrulamasını ve yeterli bakiyenin ve önekin doğru olup olmadığını kontrol etmek de dahil olmak üzere bir dizi doğrulamayı içerir. Gelecekte (örneğin, EIP-7701 gibi yerel hesap soyutlaması kullanılarak) bu, bazı EVM kodlarını çalıştırmayı gerektirebilir ve bu kodlar bazı durum erişimleri yapabilir. Düğüm durumsuz ise, işlem durum nesnesinin kanıtını eklemesi gerekecektir.
· Liste içerir: Bu, (muhtemelen küçük ölçekli ve karmaşık olmayan) bir Proof of Stake doğrulayıcının, (muhtemelen büyük ölçekli ve karmaşık olan) bir Blok oluşturucusunun isteğine bakılmaksızın, bir sonraki Blok'un işlemleri içermesine izin veren bir önerilen özelliktir. Bu, doğrulayıcıların Blok zincirini manipüle etmek için gecikme süresi işlemlerini kullanma yeteneklerini zayıflatacaktır. Bununla birlikte, doğrulayıcıların liste içindeki işlemlerin geçerliliğini doğrulama yeteneklerine sahip olmaları gerekir.
· hafif müşteri：Eğer kullanıcıların cüzdanları aracılığıyla Zincire (Örn. Metamask, Rainbow, Rabby vb.) erişmesini istiyorsak, bunu başarmak için hafif müşteri (Örn. Helios) çalıştırmaları gerekmektedir. Helios'un çekirdek modülü kullanıcılara doğrulanmış durum kökü sağlar. Tamamen güvensiz bir deneyim elde etmek için kullanıcıların her RPC çağrısı için kanıt sunmaları gerekmektedir (Örn. ETH ağı çağrısı için, kullanıcıların erişim sağladıkları tüm durumu kanıtlamaları gerekmektedir).
Tüm bu durumların ortak bir özelliği var, o da oldukça fazla kanıt gerektirmeleridir, ancak her bir kanıt çok küçüktür. Bu nedenle, STARK kanıtları onlar için gerçekten anlamlı değildir; aksine, en gerçekçi yaklaşım doğrudan Merkle dallarını kullanmaktır. Merkle dalının diğer bir avantajı da güncellenebilir olmasıdır: Blok B köküne sahip bir durum nesnesi X için bir kanıt verildiğinde, bir alt Blok B2 ve onun tanıklığını alırsanız, kanıtı güncelleyebilir ve Blok B2 köküne göre ayarlayabilirsiniz. Verkle kanıtları da doğal olarak güncellenebilir.
Mevcut araştırmalarla ne tür bağlantılar var:
· Verkle ağaçları
· John Kuszmaul Verkle ağacı hakkındaki orijinal makale
· Starkware
· Poseidon2 belgesi
· Ajtai (kristal kafes sertliğine dayalı alternatif hızlı hash fonksiyonu)
· Verkle.info
Başka neler yapabilirsiniz?
Kalan ana iş
EIP-4762 sonuçlarıyla ilgili daha fazla analiz (stateless gas maliyet değişikliği)
Geçiş programının tamamlanması ve test edilmesi, herhangi bir uluslararası olmayan ortam uygulama planının karmaşıklığının ana bölümüdür.
Poseidon, Ajtai ve diğer "STARK-friendly" hash fonksiyonlarına yönelik daha fazla güvenlik analizi
'Konservatif' (veya 'geleneksel') hash'in daha da verimli STARK protokolü özellikleri için Binius veya GKR tabanlı görüşlere dayalı olarak geliştirilmesi.
Ayrıca, yakında aşağıdaki üç seçenek arasından birini seçmeye karar vereceğiz: (i) Verkle ağacı, (ii) STARK dostu hash fonksiyonu ve (iii) muhafazakar hash fonksiyonu. Bunların özellikleri genellikle aşağıdaki tabloda özetlenmiştir:
Bu "başlık numaraları" dışında dikkate almanız gereken diğer önemli faktörler:
· Şu anda, Verkle ağacı kodu oldukça olgun hale gelmiştir. Verkle dışındaki başka bir kod kullanmanın dağıtımı geciktireceği, büyük olasılıkla bir çatala neden olacağı da doğru. Bu da sorun değil, özellikle Ethereum'a ekstra zaman harcamamız gerekiyorsa, hash fonksiyonu analizi veya doğrulayıcı uygulaması yapmamız gerekiyorsa veya daha erken Ethereum'a dahil etmek istediğimiz başka önemli özelliklerimiz varsa.
· Bir durum kökünü karma ile güncellemek, Verkle ağacı kullanmaktan daha hızlıdır. Bu, hash tabanlı bir yaklaşımın tam düğümün senkronizasyon süresini azaltabileceği anlamına gelir.
· Verkle ağacı güncellenebilir bir tanıklama özelliğine sahiptir - Verkle ağacı tanıklaması güncellenebilir. Bu özellik mempool, içerik listeleri ve diğer kullanım durumları için faydalı olabilir ve ayrıca uygulama verimliliğinin artmasına yardımcı olabilir: Durum nesnesi güncellendiğinde, bir önceki katmanın tanıklaması güncellenebilir, son katmanın içeriğini okumadan.
· Verkle ağacının SNARK kanıtlaması daha zor hale geliyor. Kanıt boyutunu binlerce bayta kadar düşürmek istiyorsak, Verkle kanıtlaması bazı zorluklar getirecektir. Bu, Verkle kanıtının doğrulamasının çok sayıda 256 bit işlemi içermesi nedeniyle gerçekleşir, bu da kanıt sisteminin ya büyük bir maliyeti ya da kendisinin 256 bit'lik Verkle kanıtı bölümünü içeren özelleştirilmiş bir iç yapıya sahip olmasını gerektirir. Bu, durumun kendisi için bir sorun olmasa da, daha fazla zorluk getirecektir.
Eğer Verkle tanıklığı yenilenebilirliği kuantum güvenli ve makul verimli bir şekilde elde etmek istiyorsak, başka bir olası yol lattice tabanlı Merkle ağacına dayanmaktadır.
Eğer en kötü durumda dahi sistem verimliliğinin yeterince yüksek olmadığı kanıtlanırsa, bu eksikliği telafi etmek için beklenmedik bir araç olan çoklu boyutlu gas'ı kullanabiliriz: (i) calldata için; (ii) hesaplama için; (iii) durum erişimi ve olası diğer farklı kaynaklar için ayrı gas sınırları belirleme. Çoklu boyutlu gas, karmaşıklığı artırır, ancak karşılığında ortalama durum ile en kötü durum arasındaki oranı daha sıkı bir şekilde sınırlar. Çoklu boyutlu gas ile teoride kanıtlanması gereken maksimum dal sayısı, 12500'den 3000'e kadar azalabilir. Bu, BLAKE3'ün bugün dahi (zor da olsa) yeterli olmasını sağlayabilir.
Çok boyutlu gas, Blok'un kaynak sınırlarını altta yatan donanımın kaynak sınırlarına daha yakın hale getirir.
Başka bir beklenmedik araç, durum kökünün Blok'tan sonra hesaplanan gecikme süresidir. Bu şekilde, durum kökünü hesaplamak için tam 12 saniye zamanımız var, bu da en aşırı durumlarda bile saniyede sadece 60000 karma sayısının yeterli olduğu anlamına geliyor, bu da tekrar BLAKE3'ün talepleri zorlukla karşılayabileceğini düşündürüyor.
Bu yöntemin bir dezavantajı, bir hafif müşteri gecikme süresi eklemesi, ancak bu tür gecikme süresini sadece kanıt üretimi gecikmesine indirebilecek daha akıllı teknikler de var. Örneğin, kanıt, herhangi bir düğümün oluşturulmasından hemen sonra ağda yayınlanabilir, bir sonraki bloğu beklemek zorunda kalmadan.
Diğer yol haritası bölümleriyle nasıl etkileşime geçiyor?
Durumsuz sorunu çözmek, tek kişilik hedef alma zorluğunu büyük ölçüde artırır. Tek kişilik hedef belirleme en düşük dengeye sahipse, Orbit SSF veya Uygulama Katmanı stratejileri gibi, takım hedef belirleme daha uygulanabilir hale gelecektir.
Eğer EOF aynı anda dahil edilirse, çok boyutlu gaz analizi daha da kolaylaşacaktır. Bu, çok boyutlu gazın ana yürütme karmaşıklığının çoğunlukla, ebeveyn çağrının tüm gazını iletmeyen alt çağrıları işlemesinden kaynaklandığı için böyledir, EOF ise bu tür alt çağrıları yasadışı hale getirmek için sadece bu sorunu önemsiz hale getirebilir (ve yerel hesap soykütlesi için bir protokol içinde kısmi gazın mevcut ana kullanım durumu için bir alternatif sunar).
Durum doğrulama ve geçmişin süresi arasında önemli bir işbirliği var. Bugün, istemci 1TB yakınında geçmiş verileri depolamak zorundadır; bu veriler durum verilerinin katlarıdır. İstemci durumsuz olsa bile, istemci depolama geçmiş verileri sorumluluğunu ortadan kaldıramadığı sürece neredeyse hiç depolama yapamayacaktır. Bu konuda atılacak ilk adım EIP-4444'tür, bu da geçmiş verilerin torrentlerde veya Portal Network portal ağındaki depolanması anlamına gelir.
EVM 执行的geçerlilik kanıtı
Biz hangi sorunu çözmek istiyoruz?
ETH Blok doğrulamasının uzun vadeli hedefi oldukça açıktır - ETH Blok'un aşağıdaki yollarla doğrulanabilmesi gerekmektedir: (i) Blok'u indirmek veya sadece veri kullanılabilirliği örnekleme kısmını indirmek; (ii) Bir Blok'un geçerli olup olmadığını doğrulayan küçük bir kanıt. Bu, mobil istemci, tarayıcı cüzdan veya hatta başka bir zincirde (veri kullanılabilirliği olmayan bir bölüm olmadan) gerçekleştirilebilen çok düşük kaynak tüketen bir işlem olacaktır.
Bu hedefe ulaşmak için (i) konsensüs katmanı (yani hisse senedi kanıtı) ve (ii) yürütme katmanı (yani EVM) için SNARK veya STARK kanıtları gereklidir. İlkini zaten bir zorluk olarak ele almak gerekiyor ve konsensüs katmanını sürekli olarak geliştirmenin bir parçası olarak çözülmelidir (örneğin, tek yuva finalitesi için). İkincisi, EVM yürütme kanıtlarını gerektirir.
O nedir, nasıl çalışır?
Görünüşe göre, ETH Eter spesifikasyonunda, EVM bir durum geçiş fonksiyonu olarak tanımlanmıştır: Eğer bir önceki durum S'niz, bir Blok B'niz varsa, bir sonraki durum S' = STF(S, B) hesaplıyorsunuz. Kullanıcılar hafif müşteri kullansalar bile, tam olarak S ve S'ye sahip değillerdir, hatta E'ye sahip değillerdir; bunun yerine bir önceki durum kökü R, bir sonraki durum kökü R' ve bir Blok hash değeri H'ye sahiptirler.
· Ortak giriş: Önceki durum kökü R, sonraki durum kökü R', blok hash'i H
· Özel giriş: Program bloğu B, program bloğu Q tarafından erişilen durumdaki nesneler, Q'yi yürüttükten sonra aynı nesneler, durum kanıtları (örneğin Merkle dalları) P
· Argüman 1: P, Q'nun temsil ettiği durumun bazı kısımlarını içerdiğini kanıtlayan geçerli bir kanıttır.
· Argüman 2: STF Q üzerinde çalıştırılıyorsa, (i) işlem sadece Q'nun içindeki nesnelere erişir, (ii) veri blokları geçerlidir, (iii) sonuç Q'
· 3. iddia: Q' ve P bilgilerini kullanarak yeni durum kökünü yeniden hesaplarsak, R' elde ederiz
Eğer böyle bir durum varsa, tam olarak doğrulanan ETH EVM işlemini gerçekleştiren hafif bir istemciye sahip olabilirsiniz. Bu, istemcinin kaynaklarının oldukça düşük olduğu anlamına gelir. Gerçek bir tam olarak doğrulanan ETH müşterisi elde etmek için, Konsensüs tarafında aynı çalışmayı yapmak gerekmektedir.
EVM hesaplamaları için geçerlilik kanıtı uygulaması zaten mevcut ve L2 tarafından yaygın bir şekilde kullanılıyor. Ancak EVM geçerlilik kanıtının L1'de kullanılabilir hale gelmesi için hala çok çalışma yapılması gerekiyor.
Mevcut araştırmalarla nasıl ilişkisi var?
· EFPSE ZK-EVM（由于存在更好的选择，现已停用）
· Zeth, işleyişi EVM'yi RISC-0 ZK-VM'ye derlemek olarak çalışır.
· ZK-EVM Biçimsel Doğrulama projesi
Başka neler yapabilirsiniz?
Bugün, elektronik muhasebe sisteminin geçerlilik kanıtı, güvenlik ve doğrulama süresi açısından yetersizdir.
Bir güvenliğin geçerlilik kanıtı, SNARK'ın EVM hesaplamasını gerçekten doğruladığını ve hiçbir açığın olmadığını sağlamalıdır. Güvenliği artırmak için iki ana teknik çoklu doğrulayıcı ve formal doğrulamadır. Çoklu doğrulayıcı, çoklu bağımsız geçerlilik kanıtı uygulamasına atıfta bulunur, sanki birden fazla istemci gibi; eğer bir Blok bu uygulamalardan biri tarafından yeterince büyük bir alt küme ile kanıtlanırsa, istemci o Blok'ü kabul eder. Formal doğrulama, genellikle matematik teoremlerini kanıtlamak için kullanılan araçları kullanarak, geçerlilik kanıtının, EVM K semantiği veya python ile yazılmış ETHereum yürütme katmanı spesifikasyonu (EELS) gibi altta yatan EVM spesifikasyonunun doğru bir şekilde uygulandığını kanıtlamayı içerir.
Yeterince hızlı doğrulama süresi, herhangi bir ETH bloğunun doğrulanmasının 4 saniyeden kısa bir sürede gerçekleşebileceği anlamına gelir. Bugün, bu hedefe oldukça uzak bir noktadayız, ancak iki yıl önce hayal ettiğimizden çok daha yakınız. Bu hedefe ulaşmak için üç yönde ilerleme kaydetmemiz gerekiyor:
· Paralelleştirme – En hızlı EVM doğrulayıcısı, bir Ethereum bloğunu ortalama 15 saniyede kanıtlayabilir. Bunu, yüzlerce GPU'yu paralel hale getirerek ve sonunda çalışmalarını bir araya getirerek yapar. Teorik olarak, hesaplamayı O(log(N)) zamanında kanıtlayabilen bir EVM doğrulayıcısının nasıl oluşturulacağını tam olarak biliyoruz: her adımı bir GPU'nun yapmasına izin verin ve ardından bir "toplama ağacı" oluşturun:
Bu bir zorlukla karşılaşır. En kötü durumda bile, yani çok büyük bir işlem tüm Blok'ı kapladığında, hesaplamanın bölünmesi sırayla değil, altta yatan Sanal Makine'nin işlem kodlarına (EVM veya RISC-V gibi) göre yapılmalıdır. Sanal Makine'nin "belleği"nin farklı bölümler arasında tutarlı kalmasını sağlamak, uygulama sürecinde önemli bir zorluktur. Ancak, bu tür bir özyinelemeli kanıtı gerçekleştirebilirsek, en azından gecikme süresi sorunu çözülmüş olur, diğer yönlerde herhangi bir iyileştirme olmasa bile.
· Kanıt sistemi optimizasyonu - Orion, Binius, GRK gibi yeni kanıt sistemleri ve diğer bilgiler, genel hesaplama doğrulama süresini büyük ölçüde kısaltabilir.
· Diğer EVM gaz maliyeti değişiklikleri - EVM'deki birçok şey optimize edilebilir, böylece özellikle en kötü durumlarda doğrulayıcılara daha uygun hale gelir. Bir saldırgan, doğrulayıcıyı on dakika boyunca bloke eden bir Blok oluşturabilirse, sadece 4 saniye içinde normal bir ETH Blok'un doğrulanması yeterli olmayacaktır. Gerekli EVM değişiklikleri genel olarak aşağıdaki kategorilere ayrılabilir:
gas maliyetinin değişimi - bir işlemin kanıtlanması uzun sürerse, hesaplama hızı göreceli olarak hızlı olsa bile yüksek gas maliyeti olmalıdır. EIP-7667, bu ciddi sorunu ele almak için önerilen bir EIP'dir: (geleneksel) hash fonksiyonlarının gas maliyetini önemli ölçüde arttırır çünkü bu fonksiyonların işlem kodları ve önceden derleme göre daha ucuzdur. Bu gas maliyetlerinin artışını telafi etmek için, EVM işlem kodlarının düşük maliyetli gas maliyeti kanıtını düşürerek ortalama işlemci hızını sabit tutabiliriz.
Veri yapıları değişimi - STARK için daha dostane bir yöntemle durum ağacını değiştirmenin yanı sıra, işlem listesi, makbuz ağacı ve diğer yüksek maliyetli kanıtları da değiştirmemiz gerekiyor. Etan Kissling'in işlem ve makbuz yapısını SSZ'nin EIP'sine taşıması bu yönde atılmış bir adımdır.
Ayrıca, önceki bölümde bahsedilen iki araç (çok boyutlu gas ve gecikme süresi durumu) de bu konuda yardımcı olabilir. Ancak, dikkat edilmesi gereken nokta, durumsuz doğrulama ile farklı olarak, bu iki aracı kullanmanın, şu anda ihtiyacımız olan işi tamamlamak için yeterli teknolojiye sahip olduğumuz anlamına geldiğidir ve bu teknolojileri kullansak bile, tam ZK-EVM doğrulaması daha fazla çalışma gerektirir - sadece daha az çalışma gerektirir.
Yukarıda bahsedilmeyen bir nokta, kanıtlayıcı donanımdır: GPU, FPGA ve ASIC kullanarak daha hızlı kanıt oluşturmak. Fabric Cryptography, Cysic ve Accseal, bu alanda ilerleme kaydeden üç şirkettir. Bu, L2 için çok değerli olsa da, L1'in belirleyici bir faktörü olması pek olası değildir, çünkü insanlar L1'in yüksek Merkeziyetsizlik seviyesini korumasını istiyorlar, bu da kanıt oluşturmanın ETH blok zinciri kullanıcılarının makul aralığında olması gerektiği anlamına geliyor ve tek bir şirketin donanımının darboğaz kısıtlamasına tabi olmamalıdır. L2, daha olumlu bir dengeleme yapabilir.
Bu alanlarda daha fazla çalışma yapılması gerekmektedir:
Paralel kanıt, sistemdeki farklı parçaların "paylaşılan belleği" (örneğin arama tablosu) paylaşabileceğini gerektirir. Bunu yapmanın tekniklerini biliyoruz, ancak bunun gerçekleştirilmesi gerekiyor.
· Daha fazla analiz yapmamız gerekiyor, böylece en kötü durumda doğrulama süresini en aza indirgemek için ideal gaz maliyet değişim setini bulabiliriz.
· Bizim daha fazla çalışma kanıt sistemi açısından gerekiyor
Olası maliyet:
· Güvenlik ve doğrulayıcı süresi: Daha agresif bir karma işlevi, daha karmaşık bir kanıt sistemi veya daha agresif bir güvenlik varsayımı veya diğer tasarım seçenekleri seçilirse doğrulayıcı süresi kısaltılabilir.
· Merkeziyetsizlik ve kanıtlayıcı zamanı: Topluluk, hedeflenen kanıtlayıcı donanımın 'özellikleri' konusunda uzlaşmaya varmalıdır. Kanıtlayıcıların büyük ölçekli varlıklar olması isteniyor mu? Bir ETH bloğunu 4 saniye içinde kanıtlayabilen yüksek kaliteli bir dizüstü bilgisayar mümkün mü? Arada mı?
Geriye dönük uyumluluğu bozma derecesi: Diğer eksiklikler daha aktif bir şekilde gas maliyet değişikliği ile telafi edilebilir, ancak bu muhtemelen bazı uygulamaların maliyetini orantısız şekilde artırarak geliştiricilerin kodları yeniden yazmalarını ve yeniden dağıtmalarını zorunlu kılacaktır, böylece ekonomik olarak sürdürülebilirliği koruyacaktır. Aynı şekilde, bu araçların her ikisinin de kendi karmaşıklığı ve dezavantajları vardır.
Diğer yol haritası bölümleriyle nasıl etkileşime geçiyor?
L1 EVM geçerlilik kanıtı için gereken temel teknoloji, büyük ölçüde diğer iki alana da paylaşılmaktadır:
· L2'nin geçerlilik kanıtı (yani "ZK rollup")
· Durumsuz "STARK ikili hash kanıtı" yöntemi
L1 başarıyla geçerlilik kanıtını gerçekleştirdiğinde, kolay tek kişilik Stake'e ulaşmak mümkün olur: en zayıf bilgisayarlar bile (telefonlar veya akıllı saatler dahil) Stake yapabilir. Bu, tek kişilik Stake'in diğer kısıtlamalarını (örneğin 32ETH asgari miktarı) çözmede değerini daha da artırır.
Ayrıca, L1'in EVM geçerlilik kanıtı, L1'in gas limitini büyük ölçüde artırabilir.
Konsensüs'un geçerlilik kanıtı
Biz hangi sorunu çözmek istiyoruz?
SNARK'ı kullanarak bir ETH bloğunu tamamen doğrulamak istiyorsak, EVM'nin yürütülmesi sadece kanıtlamamız gereken tek kısım değildir. Ayrıca, tasdik, yani mevduat işlemlerinin işlenmesi, çekilme işlemleri, imza işlemleri, doğrulayıcı bakiye güncellemeleri ve ETH Proof of Stake bölümündeki diğer unsurların da kanıtlanması gerekmektedir.
Konsensüs, EVM'den çok daha basittir, ancak karşılaştığı zorluk şudur ki, L2 EVM katmanımız olmadığı için, her durumda çoğu çalışma tamamlanmalıdır. Bu nedenle, ETH blok zinciri üzerinde Konsensüs'ün kanıtlanması için herhangi bir uygulamanın 'sıfırdan başlaması' gerekmektedir, ancak kanıt sistemi üzerine inşa edilebilecek paylaşılan iş vardır.
Ne olduğu, nasıl çalışır?
beacon ağı, EVM gibi bir durum geçiş işlevi olarak tanımlanır. Durum geçiş işlevi temel olarak üç bölümden oluşur:
· ECADD (BLS imzasını doğrulamak için kullanılır)
· Eşleştirme (BLS imzasını doğrulamak için kullanılır)
· SHA256 Hash değeri (durumun okunması ve güncellenmesi için kullanılır)
Her Blok içinde, her doğrulayıcı için 1-16 adet BLS12-381 ECADD'yi (birden fazla kümede imza olabileceği için) kanıtlamamız gerekiyor. Bu, alt küme ön hesaplama teknolojisi ile telafi edilebilir, bu nedenle her doğrulayıcının sadece bir BLS12-381 ECADD'yi kanıtlaması gerektiğini söyleyebiliriz. Şu anda, her yuva için 30000 doğrulayıcı imzası bulunmaktadır. Gelecekte, tek zaman dilimi finalite uygulaması ile bu durum iki yönde değişebilir: "brute force" yolunu izlersek, her zaman dilimindeki doğrulayıcı sayısı 1 milyona kadar artabilir. Aynı zamanda, Orbit SSF kullanılırsa, doğrulayıcı sayısı 32768 veya hatta 8192'ye kadar azalabilir.
BLS Aggregasyon Nasıl Çalışır: Doğrulama toplam imza için her katılımcının bir ECADD'ye ihtiyacı olduğunu, bir ECMUL yerine. Ancak 30000 ECADD hala büyük bir kanıt miktarıdır.
Eşleme için, şu anda her yuvasında en fazla 128 kanıt bulunur, bu da 128 eşlemeyi doğrulamanız gerektiği anlamına gelir. ElP-7549 ve ilave düzenlemelerle, her yuva 16'ya kadar azaltılabilir. Eşleme sayısı azdır, ancak maliyeti son derece yüksektir: Her eşlemenin çalışma (veya kanıt) süresi ECADD'den k kat daha uzundur.
BLS12-381 işleminin ana zorluğu, BLS12-381 alan boyutuna eşit eğri derecesi olmayan uygun eğri olmamasıdır, bu da herhangi bir kanıt sistemi için oldukça büyük bir maliyet artışına neden olur. Öte yandan, ETHereum için önerilen Verkle ağacı Bandersnatch eğrisiyle oluşturulmuştur, bu da BLS12-381'in SNARK sistemi içinde Verkle dalını kanıtlamak için kullanılan kendi eğrisi haline gelmesini sağlar. Saniyede 100 G1 toplama kanıtı yapabilen basit bir uygulama; kanıt hızını yeterince hızlı hale getirmek için muhtemelen GKR gibi ustaca tekniklere ihtiyaç duyulacaktır.
SHA256 hash değeri için, şu anda en kötü senaryo dönüm dönüş bloğu, tüm doğrulayıcıların kısa denge ağacı ve çok sayıda doğrulayıcı dengesi güncellenecektir. Her doğrulayıcının kısa denge ağacı sadece bir bayttır, bu nedenle 1 MB veri yeniden karma alınır. Bu 32768 SHA256 çağrısıyla eşdeğerdir. Eğer bin doğrulayıcının bakiyesi bir eşik değerinin üzerinde veya altında ise, doğrulayıcılar kayıtlarındaki geçerli bakiyeyi güncellemek gerekebilir. Bu bin adet Merkle dalına denk gelir, bu nedenle 10000 karma değeri gerekebilir. Karıştırma mekanizması her doğrulayıcının 90 Bit'i gerektirir (bu nedenle 11 MB veri gerektirir), ancak bu herhangi bir dönemde hesaplanabilir. Tek slotta sonlandırma durumunda, bu sayılar belirli durumlara göre değişebilir. Karıştırma gerekli olmaktan çıkar, ancak Orbit bu ihtiyacı belirli bir ölçüde geri kazanabilir.
Başka bir zorluk, bir Blok'u doğrulamak için Açık Anahtar da dahil olmak üzere tüm doğrulayıcı durumlarını yeniden elde etmek gerektiğidir. 1 milyon doğrulayıcı için sadece Açık Anahtar'ı okumak 48 milyon bayt gerektirir, bunun üzerine Merkle dalı eklenir. Bu, her bir dönemde milyonlarca karma değeri gerektirir. PoS'nin etkinliğini kanıtlamamız gerekiyorsa, gerçekçi bir yöntem, bir tür artımlı doğrulanabilir hesaplama şeklidir: kanıt sistemi içinde ayrı bir veri yapısı depolamak, bu veri yapısının optimize edilmiş bir şekilde etkili bir şekilde aranabilmesini ve güncellemelere karşı kanıtlanabilmesini sağlamaktır.
Sonuç olarak, birçok zorluk var. Bu zorluklarla en etkili şekilde başa çıkmak için muhtemelen beacon ağına derinlemesine yeniden tasarım gerekecek ve bu muhtemelen tek yuva sonlandırmaya doğru bir dönüşü içerecektir. Bu yeniden tasarımın özellikleri muhtemelen şunları içerebilir:
· hash fonksiyonunun değişimi: Şu anda kullanılan "tam" SHA256 hash fonksiyonu, dolayısıyla doldurma nedeniyle her çağrıda iki kez altta yatan sıkıştırma fonksiyonunu çağırmak zorunda kalır. Eğer SHA256 sıkıştırma fonksiyonu kullanırsak, en azından 2 kat kazanabiliriz. Eğer Poseidon kullanırsak, muhtemelen 100 kat kazanç elde edebiliriz, bu da tüm sorunlarımızı (en azından hash değeri açısından) tamamen çözebilir: Saniyede 1.7 milyon hash değeri (54MB), hatta bir milyon doğrulama kaydı da kanıt içinde birkaç saniye içinde "okunabilir".
· Eğer Orbit ise, doğrulayıcı kayıtlarını karıştırdıktan sonra doğrudan depolarız: Belirli bir yuva için belirli bir sayıda doğrulayıcıyı (örneğin 8192 veya 32768) komite olarak seçerseniz, bunları birbirlerinin yanına doğrudan duruma yerleştiririz, bu sayede tüm doğrulayıcıların Açık Anahtarlarını okumak için en az sayıda hash gereklidir. Bu şekilde tüm denge güncellemeleri verimli bir şekilde tamamlanabilir.
· İmza birleştirme: Herhangi bir yüksek performanslı imza birleştirme çözümü, ağdaki farklı düğümlerin imza alt kümesini araştırma gerektiren bir tür özyineleme kanıtını içerir. Bu, doğal olarak kanıt işini ağdaki birden fazla düğüme dağıtır ve 'son kanıtlayıcı'nın iş yükünü büyük ölçüde azaltır.
· Diğer imza şemaları: Lamport+Merkle imzası için 256+32 adet hash değeri gereklidir; 32768 imzacı ile çarpılırsa 9437184 hash değeri elde edilir. İmza şemasını optimize ettikten sonra, bu sonucu daha da iyileştirmek için küçük bir sabit faktör kullanılabilir. Poseidon kullanırsak, bu tek bir yuva içinde kanıtlanabilir. Ancak aslında, rekürsif birleşim şeması daha hızlı olacaktır.
Mevcut araştırmalarla nasıl ilişkisi var?
· Basit Ethereum Konsensüsü ispatı (yalnızca senkronizasyon komitesi için)
Helios, included in SP1 of Simplified Chinese, is concise.
· Özet BLS12-381 Önceden Derlenmiş
· Halo2 temelli BLS toplu imza doğrulaması
Hangi işler yapılmalı, nasıl seçim yapılmalı:
Aslında, Ethereum Konsensüsü'nün geçerlilik kanıtını elde etmek için yıllarca süreye ihtiyacımız var. Bu, tek yuva finality, Orbit, İmza Algoritması'nı değiştirme ve güvenlik analizi gibi diğer problemleri çözmek için gereken zamanla yaklaşık olarak aynıdır ve güvenlik analizi, Poseidon gibi 'ilerici' bir karma işlevini kullanmak için yeterli güvene sahip olmayı gerektirir. Bu nedenle, en akıllıca yaklaşım bu diğer sorunları çözmek ve aynı zamanda STARK'ın dostane doğasını göz önünde bulundurmaktır.
Ana tartışma muhtemelen işlem sırasında, Ethereum'un uzlaşma katmanını daha kademeli bir yaklaşım ve daha radikal bir "birçok şeyi bir kerede değiştirme" yaklaşımı arasında dengelemektir. EVM için aşamalı yaklaşım makuldir çünkü geriye dönük uyumluluk üzerindeki etkileri en aza indirebilir. Uzlaşma katmanı için geriye dönük uyumluluk etkisi daha azdır ve beacon ağı oluşturma şeklinin çeşitli detaylarını daha "kapsamlı" bir şekilde yeniden düşünmek, SNARK dostu optimizasyonları en iyi şekilde yapmak da faydalıdır.
Diğer yol haritası bölümleriyle nasıl etkileşime geçiyor?
ETH bloğunda PoS uzun vadeli olarak yeniden tasarlanırken, STARK dostu bir faktör olarak öncelikli bir düşünce olmalıdır, özellikle tek yuva finalitesi, Orbit, imza planı değişikliği ve imza birleştirme.
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
Vitalik'in ETH hakkındaki olası geleceği (4): The Verge
Önceki yazıları okuyun: "Vitalik ETHereum'un olası geleceği (1): Birleşme", "Vitalik ETHereum'un olası geleceği (2): Yükseliş", "Vitalik ETHereum'un olası geleceği (3): Felaket"
Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy Ryan Sean Adams and Uma Roy'ın geri bildirimleri ve incelemeleri için özellikle teşekkür ederiz.
Blok zincirinin en güçlü özelliklerinden biri, herhangi bir kişinin kendi bilgisayarında bir Düğüm çalıştırabilmesi ve Blok zincirinin doğruluğunu doğrulayabilmesidir. 9596 PoW, PoS konsensüsü çalıştıran Düğümün, hemen kuralları değiştirme ve yeni kurallara göre Blok üretmeye başlama konusunda anlaşmaları durumunda, tamamen doğrulama yapabilen her Düğüm, zinciri kabul etmeyecektir. Bu komplo grubuna ait olmayan para üreticileri otomatik olarak eski kurallara uygun olan bir on-chain'e toplanacak ve bu zinciri oluşturmaya devam ederken, tamamen doğrulama yapan kullanıcılar bu zincire uyar.
Bu, blok zinciri ile merkezi sistem arasındaki temel farktır. Ancak, bu özelliğin geçerli olması için tam bir doğrulama düğümünü çalıştırmak, yeterli sayıda insan için gerçekten uygulanabilir olmalıdır. Bu hem stakeholder'lar için geçerlidir (çünkü stakeholder'lar zinciri doğrulamazlarsa, protokol kurallarına katkıda bulunmazlar), hem de normal kullanıcılar için geçerlidir. Günümüzde, tüketici dizüstü bilgisayarlarında (bu makale yazılırken kullanılan dizüstü bilgisayar da dahil olmak üzere) tam bir doğrulama düğümünü çalıştırmak mümkün olabilir, ancak bunu başarmak zordur. The Verge, tam doğrulama zincirinin hesaplama maliyetini düşürmeyi ve her cep telefonu cüzdanının, tarayıcı cüzdanının hatta akıllı saatlerin varsayılan olarak doğrulama yapmasını sağlamayı hedefliyor.
Başlangıçta, "Verge", ETHereum durum depolamanın Verkle ağacına taşınması anlamına geliyordu - daha sıkı kanıtlara izin veren ağaç yapısı, ETHereum bloklarının durumsuz doğrulamasını mümkün kılar. Bir düğüm, bir ETHereum bloğunu doğrulayabilir ve herhangi bir ETHereum durumunu (hesap bakiyesi, akıllı sözleşme kodu, depolama alanı...) diskte depolamadan doğrulama yapabilir, bunun bedeli, bir kanıtı doğrulamak için birkaç yüz KB veri ve ek birkaç yüz milisaniye harcamaktır. Bugün, Verge, ETHereum zincirinin maksimum kaynak verimliliği doğrulamasına odaklanan daha büyük bir vizyonu temsil ediyor, bu sadece durumsuz doğrulama teknolojisini değil, aynı zamanda tüm ETHereum yürütmesini SNARK kullanarak doğrulamayı içeriyor.
SNARK doğrulamasının tam zincir boyunca takip edilmesi dışında, Verkle ağacının en iyi teknoloji olup olmadığıyla ilgili başka bir yeni sorun vardır. Verkle ağacı Kuantum Bilgisayar saldırısına açıktır, bu nedenle mevcut KECCAK Merkle Patricia ağacındaki Verkle ağacını kullanıyorsak, ileride tekrar ağacı değiştirmemiz gerekecektir. Merkle ağacının kendini değiştirme yöntemi, Merkle dallarını atlayan STARK'ı kullanmaktır ve bunu ikili ağaca yerleştirmektir. Tarih boyunca, maliyeti ve teknik karmaşıklığı nedeniyle bu yöntem uygulanabilir görülmemiştir. Ancak son zamanlarda, Starkware'nin bir dizüstü bilgisayarda ckcle STARKs kullanarak saniyede 1.7 milyon Poseidon hash'i kanıtladığını ve GKB gibi teknolojilerin ortaya çıkması nedeniyle daha fazla "geleneksel" hash değerinin kanıt süresinin hızla kısalıyor olduğunu gördük. Bu nedenle, geçen yıl içinde "Verge" daha açık hale geldi ve birkaç olasılığı vardır.
The Verge: Ana Hedef
· Durumsuz istemci: Tamamen doğrulanan istemci ve Düğüm işaretlemesi için gereken depolama alanı birkaç GB'ı aşmamalıdır.
· (Uzun vadeli) Akıllı saatte zinciri tamamen doğrulayın (Konsensüs ve yürütme). Bazı verileri indirin, SNARK'ı doğrulayın, tamamlayın.
Bu bölümde
· Durum Bilgisi Olmayan İstemci: Verkle veya STARKs
· EVM tarafından yürütülen geçerlilik kanıtı
· Konsensüsün geçerlilik kanıtı
Durum Doğrulaması: Verkle veya STARKs
Biz hangi sorunu çözmek istiyoruz?
Şu anda, ETH blok istemcisi, Blokları doğrulamak için yüzlerce gigabayt durum verisini depolamalıdır ve bu miktar her yıl artmaktadır. Orijinal durum verisi yaklaşık olarak her yıl 30 GB artar ve bir istemci, üçlüyü etkin bir şekilde güncellemek için biraz ek veri depolamalıdır.
Bu, tam Ethereum Düğümü'nü çalıştırmak için yeterli olmasa da, Ethereum durumunu hatta yıllarca geçmişini depolamak için yeterli olan büyük sabit disklere sahip olabileceği gerçeğini azaltır: insanlar genellikle birkaç yüz gigabayt depolama alanına sahip bilgisayarlar satın alırlar. Durumun boyutu, Düğümün ilk kez kurulma sürecinde büyük bir sürtünme yaratır: Düğüm, tüm durumu indirmesi gerekmektedir, bu da saatler veya günler sürebilir. Bu çeşitli zincirleme tepkilere yol açar. Örneğin, Düğüm oluşturucusunun Düğüm ayarlarını yükseltme zorluğunu büyük ölçüde artırır. Teknik olarak, bir yükseltmeyi durdurmadan tamamlayabilirsiniz - yeni bir istemci başlatın, senkronize olmasını bekleyin, eski istemciyi kapatın ve Gizli Anahtar'ı aktarın - ancak pratikte bunlar teknik açıdan çok karmaşıktır.
Nasıl çalışır?
Durum doğrulaması, Düğüm'ün Blok'u tüm durumu bilmeksizin doğrulamasına izin veren bir teknolojidir. Bunun yerine, her Blok, (i) erişeceği durumun belirli bir konumundaki değerleri, kodları, bakiyeleri, depolamayı içeren bir tanık içerir; (ii) bu değerlerin doğru olduğunu kanıtlayan şifreleme kanıtı.
Aslında, durum olmadan doğrulama gerçekleştirmek için Ethereum'un durum ağacı yapısını değiştirmeyi gerektirir. Bu, mevcut Merkle Patricia ağacının herhangi bir şifreleme kanıt şemasını uygulamak için son derece kullanışsız olduğu, özellikle en kötü durumda olduğu anlamına gelir. Hem 'orijinal' Merkle dallanması hem de STARK olarak 'paketlenmesi' olasılıkları da böyledir. Temel zorluklar, MPT'nin bazı zayıf noktalarından kaynaklanır:
Bu bir 16-çocuklu bir ağaçtır (yani her Düğümün 16 alt Düğümü vardır). Bu, N büyüklüğündeki bir ağaçta, bir kanıtın ortalama olarak 32*(16-1)log16(N) = 120 log2(N) bayt veya 2^32 öğenin ağacında yaklaşık 3840 bayt gerektirdiği anlamına gelir. İkili ağaçlar için sadece 32*(2-1)log2(N) = 32 log2(N) bayt gereklidir veya yaklaşık 1024 bayt.
Kod Merkle ileştirilmemiştir. Bu, hesap kodunun erişim iznini kanıtlamanın, tüm kodun en fazla 24000 baytını sağlamak gerektiği anlamına gelir.
En kötü senaryoyu aşağıdaki gibi hesaplayabiliriz:
30000000 gas / 2400 (soğuk hesap okuma maliyeti) *（5 * 488 + 24000) = 330000000 bayt
Şube maliyeti biraz azalır (8*480 yerine 5*480) çünkü daha fazla şube olduğunda şubenin üst kısmı tekrarlanır. Ancak o zaman bile, tek bir zaman diliminde indirilecek veri miktarı tamamen gerçekçi değildir. Bunu STARK'larla kapsüllemeye çalışırsak, iki sorunla karşılaşırız: (i) KECCAK, STARK'lara nispeten düşmancadır; (ii) 330 MB veri, STARK'ın KECCAK'ın daha verimli olduğunu kanıtlamasını sağlasak bile, en güçlü tüketici sınıfı donanım dışında herkes için kanıtlanamayabilir, KECCAK yuvarlak işlevine 5 milyon çağrıyı kanıtlamamız gerektiği anlamına gelir.
Eğer on altılık ağacın yerine ikili ağacı doğrudan kullanıp kodu ekstra bir Merkle işlemine tabi tutarsak, en kötü durum yaklaşık olarak 30000000/240032(32-14+8) = 10400000 byte olur (14, 2^14 dallanma için yapılan gereksiz bitlerin çıkarılmasıdır ve 8, kod bloğuna giren kanıtların uzunluğudur). Dikkat edilmesi gereken nokta, her ayrı kod bloğuna erişim için gaz maliyetine değişiklik yapmaktır; EIP-4762 bunu yapar. 10.4 MB'lık bir kapasite çok daha iyi olsa da, bir zaman dilimi içinde indirilen veriler birçok düğüm için hala fazla. Bu nedenle, daha güçlü teknikler sunmamız gerekiyor. Bu konuda, iki önde gelen çözüm var: Verkle ağacı ve STARKed ikili karma ağacı.
Verkle 树
Verkle ağacı, kısa kanıtlar için eliptik eğri tabanlı vektör taahhütlerini kullanır. Kilidinin açılması için, ağacın genişliği ne olursa olsun, her ebeveyn-çocuk ilişkisi için kanıt bölümü sadece 32 bayttır. Kanıt ağacının genişliğini sınırlayan tek kısıtlama, kanıt ağacı çok genişse, kanıtın hesaplama verimliliğinin düşeceğidir. ETHereum için önerilen uygulamanın genişliği 256'dır.
Bu nedenle, tek bir dalın boyutunun 32-1og256(N) = 4 * log2(N) bayta kadar değiştiği kanıtlanmıştır. Bu nedenle, teorik olarak maksimum kanıt boyutu yaklaşık olarak 30000000 / 2400 * 32 * (32 -14 + 8) / 8 = 130000 bayt olabilir (durum bloklarının dağılımı eşit olmadığından, gerçek hesaplama sonuçları biraz farklı olabilir ancak birinci yaklaşım olarak kabul edilebilir).
Ayrıca dikkate alınması gereken bir diğer husus, yukarıdaki tüm örneklerde, bu 'en kötü durum' aslında en kötü durum değildir: Daha kötü bir durum, saldırganın iki Adres'i kasıtlı olarak 'kazması' ve daha uzun ortak bir öneki olan bir ağa sahip olmasını sağlamaktır ve verileri bir Adres'ten okumak için, bu durum en kötü durumun dallanma uzunluğunu 2 katına çıkarabilir. Ancak böyle bir durum olsa bile, Verkle ağacının en kötü durumda ispat uzunluğu 2.6MB'dir, şu anda en kötü durumda olan doğrulama verileriyle neredeyse aynıdır.
Bu önlemi kullanarak başka bir şey yaptık: 'komşu' depolama alanına erişimin maliyetini çok düşük hale getirdik: ya aynı sözleşmenin birçok kod bloğu ya da bitişik depolama yuvası olabilir. EIP-4762, bitişik tanımını sağlayarak komşu erişim için sadece 200 gas ücret alır. Bitişik erişim durumunda, en kötü durumda kanıt boyutu 30000000 / 200 * 32 - 4800800 byte olur, bu hala kabul edilebilir bir aralıktadır. Güvenlik için bu değeri azaltmak istiyorsak, bitişik erişim ücretini biraz artırabiliriz.
STARKed 二进制哈希树
Bu teknolojinin prensibi açıktır: Sadece bir ikili ağaç yapmanız ve bloktaki değerleri kanıtlamanız için en fazla 10,4 MB kanıt almanız gerekmektedir, ardından kanıt yerine STARK kanıtını kullanmanız gerekmektedir. Böylece kanıt yalnızca kanıtlanan verileri içeren, gerçek STARK'tan gelen 100-300 kB sabit maliyetle birlikte olacaktır.
Buradaki ana zorluk, zamanın doğrulanmasıdır. Yukarıdaki temel hesaplamaları yapabiliriz, ancak hesapladığımız şey bayt sayısı değil, karma değeridir. 10.4 MB bir Blok, 330,000 karma değeri anlamına gelir. Bir saldırganın Adres ağacında uzun bir ortak öneki olan kazma olasılığını eklersek, en kötü durumda karma değerleri yaklaşık 660,000 karma değerine ulaşacaktır. Dolayısıyla, saniyede 200,000 karma değerini kanıtlayabilirsek, sorun yok demektir.
Poseidon hash fonksiyonunu kullanan tüketici dizüstü bilgisayarlarında, bu sayılar 01928374656574839201'e ulaştı, ve Poseidon hash fonksiyonu özellikle STARK dostu olarak tasarlanmıştır. Ancak, Poseidon sistemi hala nispeten olgun değil, bu yüzden birçok insan onun güvenliğine güvenmiyor. Bu nedenle, iki gerçek ilerleme yolu vardır:
Poseidon'a hızlı bir şekilde kapsamlı güvenlik analizi yapın ve L1'de dağıtım için yeterince bilgi sahibi olun.
Daha "muhafazakar" bir karma fonksiyonu kullanın, örneğin SHA256 veya BLAKE
Konservatif hash fonksiyonunun kanıtlanması gerekiyorsa, Starkware'in STARK halkası, bu yazı yazılırken yalnızca tüketici dizüstü bilgisayarlarında saniyede 10-30k hash değeri kanıtlayabilir. Ancak, STARK teknolojisi hızla ilerliyor. Bugün bile, GKR temelli teknoloji, bu hızı 100-2O0k aralığına çıkarmayı göstermektedir.
Bloğun dışında tanıklık kullanım örnekleri doğrulama
Blok doğrulamalarının yanı sıra, daha verimli durumsuz doğrulamaya ihtiyaç duyan diğer üç önemli kullanım durumu bulunmaktadır:
· Bellek havuzu: İşlem yayınlandığında, P2P ağındaki düğümler işlemin geçerli olup olmadığını yeniden yayınlamadan önce doğrulamalıdır. Şu anda doğrulama, imza doğrulamasını ve yeterli bakiyenin ve önekin doğru olup olmadığını kontrol etmek de dahil olmak üzere bir dizi doğrulamayı içerir. Gelecekte (örneğin, EIP-7701 gibi yerel hesap soyutlaması kullanılarak) bu, bazı EVM kodlarını çalıştırmayı gerektirebilir ve bu kodlar bazı durum erişimleri yapabilir. Düğüm durumsuz ise, işlem durum nesnesinin kanıtını eklemesi gerekecektir.
· Liste içerir: Bu, (muhtemelen küçük ölçekli ve karmaşık olmayan) bir Proof of Stake doğrulayıcının, (muhtemelen büyük ölçekli ve karmaşık olan) bir Blok oluşturucusunun isteğine bakılmaksızın, bir sonraki Blok'un işlemleri içermesine izin veren bir önerilen özelliktir. Bu, doğrulayıcıların Blok zincirini manipüle etmek için gecikme süresi işlemlerini kullanma yeteneklerini zayıflatacaktır. Bununla birlikte, doğrulayıcıların liste içindeki işlemlerin geçerliliğini doğrulama yeteneklerine sahip olmaları gerekir.
· hafif müşteri：Eğer kullanıcıların cüzdanları aracılığıyla Zincire (Örn. Metamask, Rainbow, Rabby vb.) erişmesini istiyorsak, bunu başarmak için hafif müşteri (Örn. Helios) çalıştırmaları gerekmektedir. Helios'un çekirdek modülü kullanıcılara doğrulanmış durum kökü sağlar. Tamamen güvensiz bir deneyim elde etmek için kullanıcıların her RPC çağrısı için kanıt sunmaları gerekmektedir (Örn. ETH ağı çağrısı için, kullanıcıların erişim sağladıkları tüm durumu kanıtlamaları gerekmektedir).
Tüm bu durumların ortak bir özelliği var, o da oldukça fazla kanıt gerektirmeleridir, ancak her bir kanıt çok küçüktür. Bu nedenle, STARK kanıtları onlar için gerçekten anlamlı değildir; aksine, en gerçekçi yaklaşım doğrudan Merkle dallarını kullanmaktır. Merkle dalının diğer bir avantajı da güncellenebilir olmasıdır: Blok B köküne sahip bir durum nesnesi X için bir kanıt verildiğinde, bir alt Blok B2 ve onun tanıklığını alırsanız, kanıtı güncelleyebilir ve Blok B2 köküne göre ayarlayabilirsiniz. Verkle kanıtları da doğal olarak güncellenebilir.
Mevcut araştırmalarla ne tür bağlantılar var:
· Verkle ağaçları
· John Kuszmaul Verkle ağacı hakkındaki orijinal makale
· Starkware
· Poseidon2 belgesi
· Ajtai (kristal kafes sertliğine dayalı alternatif hızlı hash fonksiyonu)
· Verkle.info
Başka neler yapabilirsiniz?
Kalan ana iş
EIP-4762 sonuçlarıyla ilgili daha fazla analiz (stateless gas maliyet değişikliği)
Geçiş programının tamamlanması ve test edilmesi, herhangi bir uluslararası olmayan ortam uygulama planının karmaşıklığının ana bölümüdür.
Poseidon, Ajtai ve diğer "STARK-friendly" hash fonksiyonlarına yönelik daha fazla güvenlik analizi
'Konservatif' (veya 'geleneksel') hash'in daha da verimli STARK protokolü özellikleri için Binius veya GKR tabanlı görüşlere dayalı olarak geliştirilmesi.
Ayrıca, yakında aşağıdaki üç seçenek arasından birini seçmeye karar vereceğiz: (i) Verkle ağacı, (ii) STARK dostu hash fonksiyonu ve (iii) muhafazakar hash fonksiyonu. Bunların özellikleri genellikle aşağıdaki tabloda özetlenmiştir:
Bu "başlık numaraları" dışında dikkate almanız gereken diğer önemli faktörler:
· Şu anda, Verkle ağacı kodu oldukça olgun hale gelmiştir. Verkle dışındaki başka bir kod kullanmanın dağıtımı geciktireceği, büyük olasılıkla bir çatala neden olacağı da doğru. Bu da sorun değil, özellikle Ethereum'a ekstra zaman harcamamız gerekiyorsa, hash fonksiyonu analizi veya doğrulayıcı uygulaması yapmamız gerekiyorsa veya daha erken Ethereum'a dahil etmek istediğimiz başka önemli özelliklerimiz varsa.
· Bir durum kökünü karma ile güncellemek, Verkle ağacı kullanmaktan daha hızlıdır. Bu, hash tabanlı bir yaklaşımın tam düğümün senkronizasyon süresini azaltabileceği anlamına gelir.
· Verkle ağacı güncellenebilir bir tanıklama özelliğine sahiptir - Verkle ağacı tanıklaması güncellenebilir. Bu özellik mempool, içerik listeleri ve diğer kullanım durumları için faydalı olabilir ve ayrıca uygulama verimliliğinin artmasına yardımcı olabilir: Durum nesnesi güncellendiğinde, bir önceki katmanın tanıklaması güncellenebilir, son katmanın içeriğini okumadan.
· Verkle ağacının SNARK kanıtlaması daha zor hale geliyor. Kanıt boyutunu binlerce bayta kadar düşürmek istiyorsak, Verkle kanıtlaması bazı zorluklar getirecektir. Bu, Verkle kanıtının doğrulamasının çok sayıda 256 bit işlemi içermesi nedeniyle gerçekleşir, bu da kanıt sisteminin ya büyük bir maliyeti ya da kendisinin 256 bit'lik Verkle kanıtı bölümünü içeren özelleştirilmiş bir iç yapıya sahip olmasını gerektirir. Bu, durumun kendisi için bir sorun olmasa da, daha fazla zorluk getirecektir.
Eğer Verkle tanıklığı yenilenebilirliği kuantum güvenli ve makul verimli bir şekilde elde etmek istiyorsak, başka bir olası yol lattice tabanlı Merkle ağacına dayanmaktadır.
Eğer en kötü durumda dahi sistem verimliliğinin yeterince yüksek olmadığı kanıtlanırsa, bu eksikliği telafi etmek için beklenmedik bir araç olan çoklu boyutlu gas'ı kullanabiliriz: (i) calldata için; (ii) hesaplama için; (iii) durum erişimi ve olası diğer farklı kaynaklar için ayrı gas sınırları belirleme. Çoklu boyutlu gas, karmaşıklığı artırır, ancak karşılığında ortalama durum ile en kötü durum arasındaki oranı daha sıkı bir şekilde sınırlar. Çoklu boyutlu gas ile teoride kanıtlanması gereken maksimum dal sayısı, 12500'den 3000'e kadar azalabilir. Bu, BLAKE3'ün bugün dahi (zor da olsa) yeterli olmasını sağlayabilir.
Çok boyutlu gas, Blok'un kaynak sınırlarını altta yatan donanımın kaynak sınırlarına daha yakın hale getirir.
Başka bir beklenmedik araç, durum kökünün Blok'tan sonra hesaplanan gecikme süresidir. Bu şekilde, durum kökünü hesaplamak için tam 12 saniye zamanımız var, bu da en aşırı durumlarda bile saniyede sadece 60000 karma sayısının yeterli olduğu anlamına geliyor, bu da tekrar BLAKE3'ün talepleri zorlukla karşılayabileceğini düşündürüyor.
Bu yöntemin bir dezavantajı, bir hafif müşteri gecikme süresi eklemesi, ancak bu tür gecikme süresini sadece kanıt üretimi gecikmesine indirebilecek daha akıllı teknikler de var. Örneğin, kanıt, herhangi bir düğümün oluşturulmasından hemen sonra ağda yayınlanabilir, bir sonraki bloğu beklemek zorunda kalmadan.
Diğer yol haritası bölümleriyle nasıl etkileşime geçiyor?
Durumsuz sorunu çözmek, tek kişilik hedef alma zorluğunu büyük ölçüde artırır. Tek kişilik hedef belirleme en düşük dengeye sahipse, Orbit SSF veya Uygulama Katmanı stratejileri gibi, takım hedef belirleme daha uygulanabilir hale gelecektir.
Eğer EOF aynı anda dahil edilirse, çok boyutlu gaz analizi daha da kolaylaşacaktır. Bu, çok boyutlu gazın ana yürütme karmaşıklığının çoğunlukla, ebeveyn çağrının tüm gazını iletmeyen alt çağrıları işlemesinden kaynaklandığı için böyledir, EOF ise bu tür alt çağrıları yasadışı hale getirmek için sadece bu sorunu önemsiz hale getirebilir (ve yerel hesap soykütlesi için bir protokol içinde kısmi gazın mevcut ana kullanım durumu için bir alternatif sunar).
Durum doğrulama ve geçmişin süresi arasında önemli bir işbirliği var. Bugün, istemci 1TB yakınında geçmiş verileri depolamak zorundadır; bu veriler durum verilerinin katlarıdır. İstemci durumsuz olsa bile, istemci depolama geçmiş verileri sorumluluğunu ortadan kaldıramadığı sürece neredeyse hiç depolama yapamayacaktır. Bu konuda atılacak ilk adım EIP-4444'tür, bu da geçmiş verilerin torrentlerde veya Portal Network portal ağındaki depolanması anlamına gelir.
EVM 执行的geçerlilik kanıtı
Biz hangi sorunu çözmek istiyoruz?
ETH Blok doğrulamasının uzun vadeli hedefi oldukça açıktır - ETH Blok'un aşağıdaki yollarla doğrulanabilmesi gerekmektedir: (i) Blok'u indirmek veya sadece veri kullanılabilirliği örnekleme kısmını indirmek; (ii) Bir Blok'un geçerli olup olmadığını doğrulayan küçük bir kanıt. Bu, mobil istemci, tarayıcı cüzdan veya hatta başka bir zincirde (veri kullanılabilirliği olmayan bir bölüm olmadan) gerçekleştirilebilen çok düşük kaynak tüketen bir işlem olacaktır.
Bu hedefe ulaşmak için (i) konsensüs katmanı (yani hisse senedi kanıtı) ve (ii) yürütme katmanı (yani EVM) için SNARK veya STARK kanıtları gereklidir. İlkini zaten bir zorluk olarak ele almak gerekiyor ve konsensüs katmanını sürekli olarak geliştirmenin bir parçası olarak çözülmelidir (örneğin, tek yuva finalitesi için). İkincisi, EVM yürütme kanıtlarını gerektirir.
O nedir, nasıl çalışır?
Görünüşe göre, ETH Eter spesifikasyonunda, EVM bir durum geçiş fonksiyonu olarak tanımlanmıştır: Eğer bir önceki durum S'niz, bir Blok B'niz varsa, bir sonraki durum S' = STF(S, B) hesaplıyorsunuz. Kullanıcılar hafif müşteri kullansalar bile, tam olarak S ve S'ye sahip değillerdir, hatta E'ye sahip değillerdir; bunun yerine bir önceki durum kökü R, bir sonraki durum kökü R' ve bir Blok hash değeri H'ye sahiptirler.
· Ortak giriş: Önceki durum kökü R, sonraki durum kökü R', blok hash'i H
· Özel giriş: Program bloğu B, program bloğu Q tarafından erişilen durumdaki nesneler, Q'yi yürüttükten sonra aynı nesneler, durum kanıtları (örneğin Merkle dalları) P
· Argüman 1: P, Q'nun temsil ettiği durumun bazı kısımlarını içerdiğini kanıtlayan geçerli bir kanıttır.
· Argüman 2: STF Q üzerinde çalıştırılıyorsa, (i) işlem sadece Q'nun içindeki nesnelere erişir, (ii) veri blokları geçerlidir, (iii) sonuç Q'
· 3. iddia: Q' ve P bilgilerini kullanarak yeni durum kökünü yeniden hesaplarsak, R' elde ederiz
Eğer böyle bir durum varsa, tam olarak doğrulanan ETH EVM işlemini gerçekleştiren hafif bir istemciye sahip olabilirsiniz. Bu, istemcinin kaynaklarının oldukça düşük olduğu anlamına gelir. Gerçek bir tam olarak doğrulanan ETH müşterisi elde etmek için, Konsensüs tarafında aynı çalışmayı yapmak gerekmektedir.
EVM hesaplamaları için geçerlilik kanıtı uygulaması zaten mevcut ve L2 tarafından yaygın bir şekilde kullanılıyor. Ancak EVM geçerlilik kanıtının L1'de kullanılabilir hale gelmesi için hala çok çalışma yapılması gerekiyor.
Mevcut araştırmalarla nasıl ilişkisi var?
· EFPSE ZK-EVM（由于存在更好的选择，现已停用）
· Zeth, işleyişi EVM'yi RISC-0 ZK-VM'ye derlemek olarak çalışır.
· ZK-EVM Biçimsel Doğrulama projesi
Başka neler yapabilirsiniz?
Bugün, elektronik muhasebe sisteminin geçerlilik kanıtı, güvenlik ve doğrulama süresi açısından yetersizdir.
Bir güvenliğin geçerlilik kanıtı, SNARK'ın EVM hesaplamasını gerçekten doğruladığını ve hiçbir açığın olmadığını sağlamalıdır. Güvenliği artırmak için iki ana teknik çoklu doğrulayıcı ve formal doğrulamadır. Çoklu doğrulayıcı, çoklu bağımsız geçerlilik kanıtı uygulamasına atıfta bulunur, sanki birden fazla istemci gibi; eğer bir Blok bu uygulamalardan biri tarafından yeterince büyük bir alt küme ile kanıtlanırsa, istemci o Blok'ü kabul eder. Formal doğrulama, genellikle matematik teoremlerini kanıtlamak için kullanılan araçları kullanarak, geçerlilik kanıtının, EVM K semantiği veya python ile yazılmış ETHereum yürütme katmanı spesifikasyonu (EELS) gibi altta yatan EVM spesifikasyonunun doğru bir şekilde uygulandığını kanıtlamayı içerir.
Yeterince hızlı doğrulama süresi, herhangi bir ETH bloğunun doğrulanmasının 4 saniyeden kısa bir sürede gerçekleşebileceği anlamına gelir. Bugün, bu hedefe oldukça uzak bir noktadayız, ancak iki yıl önce hayal ettiğimizden çok daha yakınız. Bu hedefe ulaşmak için üç yönde ilerleme kaydetmemiz gerekiyor:
· Paralelleştirme – En hızlı EVM doğrulayıcısı, bir Ethereum bloğunu ortalama 15 saniyede kanıtlayabilir. Bunu, yüzlerce GPU'yu paralel hale getirerek ve sonunda çalışmalarını bir araya getirerek yapar. Teorik olarak, hesaplamayı O(log(N)) zamanında kanıtlayabilen bir EVM doğrulayıcısının nasıl oluşturulacağını tam olarak biliyoruz: her adımı bir GPU'nun yapmasına izin verin ve ardından bir "toplama ağacı" oluşturun:
Bu bir zorlukla karşılaşır. En kötü durumda bile, yani çok büyük bir işlem tüm Blok'ı kapladığında, hesaplamanın bölünmesi sırayla değil, altta yatan Sanal Makine'nin işlem kodlarına (EVM veya RISC-V gibi) göre yapılmalıdır. Sanal Makine'nin "belleği"nin farklı bölümler arasında tutarlı kalmasını sağlamak, uygulama sürecinde önemli bir zorluktur. Ancak, bu tür bir özyinelemeli kanıtı gerçekleştirebilirsek, en azından gecikme süresi sorunu çözülmüş olur, diğer yönlerde herhangi bir iyileştirme olmasa bile.
· Kanıt sistemi optimizasyonu - Orion, Binius, GRK gibi yeni kanıt sistemleri ve diğer bilgiler, genel hesaplama doğrulama süresini büyük ölçüde kısaltabilir.
· Diğer EVM gaz maliyeti değişiklikleri - EVM'deki birçok şey optimize edilebilir, böylece özellikle en kötü durumlarda doğrulayıcılara daha uygun hale gelir. Bir saldırgan, doğrulayıcıyı on dakika boyunca bloke eden bir Blok oluşturabilirse, sadece 4 saniye içinde normal bir ETH Blok'un doğrulanması yeterli olmayacaktır. Gerekli EVM değişiklikleri genel olarak aşağıdaki kategorilere ayrılabilir:
gas maliyetinin değişimi - bir işlemin kanıtlanması uzun sürerse, hesaplama hızı göreceli olarak hızlı olsa bile yüksek gas maliyeti olmalıdır. EIP-7667, bu ciddi sorunu ele almak için önerilen bir EIP'dir: (geleneksel) hash fonksiyonlarının gas maliyetini önemli ölçüde arttırır çünkü bu fonksiyonların işlem kodları ve önceden derleme göre daha ucuzdur. Bu gas maliyetlerinin artışını telafi etmek için, EVM işlem kodlarının düşük maliyetli gas maliyeti kanıtını düşürerek ortalama işlemci hızını sabit tutabiliriz.
Veri yapıları değişimi - STARK için daha dostane bir yöntemle durum ağacını değiştirmenin yanı sıra, işlem listesi, makbuz ağacı ve diğer yüksek maliyetli kanıtları da değiştirmemiz gerekiyor. Etan Kissling'in işlem ve makbuz yapısını SSZ'nin EIP'sine taşıması bu yönde atılmış bir adımdır.
Ayrıca, önceki bölümde bahsedilen iki araç (çok boyutlu gas ve gecikme süresi durumu) de bu konuda yardımcı olabilir. Ancak, dikkat edilmesi gereken nokta, durumsuz doğrulama ile farklı olarak, bu iki aracı kullanmanın, şu anda ihtiyacımız olan işi tamamlamak için yeterli teknolojiye sahip olduğumuz anlamına geldiğidir ve bu teknolojileri kullansak bile, tam ZK-EVM doğrulaması daha fazla çalışma gerektirir - sadece daha az çalışma gerektirir.
Yukarıda bahsedilmeyen bir nokta, kanıtlayıcı donanımdır: GPU, FPGA ve ASIC kullanarak daha hızlı kanıt oluşturmak. Fabric Cryptography, Cysic ve Accseal, bu alanda ilerleme kaydeden üç şirkettir. Bu, L2 için çok değerli olsa da, L1'in belirleyici bir faktörü olması pek olası değildir, çünkü insanlar L1'in yüksek Merkeziyetsizlik seviyesini korumasını istiyorlar, bu da kanıt oluşturmanın ETH blok zinciri kullanıcılarının makul aralığında olması gerektiği anlamına geliyor ve tek bir şirketin donanımının darboğaz kısıtlamasına tabi olmamalıdır. L2, daha olumlu bir dengeleme yapabilir.
Bu alanlarda daha fazla çalışma yapılması gerekmektedir:
Paralel kanıt, sistemdeki farklı parçaların "paylaşılan belleği" (örneğin arama tablosu) paylaşabileceğini gerektirir. Bunu yapmanın tekniklerini biliyoruz, ancak bunun gerçekleştirilmesi gerekiyor.
· Daha fazla analiz yapmamız gerekiyor, böylece en kötü durumda doğrulama süresini en aza indirgemek için ideal gaz maliyet değişim setini bulabiliriz.
· Bizim daha fazla çalışma kanıt sistemi açısından gerekiyor
Olası maliyet:
· Güvenlik ve doğrulayıcı süresi: Daha agresif bir karma işlevi, daha karmaşık bir kanıt sistemi veya daha agresif bir güvenlik varsayımı veya diğer tasarım seçenekleri seçilirse doğrulayıcı süresi kısaltılabilir.
· Merkeziyetsizlik ve kanıtlayıcı zamanı: Topluluk, hedeflenen kanıtlayıcı donanımın 'özellikleri' konusunda uzlaşmaya varmalıdır. Kanıtlayıcıların büyük ölçekli varlıklar olması isteniyor mu? Bir ETH bloğunu 4 saniye içinde kanıtlayabilen yüksek kaliteli bir dizüstü bilgisayar mümkün mü? Arada mı?
Diğer yol haritası bölümleriyle nasıl etkileşime geçiyor?
L1 EVM geçerlilik kanıtı için gereken temel teknoloji, büyük ölçüde diğer iki alana da paylaşılmaktadır:
· L2'nin geçerlilik kanıtı (yani "ZK rollup")
· Durumsuz "STARK ikili hash kanıtı" yöntemi
L1 başarıyla geçerlilik kanıtını gerçekleştirdiğinde, kolay tek kişilik Stake'e ulaşmak mümkün olur: en zayıf bilgisayarlar bile (telefonlar veya akıllı saatler dahil) Stake yapabilir. Bu, tek kişilik Stake'in diğer kısıtlamalarını (örneğin 32ETH asgari miktarı) çözmede değerini daha da artırır.
Ayrıca, L1'in EVM geçerlilik kanıtı, L1'in gas limitini büyük ölçüde artırabilir.
Konsensüs'un geçerlilik kanıtı
Biz hangi sorunu çözmek istiyoruz?
SNARK'ı kullanarak bir ETH bloğunu tamamen doğrulamak istiyorsak, EVM'nin yürütülmesi sadece kanıtlamamız gereken tek kısım değildir. Ayrıca, tasdik, yani mevduat işlemlerinin işlenmesi, çekilme işlemleri, imza işlemleri, doğrulayıcı bakiye güncellemeleri ve ETH Proof of Stake bölümündeki diğer unsurların da kanıtlanması gerekmektedir.
Konsensüs, EVM'den çok daha basittir, ancak karşılaştığı zorluk şudur ki, L2 EVM katmanımız olmadığı için, her durumda çoğu çalışma tamamlanmalıdır. Bu nedenle, ETH blok zinciri üzerinde Konsensüs'ün kanıtlanması için herhangi bir uygulamanın 'sıfırdan başlaması' gerekmektedir, ancak kanıt sistemi üzerine inşa edilebilecek paylaşılan iş vardır.
Ne olduğu, nasıl çalışır?
beacon ağı, EVM gibi bir durum geçiş işlevi olarak tanımlanır. Durum geçiş işlevi temel olarak üç bölümden oluşur:
· ECADD (BLS imzasını doğrulamak için kullanılır)
· Eşleştirme (BLS imzasını doğrulamak için kullanılır)
· SHA256 Hash değeri (durumun okunması ve güncellenmesi için kullanılır)
Her Blok içinde, her doğrulayıcı için 1-16 adet BLS12-381 ECADD'yi (birden fazla kümede imza olabileceği için) kanıtlamamız gerekiyor. Bu, alt küme ön hesaplama teknolojisi ile telafi edilebilir, bu nedenle her doğrulayıcının sadece bir BLS12-381 ECADD'yi kanıtlaması gerektiğini söyleyebiliriz. Şu anda, her yuva için 30000 doğrulayıcı imzası bulunmaktadır. Gelecekte, tek zaman dilimi finalite uygulaması ile bu durum iki yönde değişebilir: "brute force" yolunu izlersek, her zaman dilimindeki doğrulayıcı sayısı 1 milyona kadar artabilir. Aynı zamanda, Orbit SSF kullanılırsa, doğrulayıcı sayısı 32768 veya hatta 8192'ye kadar azalabilir.
BLS Aggregasyon Nasıl Çalışır: Doğrulama toplam imza için her katılımcının bir ECADD'ye ihtiyacı olduğunu, bir ECMUL yerine. Ancak 30000 ECADD hala büyük bir kanıt miktarıdır.
Eşleme için, şu anda her yuvasında en fazla 128 kanıt bulunur, bu da 128 eşlemeyi doğrulamanız gerektiği anlamına gelir. ElP-7549 ve ilave düzenlemelerle, her yuva 16'ya kadar azaltılabilir. Eşleme sayısı azdır, ancak maliyeti son derece yüksektir: Her eşlemenin çalışma (veya kanıt) süresi ECADD'den k kat daha uzundur.
BLS12-381 işleminin ana zorluğu, BLS12-381 alan boyutuna eşit eğri derecesi olmayan uygun eğri olmamasıdır, bu da herhangi bir kanıt sistemi için oldukça büyük bir maliyet artışına neden olur. Öte yandan, ETHereum için önerilen Verkle ağacı Bandersnatch eğrisiyle oluşturulmuştur, bu da BLS12-381'in SNARK sistemi içinde Verkle dalını kanıtlamak için kullanılan kendi eğrisi haline gelmesini sağlar. Saniyede 100 G1 toplama kanıtı yapabilen basit bir uygulama; kanıt hızını yeterince hızlı hale getirmek için muhtemelen GKR gibi ustaca tekniklere ihtiyaç duyulacaktır.
SHA256 hash değeri için, şu anda en kötü senaryo dönüm dönüş bloğu, tüm doğrulayıcıların kısa denge ağacı ve çok sayıda doğrulayıcı dengesi güncellenecektir. Her doğrulayıcının kısa denge ağacı sadece bir bayttır, bu nedenle 1 MB veri yeniden karma alınır. Bu 32768 SHA256 çağrısıyla eşdeğerdir. Eğer bin doğrulayıcının bakiyesi bir eşik değerinin üzerinde veya altında ise, doğrulayıcılar kayıtlarındaki geçerli bakiyeyi güncellemek gerekebilir. Bu bin adet Merkle dalına denk gelir, bu nedenle 10000 karma değeri gerekebilir. Karıştırma mekanizması her doğrulayıcının 90 Bit'i gerektirir (bu nedenle 11 MB veri gerektirir), ancak bu herhangi bir dönemde hesaplanabilir. Tek slotta sonlandırma durumunda, bu sayılar belirli durumlara göre değişebilir. Karıştırma gerekli olmaktan çıkar, ancak Orbit bu ihtiyacı belirli bir ölçüde geri kazanabilir.
Başka bir zorluk, bir Blok'u doğrulamak için Açık Anahtar da dahil olmak üzere tüm doğrulayıcı durumlarını yeniden elde etmek gerektiğidir. 1 milyon doğrulayıcı için sadece Açık Anahtar'ı okumak 48 milyon bayt gerektirir, bunun üzerine Merkle dalı eklenir. Bu, her bir dönemde milyonlarca karma değeri gerektirir. PoS'nin etkinliğini kanıtlamamız gerekiyorsa, gerçekçi bir yöntem, bir tür artımlı doğrulanabilir hesaplama şeklidir: kanıt sistemi içinde ayrı bir veri yapısı depolamak, bu veri yapısının optimize edilmiş bir şekilde etkili bir şekilde aranabilmesini ve güncellemelere karşı kanıtlanabilmesini sağlamaktır.
Sonuç olarak, birçok zorluk var. Bu zorluklarla en etkili şekilde başa çıkmak için muhtemelen beacon ağına derinlemesine yeniden tasarım gerekecek ve bu muhtemelen tek yuva sonlandırmaya doğru bir dönüşü içerecektir. Bu yeniden tasarımın özellikleri muhtemelen şunları içerebilir:
· hash fonksiyonunun değişimi: Şu anda kullanılan "tam" SHA256 hash fonksiyonu, dolayısıyla doldurma nedeniyle her çağrıda iki kez altta yatan sıkıştırma fonksiyonunu çağırmak zorunda kalır. Eğer SHA256 sıkıştırma fonksiyonu kullanırsak, en azından 2 kat kazanabiliriz. Eğer Poseidon kullanırsak, muhtemelen 100 kat kazanç elde edebiliriz, bu da tüm sorunlarımızı (en azından hash değeri açısından) tamamen çözebilir: Saniyede 1.7 milyon hash değeri (54MB), hatta bir milyon doğrulama kaydı da kanıt içinde birkaç saniye içinde "okunabilir".
· Eğer Orbit ise, doğrulayıcı kayıtlarını karıştırdıktan sonra doğrudan depolarız: Belirli bir yuva için belirli bir sayıda doğrulayıcıyı (örneğin 8192 veya 32768) komite olarak seçerseniz, bunları birbirlerinin yanına doğrudan duruma yerleştiririz, bu sayede tüm doğrulayıcıların Açık Anahtarlarını okumak için en az sayıda hash gereklidir. Bu şekilde tüm denge güncellemeleri verimli bir şekilde tamamlanabilir.
· İmza birleştirme: Herhangi bir yüksek performanslı imza birleştirme çözümü, ağdaki farklı düğümlerin imza alt kümesini araştırma gerektiren bir tür özyineleme kanıtını içerir. Bu, doğal olarak kanıt işini ağdaki birden fazla düğüme dağıtır ve 'son kanıtlayıcı'nın iş yükünü büyük ölçüde azaltır.
· Diğer imza şemaları: Lamport+Merkle imzası için 256+32 adet hash değeri gereklidir; 32768 imzacı ile çarpılırsa 9437184 hash değeri elde edilir. İmza şemasını optimize ettikten sonra, bu sonucu daha da iyileştirmek için küçük bir sabit faktör kullanılabilir. Poseidon kullanırsak, bu tek bir yuva içinde kanıtlanabilir. Ancak aslında, rekürsif birleşim şeması daha hızlı olacaktır.
Mevcut araştırmalarla nasıl ilişkisi var?
· Basit Ethereum Konsensüsü ispatı (yalnızca senkronizasyon komitesi için)
Helios, included in SP1 of Simplified Chinese, is concise.
· Özet BLS12-381 Önceden Derlenmiş
· Halo2 temelli BLS toplu imza doğrulaması
Hangi işler yapılmalı, nasıl seçim yapılmalı:
Aslında, Ethereum Konsensüsü'nün geçerlilik kanıtını elde etmek için yıllarca süreye ihtiyacımız var. Bu, tek yuva finality, Orbit, İmza Algoritması'nı değiştirme ve güvenlik analizi gibi diğer problemleri çözmek için gereken zamanla yaklaşık olarak aynıdır ve güvenlik analizi, Poseidon gibi 'ilerici' bir karma işlevini kullanmak için yeterli güvene sahip olmayı gerektirir. Bu nedenle, en akıllıca yaklaşım bu diğer sorunları çözmek ve aynı zamanda STARK'ın dostane doğasını göz önünde bulundurmaktır.
Ana tartışma muhtemelen işlem sırasında, Ethereum'un uzlaşma katmanını daha kademeli bir yaklaşım ve daha radikal bir "birçok şeyi bir kerede değiştirme" yaklaşımı arasında dengelemektir. EVM için aşamalı yaklaşım makuldir çünkü geriye dönük uyumluluk üzerindeki etkileri en aza indirebilir. Uzlaşma katmanı için geriye dönük uyumluluk etkisi daha azdır ve beacon ağı oluşturma şeklinin çeşitli detaylarını daha "kapsamlı" bir şekilde yeniden düşünmek, SNARK dostu optimizasyonları en iyi şekilde yapmak da faydalıdır.
Diğer yol haritası bölümleriyle nasıl etkileşime geçiyor?
ETH bloğunda PoS uzun vadeli olarak yeniden tasarlanırken, STARK dostu bir faktör olarak öncelikli bir düşünce olmalıdır, özellikle tek yuva finalitesi, Orbit, imza planı değişikliği ve imza birleştirme.
Orijinal makaleye bağlantı