Dalam desain protokol Ethereum, ada banyak "detail" penting yang krusial untuk keberhasilannya. Sebenarnya, sekitar setengah dari kontennya berkaitan dengan berbagai jenis perbaikan EVM, sementara sisanya terdiri dari berbagai topik kecil, itulah arti dari "kemakmuran".
Kemakmuran: Tujuan Utama
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 biaya perdagangan, meningkatkan skalabilitas sambil mengurangi risiko
Menjelajahi kriptografi canggih, sehingga Ethereum dapat meningkat secara signifikan dalam jangka panjang
EVM perbaikan
Masalah apa yang diselesaikan?
Saat ini, EVM sulit untuk 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 dengan dukungan eksplisit melalui 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 pemisahan antara ) dan data ( yang dapat dibaca, tetapi tidak dapat dieksekusi ).
Larangan perpindahan dinamis, hanya diperbolehkan perpindahan statis
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 mendapatkan manfaat dari peningkatan efisiensi yang dibawa oleh EOF -- pertama melalui bytecode yang sedikit lebih kecil berkat fitur subrutin, kemudian dengan fungsionalitas baru khusus EOF atau pengurangan biaya gas.
Setelah memperkenalkan EOF, peningkatan lebih lanjut menjadi lebih mudah, saat ini perkembangan yang paling matang adalah perluasan aritmatika modul EVM ( EVM-MAX ). EVM-MAX menciptakan serangkaian operasi baru yang secara khusus ditujukan untuk operasi modulo, dan menempatkannya di ruang memori baru yang tidak dapat diakses melalui opcode lain, sehingga memungkinkan penggunaan optimasi seperti perkalian Montgomery.
Sebuah ide yang lebih baru adalah menggabungkan EVM-MAX dengan kemampuan SIMD (Single Instruction, Multiple Data) (, di mana SIMD sebagai sebuah konsep dalam Ethereum sudah ada sejak lama, awalnya 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 membuat kedua skala yang berorientasi pada performa ini menjadi pasangan yang alami.
Sebuah desain kasar untuk kombinasi EIP akan dimulai dari EIP-6690, lalu:
Mengizinkan )i( bilangan ganjil mana pun atau )ii( pangkat 2 yang maksimum adalah 2768 sebagai modulus
Untuk setiap opcode EVM-MAX ) penjumlahan, pengurangan, perkalian (, tambahkan satu versi, versi ini tidak lagi menggunakan 3 bilangan langsung x, y, z, tetapi 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:
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. Sambil menambahkan ISZERO) akan mengeluarkan dorongan ke tumpukan utama EVM(, yang akan cukup kuat untuk mengimplementasikan kriptografi kurva elips, kriptografi bidang kecil) seperti Poseidon, Circle STARKs(, fungsi hash tradisional) seperti SHA256, KECCAK, BLAKE( dan kriptografi berbasis kisi. Pembaruan EVM lainnya juga mungkin diimplementasikan, tetapi sampai saat ini perhatian lebih rendah.
![Vitalik tentang masa depan Ethereum yang mungkin (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 ada kemungkinan untuk menghapusnya pada saat terakhir -- pada hard fork sebelumnya ada fitur yang dihapus sementara, namun melakukan hal tersebut akan menghadapi tantangan besar. Menghapus EOF berarti bahwa setiap peningkatan EVM di masa depan harus dilakukan tanpa EOF, meskipun mungkin untuk melakukannya, tetapi bisa jadi lebih sulit.
Timbal balik utama EVM adalah kompleksitas L1 dan kompleksitas infrastruktur, EOF adalah banyak 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 prioritas untuk peta jalan peningkatan berkelanjutan Ethereum L1 harus mencakup dan dibangun di atas EOF.
Pekerjaan penting yang perlu dilakukan adalah mewujudkan fungsi yang mirip dengan EVM-MAX ditambah SIMD, serta melakukan pengujian benchmark terhadap konsumsi gas berbagai operasi kripto.
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 mengurangi biaya gas dari banyak sistem bukti, 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 akan berdampak besar terhadap efisiensi.
![Vitalik tentang masa depan Ethereum yang mungkin (Enam): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
) abstraksi akun
Masalah apa yang dipecahkan?
Saat ini, transaksi hanya dapat divalidasi dengan satu cara: tanda tangan ECDSA. Awalnya, abstraksi akun dimaksudkan untuk melampaui ini, memungkinkan logika validasi akun untuk kode EVM yang arbitrer. Ini dapat mengaktifkan serangkaian aplikasi:
Beralih ke kriptografi tahan kuantum
Mengganti kunci lama ### secara luas dianggap sebagai praktik keamanan yang disarankan (
Dompet multisignature dan dompet pemulihan sosial
Menggunakan satu kunci untuk operasi nilai rendah, menggunakan kunci lain ) atau sekelompok kunci ( untuk operasi nilai tinggi
Memungkinkan protokol privasi bekerja tanpa perantara, secara signifikan mengurangi kompleksitasnya, dan menghilangkan satu titik ketergantungan pusat yang penting.
Sejak pengenalan abstraksi akun pada tahun 2015, tujuannya juga telah diperluas 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 mewujudkannya dengan cara yang ramah terhadap pemeliharaan jaringan terdesentralisasi, dan mencegah serangan penolakan layanan.
Tantangan kunci yang khas adalah masalah kegagalan ganda: jika ada 1000 fungsi verifikasi akun yang bergantung pada nilai tunggal S, dan nilai S saat ini membuat transaksi dalam mempool semuanya valid, maka satu transaksi yang membalikkan nilai S mungkin membuat semua transaksi lain dalam mempool menjadi tidak valid. Ini memungkinkan penyerang untuk mengirim transaksi sampah ke mempool dengan biaya yang sangat rendah, sehingga menyumbat sumber daya node jaringan.
Setelah bertahun-tahun usaha, yang bertujuan untuk memperluas fungsi sambil membatasi risiko penolakan layanan ###DoS(, akhirnya mencapai solusi untuk mewujudkan "abstraksi akun ideal": ERC-4337.
![Vitalik tentang masa depan Ethereum yang mungkin (Enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
Cara kerja ERC-4337 adalah membagi pemrosesan operasi pengguna menjadi dua tahap: verifikasi dan eksekusi. Semua verifikasi diproses terlebih dahulu, kemudian semua eksekusi diproses. 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 diterapkan pada langkah verifikasi.
ERC-4337 dirancang sebagai standar protokol tambahan )ERC(, karena saat itu pengembang klien Ethereum fokus pada penggabungan )Merge(, tidak memiliki energi tambahan untuk menangani fungsi lainnya. Inilah sebabnya mengapa ERC-4337 menggunakan objek yang disebut operasi pengguna, bukan transaksi biasa. Namun, baru-baru ini kami menyadari perlunya menuliskan setidaknya sebagian dari konten tersebut ke dalam protokol.
Dua alasan kunci adalah sebagai berikut:
EntryPoint sebagai inherent ineffisiensi kontrak: setiap bundel memiliki biaya tetap sekitar 100.000 gas, ditambah ribuan gas tambahan untuk setiap operasi pengguna.
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 mewakili akun lain untuk membayar biaya, ini melanggar aturan bahwa fase verifikasi hanya dapat mengakses akun pengirim itu sendiri, oleh karena itu pengenalan 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 masa depan Ethereum yang mungkin (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 mengimplementasikan abstraksi akun sepenuhnya ke dalam protokol. EIP yang baru-baru ini populer mengenai abstraksi akun 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 dijalankan dalam langkah verifikasi untuk transaksi yang berasal dari akun tersebut.
Daya tarik dari metode ini terletak pada fakta bahwa ia dengan jelas menunjukkan dua perspektif setara dari abstraksi akun lokal:
Menjadikan EIP-4337 sebagai bagian dari protokol
Jenis EOA baru, di mana algoritma tanda tangannya adalah eksekusi kode EVM
Jika kita mulai dengan menetapkan batas ketat pada kompleksitas kode yang dapat dieksekusi selama periode verifikasi--tidak mengizinkan akses ke status eksternal, bahkan batas gas yang ditetapkan pada awalnya juga rendah hingga 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 waktu, kita perlu melonggarkan batasan ini, karena memungkinkan aplikasi perlindungan privasi 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 trade-off utama adalah "menulis cepat sebuah solusi yang kurang memuaskan bagi banyak orang" 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 untuk beberapa kasus penggunaan, dan menyisihkan 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 pekerjaan adopsi proposal, agar bersedia untuk melaksanakannya, terutama untuk memastikan bahwa L1 dan/atau L2 lainnya di masa depan dapat mengadopsi solusi yang kompatibel.
![Vitalik tentang masa depan Ethereum yang mungkin (Enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-fe95dd28b911aea1a22365468b7c42cd.webp(
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. Melakukan ini secara efektif mungkin memerlukan dukungan L2 untuk hal-hal seperti L1SLOAD atau REMOTESTATI.
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
13 Suka
Hadiah
13
4
Bagikan
Komentar
0/400
MEVHunterX
· 07-20 06:40
Teruskan biaya gas ya
Lihat AsliBalas0
BoredRiceBall
· 07-20 06:40
Ether saya akhirnya bisa menjadi lebih kuat
Lihat AsliBalas0
NeverVoteOnDAO
· 07-20 06:35
Sulit sekali, cepatlah upgrade
Lihat AsliBalas0
MemeKingNFT
· 07-20 06:18
Ai, kemakmuran terlalu jauh, tunggu aku buy the dip investasi recoup dulu.
Roadmap masa depan Ethereum: Upgrade EVM, abstraksi akun, dan perbaikan 1559
Masa Depan Protokol Ethereum ( Enam ): Kemakmuran
Dalam desain protokol Ethereum, ada banyak "detail" penting yang krusial untuk keberhasilannya. Sebenarnya, sekitar setengah dari kontennya berkaitan dengan berbagai jenis perbaikan EVM, sementara sisanya terdiri dari berbagai topik kecil, itulah arti dari "kemakmuran".
Kemakmuran: Tujuan Utama
EVM perbaikan
Masalah apa yang diselesaikan?
Saat ini, EVM sulit untuk 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 dengan dukungan eksplisit melalui 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:
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 peningkatan efisiensi yang dibawa oleh EOF -- pertama melalui bytecode yang sedikit lebih kecil berkat fitur subrutin, kemudian dengan fungsionalitas baru khusus EOF atau pengurangan biaya gas.
Setelah memperkenalkan EOF, peningkatan lebih lanjut menjadi lebih mudah, saat ini perkembangan yang paling matang adalah perluasan aritmatika modul EVM ( EVM-MAX ). EVM-MAX menciptakan serangkaian operasi baru yang secara khusus ditujukan untuk operasi modulo, dan menempatkannya di ruang memori baru yang tidak dapat diakses melalui opcode lain, sehingga memungkinkan penggunaan optimasi seperti perkalian Montgomery.
Sebuah ide yang lebih baru adalah menggabungkan EVM-MAX dengan kemampuan SIMD (Single Instruction, Multiple Data) (, di mana SIMD sebagai sebuah konsep dalam Ethereum sudah ada sejak lama, awalnya 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 membuat kedua skala yang berorientasi pada performa ini menjadi pasangan yang alami.
Sebuah desain kasar untuk kombinasi EIP akan dimulai dari EIP-6690, lalu:
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.
![Vitalik tentang masa depan Ethereum yang mungkin (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 ada kemungkinan untuk menghapusnya pada saat terakhir -- pada hard fork sebelumnya ada fitur yang dihapus sementara, namun melakukan hal tersebut akan menghadapi tantangan besar. Menghapus EOF berarti bahwa setiap peningkatan EVM di masa depan harus dilakukan tanpa EOF, meskipun mungkin untuk melakukannya, tetapi bisa jadi lebih sulit.
Timbal balik utama EVM adalah kompleksitas L1 dan kompleksitas infrastruktur, EOF adalah banyak 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 prioritas untuk peta jalan peningkatan berkelanjutan Ethereum L1 harus mencakup dan dibangun di atas EOF.
Pekerjaan penting yang perlu dilakukan adalah mewujudkan fungsi yang mirip dengan EVM-MAX ditambah SIMD, serta melakukan pengujian benchmark terhadap konsumsi gas berbagai operasi kripto.
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 mengurangi biaya gas dari banyak sistem bukti, 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 akan berdampak besar terhadap efisiensi.
![Vitalik tentang masa depan Ethereum yang mungkin (Enam): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
) abstraksi akun
Masalah apa yang dipecahkan?
Saat ini, transaksi hanya dapat divalidasi dengan satu cara: tanda tangan ECDSA. Awalnya, abstraksi akun dimaksudkan untuk melampaui ini, memungkinkan logika validasi akun untuk kode EVM yang arbitrer. Ini dapat mengaktifkan serangkaian aplikasi:
Memungkinkan protokol privasi bekerja tanpa perantara, secara signifikan mengurangi kompleksitasnya, dan menghilangkan satu titik ketergantungan pusat yang penting.
Sejak pengenalan abstraksi akun pada tahun 2015, tujuannya juga telah diperluas 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 mewujudkannya dengan cara yang ramah terhadap pemeliharaan jaringan terdesentralisasi, dan mencegah serangan penolakan layanan.
Tantangan kunci yang khas adalah masalah kegagalan ganda: jika ada 1000 fungsi verifikasi akun yang bergantung pada nilai tunggal S, dan nilai S saat ini membuat transaksi dalam mempool semuanya valid, maka satu transaksi yang membalikkan nilai S mungkin membuat semua transaksi lain dalam mempool menjadi tidak valid. Ini memungkinkan penyerang untuk mengirim transaksi sampah ke mempool dengan biaya yang sangat rendah, sehingga menyumbat sumber daya node jaringan.
Setelah bertahun-tahun usaha, yang bertujuan untuk memperluas fungsi sambil membatasi risiko penolakan layanan ###DoS(, akhirnya mencapai solusi untuk mewujudkan "abstraksi akun ideal": ERC-4337.
![Vitalik tentang masa depan Ethereum yang mungkin (Enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
Cara kerja ERC-4337 adalah membagi pemrosesan operasi pengguna menjadi dua tahap: verifikasi dan eksekusi. Semua verifikasi diproses terlebih dahulu, kemudian semua eksekusi diproses. 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 diterapkan pada langkah verifikasi.
ERC-4337 dirancang sebagai standar protokol tambahan )ERC(, karena saat itu pengembang klien Ethereum fokus pada penggabungan )Merge(, tidak memiliki energi tambahan untuk menangani fungsi lainnya. Inilah sebabnya mengapa ERC-4337 menggunakan objek yang disebut operasi pengguna, bukan transaksi biasa. Namun, baru-baru ini kami menyadari perlunya menuliskan 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-c0f722db75e53f4ff37ef40f5547dfc4.webp(
)# Pekerjaan yang tersisa dan pertimbangan
Saat ini, yang perlu diselesaikan adalah bagaimana mengimplementasikan abstraksi akun sepenuhnya ke dalam protokol. EIP yang baru-baru ini populer mengenai abstraksi akun 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 dijalankan dalam langkah verifikasi untuk transaksi yang berasal dari akun tersebut.
Daya tarik dari metode ini terletak pada fakta bahwa ia dengan jelas menunjukkan dua perspektif setara dari abstraksi akun lokal:
Jika kita mulai dengan menetapkan batas ketat pada kompleksitas kode yang dapat dieksekusi selama periode verifikasi--tidak mengizinkan akses ke status eksternal, bahkan batas gas yang ditetapkan pada awalnya juga rendah hingga 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 waktu, kita perlu melonggarkan batasan ini, karena memungkinkan aplikasi perlindungan privasi 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 trade-off utama adalah "menulis cepat sebuah solusi yang kurang memuaskan bagi banyak orang" 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 untuk beberapa kasus penggunaan, dan menyisihkan 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 pekerjaan adopsi proposal, agar bersedia untuk melaksanakannya, terutama untuk memastikan bahwa L1 dan/atau L2 lainnya di masa depan dapat mengadopsi solusi yang kompatibel.
![Vitalik tentang masa depan Ethereum yang mungkin (Enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-fe95dd28b911aea1a22365468b7c42cd.webp(
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. Melakukan ini secara efektif mungkin memerlukan dukungan L2 untuk hal-hal seperti L1SLOAD atau REMOTESTATI.