Abstraksi akun bertujuan untuk meningkatkan pengalaman pengguna dan pengembang di seluruh ekosistem Ethereum. Selain membuat pengalaman on-chain lebih mudah diakses dan menyenangkan bagi pengguna, ini juga memberdayakan pengembang untuk dapat melakukan hal-hal yang lebih kuat di Ethereum dan melayani pengguna dengan cara yang lebih bermakna.

Klasifikasi kami terhadap pendekatan abstraksi akun adalah sebagai berikut:

1. Peningkatan/programabilitas EOA: Ini termasuk perubahan tingkat protokol yang memungkinkan EOA (Akun Dimiliki Secara Eksternal) untuk mendefinisikan bagian logika eksekusi dari aturan validitas mereka. Seperti yang diketahui dalam komunitas pengembangan, EOA adalah akun yang biasanya terkait dengan pengguna akhir. Oleh karena itu, solusi yang termasuk dalam pendekatan ini akan memberdayakan akun pengguna akhir dengan lebih banyak kontrol atas jenis tindakan apa yang dapat mereka otorisasi, dibandingkan dengan bagaimana hal ini dapat dikelola saat ini.
2. Konversi / migrasi EOA: Pendekatan ini mencakup proposal yang mencari konversi lengkap EOA ke CA (akun kontrak). Ide integral dari pendekatan ini adalah bahwa akun kontrak sudah menawarkan sebagian besar manfaat yang ditawarkan oleh akun pintar, jadi seharusnya tidak perlu memperumit masalah lagi; Setiap orang hanya harus menggunakan akun kontrak sebagai akun utama mereka (melalui dompet kontrak pintar).

Pendekatan ini memiliki mekanisme yang memungkinkan EOA untuk beralih ke CA tanpa harus memindahkan asetnya, seperti EIP 7377danEIP 5003(ketika dipertimbangkan bersama EIP 3074).

1. Smart Account: Kelompok proposal ini mencakup desain yang memungkinkan EOAs dan CAs berperilaku sebagai "smart account" dengan memungkinkan mereka untuk sepenuhnya mendefinisikan aturan validitas mereka.

Berbagai proposal sebelumnya telah diajukan untuk pembuatan akun pintar dan pengabdian abstraksi akun pada tingkat protokol;EIP-86danEIP-2938beberapa yang lebih sering dikutip. Namun, ada banyak penolakan karena kompleksitas yang dirasakan yang diperkenalkan oleh desain ini dan pendapat mayoritas yang agak bahwa Ethereum belum siap untuk kompleksitas seperti itu.

Setelah Vitalik menghidupkan kembali topik tersebut setelah The Merge,ERC-4337Diusulkan sebagai versi opt-in dari standar akun pintar, mirip dengan infrastruktur PBS (Proposer-Builder Separation) untuk MEV (Maximal Extractable Value). Dengan demikian, pengguna yang ingin mengakses manfaat akun pintar dapat menggunakan pipeline ERC-4337 untuk mendefinisikan ulang logika akun mereka dan aturan validitas transaksi dalam struktur yang disebut sebagai UserOperation (atau UserOps singkat).

ERC 4337 membawa manfaat akun pintar ke Ethereum saat ini tanpa mengabadikan kompleksitas apa pun, dengan berfungsi sebagai alternatif di luar protokol untuk akun pintar yang diabadikan. Namun, ini tidak berarti bahwa infrastruktur ini optimal dalam keadaan saat ini karena kompleksitasnya sendiri masih menjadi titik kegagalan yang signifikan.

Untuk mengatasi kompleksitas ini, RIP 7560diciptakan sebagai versi yang diabadikan dari infrastruktur ERC 4337 di Ethereum dan L2-nya, sehingga mewarisi skema ketahanan sybil jaringan daripada harus menentukan suite aturan baru (seperti yang dilakukan ERC 4337 denganERC 7562).

Dalam laporan ini, kami akan berfokus pada eksplorasi programmability EOA, mengevaluasi berbagai EIP yang menggambarkan solusi sepanjang garis ini dan membahas kelebihan dan kekurangannya. Di Bagian 2 dan 3 dari seri ini, kami akan membahas dua kelas pendekatan yang tersisa untuk abstraksi akun yang sedang dieksplorasi dalam Ethereum.

Sebuah Pengantar tentang Akun dan Transaksi Ethereum

Untuk mencari tahu apa yang dapat diabstraksi, kita perlu gambaran yang cukup lengkap tentang desain akun saat ini. Bagian ini akan sebagian besar berfungsi sebagai revisi tentang apa sebenarnya akun di Ethereum, dan bagaimana transaksi mereka divalidasi dan dieksekusi.

Akun Ethereum adalah entitas dengan saldo eter (ETH) dan kemampuan untuk mengirim transaksi pada blockchain Ethereum. Mereka direpresentasikan sebagai "alamat" heksadesimal 42 karakter, yang berfungsi sebagai penunjuk unik untuk kepemilikan dan transaksi akun.

Sebuah alamat berperan sebagai kunci ke dalam trie keadaan blockchain. Node daun dari trie ini adalah struktur data akun yang dapat diuraikan menjadi empat bidang:

1. nonce: Sebuah penghitung linear yang digunakan untuk menunjukkan jumlah transaksi keluar yang diinisiasi oleh sebuah akun. Ini juga penting dalam mencegah serangan ulang.
2. saldo: Jumlah ether (ETH) yang dimiliki oleh sebuah akun, dihitung dalam wei.
3. codeHash: Hash dari kode yang dapat dieksekusi EVM yang terdapat dalam akun. EVM (Ethereum Virtual Machine) adalah lingkungan eksekusi Ethereum yang dipesan lebih dahulu yang bertanggung jawab untuk menangani transisi keadaan kompleks di luar transaksi "kirim" sederhana. Isi kode akun diprogram secara permanen untuk melakukan bentuk transisi status tertentu pada blockchain Ethereum, melalui EVM.
4. storageHash: Sebuah hash dari root penyimpanan akun, digunakan untuk merepresentasikan isi penyimpanan akun sebagai hash 256-bit dari node root merkle patricia trie. Secara sederhana, ini adalah hash dari data variabel-keadaan yang terkait dengan konten kode akun.

Isi dari empat bidang ini digunakan untuk mendefinisikan jenis akun, dan pada akhirnya mendefinisikan sejauh mana fungsionalitasnya. Oleh karena itu, dua jenis akun Ethereum adalah:

1. Akun Pemilik Eksternal (EOA) - yang diinisialisasi sebagai sepasang kunci kriptografi:

• Sebuah kunci pribadi yang dapat dienkripsi dan terbukti acak dengan 64 karakter heksadesimal, dan pasangannya yang saling melengkapi;
• Sebuah kunci publik yang berasal dari kunci pribadi menggunakan ECDSA (Elliptic Curve Digital Signature Algorithm).

EOA memiliki bidang codeHash dan storageHash yang kosong dan hanya dapat dikendalikan oleh siapa pun yang memiliki kunci pribadi. Alamat mereka dapat diperoleh dari kunci publik yang sesuai dengan menambahkan awalan "0x" pada dua puluh karakter terakhir dari hash keccak-256 kunci publik akun tersebut.

