Pos ini mengusulkan ide radikal untuk masa depan lapisan eksekusi Ethereum, yang sama ambisiusnya dengan upaya rantai beam untuk lapisan konsensus. Ini bertujuan untuk sangat meningkatkan efisiensi lapisan eksekusi Ethereum, menyelesaikan salah satu bottleneck penskalaan utama, dan juga dapat sangat meningkatkan kesederhanaan lapisan eksekusi - sebenarnya, mungkin satu-satunya cara untuk melakukannya.

Ideanya: gantikan EVM dengan RISC-V sebagai bahasa mesin virtual yang digunakan untuk menulis kontrak pintar.

Klarifikasi penting:

• Konsep akun, panggilan lintas kontrak, penyimpanan, dll akan tetap sama persis. Abstraksi-abstraksi ini berfungsi dengan baik dan para pengembang terbiasa dengan mereka. Opcodes seperti SLOAD, SSTORE, BALANCE, CALL, dll, akan menjadi syscalls RISC-V.
• Di dunia seperti itu, kontrak pintar bisa ditulis dalam Rust, tetapi saya harap sebagian besar pengembang akan tetap menulis kontrak pintar dalam Solidity (atau Vyper), yang akan beradaptasi untuk menambahkan RISC-V sebagai backend. Hal ini dikarenakan kontrak pintar yang ditulis dalam Rust adalah sebenarnyacukupjelek, dan Solidity dan Vyper adalah banyaklebihdapat dibaca. Secara potensial, devex akan berubah sangat sedikit dan para pengembang mungkin hampir tidak menyadari perubahan sama sekali.
• Kontrak EVM gaya lama akan terus berfungsi dan akan sepenuhnya interoperabel dua arah dengan kontrak gaya baru RISC-V. Ada beberapa cara untuk melakukannya, yang akan saya bahas nanti dalam posting ini.

Salah satu preseden untuk hal ini adalah Nervos CKB VM, yang merupakan pada dasarnya RISC-V.

Mengapa melakukan ini?

Dalam jangka pendek, bottleneck utama terkait skalabilitas Ethereum L1 diatasi dengan EIP yang akan datang seperti daftar akses tingkat blok, eksekusi tertundadan penyimpanan sejarah terdistribusi plusEIP-4444. Dalam jangka menengah, kami mengatasi isu lebih lanjut dengan tanpa negaradanZK-EVMsPada jangka panjang, faktor pembatas utama dalam penskalaan Ethereum L1 adalah:

1. Stabilitas dari protokol sampling ketersediaan data dan penyimpanan riwayat
2. Keinginan untuk menjaga produksi blok tetap sebagai pasar yang kompetitif
3. Kemampuan pembuktian ZK-EVM

Saya akan berpendapat bahwa mengganti ZK-EVM dengan RISC-V memecahkan bottleneck kunci pada (2) dan (3).

Ini adalah tabel jumlah siklus yang digunakan oleh Succinct ZK-EVM untuk membuktikan bagian-bagian berbeda dari lapisan eksekusi EVM:

Ada empat bagian yang memakan banyak waktu: deserialize_inputs, initialize_witness_db, state_root_computation dan block_execution.

initialize_witness_db dan state_root_computation keduanya berhubungan dengan pohon status, dan deserialize_inputs mengacu pada proses mengubah data blok dan saksi menjadi representasi internal; oleh karena itu, secara realistis lebih dari 50% dari hal itu berkaitan dengan ukuran saksi.

Bagian-bagian ini dapat dioptimalkan secara signifikan dengan mengganti pohon patricia Merkle keccak 16-ary saat ini dengan pohon biner yang menggunakan fungsi hash yang ramah bagi pembuktian. Jika kita menggunakan Poseidon, kita dapat bukti 2 juta hash per detikpada laptop (dibandingkan dengan ~15.000 hash/dtk untuk keccak). Selain itu, ada banyak opsi selain Poseidon. Secara keseluruhan, ada peluang untuk secara masif mengurangi komponen-komponen ini. Sebagai bonus, kita bisa menyingkirkan accrue_logs_bloom dengan, baik,menghilangkan bunga.

Ini meninggalkan block_execution, yang membentuk sekitar setengah dari siklus prover yang dihabiskan hari ini. Jika kita ingin meningkatkan efisiensi total prover 100x, tidak ada jalan lain selain kita perlu setidaknya efisiensi prover EVM 50x. Satu hal yang bisa kita lakukan adalah mencoba membuat implementasi dari EVM yang jauh lebih efisien dalam hal siklus prover. Hal lain yang bisa kita lakukan adalah memperhatikan bahwa prover ZK-EVM hari ini sudah bekerja dengan membuktikan implementasi EVM yang dikompilasi menjadi RISC-V, dan memberikan akses langsung kepada pengembang kontrak pintar ke RISC-V VM tersebut.

