Vitalik yeni makale: Ethereum'un muhtemel geleceği, The Verge

原文标题：《Ethereum协议可能的未来，第4部分：The Verge》

Orijinal yazar: Vitalik Buterin

Orijinal metin çevirisi: Mensh, ChainCatcher

Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy Ryan Sean Adams, and Uma Roy için geri bildirim ve gözden geçirme için özel teşekkürler.

Blok zincirinin en güçlü özelliklerinden biri, herhangi birinin kendi bilgisayarında bir Düğüm çalıştırabilmesi ve Blok zincirinin doğruluğunu doğrulayabilmesidir. 9596 PoW, PoS çalıştıran Düğümün anında kuralları değiştirmeyi kabul etmesi ve yeni kurallara göre Blok üretmeye başlaması durumunda, tam olarak doğrulanan her Düğüm, zinciri reddedecektir. Bu komplocu gruba ait olmayan madenciler, otomatik olarak eski kuralları takip eden bir on-chain'e bir araya gelecek ve bu zinciri oluşturmaya devam ederken, tam olarak doğrulanan kullanıcılar bu zinciri takip edecektir.

Bu, blockchain ve merkezi sistem arasındaki temel farktır. Ancak, bu özelliğin gerçekleştirilebilmesi için yeterli sayıda kişi için tam bir doğrulama düğümünün çalıştırılması gerçekten mümkün olmalıdır. Bu hem çıkartıcılar için geçerlidir (çünkü çıkartıcılar zinciri doğrulamazlarsa, protokol kurallarını uygulamak için katkıda bulunmazlar), hem de normal kullanıcılar için geçerlidir. Günümüzde, tüketici dizüstü bilgisayarlarında (bu makaleyi yazarken kullandığım dizüstü bilgisayar da dahil olmak üzere) tam bir doğrulama düğümünü çalıştırmak mümkündür, ancak bunu yapmak oldukça zordur. The Verge, tam bir doğrulama zincirinin hesaplama maliyetini düşürerek, her cep telefonu cüzdanı, tarayıcı cüzdanı ve hatta akıllı saatin varsayılan olarak doğrulama yapmasını sağlamayı amaçlamaktadır.

The Verge 2023 Yol Haritası

Başlangıçta, "Verge", ETH zincir durumu depolama işleminden Verkle ağacına (ETH blokunun durumsuz doğrulamasını sağlayan daha sıkı kanıtlara izin veren bir ağaç yapı) atıfta bulunuyordu. Bir Düğüm, bir ETH bloğunu doğrulayabilir ve ETH zinciri durumunu (hesap bakiyesi, sözleşme kodu, depolama alanı vb.) herhangi bir yerde depolamadan yapabilir, bunun maliyeti bir kanıtı doğrulamak için yüzlerce KB veri ve birkaç yüz milisaniye ek süre gerektirir. Şimdi Verge, ETH zinciri için en büyük kaynak verimliliği doğrulamasını gerçekleştirmeye odaklanan daha büyük bir vizyonu temsil ediyor, bu sadece durumsuz doğrulama teknolojisi değil, aynı zamanda tüm ETH işlemlerinin SNARK kullanarak doğrulanması da dahil.

SNARK doğrulaması için uzun vadeli takip etmenin yanı sıra, Verkle ağacının en iyi teknoloji olup olmadığı yeni bir sorun daha var. Verkle ağacı, Kuantum Bilgisayarların saldırısına kolayca maruz kalır, bu nedenle şu anda KECCAK Merkle Patricia ağacındaki Verkle ağacını kullanıyorsak, gelecekte ağacı tekrar değiştirmemiz gerekecektir. Merkle ağacının kendine benzer yöntemi, STARK olarak bilinen Merkle dallarını atlayarak bunları ikili bir ağaca yerleştirmektir. Geçmişe bakıldığında, bu yöntem maliyeti ve teknik karmaşıklığı nedeniyle gerçekleştirilemez olarak kabul edilmiştir. Ancak, son zamanlarda, Starkware'in bir dizüstü bilgisayarda ckcle STARKs kullanarak saniyede 1.7 milyon Poseidon hash'ini doğruladığını ve GKB gibi teknolojilerin ortaya çıkmasıyla daha fazla "geleneksel" hash değerinin de doğrulama süresinin hızla kısaldığını gördük. Sonuç olarak, "Verge" son bir yılda daha açık hale geldi ve birkaç olasılığı var.

The Verge: Kritik Hedef

• Stateless client: The storage space required for full verification client and marking node should not exceed a few GB.
• (Uzun vadeli) Zinciri tamamen akıllı saatte doğrulama (Konsensüs ve yürütme). Bazı verileri indirin, SNARK'ı doğrulayın, tamamlayın.

Bu bölümde

• Durumsuz istemci: Verkle veya STARKs
• EVM yürütmesinin geçerlilik kanıtı
• Konsensüs'ın geçerlilik kanıtı

Duruma Bağlı Olmayan Doğrulama: Verkle ya da STARKs

Hangi sorunu çözmek istiyoruz？

Şu anda, Eter blokta doğrulamak için yüzlerce terabayt durum verisi depolamak zorundadır ve bu miktar her yıl artmaktadır. Orijinal durum verisi yaklaşık olarak her yıl 30 GB artmaktadır ve tek bir istemci, üçlüyü etkili bir şekilde güncellemek için bazı ek verileri üzerinde depolamak zorundadır.

