Ethereum memiliki dua tipe akun: Akun Dimiliki Secara Eksternal (EOA) dan Akun Kontrak (CA). EOA dikendalikan oleh kunci pribadi sedangkan CA dikendalikan oleh kode kontrak pintar yang terdapat di dalamnya. EOA selalu lebih diuntungkan daripada CA karena hanya EOA yang bisa memulai eksekusi transaksi dengan membayar gas. Account Abstraction (AA) adalah sebuah proposal yang memungkinkan kontrak untuk menjadi akun “tingkat atas”, seperti EOA, yang bisa membayar biaya dan memulai eksekusi transaksi.

Motivasi AA adalah untuk secara signifikan meningkatkan pengalaman pengguna dalam berinteraksi dengan blockchain Ethereum hari ini di berbagai skenario seperti dompet, pencampur, ÐAp, dan DeFi. AA menyediakan fungsionalitas lapisan dasar di Ethereum untuk menentukan kapan seseorang dapat membayar gas yang juga memiliki implikasi pada siapa yang membayar gas dan bagaimana mereka membayarnya.

Aplikasi Status Messenger menggabungkan messenger yang berfokus pada privasi bersama dengan dompet Ethereum dan browser Web3 ÐApp. Status wallet saat ini adalah dompet EOA yang membatasi kami dari menawarkan UX yang kaya yang hanya dapat ditawarkan oleh dompet smart contract seperti keamanan multi-tanda tangan, pemulihan sosial, pembatasan tingkat, daftar alamat yang diizinkan/ditolak, dan meta-transaksi tanpa gas. Namun, UX dari dompet smart contract saat ini sangat terhambat oleh fluktuasi harga gas yang tidak efisien dipecahkan oleh pihak ketiga pengirim ulang. AA bertujuan untuk mengatasi masalah ini.

Dalam artikel ini, kami memotivasi kebutuhan akan Abstraksi Akun dalam konteks dompet kontrak cerdas. Kami kemudian melakukan penyelaman mendalam ke aspek-aspek kunci AA dengan mendeskripsikan perubahan protokol dan dampak pada node. Terakhir, kami membahas beberapa perpanjangan yang diusulkan dan menyimpulkan dengan merasionalkan peta jalan yang direncanakan untuk proyek Status yang berinteraksi dengan Ethereum dan oleh karena itu bisa terpengaruh oleh AA.

Sejarah & Motivasi

Abstraksi Akun awalnya diusulkan sebagai EIP-86pada tahun 2017 untuk melaksanakan “Abstraksi asal transaksi dan tanda tangan” tetapi asal-usul ide yang mendorongnya bahkan sudah lebih jauh lagi ke belakangawal 2016, di mana disarankan bahwa: "Daripada memiliki mekanisme dalam protokol di mana ECDSA dan skema nonce default dijadikan sebagai satu-satunya cara "standar" untuk mengamankan sebuah akun, kami mengambil langkah awal menuju model di mana dalam jangka panjang semua akun adalah kontrak, kontrak dapat membayar gas, dan pengguna bebas menentukan model keamanan mereka sendiri."

Proposal awal dianggap sulit untuk diimplementasikan karena banyak perubahan protokol yang diperlukan dan jaminan keamanan yang harus dipenuhi. Baru-baru ini, Vitalik dkk. mengusulkan draf untuk EIP-2938yang menguraikan implementasi yang jauh lebih sederhana dengan menjaga perubahan protocol/konsensus minimal dan menegakkan jaminan keamanan yang diperlukan melalui aturan mempool node. Vitalik’sPresentasi Pertemuan Grup Teknik EthereumdanPresentasi ETHOnline (bersama dengan artikel yang menyertainya @SamWilsn/ryhxoGp4D">1 & @SamWilsn/S1UQDOzBv">2) oleh Sam Wilson & Ansgar Dietrichs (dua dari penulis EIP lainnya) menawarkan pengantar yang bagus tentang topik ini. Artikel ini menyoroti aspek-aspek kunci dari semua sumber ini.

