20 Nisan'da Vitalik Buterin, Ethereum Magicians platformunda Ethereum'un uzun vadeli L1 yürütme katmanı hakkında önemli bir öneri sundu. Mevcut EVM (Ethereum Sanal Makinesi) yerine akıllı sözleşmeler yazmak için RISC-V mimarisinin benimsenmesini önerdi. Bu öneri, Ethereum'un yürütme katmanının çalışma verimliliğini temelden artırmayı, mevcut ana ölçeklenme darboğazlarından birini aşmayı ve yürütme katmanının sadeliğini büyük ölçüde basitleştirmeyi amaçlıyor.
Foresight News bu teklifi tam olarak derleyerek okuyucuların bu teknolojik konsepti anlamalarına yardımcı olmayı amaçladı. Aşağıda teklifin 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ındaki Beam Chain planı kadar iddialı bir radikal fikir sunmaktadır. Bu öneri, Ethereum'un yürütme katmanının verimliliğini önemli ölçüde artırmayı, ana genişleme darboğazlarından birini çözmeyi ve yürütme katmanını önemli ölçüde basitleştirmeyi hedeflemektedir - aslında, bu hedefe ulaşmanın tek yolu bu olabilir.
Temel fikir: Akıllı sözleşme yazımı için sanal makine dili olarak EVM'nin yerine RISC-V kullanmak.
Önemli açıklama:
Hesap sistemi, sözleşmeler arası çağrılar, 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şlem kodları RISC-V sistem çağrılarına dönüşecektir.
Bu modda, akıllı sözleşmeler Rust ile yazılabilir, ancak çoğu geliştiricinin hala sözleşmeleri yazmak için Solidity (veya Vyper) kullanmaya devam etmesini bekliyorum. Bu diller, yeni arka uç olarak RISC-V'yi destekleyecektir. Çünkü Rust ile yazılan akıllı sözleşmelerin okunabilirliği aslında daha düşüktür, oysa Solidity ve Vyper daha net ve okunaklıdır. Geliştirici deneyimi muhtemelen neredeyse etkilenmeyecek, geliştiriciler değişikliği fark etmeyebilir.
Eski EVM sözleşmeleri çalışmaya devam edecek ve yeni RISC-V sözleşmeleri ile tamamen iki yönlü uyumlu olacak. Uygulama yöntemleri çeşitli olup, bu yazının ilerleyen bölümlerinde detaylı olarak incelenecektir.
Nervos CKB VM, esasen RISC-V uygulaması olarak bir ilki açmıştır.
Bunu neden yapıyorsun?
Kısa vadede, yaklaşan EIP'ler (örneğin, blok düzeyinde erişim listeleri, ertelenmiş yürütme, dağıtılmış geçmiş depolama ve EIP-4444), Ethereum L1'in büyük ölçeklendirme darboğazlarını ele alacaktır. Orta vadede, vatansızlık ve ZK-EVM ile 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ği örnekleme 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'yi RISC-V ile değiştireceğimi, (2) ve (3)'teki kritik darboğazları çözebileceğini savunacağım.
Aşağıdaki tablo, Succinct ZK-EVM'in EVM yürütme katmanındaki her aşama için gereken döngü sayısını göstermektedir:
Grafik Açıklaması: Dört ana zaman alıcı aşama deserialize_inputs, initialize_witness_db, state_root_computation ve block_execution'dır.
initialize_witness_db ve state_root_computation, durum ağacıyla ilgiliyken, deserialize_inputs, blok ve tanıklık verilerini içsel temsile dönüştürme sürecini kapsar - aslında %50'den fazlası tanıklık verilerinin boyutuyla orantılıdır.
Mevcut keccak 16-ary Merkle patricia ağacını, kanıtlanması kolay hash fonksiyonları kullanan binary tree ile değiştirerek, bu bölümler büyük ölçüde optimize edilebilir. Poseidon kullanıldığında, dizüstü bilgisayarda her saniye 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 diğer seçenek de vardır. Genel olarak, bu bileşenlerde büyük bir optimizasyon potansiyeli bulunmaktadır. Ayrıca, bloom'u kaldırarak accrue_logs_bloom'u ortadan kaldırabiliriz.
Kalan block_execution, mevcut kanıt döngülerinin (prover cycles) yaklaşık yarısını oluşturur. Toplam kanıt verimliliğinde 100 kat artış sağlamak için, EVM kanıt verimliliğinin en az 50 kat artırılması gerekmektedir. Çözüm önerilerinden biri, EVM için daha verimli bir kanıt uygulaması oluşturmaktır; diğer bir öneri ise mevcut ZK-EVM kanıtlayıcısının aslında EVM'yi RISC-V'ye derleyerek kanıtlamasıdır ve doğrudan akıllı sözleşme geliştiricilerinin bu RISC-V sanal makinesine erişmesini sağlamaktır.
Bazı veriler, belirli durumlarda verimliliğin 100 katından fazla artabileceğini göstermektedir:
Gerçek uygulamalarda, kalan prover süresi muhtemelen mevcut ön derleme (precompiles) işlemleri tarafından işgal edilecektir. RISC-V ana sanal makine olarak alındığında, Gas planı gerçek kanıtlama süresini yansıtacak, ekonomik baskı geliştiricileri yüksek maliyetli ön derlemeleri 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 nedenimiz var.
(Dikkat edilmesi gereken bir nokta, normal EVM yürütmesinde "EVM işlemleri" ile "diğer işlemler"in zaman tüketiminin de neredeyse 50/50 olduğu, bu nedenle EVM'yi "ara katman" olarak kaldırmanın benzer şekilde önemli bir kazanç sağlayacağı düşünülmektedir.)
uygulama detayları
Bu önerinin birden fazla uygulanma biçimi vardır. En az yıkıcı olan çözüm, iki sanal makineyi aynı anda desteklemektir ve sözleşmelerin birini seçerek yazılmasına izin vermektir. Her iki tür sözleşme de aynı işlevlere erişebilir: kalıcı depolama (SLOAD/SSTORE), ETH bakiyesine sahip olma yeteneği, çağrı başlatma / alma vb. EVM ve RISC-V sözleşmeleri birbirlerini çağırabilir - RISC-V açısından bakıldığında, EVM sözleşmesini çağırmak, özel parametrelerle bir sistem çağrısını yürütmek gibidir; bir mesaj alan EVM sözleşmesi bunu CALL 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 yorumlayıcı sözleşmesine 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 D çağrı argümanı ile çağrıldığında X'i çağıran ve (C, D) ileten ve ardından dönüş değerini bekleyen ve ileten üst düzey mantıkla değiştirilecektir. 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.
Orta yol, ikinci seçeneği benimsemek, ancak protokol aracılığıyla "sanallaştırma makinesi yorumlayıcısı" kavramını açık bir şekilde desteklemek ve mantığını RISC-V ile yazmayı gerektirmektir. EVM ilk örnek olacak, gelecekte diğer diller de desteklenebilir (Move aday seçeneklerden biri 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ı önerisi tam metni: EVM yerine RISC-V kullanmak
Kaynak: Vitalik Buterin
Derleyen: KarenZ, Foresight News
20 Nisan'da Vitalik Buterin, Ethereum Magicians platformunda Ethereum'un uzun vadeli L1 yürütme katmanı hakkında önemli bir öneri sundu. Mevcut EVM (Ethereum Sanal Makinesi) yerine akıllı sözleşmeler yazmak için RISC-V mimarisinin benimsenmesini önerdi. Bu öneri, Ethereum'un yürütme katmanının çalışma verimliliğini temelden artırmayı, mevcut ana ölçeklenme darboğazlarından birini aşmayı ve yürütme katmanının sadeliğini büyük ölçüde basitleştirmeyi amaçlıyor.
Foresight News bu teklifi tam olarak derleyerek okuyucuların bu teknolojik konsepti anlamalarına yardımcı olmayı amaçladı. Aşağıda teklifin 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ındaki Beam Chain planı kadar iddialı bir radikal fikir sunmaktadır. Bu öneri, Ethereum'un yürütme katmanının verimliliğini önemli ölçüde artırmayı, ana genişleme darboğazlarından birini çözmeyi ve yürütme katmanını önemli ölçüde basitleştirmeyi hedeflemektedir - aslında, bu hedefe ulaşmanın tek yolu bu olabilir.
Temel fikir: Akıllı sözleşme yazımı için sanal makine dili olarak EVM'nin yerine RISC-V kullanmak.
Önemli açıklama:
Hesap sistemi, sözleşmeler arası çağrılar, 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şlem kodları RISC-V sistem çağrılarına dönüşecektir.
Bu modda, akıllı sözleşmeler Rust ile yazılabilir, ancak çoğu geliştiricinin hala sözleşmeleri yazmak için Solidity (veya Vyper) kullanmaya devam etmesini bekliyorum. Bu diller, yeni arka uç olarak RISC-V'yi destekleyecektir. Çünkü Rust ile yazılan akıllı sözleşmelerin okunabilirliği aslında daha düşüktür, oysa Solidity ve Vyper daha net ve okunaklıdır. Geliştirici deneyimi muhtemelen neredeyse etkilenmeyecek, geliştiriciler değişikliği fark etmeyebilir.
Eski EVM sözleşmeleri çalışmaya devam edecek ve yeni RISC-V sözleşmeleri ile tamamen iki yönlü uyumlu olacak. Uygulama yöntemleri çeşitli olup, bu yazının ilerleyen bölümlerinde detaylı olarak incelenecektir.
Nervos CKB VM, esasen RISC-V uygulaması olarak bir ilki açmıştır.
Bunu neden yapıyorsun?
Kısa vadede, yaklaşan EIP'ler (örneğin, blok düzeyinde erişim listeleri, ertelenmiş yürütme, dağıtılmış geçmiş depolama ve EIP-4444), Ethereum L1'in büyük ölçeklendirme darboğazlarını ele alacaktır. Orta vadede, vatansızlık ve ZK-EVM ile 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ği örnekleme 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'yi RISC-V ile değiştireceğimi, (2) ve (3)'teki kritik darboğazları çözebileceğini savunacağım.
Aşağıdaki tablo, Succinct ZK-EVM'in EVM yürütme katmanındaki her aşama için gereken döngü sayısını göstermektedir:
Grafik Açıklaması: Dört ana zaman alıcı aşama deserialize_inputs, initialize_witness_db, state_root_computation ve block_execution'dır.
initialize_witness_db ve state_root_computation, durum ağacıyla ilgiliyken, deserialize_inputs, blok ve tanıklık verilerini içsel temsile dönüştürme sürecini kapsar - aslında %50'den fazlası tanıklık verilerinin boyutuyla orantılıdır.
Mevcut keccak 16-ary Merkle patricia ağacını, kanıtlanması kolay hash fonksiyonları kullanan binary tree ile değiştirerek, bu bölümler büyük ölçüde optimize edilebilir. Poseidon kullanıldığında, dizüstü bilgisayarda her saniye 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 diğer seçenek de vardır. Genel olarak, bu bileşenlerde büyük bir optimizasyon potansiyeli bulunmaktadır. Ayrıca, bloom'u kaldırarak accrue_logs_bloom'u ortadan kaldırabiliriz.
Kalan block_execution, mevcut kanıt döngülerinin (prover cycles) yaklaşık yarısını oluşturur. Toplam kanıt verimliliğinde 100 kat artış sağlamak için, EVM kanıt verimliliğinin en az 50 kat artırılması gerekmektedir. Çözüm önerilerinden biri, EVM için daha verimli bir kanıt uygulaması oluşturmaktır; diğer bir öneri ise mevcut ZK-EVM kanıtlayıcısının aslında EVM'yi RISC-V'ye derleyerek kanıtlamasıdır ve doğrudan akıllı sözleşme geliştiricilerinin bu RISC-V sanal makinesine erişmesini sağlamaktır.
Bazı veriler, belirli durumlarda verimliliğin 100 katından fazla artabileceğini göstermektedir:
Gerçek uygulamalarda, kalan prover süresi muhtemelen mevcut ön derleme (precompiles) işlemleri tarafından işgal edilecektir. RISC-V ana sanal makine olarak alındığında, Gas planı gerçek kanıtlama süresini yansıtacak, ekonomik baskı geliştiricileri yüksek maliyetli ön derlemeleri 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 nedenimiz var.
(Dikkat edilmesi gereken bir nokta, normal EVM yürütmesinde "EVM işlemleri" ile "diğer işlemler"in zaman tüketiminin de neredeyse 50/50 olduğu, bu nedenle EVM'yi "ara katman" olarak kaldırmanın benzer şekilde önemli bir kazanç sağlayacağı düşünülmektedir.)
uygulama detayları
Bu önerinin birden fazla uygulanma biçimi vardır. En az yıkıcı olan çözüm, iki sanal makineyi aynı anda desteklemektir ve sözleşmelerin birini seçerek yazılmasına izin vermektir. Her iki tür sözleşme de aynı işlevlere erişebilir: kalıcı depolama (SLOAD/SSTORE), ETH bakiyesine sahip olma yeteneği, çağrı başlatma / alma vb. EVM ve RISC-V sözleşmeleri birbirlerini çağırabilir - RISC-V açısından bakıldığında, EVM sözleşmesini çağırmak, özel parametrelerle bir sistem çağrısını yürütmek gibidir; bir mesaj alan EVM sözleşmesi bunu CALL 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 yorumlayıcı sözleşmesine 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 D çağrı argümanı ile çağrıldığında X'i çağıran ve (C, D) ileten ve ardından dönüş değerini bekleyen ve ileten üst düzey mantıkla değiştirilecektir. 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.
Orta yol, ikinci seçeneği benimsemek, ancak protokol aracılığıyla "sanallaştırma makinesi yorumlayıcısı" kavramını açık bir şekilde desteklemek ve mantığını RISC-V ile yazmayı gerektirmektir. EVM ilk örnek olacak, gelecekte diğer diller de desteklenebilir (Move aday seçeneklerden biri 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.