Artikel ini mengajukan sebuah ide radikal tentang masa depan lapisan eksekusi Ethereum, dengan ambisi yang sebanding dengan upaya beacon chain di lapisan konsensus. Ini bertujuan untuk secara signifikan meningkatkan efisiensi lapisan eksekusi Ethereum, mengatasi salah satu hambatan skala utama, sambil juga secara signifikan menyederhanakan lapisan eksekusi—sebenarnya, ini mungkin adalah satu-satunya cara untuk mencapai penyederhanaan.
Ide inti: mengganti EVM dengan RISC-V sebagai bahasa mesin virtual untuk menulis kontrak pintar.
Pernyataan Penting:
Konsep seperti akun, panggilan lintas kontrak, dan penyimpanan tetap tidak berubah. Konsep abstrak ini berjalan dengan baik, dan para pengembang juga sudah terbiasa. Opcode seperti SLOAD, SSTORE, BALANCE, CALL akan berubah menjadi syscalls RISC-V.
Dalam kasus ini, smart contracts dapat ditulis dalam Rust, tetapi saya memperkirakan sebagian besar pengembang masih akan terus menggunakan Solidity (atau Vyper), bahasa-bahasa ini akan disesuaikan dengan RISC-V sebagai backend. Ini karena kode smart contracts yang ditulis dalam Rust sering kali kurang menarik, sementara Solidity dan Vyper lebih mudah dibaca. Potensial, perubahan pengalaman pengembang (devex) mungkin sangat kecil, pengembang bahkan mungkin hampir tidak menyadari perubahannya.
Kontrak EVM lama akan terus berjalan dan akan mewujudkan interoperabilitas dua arah yang lengkap dengan kontrak RISC-V baru. Ada beberapa cara untuk mengimplementasikannya, yang akan saya uraikan lebih lanjut di bagian berikut.
Salah satu contohnya adalah Nervos CKB VM, yang pada dasarnya didasarkan pada RISC-V.
Mengapa harus melakukan ini?
Dalam jangka pendek, hambatan utama skalabilitas Ethereum L1 akan diatasi melalui EIP yang akan datang, seperti daftar akses tingkat blok, eksekusi tertunda, penyimpanan riwayat terdistribusi, serta EIP-4444. Dalam jangka menengah, kami akan menyelesaikan masalah lebih lanjut melalui ketidakberadaan status dan ZK-EVM. Dalam jangka panjang, faktor pembatas utama dari penskalaan Ethereum L1 adalah:
Stabilitas pengambilan sampel ketersediaan data (data availability sampling) dan protokol penyimpanan sejarah (history storage protocols).
Menjaga produksi block sebagai keinginan pasar yang kompetitif.
Kemampuan pembuktian ZK-EVM.
Saya akan membuktikan bahwa mengganti ZK-EVM dengan RISC-V dapat menyelesaikan hambatan kunci dalam (2) dan (3).
Berikut adalah tabel jumlah siklus yang diperlukan oleh Succinct ZK-EVM untuk membuktikan bagian yang berbeda dari lapisan eksekusi EVM:
Di antara keempat bagian ini, yang paling memakan waktu adalah: 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 mengacu pada proses mengubah data block dan witness menjadi representasi internal. Oleh karena itu, sebenarnya lebih dari 50% waktu yang dihabiskan sebanding dengan ukuran witness.
Dengan mengganti pohon Merkle Patricia keccak 16-ary saat ini dengan pohon biner yang menggunakan fungsi hash yang ramah prover, bagian-bagian ini dapat dioptimalkan secara signifikan. Jika menggunakan Poseidon, kita dapat membuktikan 2 juta hash per detik di laptop (sebagai perbandingan, keccak hanya sekitar 15.000 hash/detik). Selain Poseidon, ada banyak pilihan lainnya. Secara keseluruhan, komponen-komponen ini memiliki banyak ruang untuk dioptimalkan. Sebagai keuntungan tambahan, kita dapat menghilangkan accrue_logs_bloom dengan menghapus bloom.
Ini meninggalkan blok _execution, yang saat ini menyumbang sekitar setengah dari siklus prover. Jika kita ingin meningkatkan efisiensi prover total hingga 100 kali lipat, kita harus meningkatkan efisiensi prover EVM setidaknya 50 kali lipat. Kita dapat mencoba membuat implementasi EVM yang lebih efisien untuk mengurangi siklus prover. Pendekatan lain adalah untuk dicatat bahwa prover ZK-EVM saat ini telah terbukti dengan mengkompilasi EVM ke RISC-V, sehingga dimungkinkan untuk secara langsung memungkinkan pengembang kontrak pintar untuk menggunakan VM RISC-V.
Beberapa data menunjukkan bahwa dalam kondisi tertentu, ini dapat memberikan peningkatan efisiensi lebih dari 100 kali lipat:
Dalam praktiknya, saya berharap bahwa waktu prover yang tersisa akan didominasi oleh prakompilasi hari ini. Jika kita memiliki RISC-V sebagai VM utama, maka jadwal gas akan mencerminkan waktu pembuktian, sehingga akan ada tekanan finansial pada pengembang untuk berhenti menggunakan prakompilasi yang lebih mahal. Namun, keuntungan efisiensi mungkin tidak sedramatis yang disarankan data, tetapi ada alasan bagus untuk percaya bahwa mereka akan signifikan.
(Sekadar informasi, proporsi EVM dan "bagian lain" masing-masing sekitar 50% juga muncul dalam eksekusi EVM biasa, secara intuitif kami berharap peningkatan yang dihasilkan dari menghapus EVM sebagai "perantara" juga akan sangat besar.)
Detail implementasi
Ada berbagai cara untuk merealisasikan proposal ini. Berikut adalah beberapa metode yang mungkin:
Cara paling tidak merusak: mendukung dua jenis VM, memungkinkan kontrak ditulis dengan salah satu VM. Kedua kontrak dapat mengakses fungsi yang sama: penyimpanan yang persisten (SLOAD dan SSTORE), memiliki saldo ETH, melakukan dan menerima panggilan, dll. Kontrak EVM dan RISC-V dapat saling memanggil dengan bebas; dari sudut pandang RISC-V, memanggil kontrak EVM seperti menjalankan syscall dengan parameter khusus; kontrak EVM yang menerima pesan akan menginterpretasikannya sebagai CALL.
Metode yang lebih radikal: mengonversi kontrak EVM yang ada menjadi kontrak interpreter EVM yang ditulis dengan RISC-V, untuk menjalankan kode EVM yang ada. Artinya, jika sebuah 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 dengan parameter panggilan D, ia akan memanggil X dengan (C, D), lalu menunggu nilai kembali dan meneruskan. Jika interpreter EVM itu sendiri memanggil kontrak tersebut, meminta untuk menjalankan CALL atau SLOAD/SSTORE, maka kontrak akan melakukan operasi yang sesuai.
Jalur tengah: Menggunakan cara kedua, tetapi menciptakan karakteristik protokol yang jelas—pada dasarnya menulis konsep "interpreter mesin virtual" ke dalam protokol dan mengharuskan logikanya ditulis dengan RISC-V. EVM akan menjadi interpreter pertama, tetapi bisa ada interpreter lain (misalnya, Move mungkin menjadi kandidat).
MANFAAT UTAMA DARI PROPOSAL KEDUA DAN KETIGA ADALAH BAHWA MEREKA SANGAT MENYEDERHANAKAN SPESIFIKASI LAPISAN EKSEKUSI - PADA KENYATAANNYA, PENDEKATAN INI MUNGKIN SATU-SATUNYA CARA PRAKTIS UNTUK MENCAPAI PENYEDERHANAAN, MENGINGAT KESULITAN PENYEDERHANAAN BAHKAN INKREMENTAL SEPERTI MENGHAPUS PENGHANCURAN DIRI. Tinygrad memiliki aturan keras dan cepat: kode tidak pernah melebihi 10.000 baris; Lapisan dasar blockchain yang dioptimalkan harus dapat dengan mudah beradaptasi dengan keterbatasan ini, jika tidak kurang. Upaya rantai suar sangat menjanjikan untuk menyederhanakan lapisan konsensus Ethereum. Tetapi bagi lapisan eksekutif untuk mencapai penyederhanaan serupa, perubahan radikal ini mungkin satu-satunya jalan yang layak.
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
Proposal terbaru dari V神: mengganti EVM dengan RISC-V sebagai lapisan eksekusi L1 jangka panjang Ethereum
Penulis asli: Vitalik Buterin
Terjemahan asli: Luke, Mars Finance
Artikel ini mengajukan sebuah ide radikal tentang masa depan lapisan eksekusi Ethereum, dengan ambisi yang sebanding dengan upaya beacon chain di lapisan konsensus. Ini bertujuan untuk secara signifikan meningkatkan efisiensi lapisan eksekusi Ethereum, mengatasi salah satu hambatan skala utama, sambil juga secara signifikan menyederhanakan lapisan eksekusi—sebenarnya, ini mungkin adalah satu-satunya cara untuk mencapai penyederhanaan.
Ide inti: mengganti EVM dengan RISC-V sebagai bahasa mesin virtual untuk menulis kontrak pintar.
Pernyataan Penting:
Konsep seperti akun, panggilan lintas kontrak, dan penyimpanan tetap tidak berubah. Konsep abstrak ini berjalan dengan baik, dan para pengembang juga sudah terbiasa. Opcode seperti SLOAD, SSTORE, BALANCE, CALL akan berubah menjadi syscalls RISC-V.
Dalam kasus ini, smart contracts dapat ditulis dalam Rust, tetapi saya memperkirakan sebagian besar pengembang masih akan terus menggunakan Solidity (atau Vyper), bahasa-bahasa ini akan disesuaikan dengan RISC-V sebagai backend. Ini karena kode smart contracts yang ditulis dalam Rust sering kali kurang menarik, sementara Solidity dan Vyper lebih mudah dibaca. Potensial, perubahan pengalaman pengembang (devex) mungkin sangat kecil, pengembang bahkan mungkin hampir tidak menyadari perubahannya.
Kontrak EVM lama akan terus berjalan dan akan mewujudkan interoperabilitas dua arah yang lengkap dengan kontrak RISC-V baru. Ada beberapa cara untuk mengimplementasikannya, yang akan saya uraikan lebih lanjut di bagian berikut.
Salah satu contohnya adalah Nervos CKB VM, yang pada dasarnya didasarkan pada RISC-V.
Mengapa harus melakukan ini?
Dalam jangka pendek, hambatan utama skalabilitas Ethereum L1 akan diatasi melalui EIP yang akan datang, seperti daftar akses tingkat blok, eksekusi tertunda, penyimpanan riwayat terdistribusi, serta EIP-4444. Dalam jangka menengah, kami akan menyelesaikan masalah lebih lanjut melalui ketidakberadaan status dan ZK-EVM. Dalam jangka panjang, faktor pembatas utama dari penskalaan Ethereum L1 adalah:
Stabilitas pengambilan sampel ketersediaan data (data availability sampling) dan protokol penyimpanan sejarah (history storage protocols).
Menjaga produksi block sebagai keinginan pasar yang kompetitif.
Kemampuan pembuktian ZK-EVM.
Saya akan membuktikan bahwa mengganti ZK-EVM dengan RISC-V dapat menyelesaikan hambatan kunci dalam (2) dan (3).
Berikut adalah tabel jumlah siklus yang diperlukan oleh Succinct ZK-EVM untuk membuktikan bagian yang berbeda dari lapisan eksekusi EVM:
Di antara keempat bagian ini, yang paling memakan waktu adalah: 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 mengacu pada proses mengubah data block dan witness menjadi representasi internal. Oleh karena itu, sebenarnya lebih dari 50% waktu yang dihabiskan sebanding dengan ukuran witness.
Dengan mengganti pohon Merkle Patricia keccak 16-ary saat ini dengan pohon biner yang menggunakan fungsi hash yang ramah prover, bagian-bagian ini dapat dioptimalkan secara signifikan. Jika menggunakan Poseidon, kita dapat membuktikan 2 juta hash per detik di laptop (sebagai perbandingan, keccak hanya sekitar 15.000 hash/detik). Selain Poseidon, ada banyak pilihan lainnya. Secara keseluruhan, komponen-komponen ini memiliki banyak ruang untuk dioptimalkan. Sebagai keuntungan tambahan, kita dapat menghilangkan accrue_logs_bloom dengan menghapus bloom.
Ini meninggalkan blok _execution, yang saat ini menyumbang sekitar setengah dari siklus prover. Jika kita ingin meningkatkan efisiensi prover total hingga 100 kali lipat, kita harus meningkatkan efisiensi prover EVM setidaknya 50 kali lipat. Kita dapat mencoba membuat implementasi EVM yang lebih efisien untuk mengurangi siklus prover. Pendekatan lain adalah untuk dicatat bahwa prover ZK-EVM saat ini telah terbukti dengan mengkompilasi EVM ke RISC-V, sehingga dimungkinkan untuk secara langsung memungkinkan pengembang kontrak pintar untuk menggunakan VM RISC-V.
Beberapa data menunjukkan bahwa dalam kondisi tertentu, ini dapat memberikan peningkatan efisiensi lebih dari 100 kali lipat:
Dalam praktiknya, saya berharap bahwa waktu prover yang tersisa akan didominasi oleh prakompilasi hari ini. Jika kita memiliki RISC-V sebagai VM utama, maka jadwal gas akan mencerminkan waktu pembuktian, sehingga akan ada tekanan finansial pada pengembang untuk berhenti menggunakan prakompilasi yang lebih mahal. Namun, keuntungan efisiensi mungkin tidak sedramatis yang disarankan data, tetapi ada alasan bagus untuk percaya bahwa mereka akan signifikan.
(Sekadar informasi, proporsi EVM dan "bagian lain" masing-masing sekitar 50% juga muncul dalam eksekusi EVM biasa, secara intuitif kami berharap peningkatan yang dihasilkan dari menghapus EVM sebagai "perantara" juga akan sangat besar.)
Detail implementasi
Ada berbagai cara untuk merealisasikan proposal ini. Berikut adalah beberapa metode yang mungkin:
Cara paling tidak merusak: mendukung dua jenis VM, memungkinkan kontrak ditulis dengan salah satu VM. Kedua kontrak dapat mengakses fungsi yang sama: penyimpanan yang persisten (SLOAD dan SSTORE), memiliki saldo ETH, melakukan dan menerima panggilan, dll. Kontrak EVM dan RISC-V dapat saling memanggil dengan bebas; dari sudut pandang RISC-V, memanggil kontrak EVM seperti menjalankan syscall dengan parameter khusus; kontrak EVM yang menerima pesan akan menginterpretasikannya sebagai CALL.
Metode yang lebih radikal: mengonversi kontrak EVM yang ada menjadi kontrak interpreter EVM yang ditulis dengan RISC-V, untuk menjalankan kode EVM yang ada. Artinya, jika sebuah 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 dengan parameter panggilan D, ia akan memanggil X dengan (C, D), lalu menunggu nilai kembali dan meneruskan. Jika interpreter EVM itu sendiri memanggil kontrak tersebut, meminta untuk menjalankan CALL atau SLOAD/SSTORE, maka kontrak akan melakukan operasi yang sesuai.
Jalur tengah: Menggunakan cara kedua, tetapi menciptakan karakteristik protokol yang jelas—pada dasarnya menulis konsep "interpreter mesin virtual" ke dalam protokol dan mengharuskan logikanya ditulis dengan RISC-V. EVM akan menjadi interpreter pertama, tetapi bisa ada interpreter lain (misalnya, Move mungkin menjadi kandidat).
MANFAAT UTAMA DARI PROPOSAL KEDUA DAN KETIGA ADALAH BAHWA MEREKA SANGAT MENYEDERHANAKAN SPESIFIKASI LAPISAN EKSEKUSI - PADA KENYATAANNYA, PENDEKATAN INI MUNGKIN SATU-SATUNYA CARA PRAKTIS UNTUK MENCAPAI PENYEDERHANAAN, MENGINGAT KESULITAN PENYEDERHANAAN BAHKAN INKREMENTAL SEPERTI MENGHAPUS PENGHANCURAN DIRI. Tinygrad memiliki aturan keras dan cepat: kode tidak pernah melebihi 10.000 baris; Lapisan dasar blockchain yang dioptimalkan harus dapat dengan mudah beradaptasi dengan keterbatasan ini, jika tidak kurang. Upaya rantai suar sangat menjanjikan untuk menyederhanakan lapisan konsensus Ethereum. Tetapi bagi lapisan eksekutif untuk mencapai penyederhanaan serupa, perubahan radikal ini mungkin satu-satunya jalan yang layak.