Motivasi: Alasan mendasar di balik AA sangat sederhana namun fundamental: Transaksi Ethereum saat ini memiliki efek yang dapat diprogram (dicapai melalui panggilan ke kontrak pintar) tetapi memiliki validitas tetap dalam artian transaksi valid hanya jika memiliki tanda tangan ECDSA yang valid dengan nonce yang valid dan memiliki saldo akun yang cukup. AA meningkatkan transaksi dari validitas tetap menjadi validitas yang dapat diprogram dengan memperkenalkan tipe transaksi AA baru yang selalu berasal dari alamat khusus yang tidak memerlukan tanda tangan, nonce, atau pemeriksaan saldo oleh protokol. Validitas transaksi AA tersebut ditentukan oleh kontrak pintar target yang dapat menegakkan aturan validitasnya sendiri setelah itu dapat memutuskan untuk membayar transaksi tersebut.

Jadi, mengapa ini berguna? Mari kita ambil contoh dompet Ethereum untuk menyoroti manfaat dari AA.

Dompet Kontrak Pintar: Sebagian besar dompet Ethereum saat ini adalah dompet EOA yang dilindungi oleh kunci pribadi yang dihasilkan dari frasa biji. (A BIP-39frasa benih atau mnemonik adalah daftar berurutan dari 12-24 kata yang dipilih secara acak dari daftar 2048 kata. Ini memberikan entropi yang diperlukan untuk mendapatkan benih biner yang dihasilkan menggunakan fungsi PBKDF2. Benih biner kemudian digunakan untuk menghasilkan pasangan kunci asimetris untuk BIP-32 wallet.) Pengguna diharapkan mencatat frasa biji di tempat yang aman karena mungkin diperlukan nantinya untuk mengembalikan kunci di dompet lain. Namun, dompet seperti itu rentan terhadap pencurian kunci pribadi atau kehilangan frasa biji yang mengakibatkan kehilangan dana pengguna.

Dompet kontrak pintar diimplementasikan on-chain melalui kontrak pintar (sesuai namanya). Dompet seperti ini menawarkan mitigasi risiko yang dapat diprogram dan pengalaman yang ramah pengguna dengan mengimplementasikan fitur-fitur seperti keamanan multi-tanda tangan, pemulihan sosial atau berbasis waktu, pembatasan tingkat transaksi atau jumlah, daftar alamat yang diizinkan/ditolak, meta-transaksi tanpa gas, dan transaksi kelompok.

Sementara dompet kontrak pintar terpapar risiko keamanan dari kontrak pintar yang rentan, risiko ini dapat dikurangi melalui pengujian keamanan dan tinjauan yang dilakukan oleh penyedia dompet. Risiko dalam dompet EOA sepenuhnya terletak pada pengguna dompet yang dipercayakan dengan keamanan frasa benih tanpa perlindungan yang dapat diprogram yang mungkin dimiliki dengan kontrak pintar.

Contoh dari dompet kontrak pintar adalah Argent, Authereum, Dapper, Dharma, Gnosis Safe, MonolitdanMYKEYAdopsi dompet semacam itu tampaknya semakin meningkat seperti yang ditunjukkan oleh di bawah inigrafik.

Argent menerapkan pemulihan sosial tanpa benih dengan konsep mereka tentang Guardians yang merupakan orang atau perangkat tepercaya pengguna yang dapat membantu dalam memulihkan dompet pengguna. Argent juga bertujuan untuk memungkinkan keamanan mirip bank (melalui fitur seperti batas transaksi harian, penguncian akun, dan kontak tepercaya) dikombinasikan dengan kegunaan mirip Venmo (melalui penggunaan nama ENS alih-alih alamat dan dukungan untuk meta-transaksi).

Gnosis Safe adalah dompet kontrak pintar multi-tanda tangan yang berfokus pada manajemen tim dana yang memerlukan sejumlah minimum (m-of-n) anggota tim untuk menyetujui transaksi sebelum transaksi dapat terjadi. Ini juga memungkinkan tanda tangan tanpa gas melalui meta-transaksi.

