Pengembang membantah Vitalik: asumsinya salah, dan RISC-V bukanlah pilihan terbaik

Artikel ini dari: kompilasi pengembang Ethereum levochka.eth

|Odaily Planet Daily (@OdailyChina); @azuma_eth Catatan editor

:

Kemarin, salah satu pendiri Ethereum Vitalik merilis artikel radikal tentang peningkatan lapisan eksekusi Ethereum (lihat "Artikel Baru Radikal Vitalik: Penskalaan Lapisan Eksekusi "Tidak Rusak, Tidak Berdiri", EVM Harus Diulang di Masa Depan), menyebutkan bahwa dia berharap untuk menggantinya dengan RISC-V EVM sebagai bahasa mesin virtual untuk kontrak pintar.

Begitu artikel ini keluar, itu langsung menyebabkan kegemparan di komunitas pengembang Ethereum, dan banyak petinggi teknis mengungkapkan pandangan yang berbeda tentang rencana tersebut. Tak lama setelah artikel tersebut diterbitkan, pengembang Ethereum Tier-1 levochka.eth menulis artikel panjang di bawah artikel asli yang membantah argumen Vitalik bahwa Vitalik telah membuat asumsi yang salah tentang sistem pembuktian dan kinerjanya, dan bahwa RISC-V mungkin bukan pilihan terbaik karena tidak dapat menyeimbangkan "skalabilitas" dan "pemeliharaan".

Berikut ini adalah artikel asli di levochka.eth, yang disusun oleh surat kabar harian Odaily.

Tolong jangan lakukan ini.

Rencana ini tidak masuk akal, karena Anda membuat asumsi yang salah tentang membuktikan sistem dan kinerjanya.

Hipotesis Validasi

Seperti yang saya pahami, argumen utama untuk skema ini adalah "skalabilitas" dan "pemeliharaan".

Pertama, saya ingin berbicara tentang pemeliharaan.

Faktanya, semua RISC-V zk-VM memerlukan "prakompilasi" untuk menangani operasi intensif komputasi. Daftar SP 1 yang telah disusun sebelumnya dapat ditemukan dalam dokumentasi Ringkas, dan Anda akan menemukan bahwa itu mencakup hampir semua opcode "komputasi" penting dalam EVM.

Akibatnya, semua modifikasi pada primitif kriptografi lapisan dasar memerlukan "sirkuit" baru untuk ditulis dan diaudit untuk prakompilasi ini, yang merupakan batasan serius.

Memang, jika kinerjanya cukup baik, mungkin relatif mudah untuk melakukan kemudahan servis bagian "non-EVM" dari klien. Saya tidak yakin apakah itu cukup baik, tetapi saya kurang percaya diri di bagian ini karena alasan berikut:

• "perhitungan pohon keadaan" memang dapat sangat dipercepat dengan pra-kompilasi yang ramah seperti Poseidon.

• Namun, tidak jelas apakah "deserialisasi" dapat ditangani dengan cara yang elegan dan dapat dipelihara.
  

• Selain itu, ada beberapa detail rumit (seperti pengukuran gas dan berbagai pemeriksaan) yang mungkin termasuk dalam "waktu evaluasi blok" tetapi sebenarnya harus diklasifikasikan sebagai bagian "non-EVM", yang cenderung lebih rentan terhadap tekanan perawatan.

Kedua, bagian tentang skalabilitas.

Saya perlu menegaskan kembali bahwa tidak mungkin bagi RISC-V untuk menangani beban EVM tanpa menggunakan prakompilasi, sama sekali tidak.

Jadi, pernyataan dalam teks asli bahwa "waktu pembuktian akhir akan didominasi oleh operasi prakompilasi saat ini" secara teknis benar, tetapi terlalu optimis - itu mengasumsikan bahwa tidak akan ada prakompilasi di masa depan, padahal sebenarnya (dalam skenario masa depan ini) prakompilasi masih akan ada, dan persis sama dengan opcode intensif komputasi dalam EVM (seperti tanda tangan, hash, dan mungkin analog besar).

Sulit untuk menilai contoh Fibonacci tanpa masuk ke detail yang paling halus, tetapi keuntungannya datang setidaknya sebagian:

• perbedaan antara Interpretasi dan overhead eksekusi;

• Pelepasan siklik (mengurangi "aliran kontrol" RISC-V, tidak pasti apakah Solidity dapat diimplementasikan, tetapi bahkan satu opcode masih dapat menghasilkan sejumlah besar aliran kontrol/akses memori karena overhead interpretasi);

• menggunakan tipe data yang lebih kecil;

Di sini saya ingin menunjukkan bahwa untuk mewujudkan manfaat dari poin 1 dan poin 2, "overhead interpretasi" harus dihilangkan. Ini sejalan dengan filosofi RISC-V, tetapi ini bukan RISC-V yang sedang kita diskusikan, melainkan "(?)RISC-V" yang serupa - ini membutuhkan kemampuan tambahan tertentu, seperti dukungan untuk konsep kontrak.

Inilah

masalahnya, jadi, ada beberapa masalah di sini.

• Untuk meningkatkan pemeliharaan, Anda memerlukan RISC-V (dengan prakompilasi) yang mengkompilasi EVM - itu saja.

• Untuk meningkatkan skalabilitas, sesuatu yang sama sekali berbeda diperlukan – arsitektur baru yang mungkin mirip dengan RISC-V yang memahami konsep "kontrak", kompatibel dengan batasan runtime Ethereum, dan dapat mengeksekusi kode kontrak secara langsung (tanpa "overhead interpretasi").

Saya sekarang berasumsi Anda mengacu pada kasus kedua (karena sisa artikel tampaknya menyiratkan itu). Saya perlu menarik perhatian Anda pada fakta bahwa semua kode di luar lingkungan ini akan tetap ditulis dalam bahasa RISC-V zkVM saat ini, yang berdampak signifikan pada pemeliharaan.

Sebagai alternatif,

kita dapat mengkompilasi bytecode dari opcode EVM tingkat tinggi. Kompiler bertanggung jawab untuk memastikan bahwa pembuat tetap invarian, seperti tidak mengalami "tumpukan luapan ". Saya ingin melihat ini ditampilkan dalam EVM normal. SNARK yang dikompilasi dengan benar dapat diberikan instruksi penyebaran kontrak.

Kita juga dapat membangun "bukti formal" yang membuktikan bahwa beberapa invarian dipertahankan. Sejauh yang saya tahu, pendekatan ini (bukan "virtualisasi") telah digunakan dalam beberapa konteks browser. Dengan menghasilkan SNARK dari bukti formal ini, Anda dapat mencapai hasil yang serupa. 

Tentu saja, pilihan termudah adalah gigit jari dan melakukan ......

Membangun MMU "berantai" minimal

, yang mungkin Anda ungkapkan secara implisit dalam artikel, tetapi izinkan saya memperingatkan bahwa jika Anda ingin menghilangkan overhead virtualisasi, Anda harus mengeksekusi kode yang dikompilasi secara langsung — yang berarti bahwa Anda perlu entah bagaimana mencegah kontrak (sekarang dapat dieksekusi) menulis ke memori kernel (bukan implementasi EVM).

Oleh karena itu, kita membutuhkan semacam "unit manajemen memori" (MMU). Mekanisme paging komputer tradisional mungkin tidak diperlukan karena ruang memori "fisik" hampir tak terbatas. MMU ini harus seramping mungkin (karena berada pada tingkat abstraksi yang sama dengan arsitektur itu sendiri), tetapi beberapa fitur seperti atomisitas transaksi dapat dipindahkan ke lapisan ini.

Pada titik ini, EVM yang dapat dibuktikan menjadi program kernel yang berjalan pada arsitektur ini.

RISC-V mungkin bukan pilihan terbaik

Menariknya, dalam semua kondisi ini, "arsitektur set instruksi" (ISA) terbaik untuk tugas ini mungkin bukan RISC-V, tetapi sesuatu yang mirip dengan EOF-EVM karena alasan berikut:

• Opcode "kecil" sebenarnya menghasilkan banyak akses memori, yang sulit ditangani oleh metode pengesahan yang ada secara efisien.

• Untuk mengurangi overhead percabangan, kami menunjukkan cara membuktikan kode "lompat statis" (EOF) dengan kinerja tingkat prakompilasi dalam makalah terbaru kami, Morgana.

Saran saya adalah membangun arsitektur baru yang ramah bukti dengan MMU minimal yang memungkinkan kontrak berjalan sebagai executable terpisah. Saya tidak berpikir itu seharusnya menjadi RISC-V, melainkan ISA baru yang dioptimalkan untuk batasan protokol SNARK, dan bahkan ISA yang sebagian mewarisi subset opcode EVM mungkin lebih baik - seperti yang kita ketahui, prakompilasi akan tetap ada, suka atau tidak, jadi RISC-V tidak membawa penyederhanaan apa pun di sini.