Öneri: Akıllı sözleşmelerin yazıldığı sanal makine dili olarak EVM’nin yerine RISC-V mimarisini getirmek.

Önemli Noktalar:

• Hesaplar, sözleşmeler arası çağrılar, veri depolama gibi temel kavramlar aynı kalacak. Bu soyutlamalar zaten iyi çalışıyor ve geliştiriciler bu yapıya alışık.
• SLOAD, SSTORE, BALANCE, CALL gibi EVM opcode’ları RISC-V sistem çağrılarına dönüştürülecek.
• Akıllı sözleşmeler Rust ile yazılabilir hale gelecek. Ancak geliştiricilerin büyük kısmının Solidity veya Vyper kullanmaya devam etmesi bekleniyor. Bu diller, RISC-V’yi bir derleyici arka ucu olarak destekleyecek şekilde uyarlanabilir.
• Rust’ta yazılmış akıllı sözleşmeler teknik olarak mümkün olsa da okunabilirlik açısından zayıf. Solidity ve Vyper ise geliştirici deneyimi açısından çok daha kullanışlı ve okunabilir kalmaya devam edecek.
• Geliştirici deneyimi büyük ölçüde değişmeyecek, hatta çoğu geliştirici geçişi neredeyse fark etmeyebilir.
• Mevcut EVM sözleşmeleri geçerliliğini koruyacak ve RISC-V sözleşmeleriyle tam uyumlu çalışabilecek.
• İki taraflı etkileşim mümkün olacak; bunun nasıl sağlanacağı yazının ilerleyen bölümlerinde ele alınıyor.

Bu konuda öne çıkan örneklerden biri Nervos’un CKB sanal makinesi. CKB VM de RISC-V tabanlı bir yapıya sahip ve pratikte bu geçişin mümkün olduğunu gösteriyor.

Neden Bunu Yapıyoruz?

Kısa vadede, Ethereum L1 ölçeklenebilirliğinin ana engelleri bazı EIP’lerle çözülmeye çalışılıyor. Bunlar arasında blok düzeyinde erişim listeleri, gecikmeli yürütme, dağıtılmış geçmiş depolama ve EIP-4444 yer alıyor.

Orta vadede ise devletsiz yapıların ve ZK-EVM’lerin devreye alınması planlanıyor. Ancak uzun vadede Ethereum L1’in karşı karşıya kalacağı temel sınırlayıcı faktörler şunlar:

• Veri erişilebilirliği örneklemesinin ve geçmiş depolama protokollerinin kararlılığı
• Blok üretiminin rekabetçi bir piyasa yapısında sürdürülmesi gereği
• ZK-EVM kanıtlama verimliliği

ZK-EVM’i RISC-V tabanlı bir yapı ile değiştirmek, özellikle (2) ve (3) numaralı darboğazlara doğrudan çözüm sunabilir. ZK-EVM’lerin kanıt üretim sürecinde en çok zaman alan dört temel bölüm vardır:

• deserialize_inputs
• initialize_witness_db
• state_root_computation
• block_execution

Bu işlemlerden initialize_witness_db ve state_root_computation, durum ağacıyla ilgilidir. deserialize_inputs, blok ve şahit verilerini içsel bir yapıya dönüştürür. Bu işlemlerin büyük bölümü, şahit (witness) boyutlarına bağlıdır.

Bu işlemlerden initialize_witness_db ve state_root_computation, durum ağacıyla ilgilidir. deserialize_inputs, blok ve şahit verilerini içsel bir yapıya dönüştürür. Bu işlemlerin büyük bölümü, şahit (witness) boyutlarına bağlıdır.

Bu alanlar, mevcut keccak tabanlı 16-ary Merkle Patricia ağacının yerine, prover-dostu hash fonksiyonları (örneğin Poseidon) kullanılan ikili ağaçlarla optimize edilebilir. Keccak ile dizüstü bir bilgisayarda saniyede ~15.000 hash üretilebilirken, Poseidon ile bu sayı 2 milyona çıkabiliyor. Başka alternatif hash fonksiyonları da mevcut. Bu optimizasyonlar, şahit boyutunu ve prover yükünü ciddi biçimde azaltabilir. Ek olarak, accrue_logs_bloom gibi gereksiz işlemler kaldırılabilir.

Ancak tüm bu düzenlemelerden sonra elimizde hâlâ block_execution kalır. Bu, günümüzde prover döngülerinin yaklaşık yarısını oluşturur. Toplam prover verimliliğinde 100 kat artış isteniyorsa, EVM tarafında en az 50 kat iyileşme kaçınılmazdır.

Bu iyileşmeyi sağlamak için iki temel yaklaşım var:

1. Prover döngüleri açısından çok daha verimli EVM uygulamaları geliştirmek.
2. ZK-EVM prover’larının halihazırda EVM uygulamalarını RISC-V’e derleyerek ispatladığını fark edip, akıllı sözleşme geliştiricilerine doğrudan RISC-V VM erişimi sağlamak.

Bazı durumlarda bu yapı 100 kata kadar verimlilik sağlayabilir.

