Pada 20 April, Vitalik Buterin mengajukan sebuah proposal penting mengenai lapisan eksekusi L1 Ethereum di platform Ethereum Magicians. Ia mengusulkan untuk menggunakan arsitektur RISC-V menggantikan EVM (Ethereum Virtual Machine) yang ada sebagai bahasa mesin virtual untuk menulis kontrak pintar, yang bertujuan untuk secara fundamental meningkatkan efisiensi operasi lapisan eksekusi Ethereum, mengatasi salah satu kendala utama dalam perluasan saat ini, sekaligus menyederhanakan kesederhanaan lapisan eksekusi.
Foresight News telah menerjemahkan seluruh proposal ini, bertujuan untuk membantu pembaca memahami gagasan teknologi ini. Berikut adalah isi terjemahan dari teks asli proposal:
Artikel ini mengusulkan ide radikal tentang masa depan lapisan eksekusi Ethereum, yang ambisinya tidak kalah dengan rencana Beam Chain di lapisan konsensus. Proposal ini bertujuan untuk secara signifikan meningkatkan efisiensi lapisan eksekusi Ethereum, mengatasi salah satu bottleneck utama dalam skala, dan secara signifikan menyederhanakan lapisan eksekusi - sebenarnya, ini mungkin satu-satunya cara untuk mencapai tujuan ini.
Gagasan inti: Mengganti EVM dengan RISC-V sebagai bahasa mesin virtual untuk penulisan kontrak pintar.
Pernyataan Penting:
Konsep seperti sistem akun, panggilan lintas kontrak, penyimpanan, dll., Akan dipertahankan sepenuhnya. Desain abstrak ini bekerja dengan baik dan pengembang terbiasa menggunakannya. Opcode seperti SLOAD, SSTORE, BALANCE, CALL, dll., Diubah menjadi panggilan sistem RISC-V.
Dalam mode ini, kontrak pintar dapat ditulis dengan Rust, tetapi saya memperkirakan sebagian besar pengembang masih akan terus menggunakan Solidity (atau Vyper) untuk menulis kontrak, karena bahasa-bahasa ini akan disesuaikan dengan RISC-V sebagai backend baru. Karena kontrak pintar yang ditulis dengan Rust sebenarnya memiliki keterbacaan yang lebih buruk, sementara Solidity dan Vyper lebih jelas dan mudah dibaca. Pengalaman pengembangan mungkin hampir tidak terpengaruh, pengembang bahkan mungkin tidak menyadari perubahannya.
Kontrak EVM versi lama akan tetap berjalan dan sepenuhnya kompatibel dua arah dengan kontrak RISC-V versi baru. Ada beberapa cara untuk mewujudkannya, yang akan dibahas secara rinci dalam artikel ini.
Nervos CKB VM telah menciptakan preseden, pada dasarnya merupakan implementasi RISC-V.
Mengapa melakukan ini?
Dalam jangka pendek, EIP yang akan segera diterapkan (seperti daftar akses tingkat blok, eksekusi tertunda, penyimpanan sejarah terdistribusi, dan EIP-4444) dapat mengatasi hambatan utama skalabilitas Ethereum L1. Dalam jangka menengah, lebih banyak masalah akan diatasi melalui statelessness dan ZK-EVM. Dalam jangka panjang, faktor pembatas utama untuk skalabilitas Ethereum L1 akan berubah menjadi:
Stabilitas sampling ketersediaan data dan protokol penyimpanan historis
Permintaan untuk menjaga kompetisi di pasar produksi blok
Kemampuan bukti ZK-EVM
Saya akan membuktikan bahwa mengganti ZK-EVM dengan RISC-V dapat mengatasi bottleneck kunci dalam (2) dan (3).
Tabel di bawah menunjukkan jumlah siklus yang diperlukan oleh Succinct ZK-EVM untuk setiap tahap di lapisan eksekusi EVM:
Penjelasan grafik: Empat tahap yang memakan waktu utama adalah deserialize_inputs, initialize_witness_db, state_root_computation, dan block_execution
Di mana initialize_witness_db dan state_root_computation terkait dengan pohon status, deserialize_inputs melibatkan proses mengubah data blok dan saksi menjadi representasi internal—secara nyata lebih dari 50% sebanding dengan ukuran data saksi.
Dengan mengganti pohon Merkle patricia 16-ary keccak saat ini dengan pohon biner yang menggunakan fungsi hash yang mudah dibuktikan, bagian-bagian ini dapat dioptimalkan secara signifikan. Jika menggunakan Poseidon, kita dapat membuktikan 2 juta nilai hash per detik di laptop (sebagai perbandingan, keccak sekitar 15.000 hash/detik). Selain Poseidon, ada banyak pilihan lain. Secara keseluruhan, komponen-komponen ini memiliki banyak ruang untuk dioptimalkan. Selain itu, kita dapat menghilangkan bloom untuk menghapus accrue_logs_bloom.
Sisa block_execution sekitar setengah dari siklus pembuktian saat ini (prover cycles). Untuk mencapai peningkatan efisiensi pembuktian keseluruhan sebesar 100 kali, efisiensi pembuktian EVM perlu ditingkatkan setidaknya 50 kali. Salah satu solusi adalah menciptakan implementasi pembuktian yang lebih efisien untuk EVM, solusi lainnya adalah menyadari bahwa pembuktian ZK-EVM saat ini sebenarnya dilakukan dengan mengompilasi EVM menjadi RISC-V, yang memungkinkan pengembang kontrak pintar untuk mengakses mesin virtual RISC-V tersebut secara langsung.
Beberapa data menunjukkan bahwa dalam kondisi tertentu, peningkatan efisiensi dapat melebihi 100 kali.
Dalam aplikasi nyata, sisa waktu prover mungkin terutama diduduki oleh operasi precompiled (precompiles) saat ini. Jika RISC-V digunakan sebagai mesin virtual utama, jadwal Gas akan mencerminkan waktu pembuktian yang sebenarnya, dan tekanan ekonomi akan mendorong pengembang untuk mengurangi penggunaan precompiled yang mahal. Meskipun demikian, peningkatannya tidak akan begitu signifikan, tetapi kami memiliki alasan yang cukup untuk percaya bahwa peningkatan ini akan sangat substansial.
(Perlu dicatat bahwa dalam eksekusi EVM reguler, proporsi waktu yang dihabiskan untuk "operasi EVM" dan "operasi lainnya" juga mendekati 50/50, sehingga secara intuitif kami percaya bahwa menghapus EVM sebagai "lapisan perantara" akan membawa peningkatan yang signifikan yang setara.)
Detail pelaksanaan
Usulan ini memiliki berbagai cara implementasi. Solusi yang paling tidak merusak adalah dengan mendukung dua mesin virtual secara bersamaan, memungkinkan kontrak untuk menulis di salah satu darinya. Kedua jenis kontrak dapat mengakses fungsi yang sama: penyimpanan permanen (SLOAD/SSTORE), kemampuan untuk menyimpan saldo ETH, memulai/menerima panggilan, dan lain-lain. Kontrak EVM dan RISC-V dapat saling memanggil—dari sudut pandang RISC-V, memanggil kontrak EVM setara dengan menjalankan panggilan sistem dengan parameter khusus; sementara kontrak EVM yang menerima pesan akan menafsirkannya sebagai CALL.
Pendekatan yang lebih radikal dari perspektif protokol adalah mengubah kontrak EVM yang ada menjadi kontrak interpreter EVM yang ditulis dalam RISC-V untuk menjalankan kode EVM yang ada. Artinya, jika kontrak EVM memiliki kode C dan interpreter EVM berada di alamat X, maka kontrak akan diganti dengan logika tingkat atas yang, ketika dipanggil dari luar dengan argumen panggilan D, memanggil X dan meneruskan (C, D), dan kemudian menunggu nilai pengembalian dan meneruskan. Jika penerjemah EVM itu sendiri memanggil kontrak, meminta untuk menjalankan CALL atau SLOAD / SSTORE, maka kontrak melakukan operasi ini.
Solusi kompromi adalah menggunakan rencana kedua, tetapi dengan jelas mendukung konsep "interpreter mesin virtual" melalui perjanjian, yang mengharuskan logikanya ditulis dengan RISC-V. EVM akan menjadi contoh pertama, dan di masa depan juga dapat mendukung bahasa lain (Move mungkin menjadi kandidat).
Keuntungan inti dari opsi kedua dan ketiga adalah bahwa mereka sangat menyederhanakan spesifikasi lapisan eksekusi. MENGINGAT SULITNYA BAHKAN MENGHAPUS PENYEDERHANAAN TAMBAHAN SEPERTI PENGHANCURAN DIRI, GARIS PEMIKIRAN INI MUNGKIN SATU-SATUNYA JALAN YANG LAYAK UNTUK DISEDERHANAKAN. Tinygrad mematuhi aturan keras dan cepat "tidak lebih dari 10.000 baris kode", dan blockchain dasar yang optimal harus dapat dengan mudah memenuhi batas ini dan lebih disederhanakan. Inisiatif Beam Chain berjanji untuk secara dramatis menyederhanakan lapisan konsensus Ethereum, dan perubahan radikal semacam itu mungkin satu-satunya cara untuk mencapai dorongan serupa pada lapisan eksekusi.
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
Vitalik usulan lengkap lapisan eksekusi L1 jangka panjang: mengganti EVM dengan RISC-V
Sumber: Vitalik Buterin
Kompilasi: KarenZ, Berita Foresight
Pada 20 April, Vitalik Buterin mengajukan sebuah proposal penting mengenai lapisan eksekusi L1 Ethereum di platform Ethereum Magicians. Ia mengusulkan untuk menggunakan arsitektur RISC-V menggantikan EVM (Ethereum Virtual Machine) yang ada sebagai bahasa mesin virtual untuk menulis kontrak pintar, yang bertujuan untuk secara fundamental meningkatkan efisiensi operasi lapisan eksekusi Ethereum, mengatasi salah satu kendala utama dalam perluasan saat ini, sekaligus menyederhanakan kesederhanaan lapisan eksekusi.
Foresight News telah menerjemahkan seluruh proposal ini, bertujuan untuk membantu pembaca memahami gagasan teknologi ini. Berikut adalah isi terjemahan dari teks asli proposal:
Artikel ini mengusulkan ide radikal tentang masa depan lapisan eksekusi Ethereum, yang ambisinya tidak kalah dengan rencana Beam Chain di lapisan konsensus. Proposal ini bertujuan untuk secara signifikan meningkatkan efisiensi lapisan eksekusi Ethereum, mengatasi salah satu bottleneck utama dalam skala, dan secara signifikan menyederhanakan lapisan eksekusi - sebenarnya, ini mungkin satu-satunya cara untuk mencapai tujuan ini.
Gagasan inti: Mengganti EVM dengan RISC-V sebagai bahasa mesin virtual untuk penulisan kontrak pintar.
Pernyataan Penting:
Konsep seperti sistem akun, panggilan lintas kontrak, penyimpanan, dll., Akan dipertahankan sepenuhnya. Desain abstrak ini bekerja dengan baik dan pengembang terbiasa menggunakannya. Opcode seperti SLOAD, SSTORE, BALANCE, CALL, dll., Diubah menjadi panggilan sistem RISC-V.
Dalam mode ini, kontrak pintar dapat ditulis dengan Rust, tetapi saya memperkirakan sebagian besar pengembang masih akan terus menggunakan Solidity (atau Vyper) untuk menulis kontrak, karena bahasa-bahasa ini akan disesuaikan dengan RISC-V sebagai backend baru. Karena kontrak pintar yang ditulis dengan Rust sebenarnya memiliki keterbacaan yang lebih buruk, sementara Solidity dan Vyper lebih jelas dan mudah dibaca. Pengalaman pengembangan mungkin hampir tidak terpengaruh, pengembang bahkan mungkin tidak menyadari perubahannya.
Kontrak EVM versi lama akan tetap berjalan dan sepenuhnya kompatibel dua arah dengan kontrak RISC-V versi baru. Ada beberapa cara untuk mewujudkannya, yang akan dibahas secara rinci dalam artikel ini.
Nervos CKB VM telah menciptakan preseden, pada dasarnya merupakan implementasi RISC-V.
Mengapa melakukan ini?
Dalam jangka pendek, EIP yang akan segera diterapkan (seperti daftar akses tingkat blok, eksekusi tertunda, penyimpanan sejarah terdistribusi, dan EIP-4444) dapat mengatasi hambatan utama skalabilitas Ethereum L1. Dalam jangka menengah, lebih banyak masalah akan diatasi melalui statelessness dan ZK-EVM. Dalam jangka panjang, faktor pembatas utama untuk skalabilitas Ethereum L1 akan berubah menjadi:
Stabilitas sampling ketersediaan data dan protokol penyimpanan historis
Permintaan untuk menjaga kompetisi di pasar produksi blok
Kemampuan bukti ZK-EVM
Saya akan membuktikan bahwa mengganti ZK-EVM dengan RISC-V dapat mengatasi bottleneck kunci dalam (2) dan (3).
Tabel di bawah menunjukkan jumlah siklus yang diperlukan oleh Succinct ZK-EVM untuk setiap tahap di lapisan eksekusi EVM:
Penjelasan grafik: Empat tahap yang memakan waktu utama adalah deserialize_inputs, initialize_witness_db, state_root_computation, dan block_execution
Di mana initialize_witness_db dan state_root_computation terkait dengan pohon status, deserialize_inputs melibatkan proses mengubah data blok dan saksi menjadi representasi internal—secara nyata lebih dari 50% sebanding dengan ukuran data saksi.
Dengan mengganti pohon Merkle patricia 16-ary keccak saat ini dengan pohon biner yang menggunakan fungsi hash yang mudah dibuktikan, bagian-bagian ini dapat dioptimalkan secara signifikan. Jika menggunakan Poseidon, kita dapat membuktikan 2 juta nilai hash per detik di laptop (sebagai perbandingan, keccak sekitar 15.000 hash/detik). Selain Poseidon, ada banyak pilihan lain. Secara keseluruhan, komponen-komponen ini memiliki banyak ruang untuk dioptimalkan. Selain itu, kita dapat menghilangkan bloom untuk menghapus accrue_logs_bloom.
Sisa block_execution sekitar setengah dari siklus pembuktian saat ini (prover cycles). Untuk mencapai peningkatan efisiensi pembuktian keseluruhan sebesar 100 kali, efisiensi pembuktian EVM perlu ditingkatkan setidaknya 50 kali. Salah satu solusi adalah menciptakan implementasi pembuktian yang lebih efisien untuk EVM, solusi lainnya adalah menyadari bahwa pembuktian ZK-EVM saat ini sebenarnya dilakukan dengan mengompilasi EVM menjadi RISC-V, yang memungkinkan pengembang kontrak pintar untuk mengakses mesin virtual RISC-V tersebut secara langsung.
Beberapa data menunjukkan bahwa dalam kondisi tertentu, peningkatan efisiensi dapat melebihi 100 kali.
Dalam aplikasi nyata, sisa waktu prover mungkin terutama diduduki oleh operasi precompiled (precompiles) saat ini. Jika RISC-V digunakan sebagai mesin virtual utama, jadwal Gas akan mencerminkan waktu pembuktian yang sebenarnya, dan tekanan ekonomi akan mendorong pengembang untuk mengurangi penggunaan precompiled yang mahal. Meskipun demikian, peningkatannya tidak akan begitu signifikan, tetapi kami memiliki alasan yang cukup untuk percaya bahwa peningkatan ini akan sangat substansial.
(Perlu dicatat bahwa dalam eksekusi EVM reguler, proporsi waktu yang dihabiskan untuk "operasi EVM" dan "operasi lainnya" juga mendekati 50/50, sehingga secara intuitif kami percaya bahwa menghapus EVM sebagai "lapisan perantara" akan membawa peningkatan yang signifikan yang setara.)
Detail pelaksanaan
Usulan ini memiliki berbagai cara implementasi. Solusi yang paling tidak merusak adalah dengan mendukung dua mesin virtual secara bersamaan, memungkinkan kontrak untuk menulis di salah satu darinya. Kedua jenis kontrak dapat mengakses fungsi yang sama: penyimpanan permanen (SLOAD/SSTORE), kemampuan untuk menyimpan saldo ETH, memulai/menerima panggilan, dan lain-lain. Kontrak EVM dan RISC-V dapat saling memanggil—dari sudut pandang RISC-V, memanggil kontrak EVM setara dengan menjalankan panggilan sistem dengan parameter khusus; sementara kontrak EVM yang menerima pesan akan menafsirkannya sebagai CALL.
Pendekatan yang lebih radikal dari perspektif protokol adalah mengubah kontrak EVM yang ada menjadi kontrak interpreter EVM yang ditulis dalam RISC-V untuk menjalankan kode EVM yang ada. Artinya, jika kontrak EVM memiliki kode C dan interpreter EVM berada di alamat X, maka kontrak akan diganti dengan logika tingkat atas yang, ketika dipanggil dari luar dengan argumen panggilan D, memanggil X dan meneruskan (C, D), dan kemudian menunggu nilai pengembalian dan meneruskan. Jika penerjemah EVM itu sendiri memanggil kontrak, meminta untuk menjalankan CALL atau SLOAD / SSTORE, maka kontrak melakukan operasi ini.
Solusi kompromi adalah menggunakan rencana kedua, tetapi dengan jelas mendukung konsep "interpreter mesin virtual" melalui perjanjian, yang mengharuskan logikanya ditulis dengan RISC-V. EVM akan menjadi contoh pertama, dan di masa depan juga dapat mendukung bahasa lain (Move mungkin menjadi kandidat).
Keuntungan inti dari opsi kedua dan ketiga adalah bahwa mereka sangat menyederhanakan spesifikasi lapisan eksekusi. MENGINGAT SULITNYA BAHKAN MENGHAPUS PENYEDERHANAAN TAMBAHAN SEPERTI PENGHANCURAN DIRI, GARIS PEMIKIRAN INI MUNGKIN SATU-SATUNYA JALAN YANG LAYAK UNTUK DISEDERHANAKAN. Tinygrad mematuhi aturan keras dan cepat "tidak lebih dari 10.000 baris kode", dan blockchain dasar yang optimal harus dapat dengan mudah memenuhi batas ini dan lebih disederhanakan. Inisiatif Beam Chain berjanji untuk secara dramatis menyederhanakan lapisan konsensus Ethereum, dan perubahan radikal semacam itu mungkin satu-satunya cara untuk mencapai dorongan serupa pada lapisan eksekusi.