Bu makale, Ethereum yürütme katmanının geleceği hakkında iddialı bir fikir sunuyor ve iddiaları, konsensüs katmanının beacon chain çabalarıyla karşılaştırılabilir. Ethereum yürütme katmanının verimliliğini önemli ölçüde artırmayı, ana ölçekleme darboğazlarından birini çözmeyi ve yürütme katmanını önemli ölçüde basitleştirmeyi amaçlıyor - aslında, bu basitleştirmenin sağlanmasının tek yolu olabilir.
Temel fikir: Akıllı sözleşmeler yazmak için sanal makine dili olarak EVM'nin yerine RISC-V kullanmak.
Önemli bir açıklama:
Hesap, çapraz sözleşme çağrısı, depolama gibi kavramlar değişmeden kalır. Bu soyut kavramlar iyi çalışır ve geliştiriciler de buna alışmıştır. SLOAD, SSTORE, BALANCE, CALL gibi opcode'lar RISC-V'nin syscalls'ları haline gelecektir.
Bu durumda, akıllı sözleşmeler Rust ile yazılabilir, ancak çoğu geliştiricinin yine de Solidity (veya Vyper) kullanmaya devam etmesini bekliyorum, bu diller RISC-V'yi arka uç olarak uyarlayacak. Bunun nedeni, Rust ile yazılmış akıllı sözleşme kodlarının genellikle daha az estetik olmasıdır, oysa Solidity ve Vyper'ın okunabilirliği daha yüksektir. Potansiyel olarak, geliştirici deneyimindeki (devex) değişiklikler çok küçük olabilir, geliştiriciler bu değişiklikleri neredeyse hiç fark etmeyebilir.
Eski EVM sözleşmeleri çalışmaya devam edecek ve yeni RISC-V sözleşmeleri ile tamamen çift yönlü bir etkileşim gerçekleştirecektir. Birkaç uygulama yöntemi var, bunları sonraki bölümlerde detaylandıracağım.
Bir örnek, temelde RISC-V'e dayanan Nervos CKB VM'dir.
Bunu neden yapmak gerekiyor?
Kısa vadede, Ethereum L1 ölçeklenebilirliğinin ana engeli, yaklaşan EIP'ler aracılığıyla çözülecektir; bunlar arasında blok seviyesi erişim listeleri, gecikmeli yürütme, dağıtılmış tarih depolama ve EIP-4444 bulunmaktadır. Orta vadede, daha fazla sorunu statelesslık ve ZK-EVM'ler ile çözmeyi amaçlıyoruz. Uzun vadede, Ethereum L1 ölçeklenmesinin ana sınırlayıcı faktörü şunlar olacaktır:
Veri erişilebilirliği örnekleme (data availability sampling) ve tarihsel depolama protokolleri (history storage protocols) stabilitesi.
ZK-EVM'yi RISC-V ile değiştirmemin (2) ve (3) içindeki kritik darboğazları çözebileceğini savunacağım.
Aşağıda Succinct ZK-EVM'nin EVM yürütme katmanının farklı bölümlerinin gerektirdiği cycle sayısı tablosu bulunmaktadır:
Bu dört bölümde, en fazla zaman alanlar: deserialize_inputs, initialize_witness_db, state_root_computation ve block_execution.
initialize_witness_db ve state_root_computation, state tree ile ilgilidir.
deserialize_inputs, block ve witness verilerini içsel bir temsile dönüştürme sürecini ifade eder. Bu nedenle, aslında zamanın %50'sinden fazlası witness boyutlarıyla orantılı olarak harcanmaktadır.
Bu bölümler, mevcut keccak 16-ary Merkle Patricia ağacını, kanıtlayıcı dostu hash işlevini kullanan ikili bir ağaçla değiştirerek büyük ölçüde optimize edilebilir. Poseidon kullanırsak, bir dizüstü bilgisayarda saniyede 2 milyon hash kanıtlayabiliriz (keccak için yalnızca yaklaşık 15.000 hash/sn'ye kıyasla). Poseidon'a ek olarak, başka birçok seçenek var. Genel olarak, bu bileşenler için optimizasyon için çok fazla alan var. Ek bir bonus olarak, çiçeklenmeyi kaldırarak tahakkuk_logs_bloom'dan kurtulabiliriz.
Bu durumda geriye block_execution kaldı, şu anda yaklaşık olarak prover döngülerinin yarısını kaplıyor. Toplam prover verimliliğini 100 kat artırmak istiyorsak, EVM'nin prover verimliliğini en az 50 kat artırmamız gerekiyor. Prover döngülerini azaltmak için daha verimli bir EVM uygulaması oluşturmaya çalışabiliriz. Bir diğer yöntem, mevcut ZK-EVM prover'larının EVM'yi RISC-V'ye derleyerek ispatladığını fark etmektir; bu nedenle akıllı sözleşme geliştiricilerinin doğrudan RISC-V VM kullanmasına izin verilebilir.
Bazı veriler, belirli koşullarda bunun %100'den fazla verimlilik artışı sağlayabileceğini göstermektedir:
Pratikte, kalan kanıtlayıcı süresinin bugünün ön derlemeleri tarafından domine edileceğini umuyorum. Birincil VM olarak RISC-V'ye sahipsek, gaz zamanlaması kanıtlama süresini yansıtacaktır, bu nedenle geliştiriciler üzerinde daha pahalı ön derlemeleri kullanmayı bırakmaları için finansal baskı olacaktır. Yine de, verimlilik kazanımları verilerin önerdiği kadar dramatik olmayabilir, ancak önemli olacağına inanmak için iyi nedenler var.
(Bu arada, EVM'nin "diğer kısımlar" ile yaklaşık %50 oranında yer aldığı, normal EVM yürütmesinde de görülmektedir; EVM'yi "aracı" olarak kaldırmanın getireceği iyileşmenin de büyük olacağını sezgisel olarak bekliyoruz.)
Uygulama ayrıntıları
Bu teklifi gerçekleştirmenin çeşitli yolları vardır. İşte bazı olası yöntemler:
En az yıkıcı yöntem: İki tür VM'yi destekleyerek, sözleşmelerin herhangi bir VM ile yazılmasına izin veriyor. Her iki sözleşme de aynı işlevlere erişim sağlayabilir: kalıcı depolama (SLOAD ve SSTORE), ETH bakiyesi tutma, çağrı başlatma ve alma vb. EVM ve RISC-V sözleşmeleri birbirlerini özgürce çağırabilir; RISC-V açısından, EVM sözleşmesini çağırmak özel parametrelerle syscall yürütmek gibidir; mesaj alan EVM sözleşmesi bunu CALL olarak yorumlayacaktır.
Daha radikal bir yol: Mevcut EVM sözleşmelerini RISC-V ile yazılmış EVM yorumlayıcı sözleşmelerini (interpreter contract) çağıracak şekilde dönüştürmek, böylece mevcut EVM kodunu çalıştırmak. Yani, bir EVM sözleşmesinin C kodu varsa ve EVM yorumlayıcısı X adresinde bulunuyorsa, bu sözleşme üst düzey mantıkla değiştirilir: D dışarıdan çağrı parametreleri ile çağrıldığında, (C, D) ile X'i çağırır ve ardından geri dönüş değerini bekler ve iletir. Eğer EVM yorumlayıcısı kendisi bu sözleşmeyi çağırırsa, CALL veya SLOAD/SSTORE işlemlerini gerektiriyorsa, sözleşme ilgili işlemi gerçekleştirir.
Orta yol: İkinci yaklaşımı ele alalım, ancak net bir protokol özelliği oluşturun - temel olarak protokole "sanal makine yorumlayıcısı" kavramını yazmak ve mantığının RISC-V'de yazılmasını istemek. EVM ilk tercüman olacaktır, ancak başka tercümanlar da olabilir (örneğin, Move bir aday olabilir).
İKINCI VE ÜÇÜNCÜ TEKLIFLERIN ÖNEMLI BIR YARARI, YÜRÜTME KATMANI SPESIFIKASYONUNU BÜYÜK ÖLÇÜDE BASITLEŞTIRMELERIDIR - ASLINDA, BU YAKLAŞIM, KENDI KENDINI YOK ETMEYI KALDIRMAK GIBI ARTIMLI BASITLEŞTIRMENIN BILE ZORLUĞU GÖZ ÖNÜNE ALINDIĞINDA, BASITLEŞTIRMEYI BAŞARMANIN TEK PRATIK YOLU OLABILIR. Tinygrad'ın zor ve hızlı bir kuralı vardır: kod asla 10.000 satırı geçmez; Optimize edilmiş bir blok zinciri temel katmanı, daha az olmasa da bu sınırlamaya kolayca uyum sağlayabilmelidir. İşaret zincirinin çabaları, Ethereum'un konsensüs katmanını büyük ölçüde basitleştirmek için büyük umut vaat ediyor. Ancak yönetici katmanın benzer bir basitleştirme elde etmesi için, bu radikal değişiklik tek geçerli yol olabilir.
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 Buterin'in en son önerisi: Ethereum'un uzun vadeli L1 yürütme katmanının EVM ile değiştirilmesi için RISC-V kullanılması
Orijinal yazar: Vitalik Buterin
Orijinal metin çevirisi: Luke, Mars Finans
Bu makale, Ethereum yürütme katmanının geleceği hakkında iddialı bir fikir sunuyor ve iddiaları, konsensüs katmanının beacon chain çabalarıyla karşılaştırılabilir. Ethereum yürütme katmanının verimliliğini önemli ölçüde artırmayı, ana ölçekleme darboğazlarından birini çözmeyi ve yürütme katmanını önemli ölçüde basitleştirmeyi amaçlıyor - aslında, bu basitleştirmenin sağlanmasının tek yolu olabilir.
Temel fikir: Akıllı sözleşmeler yazmak için sanal makine dili olarak EVM'nin yerine RISC-V kullanmak.
Önemli bir açıklama:
Hesap, çapraz sözleşme çağrısı, depolama gibi kavramlar değişmeden kalır. Bu soyut kavramlar iyi çalışır ve geliştiriciler de buna alışmıştır. SLOAD, SSTORE, BALANCE, CALL gibi opcode'lar RISC-V'nin syscalls'ları haline gelecektir.
Bu durumda, akıllı sözleşmeler Rust ile yazılabilir, ancak çoğu geliştiricinin yine de Solidity (veya Vyper) kullanmaya devam etmesini bekliyorum, bu diller RISC-V'yi arka uç olarak uyarlayacak. Bunun nedeni, Rust ile yazılmış akıllı sözleşme kodlarının genellikle daha az estetik olmasıdır, oysa Solidity ve Vyper'ın okunabilirliği daha yüksektir. Potansiyel olarak, geliştirici deneyimindeki (devex) değişiklikler çok küçük olabilir, geliştiriciler bu değişiklikleri neredeyse hiç fark etmeyebilir.
Eski EVM sözleşmeleri çalışmaya devam edecek ve yeni RISC-V sözleşmeleri ile tamamen çift yönlü bir etkileşim gerçekleştirecektir. Birkaç uygulama yöntemi var, bunları sonraki bölümlerde detaylandıracağım.
Bir örnek, temelde RISC-V'e dayanan Nervos CKB VM'dir.
Bunu neden yapmak gerekiyor?
Kısa vadede, Ethereum L1 ölçeklenebilirliğinin ana engeli, yaklaşan EIP'ler aracılığıyla çözülecektir; bunlar arasında blok seviyesi erişim listeleri, gecikmeli yürütme, dağıtılmış tarih depolama ve EIP-4444 bulunmaktadır. Orta vadede, daha fazla sorunu statelesslık ve ZK-EVM'ler ile çözmeyi amaçlıyoruz. Uzun vadede, Ethereum L1 ölçeklenmesinin ana sınırlayıcı faktörü şunlar olacaktır:
Veri erişilebilirliği örnekleme (data availability sampling) ve tarihsel depolama protokolleri (history storage protocols) stabilitesi.
rekabetçi piyasanın arzusunu blok üretimini sürdürmek.
ZK-EVM'nin kanıtlama yeteneği.
ZK-EVM'yi RISC-V ile değiştirmemin (2) ve (3) içindeki kritik darboğazları çözebileceğini savunacağım.
Aşağıda Succinct ZK-EVM'nin EVM yürütme katmanının farklı bölümlerinin gerektirdiği cycle sayısı tablosu bulunmaktadır:
Bu dört bölümde, en fazla zaman alanlar: deserialize_inputs, initialize_witness_db, state_root_computation ve block_execution.
initialize_witness_db ve state_root_computation, state tree ile ilgilidir.
deserialize_inputs, block ve witness verilerini içsel bir temsile dönüştürme sürecini ifade eder. Bu nedenle, aslında zamanın %50'sinden fazlası witness boyutlarıyla orantılı olarak harcanmaktadır.
Bu bölümler, mevcut keccak 16-ary Merkle Patricia ağacını, kanıtlayıcı dostu hash işlevini kullanan ikili bir ağaçla değiştirerek büyük ölçüde optimize edilebilir. Poseidon kullanırsak, bir dizüstü bilgisayarda saniyede 2 milyon hash kanıtlayabiliriz (keccak için yalnızca yaklaşık 15.000 hash/sn'ye kıyasla). Poseidon'a ek olarak, başka birçok seçenek var. Genel olarak, bu bileşenler için optimizasyon için çok fazla alan var. Ek bir bonus olarak, çiçeklenmeyi kaldırarak tahakkuk_logs_bloom'dan kurtulabiliriz.
Bu durumda geriye block_execution kaldı, şu anda yaklaşık olarak prover döngülerinin yarısını kaplıyor. Toplam prover verimliliğini 100 kat artırmak istiyorsak, EVM'nin prover verimliliğini en az 50 kat artırmamız gerekiyor. Prover döngülerini azaltmak için daha verimli bir EVM uygulaması oluşturmaya çalışabiliriz. Bir diğer yöntem, mevcut ZK-EVM prover'larının EVM'yi RISC-V'ye derleyerek ispatladığını fark etmektir; bu nedenle akıllı sözleşme geliştiricilerinin doğrudan RISC-V VM kullanmasına izin verilebilir.
Bazı veriler, belirli koşullarda bunun %100'den fazla verimlilik artışı sağlayabileceğini göstermektedir:
Pratikte, kalan kanıtlayıcı süresinin bugünün ön derlemeleri tarafından domine edileceğini umuyorum. Birincil VM olarak RISC-V'ye sahipsek, gaz zamanlaması kanıtlama süresini yansıtacaktır, bu nedenle geliştiriciler üzerinde daha pahalı ön derlemeleri kullanmayı bırakmaları için finansal baskı olacaktır. Yine de, verimlilik kazanımları verilerin önerdiği kadar dramatik olmayabilir, ancak önemli olacağına inanmak için iyi nedenler var.
(Bu arada, EVM'nin "diğer kısımlar" ile yaklaşık %50 oranında yer aldığı, normal EVM yürütmesinde de görülmektedir; EVM'yi "aracı" olarak kaldırmanın getireceği iyileşmenin de büyük olacağını sezgisel olarak bekliyoruz.)
Uygulama ayrıntıları
Bu teklifi gerçekleştirmenin çeşitli yolları vardır. İşte bazı olası yöntemler:
En az yıkıcı yöntem: İki tür VM'yi destekleyerek, sözleşmelerin herhangi bir VM ile yazılmasına izin veriyor. Her iki sözleşme de aynı işlevlere erişim sağlayabilir: kalıcı depolama (SLOAD ve SSTORE), ETH bakiyesi tutma, çağrı başlatma ve alma vb. EVM ve RISC-V sözleşmeleri birbirlerini özgürce çağırabilir; RISC-V açısından, EVM sözleşmesini çağırmak özel parametrelerle syscall yürütmek gibidir; mesaj alan EVM sözleşmesi bunu CALL olarak yorumlayacaktır.
Daha radikal bir yol: Mevcut EVM sözleşmelerini RISC-V ile yazılmış EVM yorumlayıcı sözleşmelerini (interpreter contract) çağıracak şekilde dönüştürmek, böylece mevcut EVM kodunu çalıştırmak. Yani, bir EVM sözleşmesinin C kodu varsa ve EVM yorumlayıcısı X adresinde bulunuyorsa, bu sözleşme üst düzey mantıkla değiştirilir: D dışarıdan çağrı parametreleri ile çağrıldığında, (C, D) ile X'i çağırır ve ardından geri dönüş değerini bekler ve iletir. Eğer EVM yorumlayıcısı kendisi bu sözleşmeyi çağırırsa, CALL veya SLOAD/SSTORE işlemlerini gerektiriyorsa, sözleşme ilgili işlemi gerçekleştirir.
Orta yol: İkinci yaklaşımı ele alalım, ancak net bir protokol özelliği oluşturun - temel olarak protokole "sanal makine yorumlayıcısı" kavramını yazmak ve mantığının RISC-V'de yazılmasını istemek. EVM ilk tercüman olacaktır, ancak başka tercümanlar da olabilir (örneğin, Move bir aday olabilir).
İKINCI VE ÜÇÜNCÜ TEKLIFLERIN ÖNEMLI BIR YARARI, YÜRÜTME KATMANI SPESIFIKASYONUNU BÜYÜK ÖLÇÜDE BASITLEŞTIRMELERIDIR - ASLINDA, BU YAKLAŞIM, KENDI KENDINI YOK ETMEYI KALDIRMAK GIBI ARTIMLI BASITLEŞTIRMENIN BILE ZORLUĞU GÖZ ÖNÜNE ALINDIĞINDA, BASITLEŞTIRMEYI BAŞARMANIN TEK PRATIK YOLU OLABILIR. Tinygrad'ın zor ve hızlı bir kuralı vardır: kod asla 10.000 satırı geçmez; Optimize edilmiş bir blok zinciri temel katmanı, daha az olmasa da bu sınırlamaya kolayca uyum sağlayabilmelidir. İşaret zincirinin çabaları, Ethereum'un konsensüs katmanını büyük ölçüde basitleştirmek için büyük umut vaat ediyor. Ancak yönetici katmanın benzer bir basitleştirme elde etmesi için, bu radikal değişiklik tek geçerli yol olabilir.