Bu, tam Ethereum düğümünü çalıştırabilen kullanıcı sayısını azaltır: Ethereum durumunu saklayacak kadar büyük sabit diskler yaygın olsa da, insanların genellikle yalnızca birkaç yüz gigabayt depolama alanına sahip bilgisayarlar satın aldığını varsayarsak. Durum boyutu ayrıca ilk düğüm oluşturma sürecinde büyük sürtünme yaratır: Düğümün tüm durumu indirmesi gerekebilir, bu da birkaç saat veya gün sürebilir. Bu çeşitli zincirleme tepkilere neden olur. Örneğin, Düğüm oluşturan kişinin Düğüm yapılandırmasını yükseltme zorluğunu büyük ölçüde artırır. Teknik olarak, duraksamadan bir yükseltme yapılabilir - yeni bir istemci başlatın, senkronizasyonunu bekleyin, eski istemciyi kapatın ve Gizli Anahtarı transfer edin - ancak pratikte bu teknik olarak çok karmaşıktır.

Nasıl çalışır?

Durum doğrulama, Blok'ları Düğümün tüm durumunu bilmeksizin doğrulamasına izin veren bir teknolojidir. Bunun yerine, her Blok, (i) erişeceği durumun belirli bir konumundaki değeri, kodu, bakiyeyi, depolamayı içeren bir şahit ve (ii) bu değerlerin doğru olduğunu kanıtlayan bir şifreleme kanıtıyla birlikte gelir.

Aslında, durumsuz doğrulamanın gerçekleştirilmesi, Ethereum'un durum ağacı yapısını değiştirmeyi gerektirir. Bunun nedeni, mevcut Merkle Patricia ağacının herhangi bir şifreleme kanıtı düzenlemenin son derece kullanıcı dostu olmamasıdır, özellikle en kötü durumda. Hem 'orijinal' Merblk dalları hem de STARK olarak 'paketlenmiş' olma olasılıkları, durum budur. Temel zorluklar MPT'nin bazı zayıf noktalarından kaynaklanmaktadır:

