Vitalik'in uzun vadeli L1 yürütme katmanı önerisi: EVM'yi RISC-V ile değiştirin
Orijinal başlık: Uzun vadeli L1 yürütme katmanı önerisi: EVM'yi RISC-V ile değiştirin
Orijinal kaynak: Vitalik Buterin
Orijinal çeviri: KarenZ, Foresight News
Vitalik Buterin, 20 Nisan'da Ethereum Magicians platformunda Ethereum'un uzun vadeli L1 yürütme katmanı hakkında önemli bir öneri sundu. Akıllı sözleşmelerin yazılmasında sanal makine dili olarak mevcut EVM'nin (Ethereum Sanal Makinesi) yerini alacak RISC-V mimarisinin kullanılmasını önererek, Ethereum yürütme katmanının operasyonel verimliliğini temelden iyileştirmeyi, mevcut büyük genişleme darboğazlarından birini aşmayı ve yürütme katmanının basitliğini büyük ölçüde basitleştirmeyi amaçladı.
Foresight News, okuyucuların bu teknik konsepti anlamalarına yardımcı olmak için teklifin tam metnini derledi. Aşağıda orijinal teklifin bir derlemesi yer almaktadır:
Bu makale, Ethereum'un yürütme katmanının geleceği için, mutabakat katmanı için Beam Chain planından daha az iddialı olmayan radikal bir fikir önermektedir. Öneri, Ethereum'un yürütme katmanının verimliliğini önemli ölçüde artırmayı, ana ölçekleme darboğazlarından birini ele almayı ve yürütme katmanını önemli ölçüde basitleştirmeyi amaçlıyor; aslında bu hedefe ulaşmanın tek yolu bu olabilir.
Temel kavram: Akıllı sözleşmeleri yazmak için sanal makine dili olarak EVM'nin yerine RISC-V'yi kullanmak.
Önemli Not:
· Hesap sistemi, sözleşmeler arası çağrılar ve depolama gibi kavramlar tamamen korunacaktır. Bu soyutlamalar iyi çalışıyor ve geliştiriciler bunlara alışkın. SLOAD, SSTORE, BALANCE, CALL vb. opkodlar RISC-V sistem çağrılarına dönüştürülecektir.
· Bu modda akıllı sözleşmeler Rust'ta yazılabilir, ancak çoğu geliştiricinin sözleşmeleri Solidity'de (veya Vyper'da) yazmaya devam edeceğini ve bunların yeni arka uç olarak RISC-V'ye uyarlanacağını düşünüyorum. Çünkü Rust'ta yazılan akıllı sözleşmeler aslında daha az okunabilirken, Solidity ve Vyper'da yazılanlar daha anlaşılır ve okunması daha kolaydır. Geliştirme deneyimi neredeyse hiç etkilenmeyebilir ve geliştiriciler değişikliği fark etmeyebilir bile.
· Eski EVM sözleşmeleri çalışmaya devam edecek ve yeni RISC-V sözleşmeleriyle tam çift yönlü uyumluluğa sahip olacak. Bunu başarmanın çeşitli yolları vardır ve bunlar makalenin ilerleyen kısımlarında ayrıntılı olarak ele alınacaktır.
Nervos CKB VM bir emsal teşkil etmiştir ve esasen bir RISC-V uygulamasıdır.
Bunu neden yapıyorsunuz?
Kısa vadede, yaklaşan EIP'ler (blok düzeyinde erişim listeleri, gecikmeli yürütme, dağıtılmış geçmiş depolama ve EIP-4444 gibi) Ethereum L1'in ana genişleme darboğazlarını çözebilir. Orta vadede vatansızlık ve ZK-EVM aracılığıyla daha fazla soruna çözüm bulunacak. Uzun vadede, Ethereum L1 genişlemesinin önündeki temel sınırlayıcı faktörler şunlar olacaktır:
1. Veri kullanılabilirliği örneklemesinin ve geçmiş depolama protokollerinin kararlılığı
2. Rekabetçi bir blok üretim pazarının sürdürülmesi ihtiyacı
3. ZK-EVM'nin kanıt yeteneği
ZK-EVM'nin RISC-V ile değiştirilmesinin (2) ve (3)'teki temel darboğazları çözebileceğini savunacağım.
Aşağıdaki tablo, Succinct ZK-EVM kanıtı EVM yürütme katmanının her adımı için gereken döngü sayısını göstermektedir:
Grafik açıklaması: Dört ana zaman alıcı adım deserialize_inputs, initialize_witness_db, state_root_computation ve block_execution'dır
Bunlar arasında initialize_witness_db ve state_root_computation durum ağacıyla ilişkilidir ve deserialize_inputs, blok ve tanık verilerini dahili gösterimlere dönüştürme sürecini içerir - aslında, %50'den fazlası tanık verilerinin boyutuyla orantılıdır.
Bu parçalar, mevcut keccak 16'lı Merkle patricia ağacının, kolayca kanıtlanabilir bir karma işlevi kullanan ikili bir ağaçla değiştirilmesiyle büyük ölçüde optimize edilebilir. Poseidon'u kullanarak bir dizüstü bilgisayarda saniyede 2 milyon hash'in (keccak için saniyede yaklaşık 15.000 hash'le karşılaştırıldığında) üretilebildiğini kanıtlayabiliriz. Poseidon'un dışında da birçok seçenek var. Genel olarak bu bileşenlerin optimizasyonu için çok fazla alan var. Ayrıca, bloom'u kaldırarak accrue_logs_bloom'u 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 kat iyileştirme elde etmek için, EVM kanıt verimliliğinin en az 50 kat artırılması gerekiyor. Çözümlerden biri, EVM için daha verimli bir kanıt uygulaması oluşturmaktır; diğeri ise mevcut ZK-EVM kanıtlayıcısının aslında EVM'yi RISC-V'ye derleyerek kanıtları gerçekleştirdiğini ve akıllı sözleşme geliştiricilerine RISC-V sanal makinesine doğrudan erişim sağladığını belirtmektir.
Bazı veriler, verimlilik artışının belirli durumlarda 100 katı aşabileceğini göstermektedir:
Gerçek uygulamalarda, kalan kanıtlayıcı süresi esas olarak mevcut ön derleme işlemi tarafından işgal edilebilir. Ana sanal makine olarak RISC-V kullanılırsa, Gas çizelgesi gerçek kanıt süresini yansıtacak ve ekonomik baskı, geliştiricileri yüksek maliyetli ön derleme kullanımını azaltmaya yöneltecektir. Yine de kazanımlar o kadar büyük olmayacak, ancak önemli olacağına inanmak için iyi sebepler var.
(Normal EVM yürütmede "EVM işlemleri" ve "diğer işlemler" için harcanan zamanın da yaklaşık 50/50 olduğunu belirtmekte fayda var, bu nedenle EVM'yi "orta katman" olarak kaldırmanın eşit derecede önemli kazanımlar getireceğini sezgisel olarak düşünüyoruz)
Uygulama ayrıntıları
Bu öneri birden fazla şekilde uygulanabilir. En az kesintiye neden olan çözüm, aynı anda her iki sanal makineyi desteklemek ve sözleşmelerin her ikisinde de yazılabilmesine olanak tanımaktır. Her iki sözleşme türü de aynı işlevselliğe erişebilir: kalıcı depolama (SLOAD/SSTORE), ETH bakiyelerini tutma yeteneği, çağrı yapma/alma, vb. EVM ve RISC-V sözleşmeleri birbirlerini arayabilir - RISC-V perspektifinden, bir EVM sözleşmesini çağırmak, özel parametrelere sahip bir sistem çağrısı yürütmeye eşdeğerdir; ve mesajı alan EVM sözleşmesi bunu bir ÇAĞRI olarak yorumlayacaktır.
Protokol perspektifinden daha radikal bir yaklaşım, mevcut EVM sözleşmelerini, mevcut EVM kodunu çalıştıran RISC-V'de yazılmış bir EVM yorumlayıcı sözleşmesini çağıracak şekilde dönüştürmektir. Yani, bir EVM sözleşmesinin kodu C ise ve EVM yorumlayıcısı X adresindeyse, sözleşme, dışarıdan çağrı argümanları D ile çağrıldığında X'i çağıran ve (C, D)'yi geçiren, ardından dönüş değerini bekleyen ve bunu ileten en üst düzey mantıkla değiştirilecektir. EVM yorumlayıcısı sözleşmeyi kendisi çağırırsa ve CALL veya SLOAD/SSTORE çalıştırmasını isterse, sözleşme bu işlemleri yürütür.
Uzlaşma, ikinci seçeneği benimsemek, ancak protokol aracılığıyla "sanal makine yorumlayıcısı" konseptini açıkça desteklemek ve mantığının RISC-V'de yazılmasını gerektirmektir. EVM ilk uygulama olacak, gelecekte diğer diller de desteklenecek (Move olası bir aday).
İkinci ve üçüncü seçeneklerin temel avantajı, yürütme katmanı özelliklerini büyük ölçüde basitleştirebilmeleridir. SELFDESTRUCT'ı kaldırmak gibi artımlı bir basitleştirmenin bile zor olduğu göz önüne alındığında, bu yaklaşım tek uygulanabilir basitleştirme yolu olabilir. Tinygrad, "10.000 satırdan fazla kod olmamalı" şeklindeki katı kuralı takip ediyor ve blok zincirinin altındaki en uygun katman, bu kısıtlamayı kolayca karşılayabilmeli ve daha da basitleştirebilmelidir. Beam Chain projesi, Ethereum'un konsensüs katmanını önemli ölçüde basitleştirmeyi vaat ediyor ve bu radikal değişim, yürütme katmanında benzer iyileştirmeler elde etmenin tek uygulanabilir yolu olabilir.
BlockBeats Resmi Topluluğuna Katılın:
Telegram Abonelik Grubu: https://t.me/theblockbeats
Telegram Sohbet Grubu: https://t.me/BlockBeats_App
Twitter Resmi Hesabı: https://twitter.com/BlockBeatsAsia
