Hedef, yürütme katmanının verimliliğini ve sadeliğini önemli ölçüde artırmak ve genişleme darboğazını aşmaktır.
**Kaynak:**Vitalik Buterin
Derleyen: KarenZ, Foresight News
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 iyileştirmeyi, 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 bu öneriyi tam metin olarak derledi, amacı okuyucuların bu teknoloji tasarımını anlamalarına yardımcı olmaktır. Aşağıda önerinin orijinal metninin derlenmiş içeriği bulunmaktadır:
Bu makale, Ethereum'un yürütme katmanının geleceği hakkında, konsensüs katmanının Işın Zinciri 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'nin yerine RISC-V kullanarak akıllı sözleşme yazımı için sanal makine dili.
Önemli Açıklama:
Hesap sistemi, çapraz sözleşme çağrısı, depolama gibi kavramlar tamamen korunacaktır. Bu soyut tasarımlar iyi çalışmakta ve geliştiriciler tarafından kullanılmaya alışılmıştır. SLOAD, SSTORE, BALANCE, CALL gibi işletim kodları RISC-V sistem çağrılarına dönüşecektir.
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şmeleri çalışmaya devam edecek ve yeni RISC-V sözleşmeleri ile tamamen iki yönlü uyumlu olacaktır. Uygulama yöntemleri çeşitlidir, bu makalede daha sonra detaylı olarak ele alınacaktır.
Nervos CKB VM bir öncülük yapmıştır, esasen RISC-V uygulamasıdır.
neden böyle yapıyorsun?
Kısa vadede, uygulanacak olan EIP'ler (blok düzeyinde erişim listesi, gecikmeli yürütme, dağıtık tarih depolama ve EIP-4444 gibi) Ethereum L1'in ana genişleme darboğazlarını çözebilir. Orta vadede, stateless yapı ve ZK-EVM daha fazla sorunu çözmek için kullanılacaktır. Uzun vadede, Ethereum L1 genişlemesinin ana kısıtlayıcı faktörü şunlar olacaktır:
Veri kullanılabilirliği örneklemesi ve tarihsel depolama protokolünün kararlılığı
Blok üretim pazarının rekabetçiliğini koruma talebi
ZK-EVM'in kanıtlama yeteneği
ZK-EVM'nin RISC-V ile değiştirilmesinin (2) ve (3) içindeki kritik darboğazları çözebileceğini savunacağım.
Aşağıdaki tablo, Succinct ZK-EVM'nin EVM yürütme katmanının her aşaması için gereken döngü sayısını göstermektedir:
Grafik Açıklaması: Dört ana zaman alanı deserialize_inputs, initialize_witness_db, state_root_computation ve block_execution
initialize_witness_db ve state_root_computation, durum ağacı ile ilgilidir; deserialize_inputs, blok ve tanık verilerini içsel temsile dönüştürme sürecini kapsar - aslında %50'den fazlası, tanık verisi boyutu ile orantılıdır.
Güncel keccak 16-ary Merkle patricia ağacını, kanıtlaması kolay hash fonksiyonları kullanan binary ağacıyla değiştirmek, bu bileşenlerin büyük ölçüde optimize edilmesini sağlayabilir. Poseidon kullanıldığında, dizüstü bilgisayarda saniyede 2 milyon hash değeri kanıtlayabiliriz (karşılaştırıldığında, keccak yaklaşık 15.000 hash/saniye). Poseidon dışında birçok başka seçenek de var. Genel olarak, bu bileşenlerin büyük bir optimize edilme potansiyeli var. Ayrıca, bloom'u kaldırarak accrue_logs_bloom'u ortadan kaldırabiliriz.
Kalan block_execution, mevcut kanıt döngüsünün (prover cycles) yaklaşık yarısını oluşturur. Toplam kanıt verimliliğini 100 kat artırmak için, EVM kanıt verimliliğinin en az 50 kat artırılması gerekir. Çözüm yollarından biri, EVM için daha verimli bir kanıt uygulaması oluşturmaktır; diğer bir yol ise mevcut ZK-EVM kanıtlayıcısının aslında EVM'yi RISC-V'ye derleyerek kanıtladığını fark etmektir; bu da akıllı sözleşme geliştiricilerinin doğrudan bu RISC-V sanal makinesine erişmesini sağlar.
Bazı veriler, belirli durumlarda verimliliğin 100 katından fazla artabileceğini göstermektedir:
Gerçek uygulamalarda, kalan prover süresi muhtemelen mevcut ön derlemeler (precompiles) işlemleri tarafından işgal edilecektir. RISC-V'yi ana sanal makine olarak aldığımızda, Gas takvimi gerçek kanıtlama süresini yansıtacaktır, ekonomik baskı geliştiricileri yüksek maliyetli ön derlemeleri kullanmalarını azaltmaya teşvik edecektir. Yine de, kazançlar bu kadar belirgin olmayacaktır, ancak bu kazançların oldukça önemli olacağına dair yeterli sebebimiz var.
(Dikkat edilmesi gereken bir nokta, normal EVM yürütmesinde "EVM işlemleri" ile "diğer işlemler" arasındaki zaman payının da yaklaşık 50/50 olduğu, bu nedenle EVM'yi "ara katman" olarak kaldırmanın benzer şekilde önemli faydalar sağlayacağını düşünüyoruz.)
uygulama detayları
Bu teklifi uygulamanın birkaç yolu vardır. En az kesintiye neden olan çözüm, her iki sanal makineyi de aynı anda destekleyerek 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, 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 yorumlar.
Protokol açısından daha radikal bir yaklaşım, mevcut EVM sözleşmelerinin, mevcut EVM kodunu çalıştıran RISC-V ile yazılmış bir EVM yorumlayıcı sözleşmesine çağrı yapacak şekilde dönüştürülmesidir. Yani, eğer bir EVM sözleşmesinde C kodu varsa ve EVM yorumlayıcısı X adresindeyse, o zaman bu sözleşme üst düzey mantıkla değiştirilir; dışarıdan D parametreleriyle çağrıldığında X'i arar ve (C, D) ile birlikte iletir ve ardından geri dönüş değerini bekleyip iletir. Eğer EVM yorumlayıcısı kendisi bu sözleşmeyi çağırırsa ve CALL veya SLOAD/SSTORE çalıştırılmasını talep ederse, o zaman sözleşme bu işlemleri gerçekleştirir.
Orta yol, ikinci seçeneği benimsemek ancak protokolde "sanallaştırıcı yorumlayıcı" kavramını açıkça desteklemek ve mantığının RISC-V ile yazılmasını gerektirmektir. EVM, ilk örnek olacak, gelecekte başka diller de desteklenebilir (Move muhtemel 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, "en fazla 10.000 satır kod" gibi katı ve hızlı bir kurala bağlıdır ve en uygun temel blok zinciri bu sınırı kolayca karşılayabilmeli ve daha da kolaylaştırılabilmelidir. 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.
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 uzun vadeli L1 yürütme katmanı önerisinin tam metni: EVM yerine RISC-V kullanmak
**Kaynak:**Vitalik Buterin
Derleyen: KarenZ, Foresight News
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 iyileştirmeyi, 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 bu öneriyi tam metin olarak derledi, amacı okuyucuların bu teknoloji tasarımını anlamalarına yardımcı olmaktır. Aşağıda önerinin orijinal metninin derlenmiş içeriği bulunmaktadır:
Bu makale, Ethereum'un yürütme katmanının geleceği hakkında, konsensüs katmanının Işın Zinciri 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'nin yerine RISC-V kullanarak akıllı sözleşme yazımı için sanal makine dili.
Önemli Açıklama:
Nervos CKB VM bir öncülük yapmıştır, esasen RISC-V uygulamasıdır.
neden böyle yapıyorsun?
Kısa vadede, uygulanacak olan EIP'ler (blok düzeyinde erişim listesi, gecikmeli yürütme, dağıtık tarih depolama ve EIP-4444 gibi) Ethereum L1'in ana genişleme darboğazlarını çözebilir. Orta vadede, stateless yapı ve ZK-EVM daha fazla sorunu çözmek için kullanılacaktır. Uzun vadede, Ethereum L1 genişlemesinin ana kısıtlayıcı faktörü şunlar olacaktır:
ZK-EVM'nin RISC-V ile değiştirilmesinin (2) ve (3) içindeki kritik darboğazları çözebileceğini savunacağım.
Aşağıdaki tablo, Succinct ZK-EVM'nin EVM yürütme katmanının her aşaması için gereken döngü sayısını göstermektedir:
Grafik Açıklaması: Dört ana zaman alanı deserialize_inputs, initialize_witness_db, state_root_computation ve block_execution
initialize_witness_db ve state_root_computation, durum ağacı ile ilgilidir; deserialize_inputs, blok ve tanık verilerini içsel temsile dönüştürme sürecini kapsar - aslında %50'den fazlası, tanık verisi boyutu ile orantılıdır.
Güncel keccak 16-ary Merkle patricia ağacını, kanıtlaması kolay hash fonksiyonları kullanan binary ağacıyla değiştirmek, bu bileşenlerin büyük ölçüde optimize edilmesini sağlayabilir. Poseidon kullanıldığında, dizüstü bilgisayarda saniyede 2 milyon hash değeri kanıtlayabiliriz (karşılaştırıldığında, keccak yaklaşık 15.000 hash/saniye). Poseidon dışında birçok başka seçenek de var. Genel olarak, bu bileşenlerin büyük bir optimize edilme potansiyeli var. Ayrıca, bloom'u kaldırarak accrue_logs_bloom'u ortadan kaldırabiliriz.
Kalan block_execution, mevcut kanıt döngüsünün (prover cycles) yaklaşık yarısını oluşturur. Toplam kanıt verimliliğini 100 kat artırmak için, EVM kanıt verimliliğinin en az 50 kat artırılması gerekir. Çözüm yollarından biri, EVM için daha verimli bir kanıt uygulaması oluşturmaktır; diğer bir yol ise mevcut ZK-EVM kanıtlayıcısının aslında EVM'yi RISC-V'ye derleyerek kanıtladığını fark etmektir; bu da akıllı sözleşme geliştiricilerinin doğrudan bu RISC-V sanal makinesine erişmesini sağlar.
Bazı veriler, belirli durumlarda verimliliğin 100 katından fazla artabileceğini göstermektedir:
Gerçek uygulamalarda, kalan prover süresi muhtemelen mevcut ön derlemeler (precompiles) işlemleri tarafından işgal edilecektir. RISC-V'yi ana sanal makine olarak aldığımızda, Gas takvimi gerçek kanıtlama süresini yansıtacaktır, ekonomik baskı geliştiricileri yüksek maliyetli ön derlemeleri kullanmalarını azaltmaya teşvik edecektir. Yine de, kazançlar bu kadar belirgin olmayacaktır, ancak bu kazançların oldukça önemli olacağına dair yeterli sebebimiz var.
(Dikkat edilmesi gereken bir nokta, normal EVM yürütmesinde "EVM işlemleri" ile "diğer işlemler" arasındaki zaman payının da yaklaşık 50/50 olduğu, bu nedenle EVM'yi "ara katman" olarak kaldırmanın benzer şekilde önemli faydalar sağlayacağını düşünüyoruz.)
uygulama detayları
Bu teklifi uygulamanın birkaç yolu vardır. En az kesintiye neden olan çözüm, her iki sanal makineyi de aynı anda destekleyerek 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, 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 yorumlar.
Protokol açısından daha radikal bir yaklaşım, mevcut EVM sözleşmelerinin, mevcut EVM kodunu çalıştıran RISC-V ile yazılmış bir EVM yorumlayıcı sözleşmesine çağrı yapacak şekilde dönüştürülmesidir. Yani, eğer bir EVM sözleşmesinde C kodu varsa ve EVM yorumlayıcısı X adresindeyse, o zaman bu sözleşme üst düzey mantıkla değiştirilir; dışarıdan D parametreleriyle çağrıldığında X'i arar ve (C, D) ile birlikte iletir ve ardından geri dönüş değerini bekleyip iletir. Eğer EVM yorumlayıcısı kendisi bu sözleşmeyi çağırırsa ve CALL veya SLOAD/SSTORE çalıştırılmasını talep ederse, o zaman sözleşme bu işlemleri gerçekleştirir.
Orta yol, ikinci seçeneği benimsemek ancak protokolde "sanallaştırıcı yorumlayıcı" kavramını açıkça desteklemek ve mantığının RISC-V ile yazılmasını gerektirmektir. EVM, ilk örnek olacak, gelecekte başka diller de desteklenebilir (Move muhtemel 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, "en fazla 10.000 satır kod" gibi katı ve hızlı bir kurala bağlıdır ve en uygun temel blok zinciri bu sınırı kolayca karşılayabilmeli ve daha da kolaylaştırılabilmelidir. 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.