Arah Pengembangan Masa Depan Protokol Ethereum: Bagian Kemakmuran

Dalam protokol Ethereum, ada banyak "detail" yang sangat penting untuk kesuksesannya. Sebenarnya, sekitar setengah dari kontennya terkait dengan berbagai jenis perbaikan EVM, sementara sisanya terdiri dari berbagai topik niche, itulah 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 ekonomi biaya transaksi, meningkatkan skalabilitas sambil mengurangi risiko
• Menjelajahi kriptografi yang canggih, sehingga Ethereum dapat meningkat secara signifikan dalam jangka panjang

EVM perbaikan

Masalah apa yang diselesaikan?

Saat ini, EVM sulit untuk melakukan analisis statis, yang membuat penciptaan 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 didukung secara eksplisit melalui prapengompilan.

Apa itu, bagaimana cara kerjanya?

Langkah pertama dari peta jalan peningkatan EVM saat ini adalah format objek EVM (EOF), yang direncanakan untuk dimasukkan dalam pembagian keras 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 mengeksekusi antara pemisahan ).
• Dilarang melakukan pengalihan dinamis, hanya pengalihan 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 secara bertahap ditinggalkan dengan kontrak lama ( bahkan mungkin dipaksa untuk beralih ke kode EOF ). Kontrak baru akan mendapatkan manfaat dari peningkatan efisiensi yang dibawa oleh EOF -- pertama-tama melalui bytecode yang sedikit lebih kecil berkat fitur subrutin, kemudian dengan fungsi baru yang spesifik untuk EOF atau pengurangan biaya gas.

Setelah memperkenalkan EOF, peningkatan lebih lanjut menjadi lebih mudah, yang paling berkembang saat ini adalah perluasan aritmatika modul EVM ( EVM-MAX ). EVM-MAX menciptakan serangkaian operasi baru yang ditujukan 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 menjadikan kedua ekspansi yang berorientasi pada kinerja ini sebagai pasangan yang alami.

Tautan penelitian yang ada

• EOF:
• EVM-MAX:
• SIMD:

Pekerjaan yang tersisa dan pertimbangan

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

Pertimbangan utama EVM adalah kompleksitas L1 dan kompleksitas infrastruktur, EOF adalah banyak kode yang perlu ditambahkan ke implementasi EVM, dan pemeriksaan kode statis juga relatif kompleks. Namun, sebagai imbalannya, kita dapat menyederhanakan bahasa tingkat tinggi, menyederhanakan implementasi EVM, dan manfaat lainnya. Bisa dikatakan, prioritas untuk peta jalan perbaikan berkelanjutan Ethereum L1 harus mencakup dan dibangun di atas EOF.

Salah satu pekerjaan penting yang perlu dilakukan adalah merealisasikan fungsi serupa EVM-MAX ditambah SIMD, dan melakukan pengujian kinerja konsumsi gas untuk 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 membuat L2 lebih efisien. Ini juga membuat lebih mudah untuk mengganti lebih banyak pra-kompilasi dengan kode EVM yang dapat menjalankan tugas yang sama, yang mungkin tidak berdampak besar pada efisiensi.

abstraksi akun

Apa masalah yang diselesaikan?

Saat ini, transaksi hanya dapat divalidasi melalui satu cara: tanda tangan ECDSA. Pada awalnya, abstraksi akun dirancang untuk melampaui ini, memungkinkan logika validasi akun untuk menjadi kode EVM yang sembarang. Ini dapat mengaktifkan serangkaian aplikasi:

• Beralih ke kriptografi tahan 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 sekelompok kunci ) untuk operasi nilai tinggi

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

Sejak pengajuan abstraksi akun pada tahun 2015, tujuannya juga telah meluas untuk mencakup banyak "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 hal ini dengan cara yang ramah terhadap pemeliharaan jaringan terdesentralisasi, dan melindungi dari serangan penolakan layanan.

Salah satu tantangan kunci yang khas adalah masalah kegagalan ganda:

