Masa Depan Protokol Ethereum yang Mungkin (Enam): Kemakmuran

Penulis: Vitalik Buterin

Beberapa hal sulit untuk dimasukkan ke dalam satu kategori. Dalam desain protokol Ethereum, terdapat banyak "detail" yang sangat penting bagi kesuksesan Ethereum. Sebenarnya, sekitar setengah dari konten melibatkan berbagai jenis perbaikan EVM, sementara sisanya terdiri dari berbagai tema niche, inilah makna 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 sambil mengurangi risiko
• Menjelajahi kriptografi canggih, sehingga Ethereum dapat meningkat secara signifikan 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 implementasi banyak bentuk kriptografi tingkat tinggi, kecuali jika didukung secara eksplisit melalui prekompilasi.

Apa itu, 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)
• Dilarang melakukan pengalihan dinamis, hanya pengalihan statis yang diizinkan
• Kode EVM tidak dapat lagi mengamati informasi yang terkait dengan bahan bakar
• Menambahkan mekanisme subrutin eksplisit baru

Kontrak lama akan tetap 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 dengan bytecode yang sedikit lebih kecil berkat fitur subrutin, kemudian dengan fungsi baru spesifik EOF atau biaya gas yang berkurang.

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

Sebuah pemikiran yang lebih baru adalah menggabungkan EVM-MAX dengan fitur Single Instruction Multiple Data (SIMD), di mana SIMD sebagai sebuah ide di Ethereum sudah ada sejak lama, 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, kombinasi EVM-MAX dan SIMD menjadikan kedua perluasan yang berorientasi kinerja ini sebagai pasangan yang alami.

Desain umum dari kombinasi EIP akan dimulai dari EIP-6690, kemudian:

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

untuk i dalam jangkauan(jumlah): mem[z_start + z_skip * count] = op( mem[x_start + x_skip * count], mem[y_start + y_skip * count] )

Dalam implementasi sebenarnya, ini akan diproses secara paralel.

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

Tautan penelitian yang ada

• EOF:
• EVM-MAX:
• SIMD:

Sisa pekerjaan dan pertimbangan

Saat ini, EOF direncanakan untuk dimasukkan dalam hard fork berikutnya. Meskipun selalu mungkin untuk menghapusnya pada menit terakhir—fungsi sebelumnya pernah dihapus sementara dalam hard fork sebelumnya, tetapi melakukannya akan menghadapi tantangan besar. Menghapus EOF berarti bahwa setiap peningkatan EVM di masa depan harus dilakukan tanpa EOF, meskipun itu mungkin dilakukan, tetapi bisa lebih sulit.

Perimbangan utama EVM adalah antara kompleksitas L1 dan kompleksitas infrastruktur, EOF adalah sejumlah besar kode yang perlu ditambahkan ke dalam 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 peningkatan berkelanjutan Ethereum L1 harus mencakup dan dibangun di atas EOF.

Tugas penting yang perlu dilakukan adalah mewujudkan fungsi serupa EVM-MAX dengan SIMD, dan melakukan pengujian kinerja terhadap konsumsi gas dari berbagai operasi kriptografi.

Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?

L1 menyesuaikan EVM-nya sehingga L2 juga dapat lebih mudah melakukan penyesuaian yang sesuai. Jika keduanya tidak melakukan penyesuaian secara bersamaan, hal ini dapat menyebabkan ketidakcocokan dan membawa dampak negatif. Selain itu, EVM-MAX dan SIMD dapat menurunkan biaya gas dari banyak sistem pembuktian, sehingga membuat L2 lebih efisien. Ini juga membuat lebih mudah untuk mengganti lebih banyak pra-kompilasi 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 diverifikasi melalui satu cara: tanda tangan ECDSA. Awalnya, abstraksi akun dirancang untuk melampaui hal ini, memungkinkan logika verifikasi akun untuk menjadi kode EVM yang sembarang. Ini dapat mengaktifkan serangkaian aplikasi:

• Beralih ke kriptografi tahan kuantum
• Rotasi kunci lama (secara luas dianggap sebagai praktik keamanan yang dianjurkan)
• Dompet multisig dan dompet pemulihan sosial
• Menggunakan satu kunci untuk operasi nilai rendah, menggunakan kunci lain (atau satu set kunci) untuk operasi nilai tinggi

Memungkinkan protokol privasi beroperasi tanpa perantara, secara signifikan mengurangi kompleksitasnya, dan menghilangkan satu titik ketergantungan pusat yang kunci.

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

MPC (komputasi multi-pihak) adalah teknologi yang telah ada selama 40 tahun, digunakan untuk membagi kunci menjadi beberapa bagian dan menyimpannya di berbagai perangkat, memanfaatkan teknik 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 merupakan hasil dari pengakuan yang semakin meningkat terhadap kenyamanan abstraksi akun untuk menguntungkan semua pengguna (termasuk pengguna EOA), bertujuan untuk meningkatkan pengalaman semua pengguna dalam jangka pendek, dan menghindari pembagian menjadi dua ekosistem.

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

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

Apa itu, bagaimana cara kerjanya?

Inti dari abstraksi akun adalah sederhana: memungkinkan kontrak pintar untuk memulai transaksi, bukan hanya EOA. Seluruh kompleksitas berasal dari cara mewujudkan hal ini 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 satu nilai tunggal S, dan nilai S saat ini membuat transaksi di dalam mempool menjadi valid, maka satu transaksi tunggal yang membalik nilai S dapat membuat semua transaksi lain di dalam mempool menjadi tidak valid. Ini memungkinkan penyerang untuk mengirimkan transaksi sampah ke dalam mempool dengan biaya yang sangat rendah, sehingga menghambat sumber daya node jaringan.

Setelah bertahun-tahun usaha, 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 operasi pengguna menjadi dua tahap: verifikasi dan eksekusi. Semua verifikasi diproses terlebih dahulu, diikuti dengan semua eksekusi. Dalam memori pool, operasi pengguna hanya akan diterima jika tahap verifikasinya hanya melibatkan akun mereka sendiri dan tidak membaca variabel lingkungan. Ini dapat mencegah serangan kegagalan ganda. Selain itu, langkah verifikasi juga dikenakan batas gas yang ketat.

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, alih-alih transaksi biasa. Namun, baru-baru ini kami menyadari perlunya menulis setidaknya sebagian dari kontennya ke dalam protokol.

Dua alasan kunci adalah sebagai berikut:

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

Selain itu, ERC-4337 juga memperluas dua fungsi:

• Pembayaran perwakilan (Paymasters): Memungkinkan satu akun untuk membayar biaya atas nama akun lain, fungsi ini melanggar aturan bahwa tahap verifikasi hanya dapat mengakses akun pengirim itu sendiri, sehingga pengenalan penanganan khusus diperlukan untuk memastikan keamanan mekanisme pembayaran perwakilan.
• Pengumpul (Aggregators): Mendukung fungsi penggabungan tanda tangan, seperti penggabungan BLS atau penggabungan berbasis SNARK. Ini diperlukan untuk mencapai efisiensi data tertinggi di Rollup.

Tautan penelitian yang ada

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