Beberapa angka menunjukkan bahwa dalam kasus terbatas, hal ini dapat memberikan keuntungan efisiensi lebih dari 100x:

Dalam prakteknya, saya berharap bahwa waktu pembuktian yang tersisa akan didominasi oleh apa yang saat ini adalah pra-kompilasi. Jika kita menjadikan RISC-V sebagai VM utama, maka jadwal gas akan mencerminkan waktu pembuktian, dan oleh karena itu akan ada tekanan ekonomi untuk berhenti menggunakan pra-kompilasi yang lebih mahal; namun bahkan demikian keuntungannya tidak akan begitu mengesankan, tetapi kami memiliki alasan yang baik untuk percaya bahwa mereka akan sangat signifikan.

(Sekali-sekali, pembagian sekitar 50/50 antara "EVM" dan "hal lainnya" juga muncul dalam eksekusi EVM reguler, dan kami secara intuitif mengharapkan bahwa keuntungan dari penghapusan EVM sebagai “perantara” seharusnya juga besar)

Detail implementasi

Ada beberapa cara untuk menerapkan jenis proposal ini. Yang paling sedikit mengganggu adalah dengan mendukung dua VM, dan memungkinkan kontrak ditulis di salah satunya. Kedua jenis kontrak akan memiliki akses ke jenis fasilitas yang sama: penyimpanan persisten (SLOAD dan SSTORE), kemampuan untuk memegang saldo ETH, kemampuan untuk melakukan dan menerima panggilan, dll. Kontrak EVM dan RISC-V akan bebas untuk saling memanggil; dari perspektif RISC-V memanggil kontrak EVM akan muncul dari perspektifnya sebagai melakukan syscall dengan beberapa parameter khusus; kontrak EVM yang menerima pesan akan menginterpretasikannya sebagai sebuah PANGGILAN.

Sebuah pendekatan yang lebih radikal dari segi protokol adalah mengubah kontrak EVM yang ada menjadi kontrak yang memanggil kontrak interpreter EVM yang ditulis dalam RISC-V yang menjalankan kode EVM mereka yang ada. Artinya, jika sebuah kontrak EVM memiliki kode C, dan interpreter EVM berada di alamat X, maka kontrak tersebut digantikan dengan logika tingkat atas yang, ketika dipanggil dari luar dengan parameter panggilan D, memanggil X dengan (C, D), dan kemudian menunggu nilai kembali dan meneruskannya. Jika interpreter EVM itu sendiri memanggil kontrak, meminta untuk menjalankan sebuah CALL atau SLOAD/SSTORE, maka kontrak melakukannya.

Salah satu opsi menengah adalah melakukan opsi kedua, tetapi membuat fitur protokol eksplisit untuk itu - pada dasarnya, mengabadikan konsep dari interpreter mesin virtual, dan memerlukan logikanya ditulis dalam RISC-V. EVM akan menjadi yang pertama, tetapi mungkin ada yang lain (misalnya, Move mungkin menjadi kandidat).

Manfaat utama dari proposal kedua dan ketiga adalah bahwa mereka sangat menyederhanakan spesifikasi lapisan eksekusi - memang, jenis ide seperti ini mungkin merupakan satu-satunya cara praktis untuk melakukannya, mengingat kesulitan besar bahkan dalam penyederhanaan bertahap seperti menghapus SELFDESTRUCT. Tinygrad memiliki aturan kerastidak pernah melebihi 10000 baris kode; lapisan dasar blockchain yang optimal seharusnya mampu masuk dengan baik dalam batasan-batasan tersebut dan bahkan menjadi lebih kecil. Upaya beam chain menjanjikan untuk sangat menyederhanakan lapisan konsensus Ethereum. Tetapi untuk lapisan eksekusi melihat peningkatan serupa, jenis perubahan radikal ini mungkin menjadi satu-satunya jalan yang layak.

Penafian:

1. Artikel ini dicetak ulang dari [Para Ahli Ethereum]. Semua hak cipta milik penulis asli [Vitalik Buterin]. Jika ada keberatan terhadap cetak ulang ini, silakan hubungi Belajar Gatetim, dan mereka akan menanganinya dengan segera.
2. Penyangkalan Tanggung Jawab: Pandangan dan opini yang diungkapkan dalam artikel ini semata-mata milik penulis dan tidak merupakan saran investasi apa pun.
3. Tim Belajar Gate menerjemahkan artikel ke dalam bahasa lain. Menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang kecuali disebutkan.