1. Bu, bir 6 dallı ağaçtır (her Düğüm'ün 16 alt Düğümü vardır). Bu, N boyutunda bir ağaçta bir kanıtın ortalama olarak 32 * (16-1) * log 16 (N) = 120 * log 2 (N) bayt veya 2 ^ 32 öğenin olduğu bir ağaçta yaklaşık 3840 bayt gerektirdiği anlamına gelir. İkili ağaç için sadece 32 * (2-1) * log 2 (N) = 32 * log 2 (N) bayt veya yaklaşık 1024 bayt gereklidir.

2. Kod Merkle ileştirilmedi. Bu, hesap kodunun herhangi bir erişim iznini kanıtlamak için tüm kodun sağlanması gerektiği anlamına gelir, en fazla 24000 bayt.

En kötü durumu aşağıdaki gibi hesaplayabiliriz:

30000000 gas / 2400 (soğuk hesap okuma maliyeti) * (5 * 488 + 24000) = 330000000 byte

分支成本略有 düşüş (5480 yerine 8480 kullanarak), çünkü daha fazla dal olduğunda üst kısım tekrarlanır. Bununla birlikte, bir zaman diliminde indirilmesi gereken veri miktarı tamamen gerçekçi değildir. Eğer bunu STARK ile paketlemeyi denemeye çalışırsak, iki sorunla karşılaşırız: (i) KECCAK, STARK'a göre daha az dostanedir; (ii) 330 MB veri, KECCAK yuvarlama fonksiyonuna 5 milyon çağrıyı kanıtlamamız gerektiği anlamına gelir, bu da en güçlü tüketici donanımından başka tüm donanımlar için kanıtlanamaz, hatta STARK'ın KECCAK'ı daha verimli kanıtlayabileceğimiz durumda bile.

Eğer doğrudan onaltılık ağacı ikili ağaçla değiştirir ve kodu ekstra Merkle işlemine tabi tutarsak, en kötü durum yaklaşık olarak 30000000/2400* 32*( 32-14+ 8) = 10400000 bayt olur (14, 2 ^ 14 dallanma için gereksiz bitlerin çıkarılmasıdır ve 8 ise kod bloğuna girme kanıtının uzunluğudur). Dikkat edilmesi gereken bir nokta, her bir ayrı kod bloğuna erişim için gas maliyetinin değişmesidir; EIP-4762 tam olarak bunu yapar. 10.4 MB'lık bir kapasite çok daha iyi olsa da, birçok düğüm için, bir zaman dilimi içinde indirilen veri hala fazla. Bu nedenle, daha güçlü teknolojileri devreye sokmamız gerekiyor. Bu konuda önde gelen iki çözüm var: Verkle ağacı ve STARKed ikili karma ağacı.

Verkle 树

Verkle ağaç, daha kısa kanıtlar için eliptik eğri tabanlı vektör taahhütleri kullanır. Kilidin anahtarı, her ebeveyn-çocuk ilişkisi için yalnızca 32 bayt olan kanıt bölümüne karşılık gelir, ağaç genişliğinin tek sınırlaması, kanıt ağacı çok genişse kanıtın hesaplama verimliliğini düşüş eder. ETHereum için önerilen uygulamanın genişliği 256'dır.

Bu nedenle, kanıtta tek bir dalın boyutu 32-1 OG 256 (N) = 4 * log 2 (N) bayt olur. Dolayısıyla, teorik olarak maksimum kanıt büyüklüğü yaklaşık olarak 30000000 / 2400 * 32 * (32-14 + 8) / 8 = 130000 bayt (durum bloklarının dağılımı dengesiz olduğundan, gerçek hesaplama sonuçları biraz farklı olabilir ancak birinci yaklaşım değeri olarak kabul edilebilir).

Ayrıca dikkat edilmesi gereken bir diğer husus, yukarıdaki tüm örneklerde bu 'en kötü durum' durumu gerçekten en kötü durum değildir: daha kötü bir durum, saldırganın bilerek iki Adres'i 'çıkarması' ve bu Adres'lerin ağaçta daha uzun bir ortak önek sahip olmasını sağlaması ve verileri bir Adres'ten okumasıdır. Bu durumda en kötü durum senaryosunda dal uzunluğu 2 kat daha uzayabilir. Ancak böyle bir durum olsa bile, Verkle ağacının en kötü kanıt uzunluğu 2.6 MB'dir ve mevcut en kötü durum senaryosunda doğrulama verileri ile neredeyse aynıdır.

Bu talimatı bir başka şey için de kullandık: 'yan' depolama alanına erişimi çok ucuz hale getirdik: ya aynı sözleşmenin çok sayıda kod bloğu ya da bitişik depolama yuvası. EIP - 4762, bitişik erişimi tanımlar ve bitişik 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 bayt olur, bu hala kabul edilebilir bir aralıktadır. Güvenlik açısından 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, en fazla 10.4 MB'lık bir kanıt elde etmeniz, blok içindeki değeri kanıtlamanız ve ardından kanıtın yerine STARK'ın getirilmesi gerekmektedir. Böylece kanıt sadece kanıtlanması gereken veriyi içerir ve ayrıca gerçek STARK'tan gelen 100-300 kB sabit masrafları eklenir.

Buradaki ana zorluk zaman doğrulamasıdır. Yukarıdaki temel hesaplamaları yapabiliriz, ancak hesapladığımız şey bayt değil karmadır. 10.4 MB'lik bir Blok, 330000 karmaya denk gelir. Ayrıca saldırganın, "Adres" ağacında uzun bir ortak önek olan blokların olasılığını eklersek, en kötü durumda yaklaşık 660000 karma değeri elde ederiz. Bu nedenle, saniyede 200,000 karma yapabildiğimizi kanıtlayabilirsek, sorun olmaz.

Poseidon hash işlevini kullanan tüketici sınıfı dizüstü bilgisayarlarda bu sayılar zaten 01928374656574839201'e ulaşmıştır ve Poseidon hash işlevi özellikle STARK dostu olacak şekilde tasarlanmıştır. Bununla birlikte, Poseidon sistemi henüz tam olarak olgunlaşmamış olduğundan, birçok insan onun güvenliğine güvenmemektedir. Bu nedenle, gerçekçi iki yol bulunmaktadır:

1. Poseidon'a hızlı bir şekilde büyük miktarlarda güvenlik analizi yapın ve L1'e dağıtmak için yeterince tanıyın.
2. Daha "güvenli" bir karma işlevi kullanın, örneğin SHA 256 veya BLAKE

Konservatif bir kriptografik hash fonksiyonunun doğruluğunu kanıtlamak için, Starkware'in STARK devresi bu yazı yazılırken sadece tüketici dizüstü bilgisayarlarında 10-30 k hash değeri / saniye doğrulayabilir. Ancak STARK teknolojisi hızla gelişmektedir. Bugün bile GKR tabanlı teknolojiler, bu hızı 100-200 k aralığına kadar artırmayı göstermektedir.

Tanıklık kullanım vakaları dışında blok doğrulama

Blok dışında, daha verimli durumsuz doğrulama için diğer üç önemli kullanım durumu da var:

• Bellek Havuzu: Bir işlem yayınlandığında, P2P ağındaki düğümler işlemin geçerli olup olmadığını kontrol etmeden önce yeniden yayınlanması gerekebilir. Bugün doğrulama, imzaların doğruluğunu kontrol etmekle kalmaz, ayrıca bakiyenin yeterli olup olmadığını ve önekin doğru olup olmadığını da kontrol eder. Gelecekte (örneğin, EIP-7701 gibi doğal hesap soyutlamaları kullanılarak) bazı EVM kodlarının çalıştırılması gerektiği durumlarda, bir takım durum erişimleri yapacak olan kodlar da bulunabilir. Eğer düğüm durumsuzsa, işlem durum nesnesinin ispatını içeren bir ispatın eklenmesi gerekir.
• Liste İçerir: Bu, (muhtemelen küçük ölçekli ve karmaşık olmayan) Proof of Stake doğrulayıcıları tarafından bir sonraki Blok'un, (muhtemelen büyük ölçekli ve karmaşık olan) Blok oluşturucularının isteklerine bakılmaksızın işlem içermesine izin veren önerilen bir özelliktir. Bu, güç sahiplerinin Blok zincirini gecikme süresi işlemleri yoluyla manipüle etme yeteneğini zayıflatacaktır. Ancak, bu, doğrulayıcıların işlem listesindeki işlemlerin geçerliliğini nasıl doğrulayacaklarını bilmesini gerektirir.
• Hafif müşteri: Eğer kullanıcıların Metamask, Rainbow, Rabby gibi cüzdanlar aracılığıyla zincire erişmelerini istiyorsak, buna ulaşmak için hafif bir istemci (örneğin Helios) çalıştırmaları gerekiyor. Helios çekirdek modülü, kullanıcılara doğrulanmış durum kökü sağlar. Tamamen güvensiz bir deneyim elde etmek için ise kullanıcılar her RPC çağrısı için yaptıkları her istek için kanıt sağlamalıdır (örneğin, ETH ağı çağrısı isteği için, kullanıcıların eriştiği tüm durumları çağırma işlemi sırasında kanıtlama gereklidir).

Tüm bu durumların ortak bir noktası var, o da çok sayıda kanıt gerektirmeleridir, ancak her bir kanıt çok küçüktür. Bu nedenle, STARK kanıtları için bunlar gerçekten anlam taşımaz; aksine, en gerçekçi yaklaşım doğrudan Merkle dallarını kullanmaktır. Merkle dalının başka bir avantajı da güncellenebilir olmasıdır: Blok B köküne sahip X durum nesnesi için bir kanıt verildiğinde, bir alt Blok B 2 ve onun tanıklığı alındığında, kanıt güncellenebilir ve Blok B 2 kökü olarak ayarlanabilir. Verkle kanıtları da doğal olarak güncellenebilir.

Mevcut araştırmalarla nasıl bağlantılar kurulmuştur:

• Verkle ağaçları
• John Kuszmaul 关于 Verkle tree 的原始论文
• Starkware
• Poseidon 2 kağıt
• Ajtai (kafes sertliğine dayalı alternatif hızlı hash fonksiyonu)
• Verkle.info

Başka ne yapabilirim?

Kalan ana iş

1. EIP-4762'nin Sonuçları Hakkında Daha Fazla Analiz (stateless gas maliyet değişikliği)

2. Daha fazla geçiş programı tamamlamak ve test etmek, herhangi bir yabancı ülke ortamında uygulama planının karmaşıklığının ana kısmıdır

3. Poseidon, Ajtai ve diğer 'STARK-friendly' hash fonksiyonlarına yönelik daha fazla güvenlik analizi

4. "Konservatif" (veya "geleneksel") hash için daha fazla yüksek verimli STARK protokol özelliği geliştirmek, örneğin Binius veya GKR tabanlı.

Ayrıca, yakında aşağıdaki üç seçenekten birini seçme kararı vereceğiz: (i) Verkle ağacı, (ii) STARK dostu hash fonksiyonu ve (iii) koruyucu hash fonksiyonu. Özellikleri aşağıdaki tabloda özetlenmiştir:

Bu "başlık numaraları" dışında dikkate almanız gereken diğer önemli faktörler de vardır:

• Şu anda, Verkle ağaç kodu oldukça olgun hale geldi. Verkle dışında başka herhangi bir kod kullanmak, bir çatalı geciktirebilir ve muhtemelen birçatalı geciktirebilir. Bu da önemli değil, özellikle eğer Ethereum'a daha erken dahil etmek istediğimiz ekstra zamanımız varsa, hash fonksiyon analizi veya doğrulayıcı uygulaması veya diğer önemli özellikler için.
• Durum kökünü güncellemek için kullandığınızda, Verkle ağacından daha hızlıdır. Bu, hash tabanlı yöntemlerin tam düğüm senkronizasyon süresini düşürebileceği anlamına gelir.
• Verkle ağacının ilginç bir güncelleme özelliği vardır - Verkle ağacı şahitleri güncellenebilir. Bu özellik mempool, içerme listeleri ve diğer kullanım durumları için çok faydalıdır ve uygulama verimliliğini artırmaya yardımcı olabilir: durum nesnesi güncellendiğinde, son katmanın içeriğini okumadan önceki katmanın şahitlerini güncelleyebilirsiniz.
• Verkle ağacı SNARK kanıtlamasını yapmak daha zordur. Kanıt boyutunu binlerce bayta kadar düşürmek istiyorsak, Verkle kanıtı bazı zorluklar yaratacaktır. Bu, Verkle kanıtının doğrulamasının 256 bit işlemi büyük miktarda tanıtmasını gerektirmesi nedeniyledir, bu da kanıt sisteminin ya büyük bir maliyete sahip olmasını ya da kendi özel dahili yapısına sahip olmasını gerektirir, içinde 256 bit Verkle kanıtı kısmını içerir. Bu, durumsuz için bir sorun olmayabilir, ancak daha fazla zorluk getirecektir.

Eğer quantum güvenli ve makul derecede verimli bir şekilde Verkle tanıklığının güncellenebilirliğine 01928374656574839201 elde etmek istiyorsak, başka bir olasılık da örgü tabanlı Merkle ağacına dayalıdır.

En kötü durumda bile, sistem verimliliği yeterli değilse, bu eksikliği telafi etmek için beklenmedik bir araç olan çok boyutlu gazı kullanabiliriz: (i) call verisi; (ii) hesaplama; (iii) durum erişimi ve olası diğer farklı kaynaklar için ayrı gaz sınırları belirleme. Çok boyutlu gaz karmaşıklığı artırır, ancak karşılığında ortalama durum ve en kötü durum arasındaki oranı daha sıkı bir şekilde sınırlar. Çok boyutlu gaz sayesinde, teorik olarak kanıtlanması gereken maksimum dallanma sayısı 12500'den 3000'e kadar azalabilir. Bu, BLAKE 3'ün bugün bile (zar zor) yeterli olmasını sağlar.

Çok boyutlu gas, Blok'un kaynak sınırlamalarını alt seviye donanımın kaynak sınırlamalarına daha yakın hale getirir

Başka bir beklenmeyen araç, durum kökünün hesaplanma gecikme süresi sonrasında Blok arasındaki zaman dilimidir. Bu, durum kökünü hesaplama için tam 12 saniyemizin olduğu anlamına gelir, bu da demektir ki, en aşırı durumlarda bile, saniyede sadece 60000 karma sayısının yeterli olduğuna tekrar inanmamıza neden oluyor, bu tekrar BLAKE 3'ün sadece zorla gereksinimleri karşılayabileceği anlamına geliyor.

Bu yöntemin dezavantajı, bir hafif müşteri gecikme süresi eklemesidir, ancak bu tür gecikme süresini sadece kanıt oluşturma gecikme süresine indirmek için daha akıllıca teknikler de vardır. Örneğin, kanıt herhangi bir Düğüm tarafından üretildikten hemen sonra ağda yayınlanabilir, bir sonraki Blok'ü beklemek zorunda kalmadan.

Diğer yol haritası bölümleriyle nasıl etkileşime geçiyor?

Durumsuz sorunu çözmek, tek kişilik hedefin zorluğunu büyük ölçüde arttırdı. Eğer tek kişilik hedefin en düşük denge noktasına Orbit SSF veya Uygulama Katmanı gibi stratejilerle ulaşılabilirse, takım hedeflemesi daha mümkün hale gelecektir.

Eğer EOF aynı anda tanıtılırsa, çoklu boyutlu gaz analizi daha da kolaylaşacaktır. Bu, çoklu boyutlu gazın ana yürütme karmaşıklığının, ebeveyn çağrısının tüm gazını geçirmeyen alt çağrıları işlemekten kaynaklandığı için, EOF sadece bu tür alt çağrıları geçersiz kılmak için bu sorunu önemsiz hale getirebilir (ve yerel hesap soyutlaması, mevcut ana kullanım durumunun bir protokol içi alternatifini sağlar.

Durum doğrulama ve tarihli sona erme arasında önemli bir işbirliği vardır. Bugünlerde istemci, yaklaşık 1 TB tarih verisini depolamak zorunda; bu veriler durum verisinin katlarıdır. İstemci durumsuz olsa bile, istemcinin tarih verisini depolama sorumluluğunu kaldıramadıkça neredeyse depolamayan istemcinin hayali gerçekleşemez. Bu konuda ilk adım EIP-4444'tür ve bu aynı zamanda tarih verisinin torrentler veya Portal Network portal ağına depolanması anlamına gelir.

EVM'nin yürüttüğügeçerlilik kanıtı

Hangi sorunu çözmek istiyoruz？

ETH blok doğrulamasının uzun vadeli hedefi oldukça açıktır - ETH bloğunu aşağıdaki şekillerde doğrulayabilmelidir: (i) Blok indirme veya hatta yalnızca veri kullanılabilirliği örneklemesinin küçük bir kısmını indirme; (ii) Bloğun geçerli olduğunu doğrulayan küçük bir kanıt. Bu, düşük kaynak tüketimi gerektiren bir işlem olacak ve mobil istemci, tarayıcı cüzdanında tamamlanabilecek ve hatta başka bir zincirde bile tamamlanabilecektir (veri kullanılabilirliği bölümü olmadan).

Bu hedefe ulaşmak için, (i) konsensüs katmanı (yani hisse senedi kanıtı) ve (ii) yürütme katmanı (yani EVM) SNARK veya STARK kanıtlarına ihtiyaç duyulur. İlk önce zaten bir meydan okuma olan birincisi, örneğin tek yuva sonlandırıcılara yönelik olarak sürekli olarak konsensüs katmanını geliştirmek için çözülmelidir. İkincisi, EVM yürütme kanıtına ihtiyaç duyar.

Bu nedir, nasıl çalışır?

Formal olarak, ETHereum Blok zinciri spesifikasyonunda, EVM bir durum geçiş fonksiyonu olarak tanımlanmıştır: Bir önceki durum S, bir Blok B ve bir sonraki durum S' = STF(S, B) ile hesaplama yapmaktasınız. Kullanıcılar hafif müşteri kullandıklarında, tam olarak S ve S'ye sahip değillerdir, hatta E'ye bile; bunun yerine, bir önceki durum kökü R, bir sonraki durum kökü R' ve bir Blok karma değeri H'ye sahiptirler.

• Genel giriş: önceki durum kökü R, son durum kökü R', blokhash H
• Özel giriş: Program bloğu B, program bloğu Q'nun eriştiği durumdaki nesneler, Q'ya ait aynı nesnelerin durumları, durum ispatı (Merkle dalı gibi) P
• Savunma 1: P, Q'nun R tarafından temsil edilen durumun bazı kısımlarını içeren geçerli bir kanıttır.
• İddia 2: STF'yi Q üzerinde çalıştırırsanız, (i) yürütme işlemi yalnızca Q içindeki nesnelere erişir, (ii) blok geçerlidir ve (iii) sonuç Q' olur
• İstem 3: Yeni durum kökünü Q' ve P bilgileriyle yeniden hesaplarsanız, R' elde edersiniz

Bu durumda, tamamen doğrulanmış bir Ethereum Virtual Machine (EVM) yürütme sahip hafif istemciye sahip olabilirsiniz. Bu, istemcinin kaynaklarının oldukça düşük olduğu anlamına gelir. Gerçekten tamamen doğrulanmış bir Ethereum istemcisini gerçekleştirmek için, Konsensüs tarafında aynı işi yapmak gerekiyor.

EVM hesaplamaları için geçerlilik kanıtı uygulaması zaten mevcuttur ve L2'de yaygın olarak kullanılmaktadır. Ancak EVM geçerlilik kanıtının L1'de mümkün olması için yapılacak çok iş var.

Mevcut araştırmalarla hangi bağlantılar var?

• EFPSE ZK-EVM (devre dışı bırakıldı çünkü daha iyi seçenekler mevcut)
• Zeth, çalışma prensibi EVM'in RISC-0 ZK-VM'e derlenmesidir
• ZK-EVM 项目

Başka ne yapabilirim?

Şu anda, elektronik muhasebe sistemlerinin geçerlilik kanıtı açısından iki eksiklik bulunmaktadır: güvenlik ve doğrulama süresi.

Bir güvenlik doğrulama kanıtı, SNARK'ın EVM hesaplamasını gerçekten doğruladığını ve açıklar olmadığını sağlamalıdır. Güvenliği artırmak için kullanılan iki temel teknik çoklu doğrulayıcı ve biçimsel doğrulamadır. Çoklu doğrulayıcı, bağımsız olarak yazılmış birden fazla doğrulama kanıtı uygulamasına atıfta bulunur ve bu uygulamalardan biri tarafından yeterince büyük bir alt küme doğrulanırsa, istemci bu bloğu kabul eder. Biçimsel doğrulama, matematik teoremlerini kanıtlamak için kullanılan araçlar olan Lean 4 gibi, doğrulama kanıtının yalnızca altta yatan EVM spesifikasyonunu (örneğin EVM K semantiği veya python ile yazılmış ETH blok yürütme katmanı spesifikasyonu (EELS)) doğru bir şekilde kabul ettiğini kanıtlamak için kullanılır.

Yeterince hızlı doğrulama süresi, herhangi bir ETH bloğunun doğrulanabilmesi için 4 saniyenin altında bir sürede elde edilebileceğ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 - Şu anda en hızlı EVM doğrulayıcısı ortalama olarak bir Ethereum Blokunu 15 saniye içinde kanıtlayabilir. Bu, yüzlerce GPU arasında paralelleştirme yaparak ve sonunda işlerini bir araya getirerek gerçekleştirilir. Teorik olarak, hesaplamayı O(log(N)) zamanında kanıtlayabilen bir EVM doğrulayıcısı nasıl yapılacağını tam olarak biliyoruz: Her adımı bir GPU'ya yaptırın, sonra bir "birleştirme ağacı" yapın: 01928374656574839201

Bu, bir meydan okumayı temsil ediyor. En kötü durumda bile, yani çok büyük bir işlem tüm Blok'u kapladığında, hesaplamanın bölünmesi sırayla değil, işlem koduna (EVM veya RISC-V gibi altta yatan Sanal Makine'nin işlem koduna) göre yapılmalıdır. Sanal Makine'nin "belleği"nin farklı kısımları arasında tutarlı kalmasını sağlamak, uygulama sürecinde kritik bir meydan okuma. Ancak, bu tür bir özyinelemeli kanıtı gerçekleştirebilirsek, diğer herhangi bir iyileştirme olmasa bile, en azından kanıtlayıcının gecikme süresi sorununun çözüldüğünü biliyoruz.

• Proof system optimization--The new proof systems, such as Orion, Binius, GRK, and other more information, are likely to lead to another significant reduction in the verification time of general computation.
• EVM gaz maliyetinin diğer değişiklikleri - EVM'deki birçok şey optimize edilebilir ve özellikle en kötü durumda doğrulayıcılara daha uygun hale getirilebilir. Bir saldırgan, bir Blokun doğrulayıcıyı on dakika boyunca engelleyebileceği bir senaryo oluşturabilirse, sadece normal bir ETH Blokunu dört saniye içinde doğrulamak yeterli olmaz. Gerekli EVM değişiklikleri genel olarak aşağıdaki kategorilere ayrılabilir:

• gas maliyetinin değişmesi - bir işlemin kanıtlanması uzun sürüyorsa, hesaplama hızı hızlı olsa bile yüksek gas maliyeti olmalıdır. EIP-7667, bu ciddi sorunla ilgilenmek için bir EIP önerisidir: (geleneksel) hash fonksiyonlarının gas maliyetini büyük ölçüde artırır, çünkü bu fonksiyonların işlem kodları ve önceden derlenmiş işlemler göreli olarak ucuzdur. Bu gas maliyetinin artışını telafi etmek için, ortalama verimliliği korumak için düşük maliyetli EVM işlem kodlarına düşüş ispatı gas maliyeti uygulanabilir.

• Veri yapısı değişimi - STARK için daha uygun olan bir yöntemle durum ağacını değiştirmenin yanı sıra, işlem listesini, makbuz ağacını 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 gaz ve gecikme süresi durumu kök) de bu konuda yardımcı olabilir. Ancak, dikkat edilmesi gereken nokta, durumsuz doğrulamadan farklı olarak, bu iki aracı kullanmanın, mevcut ihtiyaçlarımızı tamamlamak için yeterli teknolojiye sahip olduğumuz anlamına geldiğidir ve bu teknolojileri kullanmak bile, tam ZK-EVM doğrulaması için daha fazla çalışma gerektirir - sadece daha az çalışma gerektirir.

