Masa Depan Protokol Ethereum yang Mungkin (Enam): Kemakmuran
Desain protokol Ethereum memiliki banyak "detail" yang sangat penting untuk keberhasilannya. Sebenarnya, sekitar setengah dari isi melibatkan berbagai jenis peningkatan EVM, sementara sisanya terdiri dari berbagai topik kecil, inilah yang dimaksud dengan "kompleksitas".
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 canggih, sehingga 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 menyulitkan penerapan banyak bentuk kriptografi tingkat tinggi, kecuali jika didukung secara eksplisit melalui prekompilasi.
Apa itu, dan bagaimana cara kerjanya?
Langkah pertama dari roadmap perbaikan EVM saat ini adalah format objek EVM (EOF), yang direncanakan untuk dimasukkan dalam hard fork berikutnya. EOF adalah serangkaian EIP yang menetapkan versi baru kode EVM, 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 diizinkan
Kode EVM tidak dapat lagi mengamati informasi terkait bahan bakar
Menambahkan mekanisme subrutin 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 dengan bytecode yang sedikit diperkecil melalui fitur subrutin, kemudian dengan fungsi baru khusus EOF atau pengurangan biaya gas.
Setelah pengenalan EOF, peningkatan lebih lanjut menjadi lebih mudah, saat ini perkembangan yang paling matang adalah perluasan aritmatika modul EVM ( EVM-MAX ). EVM-MAX menciptakan sekumpulan operasi baru yang khusus untuk operasi modulus, 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 SIMD (Single Instruction Multiple Data) (, SIMD sebagai sebuah konsep di Ethereum telah ada sejak lama, pertama kali diajukan oleh Greg Colvin dalam EIP-616. SIMD dapat digunakan untuk mempercepat banyak bentuk kriptografi, termasuk fungsi hash, STARKs 32-bit, dan kriptografi berbasis kisi. Kombinasi EVM-MAX dan SIMD membuat kedua skala yang berorientasi pada kinerja ini menjadi pasangan yang alami.
![Vitalik tentang masa depan Ethereum yang mungkin (Enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
Sebuah desain kasar untuk kombinasi EIP akan dimulai dari EIP-6690, kemudian:
Mengizinkan )i( setiap bilangan ganjil atau )ii( setiap pangkat 2 tertinggi yang tidak melebihi 2768 sebagai modulus
Untuk setiap opcode EVM-MAX ) penjumlahan, pengurangan, perkalian (, tambahkan sebuah versi, yang tidak lagi menggunakan 3 nilai langsung x, y, z, tetapi menggunakan 7 nilai 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 mengeluarkan dorongan 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 hingga saat ini perhatian terhadapnya masih rendah.
) Tautan penelitian yang ada
EOF:
EVM-MAX:
SIMD:
Sisa pekerjaan dan pertimbangan
Saat ini, EOF direncanakan untuk dimasukkan dalam hard fork berikutnya. Meskipun selalu mungkin untuk menghapusnya pada saat terakhir — pada hard fork sebelumnya, beberapa fungsi pernah dihapus sementara, namun melakukan hal itu akan menghadapi tantangan besar. Menghapus EOF berarti bahwa setiap peningkatan EVM di masa depan harus dilakukan tanpa EOF, meskipun hal itu mungkin dilakukan, tetapi bisa menjadi lebih sulit.
Pertimbangan utama EVM adalah kompleksitas L1 dan kompleksitas infrastruktur, EOF adalah sejumlah besar kode yang perlu ditambahkan ke 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 peningkatan berkelanjutan Ethereum L1 harus mencakup dan dibangun di atas EOF.
Pekerjaan penting yang perlu dilakukan adalah untuk mewujudkan fungsi serupa 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, hal ini dapat menyebabkan ketidakcocokan dan membawa dampak negatif. Selain itu, EVM-MAX dan SIMD dapat mengurangi biaya gas dari banyak sistem bukti, sehingga membuat L2 lebih efisien. Ini juga membuatnya lebih mudah untuk mengganti lebih banyak pra-kompilasi dengan kode EVM yang dapat menjalankan tugas yang sama, yang mungkin tidak akan berdampak besar pada efisiensi.
![Vitalik tentang masa depan Ethereum yang mungkin (Enam): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
Abstraksi Akun
) Apa masalah yang diselesaikan?
Saat ini, transaksi hanya dapat diverifikasi dengan satu cara: tanda tangan ECDSA. Awalnya, abstraksi akun bertujuan untuk melampaui ini, memungkinkan logika verifikasi akun untuk kode EVM yang arbitrer. Ini dapat mengaktifkan berbagai aplikasi:
Beralih ke kriptografi tahan kuantum
Menggantikan 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 satu set kunci ( untuk operasi nilai tinggi.
Memungkinkan protokol privasi berfungsi tanpa perantara, secara signifikan mengurangi kompleksitasnya, dan menghilangkan satu titik ketergantungan pusat yang penting.
Sejak pengajuan abstraksi akun pada tahun 2015, tujuannya juga telah diperluas untuk mencakup sejumlah "tujuan kenyamanan", misalnya, akun yang tidak memiliki ETH tetapi memiliki beberapa ERC20 dapat menggunakan ERC20 untuk membayar gas.
MPC) penghitungan multi pihak( adalah teknologi yang sudah 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 semakin meningkat tentang penyediaan kenyamanan abstraksi akun untuk menguntungkan semua pengguna ) termasuk pengguna EOA (, bertujuan untuk meningkatkan pengalaman semua pengguna dalam jangka pendek dan menghindari perpecahan menjadi dua ekosistem.
Pekerjaan ini dimulai dengan EIP-3074 dan akhirnya membentuk EIP-7702. EIP-7702 menyediakan "fungsi kenyamanan" abstraksi akun untuk semua pengguna, termasuk EOA) akun yang dimiliki secara eksternal, yaitu akun yang dikendalikan oleh tanda tangan ECDSA (.
Meskipun beberapa tantangan ) terutama tantangan "kenyamanan" ( dapat diatasi melalui teknologi bertahap seperti komputasi multipihak atau EIP-7702, tetapi 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 terletak pada implementasi yang aman, yang merupakan tantangan.
![Vitalik tentang kemungkinan masa depan Ethereum (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 bergantung pada satu nilai S, dan nilai S saat ini membuat transaksi dalam mempool semuanya valid, maka satu transaksi yang membalik nilai S dapat membuat semua transaksi lainnya dalam mempool menjadi tidak valid. Ini memungkinkan penyerang untuk mengirimkan transaksi sampah ke mempool dengan biaya yang sangat rendah, sehingga membebani sumber daya node jaringan.
Setelah bertahun-tahun berusaha, yang bertujuan untuk memperluas fungsionalitas sambil membatasi risiko penolakan layanan ###DoS(, akhirnya dihasilkan 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 kemudian. Dalam memori pool, 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 untuk 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 ERC-4337 menggunakan objek yang disebut operasi pengguna, alih-alih 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 inherent ineffisiensi kontrak: setiap bundel memiliki biaya tetap sekitar 100,000 gas, serta tambahan ribuan gas untuk setiap operasi pengguna.
Memastikan pentingnya atribut Ethereum: seperti daftar yang dibuat yang mencakup jaminan yang perlu dipindahkan ke pengguna akun abstrak.
![Vitalik tentang masa depan Ethereum yang mungkin (Enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
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 pada tahap verifikasi hanya dapat mengakses akun pengirim itu sendiri, oleh karena itu diperkenalkan penanganan khusus untuk memastikan keamanan mekanisme agen pembayaran.
Aggregator ) Aggregators (: Mendukung fungsi penggabungan tanda tangan, seperti penggabungan BLS atau penggabungan berbasis SNARK. Ini diperlukan untuk mencapai efisiensi data tertinggi di Rollup.
) Tautan penelitian yang ada
Tentang sejarah abstraksi akun:
ERC-4337:
EIP-7702:
Kode BLSWallet ### menggunakan fitur agregasi (:
EIP-7562) menulis protokol akuntabilitas (:
EIP-7701) akun abstraksi protokol penulisan berbasis EOF (:
) pekerjaan yang tersisa dan pertimbangan
Saat ini, yang perlu diselesaikan adalah bagaimana cara sepenuhnya mengintegrasikan abstraksi akun ke dalam protokol. EIP abstraksi akun yang baru-baru ini populer adalah EIP-7701, yang mengimplementasikan abstraksi akun di atas EOF. Sebuah akun dapat memiliki bagian kode terpisah untuk verifikasi, dan jika akun mengatur bagian kode tersebut, maka kode itu akan dieksekusi dalam langkah verifikasi dari transaksi yang berasal dari akun tersebut.
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.
17 Suka
Hadiah
17
5
Posting ulang
Bagikan
Komentar
0/400
GweiTooHigh
· 08-12 00:28
Apakah account abstraction benar-benar bisa tersebar luas?
Lihat AsliBalas0
MEVictim
· 08-10 08:39
Jadi ini hanya soal EVM, tidak menarik.
Lihat AsliBalas0
BlockchainDecoder
· 08-10 08:39
Merujuk pada data makalah RV tahun 2022, efisiensi tumpukan arsitektur EVM yang ada saat ini hanya 42%, yang memang sangat perlu dioptimalkan.
Lihat AsliBalas0
PessimisticOracle
· 08-10 08:39
Sudah berbicara lama, tidak lain hanya omong kosong? Jika benar-benar bisa terwujud, saya mengaku kalah.
Prospek Masa Depan Ethereum: Pembaruan EVM dan Abstraksi Akun Memimpin Tahap Kemakmuran Baru
Masa Depan Protokol Ethereum yang Mungkin (Enam): Kemakmuran
Desain protokol Ethereum memiliki banyak "detail" yang sangat penting untuk keberhasilannya. Sebenarnya, sekitar setengah dari isi melibatkan berbagai jenis peningkatan EVM, sementara sisanya terdiri dari berbagai topik kecil, inilah yang dimaksud dengan "kompleksitas".
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 menyulitkan penerapan banyak bentuk kriptografi tingkat tinggi, kecuali jika didukung secara eksplisit melalui prekompilasi.
Apa itu, dan bagaimana cara kerjanya?
Langkah pertama dari roadmap perbaikan EVM saat ini adalah format objek EVM (EOF), yang direncanakan untuk dimasukkan dalam hard fork berikutnya. EOF adalah serangkaian EIP yang menetapkan versi baru kode EVM, 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 dengan bytecode yang sedikit diperkecil melalui fitur subrutin, kemudian dengan fungsi baru khusus EOF atau pengurangan biaya gas.
Setelah pengenalan EOF, peningkatan lebih lanjut menjadi lebih mudah, saat ini perkembangan yang paling matang adalah perluasan aritmatika modul EVM ( EVM-MAX ). EVM-MAX menciptakan sekumpulan operasi baru yang khusus untuk operasi modulus, 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 SIMD (Single Instruction Multiple Data) (, SIMD sebagai sebuah konsep di Ethereum telah ada sejak lama, pertama kali diajukan oleh Greg Colvin dalam EIP-616. SIMD dapat digunakan untuk mempercepat banyak bentuk kriptografi, termasuk fungsi hash, STARKs 32-bit, dan kriptografi berbasis kisi. Kombinasi EVM-MAX dan SIMD membuat kedua skala yang berorientasi pada kinerja ini menjadi pasangan yang alami.
![Vitalik tentang masa depan Ethereum yang mungkin (Enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.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 nyata, ini akan diproses secara paralel.
) Tautan penelitian yang ada
Sisa pekerjaan dan pertimbangan
Saat ini, EOF direncanakan untuk dimasukkan dalam hard fork berikutnya. Meskipun selalu mungkin untuk menghapusnya pada saat terakhir — pada hard fork sebelumnya, beberapa fungsi pernah dihapus sementara, namun melakukan hal itu akan menghadapi tantangan besar. Menghapus EOF berarti bahwa setiap peningkatan EVM di masa depan harus dilakukan tanpa EOF, meskipun hal itu mungkin dilakukan, tetapi bisa menjadi lebih sulit.
Pertimbangan utama EVM adalah kompleksitas L1 dan kompleksitas infrastruktur, EOF adalah sejumlah besar kode yang perlu ditambahkan ke 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 peningkatan berkelanjutan Ethereum L1 harus mencakup dan dibangun di atas EOF.
Pekerjaan penting yang perlu dilakukan adalah untuk mewujudkan fungsi serupa 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, hal ini dapat menyebabkan ketidakcocokan dan membawa dampak negatif. Selain itu, EVM-MAX dan SIMD dapat mengurangi biaya gas dari banyak sistem bukti, sehingga membuat L2 lebih efisien. Ini juga membuatnya lebih mudah untuk mengganti lebih banyak pra-kompilasi dengan kode EVM yang dapat menjalankan tugas yang sama, yang mungkin tidak akan berdampak besar pada efisiensi.
![Vitalik tentang masa depan Ethereum yang mungkin (Enam): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
Abstraksi Akun
) Apa masalah yang diselesaikan?
Saat ini, transaksi hanya dapat diverifikasi dengan satu cara: tanda tangan ECDSA. Awalnya, abstraksi akun bertujuan untuk melampaui ini, memungkinkan logika verifikasi akun untuk kode EVM yang arbitrer. Ini dapat mengaktifkan berbagai aplikasi:
Memungkinkan protokol privasi berfungsi tanpa perantara, secara signifikan mengurangi kompleksitasnya, dan menghilangkan satu titik ketergantungan pusat yang penting.
Sejak pengajuan abstraksi akun pada tahun 2015, tujuannya juga telah diperluas untuk mencakup sejumlah "tujuan kenyamanan", misalnya, akun yang tidak memiliki ETH tetapi memiliki beberapa ERC20 dapat menggunakan ERC20 untuk membayar gas.
MPC) penghitungan multi pihak( adalah teknologi yang sudah 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 semakin meningkat tentang penyediaan kenyamanan abstraksi akun untuk menguntungkan semua pengguna ) termasuk pengguna EOA (, bertujuan untuk meningkatkan pengalaman semua pengguna dalam jangka pendek dan menghindari perpecahan menjadi dua ekosistem.
Pekerjaan ini dimulai dengan EIP-3074 dan akhirnya membentuk EIP-7702. EIP-7702 menyediakan "fungsi kenyamanan" abstraksi akun untuk semua pengguna, termasuk EOA) akun yang dimiliki secara eksternal, yaitu akun yang dikendalikan oleh tanda tangan ECDSA (.
Meskipun beberapa tantangan ) terutama tantangan "kenyamanan" ( dapat diatasi melalui teknologi bertahap seperti komputasi multipihak atau EIP-7702, tetapi 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 terletak pada implementasi yang aman, yang merupakan tantangan.
![Vitalik tentang kemungkinan masa depan Ethereum (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 bergantung pada satu nilai S, dan nilai S saat ini membuat transaksi dalam mempool semuanya valid, maka satu transaksi yang membalik nilai S dapat membuat semua transaksi lainnya dalam mempool menjadi tidak valid. Ini memungkinkan penyerang untuk mengirimkan transaksi sampah ke mempool dengan biaya yang sangat rendah, sehingga membebani sumber daya node jaringan.
Setelah bertahun-tahun berusaha, yang bertujuan untuk memperluas fungsionalitas sambil membatasi risiko penolakan layanan ###DoS(, akhirnya dihasilkan 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 kemudian. Dalam memori pool, 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 untuk 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 ERC-4337 menggunakan objek yang disebut operasi pengguna, alih-alih transaksi biasa. Namun, baru-baru ini kami menyadari perlunya menulis setidaknya sebagian dari konten tersebut ke dalam protokol.
Dua alasan kunci adalah sebagai berikut:
![Vitalik tentang masa depan Ethereum yang mungkin (Enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
Selain itu, ERC-4337 juga memperluas dua fungsi:
) Tautan penelitian yang ada
) pekerjaan yang tersisa dan pertimbangan
Saat ini, yang perlu diselesaikan adalah bagaimana cara sepenuhnya mengintegrasikan abstraksi akun ke dalam protokol. EIP abstraksi akun yang baru-baru ini populer adalah EIP-7701, yang mengimplementasikan abstraksi akun di atas EOF. Sebuah akun dapat memiliki bagian kode terpisah untuk verifikasi, dan jika akun mengatur bagian kode tersebut, maka kode itu akan dieksekusi dalam langkah verifikasi dari transaksi yang berasal dari akun tersebut.
Metode ini mempesona