Masa Depan Protokol Ethereum ( Enam ): Kemakmuran

Ditulis oleh: Vitalik Buterin

Beberapa hal sulit untuk dikategorikan secara tunggal, dalam desain protokol Ethereum, ada banyak "detail" yang sangat penting untuk keberhasilan Ethereum. Sebenarnya, sekitar setengah dari konten melibatkan berbagai jenis perbaikan EVM, sementara sisanya terdiri dari berbagai tema kecil, itulah arti dari "kemakmuran".

Kemakmuran: Tujuan Kunci

• Mengubah EVM menjadi "status akhir" yang berkinerja tinggi dan stabil
• Memperkenalkan abstraksi akun ke dalam protokol, memungkinkan semua pengguna menikmati akun yang lebih aman dan nyaman.
• Mengoptimalkan biaya transaksi ekonomi, meningkatkan skalabilitas sekaligus mengurangi risiko
• Menjelajahi kriptografi canggih untuk secara signifikan meningkatkan Ethereum dalam jangka panjang

perbaikan EVM

Apa masalah yang diselesaikan?

Saat ini, EVM sulit untuk dianalisis secara statis, yang membuat pembuatan implementasi yang efisien, verifikasi formal kode, dan perluasan lebih lanjut menjadi sulit. Selain itu, efisiensi EVM yang rendah menyulitkan penerapan banyak bentuk kriptografi tingkat tinggi, kecuali jika didukung secara eksplisit melalui prekompilasi.

Apa itu, dan bagaimana cara kerjanya?

Langkah pertama dari peta jalan perbaikan EVM saat ini adalah format objek EVM (EOF), yang direncanakan untuk dimasukkan dalam hard fork berikutnya. EOF adalah serangkaian EIP yang menetapkan versi kode EVM baru dengan banyak fitur unik, yang paling mencolok adalah:

• Pemisahan antara kode (dapat dieksekusi, tetapi tidak dapat dibaca dari EVM) dan data (dapat dibaca, tetapi tidak dapat dieksekusi)
• Larangan lompat dinamis, hanya lompat statis yang diizinkan
• Kode EVM tidak dapat lagi mengamati informasi yang terkait dengan bahan bakar
• Menambahkan mekanisme sub-rutin eksplisit baru

Kontrak lama akan terus ada dan dapat dibuat, meskipun pada akhirnya mungkin akan secara bertahap ditinggalkan (bahkan mungkin dipaksa untuk dikonversi menjadi kode EOF). Kontrak baru akan mendapatkan manfaat dari peningkatan efisiensi yang dibawa oleh EOF------pertama-tama dengan ukuran bytecode yang sedikit lebih kecil melalui fitur subrutin, dan selanjutnya dengan fungsi baru atau pengurangan biaya gas yang spesifik untuk EOF.

Setelah pengenalan EOF, peningkatan lebih lanjut menjadi lebih mudah, saat ini yang paling berkembang adalah perluasan aritmatika modul EVM (EVM-MAX). EVM-MAX menciptakan serangkaian operasi baru yang khusus untuk operasi modulus dan menempatkannya dalam ruang memori baru yang tidak dapat diakses melalui opcode lainnya, yang memungkinkan penggunaan optimasi seperti perkalian Montgomery.

Sebuah ide yang lebih baru adalah menggabungkan EVM-MAX dengan fitur Single Instruction Multiple Data (SIMD), di mana SIMD sebagai sebuah konsep dalam Ethereum telah ada sejak lama, yang pertama kali diajukan oleh Greg Colvin dalam EIP-616. SIMD dapat digunakan untuk mempercepat banyak bentuk kriptografi, termasuk fungsi hash, STARKs 32-bit, dan kriptografi berbasis kisi, penggabungan EVM-MAX dan SIMD membuat kedua skalabilitas yang berorientasi pada kinerja ini menjadi pasangan yang alami.

Desain kasar dari sebuah kombinasi EIP akan dimulai dari EIP-6690, kemudian:

• Memungkinkan (i) bilangan ganjil mana pun atau (ii) pangkat 2 mana pun yang paling tinggi adalah 2768 sebagai modulus
• Untuk setiap opcode EVM-MAX (penjumlahan, pengurangan, perkalian), tambahkan versi yang tidak lagi menggunakan 3 konstanta langsung x, y, z, tetapi menggunakan 7 konstanta langsung: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. Dalam kode Python, fungsi opcode ini mirip dengan:

for i in range(count):

mem[z_start + z_skip * count] = op(

mem[x_start + x_skip * count],

mem[y_start + y_skip * count]

)

Dalam implementasi nyata, ini akan diproses secara paralel.

