Usulan baru Vitalik: menggantikan EVM saat ini dengan RISC-V

Artikel ini mengajukan ide radikal untuk masa depan lapisan eksekusi Ethereum, yang sama ambisiusnya dengan upaya Beam Chain terhadap lapisan konsensus. Ini bertujuan untuk secara signifikan meningkatkan efisiensi lapisan eksekusi Ethereum, mengatasi salah satu kendala skalabilitas utama, dan juga dapat secara drastis meningkatkan kesederhanaan lapisan eksekusi—sebenarnya, ini mungkin adalah satu-satunya cara.

Ide: Menggunakan RISC-V sebagai bahasa mesin virtual untuk menulis kontrak pintar menggantikan EVM (catatan penerjemah: RISC-V adalah arsitektur set instruksi terbuka yang dibangun berdasarkan prinsip RISC, di mana V menunjukkan generasi kelima RISC).

Pernyataan Penting:

• Akun, panggilan lintas kontrak, penyimpanan, dan konsep lainnya akan tetap sama persis. Abstraksi ini bekerja dengan baik, dan para pengembang juga sudah terbiasa dengan mereka. Opcode seperti SLOAD, SSTORE, BALANCE, CALL akan menjadi panggilan sistem RISC-V.
• Di dunia seperti ini, kontrak pintar dapat ditulis dengan Rust, tetapi saya memperkirakan sebagian besar pengembang akan terus menulis kontrak pintar dengan Solidity (atau Vyper) yang akan disesuaikan untuk menambahkan RISC-V sebagai backend. Ini karena kontrak pintar yang ditulis dengan Rust sebenarnya cukup jelek, sedangkan keterbacaan Solidity dan Vyper jauh lebih tinggi. Mungkin perubahan devex sangat kecil, pengembang mungkin hampir tidak akan menyadari perubahan ini.
• Kontrak EVM lama akan tetap berlaku dan akan sepenuhnya interoperable dua arah dengan kontrak RISC-V baru. Ada beberapa cara untuk melakukan ini, yang akan saya bahas di bagian belakang artikel ini.

Salah satu contohnya adalah Nervos CKB VM, yang pada dasarnya adalah RISC-V.

Mengapa melakukan ini?

Dalam jangka pendek, kendala utama skalabilitas Ethereum L1 akan diselesaikan melalui EIP yang akan datang, seperti daftar akses tingkat blok, eksekusi tertunda, dan penyimpanan sejarah terdistribusi serta EIP-4444. Dalam jangka menengah, kita akan menyelesaikan masalah lebih lanjut terkait tanpa status dan ZK-EVM. Dalam jangka panjang, faktor pembatas utama untuk perluasan Layer1 Ethereum adalah:

• Stabilitas sampling ketersediaan data dan protokol penyimpanan historis
• Harap mempertahankan daya saing pasar produksi blok
• Kemampuan verifikasi ZK-EVM

Saya percaya bahwa mengganti ZK-EVM dengan RISC-V dapat mengatasi salah satu kendala kunci dalam (2) dan (3).

Ini adalah tabel jumlah siklus untuk bagian yang berbeda dari lapisan eksekusi EVM yang digunakan oleh Succinct ZK-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 terkait dengan pohon status, deserialize_inputs merujuk pada proses mengubah data blok dan saksi menjadi representasi internal; oleh karena itu, sebenarnya lebih dari 50% sebanding dengan skala saksi.

Dengan mengganti pohon Merkle patricia keccak 16 yang ada dengan pohon biner yang menggunakan fungsi hash ramah pembuktian, kita dapat melakukan optimasi besar-besaran pada bagian-bagian ini. Jika kita menggunakan Poseidon, kita dapat membuktikan 2 juta nilai hash per detik di laptop (sementara keccak sekitar 15.000 nilai hash per detik). Selain Poseidon, ada banyak pilihan lain. Secara keseluruhan, kita memiliki kesempatan untuk secara signifikan mengurangi komponen-komponen ini. Sebagai imbalan, kita dapat menghilangkan accrue_logs_bloom dengan menyingkirkan bloom.

