Mendalami Masa Lalu dan Masa Depan Jalur Abstraksi Akun Ethereum
Pendahuluan
Artikel ini dibagi menjadi dua bagian besar:
Bagian pertama dimulai dari proposal AA pertama pada tahun 2015, sistem ini merangkum isi proposal EIP utama yang ada hingga saat ini, membahas perkembangan sejarah proposal AA, dan melakukan evaluasi komprehensif terhadap masing-masing skema.
Bagian kedua fokus pada perbandingan reaksi pasar setelah peluncuran EIP4337, serta analisis mendalam tentang EIP7702 yang akan dimasukkan dalam pembaruan versi berikutnya dari Ethereum. Setelah proposal ini digabungkan, itu akan mengubah secara drastis bentuk aplikasi di blockchain.
EIP-7702 memiliki makna yang sangat penting, mari kita pelajari lebih dalam.
1. Latar Belakang Account Abstraction
1.1 Penempatan makna dari akun abstrak
Pendiri Ethereum, Vitalik, pada akhir tahun 2023 kembali memperbarui peta jalan pengembangan ETH, tetapi posisi tentang akun abstraksi tidak berubah. Model utama saat ini sedang beralih dari EIP-4337 ke tahap berikutnya "konversi sukarela akun EOA".
1.2 Status pasar dari account abstraction
Setelah satu setengah tahun pengembangan, jumlah total alamat EIP4337 di rantai utama hanya 12 juta, di mana alamat aktif di jaringan utama Ethereum hanya 6.764, jauh berbeda dari jumlah alamat EOA dan CA. Jumlah alamat independen di jaringan utama Ethereum telah mencapai 270 juta, bisa dibilang EIP4337 berkembang lambat di jaringan utama.
Namun, ini tidak mempengaruhi nilai inti dari AA. Desain EIP4337 sudah ditakdirkan untuk kesulitan dalam kompatibilitas maju di jaringan utama. Dengan berbagai jenis L2 chain yang secara umum mengintegrasikan AA asli, jumlah alamat EIP4337 meledak di L2, dengan aktif bulanan pada bulan Juli untuk chain Base dan Polygon masing-masing mencapai 1 juta dan 3 juta, menunjukkan performa yang baik.
Oleh karena itu, desain EIP4337 bukanlah kesalahan, ia memiliki banyak kelebihan. Status saat ini berasal dari perbedaan antara mainnet dan L2, yang memerlukan solusi yang sesuai untuk masing-masing.
2. Apa itu abstraksi akun?
Account abstraction pada dasarnya adalah solusi untuk masalah pemisahan kepemilikan.
Ada dua jenis akun dalam arsitektur EVM: akun eksternal ( EOA ) dan akun kontrak ( CA ). Dalam akun eksternal, kepemilikan dan hak tanda tangan dimiliki oleh entitas yang sama. Orang yang memiliki kunci pribadi tidak hanya memiliki "kepemilikan akun", tetapi juga memiliki hak untuk "menandatangani transfer semua aset".
Ini ditentukan oleh struktur transaksi akun Ethereum. Dari struktur transaksi, dapat dilihat bahwa transaksi standar sebenarnya tidak memiliki kolom From. Saat mentransfer dana, alamat konsumsi spesifik diperoleh melalui parameter VRS ( yaitu tanda tangan pengguna ) yang diparse secara terbalik.
Dan efek inti dari EIP4337 adalah menambahkan Alamat Pengirim di bidang transaksi, sehingga mewujudkan pemisahan antara kunci pribadi dan alamat yang dioperasikan.
Alasan mengapa pemisahan kepemilikan sangat penting adalah bahwa desain akun eksternal (EOA) akan menimbulkan banyak masalah:
Kunci pribadi sulit dilindungi: kehilangan kunci pribadi berarti kehilangan semua aset.
Algoritma tanda tangan tunggal: Protokol asli hanya dapat memverifikasi transaksi menggunakan algoritma ECDSA.
Otoritas tanda tangan terlalu tinggi: tidak ada fungsi multi-tanda tangan asli, tanda tangan tunggal dapat melakukan operasi apa pun.
Biaya transaksi hanya dapat dibayar dengan ETH, tidak mendukung transaksi massal.
Privasi transaksi mudah bocor: transaksi satu lawan satu mudah menganalisis informasi pemilik akun.
Pembatasan ini membuat pengguna biasa sulit untuk menggunakan Ethereum:
Pertama, pengguna harus memiliki Ether dan menanggung risiko fluktuasi harga.
Kedua, pengguna perlu menangani logika biaya yang kompleks, seperti harga Gas, batas Gas, dan konsep penundaan transaksi.
Akhirnya, dompet atau aplikasi blockchain berusaha meningkatkan pengalaman pengguna melalui optimalisasi produk, tetapi hasilnya terbatas.
Oleh karena itu, solusinya terletak pada penerapan account abstraction, yang memisahkan kepemilikan (Owner) dan hak tanda tangan (Signer), sehingga secara bertahap menyelesaikan masalah di atas.
Dalam sejarah, ada berbagai rencana, yang pada akhirnya disimpulkan menjadi dua jalur.
3. Penelusuran Sejarah Proposal AA
Solusi untuk masalah ini tampaknya memiliki banyak usulan EIP, tetapi pada akhirnya hanya ada dua pemikiran inti. Setiap masalah yang dipertimbangkan dalam EIP yang tidak disetujui, berkumpul menjadi titik terobosan dari solusi yang ada.
3.1 Jalur pertama: Mengubah alamat EOA menjadi alamat CA
Pada bulan November 2015, Vitalik mengusulkan struktur baru akun sebagai kontrak dalam EIP-101. Mengubah alamat menjadi hanya kode dan ruang penyimpanan, mendukung pembayaran biaya dengan ERC20, melalui kontrak pra-kompilasi mengubah token asli menjadi saldo penyimpanan mirip ERC20, serta menyederhanakan bidang transaksi menjadi to, startgas, data, dan code.
Solusi ini dapat dikatakan sebagai perubahan yang bersifat lompatan besar, yang akan mengubah desain dasar secara signifikan, sehingga setiap alamat akun memiliki "logika" nya sendiri (, itulah efek yang ingin dicapai oleh EIP-7702 ).
Ini juga dapat menghasilkan fungsi lain, seperti:
Biarkan transaksi menggunakan lebih banyak algoritma kripto, dengan metode verifikasi tanda tangan yang ditentukan oleh kode internal masing-masing alamat.
Memiliki karakteristik tahan serangan kuantum, karena kode dapat diupgrade.
Membuat Ether memiliki fungsi yang sama dengan kontrak ERC20, seperti otorisasi pemotongan.
Meningkatkan ruang kustomisasi akun, mendukung pemulihan sosial, dukungan SBT, pemulihan kunci, dan lain-lain.
Alasan tidak melanjutkan adalah karena langkah yang diambil terlalu besar, dan tidak mempertimbangkan dengan baik masalah konflik hash transaksi saat ini serta potensi masalah keamanan, tetapi setiap konsep keunggulan telah menjadi salah satu fungsi inti dari EIP4337 dan EIP7702 yang akan datang.
Selanjutnya ada serangkaian EIP yang berusaha menyempurnakan logika ini:
EIP-859: abstraksi akun rantai utama (2018-01-30)
Mencoba menyelesaikan masalah penyebaran kode. Fungsi utamanya adalah, jika kontrak pihak transaksi belum dideploy, maka menggunakan parameter kode yang disertakan dalam transaksi untuk mengeksekusi penyebaran dompet kontrak. Juga mengusulkan opcode PAYGAS baru, yang selain membayar gas, juga berfungsi sebagai pemisah antara bagian verifikasi dan bagian eksekusi dalam parameter transaksi.
Meskipun tidak berhasil saat itu, ini juga menjadi salah satu logika inti dari EIP7702. Setiap transaksi EIP7702 menggabungkan struktur transaksi khusus, yang dapat menyertakan kode tertentu, memungkinkan alamat EOA memiliki kemampuan kontrak dalam transaksi ini.
EIP-7702: mengatur kode akun EOA (2024-05-07)
Ini adalah EIP inti yang akan dibahas dalam artikel ini, yang diusulkan oleh Vitalik sebagai alternatif untuk EIP-3074. EIP-3074 telah ditinggalkan, EIP-7702 akan dimasukkan dalam hard fork ETH Prague/Electra(Pectra) yang akan datang.
3.2 Rute kedua: membiarkan alamat EOA menggerakkan alamat CA
EIP-3074: menambahkan opcode AUTH dan AUTHCALL (2020-10-15)
Menambahkan dua OpCode baru di EVM: AUTH dan AUTHCALL, sehingga EOA dapat memberi kuasa kepada kontrak untuk memanggil kontrak lain atas nama EOA menggunakan kedua opcode ini.
Secara umum, EOA dapat mengirimkan pesan yang telah ditandatangani ( transaksi ) ke kontrak yang dipercaya sendiri ( yang disebut Invoker ), kontrak Invoker ini dapat menggunakan opcode AUTH dan AUTHCALL sebagai pengganti EOA untuk mengeluarkan transaksi.
EIP-4337: Mengimplementasikan abstraksi akun dengan memori transaksi (2021-09-29)
Dirancang terinspirasi oleh MEV, nilai inti adalah sepenuhnya menghindari perubahan protokol lapisan konsensus.
EIP4337 mengusulkan objek transaksi baru UserOperation, pengguna mengirimkan objek ini ke mempool, yang kemudian dibundel oleh bundler dari sudut pandang penambang untuk secara massal membundel dan mengirimkan transaksi eksekusi kontrak, pada dasarnya membawa transaksi dasar dan operasi akun ke tingkat kontrak untuk dieksekusi.
EIP-5189: melalui endorser operasi akun abstrak (2022-06-29)
Ini adalah optimasi dari logika EIP4337, dengan membangun mekanisme dukungan denda dana untuk mencegah serangan DoS pemblokiran dari Bundler yang berbahaya.
3.3 proposal lain yang mendukung AA
EIP-2718: Pembungkus jenis transaksi baru (2020-06-13)
Ini adalah proposal yang sudah Final, mendefinisikan jenis transaksi baru sebagai amplop untuk jenis transaksi tambahan di masa depan.
Hasil akhirnya adalah, saat memperkenalkan jenis transaksi baru, jenis transaksi dibedakan melalui pengkodean tertentu, hanya perlu kompatibel ke belakang, tidak perlu kompatibel ke depan. Contoh yang paling umum adalah EIP1559, yang membedakan biaya transaksi, menggunakan pengkodean jenis transaksi baru, tetapi tidak mempengaruhi jenis transaksi legacy yang awal.
EIP-3607: membuat alamat EOA tidak dapat menerapkan kontrak (2021-06-10)
Ini adalah rencana tambahan di jalur AA, digunakan untuk mencegah konflik antara alamat penyebaran kontrak dan alamat EOA. Ini akan mengontrol metode pembuatan kontrak, tidak mengizinkan kode untuk disebarkan ke alamat yang sudah merupakan alamat EOA. Risiko ini sebenarnya sangat kecil, alamat Ethereum memiliki panjang 160 bit, meskipun ada metode untuk menghasilkan kunci pribadi dari alamat kontrak yang ditentukan dengan tabrakan kunci pribadi, tetapi dengan total daya komputasi Bitcoin, diperkirakan juga memerlukan waktu satu tahun.
3.4 Bagaimana cara memahami perkembangan sejarah akun abstraksi?
Pertama-tama, perlu dipahami nilai setelah diubah menjadi CA, pada dasarnya adalah efek nyata dari EIP-4337:
Mendukung transaksi massal
Mendukung pemulihan sosial
Mendukung verifikasi tanda tangan kustom
Tidak perlu membayar biaya transaksi dengan token asli
Manajemen izin yang lebih terperinci
Dapat ditingkatkan
Namun, kekurangan utama dari EIP-4337 adalah bertentangan dengan prinsip motivasi manusia.
Tampaknya lebih baik, tetapi terjebak dalam lingkaran mati perkembangan pasar: banyak Dapp masih tidak kompatibel, pengguna enggan menggunakan alamat CA, menggunakan CA justru memiliki biaya transaksi yang lebih tinggi ( dalam skenario transfer biasa, biaya transaksi menjadi dua kali lipat ), terlalu bergantung pada kompatibilitas Dapp itu sendiri.
Jadi hingga saat ini belum ada penyebaran di jaringan utama Ethereum.
Biaya adalah ukuran yang paling penting bagi pengguna, biaya harus diturunkan.
Namun, untuk benar-benar mengurangi GAS, Ethereum itu sendiri harus melakukan upgrade fork lunak, mengubah perhitungan GAS atau mengubah modul konsumsi GAS dari opcode. Karena kita akan melakukan fork lunak, lebih baik langsung mempertimbangkan EIP-7702.
4. Analisis Menyeluruh EIP-7702
4.1 Apa itu EIP-7702
Ini memungkinkan EOA untuk sementara memiliki fungsi kontrak pintar dalam satu transaksi melalui jenis transaksi baru, mendukung transaksi massal, transaksi tanpa Gas, dan manajemen izin kustom, serta tidak memerlukan pengenalan opCode EVM baru ( yang mempengaruhi kompatibilitas ke depan ).
Pengguna tidak perlu menerapkan kontrak pintar untuk mendapatkan sebagian besar kemampuan AA, bahkan dapat memberikan kemampuan kepada pihak ketiga untuk memulai transaksi atas nama pengguna, dan tidak memerlukan pengguna untuk memberikan kunci pribadi, hanya perlu menandatangani informasi otorisasi.
4.2 Struktur Data
Mendefinisikan jenis transaksi baru 0x04, TransactionPayload adalah hasil serialisasi RLP dari konten berikut:
Penting untuk menambahkan objek authorization_list, yang menyimpan kode yang diinginkan oleh penandatangan untuk dijalankan dalam EOA mereka. Pengguna menandatangani transaksi sekaligus menandatangani kode kontrak yang akan dijalankan, yang ada sebagai daftar dua dimensi, dapat menyimpan beberapa informasi operasi secara massal dan melakukan operasi massal.
Atur kode penandatangan authority menjadi 0xef0100 || address( untuk melewati strategi pencegahan tabrakan EIP3607).
Menambahkan nonce authority signer ( untuk mencegah replay signature lokal ).
Tambahkan akun penandatangan authority ke daftar alamat yang telah diakses ( untuk alamat panas, mengurangi biaya gas penyimpanan kueri ).
4.3.2 Tahap Pelaksanaan Operasi
"Versi "baru" hanya mengubah perilaku penyebaran kode.
Tidak lagi mengatur account_code sebagai contract_code, tetapi mengambil kode yang ditentukan oleh address dari authorization_list dan mengaturnya sebagai account_code.
Saat menjalankan kode otorisasi, muat kode dari bidang address di authorization_list, dan jalankan dalam konteks akun penandatangan.
Ini berarti bahwa kode kontrak pengguna disimpan di alamat tertentu di rantai, bukan langsung termasuk dalam transaksi.
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.
11 Suka
Hadiah
11
7
Bagikan
Komentar
0/400
LiquidationWizard
· 07-25 01:53
Apa yang dilakukan 7702 lagi
Lihat AsliBalas0
GasWaster
· 07-24 18:03
ya ampun, satu EIP lagi... tahun lalu saya menghabiskan 2eth untuk transaksi yang gagal dan sekarang mereka memberi tahu saya ini?
Lihat AsliBalas0
EntryPositionAnalyst
· 07-24 15:19
AA kembali menjadi hangat setelah beberapa hari.
Lihat AsliBalas0
MetaMuskRat
· 07-22 06:03
Sekarang mulai berbicara tentang AA lagi, sepertinya Blockchain adalah botol lama yang diisi dengan anggur baru.
EIP-7702 akan membentuk kembali ekosistem Ethereum, abstraksi akun memasuki era baru.
Mendalami Masa Lalu dan Masa Depan Jalur Abstraksi Akun Ethereum
Pendahuluan
Artikel ini dibagi menjadi dua bagian besar:
Bagian pertama dimulai dari proposal AA pertama pada tahun 2015, sistem ini merangkum isi proposal EIP utama yang ada hingga saat ini, membahas perkembangan sejarah proposal AA, dan melakukan evaluasi komprehensif terhadap masing-masing skema.
Bagian kedua fokus pada perbandingan reaksi pasar setelah peluncuran EIP4337, serta analisis mendalam tentang EIP7702 yang akan dimasukkan dalam pembaruan versi berikutnya dari Ethereum. Setelah proposal ini digabungkan, itu akan mengubah secara drastis bentuk aplikasi di blockchain.
EIP-7702 memiliki makna yang sangat penting, mari kita pelajari lebih dalam.
1. Latar Belakang Account Abstraction
1.1 Penempatan makna dari akun abstrak
Pendiri Ethereum, Vitalik, pada akhir tahun 2023 kembali memperbarui peta jalan pengembangan ETH, tetapi posisi tentang akun abstraksi tidak berubah. Model utama saat ini sedang beralih dari EIP-4337 ke tahap berikutnya "konversi sukarela akun EOA".
1.2 Status pasar dari account abstraction
Setelah satu setengah tahun pengembangan, jumlah total alamat EIP4337 di rantai utama hanya 12 juta, di mana alamat aktif di jaringan utama Ethereum hanya 6.764, jauh berbeda dari jumlah alamat EOA dan CA. Jumlah alamat independen di jaringan utama Ethereum telah mencapai 270 juta, bisa dibilang EIP4337 berkembang lambat di jaringan utama.
Namun, ini tidak mempengaruhi nilai inti dari AA. Desain EIP4337 sudah ditakdirkan untuk kesulitan dalam kompatibilitas maju di jaringan utama. Dengan berbagai jenis L2 chain yang secara umum mengintegrasikan AA asli, jumlah alamat EIP4337 meledak di L2, dengan aktif bulanan pada bulan Juli untuk chain Base dan Polygon masing-masing mencapai 1 juta dan 3 juta, menunjukkan performa yang baik.
Oleh karena itu, desain EIP4337 bukanlah kesalahan, ia memiliki banyak kelebihan. Status saat ini berasal dari perbedaan antara mainnet dan L2, yang memerlukan solusi yang sesuai untuk masing-masing.
2. Apa itu abstraksi akun?
Account abstraction pada dasarnya adalah solusi untuk masalah pemisahan kepemilikan.
Ada dua jenis akun dalam arsitektur EVM: akun eksternal ( EOA ) dan akun kontrak ( CA ). Dalam akun eksternal, kepemilikan dan hak tanda tangan dimiliki oleh entitas yang sama. Orang yang memiliki kunci pribadi tidak hanya memiliki "kepemilikan akun", tetapi juga memiliki hak untuk "menandatangani transfer semua aset".
Ini ditentukan oleh struktur transaksi akun Ethereum. Dari struktur transaksi, dapat dilihat bahwa transaksi standar sebenarnya tidak memiliki kolom From. Saat mentransfer dana, alamat konsumsi spesifik diperoleh melalui parameter VRS ( yaitu tanda tangan pengguna ) yang diparse secara terbalik.
Dan efek inti dari EIP4337 adalah menambahkan Alamat Pengirim di bidang transaksi, sehingga mewujudkan pemisahan antara kunci pribadi dan alamat yang dioperasikan.
Alasan mengapa pemisahan kepemilikan sangat penting adalah bahwa desain akun eksternal (EOA) akan menimbulkan banyak masalah:
Kunci pribadi sulit dilindungi: kehilangan kunci pribadi berarti kehilangan semua aset.
Algoritma tanda tangan tunggal: Protokol asli hanya dapat memverifikasi transaksi menggunakan algoritma ECDSA.
Otoritas tanda tangan terlalu tinggi: tidak ada fungsi multi-tanda tangan asli, tanda tangan tunggal dapat melakukan operasi apa pun.
Biaya transaksi hanya dapat dibayar dengan ETH, tidak mendukung transaksi massal.
Privasi transaksi mudah bocor: transaksi satu lawan satu mudah menganalisis informasi pemilik akun.
Pembatasan ini membuat pengguna biasa sulit untuk menggunakan Ethereum:
Pertama, pengguna harus memiliki Ether dan menanggung risiko fluktuasi harga.
Kedua, pengguna perlu menangani logika biaya yang kompleks, seperti harga Gas, batas Gas, dan konsep penundaan transaksi.
Akhirnya, dompet atau aplikasi blockchain berusaha meningkatkan pengalaman pengguna melalui optimalisasi produk, tetapi hasilnya terbatas.
Oleh karena itu, solusinya terletak pada penerapan account abstraction, yang memisahkan kepemilikan (Owner) dan hak tanda tangan (Signer), sehingga secara bertahap menyelesaikan masalah di atas.
Dalam sejarah, ada berbagai rencana, yang pada akhirnya disimpulkan menjadi dua jalur.
3. Penelusuran Sejarah Proposal AA
Solusi untuk masalah ini tampaknya memiliki banyak usulan EIP, tetapi pada akhirnya hanya ada dua pemikiran inti. Setiap masalah yang dipertimbangkan dalam EIP yang tidak disetujui, berkumpul menjadi titik terobosan dari solusi yang ada.
3.1 Jalur pertama: Mengubah alamat EOA menjadi alamat CA
Pada bulan November 2015, Vitalik mengusulkan struktur baru akun sebagai kontrak dalam EIP-101. Mengubah alamat menjadi hanya kode dan ruang penyimpanan, mendukung pembayaran biaya dengan ERC20, melalui kontrak pra-kompilasi mengubah token asli menjadi saldo penyimpanan mirip ERC20, serta menyederhanakan bidang transaksi menjadi to, startgas, data, dan code.
Solusi ini dapat dikatakan sebagai perubahan yang bersifat lompatan besar, yang akan mengubah desain dasar secara signifikan, sehingga setiap alamat akun memiliki "logika" nya sendiri (, itulah efek yang ingin dicapai oleh EIP-7702 ).
Ini juga dapat menghasilkan fungsi lain, seperti:
Biarkan transaksi menggunakan lebih banyak algoritma kripto, dengan metode verifikasi tanda tangan yang ditentukan oleh kode internal masing-masing alamat.
Memiliki karakteristik tahan serangan kuantum, karena kode dapat diupgrade.
Membuat Ether memiliki fungsi yang sama dengan kontrak ERC20, seperti otorisasi pemotongan.
Meningkatkan ruang kustomisasi akun, mendukung pemulihan sosial, dukungan SBT, pemulihan kunci, dan lain-lain.
Alasan tidak melanjutkan adalah karena langkah yang diambil terlalu besar, dan tidak mempertimbangkan dengan baik masalah konflik hash transaksi saat ini serta potensi masalah keamanan, tetapi setiap konsep keunggulan telah menjadi salah satu fungsi inti dari EIP4337 dan EIP7702 yang akan datang.
Selanjutnya ada serangkaian EIP yang berusaha menyempurnakan logika ini:
EIP-859: abstraksi akun rantai utama (2018-01-30)
Mencoba menyelesaikan masalah penyebaran kode. Fungsi utamanya adalah, jika kontrak pihak transaksi belum dideploy, maka menggunakan parameter kode yang disertakan dalam transaksi untuk mengeksekusi penyebaran dompet kontrak. Juga mengusulkan opcode PAYGAS baru, yang selain membayar gas, juga berfungsi sebagai pemisah antara bagian verifikasi dan bagian eksekusi dalam parameter transaksi.
Meskipun tidak berhasil saat itu, ini juga menjadi salah satu logika inti dari EIP7702. Setiap transaksi EIP7702 menggabungkan struktur transaksi khusus, yang dapat menyertakan kode tertentu, memungkinkan alamat EOA memiliki kemampuan kontrak dalam transaksi ini.
EIP-7702: mengatur kode akun EOA (2024-05-07)
Ini adalah EIP inti yang akan dibahas dalam artikel ini, yang diusulkan oleh Vitalik sebagai alternatif untuk EIP-3074. EIP-3074 telah ditinggalkan, EIP-7702 akan dimasukkan dalam hard fork ETH Prague/Electra(Pectra) yang akan datang.
3.2 Rute kedua: membiarkan alamat EOA menggerakkan alamat CA
EIP-3074: menambahkan opcode AUTH dan AUTHCALL (2020-10-15)
Menambahkan dua OpCode baru di EVM: AUTH dan AUTHCALL, sehingga EOA dapat memberi kuasa kepada kontrak untuk memanggil kontrak lain atas nama EOA menggunakan kedua opcode ini.
Secara umum, EOA dapat mengirimkan pesan yang telah ditandatangani ( transaksi ) ke kontrak yang dipercaya sendiri ( yang disebut Invoker ), kontrak Invoker ini dapat menggunakan opcode AUTH dan AUTHCALL sebagai pengganti EOA untuk mengeluarkan transaksi.
EIP-4337: Mengimplementasikan abstraksi akun dengan memori transaksi (2021-09-29)
Dirancang terinspirasi oleh MEV, nilai inti adalah sepenuhnya menghindari perubahan protokol lapisan konsensus.
EIP4337 mengusulkan objek transaksi baru UserOperation, pengguna mengirimkan objek ini ke mempool, yang kemudian dibundel oleh bundler dari sudut pandang penambang untuk secara massal membundel dan mengirimkan transaksi eksekusi kontrak, pada dasarnya membawa transaksi dasar dan operasi akun ke tingkat kontrak untuk dieksekusi.
EIP-5189: melalui endorser operasi akun abstrak (2022-06-29)
Ini adalah optimasi dari logika EIP4337, dengan membangun mekanisme dukungan denda dana untuk mencegah serangan DoS pemblokiran dari Bundler yang berbahaya.
3.3 proposal lain yang mendukung AA
EIP-2718: Pembungkus jenis transaksi baru (2020-06-13)
Ini adalah proposal yang sudah Final, mendefinisikan jenis transaksi baru sebagai amplop untuk jenis transaksi tambahan di masa depan.
Hasil akhirnya adalah, saat memperkenalkan jenis transaksi baru, jenis transaksi dibedakan melalui pengkodean tertentu, hanya perlu kompatibel ke belakang, tidak perlu kompatibel ke depan. Contoh yang paling umum adalah EIP1559, yang membedakan biaya transaksi, menggunakan pengkodean jenis transaksi baru, tetapi tidak mempengaruhi jenis transaksi legacy yang awal.
EIP-3607: membuat alamat EOA tidak dapat menerapkan kontrak (2021-06-10)
Ini adalah rencana tambahan di jalur AA, digunakan untuk mencegah konflik antara alamat penyebaran kontrak dan alamat EOA. Ini akan mengontrol metode pembuatan kontrak, tidak mengizinkan kode untuk disebarkan ke alamat yang sudah merupakan alamat EOA. Risiko ini sebenarnya sangat kecil, alamat Ethereum memiliki panjang 160 bit, meskipun ada metode untuk menghasilkan kunci pribadi dari alamat kontrak yang ditentukan dengan tabrakan kunci pribadi, tetapi dengan total daya komputasi Bitcoin, diperkirakan juga memerlukan waktu satu tahun.
3.4 Bagaimana cara memahami perkembangan sejarah akun abstraksi?
Pertama-tama, perlu dipahami nilai setelah diubah menjadi CA, pada dasarnya adalah efek nyata dari EIP-4337:
Namun, kekurangan utama dari EIP-4337 adalah bertentangan dengan prinsip motivasi manusia.
Tampaknya lebih baik, tetapi terjebak dalam lingkaran mati perkembangan pasar: banyak Dapp masih tidak kompatibel, pengguna enggan menggunakan alamat CA, menggunakan CA justru memiliki biaya transaksi yang lebih tinggi ( dalam skenario transfer biasa, biaya transaksi menjadi dua kali lipat ), terlalu bergantung pada kompatibilitas Dapp itu sendiri.
Jadi hingga saat ini belum ada penyebaran di jaringan utama Ethereum.
Biaya adalah ukuran yang paling penting bagi pengguna, biaya harus diturunkan.
Namun, untuk benar-benar mengurangi GAS, Ethereum itu sendiri harus melakukan upgrade fork lunak, mengubah perhitungan GAS atau mengubah modul konsumsi GAS dari opcode. Karena kita akan melakukan fork lunak, lebih baik langsung mempertimbangkan EIP-7702.
4. Analisis Menyeluruh EIP-7702
4.1 Apa itu EIP-7702
Ini memungkinkan EOA untuk sementara memiliki fungsi kontrak pintar dalam satu transaksi melalui jenis transaksi baru, mendukung transaksi massal, transaksi tanpa Gas, dan manajemen izin kustom, serta tidak memerlukan pengenalan opCode EVM baru ( yang mempengaruhi kompatibilitas ke depan ).
Pengguna tidak perlu menerapkan kontrak pintar untuk mendapatkan sebagian besar kemampuan AA, bahkan dapat memberikan kemampuan kepada pihak ketiga untuk memulai transaksi atas nama pengguna, dan tidak memerlukan pengguna untuk memberikan kunci pribadi, hanya perlu menandatangani informasi otorisasi.
4.2 Struktur Data
Mendefinisikan jenis transaksi baru 0x04, TransactionPayload adalah hasil serialisasi RLP dari konten berikut:
rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])
Penting untuk menambahkan objek authorization_list, yang menyimpan kode yang diinginkan oleh penandatangan untuk dijalankan dalam EOA mereka. Pengguna menandatangani transaksi sekaligus menandatangani kode kontrak yang akan dijalankan, yang ada sebagai daftar dua dimensi, dapat menyimpan beberapa informasi operasi secara massal dan melakukan operasi massal.
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
4.3 siklus hidup transaksi
4.3.1 tahap verifikasi
Saat eksekusi transaksi dimulai, untuk setiap tuple [chain_id, address, nonce, y_parity, r, s] dari authorization_list:
4.3.2 Tahap Pelaksanaan Operasi
"Versi "baru" hanya mengubah perilaku penyebaran kode.
Tidak lagi mengatur account_code sebagai contract_code, tetapi mengambil kode yang ditentukan oleh address dari authorization_list dan mengaturnya sebagai account_code.
Saat menjalankan kode otorisasi, muat kode dari bidang address di authorization_list, dan jalankan dalam konteks akun penandatangan.
Ini berarti bahwa kode kontrak pengguna disimpan di alamat tertentu di rantai, bukan langsung termasuk dalam transaksi.