• Mungkin menambahkan XOR, AND, OR, NOT, dan SHIFT (termasuk sirkular dan non-sirkular), setidaknya untuk modulus pangkat 2. Sementara itu, menambahkan ISZERO (yang akan mendorong output ke tumpukan utama EVM), ini akan cukup kuat untuk menerapkan kriptografi kurva elips, kriptografi domain kecil (seperti Poseidon, Circle STARKs), fungsi hash tradisional (seperti SHA256, KECCAK, BLAKE), dan kriptografi berbasis kisi. Pembaruan EVM lainnya juga mungkin diimplementasikan, tetapi sejauh ini kurang diperhatikan.

Tautan penelitian yang ada

• EOF:
• EVM-MAX:
• SIMD:

Pekerjaan yang tersisa dan pertimbangan

Saat ini, EOF direncanakan untuk dimasukkan dalam hard fork berikutnya. Meskipun selalu ada kemungkinan untuk menghapusnya pada saat-saat terakhir------fungsi dalam hard fork sebelumnya pernah dihapus sementara, tetapi melakukan hal ini akan menghadapi tantangan besar. Menghapus EOF berarti bahwa setiap pembaruan EVM di masa depan harus dilakukan tanpa EOF, meskipun bisa dilakukan, tetapi mungkin lebih sulit.

Pertimbangan utama EVM adalah kompleksitas L1 dan kompleksitas infrastruktur, EOF adalah sejumlah besar kode yang perlu ditambahkan ke implementasi EVM, dan pemeriksaan kode statis juga relatif kompleks. Namun, sebagai imbalannya, kita dapat menyederhanakan bahasa tingkat tinggi, menyederhanakan implementasi EVM, dan manfaat lainnya. Dapat dikatakan bahwa peta jalan yang memprioritaskan perbaikan berkelanjutan Ethereum L1 harus mencakup dan dibangun di atas EOF.

Sebuah pekerjaan penting yang perlu dilakukan adalah mengimplementasikan fungsi serupa EVM-MAX dengan SIMD, dan melakukan pengujian dasar untuk konsumsi gas dari berbagai operasi kripto.

Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?

L1 menyesuaikan EVM-nya sehingga L2 juga dapat melakukan penyesuaian yang sesuai dengan lebih mudah. Jika keduanya tidak melakukan penyesuaian secara sinkron, hal ini dapat menyebabkan ketidakcocokan dan membawa dampak negatif. Selain itu, EVM-MAX dan SIMD dapat mengurangi biaya gas dari banyak sistem pembuktian, sehingga membuat L2 lebih efisien. Ini juga membuatnya lebih mudah untuk mengganti lebih banyak prekompilasi dengan kode EVM yang dapat menjalankan tugas yang sama, yang mungkin tidak akan berdampak besar pada efisiensi.

abstraksi akun

Apa masalah yang diselesaikan?

Saat ini, transaksi hanya dapat divalidasi dengan satu cara: tanda tangan ECDSA. Awalnya, abstraksi akun dimaksudkan untuk melampaui hal ini, memungkinkan logika verifikasi akun menjadi kode EVM yang sembarangan. Ini dapat mengaktifkan serangkaian aplikasi:

• Beralih ke kriptografi pasca-kuantum
• Ganti kunci lama (secara luas dianggap sebagai praktik keamanan yang disarankan)
• Dompet multisig dan dompet pemulihan sosial
• Gunakan satu kunci untuk operasi nilai rendah, gunakan kunci lain (atau satu set kunci) untuk operasi nilai tinggi

Memungkinkan protokol privasi berfungsi tanpa relai, secara signifikan mengurangi kompleksitasnya dan menghilangkan satu titik ketergantungan sentral yang penting.

Sejak pengenalan abstraksi akun pada tahun 2015, tujuannya juga diperluas untuk mencakup banyak "tujuan kemudahan", misalnya, akun yang tidak memiliki ETH tetapi memiliki beberapa ERC20 dapat membayar gas menggunakan ERC20. Berikut adalah grafik ringkasan dari tujuan-tujuan ini:

MPC (Multi-Party Computation) adalah teknologi yang telah ada selama 40 tahun, digunakan untuk membagi kunci menjadi beberapa bagian dan menyimpannya di berbagai perangkat, memanfaatkan teknologi kriptografi untuk menghasilkan tanda tangan, tanpa perlu menggabungkan bagian-bagian kunci tersebut secara langsung.

EIP-7702 adalah proposal yang direncanakan untuk diperkenalkan dalam hard fork berikutnya, EIP-7702 adalah hasil dari meningkatnya kesadaran untuk memberikan kemudahan abstraksi akun yang menguntungkan semua pengguna (termasuk pengguna EOA), bertujuan untuk meningkatkan pengalaman semua pengguna dalam jangka pendek, dan menghindari perpecahan menjadi dua ekosistem.

