Masa Depan Potensial Protokol Ethereum (Enam): Kemakmuran

Dalam desain protokol Ethereum, ada banyak "detail" yang sangat penting untuk keberhasilannya. Sekitar setengah dari isi berkaitan dengan berbagai jenis perbaikan EVM, sementara sisanya terdiri dari berbagai tema kecil, itulah arti dari "kemakmuran".

Kemakmuran: Tujuan Utama

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

perbaikan EVM

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 penerapan 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:

• Kode ( dapat dieksekusi, tetapi tidak dapat membaca ) dari EVM dan data ( dapat dibaca, tetapi tidak dapat mengeksekusi antara pemisahan ).
• Larangan perpindahan dinamis, hanya perpindahan 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 kontrak lama ( bahkan mungkin dipaksa untuk dikonversi menjadi kode EOF ). Kontrak baru akan mendapat manfaat dari peningkatan efisiensi yang dibawa oleh EOF - pertama-tama melalui bytecode yang sedikit lebih kecil berkat fitur subrutin, kemudian dengan fitur baru yang spesifik untuk EOF atau pengurangan biaya gas.

Setelah pengenalan EOF, peningkatan lebih lanjut menjadi lebih mudah, saat ini pengembangan yang paling matang adalah perluasan aritmetika modul EVM ( EVM-MAX ). EVM-MAX menciptakan seperangkat operasi baru yang khusus untuk operasi modulo, dan menempatkannya di ruang memori baru yang tidak dapat diakses melalui opcode lain, sehingga memungkinkan penggunaan optimasi seperti perkalian Montgomery.

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

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

• Mengizinkan )i( bilangan ganjil mana pun atau )ii( pangkat 2 yang paling tinggi sebesar 2768 sebagai modulus
• Untuk setiap opcode EVM-MAX ) penjumlahan, pengurangan, perkalian (, tambahkan satu 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 rentang)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 loop dan non-loop(, setidaknya untuk modulus pangkat 2. Sementara menambahkan ISZERO) 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 perhatian lebih rendah.

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

)# Pekerjaan yang tersisa dan pertimbangan

Saat ini, EOF direncanakan untuk dimasukkan dalam hard fork berikutnya. Meskipun selalu mungkin untuk menghapusnya pada menit terakhir - fungsi telah sementara dihapus dalam hard fork sebelumnya, melakukan hal itu akan menghadapi tantangan besar. Menghapus EOF berarti bahwa setiap peningkatan terhadap 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 kode yang perlu ditambahkan ke dalam implementasi EVM yang banyak, dan pemeriksaan kode statis juga relatif kompleks. Namun, sebagai imbalan, kita dapat menyederhanakan bahasa tingkat tinggi, menyederhanakan implementasi EVM, serta manfaat lainnya. Dapat dikatakan bahwa peta jalan yang memprioritaskan perbaikan berkelanjutan Ethereum L1 harus mencakup dan dibangun di atas EOF.

Salah satu pekerjaan penting yang perlu dilakukan adalah mengimplementasikan fungsi serupa EVM-MAX ditambah 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 sesuai dengan lebih mudah. Jika keduanya tidak melakukan penyesuaian secara sinkron, mungkin akan menyebabkan ketidakcocokan yang dapat berdampak buruk. Selain itu, EVM-MAX dan SIMD dapat mengurangi biaya gas dari banyak sistem pembuktian, sehingga membuat L2 lebih efisien. Ini juga membuat lebih mudah untuk mengganti lebih banyak kompilasi pra dengan kode EVM yang dapat menjalankan tugas yang sama, yang mungkin tidak akan berdampak besar pada efisiensi.

