Bu yazıda, Ethereum'un yürütme katmanının geleceği hakkında, konsensüs katmanının Beam Chain planıyla karşılaştırılabilecek kadar büyük bir radikal fikir önereceğim. Bu plan, Ethereum'un yürütme katmanının verimliliğini önemli ölçüde artırmayı, ana ölçekleme darboğazlarından birini çözmeyi ve aynı zamanda yürütme katmanının karmaşıklığını büyük ölçüde basitleştirmeyi amaçlıyor - aslında, bu basitleştirmenin sağlanmasının tek yolu bu olabilir.
Bu makalenin temel görüşü, akıllı sözleşmeler için sanal makine dili olarak RISC-V'nin EVM'nin yerini almasıdır.
Önemli Açıklama:
Hesap, çapraz sözleşme çağrısı, depolama gibi kavramlar tamamen korunacaktır. Bu soyut mekanizmalar iyi çalışıyor ve geliştiriciler bunları kullanmaya alışkın. SLOAD, SSTORE, BALANCE, CALL gibi işlem kodları RISC-V sistem çağrıları haline gelecektir.
Geliştiriciler hâlâ Solidity veya Vyper'ı seçebilir. Teorik olarak akıllı sözleşmeler Rust ile yazılabilir, ancak çoğu geliştiricinin Solidity (veya Vyper) kullanmaya devam etmesi bekleniyor; bu diller, RISC-V'i arka uç derleme hedefi olarak kullanarak uyum sağlayacak — bunun nedeni, Rust ile yazılan akıllı sözleşmelerin daha kötü okunabilirliğe sahip olması, oysa Solidity ve Vyper daha kolay anlaşılmaktadır. Geliştirme deneyimi neredeyse değişmeyecek, geliştiriciler fark edilmeyen bir farklılık hissedebilir.
Yeni ve eski sözleşmeler çift yönlü etkileşim sağlayacak. Geleneksel EVM sözleşmeleri çalışmaya devam edecek ve yeni RISC-V sözleşmeleri ile tamamen etkileşimde bulunabilecektir. Uygulama yöntemi daha sonra ayrıntılı olarak açıklanacaktır.
Daha önceki örnekler mevcut: Nervos CKB VM esasen RISC-V tabanlı bir uygulamadır.
Neden bu tür bir değişime ihtiyaç var?
Kısa vadede, Ethereum Layer 1 genişlemesinin ana darboğazı, önümüzdeki EIP'ler (blok düzeyinde erişim listesi, gecikmeli yürütme, dağıtılmış tarih depolama ve EIP-4444 gibi) ile çözülecektir; orta vadede, durum dışılık ve ZK-EVM ile daha fazla sorunu çözmeyi hedefleyeceğiz; ancak uzun vadede, Ethereum Layer 1 genişlemesini kısıtlayan ana faktör şunlar olacaktır:
Veri kullanılabilirliği örnekleme ve tarihsel depolama protokolünün istikrarı;
Blok üretim pazarı rekabetçiliğini sürdürme ihtiyacı;
ZK-EVM'nin kanıtlama yeteneği.
Bu makalede, RISC-V'nin ZK-EVM'nin yerini almasının 2. ve 3. noktalardaki kritik engelleri aşabileceği savunulacaktır.
Aşağıda, Succinct ZK-EVM'nin EVM yürütme katmanının her aşaması için gereken döngü sayısının istatistik tablosu bulunmaktadır:
Dört ana zaman alanı aşaması şunlardır: "deserialize_inputs" (veri tersine serileştirme), "initialize_witness_db" (şahit veritabanı başlatma), "state_root_computation" (durum kökü hesaplama) ve "block_execution" (blok yürütme).
"Veri tabanı başlatma" ve "durum kökü hesaplama" durum ağacı ile ilgilidir, "veri tersine serileştirme" ise blok ve başvuru verilerini iç temsil haline dönüştürme sürecini ifade eder. Bu nedenle, aslında zamanın %50'sinden fazlası başvuru verilerinin boyutu ile ilgilidir.
Mevcut "keccak 16-ary Merkle patricia tree" (keccak onaltılı Merkle Patricia ağacı) yerine kanıt dostu bir hash fonksiyonu kullanan "binary tree" (ikili ağaç) kullanarak, bu aşamalar büyük ölçüde optimize edilebilir. "Poseidon" kullandığımızda, dizüstü bilgisayarımızda saniyede 2 milyon hash kanıtlayabiliriz (karşılaştırıldığında, keccak saniyede yaklaşık 15,000 hash). "Poseidon" dışında birçok başka seçenek de mevcuttur. Genel olarak, bu aşamaların sürelerini önemli ölçüde azaltma fırsatı vardır. Ayrıca, "accrue_logs_bloom" u kaldırarak süreci daha da basitleştirebiliriz.
Şimdi geriye sadece "blok yürütme" kaldı, bu da mevcut kanıt döngüsünün yaklaşık yarısını kapsıyor. Genel kanıt verimliliğini 100 kat artırmak istiyorsak, EVM kanıt verimliliğini en az 50 kat artırmalıyız. Mevcut iki yol var: birincisi, kanıt döngüsünü azaltmak için daha verimli bir EVM uygulaması yaratmaya çalışmak; ikincisi, geliştiricilerin ZK-EVM altyapısında kullanılan RISC-V sanal makinesini doğrudan kullanmalarını sağlamak.
Bazı veriler, belirli senaryolar altında verimliliğin 100 katın üzerinde artabileceğini gösteriyor:
Pratikte, kalan kanıt süresi esas olarak ön derleme sözleşmelerine (precompiles) harcanacaktır. RISC-V ana sanal makine olarak ayarlandığında, gaz ücret mekanizması gerçek kanıt süresini yansıtacak, ekonomik baskı geliştiricileri yüksek maliyetli ön derlemeleri azaltmaya teşvik edecektir. Gerçek kazançlar teorik değerin altında olabilir, ancak beklentiler yine de çok belirgin olacaktır.
Dikkate değer bir nokta, normal EVM yürütmelerinde de benzer "EVM" ile "diğer aşamalar" arasında %50/%50 zaman dağılımının bulunmasıdır. Görünüşe göre, EVM'yi "ara katman" olarak kaldırmanın benzer bir verimlilik artışı sağlayabileceğini düşünüyoruz.
Uygulama Yöntemi
Yukarıda belirtilen öneriyi gerçekleştirmek için çeşitli yöntemler vardır.
En az yıkıcı yöntem, iki sanal makineyi desteklemektir; bu, sözleşmelerin herhangi bir sanal makineyi seçerek yazılmasına izin verir. İki tür sözleşme de aynı işlevlere erişebilir: kalıcı depolama (SLOAD/SSTORE), ETH bakiye yönetimi, çağrı başlatma ve alma vb. EVM ve RISC-V sözleşmeleri serbestçe birbirlerini çağırabilir: RISC-V perspektifinden EVM sözleşmesine yapılan çağrı, özel parametreler içeren bir sistem çağrısı (syscall) olarak kabul edilecek, çağrı alan EVM sözleşmesi ise bunu normal CALL talimatı olarak yorumlayacaktır.
Daha radikal bir yaklaşım, mevcut EVM sözleşmelerini RISC-V ile yazılmış EVM yorumlayıcı sözleşmelerini çağıracak şekilde dönüştürmektir. Özellikle, belirli bir EVM sözleşmesinin C kodunu içerdiğini ve EVM yorumlayıcısının X adresinde bulunduğunu varsayalım, o zaman bu sözleşme üst düzey mantık ile değiştirilir: D çağrı parametresiyle dışarıdan bir çağrı yapıldığında, bu mantık X'e (C, D) isteği gönderir, dönen değeri bekler ve iletir. Eğer EVM yorumlayıcısı kendisi CALL, SLOAD veya SSTORE gibi işlemleri gerçekleştirmek için bir sözleşmeyi çağırması gerekiyorsa, sözleşme doğrudan yanıt verecektir.
Uzlaşma planı, ikinci planın temelinde, protokol katmanında "sanallaştırma makinesi yorumlayıcısı" kavramını açıkça desteklemeyi gerektirir - yani yorumlayıcı mantığının RISC-V ile yazılması zorunludur. EVM, ilk resmi yorumlayıcı olarak görev yapacak, gelecekte diğer türlerin (örneğin Move dili yorumlayıcısı) dahil edilmesi mümkün olabilir.
İkinci ve üçüncü seçeneklerin temel avantajı, yürütme katmanı standartlarını büyük ölçüde basitleştirmekte yatmaktadır. SELFDESTRUCT gibi kademeli basitleştirmelerin bile zor olduğu göz önüne alındığında, bu tür değişiklikler basitleştirmenin tek gerçekçi yolu olabilir. Tinygrad projesi, kod miktarının asla 10.000 satırı geçmemesini kesin bir şekilde belirler; ideal bir blok zinciri temel katmanı daha aşırı bir basitlik peşinde koşmalıdır. Beam Chain, Ethereum konsensüs katmanının basitleştirilmesi için bir yön belirlerken, yürütme katmanının benzer bir atılım gerçekleştirebilmesi için belki de yalnızca bu tür köklü değişiklikler gerekecektir.
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 radikal yeni makalesi: İcra katmanında genişleme "yıkmadan inşa edilemez", EVM'nin geleceği mutlaka yenilenmelidir.
Bu yazı: Ethereum'un kurucu ortağı Vitalik'ten.
Derleme｜Odaily Yıldız Gazetesi（@OdailyChina）
Çevirmen｜Azuma（@azuma_eth）
Bu yazıda, Ethereum'un yürütme katmanının geleceği hakkında, konsensüs katmanının Beam Chain planıyla karşılaştırılabilecek kadar büyük bir radikal fikir önereceğim. Bu plan, Ethereum'un yürütme katmanının verimliliğini önemli ölçüde artırmayı, ana ölçekleme darboğazlarından birini çözmeyi ve aynı zamanda yürütme katmanının karmaşıklığını büyük ölçüde basitleştirmeyi amaçlıyor - aslında, bu basitleştirmenin sağlanmasının tek yolu bu olabilir.
Bu makalenin temel görüşü, akıllı sözleşmeler için sanal makine dili olarak RISC-V'nin EVM'nin yerini almasıdır.
Önemli Açıklama:
Neden bu tür bir değişime ihtiyaç var?
Kısa vadede, Ethereum Layer 1 genişlemesinin ana darboğazı, önümüzdeki EIP'ler (blok düzeyinde erişim listesi, gecikmeli yürütme, dağıtılmış tarih depolama ve EIP-4444 gibi) ile çözülecektir; orta vadede, durum dışılık ve ZK-EVM ile daha fazla sorunu çözmeyi hedefleyeceğiz; ancak uzun vadede, Ethereum Layer 1 genişlemesini kısıtlayan ana faktör şunlar olacaktır:
Bu makalede, RISC-V'nin ZK-EVM'nin yerini almasının 2. ve 3. noktalardaki kritik engelleri aşabileceği savunulacaktır.
Aşağıda, Succinct ZK-EVM'nin EVM yürütme katmanının her aşaması için gereken döngü sayısının istatistik tablosu bulunmaktadır:
Dört ana zaman alanı aşaması şunlardır: "deserialize_inputs" (veri tersine serileştirme), "initialize_witness_db" (şahit veritabanı başlatma), "state_root_computation" (durum kökü hesaplama) ve "block_execution" (blok yürütme).
"Veri tabanı başlatma" ve "durum kökü hesaplama" durum ağacı ile ilgilidir, "veri tersine serileştirme" ise blok ve başvuru verilerini iç temsil haline dönüştürme sürecini ifade eder. Bu nedenle, aslında zamanın %50'sinden fazlası başvuru verilerinin boyutu ile ilgilidir.
Mevcut "keccak 16-ary Merkle patricia tree" (keccak onaltılı Merkle Patricia ağacı) yerine kanıt dostu bir hash fonksiyonu kullanan "binary tree" (ikili ağaç) kullanarak, bu aşamalar büyük ölçüde optimize edilebilir. "Poseidon" kullandığımızda, dizüstü bilgisayarımızda saniyede 2 milyon hash kanıtlayabiliriz (karşılaştırıldığında, keccak saniyede yaklaşık 15,000 hash). "Poseidon" dışında birçok başka seçenek de mevcuttur. Genel olarak, bu aşamaların sürelerini önemli ölçüde azaltma fırsatı vardır. Ayrıca, "accrue_logs_bloom" u kaldırarak süreci daha da basitleştirebiliriz.
Şimdi geriye sadece "blok yürütme" kaldı, bu da mevcut kanıt döngüsünün yaklaşık yarısını kapsıyor. Genel kanıt verimliliğini 100 kat artırmak istiyorsak, EVM kanıt verimliliğini en az 50 kat artırmalıyız. Mevcut iki yol var: birincisi, kanıt döngüsünü azaltmak için daha verimli bir EVM uygulaması yaratmaya çalışmak; ikincisi, geliştiricilerin ZK-EVM altyapısında kullanılan RISC-V sanal makinesini doğrudan kullanmalarını sağlamak.
Bazı veriler, belirli senaryolar altında verimliliğin 100 katın üzerinde artabileceğini gösteriyor:
Pratikte, kalan kanıt süresi esas olarak ön derleme sözleşmelerine (precompiles) harcanacaktır. RISC-V ana sanal makine olarak ayarlandığında, gaz ücret mekanizması gerçek kanıt süresini yansıtacak, ekonomik baskı geliştiricileri yüksek maliyetli ön derlemeleri azaltmaya teşvik edecektir. Gerçek kazançlar teorik değerin altında olabilir, ancak beklentiler yine de çok belirgin olacaktır.
Dikkate değer bir nokta, normal EVM yürütmelerinde de benzer "EVM" ile "diğer aşamalar" arasında %50/%50 zaman dağılımının bulunmasıdır. Görünüşe göre, EVM'yi "ara katman" olarak kaldırmanın benzer bir verimlilik artışı sağlayabileceğini düşünüyoruz.
Uygulama Yöntemi
Yukarıda belirtilen öneriyi gerçekleştirmek için çeşitli yöntemler vardır.
En az yıkıcı yöntem, iki sanal makineyi desteklemektir; bu, sözleşmelerin herhangi bir sanal makineyi seçerek yazılmasına izin verir. İki tür sözleşme de aynı işlevlere erişebilir: kalıcı depolama (SLOAD/SSTORE), ETH bakiye yönetimi, çağrı başlatma ve alma vb. EVM ve RISC-V sözleşmeleri serbestçe birbirlerini çağırabilir: RISC-V perspektifinden EVM sözleşmesine yapılan çağrı, özel parametreler içeren bir sistem çağrısı (syscall) olarak kabul edilecek, çağrı alan EVM sözleşmesi ise bunu normal CALL talimatı olarak yorumlayacaktır.
Daha radikal bir yaklaşım, mevcut EVM sözleşmelerini RISC-V ile yazılmış EVM yorumlayıcı sözleşmelerini çağıracak şekilde dönüştürmektir. Özellikle, belirli bir EVM sözleşmesinin C kodunu içerdiğini ve EVM yorumlayıcısının X adresinde bulunduğunu varsayalım, o zaman bu sözleşme üst düzey mantık ile değiştirilir: D çağrı parametresiyle dışarıdan bir çağrı yapıldığında, bu mantık X'e (C, D) isteği gönderir, dönen değeri bekler ve iletir. Eğer EVM yorumlayıcısı kendisi CALL, SLOAD veya SSTORE gibi işlemleri gerçekleştirmek için bir sözleşmeyi çağırması gerekiyorsa, sözleşme doğrudan yanıt verecektir.
Uzlaşma planı, ikinci planın temelinde, protokol katmanında "sanallaştırma makinesi yorumlayıcısı" kavramını açıkça desteklemeyi gerektirir - yani yorumlayıcı mantığının RISC-V ile yazılması zorunludur. EVM, ilk resmi yorumlayıcı olarak görev yapacak, gelecekte diğer türlerin (örneğin Move dili yorumlayıcısı) dahil edilmesi mümkün olabilir.
İkinci ve üçüncü seçeneklerin temel avantajı, yürütme katmanı standartlarını büyük ölçüde basitleştirmekte yatmaktadır. SELFDESTRUCT gibi kademeli basitleştirmelerin bile zor olduğu göz önüne alındığında, bu tür değişiklikler basitleştirmenin tek gerçekçi yolu olabilir. Tinygrad projesi, kod miktarının asla 10.000 satırı geçmemesini kesin bir şekilde belirler; ideal bir blok zinciri temel katmanı daha aşırı bir basitlik peşinde koşmalıdır. Beam Chain, Ethereum konsensüs katmanının basitleştirilmesi için bir yön belirlerken, yürütme katmanının benzer bir atılım gerçekleştirebilmesi için belki de yalnızca bu tür köklü değişiklikler gerekecektir.