Masa Depan Potensial Protokol Ethereum (Enam): Kemakmuran
Desain protokol Ethereum memiliki banyak "detail" yang sangat penting untuk keberhasilan Ethereum. Sebenarnya, sekitar setengah dari kontennya terkait dengan berbagai jenis peningkatan EVM, sementara sisanya terdiri dari berbagai topik yang kurang umum, inilah yang dimaksud dengan "keterpurukan".
Kemakmuran: Tujuan Kunci
Mengubah EVM menjadi "status akhir" yang berkinerja tinggi dan stabil
Memperkenalkan abstraksi akun ke dalam protokol, memungkinkan semua pengguna untuk menikmati akun yang lebih aman dan nyaman.
Mengoptimalkan ekonomi biaya transaksi, meningkatkan skalabilitas sambil mengurangi risiko
Menjelajahi kriptografi canggih, untuk meningkatkan Ethereum secara signifikan 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 peningkatan lebih lanjut menjadi sulit. Selain itu, efisiensi EVM yang rendah menyulitkan penerapan banyak bentuk kriptografi tingkat tinggi, kecuali didukung secara eksplisit melalui pra-kompilasi.
Apa itu, dan 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 dibaca dari EVM, dan data ) dapat dibaca, tetapi tidak dapat dieksekusi antara pemisahan (.
Dilarang melakukan pengalihan dinamis, hanya pengalihan statis yang diizinkan
Kode EVM tidak dapat lagi mengamati informasi terkait bahan bakar
Menambahkan mekanisme subroutine eksplisit baru
![Vitalik tentang kemungkinan masa depan Ethereum (Enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(
Kontrak lama akan terus ada dan dapat dibuat, meskipun pada akhirnya mungkin 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, dan selanjutnya melalui fungsi baru atau pengurangan biaya gas yang spesifik untuk EOF.
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 ditujukan untuk operasi modulus, dan menempatkannya di ruang memori baru yang tidak dapat diakses melalui opcode lainnya, 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 telah ada sejak lama, pertama kali diusulkan oleh Greg Colvin dalam EIP-616. SIMD dapat digunakan untuk mempercepat banyak bentuk kriptografi, termasuk fungsi hash, STARK 32-bit, dan kriptografi berbasis kisi. Kombinasi EVM-MAX dan SIMD membuat kedua skala yang berorientasi kinerja ini menjadi pasangan yang alami.
Desain kasar dari kombinasi EIP akan dimulai dari EIP-6690, kemudian:
Memungkinkan (i) bilangan ganjil mana pun atau (ii) pangkat 2 mana pun yang 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:
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 mendorong output ke tumpukan utama EVM), yang 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. Pembaruan EVM lainnya juga mungkin diimplementasikan, tetapi sejauh ini kurang mendapatkan perhatian.
(# Tautan penelitian yang ada
EOF:
EVM-MAX:
SIMD:
)# Pekerjaan yang tersisa dan pertimbangan
Saat ini, EOF direncanakan untuk dimasukkan dalam fork keras berikutnya. Meskipun selalu mungkin untuk menghapusnya pada saat-saat terakhir — beberapa fungsi telah dihapus sementara dalam fork keras sebelumnya, namun melakukannya akan menghadapi tantangan besar. Menghapus EOF berarti bahwa setiap peningkatan EVM di masa depan harus dilakukan tanpa EOF, meskipun itu mungkin, tetapi bisa lebih sulit.
Kompromi utama EVM terletak pada 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 mewujudkan 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 kedua belah pihak tidak melakukan penyesuaian secara sinkron, mungkin akan menyebabkan ketidakcocokan, yang dapat membawa dampak 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 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
)# 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 menjadi kode EVM yang arbitrer. Ini dapat mengaktifkan serangkaian aplikasi:
Beralih ke kriptografi tahan kuantum
Mengganti kunci lama ### secara luas dianggap sebagai praktik keamanan yang dianjurkan ###
Dompet multisignatur dan dompet pemulihan sosial
Menggunakan satu kunci untuk operasi bernilai rendah, menggunakan kunci lain ( atau sekumpulan kunci ) untuk operasi bernilai tinggi
Memungkinkan protokol privasi beroperasi tanpa perantara, secara signifikan mengurangi kompleksitasnya, dan menghilangkan satu titik ketergantungan pusat yang krusial.
Sejak pengajuan abstraksi akun pada tahun 2015, tujuannya juga telah diperluas untuk mencakup sejumlah "tujuan kenyamanan", seperti, sebuah akun yang tidak memiliki ETH tetapi memiliki beberapa ERC20 dapat menggunakan ERC20 untuk membayar gas.
MPC( komputasi multipihak) adalah teknologi yang telah 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 pengakuan yang semakin meningkat tentang pentingnya memberikan kenyamanan abstraksi akun untuk menguntungkan semua pengguna (, termasuk pengguna EOA ), yang bertujuan untuk meningkatkan pengalaman semua pengguna dalam jangka pendek dan menghindari pembagian menjadi dua ekosistem.
Pekerjaan ini dimulai dengan EIP-3074 dan akhirnya membentuk EIP-7702. EIP-7702 memberikan "fungsi kenyamanan" dari abstraksi akun kepada semua pengguna, termasuk EOA( akun yang dimiliki secara eksternal saat ini, yaitu akun yang dikendalikan oleh tanda tangan ECDSA ).
Meskipun beberapa tantangan ( terutama tantangan "kenyamanan" ) dapat diatasi melalui teknologi bertahap seperti komputasi multi pihak atau EIP-7702, tetapi tujuan keamanan utama dari proposal abstraksi akun yang diusulkan pada awalnya hanya dapat dicapai dengan menelusuri kembali dan menyelesaikan masalah asli: memungkinkan kode kontrak pintar mengontrol verifikasi transaksi. Penyebab mengapa ini belum terwujud hingga saat ini adalah implementasi yang aman, yang merupakan tantangan.
(# Apa itu, dan bagaimana cara kerjanya?
Inti dari abstraksi akun adalah sederhana: memungkinkan kontrak pintar untuk memulai transaksi, bukan hanya EOA. Seluruh kompleksitas berasal dari cara untuk mewujudkannya dengan cara yang ramah terhadap pemeliharaan jaringan terdesentralisasi, serta mencegah serangan penolakan layanan.
Tantangan kunci yang khas adalah masalah kegagalan ganda:
Jika ada 1000 fungsi verifikasi akun yang bergantung pada satu nilai tunggal S, dan nilai S saat ini membuat transaksi dalam memori pool menjadi valid, maka satu transaksi tunggal yang membalik nilai S mungkin akan membuat semua transaksi lain dalam memori pool menjadi tidak valid. Ini memungkinkan penyerang untuk mengirimkan transaksi sampah ke memori pool dengan biaya yang sangat rendah, sehingga menghambat sumber daya node jaringan.
Setelah bertahun-tahun berusaha, yang bertujuan untuk memperluas fungsi sambil membatasi risiko penolakan layanan )DoS###, akhirnya menghasilkan solusi untuk mencapai "abstraksi akun yang 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. 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, 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), tanpa 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 menulis setidaknya sebagian dari konten ini ke dalam protokol.
Dua alasan kunci adalah sebagai berikut:
EntryPoint sebagai inefisiensi bawaan 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 abstrak akun.
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 fase verifikasi hanya dapat mengakses akun pengirim itu sendiri, oleh karena itu pengenalan penanganan khusus untuk memastikan keamanan mekanisme agen pembayaran.
Pengumpul ( Aggregators ): Mendukung fungsi pengumpulan tanda tangan, seperti pengumpulan BLS atau pengumpulan berbasis SNARK. Ini diperlukan untuk mencapai efisiensi data tertinggi di atas Rollup.
(# Tautan penelitian yang ada
Tentang sejarah abstraksi akun:
ERC-4337:
EIP-7702:
Kode BLSWallet ) menggunakan fungsi agregasi ###:
EIP-7562( menulis protokol abstraksi akun ):
EIP-7701( akun abstraksi protokol penulisan berbasis EOF ):
(# 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 untuk menulis protokol abstraksi akun 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 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.
10 Suka
Hadiah
10
5
Bagikan
Komentar
0/400
SignatureAnxiety
· 17jam yang lalu
Apa yang bisa dibeli dengan gas yang dihemat ini?
Lihat AsliBalas0
BlockchainRetirementHome
· 08-02 07:21
Akhirnya menunggu pembaruan versi EVM, Legenda Emas
Lihat AsliBalas0
Web3ExplorerLin
· 08-02 07:20
hipotesis: evm seperti komputer kuno yang mencari bentuk akhirnya... menarik bagaimana itu mencerminkan evolusi kesadaran manusia sejujurnya
Lihat AsliBalas0
WenAirdrop
· 08-02 07:09
Jangan bercanda, biaya gas masih mahal sampai muntah, ya?
Lihat AsliBalas0
MEVictim
· 08-02 07:08
Seberapa lama lagi reformasi biaya bisa ditunda... Jangan buat EVM terlalu rumit.
Ethereum EVM upgrade dan account abstraction: membangun infrastruktur Blockchain yang lebih efisien dan aman
Masa Depan Potensial Protokol Ethereum (Enam): Kemakmuran
Desain protokol Ethereum memiliki banyak "detail" yang sangat penting untuk keberhasilan Ethereum. Sebenarnya, sekitar setengah dari kontennya terkait dengan berbagai jenis peningkatan EVM, sementara sisanya terdiri dari berbagai topik yang kurang umum, inilah yang dimaksud dengan "keterpurukan".
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 peningkatan lebih lanjut menjadi sulit. Selain itu, efisiensi EVM yang rendah menyulitkan penerapan banyak bentuk kriptografi tingkat tinggi, kecuali didukung secara eksplisit melalui pra-kompilasi.
Apa itu, dan 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:
![Vitalik tentang kemungkinan masa depan Ethereum (Enam): The Splurge])https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(
Kontrak lama akan terus ada dan dapat dibuat, meskipun pada akhirnya mungkin 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, dan selanjutnya melalui fungsi baru atau pengurangan biaya gas yang spesifik untuk EOF.
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 ditujukan untuk operasi modulus, dan menempatkannya di ruang memori baru yang tidak dapat diakses melalui opcode lainnya, 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 telah ada sejak lama, pertama kali diusulkan oleh Greg Colvin dalam EIP-616. SIMD dapat digunakan untuk mempercepat banyak bentuk kriptografi, termasuk fungsi hash, STARK 32-bit, dan kriptografi berbasis kisi. Kombinasi EVM-MAX dan SIMD membuat kedua skala yang berorientasi kinerja ini menjadi pasangan yang alami.
Desain kasar dari 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
)# Pekerjaan yang tersisa dan pertimbangan
Saat ini, EOF direncanakan untuk dimasukkan dalam fork keras berikutnya. Meskipun selalu mungkin untuk menghapusnya pada saat-saat terakhir — beberapa fungsi telah dihapus sementara dalam fork keras sebelumnya, namun melakukannya akan menghadapi tantangan besar. Menghapus EOF berarti bahwa setiap peningkatan EVM di masa depan harus dilakukan tanpa EOF, meskipun itu mungkin, tetapi bisa lebih sulit.
Kompromi utama EVM terletak pada 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 mewujudkan 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 kedua belah pihak tidak melakukan penyesuaian secara sinkron, mungkin akan menyebabkan ketidakcocokan, yang dapat membawa dampak 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 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
)# 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 menjadi kode EVM yang arbitrer. Ini dapat mengaktifkan serangkaian aplikasi:
Memungkinkan protokol privasi beroperasi tanpa perantara, secara signifikan mengurangi kompleksitasnya, dan menghilangkan satu titik ketergantungan pusat yang krusial.
Sejak pengajuan abstraksi akun pada tahun 2015, tujuannya juga telah diperluas untuk mencakup sejumlah "tujuan kenyamanan", seperti, sebuah akun yang tidak memiliki ETH tetapi memiliki beberapa ERC20 dapat menggunakan ERC20 untuk membayar gas.
MPC( komputasi multipihak) adalah teknologi yang telah 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 pengakuan yang semakin meningkat tentang pentingnya memberikan kenyamanan abstraksi akun untuk menguntungkan semua pengguna (, termasuk pengguna EOA ), yang bertujuan untuk meningkatkan pengalaman semua pengguna dalam jangka pendek dan menghindari pembagian menjadi dua ekosistem.
Pekerjaan ini dimulai dengan EIP-3074 dan akhirnya membentuk EIP-7702. EIP-7702 memberikan "fungsi kenyamanan" dari abstraksi akun kepada semua pengguna, termasuk EOA( akun yang dimiliki secara eksternal saat ini, yaitu akun yang dikendalikan oleh tanda tangan ECDSA ).
Meskipun beberapa tantangan ( terutama tantangan "kenyamanan" ) dapat diatasi melalui teknologi bertahap seperti komputasi multi pihak atau EIP-7702, tetapi tujuan keamanan utama dari proposal abstraksi akun yang diusulkan pada awalnya hanya dapat dicapai dengan menelusuri kembali dan menyelesaikan masalah asli: memungkinkan kode kontrak pintar mengontrol verifikasi transaksi. Penyebab mengapa ini belum terwujud hingga saat ini adalah implementasi yang aman, yang merupakan tantangan.
(# Apa itu, dan bagaimana cara kerjanya?
Inti dari abstraksi akun adalah sederhana: memungkinkan kontrak pintar untuk memulai transaksi, bukan hanya EOA. Seluruh kompleksitas berasal dari cara untuk mewujudkannya dengan cara yang ramah terhadap pemeliharaan jaringan terdesentralisasi, serta mencegah serangan penolakan layanan.
Tantangan kunci yang khas adalah masalah kegagalan ganda:
Jika ada 1000 fungsi verifikasi akun yang bergantung pada satu nilai tunggal S, dan nilai S saat ini membuat transaksi dalam memori pool menjadi valid, maka satu transaksi tunggal yang membalik nilai S mungkin akan membuat semua transaksi lain dalam memori pool menjadi tidak valid. Ini memungkinkan penyerang untuk mengirimkan transaksi sampah ke memori pool dengan biaya yang sangat rendah, sehingga menghambat sumber daya node jaringan.
Setelah bertahun-tahun berusaha, yang bertujuan untuk memperluas fungsi sambil membatasi risiko penolakan layanan )DoS###, akhirnya menghasilkan solusi untuk mencapai "abstraksi akun yang 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. 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, 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), tanpa 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 menulis setidaknya sebagian dari konten ini ke dalam protokol.
Dua alasan kunci adalah sebagai berikut:
Selain itu, ERC-4337 juga memperluas dua fungsi:
(# Tautan penelitian yang ada
(# 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 untuk menulis protokol abstraksi akun 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 transaksi yang berasal dari akun tersebut.
Jenis ini