Vitalik'in uzun vadeli L1 yönetici katmanı önerisinin tam metni: EVM'yi RISC-V ile değiştirme
Kaynak: Vitalik Buterin
Derleme: KarenZ, Öngörü Haberleri
20 Nisan'da Vitalik Buterin, Ethereum'un uzun vadeli L1 yürütme katmanı için Ethereum Magicians platformunda önemli bir teklif sundu. Ethereum'un yürütme katmanının operasyonel verimliliğini temelden artırmayı, mevcut büyük ölçeklendirme darboğazlarından birini aşmayı ve yürütme katmanının basitliğini büyük ölçüde basitleştirmeyi amaçlayan, akıllı sözleşmeler yazmak için sanal bir makine dili olarak mevcut EVM'nin (Ethereum Sanal Makinesi) RISC-V mimarisiyle değiştirilmesini önerdi.
Foresight News, okuyucuların bu teknik vizyonu anlamalarına yardımcı olmak için teklifin tam metnini derledi. Aşağıdakiler, orijinal teklifin bir derlemesidir:
Bu makale, Ethereum'un yürütme katmanının geleceği hakkında, konsensüs katmanının Beam Chain girişimlerinden daha az iddialı olmayan radikal bir fikir sunuyor. Teklif, Ethereum'un yürütme katmanının verimliliğini önemli ölçüde artırmayı, en büyük ölçeklendirme darboğazlarından birini ele almayı ve yürütme katmanını önemli ölçüde basitleştirmeyi amaçlıyor - aslında, bunu başarmanın tek yolu bu olabilir.
Temel fikir: EVM'yi akıllı sözleşmeler için sanal bir makine dili olarak RISC-V ile değiştirin.
Önemli Notlar:
-
Hesap sistemi, sözleşmeler arası arama, depolama vb. kavramlar tamamen korunacaktır. Bu soyut tasarımlar iyi çalışır ve geliştiriciler bunları kullanmaya alışkındır. SLOAD, SSTORE, BALANCE, CALL VB. GIBI IŞLEM KODLARI RISC-V SISTEM ÇAĞRILARINA DÖNÜŞTÜRÜLÜR.
-
Bu modda, akıllı sözleşmeler Rust'ta yazılabilir, ancak çoğu geliştiricinin, yeni arka uç olarak RISC-V'ye uyum sağlayacak olan Solidity'de (veya Vyper'da) sözleşmeler yazmaya devam etmesini bekliyorum. Çünkü Rust ile yazılan akıllı sözleşmeler aslında daha az okunabilirken, Solidity ve Vyper daha net ve okunması daha kolaydır. Geliştirme deneyimi çok az etkilenebilir ve geliştiriciler değişikliği fark etmeyebilir bile.
-
Eski EVM sözleşmesi çalışmaya devam edecek ve yeni RISC-V sözleşmesi ile tamamen çift yönlü olarak uyumludur. Bunu yapmanın birkaç yolu vardır ve bu makalenin ilerleyen kısımlarında daha ayrıntılı olarak ele alınacaktır.
Nervos CKB VM bir emsal oluşturmuştur ve esasen bir RISC-V uygulamasıdır.
Neden?
Kısa vadede, yaklaşan EIP'ler (örneğin, blok düzeyinde erişim listeleri, ertelenmiş yürütme, dağıtılmış geçmiş depolaması ve EIP-4444) Ethereum L1'in büyük ölçeklendirme darboğazlarını ele alacaktır. Vatansızlık ve ZK-EVM ile orta vadede daha fazla sorun çözülecektir. Uzun vadede, Ethereum L1 ölçeklendirmesi için ana sınırlayıcı faktörler şunlar olacaktır:
-
Veri kullanılabilirliğinin, örneklemenin ve geçmiş depolama protokollerinin kararlılığı
-
Blok üretim pazarında rekabet talebini korumak
-
ZK-EVM'nin Kanıtı
ZK-EVM'yi RISC-V ile değiştirmenin (2) ve (3)'teki temel darboğazları çözebileceğini iddia edeceğim.
Aşağıdaki tablo, Kısa ve Özlü ZK-EVM Proof EVM yürütme katmanının her adımı için gereken döngü sayısını göstermektedir:
Diyagram açıklaması: Zaman alan dört ana segment deserialize_inputs, initialize_witness_db, state_root_computation ve block_execution
initialize_witness_db ve state_root_computation, durum ağaçlarıyla ilgilidir ve deserialize_inputs, blok ve tanık verilerini dahili temsillere dönüştürme sürecini içerir - bunların %50'sinden fazlası aslında tanık verilerinin boyutuyla orantılıdır.
Bu bölümler, mevcut keccak 16-ary Merkle patricia ağacını, kanıtlanması kolay bir hash fonksiyonu 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 yaklaşık 15.000 hash/sn ile karşılaştırıldığında). Poseidon'a ek olarak, başka birçok seçenek var. Genel olarak, bu bileşenler için optimizasyon için çok fazla alan vardır. Ek olarak, çiçeklenmeyi kaldırarak accrue_logs_bloom ortadan kaldırabiliriz.
Kalan block_execution, mevcut kanıtlayıcı döngülerinin yaklaşık yarısını oluşturur. Genel kanıt verimliliğinde 100 katlık bir artış elde etmek için en az 50 katlık bir EVM kanıt verimliliği gereklidir. Çözümlerden biri, EVM için daha verimli bir kanıt uygulaması oluşturmak, diğeri ise mevcut ZK-EVM kanıtlayıcısının kanıt için EVM'yi RISC-V'ye derlediğini ve akıllı sözleşme geliştiricilerine RISC-V sanal makinesine doğrudan erişim sağladığını fark etmektir.
Bazı veriler, belirli durumlarda 100 kattan fazla verimlilik artışlarının meydana gelebileceğini göstermektedir:
Pratikte, kalan kanıtlayıcı süresi çoğunlukla geçerli ön derleme işlemi tarafından işgal edilebilir. Birincil VM olarak RISC-V ile, gaz programı gerçek kanıt süresini yansıtacak ve ekonomik baskı, geliştiricileri yüksek maliyetli ön derleme kullanımını azaltmaya itecektir. O zaman bile, kazanımlar o kadar önemli olmayacak, ancak önemli olacağına inanmak için iyi bir nedenimiz var.
(Normal EVM yürütmesinde "EVM işlemleri" ve "diğer işlemler" için geçen sürenin de 50/50'ye yakın olduğunu belirtmekte fayda var, bu nedenle sezgisel olarak EVM'yi "ara katman" olarak kaldırmanın eşit derecede önemli bir kazanç sağlayacağını varsayıyoruz.)
Uygulama ayrıntıları
Bu teklifi uygulamanın birkaç yolu vardır. En az kesintiye neden olan çözüm, her iki sanal makineyi de desteklemek ve sözleşmenin bunlardan birine yazılmasına izin vermektir. Her iki sözleşme türünün de aynı özelliklere erişimi vardır: kalıcı depolama (SLOAD/SSTORE), ETH bakiyelerini tutma, arama başlatma/alma ve daha fazlası. EVM ve RISC-V sözleşmeleri birbirine çağrılabilir - RISC-V perspektifinden bakıldığında, EVM sözleşmesini çağırmak, özel parametrelerle bir sistem çağrısı yürütmeye eşdeğerdir; Mesajı alan EVM sözleşmesi, bunu bir ÇAĞRI olarak yorumlayacaktır.
Protokol perspektifinden daha radikal bir yaklaşım, mevcut bir EVM sözleşmesini, mevcut EVM kodunu çalıştırmak için RISC-V'de yazılmış bir EVM tercüman sözleşmesine yapılan bir çağrıya dönüştürmektir. Diğer bir deyişle, bir EVM sözleşmesinin C kodu varsa ve EVM yorumlayıcısı X adresindeyse, sözleşme, dışarıdan bir çağrı argümanı D ile çağrıldığında, X'i çağıran ve (C, D) ileten üst düzey mantıkla değiştirilecektir, ardından dönüş değerini bekler ve iletir. EVM tercümanının kendisi sözleşmeyi çağırır ve CALL veya SLOAD/SSTORE'u çalıştırmayı isterse, sözleşme bu işlemleri gerçekleştirir.
Uzlaşma ikinci seçenektir, ancak mantığının RISC-V'de yazılmasını gerektiren bir protokol aracılığıyla "sanal makine yorumlayıcısı" kavramına açık destek verilir. EVM, gelecekte diğer diller için destek sağlayan ilk örnek olacak (Move bir aday olabilir).
İkinci ve üçüncü seçeneklerin temel avantajı, yürütme katmanı spesifikasyonunu büyük ölçüde basitleştirmeleridir. KENDI KENDINI YOK ETME GIBI ARTIMLI BASITLEŞTIRMELERI BILE KALDIRMANIN ZORLUĞU GÖZ ÖNÜNE ALINDIĞINDA, BU DÜŞÜNCE ÇIZGISI BASITLEŞTIRMENIN TEK GEÇERLI YOLU OLABILIR. Tinygrad, "10.000 satırdan fazla kod yazmama" katı kuralına bağlı kalır ve altta yatan en uygun blok zinciri bu sınırı kolayca karşılayabilmeli ve daha da kolaylaştırabilmelidir. Beam Chain girişimi, Ethereum'un konsensüs katmanını önemli ölçüde basitleştirmeyi vaat ediyor ve böylesine radikal bir değişiklik, yürütme katmanında benzer bir destek elde etmenin tek yolu olabilir.