1. Akun Kontrak (CAs) - yang hanya dapat dibuat oleh EOA yang sudah ada. Mereka diinisialisasi karena EOA menerapkan konten kode yang dapat dieksekusi pada EVM. Konten kode ini (disimpan sebagai codeHash) diabadikan dalam EVM, dan bertanggung jawab atas pengendalian akun dengan menentukan logika dan interaksinya.

Transaksi mereka sepenuhnya didasarkan pada tarikan dan didasarkan pada logika kode yang diterapkan.

Karena akun-akun ini hanya dapat dikendalikan oleh konten kode mereka, mereka tidak memerlukan kunci pribadi dan hanya memiliki kunci publik. Oleh karena itu, setiap agen yang memiliki kemampuan untuk memperbarui/mengubah konten kode akun kontrak akan dapat mengakses saldonya.

Alamat CA berasal dari alamat penciptanya dan nonce-nya sampai pada titik implementasi kontrak.

Transaksi

Kami baru-baru ini menggambarkan akun sebagai entitas yang memiliki kemampuan untuk mengirim transaksi di Ethereum. Oleh karena itu, kita dapat memahami bahwa tujuan utama dari sebuah akun adalah untuk mengirim dan menerima transaksi, sementara blockchain bertindak sebagai buku besar yang mencatat sejarah transaksi serta menjelaskan bagaimana transaksi mengubah bidang akun berdasarkan aturan yang dijelaskan dalam spesifikasi protokol blockchain.

Jadi apa itu "transaksi" ini?

Transaksi adalah operasi yang dikirim dari akun, yang menyebabkan perubahan dalam 'keadaan' jaringan. Mereka adalah instruksi yang ditandatangani secara kriptografis dari akun, yang menghasilkan pembaruan keadaan di seluruh jaringan ketika dieksekusi.

Kehendak tanpa izin datang dengan biaya insentif yang menyimpang, untuk menangani ini, pedoman yang ketat (atau aturan validitas) harus ditetapkan untuk interaksi di lingkungan tersebut.

Dalam konteks ini, transaksi harus mengikuti aturan validitas tertentu untuk dianggap sah dan dieksekusi. Sebagian besar aturan validitas ini diimplementasikan melalui kendala yang ditempatkan pada akun yang mengirim transaksi, dan bervariasi berdasarkan jenis akunnya.

Akun dan Validitas Transaksi

Di Ethereum, EOAs dioptimalkan untuk kegunaan karena mereka menghadap pengguna akhir. Mereka memiliki kemampuan untuk mengirim transaksi dengan cara tertentu dan beroperasi secara mandiri dengan sempurna. Mereka juga dapat dibuat secara lokal, metode yang lebih umum adalah penggunaan penyedia dompet seperti MetaMask, Rainbow, Rabby, dll.

Di sisi lain, akun kontrak hanya dapat mengirim transaksi yang diizinkan oleh logika mereka, sebagai tanggapan atas "dipanggil". Juga, mereka hanya dapat dibuat oleh EOA yang memiliki saldo yang cukup untuk membayar penyimpanan negaranya.

Deskripsi yang lebih tinggi tingkatnya adalah bahwa EOAs hanya dapat memiliki saldo, sementara CAs dapat memiliki saldo dan logika yang menentukan bagaimana saldo ini dapat digunakan.

Properti-properti ini disebabkan oleh parameter-parameter logika berikut yang menentukan aturan transaksi akun harus mematuhi:

1. Logika autentikasi - Digunakan untuk mendefinisikan bagaimana sebuah akun membuktikan identitasnya kepada jaringan saat mengubah saldo dan/atau logika.
2. Logika otorisasi - Digunakan untuk mendefinisikan kebijakan akses akun, yaitu, siapa yang dapat mengakses dan melakukan perubahan terhadap saldo dan/atau logika akun.
3. Logika nonce - yang menentukan urutan di mana transaksi dari sebuah akun akan dieksekusi.
4. Logika pembayaran gas - Digunakan untuk menentukan pihak yang bertanggung jawab untuk menyelesaikan biaya gas transaksi.
5. Logika eksekusi - Digunakan untuk mendefinisikan bentuk transaksi apa yang dapat dikirimkan oleh akun, atau bagaimana sebuah transaksi akan dieksekusi.

Parameter-parameter ini dirancang agar kaku untuk EOAs seperti itu:

• Autentikasi dan otorisasi disediakan oleh kunci privat berbasis ECDSA, yaitu, pengguna yang ingin mengirim transaksi dari EOA mereka harus menggunakan kunci privat mereka untuk mengakses akun dan dengan demikian membuktikan bahwa mereka memiliki hak untuk melakukan perubahan apapun terhadap saldo akun tersebut.
• Logika nonce mengimplementasikan skema penghitung berurutan, yang memungkinkan hanya satu transaksi per nonce unik yang dieksekusi secara berurutan per akun.
• Logika pembayaran gas menentukan bahwa biaya gas untuk transaksi harus diselesaikan oleh pengirim/akun asal.
• Logika eksekusi menentukan bahwa EOAs hanya dapat mengirimkan bentuk transaksi berikut:

1. Transfer reguler antara dua EOAs.
2. Penyebaran kontrak.
3. panggilan kontrak yang menargetkan logika akun kontrak yang sudah dideploy

Secara umum, logika eksekusi EOAs membatasi mereka hanya dapat melakukan satu transaksi per tanda tangan yang valid.

Di sisi lain, CA memiliki lebih fleksibilitas seputar parameter-parameter ini:

• Autentikasi tidak diperlukan, karena transaksi mereka bersifat konsekuensial/tarik berbasis alam.
• Otorisasi untuk CA dapat dilakukan dalam dua bentuk:

1. Kemampuan untuk "memanggil" kode konten CA (atau menjalankan kontrak pintar-nya), yang bergantung pada logika kontrak pintar akun dan invarian-nya.
2. Kemampuan untuk melakukan perubahan pada kode konten CA, yang sebagian besar tergantung pada apakah kode konten tersebut dapat ditingkatkan atau tidak.

Dalam kebanyakan kasus praktis, logika yang digunakan dalam hal ini adalah skema tanda tangan multi yang menentukan bahwa diperlukan M dari N tanda tangan yang valid (di mana M < N) dari akun-akun tertentu (biasanya EOAs) agar perubahan logika CA menjadi valid.

• Pengurutan transaksi mereka longgar berdasarkan nonce. CA itu sendiri dapat mengirimkan sebanyak mungkin transaksi ke sebanyak mungkin penelepon yang berbeda, namun setiap penelepon dibatasi berdasarkan kemampuan mereka sendiri.
• Pembayaran gas biasanya ditangani oleh pemanggil logika CA.
• Logika eksekusi CA lebih beragam untuk memungkinkan peningkatan UX seperti transaksi multicall dan transaksi atom.

Mengevaluasi fitur-fitur ini, kami memperhatikan bahwa setiap jenis akun dirancang untuk memiliki kompromi antara otonomi dan programmability.