Yukarıda bahsedilmeyen bir nokta, ispat cihazlarındır: GPU, FPGA ve ASIC kullanarak kanıt oluşturmayı daha hızlı bir şekilde yapabilirler. Fabric Cryptography, Cysic ve Accseal, bu alanda ilerleme kaydeden üç şirkettir. Bu, L2 için çok değerlidir, ancak 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 bir aralığında olması gerektiği anlamına geliyor ve tek bir şirketin donanım kısıtlamalarına maruz kalmamalıdır. L2 daha olumlu bir denge sağlayabilir.

Bu alanlarda daha yapılacak çok iş var:

• Paralelizasyon ispatının gerekliliği, sistemin farklı bölümlerinin 'paylaşımlı bellek' (örneğin arama tablosu) kullanabileceğini kanıtlamasını gerektirir. Bunu yapmak için gerekli teknolojilere sahibiz ancak bunların uygulanması gerekiyor.
• Daha fazla analiz yapmamız gerekiyor, böylece en kötü durumda doğrulama süresini en aza indirmek için ideal gaz maliyet değişim kümesini bulabiliriz.
• Bizim daha fazla çalışma kanıt sistemi açısından ihtiyacımız var

Olası maliyet:

• Güvenlik ve doğrulayıcı zaman: Daha agresif bir hash fonksiyonu, daha karmaşık bir kanıt sistemi veya daha agresif güvenlik varsayımları veya diğer tasarım seçenekleri seçilirse doğrulayıcı zamanını kısaltma olasılığı vardır.
• Ademi merkeziyetçilik ve Kanıt Süresi: Topluluğun, hedeflenen test donanımının "özellikleri" üzerinde anlaşmaya varması gerekir. Sertifikalandırıcının büyük ölçekli bir varlık olmasını zorunlu kılmak uygun mudur? Üst düzey tüketici dizüstü bilgisayarlarının bir Ethereum bloğunu 4 saniyede kanıtlayabilmesini bekliyor muyuz? Arada?
• Geriye dönük uyumluluğu kırmak: Diğer eksiklikler daha aktif bir şekilde gas maliyet değişikliği ile telafi edilebilir, ancak bu, bazı uygulamaların maliyetini orantısız bir şekilde artırma olasılığı daha yüksektir, bu da geliştiricileri kodları yeniden yazmaya ve yeniden dağıtmaya zorlayarak ekonomik olarak sürdürülebilirliği korumak için. Aynı şekilde, bu araçların her ikisi de kendi karmaşıklığı ve dezavantajlarına sahiptir.

