Teks lengkap proposal lapisan eksekutif L1 jangka panjang Vitalik: mengganti EVM dengan RISC-V

Sumber: Vitalik Buterin

Kompilasi: KarenZ, Berita Pandangan Jauh

Pada tanggal 20 April, Vitalik Buterin mempresentasikan proposal penting pada platform Ethereum Magicians untuk lapisan eksekusi L1 jangka panjang Ethereum. Dia mengusulkan penggantian EVM (Ethereum Virtual Machine) yang ada dengan arsitektur RISC-V sebagai bahasa mesin virtual untuk menulis kontrak pintar, yang bertujuan untuk secara fundamental meningkatkan efisiensi operasional lapisan eksekusi Ethereum, menembus salah satu kemacetan penskalaan utama saat ini, dan sangat menyederhanakan kesederhanaan lapisan eksekusi.

Foresight News telah menyusun teks lengkap proposal untuk membantu pembaca memahami visi teknis ini. Berikut ini adalah kompilasi proposal aslinya:

Makalah ini menyajikan gagasan radikal tentang masa depan lapisan eksekusi Ethereum, tidak kalah ambisius dari inisiatif Beam Chain lapisan konsensus. Proposal ini bertujuan untuk secara dramatis meningkatkan efisiensi lapisan eksekusi Ethereum, mengatasi salah satu kemacetan penskalaan utama, dan secara signifikan menyederhanakan lapisan eksekusi – pada kenyataannya, ini mungkin satu-satunya cara untuk mencapainya.

Ide inti: Ganti EVM dengan RISC-V sebagai bahasa mesin virtual untuk kontrak pintar.

Catatan 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 di Rust, tetapi saya berharap sebagian besar pengembang akan terus menulis kontrak di Solidity (atau Vyper), yang akan beradaptasi dengan RISC-V sebagai backend baru. Karena kontrak pintar yang ditulis di Rust sebenarnya kurang mudah dibaca, sedangkan Solidity dan Vyper lebih jelas dan mudah dibaca. Pengalaman pengembangan mungkin hampir tidak terpengaruh, dan pengembang bahkan mungkin tidak memperhatikan perubahannya.

• Kontrak EVM lama akan terus berjalan dan sepenuhnya kompatibel dua arah dengan kontrak RISC-V baru. Ada beberapa cara untuk melakukan ini, yang akan dibahas lebih rinci nanti di artikel ini.

Nervos CKB VM telah menetapkan preseden dan pada dasarnya merupakan implementasi RISC-V.

Mengapa?

Dalam jangka pendek, EIP yang akan datang (misalnya, daftar akses tingkat blok, eksekusi yang ditangguhkan, penyimpanan riwayat terdistribusi, dan EIP-4444) akan mengatasi kemacetan penskalaan utama Ethereum L1. Lebih banyak masalah akan diselesaikan dalam jangka menengah dengan tanpa kewarganegaraan dan ZK-EVM. Dalam jangka panjang, faktor pembatas utama untuk penskalaan Ethereum L1 akan menjadi:

1. Stabilitas ketersediaan data, pengambilan sampel, dan protokol penyimpanan historis

2. Mempertahankan permintaan persaingan di pasar produksi blok

3. Bukti ZK-EVM

Saya akan berpendapat bahwa mengganti ZK-EVM dengan RISC-V dapat memecahkan kemacetan utama di (2) dan (3).

Tabel berikut menggambarkan jumlah siklus yang diperlukan untuk setiap langkah lapisan eksekusi Succinct ZK-EVM Proof EVM:

Deskripsi diagram: Empat segmen utama yang memakan waktu adalah deserialize_inputs, initialize_witness_db, state_root_computation, dan block_execution

initialize_witness_db dan state_root_computation terkait dengan pohon keadaan, dan deserialize_inputs melibatkan proses konversi data blok dan saksi menjadi representasi internal – lebih dari 50% di antaranya sebenarnya sebanding dengan ukuran data saksi.

Bagian-bagian ini dapat sangat dioptimalkan dengan mengganti pohon patricia Merkle keccak 16 tahun saat ini dengan pohon biner yang menggunakan fungsi hash yang mudah dibuktikan. Jika kita menggunakan Poseidon, kita dapat membuktikan 2 juta hash per detik di laptop (dibandingkan dengan sekitar 15.000 hash/detik untuk keccak). Selain Poseidon, ada banyak pilihan lain. Secara keseluruhan, ada banyak ruang untuk pengoptimalan untuk komponen ini. Selain itu, kita dapat menghilangkan accrue_logs_bloom dengan menghilangkan mekar.