EOA memiliki otonomi penuh tetapi pemrograman terbatas; mereka dapat memberikan izin dan mengirimkan transaksi kapan pun mereka mau, tetapi transaksi ini harus mengikuti format yang kaku agar dianggap valid. CA memiliki pemrograman penuh (terbatas hanya oleh desain EVM) tetapi otonomi terbatas; transaksi mereka tidak perlu mengikuti format yang kaku, tetapi hanya dapat dikirimkan karena logika mereka dipanggil terlebih dahulu.

Dalam subbagian berikut ini, kami akan sekarang mempelajari implikasi dari pilihan desain ini, agar dapat sepenuhnya memahami proposisi dari setiap EIP yang dibahas dalam seri ini.

Dilema akun Ethereum

Sekarang setelah kita memiliki pengetahuan yang cukup ringkas tentang fungsi akun yang berbeda, kita dapat dengan mudah mengidentifikasi poin penjualan mereka serta masalah yang mereka hadapi baik bagi pengguna maupun pengembang dalam pengalaman menggunakan Ethereum.

Seperti yang telah kami sebutkan sebelumnya, EOAs dirancang sebagai akun kelas satu yang ditujukan untuk pengguna akhir. Aplikasi dirancang untuk berinteraksi dengan mudah dengan mereka, hampir tidak ada kompleksitas untuk mereka, dan tentu saja tidak ada biaya untuk membuat satu. Namun, kesederhanaannya datang dengan kehilangan novelty yang signifikan karena mereka dirancang untuk menjadi secara ketat deterministik.

Beberapa kekhawatiran seputar mereka adalah:

1. Kerentanan terhadap serangan kuantum - Skema tanda tangan ECDSA yang digunakan oleh pasangan kunci mereka tidak tahan kuantum, dan dengan jangka waktu optimis 5 hingga 10 tahun untuk mencapai sistem kuantum industri, ini merupakan ancaman besar bagi Ethereum dan aplikasinya yang sangat mengandalkan skema ECDSA untuk bukti kriptografi dan keamanan.
2. Kurangnya ekspresi - Format yang kaku dari aturan validitas EOAs menghilangkan kemampuan pengguna untuk mengungkapkan transaksi mereka secara lebih ringkas melalui fitur seperti atomisitas transaksi dan pengelompokan, dan delegasi transaksi.
3. Keberlanjutan mandiri - Setiap orang pernah mengalami momen 'saya kehabisan bensin' di tengah transaksi. Hal ini disebabkan oleh persyaratan bahwa EOAs menyelesaikan biaya gas untuk transaksi mereka sendiri, yang tidak akan menjadi masalah jika ether (ETH) bukan satu-satunya mata uang gas yang diterima. Meskipun ini adalah masalah umum dengan mesin keadaan berbasis akun (dan bahkan yang berbasis UTXO), Ethereum selalu bermaksud untuk menjadi berbeda.