Diğer yol haritası bölümleriyle nasıl etkileşime giriyor?

L1 EVM geçerlilik kanıtı所需的核心技术在很大程度上与其他两个领域共享：

• L2的geçerlilik kanıtı（即 "ZK rollup"）
• Durumsuz "STARK ikili hash kanıtı" yöntemi

L1 başarılı bir şekilde geçerlilik kanıtı sağlandığında, kolay bir tek kişilik Stake yapılabilir: En zayıf bilgisayarlar bile (telefonlar veya akıllı saatler dahil) Stake yapabilir. Bu, diğer sınırlamaları (örneğin 32 ETH alt sınırı gibi) çözmek için tek kişilik Stake çözümlerinin değerini daha da artırır.

Ayrıca, L1'in EVM geçerlilik kanıtı, L1'in gaz sınırını önemli ölçüde artırabilir.

Geçerlilik kanıtı Konsensüs

Hangi sorunu çözmek istiyoruz？

Eğer bir ETH bloğunu tamamen doğrulamak için SNARK kullanmak istiyorsak, EVM'nin yürütülmesi, kanıtlamamız gereken tek bölüm değildir. Ayrıca, depozito işlemleri, para çekme işlemleri, imza doğrulama, doğrulayıcı bakiye güncellemeleri ve ETH bloğunun Proof of Stake kısmının diğer unsurlarını da tasdik etmemiz gerekmektedir.