Sisa yang ada adalah block_execution, yang menyumbang sekitar setengah dari siklus bukti yang dihabiskan hari ini. Jika kita ingin meningkatkan efisiensi keseluruhan pembuktian sebesar 100 kali, maka kita tidak dapat menghindari fakta bahwa kita setidaknya perlu meningkatkan efisiensi pembuktian EVM sebesar 50 kali. Salah satu hal yang bisa kita lakukan adalah mencoba membuat implementasi EVM yang lebih efisien dalam hal siklus bukti. Hal lain yang bisa kita lakukan adalah menyadari bahwa pembuktian ZK-EVM hari ini telah bekerja dengan membuktikan kompilasi ke implementasi EVM RISC-V dan memberikan akses langsung kepada pengembang kontrak pintar ke RISC-V VM tersebut.

Beberapa data menunjukkan bahwa, dalam situasi terbatas, ini dapat meningkatkan efisiensi lebih dari 100 kali:

Sebenarnya, saya memperkirakan waktu bukti yang tersisa akan didominasi oleh pra-kompilasi hari ini. Jika kita menggunakan RISC-V sebagai mesin virtual utama, maka rencana gas akan mencerminkan waktu bukti, sehingga akan ada tekanan ekonomi untuk menghentikan penggunaan pra-kompilasi yang lebih mahal; tetapi meskipun demikian, hasilnya tidak akan begitu mengesankan, tetapi kita memiliki alasan yang cukup untuk percaya bahwa hasilnya akan sangat signifikan.

(Ngomong-ngomong, pemisahan sekitar 50/50 antara “EVM” dan “hal-hal lain” juga muncul dalam eksekusi EVM reguler, dan kami secara intuitif memperkirakan bahwa keuntungan yang dihapus dari EVM sebagai “perantara” seharusnya sama besar)

Detail Implementasi

Ada berbagai cara untuk mewujudkan saran semacam itu. Metode yang paling tidak merusak adalah mendukung dua mesin virtual dan memungkinkan kontrak ditulis di salah satu mesin virtual. Kedua jenis kontrak dapat menggunakan fasilitas yang sama: penyimpanan permanen (SLOAD dan SSTORE), kemampuan untuk memiliki saldo ETH, kemampuan untuk melakukan dan menerima panggilan, dll. Kontrak EVM dan RISC-V dapat saling memanggil secara bebas; dari sudut pandang RISC-V, memanggil kontrak EVM tampaknya merupakan sistem panggilan dengan beberapa parameter khusus; kontrak EVM yang menerima pesan tersebut akan menafsirkannya sebagai CALL.

Dari sudut pandang protokol, pendekatan yang lebih agresif adalah mengonversi kontrak EVM yang ada menjadi kontrak yang memanggil kontrak interpreter EVM yang ditulis dengan RISC-V, yang menjalankan kode EVM yang ada. Artinya, jika kontrak EVM memiliki kode C, dan interpreter EVM berada di alamat X, maka kontrak tersebut akan diganti dengan logika tingkat atas, ketika dipanggil dari luar menggunakan parameter D, memanggil X dengan (C, D), lalu menunggu nilai kembali dan meneruskannya. Jika interpreter EVM itu sendiri memanggil kontrak, meminta untuk menjalankan CALL atau SLOAD/SSTORE, maka kontrak tersebut akan melakukan hal itu.

Jalur tengah adalah menggunakan pilihan kedua, tetapi menciptakan fungsi protokol yang jelas untuk itu - pada dasarnya, menjadikan konsep “interpreter mesin virtual” sebagai pedoman, dan mengharuskan logikanya ditulis dengan RISC-V. EVM akan menjadi yang pertama, tetapi mungkin juga ada yang lain (misalnya, Move bisa menjadi kandidat).

Salah satu keuntungan utama dari proposal kedua dan ketiga adalah bahwa mereka sangat menyederhanakan spesifikasi lapisan eksekusi — pada kenyataannya, ide ini mungkin merupakan satu-satunya pendekatan yang layak, karena bahkan penyederhanaan bertahap seperti menghapus SELFDESTRUCT pun sangat sulit. Tinygrad memiliki aturan ketat bahwa jumlah kode tidak boleh melebihi 10.000 baris; lapisan dasar blockchain yang terbaik seharusnya dapat beradaptasi dengan baik dengan batasan ini, bahkan lebih kecil. Usaha Beam Chain memiliki harapan besar untuk menyederhanakan lapisan konsensus Ethereum secara signifikan. Namun, untuk lapisan eksekusi, perubahan radikal ini mungkin merupakan satu-satunya cara untuk mendapatkan keuntungan serupa.