Tidak semua orang ingin (atau akan mampu) selalu memegang ETH (maksud saya lihat aksi harga itu), jadi solusi yang layak adalah membiarkan beberapa mata uang gas (terlalu keras, memecah terlalu banyak invarian seperti yang dijelaskan di bagian "Mata Uang" di siniatau untuk memungkinkan pembayaran gas diselesaikan oleh akun lain yang bukan asal transaksi.

Di ujung spektrum akun lainnya, CA menargetkan pengembang dan basis pengguna yang lebih teknis. Mereka berfungsi sebagai kendaraan untuk kontrak pintar (yaitu kita mempertimbangkan kontrak pintar untuk menjadi logika atau konten kode mereka) dan dapat mengimplementasikan format transaksi baru sebagaimana yang diizinkan oleh EVM.

Namun, untuk semua fitur ini, mereka adalah akun kelas dua yang dianggap istimewa karena mereka tidak memiliki otonomi. Beberapa kekurangan mereka adalah sebagai berikut:

1. Total kurangnya otonomi – CA tidak dapat memulai transaksi, mereka hanya dapat mengirimkan transaksi sebagai tanggapan atas dipanggil dengan cara yang sangat khusus.
2. Kerentanan terhadap kesalahan manusia dalam logika mereka - Kurangnya ketegasan seringkali menyebabkan definisi invarian yang salah dan logika lainnya, yang telah menyebabkan kerugian miliaran dolar akibat eksploitasi dan peretasan kontrak pintar. Namun, ini hampir sepenuhnya topik yang berbeda yang berada di luar cakupan kita di sini.

Setelah meninjau pilihan desain yang menyebabkan masalah yang ditentukan dalam subbagian ini, kami sekarang dapat melanjutkan untuk mengevaluasi solusi yang diusulkan.

Sejarah abstraksi akun

Konsep abstraksi akun (melalui akun pintar setidaknya) selalu menjadi bagian integral dari peta jalan Ethereum. Mitosnya adalah kompleksitas yang mengelilingi implementasinya mengancam untuk lebih memperlambat peluncuran Ethereum, sehingga itu dibatalkan untuk desain saat ini dengan akun yang berbeda menawarkan fungsionalitas yang berbeda. Ini ditunda lagi oleh fokus Ethereum pada The Merge, dan sekarang muncul kembali sebagai bagian utama dari upgrade besar berikutnya jaringan - Pectra. Namun, kompleksitasnya masih dianggap sebagai hambatan signifikan yang mencegah pengesahan, terutama karena Ethereum telah beralih ke peta jalan yang berpusat pada rollup.

Persyaratan sekarang menjadi dua kali lipat:

1. Standar akun harus lebih ekspresif, namun tanpa kehilangan otonomi. Standar baru yang menyatukan perbedaan antara standar EOA dan CA.
2. Standar baru harus menjembatani kesenjangan antara EOAs dan CAs, sambil tetap sepenuhnya kompatibel di seluruh Ethereum dan ekosistem L2-nya.

Secara intuitif, konsep ini memainkan peran yang lebih besar dalam konteks abstraksi rantai dan interoperabilitas, namun cakupan kami dalam laporan ini terbatas pada inisiatif teknis yang diambil untuk mencapai abstraksi akun itu sendiri.

Abstraksi akun bertujuan untuk menggabungkan fitur terbaik dari EOAs dan CAs ke dalam standar akun baru – akun pintar, yang memungkinkan pemisahan penuh atau parsial dari aturan validitas akun manapun menjadi logika validasi dan logika eksekusi; sehingga akun dapat mendefinisikan aturan validitas mereka sendiri –seperti yang diizinkan oleh EVM– sama seperti akun kontrak, sambil tetap sepenuhnya otonom seperti akun milik eksternal.

Seringkali terjadi kebingungan seputar perbedaan antara akun pintar dan dompet kontrak pintar, jadi mari kita secara eksplisit mendeskripsikan perbedaan-perbedaan tersebut di bawah ini:

• Akun pintar adalah akun Ethereum yang dikonseptualisasikan untuk memberikan bagian yang sama dari pemrograman dan otonomi. Ide tersebut adalah bahwa baik EOAs maupun CAs dapat menjadi akun pintar dengan mudah dengan memanfaatkan mekanisme tertentu (misalnya ERC 4337) yang memungkinkan mereka untuk mengganti aturan validitas yang dikenakan jaringan dengan aturan validitas yang disesuaikan, sesuai keinginan mereka.
• Sementara itu, dompet kontrak pintar adalah penyedia dompet yang berfungsi sebagai antarmuka ke akun kontrak (ya, dompet bukanlah akun).

Komersialisasi dompet kontrak pintar memudahkan adopsi CA oleh pasar yang lebih luas, memungkinkan pengguna yang kurang teknis untuk memanfaatkan fitur-fitur yang mereka tawarkan. Namun, mereka masih menghadapi masalah yang terkait dengan CA.

Kembali ke percakapan; kita sebelumnya telah membahas parameter-parameter yang digunakan untuk menentukan aturan validitas transaksi akun:

• Autentikasi
• Otorisasi
• Logika Nonce
• Logika pembayaran gas
• logika eksekusi

Nilai-nilai dari empat parameter pertama secara kolektif dapat disebut sebagai logika validasi akun, yang merupakan pemeriksaan yang terjadi sebelum eksekusi transaksi dimulai.

Parameter terakhir mendefinisikan bagaimana pelaksanaan transaksi akan dilakukan.

Dalam pengantar, kami menyediakan gambaran umum tingkat tinggi tentang lanskap AA saat ini dalam bentuk klasifikasi untuk berbagai desain yang diusulkan. Sekarang kita akan fokus pada kelas pertama solusi untuk dilema akun Ethereum - EOApemrograman.

EOA yang dapat diprogram

Daya tarik terbesar dari Ethereum adalah ekosistem DeFi yang muda namun berkembang pesat yang menampilkan berbagai aplikasi terdesentralisasi yang merupakan penyerap likuiditas utamanya. Sebagian besar DApps ini dioptimalkan untuk melayani EOAs, sehingga sulit dihubungkan dengan CAs, dan akhirnya rekening pintar. Sementara dompet kontrak pintar membantu CAs dalam hal ini, mereka datang dengan batasan mereka sendiri dan UX yang sama sekali berbeda.

Sebuah solusi sementara yang sedang dieksplorasi sementara kedua DApps dan penyedia dompet terbiasa dengan standar akun cerdas, adalah memberikan perbaikan sementara untuk EOAs yang memungkinkan mereka mengatasi sebagian besar pembatasan yang diberlakukan, baik itu validasi atau logika eksekusi mereka.

Di bawah ini, kami akan membahas spesifikasi dari tiga EIP utama yang memberikan rute yang dapat dijalankan ke EOAbilitas; dari yang kurang dikenal EIP 5806, kepada yang ambisius EIP 3074dan akhirnya ke yang menang EIP 7702.

Programabilitas melalui EIP-5806

Proposal ini bertujuan untuk memberikan lebih banyak fungsionalitas pada standar EOA dengan memungkinkannya melakukan panggilan delegasi ke logika akun kontrak (kontrak pintarnya). Ini secara efektif menyebabkan kontrak pintar dieksekusi dalam konteks EOA pemanggil, yaitu, EOA tetap mengontrol logika validasinya, sementara logika eksekusinya ditangani oleh logika CA yang sesuai.

Sebelum kita melanjutkan lebih jauh, mari kita mengingat kembali perjalanan evolusi Ethereum ke belakangEIP-7.

EIP-7 mengusulkan pembuatan opcode 0xf4/DELEgateCALL, yang digunakan untuk mengirim panggilan pesan ke akun utama dengan logika akun sekunder, sambil mempertahankan nilai-nilai bidang [pengirim] dan [nilai] akun utama.

Dengan kata lain, akun utama 'mewarisi' (atau meminjam jika Anda lebih suka) logika dari akun sekunder untuk beberapa durasi seperti yang ditentukan dalam panggilan pesan, sehingga logika terakhir dieksekusi dalam konteks yang pertama.

Opcode ini memungkinkan pengembang dApp untuk memisahkan logika aplikasi mereka menjadi beberapa kontrak pintar sambil mempertahankan ketergantungan antara mereka, sehingga mereka dapat dengan mudah menghindari batasan ukuran kode dan batasan gas.

EIP-5806 disimpulkan

Baiklah, jadi panggilan delegasi apa yang memungkinkan CA saling bergantung? Nah, EIP-5806 menggunakan EIP-7 sebagai inspirasi untuk mengusulkan ekspansi fungsi panggilan delegasi ke EOAs juga; yaitu, mari kita izinkan EOAs juga saling bergantung dengan CA, karena mengapa tidak.

Spesifikasi

EIP 5806 memperkenalkan yang baru sesuai dengan EIP-2718tipe transaksi yang dikemas sebagai berikut:

rlp([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, signature_y_parity, signature_r, signature_s]).

Transaksi ini dirancang agar bidang [to] – yang mewakili alamat penerima – hanya dapat menerima alamat sebagai input 20 byte, menonaktifkan pengirim dari menggunakan opcode CREATE.

Motivasi di balik setiap komponen dari skema RLP adalah sebagai berikut:

• chainID: Pengidentifikasi yang sesuai dengan EIP-115 dari rantai saat ini dipadatkan menjadi 32 byte. Nilai ini memberikan perlindungan dari serangan ulang untuk memastikan bahwa transaksi di rantai asli tidak mudah ditiru pada rantai EVM alternatif dengan riwayat yang mirip dan keamanan ekonomi yang lebih rendah.
• nonce: Pengenal unik untuk setiap transaksi yang juga menyediakan perlindungan serangan pengulangan.
• max_priority_fee_per_gas dan max_fee_per_gas: Nilai biaya gas yang harus dibayar oleh transaksi EIP-5806 untuk pengurutan dan inklusi secara berturut-turut.
• gas_limit: Jumlah maksimum gas yang dapat dikonsumsi oleh satu transaksi tipe 5806.
• tujuan: Penerima transaksi
• data: Konten kode yang dapat dieksekusi
• access_list: Agen yang secara kondisional diotorisasi untuk mengeksekusi transaksi EIP-5806.
• signature_y_parity, signature_r, dan signature_s: tiga nilai yang bersama-sama mewakili tanda tangan secp256k1 atas pesan — keccak256 (TX_TYPE || rlp ([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list])).

Sementara pengemasan transaksi EIP-5806 dalam amplop EIP-2718 memungkinkan mereka untuk sangat kompatibel ke belakang, EOA tidak setara dengan CA. Jadi pembatasan tertentu harus didefinisikan dengan cara EOA menggunakan panggilan delegasi untuk mencegah kerusakan invarian.

Pembatasan ini ditujukan pada opcode berikut:

• SSTORE/0x55: Opcode ini memungkinkan akun menyimpan nilai ke penyimpanan. Ini dibatasi dalam transaksi EIP-5806 untuk mencegah EOA mengatur/mengakses penyimpanan menggunakan panggilan delegasi, sehingga mencegah potensi masalah yang mungkin timbul di masa mendatang karena migrasi akun.
• CREATE/0xF0, CREATE2/0xF5, dan SELFDESTRUCT/0xFF: Opcodes ini secara luas memungkinkan pemanggil untuk membuat akun baru. Akses ke opcodes ini dibatasi untuk mencegah perubahan nonce EOA dalam kerangka eksekusi yang berbeda (pembuatan/penghancuran kontrak dalam hal ini) saat melakukan transaksi EIP-5806, untuk mencegah penghapusan harapan bahwa transaksi membawa nonce yang berurutan.

Potensi Penerapan/Kasus Penggunaan

Aplikasi utama EIP 5806 adalah abstraksi eksekusi untuk EOAs. Memungkinkan EOAs untuk berinteraksi dengan kontrak pintar tanpa harus mempercayai melampaui panggilan sederhana ke logika mereka memberikan fitur seperti:

• Pelaksanaan transaksi bersyarat
• Pengelompokan Transaksi
• Transaksi multicall (misalnya menyetujui dan menelepon)

Kritik

Perubahan yang diusulkan oleh EIP-5806, meskipun memungkinkan fitur yang dibutuhkan, tidak terlalu baru; keberadaannya sebagian besar didasarkan pada EIP-7 yang sudah berfungsi. Ini memungkinkannya untuk menghindari banyak rintangan potensial untuk diterima.

Salah satu kekhawatiran utama yang diutarakan pada awal pembentukannya adalah potensi risiko memungkinkan EOAs mengakses penyimpanan dan mengubahnya, sama halnya seperti CAs saat ini lakukan. Hal ini melanggar banyak invarian yang diamanatkan jaringan mengenai bagaimana EOAs melakukan transaksi, dan oleh karena itu ditangani dengan memperkenalkan pembatasan yang disebutkan dalam subbagian sebelumnya.

Kritik kedua (yang sedikit pedang bermata dua) adalah kesederhanaan EIP-5806; ada beberapa sentimen bahwa imbalan karena menerima EIP-5806 mungkin tidak sebanding dengan biayanya, karena hanya memungkinkan abstraksi eksekusi dan tidak banyak lagi. Setiap pembatasan validitas lainnya tetap ditentukan jaringan untuk EOA yang ikut serta dalam EIP-5806, berbeda dengan EIP lain yang agak mirip yang kita bahas dalam subbagian berikut.

Programabilitas melalui EIP-3074

EIP-3074 mengusulkan untuk memungkinkan EOAs untuk mendelegasikan sebagian besar logika validasi mereka ke akun kontrak khusus, yang disebut invokers, dengan menimpa logika otorisasi terakhir atas mereka untuk bentuk transaksi tertentu.

Ini dicapai dengan menandatangani kebijakan akses mereka ke kontrak pemanggil, yang kemudian menjadi bertanggung jawab untuk menentukan kebijakan akses EOA.

EIP ini mengusulkan penambahan dua opcode baru ke EVM:

• [AUTH] yang mengatur variabel konteks [authorized] akun untuk bertindak atas nama akun [authority] kedua, berdasarkan tanda tangan ECDSA yang terakhir.
• [AUTHCALL] yang mengirim/melaksanakan panggilan untuk akun [authority] dari/sebagai akun [authorized].

Kedua opcode ini memungkinkan EOA untuk menyerahkan kontrol kepada CA yang telah ditetapkan sebelumnya, dan dengan demikian, bertindak seolah-olah melalui CA tersebut tanpa harus menyebarkan kontrak dan menanggung biaya dan eksternalitas yang terkait dengan itu.

Spesifikasi

EIP-3074 memungkinkan transaksi menggunakan format tanda tangan [MAGIC] untuk mencegah tabrakan dengan format tanda tangan transaksi lainnya. Akun aktif ke mana instruksi [AUTHCALL] dilewatkan didefinisikan sebagai bidang variabel konteks bernama [authorized], yang hanya bertahan selama satu transaksi dan harus didefinisikan ulang untuk setiap [AUTHCALL] baru.

Sebelum membahas kompleksitas setiap opcode, berikut adalah entitas yang terlibat dalam transaksi EIP-3074:

• [authority]: Akun penandatanganan utama (EOA) yang mendelegasikan akses/kontrol ke akun kedua, yang biasanya merupakan akun kontrak.
• [authorized]: Akun tempat instruksi [AUTHCALL] diteruskan untuk dieksekusi. Dengan kata lain, ini adalah akun di mana logika [AUTHCALL] dijalankan, atas nama [otoritas], menggunakan batasan yang ditentukan oleh [invoker].
• [invoker]: Kontrak anak perusahaan yang dimaksudkan untuk mengelola interaksi antara akun [resmi] dan logika [AUTHCALL], terutama dalam kasus di mana logika utama dari kode kontrak yang terakhir adalah sponsor gas.

Kontrak Invoker menerima pesan [AUTH] dengan nilai [COMMIT] dari [otoritas]; nilai ini menentukan pembatasan yang diinginkan akun pada eksekusi instruksi [AUTHCALL] dari [otorisasi].

Dengan demikian, invokers bertanggung jawab untuk memastikan bahwa [contract_code] yang didefinisikan dalam sebuah akun [authorized] tidak bersifat berbahaya dan memiliki kemampuan untuk memenuhi invarian yang ditempatkan oleh akun penandatangan utama dalam nilai [COMMIT].

Opcode [AUTH] memiliki tiga elemen input tumpukan; atau lebih sederhana - didefinisikan oleh tiga input yang menghasilkan satu output. Input-input ini adalah:

1. authority: yang merupakan alamat EOA yang menghasilkan tanda tangan
2. offset
3. panjang

Dua input terakhir digunakan untuk menggambarkan rentang memori yang dapat dimodifikasi dari 0 hingga 97, di mana:

1. [memori(offset : offset+1)] - [yParity]
2. [memory(offset+1 : offset+33] – [r]
3. [memori (offset + 33: offset + 65)] - [s]
4. [memory(offset+65 : offset+97)] - [COMMIT]

Variabel [yParity], [r] dan [s] secara kolektif ditafsirkan sebagai tanda tangan ECDSA, [magic], pada kurva secp256k1 di atas pesan:

[keccak256 (MAGIC || chainID || nonce || alamat pemanggil || COMMIT)]

dimana:

• [MAGIC] adalah tanda tangan ECDSA yang dihasilkan dari kombinasi variabel:
  • [chainID] yang merupakan pengidentifikasi yang sesuai dengan EIP 115 rantai saat ini yang digunakan untuk memberikan perlindungan serangan replay pada rantai EVM alternatif dengan riwayat serupa dan keamanan ekonomi yang lebih sedikit.
  • [nonce] yang merupakan nonce saat ini dari alamat pengirim transaksi, dipadankan ke kiri hingga 32 byte.
  • [invokerAddress] adalah alamat kontrak yang berisi logika untuk eksekusi [AUTH].
• [COMMIT] adalah nilai 32 byte yang digunakan untuk menentukan kondisi validitas transaksi tambahan dalam logika pra-pemrosesan pemanggil.

Jika tanda tangan yang dihitung valid dan alamat penanda tangan sama dengan [otoritas], maka lapangan [terotorisasi] diperbarui dengan nilai yang diberikan oleh [otoritas]. Jika salah satu dari persyaratan ini tidak terpenuhi, maka lapangan [terotorisasi] tetap tidak berubah dalam keadaan sebelumnya, atau sebagai nilai yang tidak diatur.

Biaya gas untuk opcode ini dihitung sebagai jumlah dari:

1. Biaya tetap untuk pra-kompilasi [ecrecover] dan tambahan untuk hash keccak256 dan beberapa logika tambahan, bernilai 3100 unit
2. Biaya perluasan memori yang dihitung secara serupa dengan opcode [RETURN], dan diterapkan saat memori diperluas melebihi rentang yang ditentukan alokasi saat ini (97 unit)
3. Biaya tetap sebesar 100 unit dikeluarkan untuk [authority] yang hangat dan 2600 unit untuk yang dingin untuk mencegah serangan akibat kesalahan harga opcode akses state.

[AUTH] diimplementasikan untuk tidak memodifikasi memori, dan mengambil nilai [authority] sebagai argumen sehingga mudah untuk memverifikasi nilainya dari tanda tangan yang disediakan.

Opcode [AUTHCALL] memiliki tujuh elemen tumpukan masukan yang digunakan untuk menghitung keluaran elemen tumpukan tunggal.

Ini memiliki logika yang sama dengan opcode [CALL], yaitu; digunakan untuk mengirim pesan ke akun dan memicu logika tertentu dalam kontraknya. Satu-satunya perbedaan dalam logika mereka adalah bahwa [AUTHCALL] dirancang untuk mengatur nilai [CALLER] sebelum melanjutkan dengan eksekusi.

Dengan demikian, [AUTHCALL] digunakan oleh [otoritas] untuk memicu perilaku spesifik konteks dalam [otorisasi] dengan pemeriksaan logis yang dilanjutkan sebagai berikut:

1. Periksa nilai [authorized]. Jika tidak ditetapkan, eksekusi dianggap tidak valid dan bingkai segera keluar. Ini membantu mencegah biaya yang tidak adil akibat kegagalan yang tak terduga.
2. Memeriksa biaya gas dari perilaku yang dimaksudkan oleh [authorized].
3. Memeriksa nilai yang sesuai dengan EIP-150 dari operand [gas].
4. Memeriksa ketersediaan total biaya gas –[nilai]– dalam saldo [otoritas].
5. Pelaksanaan terjadi setelah pengurangan [nilai] dari saldo akun [otoritas]. Jika [nilai] lebih besar dari saldo mereka, pelaksanaan dibatalkan.

Biaya gas untuk [AUTHCALL] dihitung sebagai jumlah dari:

• Biaya tetap untuk memanggil [warm_storage_read]
• Biaya perluasan memori [memory_expansion_fee]; yang dihitung dengan cara yang sama seperti biaya gas untuk opcode [CALL]
• Biaya dinamis [dynamic_gas]
• Biaya eksekusi subcall [subcall_gas]

Data yang dikembalikan dari [AUTHCALL] diakses melalui:

• [RETURNDATASIZE] - yang mendorong ukuran buffer data kembali ke tumpukan output
• [RETURNDATACOPY] - yang mengkopi data dari buffer data yang dikembalikan ke memori.

Untuk menyatukan semuanya dengan sedikit bahasa teknis; transaksi Ethereum biasanya menentukan dua nilai:

1. tx.origin - yang memberikan otorisasi untuk transaksi.
2. msg.sender - di mana transaksi sebenarnya terjadi.

Dalam EOAs, seperti yang disebutkan sebelumnya, otorisasi erat terkait dengan eksekusi, yaitu; (tx.origin == msg.sender). Invarian sederhana ini menyebabkan sebagian besar masalah yang kami jelaskan dalam subbagian “Akun dan Validitas Transaksi” dalam laporan ini.

pesan [AUTH] dari [otoritas] memungkinkannya untuk menetralisir fungsi tx.origin ke [diotorisasi], sambil tetap menjadi msg.sender. Ini juga memungkinkannya untuk menentukan pembatasan terhadap hak istimewa ini menggunakan nilai [COMMIT].

[AUTHCALL] kemudian memungkinkan [authorized] untuk mengakses logika kontrak, menggunakan [invoker] sebagai perantara untuk memastikan kontrak yang ingin diakses tidak berbahaya. Artinya, untuk setiap [AUTHCALL], [authorized] harus menentukan [invoker] tertentu untuk [COMMIT] mereka.

Potensi Kegunaan/Kasus Penggunaan

EIP 3074 pada dasarnya bertanggung jawab untuk memungkinkan EOAs untuk mendelekasikan logika otorisasinya ke akun yang berbeda, namun desain terbukanya memungkinkan banyak hal lain dalam konteks yang berbeda.

Seluruh logika validasi dari sebuah EOA dapat diabstraksikan dengan menerapkan berbagai pembatasan/inovasi pada pengundang sesuai kebutuhan, beberapa desain yang mungkin berdasarkan logika target mereka termasuk:

• Logika nonce: EIP-3074 memungkinkan nonce EOAs tetap tidak terganggu setelah mengirim pesan [AUTH], sementara nonce-nya untuk setiap [AUTHCALL] tergantung pada yang mana yang memanggilnya. Dengan cara ini, ini memungkinkan paralelisme nonce untuk EOAs, sehingga mereka dapat mengirimkan beberapa [AUTHCALL] yang tidak tumpang tindih sesuai keinginan mereka.
• Logika pembayaran gas: Seperti yang ditentukandalam EIP, invokers dapat dirancang untuk mengizinkan sponsor gas. Dengan demikian, biaya gas untuk [COMMIT] pengguna dapat dikurangkan dari asal transaksi, atau dari akun pendukung apa pun, baik itu pribadi atau melalui relay berbasis layanan (layanan sponsor gas).

Selain itu, logika eksekusi secara intuitif diabstraksi; setelah semua pemanggil (yang merupakan CA) sekarang bertanggung jawab untuk mengeksekusi permintaan transaksi atas nama EOA.

Kritik

• Pusat Penggerak Pusat

MengutipSalah satu dari para penulisnya: “Saya tidak akan mengharapkan dompet untuk mengekspos fungsionalitas untuk menandatangani atas pemanggil sembarangan …”. Mungkin masalah terbesar yang dihadapi oleh inisiatif 3074 adalah bahwa inovasi di atasnya akan cenderung dengan mudah menuju aliran transaksi berizin dan propietari; sama seperti iterasi saat ini dari pasar MEV dan PBS Ethereum.

Secara default, kontrak invoker perlu diaudit secara mendalam untuk mencegah serangan yang lebih buruk daripada yang mungkin terjadi saat ini. Ini pasti akan cenderung ke ekosistem di mana hanya segelintir kontrak invoker yang dikembangkan oleh tokoh-tokoh berpengaruh akan diadopsi sebagai default untuk pengembang dompet. Dengan demikian, ini bermuara pada tradeoff antara mengambil jalur desentralisasi yang keras untuk terus-menerus mengaudit dan mendukung kontrak pemanggil dengan risiko keamanan pengguna; atau hanya mengadopsi kontrak invoker dari sumber yang mapan dan bereputasi baik dengan jaminan yang lebih baik untuk keamanan pengguna dan lebih sedikit pengawasan terhadap keamanan kontrak.

Aspek lain dari hal ini adalah fungsi biaya yang terkait dengan merancang, mengaudit, dan memasarkan pemanggil yang fungsional dan aman. Tim yang lebih kecil hampir selalu kalah oleh organisasi yang lebih besar –terutama di bagian pemasaran– yang sudah memiliki reputasi yang mapan, bahkan jika produk mereka lebih baik.

• Masalah Kompatibilitas ke Depan

EIP-3074 mengokohkan skema tanda tangan ECDSA, karena masih dianggap lebih valid daripada skema otorisasi yang diperkenalkan melalui invoker. Meskipun ada argumen bahwa ketahanan terhadap kuantum saat ini bukan masalah yang pasti, dan bahwa ada hal yang jauh lebih buruk yang dipertaruhkan di masa depan di mana ECDSA dapat dikorupsi; tujuan Ethereum yang agak tidak diungkapkan adalah selalu berada di depan masalah tersebut. Mengorbankan ketahanan terhadap kuantum dan sensor untuk peningkatan margin dalam UX mungkin bukan pilihan terbaik dalam waktu dekat.

Titik lain dalam argumen keberlanjutan ke depan adalah bahwa sementara manfaat dari 3074 masih dievaluasi, ERC-4337 (yang tidak memerlukan perubahan protokol apapun) kini memiliki pasar yang besar, jadi Anda juga harus kompatibel dengannya untuk menghindari kompartementalisasi ekosistem.

Meskipun dengan garis waktu abstraksi akun asli, opcode [AUTH] dan [AUTHCALL] pada akhirnya akan menjadi usang dalam EVM, memperkenalkan banyak hutang teknis ke Ethereum untuk memberikan peningkatan UX yang kecil.

• Skema ECDSA Ketidakpembatalan

Setelah mengirim pesan [AUTH] dan mendelekasikan kontrol, EOA diharapkan untuk menghindari skema otorisasi kunci privat biasa, karena mengirim transaksi 'normal' menyebabkan otorisasi yang didelegasikan kepada setiap pemanggil dicabut.

Oleh karena itu, skema ECDSA tetap jauh lebih unggul dibandingkan dengan skema otorisasi lain yang dapat diaktifkan oleh kontrak terkait, yang berarti kehilangan kunci pribadi akan mengakibatkan total kehilangan aset akun.

Kemampuan pemrograman melalui EIP-7702

Usulan ini awalnya diatur sebagai variasi yang agak minimalis dari EIP 3074, danbahkan dimaksudkanuntuk menjadi pembaruan untuk itu. Ia lahir untuk menangani ketidaksempurnaan yang seharusnya dari EIP 3074, terutama kekhawatiran seputar ketidakcocokan dengan ekosistem 4337 yang sudah berkembang dan proposal abstraksi akun asli – RIP 7560.

Pendekatan yang digunakan adalah menambahkan jenis transaksi yang sesuai dengan EIP 2718 baru - [SET_CODE_TX_TYPE] - yang memungkinkan EOA berperilaku sebagai akun pintar untuk transaksi yang ditentukan.

Desain ini memungkinkan fitur yang sama seperti EIP 5806 dan beberapa lagi, sambil tetap kompatibel dengan peta jalan abstraksi akun asli dan inisiatif yang ada.

Spesifikasi

EIP-7702 memungkinkan EOA untuk "mengimpor" konten kode kontrak melalui transaksi yang sesuai dengan [SET_CODE_TX_TYPE] 2718 dengan format:

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])