Konsensüs, EVM'den çok daha basit olmasına rağmen, karşılaştığı zorluk, L2 EVM konvolüsyonuna sahip olmamızdır, bu nedenle çoğu iş her durumda tamamlanmalıdır. Bu nedenle, ETH bloğu Konsensüs'ün herhangi bir kanıtının uygulanması "sıfırdan" yapılmalıdır, çünkü kanıt sistemi kendisi üzerinde paylaşılan işler şeklinde inşa edilebilir.

Nedir ve Nasıl Çalışır?

beacon ağı, EVM gibi bir durum geçiş fonksiyonu olarak tanımlanır. Durum geçiş fonksiyonu genellikle üç bileşenden oluşur:

• ECADD (BLS imzasını doğrulamak için kullanılır)
• Çift (BLS imzasını doğrulamak için kullanılır)
• SHA 256 Karma değeri (durum okuma ve güncelleme için kullanılır)

Her blokta, her doğrulayıcı için 1-16 BLS 12-381 ECADD'yi kanıtlamamız gerekir (imzalar birden fazla koleksiyonda bulunabileceğinden muhtemelen birden fazla). Bu, alt küme ön hesaplama teknikleri ile telafi edilebilir, bu nedenle her doğrulayıcıların yalnızca bir BLS 12-381 ECADD'yi kanıtlaması gerektiğini söyleyebiliriz. Şu anda, yuva başına 30.000 doğrulayıcı imzası bulunmaktadır. Gelecekte, tek yuva kesinliği elde edildiğinde bu iki yönde değişebilir: "kaba kuvvet" yolunu seçersek, yuva başına doğrulayıcılar sayısı 1 milyona çıkabilir. Aynı zamanda, Orbit SSF kabul edilirse, doğrulayıcı sayısı 32.768'de kalacak ve hatta 8.192'ye düşecek.