Pekerjaan ini dimulai dengan EIP-3074 dan akhirnya membentuk EIP-7702. EIP-7702 menyediakan "fungsi kenyamanan" dari abstraksi akun kepada semua pengguna, termasuk EOA (akun yang dimiliki secara eksternal, yaitu akun yang dikendalikan oleh tanda tangan ECDSA) hari ini.

Dari grafik, dapat dilihat bahwa meskipun beberapa tantangan (terutama tantangan "kenyamanan") dapat diatasi melalui teknologi bertahap seperti komputasi multipihak atau EIP-7702, tujuan keamanan utama dari proposal abstraksi akun yang diajukan pada awalnya hanya dapat dicapai dengan kembali dan menyelesaikan masalah asli: memungkinkan kode kontrak pintar mengontrol verifikasi transaksi. Alasan mengapa ini belum tercapai hingga saat ini adalah penerapan yang aman, yang merupakan tantangan.

Apa itu, dan bagaimana cara kerjanya?

Inti dari abstraksi akun adalah sederhana: memungkinkan kontrak cerdas untuk memulai transaksi, dan bukan hanya EOA. Seluruh kompleksitas berasal dari cara mewujudkannya dengan cara yang ramah terhadap pemeliharaan jaringan terdesentralisasi dan mencegah serangan penolakan layanan.

Salah satu tantangan kunci yang khas adalah masalah kegagalan ganda:

Jika ada 1000 fungsi verifikasi akun yang bergantung pada suatu nilai tunggal S, dan nilai S saat ini membuat semua transaksi di mempool menjadi valid, maka satu transaksi tunggal yang membalik nilai S dapat membuat semua transaksi lain di mempool menjadi tidak valid. Ini memungkinkan penyerang untuk mengirimkan transaksi sampah ke mempool dengan biaya yang sangat rendah, sehingga membanjiri sumber daya node jaringan.

Setelah bertahun-tahun bekerja keras, yang bertujuan untuk memperluas fungsionalitas sambil membatasi risiko penolakan layanan (DoS), akhirnya ditemukan solusi untuk mencapai "abstraksi akun ideal": ERC-4337.

Cara kerja ERC-4337 adalah membagi pemrosesan tindakan pengguna menjadi dua tahap: verifikasi dan eksekusi. Semua verifikasi diproses terlebih dahulu, dan semua eksekusi diproses setelahnya. Dalam memori pool, hanya jika tahap verifikasi dari tindakan pengguna hanya melibatkan akun mereka sendiri dan tidak membaca variabel lingkungan, maka itu akan diterima. Ini dapat mencegah serangan kegagalan ganda. Selain itu, pembatasan gas yang ketat juga diterapkan pada langkah verifikasi.

ERC-4337 dirancang sebagai standar protokol tambahan (ERC), karena pada saat itu pengembang klien Ethereum fokus pada penggabungan (Merge), tidak memiliki energi tambahan untuk menangani fungsi lainnya. Inilah sebabnya mengapa ERC-4337 menggunakan objek yang disebut operasi pengguna, bukan transaksi biasa. Namun, baru-baru ini kami menyadari perlunya menulis setidaknya sebagian dari konten tersebut ke dalam protokol.

Dua alasan kunci adalah sebagai berikut:

1. EntryPoint sebagai ketidakefisienan bawaan kontrak: setiap bundel memiliki biaya tetap sekitar 100.000 gas, ditambah ribuan gas tambahan untuk setiap operasi pengguna.
2. Memastikan pentingnya atribut Ethereum: seperti daftar yang dibuat yang mencakup jaminan yang perlu dipindahkan ke pengguna akun abstrak.

Selain itu, ERC-4337 juga memperluas dua fungsi:

• Agen Pembayaran (Paymasters): Fitur yang memungkinkan satu akun membayar biaya atas nama akun lain, yang melanggar aturan bahwa hanya akun pengirim itu sendiri yang dapat diakses selama tahap verifikasi, sehingga pengenalan penanganan khusus diperlukan untuk memastikan keamanan mekanisme agen pembayaran.
• Agregator (Aggregators): mendukung fungsi agregasi tanda tangan, seperti agregasi BLS atau agregasi berbasis SNARK. Ini diperlukan untuk mencapai efisiensi data tertinggi pada Rollup.

Tautan penelitian yang ada

• Tentang sejarah abstraksi akun:
• ERC-4337：
• EIP-7702：
• Kode BLSWallet (menggunakan fungsi agregasi):
• EIP-7562 (abstraksi akun untuk menulis protokol):
• EIP-7701 (protokol akun abstraksi penulisan berbasis EOF):

Sisa