Semua kemampuan dompet canggih seperti itu memerlukan penggunaan kontrak pintar yang tidak sepele. Pengguna dompet entah memerlukan EOA dengan gas untuk berinteraksi dengannya atau bergantung pada penyedia dompet untuk mendukung meta-transaksi melalui relayer penyedia atau jaringan relayer pihak ketiga seperti Jaringan Stasiun GasSementara yang pertama mengandalkan ETH yang biasanya dibeli di bursa terpusat setelah KYC, yang terakhir bertujuan untuk mengurangi gesekan UX onboarding ini dengan memindahkan beban pengguna ke relayers dengan biaya yang dikompensasi oleh penyedia dompet on-/off-chain dan/atau oleh pengguna off-chain.

Namun, arsitektur berbasis relayer memiliki tiga kelemahan utama: (1) Mereka mungkin dianggap sebagai perantara terpusat dengan potensi untuk menyensor transaksi (2) Mereka tidak efisien secara teknis/ekonomi karena memerlukan biaya gas dasar tambahan 21000 yang diperlukan untuk transaksi relayer dan kebutuhan bisnis mereka untuk mendapatkan keuntungan di atas biaya gas (3) Penggunaan protokol khusus relayer memaksa aplikasi bergantung pada infrastruktur Ethereum non-base-layer dengan basis pengguna yang lebih kecil dan jaminan ketersediaan yang tidak pasti.

Abstraksi Akun akan memungkinkan dompet kontrak pintar menerima meta-transaksi gasless pengguna dan membayar gas mereka tanpa bergantung pada jaringan pengantar. Kemampuan lapisan dasar ini akan secara signifikan meningkatkan UX onboarding dari dompet tersebut tanpa mengorbankan jaminan desentralisasi Ethereum.

Tornado Cash: Sebuah aplikasi yang berhubungan adalah pengaduk seperti tornado.cashdi mana@tornado.cash/memperkenalkan-transaksi-pribadi-di-ethereum-sekarang-42ee915babe0">Tornado meningkatkan privasi transaksi dengan memutuskan kaitan on-chain antara alamat menggunakan kontrak pintar yang menerima deposit ETH yang kemudian dapat ditarik oleh alamat yang berbeda. Pengguna diharapkan memberikan hash dari rahasia selama deposit dan kemudian memberikan bukti zkSnark selama penarikan untuk menunjukkan pengetahuan rahasia tanpa mengungkapkan rahasia atau deposit sebelumnya itu sendiri. Ini memutuskan tautan penarikan dari deposit.

Tapi ada masalah ayam dan telur dengan penarikan. Untuk mengeksekusi transaksi penarikan dari alamat yang baru dibuat, pengguna perlu memiliki sejumlah ETH di dalamnya untuk membayar gas. Sumber ETH ini (biasanya bursa) dapat melanggar privasi Tornado. Alternatif yang lebih disukai adalah menggunakan jaringan pengantar lagi yang memiliki kekurangan yang telah diuraikan sebelumnya.

Abstraksi Akun akan menyelesaikan masalah ini dengan memungkinkan kontrak Tornado menerima transaksi penarikan AA pengguna, memvalidasi zkSnark, mengurangi sejumlah biaya gas (dari jumlah deposit sebelumnya), dan kemudian mentransfer sisa jumlah deposit ke alamat penarikan.

Abstraksi Akun

Abstraksi Akun, seperti yang diusulkan dalam EIP-2938, memungkinkan kontrak menjadi akun tingkat atas yang membayar biaya dan memulai eksekusi transaksi. Hal ini dicapai dengan memperkenalkan perubahan protokol dengan jenis transaksi AA baru yang membutuhkan dua opcode baru: NONCE dan PAYGAS, perubahan aturan mempool dan ekstensi untuk mendukung penggunaan lanjutan. Jenis akun tetap dua (EOA dan Kontrak Akun) dan semua perubahan yang diusulkan kompatibel dengan transaksi, kontrak pintar, dan protokol saat ini.

Aplikasi AA dipertimbangkan dalam dua kategori: 1) Aplikasi satu penyewa seperti dompet kontrak pintar, yang membuat kontrak baru untuk setiap pengguna 2) Aplikasi multi-penyewa seperti tornado.cash atau Uniswap, di mana beberapa pengguna berinteraksi dengan kumpulan kontrak pintar yang sama.