BLS Agregat Nasıl Çalışır: Her katılımcının bir ECMUL yerine bir ECADD yapması gerektiği için doğrulama toplam imza için sadece bir ECADD gerektirir. Ancak 30000 ECADD hala büyük bir kanıt miktarıdır.

Eşleme açısından, şu anda her yuva en fazla 128 kanıt içerebilir, bu da 128 eşlemenin doğrulanması gerektiği anlamına gelir. ElP-7549 ve daha fazla değişiklik ile her yuva 16'ya azaltılabilir. Eşleme sayısı azdır, ancak maliyeti çok yüksektir: her eşleme çalışma (veya kanıt) süresi ECADD'den katsayısız uzundur.

BLS 12-381 işleminin ana zorluğu, BLS 12-381 alan boyutuna eşit eğri derecesine sahip olmayan uygun eğrinin 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ğrisi üzerine inşa edilmiştir, bu da BLS 12-381'in SNARK sisteminde Verkle dallarını kanıtlamak için kullanılan kendi eğrisi haline gelmesini sağlar. Saniyede 100 G1 toplama kanıtı yapabilen daha basit bir uygulama; kanıt hızını yeterince hızlı hale getirmek için muhtemelen GKR gibi ustaca tekniklere ihtiyaç duyulacaktır.

