Masa Depan Protokol Ethereum ( Enam ): Kemakmuran

Dalam desain protokol Ethereum, terdapat banyak “detail” yang sangat penting bagi keberhasilan Ethereum. Sebenarnya, sekitar setengah dari kontennya melibatkan berbagai jenis perbaikan EVM, sementara sisanya terdiri dari berbagai topik kecil, itulah arti dari “kompleksitas”.

Kemakmuran: Tujuan Kunci

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

EVM perbaikan

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 penerapan banyak bentuk kriptografi tingkat tinggi, kecuali melalui dukungan eksplisit dengan 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 membaca ) dari EVM dan data ( dapat dibaca, tetapi tidak dapat dieksekusi antara pemisahan ).
• Larangan untuk lompat dinamis, hanya lompat statis yang diizinkan
• Kode EVM tidak dapat lagi mengamati informasi yang terkait dengan bahan bakar
• Menambahkan mekanisme sub-rutin eksplisit baru

Kontrak lama akan tetap ada dan dapat dibuat, meskipun pada akhirnya mungkin akan secara bertahap ditinggalkan kontrak lama ( bahkan mungkin dipaksa untuk diubah menjadi kode EOF ). Kontrak baru akan mendapatkan manfaat dari peningkatan efisiensi yang dibawa oleh EOF—pertama dengan bytecode yang sedikit lebih kecil melalui fitur sub-rutin, kemudian dengan fitur baru yang spesifik untuk EOF atau pengurangan biaya gas.

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 dalam 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 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.

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

• Mengizinkan (i) bilangan ganjil mana pun atau (ii) bilangan 2 yang pangkatnya paling tinggi 2768 sebagai modulus
• Untuk setiap opcode EVM-MAX ( penjumlahan, pengurangan, perkalian ), tambahkan sebuah versi, yang tidak lagi menggunakan 3 operand langsung x, y, z, melainkan 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:

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 sebenarnya, ini akan diproses secara paralel.

• Mungkin menambahkan XOR, AND, OR, NOT, dan SHIFT( termasuk siklus dan non-siklus), setidaknya untuk modulus pangkat 2. Pada saat yang sama 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 hingga saat ini fokusnya masih rendah.

Sisa pekerjaan dan pertimbangan

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

Kompromi 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 imbalan, 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 serupa EVM-MAX dengan SIMD, serta 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 melakukan penyesuaian yang diperlukan dengan lebih mudah. Jika keduanya tidak melakukan penyesuaian secara sinkron, mungkin akan menyebabkan ketidakcocokan yang 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 menggantikan lebih banyak prekompilasi dengan kode EVM yang dapat menjalankan tugas yang sama, yang mungkin tidak akan berdampak besar pada efisiensi.

abstraksi akun

Masalah apa yang telah 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 sewenang-wenang. Ini dapat mengaktifkan serangkaian aplikasi:

• Beralih ke kriptografi anti-kuantum
• Memutar kunci lama ( secara luas dianggap sebagai praktik keamanan yang disarankan )
• Dompet multisig dan dompet pemulihan sosial
• Menggunakan satu kunci untuk operasi nilai rendah, menggunakan kunci lain ( atau sekumpulan kunci ) untuk operasi nilai tinggi

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

Sejak abstraksi akun diajukan pada tahun 2015, tujuannya juga diperluas untuk mencakup sejumlah “tujuan kenyamanan”, misalnya, akun yang tidak memiliki ETH tetapi memiliki beberapa ERC20 dapat menggunakan ERC20 untuk membayar gas.

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 dan mencegah serangan penolakan layanan.

Salah satu tantangan kunci yang khas adalah masalah kegagalan ganda:

Jika ada 1000 fungsi validasi akun yang bergantung pada suatu nilai tunggal S, dan nilai S saat ini membuat transaksi dalam mempool valid, maka satu transaksi yang membalikkan 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 menyumbat sumber daya node jaringan.

Setelah bertahun-tahun usaha, yang bertujuan untuk memperluas fungsionalitas sambil membatasi risiko penolakan layanan (DoS), akhirnya diperoleh solusi untuk mewujudkan “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, dan semua eksekusi diproses setelahnya. Dalam mempool, 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), dan tidak memiliki energi tambahan untuk menangani fungsi lainnya. Itulah 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 akun abstrak.

Selain itu, ERC-4337 juga memperluas dua fungsi:

• Agen Pembayaran ( Paymasters ): Memungkinkan satu akun untuk membayar biaya atas nama akun lain, fitur ini melanggar aturan yang menyatakan bahwa hanya akun pengirim yang dapat diakses selama fase verifikasi, sehingga pengolahan 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 pada Rollup.

Pekerjaan yang tersisa dan pertimbangan

Saat ini yang perlu diselesaikan adalah bagaimana mengimplementasikan abstraksi akun sepenuhnya ke dalam protokol. Protokol akun abstraksi yang baru-baru ini populer adalah EIP-7701, yang mengimplementasikan 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 kenyataan bahwa ia dengan jelas menunjukkan dua perspektif ekivalen 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 ketat pada kompleksitas kode yang dapat dieksekusi selama periode verifikasi—tidak diperbolehkan mengakses status eksternal, bahkan batas gas yang ditetapkan pada awalnya begitu 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 risiko penolakan layanan (DoS), tanpa mengharuskan langkah verifikasi harus sangat sederhana.

Tampaknya keseimbangan utama adalah “menulis cepat solusi yang membuat lebih sedikit orang puas” versus “menunggu lebih lama, mungkin mendapatkan solusi yang lebih ideal”, metode ideal mungkin adalah semacam metode campuran. Salah satu metode campuran adalah menulis lebih cepat beberapa kasus penggunaan, dan menyisakan lebih banyak waktu untuk mengeksplorasi kasus penggunaan lainnya. Metode lainnya adalah terlebih dahulu menerapkan versi abstraksi akun yang lebih ambisius di L2. Namun, tantangan yang dihadapi adalah, tim L2 perlu memiliki kepercayaan penuh pada pekerjaan adopsi proposal agar mau melakukannya, terutama untuk memastikan L1 dan/atau L2 lainnya di masa depan dapat mengadopsi solusi yang kompatibel.

Satu aplikasi lain yang perlu kita pertimbangkan secara jelas adalah akun penyimpanan kunci, yang menyimpan status terkait akun di L1 atau L2 khusus, tetapi dapat digunakan di L1 dan L2 yang kompatibel mana pun. Melakukannya secara efektif mungkin memerlukan L2 untuk mendukung opcode seperti L1SLOAD atau REMOTESTATICCALL, tetapi ini juga memerlukan dukungan implementasi abstraksi akun di L2 untuk operasi tersebut.

Bagaimana ia berinteraksi dengan bagian lain dari peta jalan?

Daftar yang termasuk perlu mendukung transaksi abstraksi akun, dalam praktiknya, kebutuhan daftar yang termasuk sebenarnya sangat mirip dengan kebutuhan memori pool terdesentralisasi, meskipun terhadap