Masa Depan Protokol Ethereum yang Mungkin (Enam): Kemakmuran

Dalam desain protokol Ethereum, ada banyak "detail" yang sangat penting untuk keberhasilannya. Sebenarnya, sekitar setengah dari kontennya berkaitan dengan berbagai jenis perbaikan EVM, sementara sisanya terdiri dari berbagai topik kecil, inilah 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 secara ekonomi, meningkatkan skalabilitas sambil mengurangi risiko
• Menjelajahi kriptografi canggih, membuat Ethereum secara signifikan membaik dalam jangka panjang

Perbaikan EVM

Apa masalah yang diselesaikan?

Saat ini EVM sulit untuk dianalisis secara statis, yang membuat sulit untuk membuat implementasi yang efisien, memverifikasi kode secara formal, dan melakukan perpanjangan lebih lanjut. Selain itu, efisiensi EVM yang rendah menyulitkan penerapan banyak bentuk kriptografi tingkat tinggi, kecuali 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 menentukan versi kode EVM baru, dengan banyak fitur unik, yang paling mencolok adalah:

• Kode ( dapat dieksekusi, tetapi tidak dapat membaca ) dari EVM dan data ( dapat dibaca, tetapi tidak dapat dieksekusi antara pemisahan ).
• Larangan loncatan dinamis, hanya loncatan statis yang diperbolehkan
• Kode EVM tidak dapat lagi mengamati informasi terkait bahan bakar
• Menambahkan mekanisme subrutin eksplisit baru

Kontrak lama akan terus ada dan dapat dibuat, meskipun pada akhirnya mungkin secara bertahap ditinggalkan, kontrak lama ( bahkan mungkin dipaksa untuk dikonversi menjadi kode EOF ). Kontrak baru akan mendapat manfaat dari peningkatan efisiensi yang dibawa oleh EOF—pertama dengan ukuran bytecode yang sedikit menyusut melalui fitur sub-rutin, kemudian dengan fungsi baru atau biaya gas yang berkurang yang spesifik untuk EOF.

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