Dukungan AA untuk aplikasi multi-penyewa memerlukan penelitian lebih lanjut dan diusulkan sebagai pekerjaan masa depan. Jadi, kami akan fokus pada dukungan AA untuk penyewa tunggal dalam artikel ini.

Perubahan Protokol

Ada tipe transaksi baru yang diperkenalkan bersama dengan dua opcode pendukung NONCE dan PAYGAS. Ini adalah satu-satunya perubahan protokol.

Transaksi AA: Sebuah jenis transaksi AA baru AA_TX_TYPE diperkenalkan. Payloadnya diinterpretasikan sebagai RLP([nonce, target, data]) daripada jenis transaksi yang sudah ada yang payloadnya adalah RLP([nonce, gas_price, gas_limit, to, value, data, v, r, s]).

Harga_gas dan batas_gas yang diabaikan dalam transaksi AA ditentukan oleh kontrak AA target selama eksekusi. Tanda tangan ECDSA v, r, s yang diabaikan dalam transaksi AA digantikan oleh pemeriksaan verifikasi khusus kontrak pada data. Alamat tujuan digantikan oleh alamat kontrak target. Nilainya diabaikan karena alamat asal untuk semua transaksi AA adalah alamat ENTRY_POINT khusus (0xFFFF…FFFF) dan bukan EOA yang memiliki nilai yang terkait dengannya.

Nonce diproses secara analog dengan transaksi yang ada dengan memeriksa apakah tx.nonce == tx.target.nonce. jika pemeriksaan ini gagal maka transaksi dianggap tidak valid tetapi jika tidak, tx.target.nonce ditambahkan dan transaksi dilanjutkan.

Biaya dasar gas dari transaksi AA diusulkan menjadi 15000 daripada 21000 saat ini (untuk mencerminkan penghematan biaya dari kurangnya tanda tangan ECDSA intrinsik). Selain itu, transaksi AA tidak memiliki batasan gas intrinsik. Ketika memulai eksekusi, batas gas hanya diatur menjadi gas yang tersisa di blok.

Opcodes NONCE: Opcode NONCE (0x48) mendorong nonce dari penerima, yaitu kontrak target AA, ke tumpukan EVM. Nonce dengan demikian terpapar ke EVM untuk memungkinkan verifikasi tanda tangan dilakukan atas semua bidang transaksi (termasuk nonce) sebagai bagian dari validasi dalam kontrak AA.

Opcode PAYGAS: Opcode PAYGAS (0x49) mengambil dua argumen dari tumpukan: (paling atas) nomor_versi, (kedua dari atas) memory_start. Nomor_versi memungkinkan implementasi di masa depan untuk mengubah semantik opcode. Saat ini, opcode memiliki semantik di bawah ini:

1. Periksa version_number == 0 (jika tidak lemparkan pengecualian)
2. Baca gas_price = bytes_to_int(vm.memory[memory_start: memory_start + 32])
3. Baca gas_limit = bytes_to_int(vm.memory[memory_start + 32: memory_start + 64])
4. Periksa kontrak. saldo >= gas_price * gas_limit (jika tidak, lempar pengecualian)
5. Periksa globals.transaction_fee_paid == False (jika tidak, lemparkan pengecualian)
6. Periksa bingkai eksekusi AA == bingkai tingkat atas, yaitu jika eksekusi EVM saat ini keluar atau melempar, eksekusi EVM dari seluruh transaksi dihentikan (selain itu lemparkan pengecualian)
7. Set kontrak.balance -= gas_price * gas_limit
8. Atur globals.transaction_fee_paid = Benar
9. Set globals.gas_price = gas_price dan globals.gas_limit = gas_limit
10. Atur sisa_gas dari konteks eksekusi saat ini = batas_gas - gas yang sudah dikonsumsi

Pada akhir eksekusi transaksi AA, (globals.gas_limit - remaining_gas)globals.gas_price ditransfer ke penambang dan kontrak AA akan dikembalikan remaining_gasglobals.gas_price.

PAYGAS berfungsi sebagai titik kontrol eksekusi EVM. Semua pembatalan setelah titik ini hanya akan dibatalkan sampai di sini dan kemudian kontrak tidak menerima pengembalian dana dan globals.gas_limit * globals.gas_price ditransfer ke penambang.

