Masa Depan Protokol Ethereum yang Mungkin (Enam): Kemakmuran

Beberapa hal sulit untuk dikategorikan, dalam desain protokol Ethereum, banyak "detail" sangat penting untuk kesuksesan Ethereum. Sekitar setengah konten terkait dengan berbagai jenis peningkatan EVM, sisanya terdiri dari berbagai topik kecil, 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, untuk perbaikan signifikan jangka panjang Ethereum.

EVM perbaikan

Masalah apa yang diselesaikan?

Saat ini EVM sulit untuk dianalisis secara statis, yang membuat pembuatan implementasi yang efisien, verifikasi formal kode, dan pengembangan lebih lanjut menjadi sulit. Selain itu, efisiensi EVM yang rendah menyulitkan untuk menerapkan banyak 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 menentukan versi kode EVM baru, dengan banyak fitur unik, yang paling mencolok adalah:

• Kode ( dapat dieksekusi, tetapi tidak dapat dibaca dari EVM. Data ) dapat dibaca, tetapi tidak dapat mengeksekusi ( yang terpisah.
• Dilarang melakukan pengalihan dinamis, hanya pengalihan statis yang diizinkan
• Kode EVM tidak dapat lagi mengamati informasi terkait bahan bakar
• Menambahkan mekanisme sub-routine eksplisit baru

Kontrak lama akan terus ada dan dapat dibuat, meskipun pada akhirnya mungkin akan secara bertahap ditinggalkan kontrak lama ) 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 melalui fitur subrutin, kemudian dengan fungsi baru atau biaya gas yang berkurang yang khusus untuk EOF.

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

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

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

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

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

python 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 yang sebenarnya, 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(, ini akan cukup kuat untuk mengimplementasikan kriptografi kurva eliptik, kriptografi bidang kecil) seperti Poseidon, Circle STARKs(, fungsi hash tradisional) seperti SHA256, KECCAK, BLAKE( dan kriptografi berbasis kisi. Pembaruan EVM lainnya juga mungkin diimplementasikan, tetapi hingga saat ini perhatian masih rendah.

)# 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 - dalam hard fork sebelumnya, beberapa fungsi telah dihapus sementara, 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.

Pertimbangan utama EVM adalah 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 untuk perbaikan berkelanjutan Ethereum L1 harus mencakup dan dibangun di atas EOF.

Pekerjaan penting yang perlu dilakukan adalah mengimplementasikan fungsi mirip EVM-MAX dengan SIMD, dan melakukan pengujian benchmark terhadap 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, dapat menyebabkan ketidakcocokan dan berdampak 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 precompiled dengan kode EVM yang dapat menjalankan tugas yang sama, yang mungkin tidak akan berdampak besar pada efisiensi.

abstraksi akun

Masalah apa yang diselesaikan?

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

• Beralih ke kriptografi pasca-kuantum
• Mengganti kunci lama ### secara luas dianggap sebagai praktik keamanan yang dianjurkan (
• 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 perantara, secara signifikan mengurangi kompleksitasnya, dan menghilangkan satu titik ketergantungan pusat yang penting.

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

MPC) komputasi multi pihak( adalah teknologi yang telah ada selama 40 tahun, digunakan untuk membagi kunci menjadi beberapa bagian dan menyimpannya di beberapa perangkat, menggunakan teknik kriptografi untuk menghasilkan tanda tangan, tanpa perlu menggabungkan bagian-bagian kunci tersebut secara langsung.

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

EIP-7702 adalah proposal yang direncanakan untuk diperkenalkan dalam hard fork berikutnya, EIP-7702 adalah hasil dari kesadaran yang meningkat tentang penyediaan kenyamanan abstraksi akun untuk keuntungan semua pengguna ) termasuk pengguna EOA (, yang bertujuan untuk meningkatkan pengalaman semua pengguna dalam jangka pendek, dan menghindari pembagian menjadi dua ekosistem.

Pekerjaan ini dimulai dari 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 (.

Meskipun beberapa tantangan ) terutama tantangan "kenyamanan" ( dapat diselesaikan dengan teknologi bertahap seperti komputasi multi-pihak atau EIP-7702, tetapi tujuan keamanan utama dari usulan abstraksi akun yang awalnya diajukan hanya dapat dicapai dengan menelusuri kembali dan menyelesaikan masalah asli: memungkinkan kode kontrak pintar mengontrol validasi transaksi. Alasan mengapa ini belum terwujud adalah karena penerapannya yang aman, yang merupakan tantangan.

)# Apa itu, bagaimana cara kerjanya?

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

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 semua transaksi di dalam mempool menjadi valid, maka satu transaksi 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 berusaha, yang bertujuan untuk memperluas fungsi sambil membatasi risiko penolakan layanan ###DoS(, akhirnya mencapai solusi untuk mewujudkan "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 mempool, tindakan 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, 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 fitur lainnya. Inilah sebabnya 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 inefisiensi inheren kontrak: setiap bundel memiliki biaya tetap sekitar 100.000 gas, serta ribuan gas tambahan untuk setiap operasi pengguna.
2. Memastikan kebutuhan atribut Ethereum: Seperti daftar yang dibuat yang mencakup jaminan yang perlu dipindahkan ke pengguna abstrak akun.

Selain itu, ERC-4337 juga memperluas dua fungsi:

• Pembayaran agen ) Paymasters (: memungkinkan satu akun untuk membayar biaya atas nama akun lain, ini melanggar aturan bahwa hanya akun pengirim yang dapat diakses selama fase verifikasi, oleh karena itu diperkenalkan 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 Rollup.

)# Sisa pekerjaan dan pertimbangan

Masalah utama saat ini adalah bagaimana mengimplementasikan abstraksi akun sepenuhnya ke dalam protokol. EIP yang baru-baru ini populer, yaitu EIP-7701, adalah EIP yang mengimplementasikan abstraksi akun di atas EOF. Sebuah akun dapat memiliki bagian kode terpisah untuk validasi, dan jika akun tersebut telah mengatur bagian kode tersebut, maka kode itu akan dieksekusi dalam langkah validasi transaksi yang berasal dari akun tersebut.

Daya tarik metode ini terletak pada kenyataan bahwa ia secara jelas menunjukkan dua perspektif setara dari abstraksi akun lokal:

1. Menjadikan EIP-4337 sebagai bagian dari protokol
2. Sebuah jenis EOA baru, di mana algoritma tanda tangan adalah eksekusi kode EVM

Jika kita mulai dengan menetapkan batasan yang ketat pada kompleksitas kode yang dapat dieksekusi selama periode verifikasi—tidak diizinkan mengakses status eksternal, bahkan batas gas yang ditetapkan di awal begitu rendah sehingga tidak efektif untuk aplikasi yang tahan kuantum atau perlindungan privasi—maka keamanan pendekatan ini sangat jelas: hanya mengganti verifikasi ECDSA dengan eksekusi kode EVM yang memerlukan waktu serupa.

Namun, seiring berjalannya waktu, kita perlu memperlebar batasan ini, karena memungkinkan aplikasi perlindungan privasi berfungsi tanpa perantara, serta ketahanan kuantum sangat penting. Untuk itu, kita perlu menemukan cara yang lebih fleksibel untuk menangani risiko penolakan layanan ###DoS(, tanpa mengharuskan langkah verifikasi yang harus sangat sederhana.

Tampaknya pertimbangan utama adalah "menulis dengan cepat sebuah solusi yang memuaskan lebih sedikit orang" dengan "menunggu lebih lama