Payload ini sepenuhnya mirip dengan EIP 5806, kecuali bahwa ia memperkenalkan "daftar otorisasi". Daftar ini adalah urutan nilai format yang diurutkan:

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

di mana setiap tuple mendefinisikan nilai [alamat].

Sebelum melanjutkan, pihak yang terlibat dalam SET_CODE_TX_TYPE adalah:

• [authority]: yang merupakan akun penandatanganan EOA/utama
• [address]: yang merupakan alamat dari akun yang berisi kode yang dapat didelegasikan.

Ketika [otoritas] menandatangani SET_CODE_TX_TYPE yang menentukan [alamat], penanda delegasi dibuat. Ini adalah "program pointer" yang menyebabkan semua permintaan pengambilan kode karena tindakan [otoritas] setiap saat disalurkan ke kode [alamat] yang dapat diamati.

Untuk setiap tuple [chain_id, address, nonce, y_parity, r, s], alur logika transaksi tipe 7702 adalah sebagai berikut:

1. Verifikasi tanda tangan [authority] dari hash yang diberikan menggunakan: authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]
2. Pencegahan serangan replay lintas rantai dan vektor serangan lainnyadengan verifikasi ID rantai.
3. Memeriksa apakah [otoritas] sudah memiliki konten kode.
4. Pemeriksaan Nonce untuk memastikan nonce [authority] sama dengan nonce yang disertakan dalam tuple.
5. Jika transaksi adalah transaksi SET_CODE_TX_TYPE pertama [otoritas], maka akan dikenakan biaya PER_EMPTY_ACCOUNT_COST. Jika saldo transaksi kurang dari nilai biaya ini, operasi akan ditinggalkan.
6. Penunjukan delegasi terjadi, di mana kode [otoritas] diatur ke penunjuk [alamat].
7. Nonce dari penandatangan –[authority]– ditingkatkan sebanyak satu.
8. [authority] ditambahkan ke daftar alamat yang diakses, yang (disederhanakan) adalah kumpulan alamat yang dibuat sedemikian rupa sehingga pembalikan cakupan transaksi dari mereka menyebabkan mereka (alamat) kembali ke keadaan sebelumnya, sebelum cakupan yang dibalik masuk. Ini seperti yang didefinisikan dalam EIP-2929untuk mengaktifkan penyimpanan nilai yang dapat digunakan kembali dan mencegah biaya yang tidak perlu.