Gerçekte, prover süresinin büyük kısmının ön yüklemeler tarafından domine edilmesini bekleyebiliriz. Ancak RISC-V birincil sanal makine haline gelirse, gaz programı doğrudan ispat süresine göre ayarlanacak. Bu da yüksek maliyetli ön yüklemelerin kullanımı üzerinde ekonomik baskı yaratacaktır.

Bununla birlikte, kazanımlar her zaman bu kadar dramatik olmayabilir. Ancak yine de sistemde kayda değer faydalar sağlayacağına dair güçlü nedenler var. Ayrıca, bugünkü EVM yürütmesinde de işlemlerin yaklaşık yarısı “EVM” dışındaki bileşenlere gider. Bu nedenle EVM’yi sistemden kaldırmakla sağlanabilecek kazanımlar içgüdüsel olarak da anlamlı görünüyor.

Uygulama Detayları

Bu öneriyi uygulamanın birkaç farklı yolu var. En az müdahaleci olan yaklaşım, hem EVM hem de RISC-V sanal makinelerini desteklemek ve geliştiricilerin her iki yapıda da sözleşme yazabilmesine izin vermek olacaktır. Bu senaryoda, her iki tür sözleşme de kalıcı depolama (SLOAD, SSTORE), ETH bakiyesi tutma, çağrı yapma ve alma gibi aynı temel işlevlere erişebilir.

EVM ve RISC-V sözleşmeleri birbirlerini çağırmakta özgür olacaktır. RISC-V tarafından bir EVM sözleşmesini çağırmak, teknik olarak bir sistem çağrısı olarak görülür. EVM tarafı bu çağrıyı standart bir CALL olarak yorumlar ve işlem gerçekleştirilir.

Daha Radikal Bir Yaklaşım

Bir diğer seçenek, mevcut EVM sözleşmelerini, kodlarını doğrudan çalıştırmak yerine, bu kodları RISC-V üzerinde yazılmış bir EVM yorumlayıcısına ileten sözleşmelere dönüştürmektir. Örneğin, bir EVM sözleşmesinin kodu “C” ve yorumlayıcının adresi “X” ise, dış çağrılar bu sözleşmeye geldiğinde içeride “(C, D)” ile X’e yönlendirilir, dönüş yanıtı alınır ve çağrıyı yapan tarafa iletilir. Eğer yorumlayıcı CALL, SLOAD veya SSTORE gibi işlemleri çalıştırmak için sözleşmeyi çağırırsa, sözleşme bu işlemleri gerçekleştirir.

Orta Yol: Yorumlayıcıyı Protokol Özelliği Haline Getirmek

İkinci yaklaşımın daha dengeli bir versiyonu, yorumlayıcı kavramını protokol düzeyinde resmileştirmek olabilir. Bu yapı altında, yorumlayıcının RISC-V ile yazılması zorunlu kılınır. EVM bu modelin ilk örneği olabilir, ancak Move gibi başka sanal makineler de zamanla desteklenebilir.

Basitlik Üzerine Kazançlar

İkinci ve üçüncü seçeneklerin ortak bir avantajı, yürütme katmanını ciddi biçimde sadeleştirme potansiyelidir. Öyle ki, SELFDESTRUCT gibi karmaşık yapıları sistemden kaldırmak bile bu radikal değişiklikten daha zor olabilir.

Tinygrad projesinin “10.000 satır kod sınırı” kuralı gibi, en iyi blockchain taban katmanın da bu tür sade yapılarla inşa edilmesi gerektiği savunuluyor. Beam zincir çalışması, Ethereum’un konsensüs katmanını sadeleştirme açısından büyük umutlar vadediyor. Ancak yürütme katmanının benzer kazançlar elde etmesi için bu düzeyde bir değişim, belki de tek geçerli yol olabilir.

Yasal Uyarı

Bu makale, Ethereum Magicians kaynağından alıntılanmıştır. İçeriğin tüm telif hakları yazarı Vitalik Buterin’e aittir. Telif haklarına ilişkin sorularınız için bizimle iletişime geçebilirsiniz.

Bu içerik yalnızca bilgilendirme amacı taşımaktadır ve yazarın kişisel görüşlerini yansıtır. Gate.TR’nin resmi görüşlerini yansıtmamaktadır. İçerikte yer alan marka, kurum, kuruluş veya kişilerle Gate.TR’nin herhangi bir ilişkisi bulunmamaktadır.

Bu içerik, yatırım tavsiyesi niteliğinde değildir. Dijital varlık alım-satımını teşvik etmeyi amaçlamaz, yalnızca bilgilendirme amaçlıdır.

Kripto varlıklar yüksek risk içerir ve ciddi fiyat dalgalanmalarına maruz kalabilir. Yatırım kararı vermeden önce kendi finansal durumunuzu değerlendirmeli ve kararınızı bağımsız olarak vermelisiniz.

Makalede yer alan veriler ve grafikler yalnızca genel bilgilendirme amacıyla sunulmuştur. Tüm içerikler özenle hazırlanmış olsa da, olası hata veya eksikliklerden dolayı sorumluluk kabul edilmez.

Gate Akademi ekibi bu içeriği farklı dillere çevirebilir. Hiçbir çeviri makale; kopyalanamaz, çoğaltılamaz veya izinsiz dağıtılamaz.