Masa Depan Protokol Ethereum ( Enam ): Kemakmuran

Dalam desain protokol Ethereum, ada banyak "detail" yang sangat penting bagi keberhasilannya. Sebenarnya, sekitar setengah dari kontennya berkaitan dengan berbagai jenis perbaikan EVM, sedangkan sisanya terdiri dari berbagai topik niche, 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 sekaligus 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 perluasan lebih lanjut menjadi sulit. Selain itu, efisiensi EVM yang rendah membuat sulit untuk menerapkan banyak bentuk kriptografi tingkat tinggi, kecuali melalui dukungan eksplisit dengan pra-kompilasi.

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 dieksekusi antara pemisahan ).
• Dilarang melakukan lompat dinamis, hanya lompat statis yang diperbolehkan
• Kode EVM tidak dapat lagi mengamati informasi yang terkait dengan bahan bakar
• Menambahkan mekanisme subrutin 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 keuntungan dari peningkatan efisiensi yang dibawa oleh EOF—pertama-tama melalui bytecode yang sedikit lebih kecil berkat fitur subrutin, dan kemudian melalui fitur baru khusus EOF atau pengurangan biaya gas.

Setelah memperkenalkan EOF, peningkatan lebih lanjut menjadi lebih mudah, saat ini pengembangan yang paling matang adalah perluasan aritmatika modul EVM ( EVM-MAX ). EVM-MAX menciptakan serangkaian operasi baru yang khusus untuk operasi modulus, dan menempatkannya di 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 SIMD (Single Instruction Multiple Data) (, SIMD sebagai sebuah konsep di Ethereum sudah 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 umum untuk kombinasi EIP akan dimulai dari EIP-6690, kemudian:

• Mengizinkan )i( bilangan ganjil mana pun atau )ii( pangkat 2 mana pun yang tidak melebihi 2768 sebagai modulus
• Untuk setiap opcode EVM-MAX ) penjumlahan, pengurangan, perkalian (, tambahkan satu versi, yang tidak lagi menggunakan 3 angka langsung x, y, z, tetapi menggunakan 7 angka 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 nyata, ini akan diproses secara paralel.

• Mungkin menambahkan XOR, AND, OR, NOT, dan SHIFT) termasuk loop dan non-loop(, setidaknya untuk modulus pangkat 2. Sementara itu, menambahkan ISZERO) akan mendorong output ke tumpukan utama EVM(, yang akan cukup kuat untuk mendukung 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 terhadapnya lebih rendah.

)# Pekerjaan yang tersisa dan pertimbangan

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

Pertimbangan utama EVM adalah kompleksitas L1 dan kompleksitas infrastruktur, EOF adalah sejumlah besar kode yang perlu ditambahkan ke implementasi EVM, pemeriksaan kode statis juga relatif kompleks. Namun, sebagai imbalan, kita dapat menyederhanakan bahasa tingkat tinggi, menyederhanakan implementasi EVM dan manfaat lainnya. Bisa dikatakan, memprioritaskan 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, dan melakukan pengujian standar 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 sesuai dengan lebih mudah. Jika keduanya tidak melakukan penyesuaian secara sinkron, mungkin akan menyebabkan ketidakcocokan yang membawa dampak negatif. Selain itu, EVM-MAX dan SIMD dapat mengurangi biaya gas dari banyak sistem pembuktian, sehingga L2 menjadi lebih efisien. Ini juga membuat lebih mudah untuk menggantikan lebih banyak pra-kompilasi dengan kode EVM yang dapat menjalankan tugas yang sama, yang mungkin tidak akan mempengaruhi efisiensi secara signifikan.

![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 kode EVM yang sembarangan. Ini dapat mengaktifkan serangkaian aplikasi:

• Beralih ke kriptografi tahan kuantum
• Memutar 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 sekumpulan kunci ( untuk operasi nilai tinggi

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

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

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 kunci tersebut secara langsung.

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

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

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 hal ini belum tercapai hingga saat ini adalah karena pelaksanaannya yang aman, yang merupakan tantangan.

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

)# 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 ini dengan cara yang ramah terhadap pemeliharaan jaringan terdesentralisasi, serta mencegah serangan penolakan layanan.

Salah satu tantangan kunci yang khas adalah masalah kegagalan ganda:

Jika ada 1000 fungsi verifikasi akun yang semuanya tergantung pada satu nilai tunggal S, dan nilai S saat ini membuat semua transaksi dalam memori pool menjadi valid, maka satu transaksi tunggal yang membalik nilai S dapat membuat semua transaksi lain dalam memori pool menjadi tidak valid. Ini memungkinkan penyerang untuk mengirim transaksi sampah ke dalam memori pool dengan biaya yang sangat rendah, sehingga membanjiri sumber daya node jaringan.

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

Cara kerja ERC-4337 adalah membagi pemrosesan operasi pengguna menjadi dua tahap: verifikasi dan eksekusi. Semua verifikasi diproses terlebih dahulu, dan semua eksekusi diproses setelahnya. 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, batasan gas yang ketat juga diberlakukan untuk langkah verifikasi.

ERC-4337 dirancang sebagai standar protokol tambahan )ERC(, karena pada saat itu para pengembang klien Ethereum fokus pada penggabungan )Merge(, dan tidak memiliki energi tambahan untuk menangani fungsi lainnya. Inilah 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 inherent ineffisiensi kontrak: setiap bundel memiliki pengeluaran tetap sekitar 100.000 gas, ditambah ribuan gas tambahan untuk setiap operasi pengguna.
2. Memastikan kebutuhan atribut Ethereum: seperti daftar yang dibuat yang mencakup jaminan yang perlu dipindahkan ke pengguna akun abstrak.

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 fase verifikasi hanya dapat mengakses akun pengirim itu sendiri, 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.

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

)# Pekerjaan yang tersisa dan pertimbangan

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

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

1. Menggunakan EIP-4337 sebagai bagian dari protokol
2. Jenis EOA baru, di mana algoritma tanda tangan untuk eksekusi kode EVM

Jika kita mulai dengan menetapkan batas ketat pada kompleksitas kode yang dapat dieksekusi selama periode verifikasi—tidak diizinkan mengakses status eksternal, bahkan batas gas yang ditetapkan pada awalnya sangat rendah sehingga tidak efektif untuk aplikasi ketahanan kuantum atau perlindungan privasi—maka keamanan pendekatan ini menjadi 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 untuk beroperasi tanpa perantara, serta ketahanan kuantum sangat penting. Untuk itu, kita perlu menemukan cara yang lebih fleksibel untuk mengatasi risiko penolakan layanan ###DoS(, tanpa mengharuskan langkah verifikasi harus sangat sederhana.