Sebuah ide yang lebih baru adalah menggabungkan EVM-MAX dengan fitur SIMD (Single Instruction Multiple Data) (, SIMD sebagai sebuah konsep dalam Ethereum telah ada sejak lama, pertama kali diusulkan 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 skala yang berorientasi pada kinerja ini menjadi pasangan yang alami.

Sebuah desain kasar kombinasi EIP akan dimulai dari EIP-6690, kemudian:

• Mengizinkan )i( bilangan ganjil mana pun atau )ii( pangkat 2 mana pun yang paling tinggi hingga 2768 sebagai modulus
• Untuk setiap opcode EVM-MAX ) penjumlahan, pengurangan, perkalian (, tambahkan satu versi, versi ini tidak lagi menggunakan 3 nilai segera x, y, z, melainkan menggunakan 7 nilai segera: 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 loop dan non-loop(, setidaknya untuk modulus pangkat 2. Secara bersamaan menambahkan ISZERO) akan mengeluarkan dorongan ke tumpukan utama EVM(, yang akan cukup kuat untuk menerapkan kriptografi kurva elips, kriptografi bidang kecil) seperti Poseidon, Circle STARKs(, fungsi hash tradisional) seperti SHA256, KECCAK, BLAKE(, dan kriptografi berbasis kisi. Pembaruan EVM lainnya mungkin juga diimplementasikan, tetapi hingga saat ini perhatian lebih rendah.

) Tautan penelitian yang ada

• EOF:
• EVM-MAX:
• SIMD:

Sisa pekerjaan dan pertimbangan

Saat ini, EOF direncanakan untuk dimasukkan dalam hard fork berikutnya. Meskipun selalu ada kemungkinan untuk menghapusnya di saat-saat terakhir — dalam hard fork sebelumnya beberapa fungsi pernah dihapus sementara, tetapi melakukan hal itu akan menghadapi tantangan besar. Menghapus EOF berarti bahwa setiap peningkatan di EVM di masa depan harus dilakukan tanpa EOF, meskipun itu 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 imbalan, kita dapat menyederhanakan bahasa tingkat tinggi, menyederhanakan implementasi EVM, dan manfaat lainnya. Dapat dikatakan bahwa prioritas untuk peta jalan perbaikan berkelanjutan Ethereum L1 harus mencakup dan dibangun di atas EOF.

Salah satu pekerjaan penting yang perlu dilakukan adalah mewujudkan fungsi serupa EVM-MAX ditambah SIMD, serta melakukan pengujian acuan untuk konsumsi gas dari berbagai operasi kriptografi.

Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?

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

![Vitalik tentang masa depan Ethereum yang mungkin (Enam): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(

Abstraksi Akun

) masalah apa yang diselesaikan?

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

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

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

Sejak abstraksi akun diusulkan pada tahun 2015, tujuannya juga diperluas untuk mencakup banyak "target kenyamanan", misalnya, akun yang tidak memiliki ETH tetapi memiliki beberapa ERC20 dapat menggunakan ERC20 untuk membayar gas.

![Vitalik tentang masa depan Ethereum yang mungkin (Enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(

MPC) penghitungan multi pihak( adalah teknologi yang sudah berusia 40 tahun, digunakan untuk membagi kunci menjadi beberapa bagian dan menyimpannya di beberapa perangkat, memanfaatkan teknologi kriptografi untuk menghasilkan tanda tangan, tanpa perlu menggabungkan bagian kunci tersebut secara langsung.

EIP-7702 adalah proposal yang direncanakan untuk diperkenalkan dalam hard fork berikutnya, EIP-7702 adalah hasil dari kesadaran yang meningkat tentang penyediaan kemudahan 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 memberikan "fungsi kenyamanan" dari abstraksi akun kepada semua pengguna, termasuk EOA) saat ini, yaitu akun yang dimiliki secara eksternal yang dikendalikan oleh tanda tangan ECDSA yaitu akun(.

Meskipun beberapa tantangan ) terutama tantangan "kemudahan" ( dapat diatasi melalui teknologi progresif seperti komputasi multi pihak atau EIP-7702, namun tujuan keamanan utama dari proposal abstraksi akun yang diajukan awalnya 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 implementasi yang aman, yang merupakan tantangan.

![Vitalik tentang masa depan Ethereum yang mungkin (Enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(

) Apa itu, dan bagaimana cara kerjanya?

Inti dari abstraksi akun adalah sederhana: memungkinkan kontrak pintar untuk memulai transaksi, 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 valid, maka satu transaksi yang membalik nilai S dapat membuat semua transaksi lainnya di mempool menjadi tidak valid. Ini memungkinkan penyerang untuk mengirimkan transaksi sampah ke mempool dengan biaya yang sangat rendah, sehingga menyumbat sumber daya node jaringan.

Setelah bertahun-tahun usaha, yang bertujuan untuk memperluas fungsionalitas sambil membatasi risiko penolakan layanan ###DoS(, akhirnya menghasilkan 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, hanya ketika tahap verifikasi dari operasi pengguna hanya melibatkan akun mereka sendiri dan tidak membaca variabel lingkungan, maka akan diterima. Ini dapat mencegah serangan kegagalan ganda. Selain itu, batas 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 fitur lainnya. Inilah sebabnya mengapa ERC-4337 menggunakan objek yang disebut tindakan pengguna, bukan transaksi biasa. Namun, baru-baru ini kami menyadari perlunya menuliskan setidaknya sebagian dari kontennya ke dalam protokol.

Dua alasan kunci adalah sebagai berikut:

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

![Vitalik tentang kemungkinan masa depan Ethereum (Enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-fe95dd28b911aea1a22365468b7c42cd.webp(

Selain itu, ERC-4337 juga memperluas dua fungsi:

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

) Tautan penelitian yang ada

• Ceramah tentang sejarah abstraksi akun:
• ERC-4337:
• EIP-7702:
• Kode BLSWallet ### menggunakan fungsi agregasi (:
• EIP-7562) menulis protokol abstraksi akun (:
• EIP-7701) Akun abstraksi protokol penulisan berbasis EOF (:

) Sisa pekerjaan dan pertimbangan

Saat ini, yang perlu diselesaikan adalah bagaimana mengimplementasikan abstraksi akun sepenuhnya ke dalam protokol. EIP abstraksi akun yang baru-baru ini populer adalah EIP-7701, usulan ini mengimplementasikan abstraksi akun di atas EOF.