Wah! Untuk mengaitkan semuanya kembali; EIP ini memungkinkan EOAs untuk mengirim transaksi yang menetapkan penunjuk ke kode kontrak, memungkinkan mereka untuk menerapkan logika ini sebagai milik mereka sendiri dalam transaksi berikutnya. Dengan cara ini, itu jauh lebih kuat daripada EIP 5806, karena memungkinkan EOAs benar-benar memiliki konten kode selama yang mereka inginkan (berbeda dengan EIP 5806 yang hanya memungkinkan EOAs untuk mengirim delegate-calls).

Potensi Aplikabilitas/Kasus Penggunaan

• Abstraksi Eksekusi

Meskipun dapat diperdebatkan bahwa ini bukan lagi abstraksi karena EOA secara aktif mengambil logika yang ingin dieksekusi, tetapi itu masih bukan 'pemilik utama' dari logika tersebut. Selain itu, itu tidak langsung mengandung logika, hanya menentukan pointer ke logika tersebut (untuk mengurangi kompleksitas komputasi). Jadi kita menggunakan abstraksi eksekusi!

• Pensponsan Gas

Sementara invarian require(msg.sender == tx.origin) dilanggar untuk memungkinkan sponsor sendiri, EIP masih memungkinkan integrasi penghubung transaksi sponsor. Namun, catatannya adalah penghubung semacam itu memerlukan sistem berbasis reputasi atau staking untuk mencegah serangan griefing.

