Analisis Mendalam tentang Sejarah dan Masa Depan Abstraksi Akun Ethereum

Lanjutan9/12/2024, 1:51:56 AM
Artikel ini akan dimulai dengan proposal Account Abstraksi (AA) pertama dari tahun 2015, secara sistematis mengorganisir konten utama dari proposal EIP hingga saat ini, kemudian membandingkan umpan balik pasar setelah diperkenalkannya EIP-4337, dan akhirnya menganalisis EIP-7702, yang direncanakan akan disertakan dalam upgrade Ethereum berikutnya.

Pendahuluan

Artikel ini dibagi menjadi dua bagian utama:

Pada bagian pertama, itu akan dimulai dengan proposal AA pertama dari tahun 2015, secara sistematis mengorganisasikan konten utama dari proposal EIP hingga saat ini. Tujuannya adalah untuk mengeksplorasi perkembangan sejarah dari proposal AA dan menilai secara komprehensif kelebihan dan kelemahan dari setiap proposal.

Pada bagian kedua, akan difokuskan pada perbandingan umpan balik pasar setelah diperkenalkannya EIP-4337 dan kemudian akan menjelajahi analisis EIP-7702, yang dijadwalkan akan disertakan dalam upgrade Ethereum berikutnya. Usulan ini, setelah digabungkan, diharapkan akan secara signifikan mengubah sifat aplikasi on-chain.

EIP-7702 menjanjikan perubahan revolusioner, dan kami akan membahasnya secara detail.

1. Latar Belakang Abstraksi Akun

1.1 Arti abstraksi akun

Pada akhir 2023, pendiri Ethereum Vitalik Buterin sekali lagi memperbarui peta jalan pengembangan ETH. Namun, ketentuan terkait Abstraksi Akun tetap tidak berubah. Model utama saat ini terus berkembang dari EIP-4337 ke fase berikutnya: Konversi EOA Sukarela (konversi akun EOA yang diinisiasi sendiri).


https://x.com/VitalikButerin/status/1741190491578810445

Sejak rilis EIP-4337 lebih dari setahun yang lalu (pada 1 Maret 2023, di WalletCon di Denver, pengembang Ethereum Foundation mengumumkan bahwa kontrak inti ERC-4337 telah lolos audit OpenZeppelin, menandai tonggak sejarah untuk peluncuran resminya), proyek ini telah menerima pengakuan pengguna yang luas tetapi belum melihat adopsi yang luas. Lingkungan pasar paradoks ini telah mempercepat kemajuan EIP-7702, yang sekarang dikonfirmasi akan disertakan dalam upgrade berikutnya.

1.2 Status pasar saat ini dari abstraksi akun

Tanpa basa-basi, mari kita lihat data tersebut.