Jika ada 1000 fungsi validasi akun yang bergantung pada satu nilai tunggal S, dan nilai S saat ini membuat semua transaksi di mempool valid, maka satu transaksi yang membalikkan nilai S dapat membuat semua transaksi lain di mempool menjadi tidak valid. Ini memungkinkan penyerang untuk mengirimkan transaksi sampah ke mempool 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 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 oleh semua eksekusi. Di dalam mempool, hanya ketika tahap verifikasi 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 diberlakukan secara ketat 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 fitur lainnya. Inilah sebabnya mengapa ERC-4337 menggunakan objek yang disebut operasi pengguna, alih-alih transaksi biasa. Namun, baru-baru ini kami menyadari perlunya menuliskan setidaknya sebagian dari konten tersebut ke dalam protokol.

Dua alasan kunci adalah sebagai berikut:

1. EntryPoint sebagai inefisiensi bawaan kontrak: setiap bundel memiliki biaya tetap sekitar 100.000 gas, ditambah beberapa ribu 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, fungsi ini melanggar aturan bahwa fase verifikasi hanya dapat mengakses akun pengirim itu sendiri, sehingga pengenalan penanganan khusus untuk memastikan keamanan mekanisme pembayaran agen.
• Aggregator ( Aggregators ): Mendukung fungsi agregasi tanda tangan, seperti agregasi BLS atau agregasi berbasis SNARK. Ini penting untuk mencapai efisiensi data tertinggi pada Rollup.

Tautan penelitian yang ada

• Pembicaraan tentang sejarah abstraksi akun:
• ERC-4337:
• EIP-7702:
• Kode BLSWallet ( menggunakan fitur agregasi ):
• EIP-7562( menulis protokol akun abstrak ):
• EIP-7701( akun abstrak protokol penulisan berbasis EOF ):

Sisa pekerjaan dan pertimbangan

Saat ini, yang perlu diatasi adalah bagaimana sepenuhnya mengintegrasikan abstraksi akun ke dalam protokol, baru-baru ini yang populer adalah EIP abstraksi akun yang ditulis ke dalam protokol yaitu EIP-7701, proposal ini 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 dari metode ini terletak pada, itu dengan 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 batas ketat pada kompleksitas kode yang dapat dieksekusi selama periode verifikasi--tidak diizinkan mengakses status eksternal, bahkan batas gas yang ditetapkan pada tahap awal sangat 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 melonggarkan batasan ini, karena memungkinkan aplikasi perlindungan privasi untuk bekerja 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 harus sangat sederhana.

Tampaknya pertimbangannya adalah "menulis dengan cepat sebuah solusi yang memuaskan sedikit orang" versus "menunggu lebih lama, mungkin mendapatkan solusi yang lebih ideal", di mana 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 lain adalah terlebih dahulu menerapkan versi abstraksi akun yang lebih ambisius di L2. Namun, tantangan yang dihadapi adalah tim L2 perlu memiliki keyakinan penuh terhadap kerja proposal yang diadopsi agar bersedia untuk melaksanakannya, terutama untuk memastikan bahwa 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. Untuk melakukannya secara efektif, mungkin diperlukan dukungan L2 untuk opcode seperti L1SLOAD atau REMOTESTATICCALL, tetapi ini juga memerlukan dukungan implementasi abstraksi akun di L2 untuk operasi ini.

Bagaimana ia berinteraksi dengan bagian lain dari peta jalan?

Daftar inklusi perlu mendukung transaksi abstraksi akun. Dalam praktiknya, kebutuhan daftar inklusi sebenarnya sangat mirip dengan kebutuhan memori pool terdesentralisasi, meskipun untuk daftar inklusi ada sedikit lebih banyak fleksibilitas. Selain itu, implementasi abstraksi akun harus sejalan sebisa mungkin antara L1 dan L2. Jika di masa depan kita mengharapkan sebagian besar pengguna menggunakan penyimpanan kunci Rollup, desain abstraksi akun harus didasarkan pada ini.

perbaikan EIP-1559

Apa masalah yang diselesaikannya?

EIP-1559 diaktifkan di Ethereum pada tahun 2021, secara signifikan meningkatkan waktu rata-rata penyertaan blok.

Namun, implementasi EIP-1559 saat ini tidak sempurna dalam banyak hal:

1. Rumus ini memiliki sedikit cacat: itu bukan ditujukan pada 50% blok, tetapi sekitar 50-53% blok penuh, tergantung pada varians ( ini terkait dengan apa yang disebut matematikawan sebagai "ketidaksetaraan rata-rata aritmetika-geometrik"