• Kebijakan Akses Bersyarat

EOA hanya dapat menunjuk ke bagian tertentu dari kode akun, sehingga hanya logika bagian tersebut yang dapat dijalankan dalam konteks mereka.

Ini juga memungkinkan keberadaan sub kunci yang terus mengaktifkan "de-eskalasi hak istimewa", sehingga dAPP tertentu hanya memiliki akses ke saldo akun dalam kondisi tertentu. Misalnya, Anda dapat membayangkan izin untuk membelanjakan token ERC-20 tetapi bukan ETH, atau membelanjakan hingga 1% dari total saldo per hari, atau hanya berinteraksi dengan aplikasi tertentu.

• Penyebaran Kontrak Cerdas Cross-chain

Karena sifatnya yang tidak membatasi, transaksi EIP-7702 dapat memungkinkan pengguna untuk mengakses opcode CREATE2 dan menggunakannya untuk mendeploy bytecode ke alamat tanpa parameter pembatas lainnya seperti logika pasar biaya (mis. EIP-1559 dan EIP-4844). Hal ini memungkinkan alamat tersebut untuk dipulihkan dan digunakan di berbagai state machine, dengan bytecode yang sama, di mana akunnya di setiap chain bertanggung jawab untuk menentukan parameter konteks-variabel lainnya.

