Artikel ini berasal dari: Ethereum developer levochka.eth
Kompilasi｜Odaily Planet Daily（@OdailyChina）；Penerjemah｜Azuma（@azuma_eth）
Editor catatan:
Kemarin, salah satu pendiri Ethereum, Vitalik, menerbitkan artikel radikal tentang peningkatan lapisan eksekusi Ethereum (lihat “Artikel Baru Radikal Vitalik: Ekspansi Lapisan Eksekusi ‘Tidak Ada yang Dihancurkan, Tidak Ada yang Dibangun’, EVM di Masa Depan Harus Diiterasi”), di mana ia menyebutkan harapannya untuk mengganti EVM dengan RISC-V sebagai bahasa mesin virtual untuk kontrak pintar.
Setelah artikel ini dirilis, segera memicu kontroversi besar di komunitas pengembang Ethereum, di mana beberapa tokoh teknis menyatakan pandangan yang berbeda tentang proposal tersebut. Tak lama setelah artikel diterbitkan, pengembang Ethereum terkemuka levochka.eth menulis artikel panjang di bawah tulisan asli yang membantah pandangan Vitalik, dengan menyatakan bahwa Vitalik telah melakukan asumsi dasar yang salah tentang sistem bukti dan kinerjanya, RISC-V mungkin tidak dapat mengakomodasi “skala” dan “pemeliharaan”, mungkin bukan pilihan terbaik.
Berikut adalah konten asli levochka.eth, yang diterjemahkan oleh Odaily Xingqiu Ribao.
Tolong jangan lakukan itu.
Rencana ini tidak masuk akal karena Anda telah membuat asumsi yang salah tentang sistem bukti dan kinerjanya.
Menguji Hipotesis
Menurut pemahaman saya, argumen utama dari rencana ini adalah “skala” (scalability) dan “pemeliharaan” (maintainability).
Pertama, saya ingin membahas tentang pemeliharaan.
Sebenarnya, semua RISC-V zk-VM perlu menggunakan “precompiles” untuk menangani operasi yang memerlukan komputasi intensif. Daftar precompile SP 1 dapat dilihat di dokumentasi Succinct, dan Anda akan menemukan bahwa itu hampir mencakup semua opcode “kalkulatif” penting dalam EVM.
Oleh karena itu, semua modifikasi terhadap primitif kriptografi lapisan dasar perlu ditulis dan diaudit “sirkuit” baru untuk pra-kompilasi ini, yang merupakan pembatasan serius.
Memang, jika kinerjanya cukup baik, pemeliharaan bagian “non EVM” dalam klien eksekusi mungkin akan relatif mudah. Saya tidak yakin apakah kinerjanya akan cukup baik, tetapi saya kurang percaya diri tentang bagian ini, alasannya sebagai berikut:
- “perhitungan pohon status” (state tree computation) memang dapat dipercepat secara signifikan melalui pra-kompilasi ramah (seperti Poseidon).
- Namun, tidak jelas apakah “deserialization” dapat ditangani dengan cara yang elegan dan dapat dipelihara.
- Selain itu, ada beberapa rincian rumit (seperti pengukuran Gas dan berbagai pemeriksaan), yang mungkin termasuk dalam “waktu penilaian blok”, tetapi sebenarnya lebih tepat diklasifikasikan sebagai bagian “non-EVM”, dan bagian-bagian ini seringkali lebih rentan terhadap tekanan pemeliharaan.
Kedua, mengenai bagian skalabilitas.
Saya perlu menegaskan satu hal, RISC-V tidak mungkin menangani beban EVM tanpa menggunakan prekompilasi, sama sekali tidak mungkin.
Jadi, pernyataan dalam teks asli bahwa “waktu pembuktian akhir akan terutama dipimpin oleh operasi pra-kompilasi saat ini” meskipun secara teknis benar, terlalu optimis — itu mengasumsikan bahwa tidak akan ada pra-kompilasi di masa depan, padahal sebenarnya (dalam skenario masa depan ini), pra-kompilasi akan tetap ada, dan sepenuhnya konsisten dengan opcode yang memerlukan komputasi intensif di EVM (seperti tanda tangan, hash, dan kemungkinan operasi numerik besar lainnya).
Mengenai contoh “Fibonacci”, sulit untuk membuat penilaian tanpa menyelami detail yang sangat mendalam, tetapi keunggulannya setidaknya sebagian berasal dari:
- Perbedaan antara “Interpreter” (Interpretasi) dan “execution overhead” (biaya eksekusi);
- Ekspansi loop (mengurangi “aliran kontrol” RISC-V, apakah Solidity dapat mewujudkannya masih belum pasti, tetapi bahkan satu opcode akan menyebabkan banyak aliran kontrol/akses memori karena biaya interpretasi);
- Gunakan tipe data yang lebih kecil;
Di sini saya ingin menunjukkan bahwa untuk mewujudkan keuntungan poin 1 dan poin 2, “biaya interpretasi” harus dihilangkan. Ini sejalan dengan filosofi RISC-V, tetapi ini bukan RISC-V yang sedang kita diskusikan saat ini, melainkan semacam “(? ) RISC-V” - yang perlu memiliki kemampuan tambahan tertentu, seperti mendukung konsep kontrak.
Masalah datang
Jadi, ada beberapa masalah di sini.
- Untuk meningkatkan pemeliharaan, Anda memerlukan RISC-V yang dapat mengkompilasi EVM (dengan pra-kompilasi) — ini sebenarnya adalah situasinya saat ini.
- Jika ingin meningkatkan skalabilitas, diperlukan sesuatu yang sepenuhnya berbeda — sebuah arsitektur baru yang mungkin mirip dengan RISC-V, yang dapat memahami konsep “kontrak”, kompatibel dengan batasan runtime Ethereum, dan dapat mengeksekusi kode kontrak secara langsung (tanpa “overhead interpretasi”).
Saya sekarang mengasumsikan bahwa Anda merujuk pada situasi kedua (karena sisa artikel tampaknya menyiratkan hal ini). Saya perlu mengingatkan Anda bahwa semua kode di luar lingkungan ini akan tetap ditulis dalam bahasa RISC-V zkVM saat ini, yang memiliki dampak besar pada pemeliharaan.
Kemungkinan Lain
Kita dapat mengompilasi bytecode dari opcode EVM tingkat tinggi. Kompiler bertanggung jawab untuk memastikan bahwa program yang dihasilkan mempertahankan invariabel, misalnya tidak terjadi “stack overflow”. Saya berharap dapat melihat ini ditunjukkan dalam EVM biasa. SNARK yang dikompilasi dengan benar dapat disertakan bersama instruksi penyebaran kontrak.
Kita juga dapat membangun sebuah “bukti formal” (formal proof) untuk membuktikan bahwa beberapa invariant tetap terjaga. Sejauh yang saya tahu, metode ini (bukan “virtualisasi, virtualization”) telah digunakan dalam konteks browser tertentu. Dengan menghasilkan SNARK dari bukti formal ini, Anda juga dapat mencapai hasil serupa.
Tentu saja, pilihan termudah adalah melakukannya dengan nekat…
Membangun MMU “rantai” terkecil
Anda mungkin telah secara implisit menyatakan hal ini dalam artikel, tetapi izinkan saya mengingatkan: Jika Anda ingin menghilangkan overhead virtualisasi, Anda harus menjalankan kode yang telah dikompilasi secara langsung - ini berarti Anda perlu mencegah kontrak (sekarang program yang dapat dieksekusi) untuk menulis ke memori kernel (implementasi non-EVM) dengan cara tertentu.
Oleh karena itu, kita memerlukan semacam “Memory Management Unit” (MMU). Mekanisme paging komputer tradisional mungkin tidak diperlukan karena ruang memori “fisik” nyaris tak terbatas. MMU ini harus sesederhana mungkin (karena berada pada tingkat abstraksi yang sama dengan arsitektur itu sendiri), tetapi beberapa fungsi (seperti “atomisitas transaksi, atomicity of transactions”) dapat dipindahkan ke lapisan tersebut.
Pada saat ini, EVM yang dapat dibuktikan akan menjadi program inti yang berjalan di arsitektur ini.
RISC-V mungkin bukan pilihan terbaik
Menariknya, dalam semua kondisi ini, “arsitektur set instruksi” (ISA) terbaik yang cocok untuk tugas ini mungkin bukan RISC-V, melainkan sesuatu yang mirip dengan EOF-EVM, alasannya adalah:
- Kode operasi “kecil” sebenarnya akan menyebabkan banyak akses memori, dan metode pembuktian yang ada sulit untuk ditangani dengan efisien.
- Untuk mengurangi biaya cabang, kami baru-baru ini menunjukkan dalam makalah Morgana bagaimana membuktikan kinerja tingkat prakomputasi untuk kode “lompatan statis” (static jumps, mirip EOF).
Saran saya adalah membangun arsitektur baru yang ramah terhadap bukti, dilengkapi dengan MMU minimal, yang memungkinkan kontrak dijalankan sebagai file eksekusi terpisah. Saya tidak berpikir itu harus RISC-V, tetapi harus menjadi ISA baru yang dioptimalkan khusus untuk pembatasan protokol SNARK**, bahkan ISA yang mewarisi sebagian subset opcode EVM mungkin lebih baik ——** Seperti yang kita ketahui, terlepas dari apakah kita mau atau tidak, precompiled akan selalu ada, jadi RISC-V di sini tidak memberikan penyederhanaan apa pun.