Sisanya block_execution menyumbang sekitar setengah dari siklus pembuktian saat ini. Untuk mencapai peningkatan 100x dalam efisiensi bukti secara keseluruhan, diperlukan efisiensi bukti EVM setidaknya 50x. Salah satu solusinya adalah membuat implementasi bukti yang lebih efisien untuk EVM, dan yang lainnya adalah memperhatikan bahwa pembuktian ZK-EVM saat ini benar-benar mengkompilasi EVM ke RISC-V untuk pembuktian, memberikan pengembang kontrak pintar akses langsung ke mesin virtual RISC-V.

Beberapa data menunjukkan bahwa peningkatan efisiensi lebih dari 100 kali lipat dapat terjadi dalam situasi tertentu:

Dalam praktiknya, waktu pembuktian yang tersisa mungkin sebagian besar ditempati oleh operasi prakompilasi saat ini. Dengan RISC-V sebagai VM utama, jadwal gas akan mencerminkan waktu bukti aktual, dan tekanan ekonomi akan mendorong pengembang untuk mengurangi penggunaan prakompilasi berbiaya tinggi. Meski begitu, keuntungannya tidak akan begitu signifikan, tetapi kami memiliki alasan bagus untuk percaya bahwa itu akan substansial.

(Perlu dicatat bahwa waktu yang dibutuhkan untuk "operasi EVM" dan "operasi lainnya" dalam eksekusi EVM reguler juga mendekati 50/50, jadi kami secara intuitif berasumsi bahwa menghapus EVM sebagai "lapisan perantara" akan membawa keuntungan yang sama signifikannya.)

Detail implementasi

Ada beberapa cara untuk mengimplementasikan proposal ini. Solusi yang paling tidak mengganggu adalah mendukung kedua mesin virtual dan mengizinkan kontrak ditulis di salah satunya. Kedua jenis kontrak memiliki akses ke fitur yang sama: penyimpanan persisten (SLOAD/SSTORE), kemampuan untuk menyimpan saldo ETH, memulai/menerima panggilan, dan banyak lagi. Kontrak EVM dan RISC-V dapat dipanggil satu sama lain - dari perspektif RISC-V, memanggil kontrak EVM setara dengan menjalankan panggilan sistem dengan parameter khusus; Kontrak EVM yang menerima pesan akan menafsirkannya sebagai CALL.

Pendekatan yang lebih radikal dari perspektif protokol adalah mengonversi kontrak EVM yang ada menjadi panggilan ke kontrak penerjemah EVM yang ditulis dalam RISC-V untuk menjalankan kode EVM yang ada. Artinya, jika kontrak EVM memiliki kode C dan penerjemah 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), lalu menunggu nilai pengembalian dan meneruskan. Jika penerjemah EVM sendiri memanggil kontrak, meminta untuk menjalankan CALL atau SLOAD/SSTORE, maka kontrak melakukan operasi ini.

Kompromi adalah opsi kedua, tetapi dengan dukungan eksplisit untuk konsep "penerjemah mesin virtual" melalui protokol yang mengharuskan logikanya ditulis dalam RISC-V. EVM akan menjadi contoh pertama, dengan dukungan untuk bahasa lain di masa depan (Move mungkin menjadi kandidat).

Keuntungan inti dari opsi kedua dan ketiga adalah bahwa mereka sangat menyederhanakan spesifikasi lapisan eksekusi. MENGINGAT KESULITAN BAHKAN MENGHILANGKAN PENYEDERHANAAN INKREMENTAL SEPERTI PENGHANCURAN DIRI, GARIS PEMIKIRAN INI MUNGKIN SATU-SATUNYA JALAN YANG LAYAK UNTUK MENYEDERHANAKAN. Tinygrad mematuhi aturan keras "tidak lebih dari 10.000 baris kode", dan blockchain yang mendasari harus dapat dengan mudah memenuhi batas ini dan merampingkannya lebih jauh. Inisiatif Beam Chain menjanjikan untuk secara dramatis menyederhanakan lapisan konsensus Ethereum, dan perubahan radikal seperti itu mungkin satu-satunya cara untuk mencapai dorongan serupa di lapisan eksekusi.