Kritik

• Kurangnya kompatibilitas mundur

Sementara EIP-7702 masih sangat baru, sudah banyak prototyping dan pengujian untuk dependensinya dan potensi kerugiannya, tetapi model minimalisnya menjamin fleksibilitas yang tinggi, dan dengan demikian kegunaannya, dalam konteks yang berbeda. Namun, hal itu melanggar terlalu banyak invarian dan tidak langsung kompatibel ke belakang.

Beberapa logika di dalamnya termasuk:

1. Pengubahan nonce EOA saat transaksi tengah berlangsung: EIP-7702 tidak membatasi opcode manapun untuk memastikan konsistensi. Ini berarti EOA dapat menerapkan opcode seperti CREATE, CREATE2, dan SSTORE saat menjalankan transaksi EIP-7702, memungkinkan nonce-nya untuk ditingkatkan dalam konteks yang berbeda.
2. Mengizinkan akun dengan nilai codeHash non-nol untuk menjadi pengirim transaksi: EIP-3607 diimplementasikan untuk mengurangi potensi dampak negatif dari "tabrakan alamat" antara EOAs dan CAs. Tabrakan alamat terjadi ketika nilai 160-bit dari alamat EOA sepenuhnya setara dengan alamat CA.

Sebagian besar pengguna tidak tahu persis isi sebuah akun (atau bahkan perbedaan antara akun dan alamat!), sehingga memungkinkan adanya tabrakan alamat berarti EOA dapat menyamar sebagai CA dan menarik dana pengguna dalam upaya yang rumit untuk akhirnya mencurinya semua. EIP-3607 menangani masalah ini dengan menentukan bahwa akun yang mengandung kode tidak boleh dapat menghabiskan saldo mereka menggunakan logika otorisasi mereka sendiri. Namun, EIP 7702 melanggar invarian ini untuk memungkinkan EOAs tetap mandiri meskipun setelah mendapatkan beberapa kemampuan pemrograman.

• Kemiripan dengan EIP-3074

Menandatangani alamat akun daripada kontennya adalah sama seperti skema 3074 dengan pemanggil. Ini tidak memberikan jaminan yang ketat terhadap konsistensi konten kode antar-rantai, karena alamat bisa memiliki konten kode yang berbeda di rantai yang berbeda. Ini berarti bahwa alamat yang kontennya mengandung logika yang sama di satu rantai bisa menjadi berbahaya atau jahat di rantai lain, dan ini bisa menyebabkan kerugian dana pengguna.

Kesimpulan

EOA dalam bentuknya saat ini sangat terbatas karena tidak memungkinkan pengguna untuk memanfaatkan fitur pemrograman yang ditawarkan oleh EVM. Meskipun ada berbagai cara untuk meningkatkan akun, seperti yang kami jelaskan pada awal laporan ini, solusi yang dipilih harus menjaga prinsip pengelolaan sendiri yang aman dan terjamin. Selain itu, peningkatan EOA dapat berdampak signifikan baik pada pengalaman pengguna maupun pengembang aplikasi sehingga semua suara pemangku kepentingan harus dipertimbangkan.

Mengizinkan EOAs untuk menjalankan kode dengan cara apa pun sangat memperluas fungsionalitas akun, tetapi ekspresibilitas baru ini datang dengan risiko yang signifikan dan kemungkinan kesalahan yang tidak terduga. Menyelesaikan kompromi ini sangat penting untuk memberikan upgrade dengan manfaat UX yang tak terbantahkan bagi pengguna Ethereum.

Budaya diskusi terbuka Ethereum menjadikannya tempat uji coba yang baik untuk inovasi seperti itu karena hampir setiap implikasi dari setiap desainnya dibongkar secara menyeluruh oleh para ahli subjek. Pertimbangan komprehensif ini harus membantu mengurangi risiko pelanggaran hukum dari lawan.

EIP-7702 saat ini menjadi contoh utama untuk mekanisme yang ingin membawa pemrograman EVM ke EOAs, telah ditandai sebagai pengganti slot EIP 3074 dalam upgrade Pectra. Ini mewarisi desain terbuka mekanisme 3074 sambil sangat mengurangi permukaan serangan / risiko. Ini juga memungkinkan banyak hal lebih banyak dengan menghindari pembatasan 3074 pada beberapa kelas opcode tertentu.

Meskipun masih ada beberapa penyempurnaan yang sedang dilakukan pada desain proposal, namun telah berhasil mendapat banyak dukungan dan simpati dari para pengembang, terutama karena didukung langsung oleh Vitalik.

Dalam komunitas, ada klaim bahwa pendekatan abstraksi akun ini mungkin bahkan lebih baik daripada akun pintar. Komentar ini menekankan bahwa jalur ini membutuhkan perubahan yang lebih sedikit dan tidak sekompleks itu, dan bahwa EOAs sudah diabadikan. Namun, kita harus ingat tentang tonggak keamanan masa depan yang berhubungan dengan daya tahan kuantum di setiap tingkat jaringan Ethereum. Keamanan kuantum ini tidak mungkin dilakukan dengan model akun inti saat ini karena penggunaan skema tanda tangan berbasis ECDSA untuk otorisasi EOA.

Oleh karena itu, programabilitas EOA harus dipandang sebagai langkah menuju akun pintar dan bukan tujuan akhir. Ini mempercepat EOAs dan memungkinkan pengalaman pengguna dan pengembang yang lebih baik, sambil tetap kompatibel dengan tujuan abstraksi akun utama dari akun pintar.

Dalam laporan berikutnya, kami akan menyelami skema migrasi EOA untuk melihat sejauh mana mereka sesuai dengan peta jalan abstraksi akun, tetap terhubung!

Penafian：

1. Artikel ini dicetak ulang dari [2077.xyz], Semua hak cipta milik penulis asli [ zhev]. Jika ada keberatan terhadap cetakan ini, silakan hubungi Gate Belajartim, dan mereka akan segera menanganinya.
2. Penafian Tanggung Jawab: Pandangan dan opini yang terungkap dalam artikel ini sepenuhnya milik penulis dan tidak merupakan nasihat investasi apa pun.
3. Penerjemahan artikel ke bahasa lain dilakukan oleh tim gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.