Jenis transaksi baru dan dua opcode baru membentuk perubahan tingkat protokol/konsensus dan semantiknya relatif mudah dipahami.

Aturan Mempool

"The mempoolmerujuk pada kumpulan struktur data dalam memori di dalam sebuah node Ethereum yang menyimpan transaksi kandidat sebelum ditambang. Geth menyebutnya sebagai “kolam transaksi”; Parity menyebutnya sebagai “antrian transaksi.” Terlepas dari nama tersebut, itu adalah kumpulan transaksi yang berada di memori menunggu untuk dimasukkan ke dalam blok. Pikirkanlah itu sebagai “area tunggu” untuk transaksi diterima ke dalam blok.

Saat ini, dengan aturan validitas transaksi yang tetap, penambang dan node lain memerlukan usaha minimal untuk memvalidasi transaksi di mempool mereka dan dengan demikian menghindari serangan DoS. Misalnya, seorang penambang dapat yakin bahwa suatu transaksi akan benar-benar membayar biaya jika memiliki tanda tangan ECDSA yang valid, nonce yang valid, dan saldo akun yang cukup. Transaksi lain di mempool penambang tersebut hanya akan membatalkan transaksi tertunda ini jika berasal dari alamat yang sama, dan entah menaikkan nonce atau cukup mengurangi saldo akun. Kondisi-kondisi ini secara minimal secara komputasi memberikan kepercayaan yang cukup kepada penambang dan node dalam mempool mereka untuk pertimbangan blok atau penyiaran ulang masing-masing.

Transaksi AA memperkenalkan kompleksitas lebih dengan validitas yang dapat diprogram. Transaksi AA tidak membayar gas di muka dan mengandalkan kontrak AA target mereka untuk membayar gas (melalui PAYGAS). Secara konseptual, pemrosesan transaksi AA terbagi menjadi dua fase: fase verifikasi yang lebih pendek (sebelum PAYGAS) dan fase eksekusi yang lebih lama (setelah PAYGAS). Jika fase verifikasi gagal (atau melempar pengecualian), transaksi tersebut tidak valid (seperti transaksi non-AA dengan tanda tangan tidak valid saat ini), tidak dimasukkan dalam blok, dan penambang tidak mendapatkan biaya.

Para penambang dan node oleh karena itu memerlukan mekanisme yang dapat diprediksi untuk menghindari ketergantungan validitas transaksi AA tertunda pada transaksi tertunda lainnya di mempool. Jika tidak, eksekusi satu transaksi dapat membatalkan banyak/semua transaksi AA di mempool yang mengarah ke serangan DoS. Untuk menghindari skenario ini, ada dua aturan yang diusulkan untuk ditegakkan (oleh penambang dan node tetapi tidak dalam protokol itu sendiri) pada transaksi AA di mempool:

Pembatasan Opcode

Untuk mencegah validitas transaksi AA bergantung pada keadaan eksternal dari kontrak AA itu sendiri, opcode berikut dianggap tidak valid dalam fase verifikasi (yaitu sebelum PAYGAS): opcode lingkungan (BLOCKHASH, COINBASE, TIMESTAMP, NUMBER, DIFFICULTY, GASLIMIT), BALANCE (dari akun manapun, termasuk target itu sendiri), panggilan/pebuat eksternal ke selain target atau prekompilasi (CALL, CALLCODE, STATICCALL, CREATE, CREATE2) dan akses keadaan eksternal yang membaca kode (EXTCODESIZE, EXTCODEHASH, EXTCODECOPY, DELEGATECALL) kecuali alamatnya adalah target.

Node diharapkan akan menolak transaksi AA di mempool yang ditujukan ke kontrak AA yang melanggar aturan pembatasan opcode ini. Hal ini memastikan bahwa transaksi AA yang valid di mempool akan tetap valid selama status kontrak AA tidak berubah.

Pembatasan Awalan Bytecode