SHA 256 hash değeri için, şu anda en kötü senaryo, epoch dönüş bloğu, tüm doğrulayıcı kısa denge ağacı ve çok sayıda doğrulayıcı dengesinin güncellenmesi demektir. Her doğrulayıcının kısa denge ağacında sadece bir byte olduğundan, 1 MB veri tekrar hashlenir. Bu, 32768 kez SHA 256 çağrısına 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ı kayıtlarının geçerli bakiyesi güncellenmelidir, bu da bin adet Merkle dalına eşdeğerdir, bu nedenle on bin adet hash değeri gerekebilir. Karıştırma mekanizması her doğrulayıcı için 90 Bit gerektirir (bu nedenle 11 MB veri gereklidir), ancak bu herhangi bir zamanda bir epoch'ta hesaplanabilir. Tek yuva sonlandığında, bu sayılar duruma göre değişebilir. Karıştırma gereksiz hale gelir, ancak Orbit bu tür bir ihtiyacı kısmen gidermeye devam edebilir.

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 almanız gerektiğidir. 1 milyon doğrulayıcı için sadece Açık Anahtar'ı okumak 48 milyon bayt gerektirir, bu da Merkle dallanmasını ekler. Bu, her bir dönemde milyonlarca karma değeri gerektirir. PoS'in geçerliliğini kanıtlamamız gerekiyorsa, gerçekçi bir yöntem, artımlı doğrulanabilir hesaplama şeklinde bir şeydir: kanıt sistemi içinde ayrı bir veri yapısı depolayarak, bu yapıyı optimize edip, etkin bir şekilde arayabilir ve güncellemelerini kanıtlayabilirsiniz.

Özetlemek gerekirse, pek çok zorluk var. Bu zorluklarla en etkili şekilde başa çıkmak için muhtemelen beacon ağına derinlemesine bir yeniden tasarım gerekebilir ve bu yeniden tasarımın tek kat sonlandırmaya yönelik bir geçişle aynı anda gerçekleştirilmesi olasıdır. Bu yeniden tasarımın özellikleri şunları içerebilir:

• hash fonksiyonunun değişimi: Şimdi kullanılan "tam" SHA 256 hash fonksiyonu olduğundan dolayı doldurma nedeniyle her çağrıda iki alt seviye sıkıştırma fonksiyonu çağrısına karşılık gelir. Eğer SHA 256 sıkıştırma fonksiyonu kullanırsak en az 2 kat kazanç elde ederiz. Poseidon kullanırsak, tüm sorunlarımızı (en azından hash değerleri açısından) tamamen çözebiliriz: saniyede 170 milyon hash (54 MB) ile, bir milyon doğrulama kaydı bile birkaç saniye içinde kanıtta "okunabilir".
• Orbit söz konusu olduğunda, karıştırılmış doğrulayıcı kayıtlarını doğrudan saklayın: Belirli sayıda doğrulayıcı (örneğin 8192 veya 32768) belirli bir yuva için komite olarak seçilirse, bunlar doğrudan yan yana duruma getirilir, böylece tüm doğrulayıcıların Açık Anahtarı minimum hash ile kanıta okunabilir. Bu aynı zamanda tüm terazi güncellemelerinin verimli bir şekilde yapılmasını sağlar.
• İmza birleştirmesi: Herhangi bir yüksek performanslı imza birleştirme çözümü, ağdaki farklı Düğümlerin imza alt kümelerini ara kanıtlamaya tabi tutar. Bu, kanıt görevinin ağdaki birden çok Düğüme bölünerek "son kanıtlayıcı"nın iş yükünün büyük ölçüde azalmasını sağlar.
• Diğer imza planları: Lamport + Merkle imza için imzayı doğrulamak için 256 + 32 karma değeri gereklidir; 32768 imzalayıcı ile çarpıldığında 9437184 karma değeri elde edilir. İmza planı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 gerçekte, özyinelemeli bir birleştirme planı daha hızlı olacaktır.

Mevcut araştırmalarla hangi bağlantılar var?

• Basit ETH EthereumKonsensüs kanıtı (yalnızca senkron komitesi için)
• Helios içindeki Simplex SP 1
• Basit BLS 12-381 derlemesi
• Halo 2 BLS toplu imza doğrulaması temelinde

Hangi diğer işler yapılmalı, nasıl tercih yapmalı:

Aslında, Ethereum Konsensüs'ünün geçerlilik kanıtını almak için yıllarca sürebilir. Bu, tek yuva sona erme, Yörünge, İmza Algoritması'nın değiştirilmesi ve güvenlik analizi gibi şeylerin gerçekleştirilmesi için gereken süre ile yaklaşık olarak aynıdır, ve güvenlik analizi Poseidon gibi "radikal" hash fonksiyonlarını kullanmak için yeterli güveni gerektirir. Bu nedenle, en akıllıca yaklaşım, bu diğer sorunları çözmek ve aynı anda STARK'ın dostane olmasını dikkate alarak bu sorunları çözmektir.

Ana değiş tokuşun, Ethereum'un konsensüs katmanında reform yapmak için daha kademeli bir yaklaşım ile daha radikal bir "aynı anda birçok kişiyi değiştir" yaklaşımı arasındaki işlem sırasına göre olması muhtemeldir. EVM'ler için ilerici bir yaklaşım mantıklıdır çünkü geriye dönük uyumlulukla paraziti en aza indirir. Ayrıca, konsensüs katmanı için daha az geriye dönük uyumluluk ve beacon ağının nasıl oluşturulduğuna dair çeşitli ayrıntıların daha "kapsamlı" bir şekilde yeniden düşünülmesi ile SNARK dostluğunu mümkün olan en iyi şekilde optimize etmenin faydaları da vardır.

Diğer yol haritası bölümleriyle nasıl etkileşime geçiyor?

ETH blok zinciri PoS üzerinde uzun vadeli bir yeniden tasarım yaparken, STARK dostu olma önemli bir faktör olmalıdır, özellikle tek yuva finalite, Orbit, imza şeması değişiklikleri ve imza birleştirme.