![Vitalik tentang kemungkinan masa depan Ethereum (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 dirancang untuk melampaui ini, memungkinkan logika verifikasi akun untuk menjadi kode EVM yang sembarang. Ini dapat mengaktifkan serangkaian aplikasi:

• Beralih ke kriptografi anti-kuantum
• Mengganti kunci lama ### secara luas dianggap sebagai praktik keamanan yang dianjurkan (
• Dompet multisignature 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 sejumlah "tujuan便利", misalnya, akun yang tidak memiliki ETH tetapi memiliki beberapa ERC20 dapat menggunakan ERC20 untuk membayar gas.

MPC) multi-party computation( adalah teknologi yang telah ada selama 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-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 akan perlunya menyediakan kenyamanan abstraksi akun untuk memberikan manfaat bagi 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" dari abstraksi akun kepada semua pengguna, termasuk EOA) akun yang dimiliki secara eksternal saat ini, yaitu akun yang dikendalikan oleh tanda tangan ECDSA (.

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

Dari grafik, dapat dilihat bahwa meskipun beberapa tantangan ) terutama tantangan "kenyamanan" ( dapat diselesaikan dengan teknologi bertahap seperti komputasi multi-pihak atau EIP-7702, namun tujuan keamanan utama yang diajukan dalam usulan abstraksi akun hanya dapat dicapai dengan menelusuri kembali dan menyelesaikan masalah asli: memungkinkan kode kontrak pintar mengontrol verifikasi transaksi. Alasan mengapa ini belum terwujud sampai sekarang 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 untuk 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 satu nilai S, dan nilai S saat ini membuat transaksi dalam mempool semuanya valid, maka satu transaksi yang membalik nilai S dapat membuat semua transaksi lain dalam mempool menjadi tidak valid. Ini memungkinkan penyerang untuk mengirimkan transaksi sampah ke mempool dengan biaya yang sangat rendah, sehingga menghambat sumber daya node jaringan.

Setelah bertahun-tahun bekerja keras, yang bertujuan untuk memperluas fungsionalitas sambil membatasi risiko penolakan layanan ###DoS(, akhirnya mencapai solusi untuk mewujudkan "abstraksi akun yang 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, tindakan pengguna hanya akan diterima jika tahap verifikasinya hanya melibatkan akun itu sendiri dan tidak membaca variabel lingkungan. 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(, tanpa energi tambahan untuk menangani fungsi lainnya. Inilah sebabnya mengapa ERC-4337 menggunakan objek yang disebut operasi pengguna, alih-alih transaksi konvensional. 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 dari 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 perlu dialihkan ke pengguna abstrak akun.

Selain itu, ERC-4337 juga memperluas dua fungsi:

• Agen Pembayaran ) Paymasters (: Memungkinkan satu akun untuk mewakili akun lain dalam membayar biaya, ini melanggar aturan bahwa hanya akun pengirim itu sendiri yang dapat diakses selama fase verifikasi, sehingga penanganan khusus diperkenalkan 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.

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

)# Sisa pekerjaan dan pertimbangan

Saat ini, yang perlu diselesaikan adalah bagaimana mengimplementasikan abstraksi akun sepenuhnya ke dalam protokol. Baru-baru ini, EIP yang populer untuk menulis protokol abstraksi akun adalah EIP-7701, yang mewujudkan abstraksi akun di atas EOF. Sebuah akun dapat memiliki bagian kode terpisah untuk verifikasi; jika akun mengatur bagian kode tersebut, maka kode itu akan dieksekusi dalam langkah verifikasi transaksi yang berasal dari akun tersebut.

Daya tarik metode ini terletak pada kemampuannya untuk secara jelas menunjukkan dua perspektif ekuivalen dari abstraksi akun lokal:

1. Menggunakan EIP-4337 sebagai bagian dari protokol
2. 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 juga rendah sehingga tidak efektif untuk aplikasi yang tahan kuantum atau perlindungan privasi - maka keamanan metode ini sangat jelas: hanya mengganti verifikasi ECDSA dengan eksekusi kode EVM yang memerlukan waktu serupa.

Namun, seiring berjalannya waktu, kita perlu melonggarkan 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 mengatasi penolakan layanan ###DoS(.