Jika transaksi non-AA dapat memengaruhi status kontrak AA maka hal ini akan memengaruhi validitas transaksi AA di mempool. Untuk mencegah hal ini, transaksi AA harus hanya diperbolehkan untuk menargetkan kontrak yang memiliki AA_PREFIX di awal bytecode mereka, di mana AA_PREFIX mengimplementasikan pemeriksaan bahwa msg.sender adalah alamat ENTRY_POINT khusus dari transaksi AA. Hal ini efektif mencegah transaksi non-AA dari berinteraksi dengan kontrak AA.

Node diharapkan untuk menolak transaksi AA ke kontrak AA yang tidak memiliki AA_PREFIX ini di titik masuk bytecode mereka.

Dua pembatasan ini yang diberlakukan pada kontrak AA bersama-sama memastikan bahwa: (1) satu-satunya status yang dapat diakses oleh logika keabsahan transaksi AA adalah status internal dari kontrak AA dan (2) status ini hanya dapat dimodifikasi oleh transaksi AA lain yang menargetkan kontrak AA tertentu ini.

Transaksi AA tertunda ke kontrak AA mungkin hanya dibatalkan oleh blok yang berisi transaksi AA lain yang dituju ke kontrak AA yang sama. Namun, mengingat bahwa ini bukan perubahan protokol/konsensus, para penambang bebas untuk menyertakan transaksi dalam blok yang melanggar aturan-aturan ini.

Ekstensi

Perubahan protokol di atas dan aturan mempool memungkinkan kontrak AA dasar untuk mengimplementasikan aplikasi satu penyewa seperti dompet kontrak cerdas dengan cukup dan aman. Penggunaan lanjutan lainnya yang memerlukan relaksasi aturan di atas atau perlu mengimplementasikan aplikasi multi-penyewa memerlukan lebih banyak dukungan dari AA dalam bentuk ekstensi seperti:

1. Opcode SET_INDESTRUCTIBLE, yang menonaktifkan SELFDESTRUCT dan memungkinkan kontrak AA untuk memanggil pustaka dengan DELEGATECALL secara aman dalam fase verifikasi.
2. Opcode IS_STATIC, yang mengembalikan nilai benar jika konteks saat ini bersifat statis dan memungkinkan pemanggil transaksi non-AA untuk mengesampingkan pembatasan awal bytecode sebelumnya dan membaca nilai dari kontrak AA dengan aman.
3. opcode RESERVE_GAS, yang menetapkan batas bawah pada gas yang dikonsumsi oleh kontrak AA ketika dipanggil dari transaksi non-AA yang berusaha menulis keadaan kontrak. Ini bertujuan untuk mencegah penyerang menghabiskan jumlah gas minimum untuk mencegah percobaan membatalkan transaksi AA apa pun di mempool.

Ada yang lain seperti transaksi tertunda ganda, hasil caching dari validasi, batas gas dinamis untuk validasi, dan transaksi yang disponsori yang diperlukan untuk mendukung aplikasi multi-penyewa dan bukti zk misalnya Tornado Cash. Diskusi mereka di luar cakupan artikel ini.

Langkah Selanjutnya

Account Abstraction EIP-2938 saat ini dalam mode draf dan sedang dibahas di forum penelitian Ethereum. Langkah selanjutnya untuk EIP ini adalah dipertimbangkan untuk dimasukkan dalam salah satu hard fork mendatang. Para penulis EIP nampaknya bertujuan untuk hard fork setelah Berlin (Berlin direncanakan untuk suatu saat di masa depan)awal 2021) yang jadwalnya saat ini belum terlalu jelas. Jadi masih terlalu awal dalam proses untuk EIP-2938.

Selain itu, juga tidak jelas apakah akan perlu menyertakan EIP-2938 di Ethereum base Layer 1 (L1). Mengingat fleksibilitas relatif dari solusi Layer 2 (L2) (seperti yang dijelaskan dalam artikel kami sebelumnya artikel) Account Abstraction dapat diterapkan pada L2 tertentu tanpa memerlukan peningkatan seluruh L1. Namun, ada manfaat dari dukungan AA yang seragam pada L1 meskipun beberapa L2 menerapkan versi AA mereka sendiri. Oleh karena itu, masih harus dilihat di mana dan bagaimana AA diimplementasikan.

