Masa Depan Potensial Protokol Ethereum(Enam): Kemakmuran
Beberapa hal sulit untuk dimasukkan ke dalam satu kategori. Dalam desain protokol Ethereum, banyak "detail" yang sangat penting bagi keberhasilan Ethereum. Sebenarnya, sekitar setengah dari kontennya melibatkan berbagai jenis peningkatan 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 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 perluasan lebih lanjut menjadi sulit. Selain itu, efisiensi EVM yang rendah membuat sulit untuk menerapkan banyak bentuk kriptografi tingkat tinggi, kecuali dengan dukungan 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 dieksekusi antara pemisahan ).
Larangan loncatan dinamis, hanya loncatan statis yang diizinkan
Kode EVM tidak dapat lagi mengamati informasi terkait bahan bakar
Menambahkan mekanisme sub-rutinitas 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 efisiensi yang dibawa oleh EOF—pertama dengan bytecode yang sedikit lebih kecil berkat fitur subrutin, dan kemudian dengan fungsi baru yang spesifik untuk EOF atau biaya gas yang berkurang.
Setelah pengenalan EOF, peningkatan lebih lanjut menjadi lebih mudah, saat ini yang paling berkembang adalah perluasan aritmatika modul EVM ( EVM-MAX ). EVM-MAX menciptakan seperangkat operasi baru yang ditujukan 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) (, di mana SIMD sebagai sebuah konsep dalam Ethereum telah ada sejak lama, pertama kali diusulkan oleh Greg Colvin dalam EIP-616. 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 sebagai pasangan yang alami.
![Vitalik tentang masa depan Ethereum yang mungkin (Enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(
Sebuah desain kasar untuk kombinasi EIP akan dimulai dari EIP-6690, kemudian:
Mengizinkan )i( bilangan ganjil mana pun atau )ii( pangkat 2 mana pun yang paling tinggi adalah 2768 sebagai modulus
Untuk setiap opcode EVM-MAX ) penambahan, pengurangan, perkalian (, tambahkan versi baru yang tidak lagi menggunakan 3 immediate x, y, z, melainkan menggunakan 7 immediate: 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 praktis, ini akan diproses secara paralel.
Mungkin menambahkan XOR, AND, OR, NOT, dan SHIFT) termasuk loop dan non-loop(, setidaknya untuk modulus pangkat 2. Sambil menambahkan ISZERO) yang akan mendorong output ke tumpukan utama EVM(, ini akan cukup kuat untuk menerapkan kriptografi kurva eliptik, kriptografi domain kecil) seperti Poseidon, Circle STARKs(, fungsi hash tradisional) seperti SHA256, KECCAK, BLAKE( dan kriptografi berbasis kisi. Upgrade EVM lainnya juga mungkin diimplementasikan, tetapi sampai saat ini perhatian lebih rendah.
Sisa pekerjaan dan pertimbangan
Saat ini, EOF direncanakan untuk dimasukkan dalam hard fork berikutnya. Meskipun selalu mungkin untuk menghapusnya pada saat-saat terakhir—sebelumnya ada fitur yang sementara dihapus dalam hard fork, tetapi melakukan hal itu akan menghadapi tantangan besar. Menghapus EOF berarti bahwa setiap pembaruan di masa depan untuk EVM 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 mewujudkan fungsi seperti 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 berdampak buruk. Selain itu, EVM-MAX dan SIMD dapat menurunkan biaya gas dari banyak sistem bukti, sehingga membuat L2 lebih efisien. Ini juga membuatnya lebih mudah untuk menggantikan lebih banyak pra-kompilasi 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-8930b556d169a2bc7168ddc2e611d3df.webp(
) abstraksi akun
Masalah apa yang diselesaikan?
Saat ini, transaksi hanya dapat diverifikasi dengan satu cara: tanda tangan ECDSA. Awalnya, abstraksi akun dimaksudkan untuk melampaui ini, memungkinkan logika verifikasi akun untuk kode EVM yang sembarang. Ini dapat mengaktifkan berbagai aplikasi:
Beralih ke kriptografi tahan kuantum
Rotasi kunci lama ### secara luas dianggap sebagai praktik keamanan yang dianjurkan (
Dompet multisignature dan dompet pemulihan sosial
Menggunakan satu kunci untuk operasi nilai rendah, menggunakan kunci lain ) atau sekumpulan kunci ( untuk operasi nilai tinggi
Memungkinkan protokol privasi berfungsi tanpa relay, 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, sebuah 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 mencegah serangan penolakan layanan.
Salah satu tantangan kunci yang khas adalah masalah kegagalan ganda:
Jika ada 1000 fungsi verifikasi akun yang tergantung pada suatu nilai tunggal S, dan nilai S saat ini membuat semua transaksi dalam mempool valid, maka satu transaksi yang membalik nilai S dapat membuat semua transaksi lain dalam mempool tidak valid. Ini memungkinkan penyerang untuk mengirimkan transaksi sampah ke dalam mempool dengan biaya yang sangat rendah, sehingga mengganggu sumber daya node jaringan.
Setelah bertahun-tahun usaha, 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, dan semua eksekusi diproses setelahnya. Dalam memori pool, 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, batasan gas yang ketat juga diberlakukan 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 fitur lainnya. Itulah 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:
EntryPoint sebagai inefisiensi yang melekat pada kontrak: setiap bundel memiliki biaya tetap sekitar 100.000 gas, ditambah ribuan gas tambahan untuk setiap operasi pengguna.
Memastikan pentingnya atribut Ethereum: seperti daftar yang dibuat yang mencakup jaminan yang perlu dipindahkan 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, fungsi 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 fungsionalitas agregasi tanda tangan, seperti agregasi BLS atau agregasi berbasis SNARK. Ini diperlukan untuk mencapai efisiensi data tertinggi di atas Rollup.
![Vitalik tentang masa depan Ethereum yang mungkin (Enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
Sisa pekerjaan dan pertimbangan
Saat ini yang perlu diselesaikan adalah bagaimana mengimplementasikan abstraksi akun sepenuhnya ke dalam protokol, baru-baru ini protokol akun abstraksi yang banyak diminati adalah 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 metode ini terletak pada fakta bahwa ia dengan jelas menunjukkan dua perspektif setara dari abstraksi akun lokal:
Mengintegrasikan EIP-4337 sebagai bagian dari protokol
Sebuah 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 mengizinkan akses ke status eksternal, bahkan batas gas yang ditetapkan pada tahap awal pun rendah sehingga tidak efektif untuk aplikasi yang tahan kuantum atau melindungi privasi—maka keamanan pendekatan ini menjadi sangat jelas: hanya mengganti verifikasi ECDSA dengan eksekusi kode EVM yang memerlukan waktu yang sama.
Namun, seiring berjalannya waktu, kita perlu melonggarkan batasan ini, karena memungkinkan aplikasi perlindungan privasi untuk beroperasi tanpa relai, serta ketahanan kuantum, semuanya 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 ada dua pilihan utama: "menulis dengan cepat sebuah solusi yang memuaskan lebih sedikit orang" versus "menunggu lebih lama, mungkin mendapatkan solusi yang lebih ideal", di mana metode idealnya mungkin adalah semacam pendekatan campuran. Salah satu pendekatan campuran adalah menulis lebih cepat beberapa kasus penggunaan, dan menyisihkan lebih banyak waktu untuk menjelajahi kasus penggunaan lainnya. Pendekatan 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 pekerjaan adopsi proposal tersebut, 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 dengan jelas adalah akun penyimpanan kunci, yang menyimpan status terkait akun di L1 atau L2 khusus, tetapi dapat digunakan di L1 dan L2 yang kompatibel. Melakukan ini secara efektif mungkin memerlukan L2 untuk mendukung opcode seperti L1SLOAD atau REMOTESTATICCALL, tetapi ini juga memerlukan implementasi abstraksi akun di L2 untuk mendukung operasi ini.
Bagaimana ia berinteraksi dengan bagian lain dari peta jalan?
Daftar yang termasuk perlu mendukung transaksi abstraksi akun, dalam praktiknya, kebutuhan daftar yang termasuk sangat mirip dengan kebutuhan kolam memori terdesentralisasi, meskipun fleksibilitas sedikit lebih besar untuk daftar yang termasuk. Selain itu, implementasi abstraksi akun harus sedapat mungkin mencapai koordinasi antara L1 dan L2. Jika di masa depan kita mengharapkan sebagian besar pengguna menggunakan penyimpanan kunci Rollup, desain abstraksi akun harus didasarkan pada hal ini.
Arah evolusi protokol Ethereum: optimasi EVM, akuntabilitas abstrak, dan inovasi mekanisme biaya
Masa Depan Potensial Protokol Ethereum(Enam): Kemakmuran
Beberapa hal sulit untuk dimasukkan ke dalam satu kategori. Dalam desain protokol Ethereum, banyak "detail" yang sangat penting bagi keberhasilan Ethereum. Sebenarnya, sekitar setengah dari kontennya melibatkan berbagai jenis peningkatan EVM, sementara sisanya terdiri dari berbagai topik niche, itulah makna dari "kemakmuran".
Kemakmuran: Tujuan Kunci
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 dengan dukungan 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:
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 efisiensi yang dibawa oleh EOF—pertama dengan bytecode yang sedikit lebih kecil berkat fitur subrutin, dan kemudian dengan fungsi baru yang spesifik untuk EOF atau biaya gas yang berkurang.
Setelah pengenalan EOF, peningkatan lebih lanjut menjadi lebih mudah, saat ini yang paling berkembang adalah perluasan aritmatika modul EVM ( EVM-MAX ). EVM-MAX menciptakan seperangkat operasi baru yang ditujukan 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) (, di mana SIMD sebagai sebuah konsep dalam Ethereum telah ada sejak lama, pertama kali diusulkan oleh Greg Colvin dalam EIP-616. 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 sebagai pasangan yang alami.
![Vitalik tentang masa depan Ethereum yang mungkin (Enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(
Sebuah desain kasar untuk kombinasi EIP akan dimulai dari EIP-6690, kemudian:
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 praktis, ini akan diproses secara paralel.
Sisa pekerjaan dan pertimbangan
Saat ini, EOF direncanakan untuk dimasukkan dalam hard fork berikutnya. Meskipun selalu mungkin untuk menghapusnya pada saat-saat terakhir—sebelumnya ada fitur yang sementara dihapus dalam hard fork, tetapi melakukan hal itu akan menghadapi tantangan besar. Menghapus EOF berarti bahwa setiap pembaruan di masa depan untuk EVM 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 mewujudkan fungsi seperti 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 berdampak buruk. Selain itu, EVM-MAX dan SIMD dapat menurunkan biaya gas dari banyak sistem bukti, sehingga membuat L2 lebih efisien. Ini juga membuatnya lebih mudah untuk menggantikan lebih banyak pra-kompilasi 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-8930b556d169a2bc7168ddc2e611d3df.webp(
) abstraksi akun
Masalah apa yang diselesaikan?
Saat ini, transaksi hanya dapat diverifikasi dengan satu cara: tanda tangan ECDSA. Awalnya, abstraksi akun dimaksudkan untuk melampaui ini, memungkinkan logika verifikasi akun untuk kode EVM yang sembarang. Ini dapat mengaktifkan berbagai aplikasi:
Memungkinkan protokol privasi berfungsi tanpa relay, 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, sebuah 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 mencegah serangan penolakan layanan.
Salah satu tantangan kunci yang khas adalah masalah kegagalan ganda:
Jika ada 1000 fungsi verifikasi akun yang tergantung pada suatu nilai tunggal S, dan nilai S saat ini membuat semua transaksi dalam mempool valid, maka satu transaksi yang membalik nilai S dapat membuat semua transaksi lain dalam mempool tidak valid. Ini memungkinkan penyerang untuk mengirimkan transaksi sampah ke dalam mempool dengan biaya yang sangat rendah, sehingga mengganggu sumber daya node jaringan.
Setelah bertahun-tahun usaha, 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, dan semua eksekusi diproses setelahnya. Dalam memori pool, 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, batasan gas yang ketat juga diberlakukan 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 fitur lainnya. Itulah 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:
Selain itu, ERC-4337 juga memperluas dua fungsi:
![Vitalik tentang masa depan Ethereum yang mungkin (Enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
Sisa pekerjaan dan pertimbangan
Saat ini yang perlu diselesaikan adalah bagaimana mengimplementasikan abstraksi akun sepenuhnya ke dalam protokol, baru-baru ini protokol akun abstraksi yang banyak diminati adalah 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 metode ini terletak pada fakta bahwa ia dengan jelas menunjukkan dua perspektif setara dari abstraksi akun lokal:
Jika kita mulai dengan menetapkan batasan ketat pada kompleksitas kode yang dapat dieksekusi selama periode verifikasi—tidak mengizinkan akses ke status eksternal, bahkan batas gas yang ditetapkan pada tahap awal pun rendah sehingga tidak efektif untuk aplikasi yang tahan kuantum atau melindungi privasi—maka keamanan pendekatan ini menjadi sangat jelas: hanya mengganti verifikasi ECDSA dengan eksekusi kode EVM yang memerlukan waktu yang sama.
Namun, seiring berjalannya waktu, kita perlu melonggarkan batasan ini, karena memungkinkan aplikasi perlindungan privasi untuk beroperasi tanpa relai, serta ketahanan kuantum, semuanya 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 ada dua pilihan utama: "menulis dengan cepat sebuah solusi yang memuaskan lebih sedikit orang" versus "menunggu lebih lama, mungkin mendapatkan solusi yang lebih ideal", di mana metode idealnya mungkin adalah semacam pendekatan campuran. Salah satu pendekatan campuran adalah menulis lebih cepat beberapa kasus penggunaan, dan menyisihkan lebih banyak waktu untuk menjelajahi kasus penggunaan lainnya. Pendekatan 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 pekerjaan adopsi proposal tersebut, 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 dengan jelas adalah akun penyimpanan kunci, yang menyimpan status terkait akun di L1 atau L2 khusus, tetapi dapat digunakan di L1 dan L2 yang kompatibel. Melakukan ini secara efektif mungkin memerlukan L2 untuk mendukung opcode seperti L1SLOAD atau REMOTESTATICCALL, tetapi ini juga memerlukan implementasi abstraksi akun di L2 untuk mendukung operasi ini.
Bagaimana ia berinteraksi dengan bagian lain dari peta jalan?
Daftar yang termasuk perlu mendukung transaksi abstraksi akun, dalam praktiknya, kebutuhan daftar yang termasuk sangat mirip dengan kebutuhan kolam memori terdesentralisasi, meskipun fleksibilitas sedikit lebih besar untuk daftar yang termasuk. Selain itu, implementasi abstraksi akun harus sedapat mungkin mencapai koordinasi antara L1 dan L2. Jika di masa depan kita mengharapkan sebagian besar pengguna menggunakan penyimpanan kunci Rollup, desain abstraksi akun harus didasarkan pada hal ini.
![Vitalik tentang masa depan Ethereum yang mungkin (