Setelah setahun setengah pengembangan, EIP-4337 hanya mengumpulkan 12 juta alamat di bawah akun rantai utama. Yang sangat mengejutkan adalah bahwa di mainnet Ethereum, hanya ada 6.764 alamat aktif. Meskipun mungkin ada isu dengan dimensi statistik, jumlah ini tetap jauh berbeda dari jumlah alamat untuk EOAs dan CAs. Untuk konteks, jumlah alamat unik di mainnet Ethereum telah mencapai 270 juta (sumber: https://etherscan.io/chart/address.

Bisa dikatakan bahwa EIP-4337 belum membuat kemajuan substansial di mainnet.


(Sumber chart: https://dune.com/niftytable/account-abstraction)

Namun, hal ini tidak mengurangi nilai intrinsik Account Abstraction (AA). Sejak awal, desain EIP-4337 sudah ditakdirkan untuk menghadapi masalah kompatibilitas mundur yang signifikan di mainnet. Akibatnya, dengan berbagai rantai Layer 2 yang mengintegrasikan AA asli, EIP-4337 telah mengalami pertumbuhan yang signifikan dalam jumlah alamat di Layer 2. Sebagai contoh, pada bulan Juli, jumlah pengguna aktif di rantai Base dan Polygon mencapai masing-masing 1 juta dan 3 juta, yang cukup mengesankan.

Oleh karena itu, bukanlah desain dari EIP-4337 yang cacat; memiliki banyak keunggulan yang akan kami ringkas secara sistematis. Situasi saat ini muncul dari perbedaan antara mainnet dan Layer 2, masing-masing memerlukan solusi yang disesuaikan.

2. Apa itu Abstraksi Akun?

Abstraksi Akun mungkin terdengar kompleks, tetapi pada dasarnya mengatasi masalah pemisahan kepemilikan.

Dalam arsitektur Mesin Virtual Ethereum (EVM), ada dua jenis akun: Akun Milik Eksternal (EOAs) dan Akun Kontrak. Pada EOAs, kepemilikan dan otoritas tanda tangan dipegang oleh entitas yang sama. Orang dengan kunci pribadi tidak hanya memiliki akun tetapi juga berhak untuk menandatangani dan mentransfer semua asetnya.

Pengaturan ini ditentukan oleh struktur transaksi rekening Ethereum. Dalam transaksi Ethereum standar, tidak ada alamat "Dari" langsung yang terlihat. Ketika transfer dana terjadi, alamat aktual dari mana dana tersebut dihabiskan disimpulkan melalui parameter VRS (yaitu, tanda tangan pengguna).

Ini melibatkan konsep seperti enkripsi asimetris ECDSA dan fungsi ambang satu arah, tetapi kami tidak akan mendalami detail-detail tersebut di sini. Pada dasarnya, kriptografi memastikan keamanan, yang mengarah ke situasi saat ini di mana kepemilikan dan otoritas tanda tangan digabungkan dalam EOAs.

Efek inti dari EIP-4337 adalah menambahkan kolom Alamat Pengirim ke transaksi, memungkinkan kunci pribadi dan alamat yang dioperasikan dipisahkan.

Jadi mengapa memisahkan kepemilikan begitu penting?

Karena desain Externally Owned Accounts (EOA) menyebabkan beberapa isu:

Perlindungan Kunci Pribadi: Kehilangan kunci pribadi (karena kehilangan, peretasan, atau penyusupan kriptografi) berarti kehilangan semua aset.

Algoritma Tanda Tangan Terbatas**: Protokol asli hanya mendukung ECDSA untuk penandatanganan dan verifikasi.

Otoritas Tanda Tangan Tinggi: Tanpa dukungan multi-tanda tangan asli (yang hanya dapat dicapai melalui kontrak pintar), satu tanda tangan dapat menjalankan operasi apa pun.

Biaya Transaksi: Biaya hanya dapat dibayar dalam ETH, yang tidak mendukung volume transaksi yang tinggi.

Privasi Transaksi: Transaksi satu lawan satu membuatnya mudah untuk menganalisis informasi pribadi pemegang akun.

Kendala-kendala ini membuat pengguna rata-rata sulit menggunakan Ethereum:

Untuk menggunakan aplikasi apa pun di Ethereum, pengguna harus memiliki ETH (dan menanggung risiko fluktuasi harga ETH).

Pengguna perlu berurusan dengan logika biaya yang kompleks, seperti harga gas, batas gas, dan pemblokiran transaksi (urutan nonce), yang bisa terlalu rumit.

Meskipun banyak dompet blockchain atau aplikasi berupaya meningkatkan pengalaman pengguna melalui optimisasi produk, efektivitas mereka telah terbatas.

Solusinya terletak pada mengimplementasikan Abstraksi Akun, yang memisahkan kepemilikan (Pemilik) dan otoritas tanda tangan (Tanda Tangan) untuk mengatasi masalah ini. Secara historis, banyak solusi muncul, akhirnya berkumpul menjadi dua pendekatan utama.

3. Tinjauan Historis tentang Usulan Abstraksi Akun

Meskipun mungkin terlihat ada banyak proposal EIP yang mengatasi masalah tersebut, pada dasarnya, hanya ada dua pendekatan inti. Masalah yang dipertimbangkan dalam proposal sebelumnya yang tidak disetujui akhirnya berkonvergensi ke dalam solusi saat ini.

3.1 Rute pertama adalah mengubah alamat EOA menjadi alamat CA

Pada 15 November 2015, Vitalik Buterin mengusulkan struktur akun baru seputar EIP-101, yang melibatkan penggunaan kontrak sebagai akun. Hal ini akan mengubah alamat menjadi entitas dengan hanya kode dan ruang penyimpanan, mengubah dukungan biaya agar dibayar melalui token ERC20, dan menggunakan kontrak pra-dikompilasi untuk mengonversi token asli menjadi token mirip ERC20 untuk penyimpanan saldo (dengan fitur seperti otorisasi yang didelegasikan). Bidang transaksi disederhanakan untuk hanya mencakup penerima, startgas, data, dan kode)

Dengan sudut pandang yang sekarang, ini adalah perubahan revolusioner yang akan secara drastis mengubah desain yang mendasar, memberikan setiap alamat rekeningnya sendiri 'kode' logika, yang pada dasarnya adalah tujuan dari EIP-7702 hari ini. Pendekatan ini juga dapat memungkinkan fitur-fitur tambahan, seperti:

Mengizinkan transaksi menggunakan lebih banyak algoritma kriptografis yang ditentukan oleh kode internal setiap alamat untuk verifikasi dan otentikasi.

Memberikan ketahanan kuantum karena sifat kode yang dapat ditingkatkan.

Memberikan Ether dengan karakteristik fungsional yang sama seperti kontrak ERC20, dengan fitur-fitur seperti otorisasi yang didelegasikan, menghilangkan kebutuhan untuk pengeluaran koin asli.

Meningkatkan kustomisasi akun, mendukung pemulihan sosial, SBT (token terikat jiwa), dan pemulihan kunci.

Alasan tidak mendorong proposal ini sangat sederhana: langkah-langkahnya terlalu ambisius. Masalah seperti tabrakan hash transaksi dan kekhawatiran keamanan tidak sepenuhnya ditangani, yang mengakibatkan penundan. Namun, banyak manfaatnya telah menjadi fitur inti dalam EIP berikutnya, termasuk EIP-4337 dan EIP-7702.

Beberapa EIP kemudian mencoba untuk menyempurnakan logika ini:

EIP-859: Abstraksi Akun di Mainnet (30 Januari 2018) bertujuan untuk mengatasi masalah implementasi kode. Fungsinya inti adalah untuk menggunakan kodeparameter yang dilampirkan ke transaksi untuk mendeploy kontrak dompet jika kontrak belum didirikan. Ini juga memperkenalkan opcode PAYGAS baru untuk memisahkan bagian verifikasi dan eksekusi dari sebuah transaksi.

Meskipun tidak berkembang pada saat itu, logika ini telah menjadi komponen inti dari EIP-7702, yang memungkinkan alamat EOA memiliki kemampuan kontrak melalui struktur transaksi khusus yang dapat mencakup kode.

EIP-7702: Menetapkan Kode Akun EOA (7 Mei 2024) adalah kunci EIP yang dibahas di sini. Vitalik mengusulkan EIP-7702 sebagai alternatif untuk EIP-3074. Akibatnya, EIP-3074 ditinggalkan, dan EIP-7702 dijadwalkan untuk disertakan dalam hard fork ETH Prague/Electra (Pectra) yang akan datang. Rincian lebih lanjut akan dibahas di bawah ini.

3.2 Pendekatan kedua adalah membiarkan alamat EOA mendorong alamat CA.

EIP-3074: Menambahkan Opcodes AUTH dan AUTHCALL (15 Oktober 2020)

EIP ini memperkenalkan dua opcode baru, AUTH dan AUTHCALL, ke dalam EVM, memungkinkan EOAs untuk memberi wewenang kepada kontrak untuk menggantikan identitas mereka dan memanggil kontrak lain. Pada dasarnya, seorang EOA dapat mengirim pesan yang ditandatangani (transaksi) ke kontrak terpercaya (yang disebut Invoker). Kontrak Invoker kemudian dapat menggunakan opcode AUTH dan AUTHCALL untuk mengirim transaksi atas nama EOA.

EIP-4337: Mengimplementasikan Abstraksi Akun melalui Kolam Transaksi (29 September 2021)

Terinspirasi oleh MEV, nilai inti dari EIP ini adalah menghindari perubahan pada protokol lapisan konsensus. EIP-4337 memperkenalkan objek transaksi baru, UserOperation, yang pengguna kirimkan ke mempool. Bundlers kemudian mengelompokkan dan mengirimkan transaksi ini ke eksekusi kontrak, secara efektif memindahkan transaksi tingkat rendah dan operasi akun ke lapisan kontrak.

EIP-5189: Operasi Akun Abstrak melalui Pemberi Penjamin (29 Juni 2022)

EIP ini mengoptimalkan EIP-4337 dengan menangani masalah potensial dengan bundlers jahat. Ini memperkenalkan mekanisme dana yang didukung oleh endorser untuk mencegah serangan DoS dengan menghukum pelaku buruk.

3.3 Proposal Lain yang Mendukung Abstraksi Akun

EIP-2718: Amplop Jenis Transaksi Baru (13 Juni 2020)

Proposal final ini mendefinisikan tipe transaksi baru sebagai amplop untuk tipe transaksi di masa depan. Ini memastikan bahwa ketika tipe transaksi baru diperkenalkan, mereka dapat dibedakan dengan encoding spesifik, menjaga kompatibilitas mundur tanpa memengaruhi tipe-tipe warisan. Contoh umumnya adalah EIP-1559, yang membedakan biaya transaksi dengan encoding tipe transaksi baru sambil mempertahankan tipe-tipe warisan.

EIP-3607: Mencegah Alamat EOA dari Mendeploy Kontrak (10 Juni 2021)

Usulan tambahan ini mengatasi masalah alamat implementasi kontrak yang bertentangan dengan alamat EOA. Ini mengontrol metode pembuatan kontrak, mencegah kode diterapkan ke alamat yang sudah digunakan oleh EOAs. Risikonya minimal mengingat panjang 160-bit dari alamat Ethereum, meskipun secara teoritis mungkin melalui tabrakan kunci, itu akan memerlukan upaya komputasi yang signifikan.

3.4 Memahami Pengembangan Abstraksi Akun

Untuk memahami nilai dari beralih ke alamat CA, penting untuk memahami efek praktis dari EIP-4337, yang dapat mencapai…

Namun, kekurangan inti dari EIP-4337 adalah bahwa itu melanggar prinsip insentif manusia. Meskipun tampaknya menawarkan peningkatan, itu terjebak dalam kebuntuan pengembangan pasar. Banyak Dapps masih tidak kompatibel dengannya, menyebabkan pengguna enggan menggunakan alamat CA. Selain itu, menggunakan CA dapat mengakibatkan biaya transaksi yang lebih tinggi (misalnya, biaya transaksi bisa dua kali lipat dalam skenario transfer biasa), membuatnya sangat bergantung pada kompatibilitas Dapps.

Sebagai hasilnya, ini belum menjadi hal yang umum di Ethereum mainnet hingga saat ini. Biaya adalah faktor paling penting bagi pengguna, dan harus dikurangi. Untuk benar-benar menurunkan biaya GAS, Ethereum sendiri perlu melakukan upgrade soft fork untuk memodifikasi perhitungan GAS atau mengubah konsumsi GAS dari opcode. Mengingat perlunya soft fork, mengapa tidak langsung mempertimbangkan EIP-7702?

4. Analisis Komprehensif tentang EIP-7702

4.1 Apa itu EIP-7702

Ini dibedakan oleh tipe transaksi baru, yang memungkinkan EOA untuk sementara memiliki fungsi kontrak pintar dalam satu transaksi, dengan mendukung transaksi kelompok, transaksi bebas gas, dan manajemen izin yang disesuaikan dalam bisnis, tanpa perlu memperkenalkan opCode EVM baru (Mempengaruhi kompatibilitas ke depan).

Ini memungkinkan pengguna untuk mendapatkan sebagian besar kemampuan AA tanpa implementasi kontrak pintar, dan bahkan dapat memberikan pihak ketiga kemampuan untuk memulai transaksi atas nama pengguna. Ini tidak memerlukan pengguna untuk memberikan kunci privat, tetapi hanya perlu menandatangani informasi yang diotorisasi.

4.2 Struktur data

Dia mendefinisikan tipe transaksi baru 0x04. TransactionPayload dari tipe transaksi ini adalah hasil serialisasi enkoding RLP dari konten berikut

rlp([

chain_id, //Chain ID, digunakan untuk mencegah serangan ulang.

nonce, // Penghitung transaksi untuk memastikan keunikan transaksi.

max_priority_fee_per_gas, //Biaya transaksi 1559

max_fee_per_gas, //biaya transaksi 1559

gas_limit,

tujuan, //Alamat target transaksi

nilai,

data,

access_list, //Daftar akses, digunakan untuk optimisasi Gas dalam EIP-2929.

daftar otorisasi,

signature_y_parity, // 3 parameter tanda tangan, digunakan untuk memverifikasi tanda tangan transaksi.

tanda_tangan_r,

tanda tangan_s

])

Hal penting adalah bahwa objek authorization_list ditambahkan untuk menyimpan kode yang ingin dieksekusi oleh pihak yang menandatangani dalam EOA-nya. Ketika pengguna menandatangani transaksi, ia juga menandatangani kode kontrak yang akan dieksekusi. Ini ada sebagai daftar dua dimensi, menunjukkan bahwa informasi operasi ganda dapat disimpan secara berkelompok, melakukan operasi paket.

authorization_list = [[chain_id, alamat, nonce, y_parity, r, s], …]

4.3 Siklus Hidup Transaksi

4.3.1 Tahap Verifikasi

Pada awal fase eksekusi transaksi, untuk setiap[chain_id, alamat, nonce, y_parity, r, s]tuple di dalamdaftar otorisasi:

Gunakanecrecoverfungsi untuk mendapatkan alamat pengirim dari tanda tangan(r, s)Catatan bahwa ini menggunakan mekanisme Ethereum yang sudah ada, sehingga algoritma tanda tangan tetap tidak berubah oleh EIP ini. Alamat ini dipulihkan menggunakan: otoritas = ecrecover(keccak(MAGIC || rlp([chain_id, alamat, nonce])), y_parity, r, s)Hal ini mirip dengan bagaimana darialamat berasal dari tanda tangan, tetapi berlaku untuk tanda tangan daftar tertentu.

Verifikasi ID rantai untuk mencegah serangan ulang pada rantai yang berbeda.

Periksa jikaotoritaskode penandatangan kosong atau didelegasikan (untuk memastikan apakah transaksi adalah transaksi EIP-7702 yang valid, dengan mekanisme delegasi menangani eksekusi).

Memverifikasiotoritasnonce penandatangan untuk mencegah serangan replay pada tanda tangan.

Atur wewenangkode penanda tangan ke0xef0100 || alamat(untuk menghindari strategi pencegahan tabrakan EIP-3607).

Meningkatkan otoritasnonce penandatangan (untuk mencegah pengulangan tanda tangan lokal).

Tambahkan otoritasakun penandatangan untuk daftar akses (untuk beralih ke penyimpanan panas, mengurangi biaya gas untuk akses).

Fase Eksekusi 4.3.2

Di mana kode kontrak dan instruksi operasional dijalankan?

Versi “baru” mengubah cara kode kontrak diimplementasikan. Alih-alih mengatur kode akun secara langsung, ia mengambil kode dari daftar otorisasialamat dan mengaturnya sebagai kode akun.

Saat menjalankan kode yang diotorisasi, muat kode dari alamat yang ditentukan di daftar otorisasidan menjalankannya dalam konteks akun penandatangan. Ini berarti kode kontrak pengguna disimpan di alamat tertentu di blockchain, daripada langsung disertakan dalam transaksi.

Petunjuk operasional dan parameter terkait disimpan di dalam databidang muatan transaksi.

4.4 Apa nilai dari EIP-7702?

EIP-7702 memperkenalkan nilai yang signifikan karena secara mendasar mengubah seluruh proses transaksi untuk dompet Web3, menyebabkan transformasi drastis dalam pengalaman pengguna. Transaksi biasa yang diinisiasi oleh EOA (Akun Dimiliki Secara Eksternal) sekarang dapat menjalankan logika ganda serupa dengan eksekusi kontrak pintar, seperti transfer batch. Hal ini juga berdampak pada skenario CeFi, mempengaruhi identifikasi transaksi dan biaya untuk penarikan dan konsolidasi.

EIP-7702 melanggar banyak asumsi yang telah lama berlaku: Ia melanggar invarian bahwa saldo rekening hanya dapat berkurang karena transaksi berasal dari rekening tersebut. Ia melanggar invarian bahwa nonce EOA meningkat sebanyak 1 setelah pelaksanaan transaksi dimulai (sekarang bisa meningkat sekaligus dengan nilai-nilai ganda). Ia melanggar logika protektif yang bergantung pada perbandingan tx.origindanmsg.sender, memperkenalkan risiko potensial bagi banyak kontrak yang ada. Ini juga melanggar fakta bahwa sebuah EOA itu sendiri tidak dapat mengeluarkan peristiwa, yang dapat memengaruhi identifikasi dan pemantauan beberapa peristiwa on-chain tertentu. Terakhir, ini melanggar asumsi bahwa alamat EOA akan selalu berhasil menerima aset ERC20, 721, 1155, dan lainnya (karena mungkin gagal karena mekanisme callback).

4.5 Perbandingan antara EIP-7702 dan EIP-4337

1. Keuntungan dari EIP-7702

EIP-7702 memiliki beberapa keuntungan. Salah satunya adalah biaya gas yang lebih rendah, karena tidak memerlukan melalui modul titik masuk, mengurangi operasi on-chain. Yang lainnya adalah biaya migrasi pengguna yang lebih rendah, karena tidak perlu mendeploy kontrak on-chain sebagai entitas utama sebelumnya.

Dibandingkan dengan EIP-4337, EIP-7702 juga mendukung eksekusi kode yang didelegasikan dan menawarkan dua jenis delegasi:

Delegasi Penuh: Ini berarti mendelagasikan kendali penuh dari suatu operasi tertentu ke alamat tertentu. Misalnya, seorang pengguna dapat mendelagasikan pengelolaan semua token ERC-20 ke alamat kontrak pintar, memungkinkan kontrak untuk melakukan semua operasi terkait atas nama pengguna.

Delegasi Dilindungi: Ini melibatkan penambahan pembatasan dan perlindungan selama delegasi untuk memastikan keamanan dan kendali operasi yang didelegasikan. Misalnya, pengguna dapat mendelegasikan hanya sebagian hak pengelolaan dari token ERC-20 ke kontrak pintar atau menetapkan kondisi (misalnya, menghabiskan maksimal 1% dari total saldo per hari).

2. Kekurangan EIP-7702

Kerugian utama dari EIP-7702 adalah melibatkan upgrade fork lunak, memerlukan konsensus dari komunitas untuk mendorong ke depan. Perubahan-perubahannya signifikan dan dapat memiliki dampak luas pada ekosistem on-chain. Berdasarkan penilaian awal oleh Shisi Jun, beberapa tantangan telah diidentifikasi, namun tantangan-tantangan ini juga dapat mewakili peluang pasar:

Tingkat kebebasan yang tinggi membuat pemeriksaan sulit, sehingga pengguna menuntut dompet yang lebih dapat diandalkan untuk memastikan perlindungan keamanan.

Perubahan pada arsitektur asli sangat signifikan. Meskipun berbagai jenis transaksi dapat dibedakan, banyak infrastruktur dasar, terutama kontrak on-chain yang tidak berubah, mungkin tidak secara langsung kompatibel.

Sementara EIP-7702 menyediakan kemampuan kontrak ke alamat EOA, ruang penyimpanan yang sesuai tidak dapat dipertahankan.

Biaya transaksi individu sedikit lebih tinggi karena peningkatan signifikan di bagian Calldata. Total biaya estimasi panggilan akan menjadi 16 (gas) 15 (bytes) = 240 (gas) untuk biaya calldata, ditambah biaya EIP-3860 sebesar 2 15 = 30, dan sekitar 150 untuk biaya runtime. Oleh karena itu, bahkan menyiapkan akun tanpa operasi akan meningkatkan biaya gas sekitar 500.

“Jika penerima menandatangani kode yang tidak memiliki fungsi penerimaan, pengirim dapat menghadapi DoS saat mencoba mengirim aset.” Lihat kasusnya. Masalah ini muncul ketika EOA A menandatangani sesuatu yang seharusnya tidak—sebuah file yang dapat diulang dengan implementasi yang tidak benar (tidak memilikiterima().

Logika konsolidasi dan penarikan on-chain mungkin tidak konsisten. Misalnya, saat mentransfer token ERC-20, jika akun penerima memiliki kode, kontrak token akan memanggilonERC20Receivedpada akun penerima. Jika onERC20Receivedmengembalikan atau mengembalikan nilai yang salah, transfer token akan mengembalikan.

Selain itu, jika sebuah EOA dapat mengeluarkan acara, apakah bisa ada masalah? Beberapa infrastruktur mungkin perlu memperhatikan hal ini.

Ini hanya beberapa kekurangan yang dirangkum oleh Shisi Jun berdasarkan proposal EIP-7702 saat ini dan diskusi di forum resmi. Analisis lengkap akan memerlukan pemeriksaan kode implementasi akhir.

5. Ringkasan

Artikel ini mungkin terlihat luas, tetapi hanya mengandung sekitar 6.000 kata. Banyak referensi ke interpretasi EIP masa lalu terkait dalam teks untuk eksplorasi lebih lanjut, jadi saya tidak akan membahasnya di sini.

Saat ini, tampaknya abstraksi akun hanya dapat ditempatkan dalam modul keenam, yang merupakan tahap akhir perbaikan sebelum mendorongnya ke depan. Kemajuan cepat dari EIP-7702 terutama membawa tantangan bagi keamanan sistem. Dapat diprediksi bahwa akhirnya akan diimplementasikan. Bagaimanapun juga, penggabungan Ethereum, yang melibatkan renovasi besar-besaran dari algoritma konsensus, sudah terjadi. Jenis transaksi baru relatif kecil dibandingkan dengan itu.

Namun, kali ini perubahannya cukup mengganggu, melanggar beberapa aturan on-chain yang sebelumnya "tidak mungkin" dan mengubah logika sebagian besar DApps. Namun, EIP-7702 dengan kuat memahami poin yang paling penting: secara signifikan mengurangi biaya pengguna. Sebaliknya, EIP-4337 hampir menggandakan biaya transaksi.

Pengguna tetap menjadi alamat EOA (Akun Milik Eksternal) tetapi hanya memanggil dan menggunakan logika CA (Akun Kontrak) bila diperlukan, sehingga mengurangi biaya penyimpanan. Tidak perlu terlebih dahulu mengonversi ke identitas CA on-chain sebelum melakukan tindakan, yang berarti pengguna tidak perlu mendaftar.

Pengguna dapat dengan mudah melakukan beberapa transaksi secara paralel menggunakan EOA mereka, seperti menggabungkan otorisasi untuk potongan dan mengeksekusi potongan tersebut. Ini secara inheren menurunkan biaya transaksi bagi pengguna. Bagi DApps, terutama proyek-proyek yang memerlukan manajemen tingkat perusahaan on-chain, seperti pertukaran, optimasi ini revolusioner. Jika konsolidasi batch diimplementasikan secara native, biaya operasional dasar untuk pertukaran bisa dikurangi lebih dari separuh, dan pada akhirnya menguntungkan pengguna juga.

Oleh karena itu, meskipun EIP-7702 memperkenalkan banyak perubahan, dampaknya terhadap biaya saja membuat nilainya untuk dipelajari dan diadaptasi untuk semua DApps. Kali ini, pengguna tidak diragukan lagi berada di pihak EIP-7702.

Penafian:

  1. Artikel ini diambil dari [PANews]. Semua hak cipta dimiliki oleh penulis asli [Fourteenth Lord]. Jika ada keberatan terhadap cetak ulang ini, silakan hubungi Belajar Gatetim, dan mereka akan menanganinya dengan segera.
  2. Penolakan Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan saran investasi apa pun.
  3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.

Analisis Mendalam tentang Sejarah dan Masa Depan Abstraksi Akun Ethereum

Lanjutan9/12/2024, 1:51:56 AM
Artikel ini akan dimulai dengan proposal Account Abstraksi (AA) pertama dari tahun 2015, secara sistematis mengorganisir konten utama dari proposal EIP hingga saat ini, kemudian membandingkan umpan balik pasar setelah diperkenalkannya EIP-4337, dan akhirnya menganalisis EIP-7702, yang direncanakan akan disertakan dalam upgrade Ethereum berikutnya.

Pendahuluan

Artikel ini dibagi menjadi dua bagian utama:

Pada bagian pertama, itu akan dimulai dengan proposal AA pertama dari tahun 2015, secara sistematis mengorganisasikan konten utama dari proposal EIP hingga saat ini. Tujuannya adalah untuk mengeksplorasi perkembangan sejarah dari proposal AA dan menilai secara komprehensif kelebihan dan kelemahan dari setiap proposal.

Pada bagian kedua, akan difokuskan pada perbandingan umpan balik pasar setelah diperkenalkannya EIP-4337 dan kemudian akan menjelajahi analisis EIP-7702, yang dijadwalkan akan disertakan dalam upgrade Ethereum berikutnya. Usulan ini, setelah digabungkan, diharapkan akan secara signifikan mengubah sifat aplikasi on-chain.

EIP-7702 menjanjikan perubahan revolusioner, dan kami akan membahasnya secara detail.

1. Latar Belakang Abstraksi Akun

1.1 Arti abstraksi akun

Pada akhir 2023, pendiri Ethereum Vitalik Buterin sekali lagi memperbarui peta jalan pengembangan ETH. Namun, ketentuan terkait Abstraksi Akun tetap tidak berubah. Model utama saat ini terus berkembang dari EIP-4337 ke fase berikutnya: Konversi EOA Sukarela (konversi akun EOA yang diinisiasi sendiri).


https://x.com/VitalikButerin/status/1741190491578810445

Sejak rilis EIP-4337 lebih dari setahun yang lalu (pada 1 Maret 2023, di WalletCon di Denver, pengembang Ethereum Foundation mengumumkan bahwa kontrak inti ERC-4337 telah lolos audit OpenZeppelin, menandai tonggak sejarah untuk peluncuran resminya), proyek ini telah menerima pengakuan pengguna yang luas tetapi belum melihat adopsi yang luas. Lingkungan pasar paradoks ini telah mempercepat kemajuan EIP-7702, yang sekarang dikonfirmasi akan disertakan dalam upgrade berikutnya.

1.2 Status pasar saat ini dari abstraksi akun

Tanpa basa-basi, mari kita lihat data tersebut.

Setelah setahun setengah pengembangan, EIP-4337 hanya mengumpulkan 12 juta alamat di bawah akun rantai utama. Yang sangat mengejutkan adalah bahwa di mainnet Ethereum, hanya ada 6.764 alamat aktif. Meskipun mungkin ada isu dengan dimensi statistik, jumlah ini tetap jauh berbeda dari jumlah alamat untuk EOAs dan CAs. Untuk konteks, jumlah alamat unik di mainnet Ethereum telah mencapai 270 juta (sumber: https://etherscan.io/chart/address.

Bisa dikatakan bahwa EIP-4337 belum membuat kemajuan substansial di mainnet.


(Sumber chart: https://dune.com/niftytable/account-abstraction)

Namun, hal ini tidak mengurangi nilai intrinsik Account Abstraction (AA). Sejak awal, desain EIP-4337 sudah ditakdirkan untuk menghadapi masalah kompatibilitas mundur yang signifikan di mainnet. Akibatnya, dengan berbagai rantai Layer 2 yang mengintegrasikan AA asli, EIP-4337 telah mengalami pertumbuhan yang signifikan dalam jumlah alamat di Layer 2. Sebagai contoh, pada bulan Juli, jumlah pengguna aktif di rantai Base dan Polygon mencapai masing-masing 1 juta dan 3 juta, yang cukup mengesankan.

Oleh karena itu, bukanlah desain dari EIP-4337 yang cacat; memiliki banyak keunggulan yang akan kami ringkas secara sistematis. Situasi saat ini muncul dari perbedaan antara mainnet dan Layer 2, masing-masing memerlukan solusi yang disesuaikan.

2. Apa itu Abstraksi Akun?

Abstraksi Akun mungkin terdengar kompleks, tetapi pada dasarnya mengatasi masalah pemisahan kepemilikan.

Dalam arsitektur Mesin Virtual Ethereum (EVM), ada dua jenis akun: Akun Milik Eksternal (EOAs) dan Akun Kontrak. Pada EOAs, kepemilikan dan otoritas tanda tangan dipegang oleh entitas yang sama. Orang dengan kunci pribadi tidak hanya memiliki akun tetapi juga berhak untuk menandatangani dan mentransfer semua asetnya.

Pengaturan ini ditentukan oleh struktur transaksi rekening Ethereum. Dalam transaksi Ethereum standar, tidak ada alamat "Dari" langsung yang terlihat. Ketika transfer dana terjadi, alamat aktual dari mana dana tersebut dihabiskan disimpulkan melalui parameter VRS (yaitu, tanda tangan pengguna).

Ini melibatkan konsep seperti enkripsi asimetris ECDSA dan fungsi ambang satu arah, tetapi kami tidak akan mendalami detail-detail tersebut di sini. Pada dasarnya, kriptografi memastikan keamanan, yang mengarah ke situasi saat ini di mana kepemilikan dan otoritas tanda tangan digabungkan dalam EOAs.

Efek inti dari EIP-4337 adalah menambahkan kolom Alamat Pengirim ke transaksi, memungkinkan kunci pribadi dan alamat yang dioperasikan dipisahkan.

Jadi mengapa memisahkan kepemilikan begitu penting?

Karena desain Externally Owned Accounts (EOA) menyebabkan beberapa isu:

Perlindungan Kunci Pribadi: Kehilangan kunci pribadi (karena kehilangan, peretasan, atau penyusupan kriptografi) berarti kehilangan semua aset.

Algoritma Tanda Tangan Terbatas**: Protokol asli hanya mendukung ECDSA untuk penandatanganan dan verifikasi.

Otoritas Tanda Tangan Tinggi: Tanpa dukungan multi-tanda tangan asli (yang hanya dapat dicapai melalui kontrak pintar), satu tanda tangan dapat menjalankan operasi apa pun.

Biaya Transaksi: Biaya hanya dapat dibayar dalam ETH, yang tidak mendukung volume transaksi yang tinggi.

Privasi Transaksi: Transaksi satu lawan satu membuatnya mudah untuk menganalisis informasi pribadi pemegang akun.

Kendala-kendala ini membuat pengguna rata-rata sulit menggunakan Ethereum:

Untuk menggunakan aplikasi apa pun di Ethereum, pengguna harus memiliki ETH (dan menanggung risiko fluktuasi harga ETH).

Pengguna perlu berurusan dengan logika biaya yang kompleks, seperti harga gas, batas gas, dan pemblokiran transaksi (urutan nonce), yang bisa terlalu rumit.

Meskipun banyak dompet blockchain atau aplikasi berupaya meningkatkan pengalaman pengguna melalui optimisasi produk, efektivitas mereka telah terbatas.

Solusinya terletak pada mengimplementasikan Abstraksi Akun, yang memisahkan kepemilikan (Pemilik) dan otoritas tanda tangan (Tanda Tangan) untuk mengatasi masalah ini. Secara historis, banyak solusi muncul, akhirnya berkumpul menjadi dua pendekatan utama.

3. Tinjauan Historis tentang Usulan Abstraksi Akun

Meskipun mungkin terlihat ada banyak proposal EIP yang mengatasi masalah tersebut, pada dasarnya, hanya ada dua pendekatan inti. Masalah yang dipertimbangkan dalam proposal sebelumnya yang tidak disetujui akhirnya berkonvergensi ke dalam solusi saat ini.

3.1 Rute pertama adalah mengubah alamat EOA menjadi alamat CA

Pada 15 November 2015, Vitalik Buterin mengusulkan struktur akun baru seputar EIP-101, yang melibatkan penggunaan kontrak sebagai akun. Hal ini akan mengubah alamat menjadi entitas dengan hanya kode dan ruang penyimpanan, mengubah dukungan biaya agar dibayar melalui token ERC20, dan menggunakan kontrak pra-dikompilasi untuk mengonversi token asli menjadi token mirip ERC20 untuk penyimpanan saldo (dengan fitur seperti otorisasi yang didelegasikan). Bidang transaksi disederhanakan untuk hanya mencakup penerima, startgas, data, dan kode)

Dengan sudut pandang yang sekarang, ini adalah perubahan revolusioner yang akan secara drastis mengubah desain yang mendasar, memberikan setiap alamat rekeningnya sendiri 'kode' logika, yang pada dasarnya adalah tujuan dari EIP-7702 hari ini. Pendekatan ini juga dapat memungkinkan fitur-fitur tambahan, seperti:

Mengizinkan transaksi menggunakan lebih banyak algoritma kriptografis yang ditentukan oleh kode internal setiap alamat untuk verifikasi dan otentikasi.

Memberikan ketahanan kuantum karena sifat kode yang dapat ditingkatkan.

Memberikan Ether dengan karakteristik fungsional yang sama seperti kontrak ERC20, dengan fitur-fitur seperti otorisasi yang didelegasikan, menghilangkan kebutuhan untuk pengeluaran koin asli.

Meningkatkan kustomisasi akun, mendukung pemulihan sosial, SBT (token terikat jiwa), dan pemulihan kunci.

Alasan tidak mendorong proposal ini sangat sederhana: langkah-langkahnya terlalu ambisius. Masalah seperti tabrakan hash transaksi dan kekhawatiran keamanan tidak sepenuhnya ditangani, yang mengakibatkan penundan. Namun, banyak manfaatnya telah menjadi fitur inti dalam EIP berikutnya, termasuk EIP-4337 dan EIP-7702.

Beberapa EIP kemudian mencoba untuk menyempurnakan logika ini:

EIP-859: Abstraksi Akun di Mainnet (30 Januari 2018) bertujuan untuk mengatasi masalah implementasi kode. Fungsinya inti adalah untuk menggunakan kodeparameter yang dilampirkan ke transaksi untuk mendeploy kontrak dompet jika kontrak belum didirikan. Ini juga memperkenalkan opcode PAYGAS baru untuk memisahkan bagian verifikasi dan eksekusi dari sebuah transaksi.

Meskipun tidak berkembang pada saat itu, logika ini telah menjadi komponen inti dari EIP-7702, yang memungkinkan alamat EOA memiliki kemampuan kontrak melalui struktur transaksi khusus yang dapat mencakup kode.

EIP-7702: Menetapkan Kode Akun EOA (7 Mei 2024) adalah kunci EIP yang dibahas di sini. Vitalik mengusulkan EIP-7702 sebagai alternatif untuk EIP-3074. Akibatnya, EIP-3074 ditinggalkan, dan EIP-7702 dijadwalkan untuk disertakan dalam hard fork ETH Prague/Electra (Pectra) yang akan datang. Rincian lebih lanjut akan dibahas di bawah ini.

3.2 Pendekatan kedua adalah membiarkan alamat EOA mendorong alamat CA.

EIP-3074: Menambahkan Opcodes AUTH dan AUTHCALL (15 Oktober 2020)

EIP ini memperkenalkan dua opcode baru, AUTH dan AUTHCALL, ke dalam EVM, memungkinkan EOAs untuk memberi wewenang kepada kontrak untuk menggantikan identitas mereka dan memanggil kontrak lain. Pada dasarnya, seorang EOA dapat mengirim pesan yang ditandatangani (transaksi) ke kontrak terpercaya (yang disebut Invoker). Kontrak Invoker kemudian dapat menggunakan opcode AUTH dan AUTHCALL untuk mengirim transaksi atas nama EOA.

EIP-4337: Mengimplementasikan Abstraksi Akun melalui Kolam Transaksi (29 September 2021)

Terinspirasi oleh MEV, nilai inti dari EIP ini adalah menghindari perubahan pada protokol lapisan konsensus. EIP-4337 memperkenalkan objek transaksi baru, UserOperation, yang pengguna kirimkan ke mempool. Bundlers kemudian mengelompokkan dan mengirimkan transaksi ini ke eksekusi kontrak, secara efektif memindahkan transaksi tingkat rendah dan operasi akun ke lapisan kontrak.

EIP-5189: Operasi Akun Abstrak melalui Pemberi Penjamin (29 Juni 2022)

EIP ini mengoptimalkan EIP-4337 dengan menangani masalah potensial dengan bundlers jahat. Ini memperkenalkan mekanisme dana yang didukung oleh endorser untuk mencegah serangan DoS dengan menghukum pelaku buruk.

3.3 Proposal Lain yang Mendukung Abstraksi Akun

EIP-2718: Amplop Jenis Transaksi Baru (13 Juni 2020)

Proposal final ini mendefinisikan tipe transaksi baru sebagai amplop untuk tipe transaksi di masa depan. Ini memastikan bahwa ketika tipe transaksi baru diperkenalkan, mereka dapat dibedakan dengan encoding spesifik, menjaga kompatibilitas mundur tanpa memengaruhi tipe-tipe warisan. Contoh umumnya adalah EIP-1559, yang membedakan biaya transaksi dengan encoding tipe transaksi baru sambil mempertahankan tipe-tipe warisan.

EIP-3607: Mencegah Alamat EOA dari Mendeploy Kontrak (10 Juni 2021)

Usulan tambahan ini mengatasi masalah alamat implementasi kontrak yang bertentangan dengan alamat EOA. Ini mengontrol metode pembuatan kontrak, mencegah kode diterapkan ke alamat yang sudah digunakan oleh EOAs. Risikonya minimal mengingat panjang 160-bit dari alamat Ethereum, meskipun secara teoritis mungkin melalui tabrakan kunci, itu akan memerlukan upaya komputasi yang signifikan.

3.4 Memahami Pengembangan Abstraksi Akun

Untuk memahami nilai dari beralih ke alamat CA, penting untuk memahami efek praktis dari EIP-4337, yang dapat mencapai…

Namun, kekurangan inti dari EIP-4337 adalah bahwa itu melanggar prinsip insentif manusia. Meskipun tampaknya menawarkan peningkatan, itu terjebak dalam kebuntuan pengembangan pasar. Banyak Dapps masih tidak kompatibel dengannya, menyebabkan pengguna enggan menggunakan alamat CA. Selain itu, menggunakan CA dapat mengakibatkan biaya transaksi yang lebih tinggi (misalnya, biaya transaksi bisa dua kali lipat dalam skenario transfer biasa), membuatnya sangat bergantung pada kompatibilitas Dapps.

Sebagai hasilnya, ini belum menjadi hal yang umum di Ethereum mainnet hingga saat ini. Biaya adalah faktor paling penting bagi pengguna, dan harus dikurangi. Untuk benar-benar menurunkan biaya GAS, Ethereum sendiri perlu melakukan upgrade soft fork untuk memodifikasi perhitungan GAS atau mengubah konsumsi GAS dari opcode. Mengingat perlunya soft fork, mengapa tidak langsung mempertimbangkan EIP-7702?

4. Analisis Komprehensif tentang EIP-7702

4.1 Apa itu EIP-7702

Ini dibedakan oleh tipe transaksi baru, yang memungkinkan EOA untuk sementara memiliki fungsi kontrak pintar dalam satu transaksi, dengan mendukung transaksi kelompok, transaksi bebas gas, dan manajemen izin yang disesuaikan dalam bisnis, tanpa perlu memperkenalkan opCode EVM baru (Mempengaruhi kompatibilitas ke depan).

Ini memungkinkan pengguna untuk mendapatkan sebagian besar kemampuan AA tanpa implementasi kontrak pintar, dan bahkan dapat memberikan pihak ketiga kemampuan untuk memulai transaksi atas nama pengguna. Ini tidak memerlukan pengguna untuk memberikan kunci privat, tetapi hanya perlu menandatangani informasi yang diotorisasi.

4.2 Struktur data

Dia mendefinisikan tipe transaksi baru 0x04. TransactionPayload dari tipe transaksi ini adalah hasil serialisasi enkoding RLP dari konten berikut

rlp([

chain_id, //Chain ID, digunakan untuk mencegah serangan ulang.

nonce, // Penghitung transaksi untuk memastikan keunikan transaksi.

max_priority_fee_per_gas, //Biaya transaksi 1559

max_fee_per_gas, //biaya transaksi 1559

gas_limit,

tujuan, //Alamat target transaksi

nilai,

data,

access_list, //Daftar akses, digunakan untuk optimisasi Gas dalam EIP-2929.

daftar otorisasi,

signature_y_parity, // 3 parameter tanda tangan, digunakan untuk memverifikasi tanda tangan transaksi.

tanda_tangan_r,

tanda tangan_s

])

Hal penting adalah bahwa objek authorization_list ditambahkan untuk menyimpan kode yang ingin dieksekusi oleh pihak yang menandatangani dalam EOA-nya. Ketika pengguna menandatangani transaksi, ia juga menandatangani kode kontrak yang akan dieksekusi. Ini ada sebagai daftar dua dimensi, menunjukkan bahwa informasi operasi ganda dapat disimpan secara berkelompok, melakukan operasi paket.

authorization_list = [[chain_id, alamat, nonce, y_parity, r, s], …]

4.3 Siklus Hidup Transaksi

4.3.1 Tahap Verifikasi

Pada awal fase eksekusi transaksi, untuk setiap[chain_id, alamat, nonce, y_parity, r, s]tuple di dalamdaftar otorisasi:

Gunakanecrecoverfungsi untuk mendapatkan alamat pengirim dari tanda tangan(r, s)Catatan bahwa ini menggunakan mekanisme Ethereum yang sudah ada, sehingga algoritma tanda tangan tetap tidak berubah oleh EIP ini. Alamat ini dipulihkan menggunakan: otoritas = ecrecover(keccak(MAGIC || rlp([chain_id, alamat, nonce])), y_parity, r, s)Hal ini mirip dengan bagaimana darialamat berasal dari tanda tangan, tetapi berlaku untuk tanda tangan daftar tertentu.

Verifikasi ID rantai untuk mencegah serangan ulang pada rantai yang berbeda.

Periksa jikaotoritaskode penandatangan kosong atau didelegasikan (untuk memastikan apakah transaksi adalah transaksi EIP-7702 yang valid, dengan mekanisme delegasi menangani eksekusi).

Memverifikasiotoritasnonce penandatangan untuk mencegah serangan replay pada tanda tangan.

Atur wewenangkode penanda tangan ke0xef0100 || alamat(untuk menghindari strategi pencegahan tabrakan EIP-3607).

Meningkatkan otoritasnonce penandatangan (untuk mencegah pengulangan tanda tangan lokal).

Tambahkan otoritasakun penandatangan untuk daftar akses (untuk beralih ke penyimpanan panas, mengurangi biaya gas untuk akses).

Fase Eksekusi 4.3.2

Di mana kode kontrak dan instruksi operasional dijalankan?

Versi “baru” mengubah cara kode kontrak diimplementasikan. Alih-alih mengatur kode akun secara langsung, ia mengambil kode dari daftar otorisasialamat dan mengaturnya sebagai kode akun.

Saat menjalankan kode yang diotorisasi, muat kode dari alamat yang ditentukan di daftar otorisasidan menjalankannya dalam konteks akun penandatangan. Ini berarti kode kontrak pengguna disimpan di alamat tertentu di blockchain, daripada langsung disertakan dalam transaksi.

Petunjuk operasional dan parameter terkait disimpan di dalam databidang muatan transaksi.

4.4 Apa nilai dari EIP-7702?

EIP-7702 memperkenalkan nilai yang signifikan karena secara mendasar mengubah seluruh proses transaksi untuk dompet Web3, menyebabkan transformasi drastis dalam pengalaman pengguna. Transaksi biasa yang diinisiasi oleh EOA (Akun Dimiliki Secara Eksternal) sekarang dapat menjalankan logika ganda serupa dengan eksekusi kontrak pintar, seperti transfer batch. Hal ini juga berdampak pada skenario CeFi, mempengaruhi identifikasi transaksi dan biaya untuk penarikan dan konsolidasi.

EIP-7702 melanggar banyak asumsi yang telah lama berlaku: Ia melanggar invarian bahwa saldo rekening hanya dapat berkurang karena transaksi berasal dari rekening tersebut. Ia melanggar invarian bahwa nonce EOA meningkat sebanyak 1 setelah pelaksanaan transaksi dimulai (sekarang bisa meningkat sekaligus dengan nilai-nilai ganda). Ia melanggar logika protektif yang bergantung pada perbandingan tx.origindanmsg.sender, memperkenalkan risiko potensial bagi banyak kontrak yang ada. Ini juga melanggar fakta bahwa sebuah EOA itu sendiri tidak dapat mengeluarkan peristiwa, yang dapat memengaruhi identifikasi dan pemantauan beberapa peristiwa on-chain tertentu. Terakhir, ini melanggar asumsi bahwa alamat EOA akan selalu berhasil menerima aset ERC20, 721, 1155, dan lainnya (karena mungkin gagal karena mekanisme callback).

4.5 Perbandingan antara EIP-7702 dan EIP-4337

1. Keuntungan dari EIP-7702

EIP-7702 memiliki beberapa keuntungan. Salah satunya adalah biaya gas yang lebih rendah, karena tidak memerlukan melalui modul titik masuk, mengurangi operasi on-chain. Yang lainnya adalah biaya migrasi pengguna yang lebih rendah, karena tidak perlu mendeploy kontrak on-chain sebagai entitas utama sebelumnya.

Dibandingkan dengan EIP-4337, EIP-7702 juga mendukung eksekusi kode yang didelegasikan dan menawarkan dua jenis delegasi:

Delegasi Penuh: Ini berarti mendelagasikan kendali penuh dari suatu operasi tertentu ke alamat tertentu. Misalnya, seorang pengguna dapat mendelagasikan pengelolaan semua token ERC-20 ke alamat kontrak pintar, memungkinkan kontrak untuk melakukan semua operasi terkait atas nama pengguna.

Delegasi Dilindungi: Ini melibatkan penambahan pembatasan dan perlindungan selama delegasi untuk memastikan keamanan dan kendali operasi yang didelegasikan. Misalnya, pengguna dapat mendelegasikan hanya sebagian hak pengelolaan dari token ERC-20 ke kontrak pintar atau menetapkan kondisi (misalnya, menghabiskan maksimal 1% dari total saldo per hari).

2. Kekurangan EIP-7702

Kerugian utama dari EIP-7702 adalah melibatkan upgrade fork lunak, memerlukan konsensus dari komunitas untuk mendorong ke depan. Perubahan-perubahannya signifikan dan dapat memiliki dampak luas pada ekosistem on-chain. Berdasarkan penilaian awal oleh Shisi Jun, beberapa tantangan telah diidentifikasi, namun tantangan-tantangan ini juga dapat mewakili peluang pasar:

Tingkat kebebasan yang tinggi membuat pemeriksaan sulit, sehingga pengguna menuntut dompet yang lebih dapat diandalkan untuk memastikan perlindungan keamanan.

Perubahan pada arsitektur asli sangat signifikan. Meskipun berbagai jenis transaksi dapat dibedakan, banyak infrastruktur dasar, terutama kontrak on-chain yang tidak berubah, mungkin tidak secara langsung kompatibel.

Sementara EIP-7702 menyediakan kemampuan kontrak ke alamat EOA, ruang penyimpanan yang sesuai tidak dapat dipertahankan.

Biaya transaksi individu sedikit lebih tinggi karena peningkatan signifikan di bagian Calldata. Total biaya estimasi panggilan akan menjadi 16 (gas) 15 (bytes) = 240 (gas) untuk biaya calldata, ditambah biaya EIP-3860 sebesar 2 15 = 30, dan sekitar 150 untuk biaya runtime. Oleh karena itu, bahkan menyiapkan akun tanpa operasi akan meningkatkan biaya gas sekitar 500.

“Jika penerima menandatangani kode yang tidak memiliki fungsi penerimaan, pengirim dapat menghadapi DoS saat mencoba mengirim aset.” Lihat kasusnya. Masalah ini muncul ketika EOA A menandatangani sesuatu yang seharusnya tidak—sebuah file yang dapat diulang dengan implementasi yang tidak benar (tidak memilikiterima().

Logika konsolidasi dan penarikan on-chain mungkin tidak konsisten. Misalnya, saat mentransfer token ERC-20, jika akun penerima memiliki kode, kontrak token akan memanggilonERC20Receivedpada akun penerima. Jika onERC20Receivedmengembalikan atau mengembalikan nilai yang salah, transfer token akan mengembalikan.

Selain itu, jika sebuah EOA dapat mengeluarkan acara, apakah bisa ada masalah? Beberapa infrastruktur mungkin perlu memperhatikan hal ini.

Ini hanya beberapa kekurangan yang dirangkum oleh Shisi Jun berdasarkan proposal EIP-7702 saat ini dan diskusi di forum resmi. Analisis lengkap akan memerlukan pemeriksaan kode implementasi akhir.

5. Ringkasan

Artikel ini mungkin terlihat luas, tetapi hanya mengandung sekitar 6.000 kata. Banyak referensi ke interpretasi EIP masa lalu terkait dalam teks untuk eksplorasi lebih lanjut, jadi saya tidak akan membahasnya di sini.

Saat ini, tampaknya abstraksi akun hanya dapat ditempatkan dalam modul keenam, yang merupakan tahap akhir perbaikan sebelum mendorongnya ke depan. Kemajuan cepat dari EIP-7702 terutama membawa tantangan bagi keamanan sistem. Dapat diprediksi bahwa akhirnya akan diimplementasikan. Bagaimanapun juga, penggabungan Ethereum, yang melibatkan renovasi besar-besaran dari algoritma konsensus, sudah terjadi. Jenis transaksi baru relatif kecil dibandingkan dengan itu.

Namun, kali ini perubahannya cukup mengganggu, melanggar beberapa aturan on-chain yang sebelumnya "tidak mungkin" dan mengubah logika sebagian besar DApps. Namun, EIP-7702 dengan kuat memahami poin yang paling penting: secara signifikan mengurangi biaya pengguna. Sebaliknya, EIP-4337 hampir menggandakan biaya transaksi.

Pengguna tetap menjadi alamat EOA (Akun Milik Eksternal) tetapi hanya memanggil dan menggunakan logika CA (Akun Kontrak) bila diperlukan, sehingga mengurangi biaya penyimpanan. Tidak perlu terlebih dahulu mengonversi ke identitas CA on-chain sebelum melakukan tindakan, yang berarti pengguna tidak perlu mendaftar.

Pengguna dapat dengan mudah melakukan beberapa transaksi secara paralel menggunakan EOA mereka, seperti menggabungkan otorisasi untuk potongan dan mengeksekusi potongan tersebut. Ini secara inheren menurunkan biaya transaksi bagi pengguna. Bagi DApps, terutama proyek-proyek yang memerlukan manajemen tingkat perusahaan on-chain, seperti pertukaran, optimasi ini revolusioner. Jika konsolidasi batch diimplementasikan secara native, biaya operasional dasar untuk pertukaran bisa dikurangi lebih dari separuh, dan pada akhirnya menguntungkan pengguna juga.

Oleh karena itu, meskipun EIP-7702 memperkenalkan banyak perubahan, dampaknya terhadap biaya saja membuat nilainya untuk dipelajari dan diadaptasi untuk semua DApps. Kali ini, pengguna tidak diragukan lagi berada di pihak EIP-7702.

Penafian:

  1. Artikel ini diambil dari [PANews]. Semua hak cipta dimiliki oleh penulis asli [Fourteenth Lord]. Jika ada keberatan terhadap cetak ulang ini, silakan hubungi Belajar Gatetim, dan mereka akan menanganinya dengan segera.
  2. Penolakan Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan saran investasi apa pun.
  3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.
Розпочати зараз
Зареєструйтеся та отримайте ваучер на
$100
!