"Abstraksi akun agak kurang penting, karena dapat diimplementasikan pada L2 terlepas dari apakah L1 mendukungnya atau tidak." — Vitalik tentang hal-hal yang akan terus penting di lapisan dasar (dalampostingpada peta jalan Ethereum yang berpusat pada rollup).

Status: Dompet Status saat ini adalah dompet EOA yang membedakan dirinya dengan pengelompokan pesan berorientasi privasi dan memungkinkan integrasi seperti pembayaran dalam obrolan atau keamanan yang ditingkatkan dengan Kartu KunciFitur dompet kontrak pintar seperti multisig dan pemulihan sosial sedang dipertimbangkan di mana dukungan EIP-2938 AA akan membantu dengan menghapus ketergantungan pada arsitektur berbasis relayer terpusat dan tidak efisien, seperti yang dijelaskan sebelumnya.

Status juga sedang mengevaluasi solusi L2 baik untuk mendukung berbagai rantai dalam dompetnya maupun untuk menyediakan penskalaan yang diperlukan untuk berbagai kasus penggunaan sebagaimana yang dijelaskan dalam sebelumnyaartikel. Misalnya, Keycard sedang menjelajahi sebuah jaringan pembayaranyang persyaratan desainnya terkait skalabilitas tingkat kartu kredit dan finalitas hampir instan tidak terpenuhi oleh jaringan Ethereum saat ini. Selain itu, ada banyak inisiatif lain seperti itu Program Referral, reaksi SNT, Tribute-to-Talkdannama ENS, semua di antaranya akan mendapatkan manfaat dari skalabilitas L2 untuk implementasi yang layak dan pengalaman pengguna yang wajar. Jika solusi L2 yang layak menerapkan AA maka proyek-proyek yang membangun di L2 tersebut akan dapat memanfaatkan manfaat AA tanpa harus bergantung pada L1.

Ringkasan

Aspek mendasar dari protokol Ethereum adalah bahwa hanya Akun yang Dimiliki Secara Eksternal (EOA) yang dapat membayar biaya gas dan memulai eksekusi transaksi. Akun Kontrak (CAs) tidak dapat melakukannya. Abstraksi Akun (AA) adalah proposal yang bertujuan untuk mengubah perbedaan ini dan memungkinkan CAs yang dibangun secara khusus untuk memeriksa validitas transaksi AA tipe baru secara programatik, memutuskan untuk membayar biaya gas atas nama mereka dan dengan demikian secara efektif memulai eksekusi mereka tanpa persyaratan EOA.

AA memiliki implikasi untuk secara signifikan meningkatkan pengalaman pengguna di berbagai skenario seperti dompet, mixer, ÐApps, dan DeFi tanpa bergantung pada arsitektur berbasis relay sentral dan tidak efisien. Skenario single-tenant dasar, seperti dompet kontrak pintar, dapat didukung dengan aman oleh AA dengan pengenalan tipe transaksi baru, dua opcode baru, dan dua aturan mempool baru. Aplikasi multi-tenant tingkat lanjut, seperti Tornado Cash, memerlukan ekstensi terhadap perubahan protokol ini dan aturan node.

Dalam artikel ini, kami memotivasi kebutuhan akan AA dalam konteks dompet kontrak cerdas. Kami menyoroti aspek kunci dari AA dengan mendeskripsikan perubahan protokol dan dampaknya pada node. Kami menyentuh beberapa perpanjangan yang diusulkan untuk penggunaan lanjutan dan akhirnya menyimpulkan dengan memposisikan AA dalam konteks peta jalan saat ini dari Ethereum dan prioritas di Status.

Mengurangi gesekan dan meningkatkan pengalaman pengguna di Web3 adalah prioritas utama untuk semua proyek dalam ekosistem ini. Abstraksi Akun, dalam beberapa bentuk, mungkin benar-benar memainkan peran penting dalam upaya ini ke depan.

Penafian:

1. Artikel ini dicetak ulang dari [status], meneruskan judul asli'Abstraksi Akun (EIP-2938): Mengapa & Apa', Semua hak cipta adalah milik penulis asli [Rajeev Gopalakrishna]. Jika ada keberatan terhadap cetak ulang ini, harap hubungi Gate Belajartim, dan mereka akan menanganinya dengan cepat.

2. Penafian Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan nasihat 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.