Apa Itu Delegasi EIP-7702? Penjelasan tentang Smart Account EOA

Delegasi EIP-7702 memungkinkan akun milik eksternal (EOA) menyerahkan logika eksekusinya kepada kontrak lain tanpa mengubah alamat atau menyerahkan kunci privatnya. Kolom kode diatur ke 0xef0100 ditambah alamat delegasi, dan panggilan berikutnya menjalankan kode tersebut dalam konteks EOA sendiri, dengan saldo, nonce, dan penyimpanan tetap menjadi milik akun.

Ini cocok bagi pembaca yang sudah memahami dompet self-custody dan model akun EVM. Ethereum telah lama memiliki dua jenis akun: EOA yang dikendalikan kunci dan akun kontrak dengan kode, dan hanya jenis kedua yang dapat memiliki logika validasi kustom, dengan konsekuensi memerlukan alamat baru. Fitur ini dirilis melalui peningkatan Pectra dan memindahkan validasi kustom dari pembukaan akun baru ke penulisan kode pada alamat yang telah digunakan.

Tuple otorisasi memuat enam kolom, dan penanda delegasi menggunakan 23 byte: awalan tiga byte ditambah alamat 20 byte. Jalur penulisan, batas kemampuan baru, perbedaan dengan ERC-4337, dan apakah delegasi dapat dipercaya menentukan seberapa besar kendali yang tetap dimiliki akun setelah tanda tangan tersebut.

Poin Utama

• Delegasi EIP-7702 mempertahankan alamat, kunci privat, saldo, dan nonce, serta hanya mengarahkan kolom kode ke kontrak delegasi.

• Transaksi tipe 0x04 menulis delegasi melalui tuple otorisasi; pesan yang ditandatangani tidak memuat kolom biaya, dan pengirim tidak harus merupakan pemilik.

• Delegasi tidak memiliki masa kedaluwarsa; pencabutan menghapus kode, tetapi tidak menghapus penyimpanan, persetujuan token, atau tanda tangan Permit.

• Delegasi tanpa receive() atau fallback() menyebabkan transfer ETH biasa gagal, dan tx.origin tidak lagi menyiratkan bahwa suatu akun tidak memiliki kode.

• ERC-4337 membangun sistem akun terpisah, sedangkan EIP-7702 menambahkan kode ke EOA yang sudah ada, sehingga keduanya dapat digunakan bersama.

Apa yang Diubah Delegasi EIP-7702 pada Akun Milik Eksternal?

Ethereum memiliki dua jenis akun: akun milik eksternal yang dikendalikan oleh kunci privat dan akun kontrak yang berisi kode.

Dengan EIP-7702, yang berubah adalah kolom kode, bukan identitas akun, karena EOA dapat sementara mengarah ke kode kontrak tanpa mengubah alamatnya. Alamat, kunci privat, saldo, dan nonce tetap berada di tempat semula; perbedaannya adalah alamat tersebut kini membawa kode yang dapat dieksekusi dari kontrak lain yang telah diterapkan.

Kolom tersebut memuat penanda delegasi 23 byte: awalan 0xef0100 ditambah alamat 20 byte. Ketika panggilan menargetkan EOA tersebut, EVM membaca penanda itu dan memuat kode delegasi, sehingga akun dapat berperilaku seperti smart account sementara kunci privat tetap memegang kendali dan pengirim, saldo, serta penyimpanan semuanya dibaca sebagai milik EOA.

Delegasi tidak dapat melihat statusnya sendiri; logika eksekusinya dimuat dari kontrak target, sementara penyimpanan dan konteks pengirim tetap menjadi milik EOA, dan penulisan mengikuti logika yang sama ke dalam penyimpanan yang sebelumnya tidak pernah digunakan EOA.

Tanda tangan tetap berasal dari kunci privat asli, sehingga akun tidak menjadi multisig, dan rancangan ini merupakan langkah menuju abstraksi akun, termasuk varian native, bukan perubahan jenis akun.

Tipe 0x04 dan Tuple Otorisasi: Cara Delegasi Mengakses Kode Kontrak

Penulisan memerlukan jenis transaksi baru, 0x04, yang isi transaksinya memuat daftar otorisasi; setiap tuple ditandatangani oleh pemegang akun, sedangkan transaksi itu sendiri dapat dikirim dan biayanya dibayar oleh alamat mana pun, dan otorisasi menentukan kode mana yang diizinkan akun untuk dijalankan.

Tuple tersebut adalah [chain_id, address, nonce, y_parity, r, s], dan pesan yang ditandatangani adalah keccak(0x05 || rlp([chain_id, address, nonce])); spesifikasi EIP-7702 menggunakan awalan 0x05 untuk membedakan tanda tangan otorisasi dari tanda tangan transaksi biasa, dan pesan tersebut tidak memuat kolom gas atau biaya.

Yang ditandatangani adalah alamat tujuan kode, bukan transaksi tertentu, sehingga beberapa sistem memasangkan otorisasi dengan intent. Akun juga dapat menandatangani satu kali secara offline sementara sponsor menanggung biaya gas.

Validasi node berjalan dalam enam langkah, dengan keterikatan nonce membuat sebuah otorisasi hanya dapat digunakan satu kali, pada nonce yang sesuai.

Daftar otorisasi berada dalam isi transaksi sebagaimana access list memperluas format transaksi: ID chain bernilai 0 atau cocok dengan chain lokal (0 berarti valid pada chain mana pun); nonce lebih kecil dari 2^64-1; ecrecover memverifikasi tanda tangan; kode akun kosong atau sudah didelegasikan; nonce cocok dengan nilai saat ini; dan kode ditulis sebagai 0xef0100 || address dengan nonce bertambah.

Pencabutan mengikuti jalur yang sama dengan address diatur ke nol, yang menghapus hash kode tanpa perubahan status permanen pada EOA yang mendasarinya.

Properti Akun Apa yang Tetap Tidak Berubah?

Empat properti tetap seperti sebelumnya, dan hanya kode serta penyimpanan yang berubah: kode berubah dari 0x menjadi penanda, slot penyimpanan yang belum digunakan mulai menerima penulisan, dan nilai tersebut tetap ada setelah pencabutan. Spesifikasi secara terpisah mencantumkan tiga invarian onchain yang tidak lagi berlaku, mencakup saldo, nonce, dan identitas pemanggil; bagian risiko membahasnya.

1. Alamat: tidak berubah, sehingga riwayat, persetujuan token, dan catatan nama tetap mengarah ke satu alamat.

2. Kunci privat: tidak berubah, dan menandatangani transaksi biasa serta otorisasi baru yang menimpa atau mencabut delegasi.

3. Saldo: tidak berubah, karena delegasi tidak memindahkan aset dan akun tetap menyimpannya secara langsung.

4. Nonce: terus bertambah, karena otorisasi menggunakan satu nonce, yang mencegah pemutaran ulang tanda tangan yang sama.

Apakah Akun yang Didelegasikan Tetap Dapat Menerima ETH Secara Normal?

Tidak secara default. Setelah akun memiliki kode, transfer ETH biasa memasuki jalur eksekusi kode; jika delegasi tidak menerapkan receive() maupun fallback(), transfer tersebut gagal dan dana dikembalikan kepada pengirim.

Masalah ini dapat terjadi pada alur pembayaran umum seperti penarikan dari bursa, penggajian, dan airdrop. Perangkat lunak dompet biasanya hanya melaporkan kegagalan, bukan bahwa delegasi adalah penyebabnya. Sebelum menandatangani, pastikan target menerapkan fungsi receive, atau arahkan pembayaran masuk melalui panggilan yang membawa calldata, dan perangkat lunak dompet sebaiknya menampilkan penyebab tersebut dengan lebih jelas kepada pengguna.

Gambar 1. Jalur penulisan EIP-7702: EOA menandatangani tuple otorisasi, transaksi tipe 0x04 mengatur kode menjadi 0xef0100 ditambah alamat delegasi, dan panggilan berikutnya mengeksekusi kode tersebut dalam konteks EOA.

Apa yang Dapat Dilakukan Akun yang Didelegasikan? Batching, Sponsor Gas, dan Pemulihan

Delegasi mengubah EOA dari akun yang hanya dapat menandatangani transaksi menjadi akun yang berperilaku seperti smart account bagi pengguna sehari-hari, dengan manfaat paling jelas pada batching, sponsor gas, dan pemulihan berbasis aturan.

Batching adalah manfaat yang paling nyata: approve dan swap dapat terjadi dalam satu transaksi, sponsor juga dapat mempermudah onboarding atau batching dengan membantu menyelesaikan beberapa langkah di latar belakang pada saat yang tepat, sehingga satu tanda tangan menyelesaikan transaksi sekali dan tidak ada persetujuan yang dibiarkan tidak digunakan di antaranya.

Sponsor gas muncul dari pemisahan tanda tangan dari pengirim: pihak ketiga membayar, akun tidak memerlukan ETH di muka, dan dengan paymaster ERC-4337 biayanya dapat ditanggung oleh aplikasi. Ini juga berarti beberapa aplikasi dapat menanggung gas atau mempermudah onboarding dengan menanganinya di latar belakang, tetapi pengembang sebaiknya tidak meminta delegasi saat pengguna hanya meminta fitur lain.

Pemulihan dan session key mengandalkan delegasi untuk memverifikasi tanda tangan sendiri, misalnya menggunakan passkey, kumpulan guardian, atau batas pengeluaran sebagai pengganti satu kunci. Delegasi juga dapat menerapkan fungsi mirip kebijakan seputar transfer atau penggunaan penanda tangan.

Batasannya tegas: siapa pun yang memegang kunci privat selalu dapat menandatangani otorisasi baru yang menimpa delegasi, sehingga pemulihan di sini lebih lemah daripada pada smart account native dan hanya menurunkan dampak dari kunci yang hilang.

Delegasi tidak memiliki masa kedaluwarsa. Delegasi tetap aktif hingga otorisasi baru menimpanya atau alamat nol mencabutnya, sehingga izin ini bersifat jangka panjang dan memerlukan pengelolaan aktif; dari sisi keamanan, tinjau cakupan akses dan kendali yang dapat dimiliki kode delegasi.

Apa Perbedaan Delegasi EIP-7702 dengan ERC-4337 dan Abstraksi Akun?

EIP-7702 menambahkan kode ke EOA yang sudah ada, sedangkan ERC-4337 membangun sistem akun terpisah; sebagai pendekatan abstraksi akun yang saling melengkapi, keduanya dapat digunakan bersama, bukan saling menggantikan.

ERC-4337 dimulai dari kontrak yang baru diterapkan, sehingga aset dan persetujuan perlu dipindahkan; 7702 dimulai dari alamat asli dan menambahkan kode, menghindari migrasi dengan memungkinkan akun yang ada menggunakan perilaku smart contract tanpa terlebih dahulu menerapkan dompet terpisah.

Bersama-sama, keduanya memungkinkan akun 7702 berfungsi sebagai implementasi akun untuk ERC-4337, dan pengembang dapat membangun alur yang kompatibel dengan 4337 di atas akun yang didelegasikan dengan 7702. Ini kembali memunculkan race condition inisialisasi: di antara delegasi diterapkan dan inisialisasi selesai, siapa pun dapat memanggil initializer dan menetapkan dirinya sebagai pemilik.

Terdapat dua perbaikan — initWithSig, yang mengikat tanda tangan pada argumen inisialisasi, atau membatasi inisialisasi hanya untuk EntryPoint.

Apakah Delegasi Dapat Dipercaya? Cara Memverifikasi bahwa Kontrak Bersifat Tidak Dapat Diubah

Delegasikan hanya kepada kontrak tidak dapat diubah yang diterapkan dari initcode CREATE2 standar; mekanisme verifikasi sebaiknya mengutamakan target tanpa jalur peningkatan, karena kontrak proxy, kontrak yang dapat ditingkatkan, dan kontrak dengan jalur self-destruct semuanya merupakan target yang kurang baik.

Delegasi menyerahkan hak eksekusi kepada kode tersebut, dan pemegang tidak menerima pemberitahuan perubahan. Target yang dapat ditingkatkan berarti pihak yang melakukan peningkatan memegang kuasa eksekusi atas setiap akun yang mendelegasikan kepadanya; target yang tidak dapat diubah setidaknya menetapkan permukaan serangan sejak awal, sehingga dapat diaudit. Paparan keamanan meningkat jika kode delegasi dapat berubah setelah otorisasi.

Tiga kriteria — kode tidak dapat diubah, tanpa proxy, penerapan yang dapat direproduksi — menjadi empat pemeriksaan di block explorer yang harus diverifikasi oleh dompet dan pengembang sebelum memberikan delegasi:

1. Baca slot implementasi dan admin: slot EIP-1967 nonnol yang dimulai dengan 0x360894 menandakan proxy atau jalur peningkatan.

2. Bandingkan bytecode onchain dengan kode sumber yang telah diverifikasi, dengan memastikan argumen constructor dan bytecode yang diterapkan sesuai.

3. Cari selfdestruct dan delegatecall, dengan memastikan tidak ada cabang yang dapat menghapus kode atau meneruskan eksekusi ke tempat lain.

4. Hitung ulang alamat CREATE2 dari initcode dan salt, dengan memastikan deployer tidak dapat mengganti kontrak lain di alamat yang berbeda.

Apa Risiko Delegasi EIP-7702?

Risiko berada di tiga tempat: bug dalam delegasi, semantik akun yang diubah oleh delegasi, dan ketidakdapatdibatalkan dari tanda tangan sekali pakai — ini merupakan kompromi keamanan sekaligus peningkatan fungsionalitas, dengan perhatian utama pada cakupan luas kode yang dapat mengendalikan akun setelah otorisasi diberikan.

Baris tx.origin memiliki dampak paling luas. Akun yang didelegasikan dapat mengeksekusi kode dalam call stack, sehingga msg.sender == tx.origin tidak lagi berarti pemanggil tidak memiliki kode, dan pelindung yang dibangun berdasarkan perbandingan tersebut tidak lagi melindungi; nonReentrant atau kunci transient-storage tidak bergantung pada identitas pemanggil.

Dalam praktiknya, jika dompet tidak menampilkan detail otorisasi dengan jelas, pengguna dapat menyetujui akses yang sebenarnya tidak ingin mereka tinjau. Panduan EIP-7702 dalam dokumen Pectra mencantumkan hal ini secara terpisah.

chain_id bernilai 0 memperluas kategori ketiga: tanda tangan yang sama valid pada chain EVM lain, sehingga sebuah akun dapat diberi kode pada chain yang tidak pernah dipertimbangkan oleh pemegangnya. Perangkat penandatanganan sering kali tidak menampilkan ID chain, dan di situlah kompromi di balik mengaktifkan delegasi pada cold wallet berada.

Bagaimana Cara Memeriksa dan Mencabut Delegasi?

Pemeriksaan hanya memerlukan satu pembacaan kode: eth_getCode yang mengembalikan 0x berarti tidak ada delegasi, 23 byte yang dimulai dengan 0xef0100 berarti akun tersebut adalah akun milik eksternal yang didelegasikan, dan bytecode lain berarti akun kontrak.

Delegasi adalah status tingkat chain, sehingga satu alamat dapat didelegasikan pada satu chain dan tidak berubah pada chain lain, dan setiap chain memerlukan pemeriksaannya sendiri; 20 byte terakhir adalah delegasi, dan dompet atau platform dapat mengotomatiskan pemeriksaan ini di berbagai chain sambil menyimpan log pemeriksaan atau perubahan status untuk audit dan pemantauan.

Untuk peninjauan manual singkat, memeriksa dan mencabut delegasi menjelaskan langkah-langkahnya.

Pencabutan dilakukan di dalam dompet: tandatangani otorisasi baru dengan kolom address diatur ke nol dan node menghapus hash kode, mengembalikan akun menjadi EOA biasa, sementara dApp eksternal umumnya tidak dapat melakukannya atas nama pemegang, dan jika tim dompet mendukung alur pencabutan, setiap permintaan untuk bertindak atas nama pemegang tetap harus memerlukan persetujuan pemegang sendiri.

Pencabutan menghapus kode delegasi, tetapi tidak menghapus persetujuan smart contract sebelumnya atau akses lain yang telah diberikan kepada aplikasi, dan catatan delegasi EOA OpenZeppelin menjelaskan batasan tersebut.

Ringkasan

EIP-7702 memberikan kemampuan pemrograman pada EOA dengan satu tanda tangan: alamat dan kunci tetap berada di tempatnya, kolom kode mengarah ke delegasi, dan eksekusi berjalan dalam konteks akun itu sendiri.

Konsekuensinya adalah semantik yang berubah dan izin jangka panjang: pembayaran masuk biasa dapat gagal, tx.origin bukan lagi EOA, tanda tangan dengan chain_id 0 dapat digunakan lintas chain, dan pencabutan hanya menghapus kode.

FAQ

Apakah EIP-7702 mengubah dompet saya menjadi multisig?

Tidak. Delegasi hanya mengubah kolom kode, dan tanda tangan tetap berasal dari kunci privat asli, sehingga pemegang satu kunci dapat bertransaksi secara mandiri dan dapat menimpa delegasi dengan otorisasi baru. Delegasi yang menuntut beberapa tanda tangan juga dapat dilewati oleh kunci tersebut.

Bagaimana cara memeriksa apakah dompet saya didelegasikan dengan EIP-7702?

Panggil eth_getCode pada alamat tersebut. Hasil 0x berarti tidak ada delegasi; 23 byte yang dimulai dengan 0xef0100 berarti akun tersebut didelegasikan, dengan 20 byte terakhir menunjukkan delegasi; bytecode lain berarti akun kontrak.

Delegasi dicatat per chain, jadi periksa setiap chain, dan dompet atau sistem administrasi dapat menyimpan log pemeriksaan tersebut untuk ditinjau. Singkatnya, jawaban dapat berbeda hanya dalam detail antarmuka antar dompet, tetapi pemeriksaan kode yang mendasarinya sama.

Bagaimana cara mencabut delegasi EIP-7702?

Tandatangani otorisasi baru dengan kolom address diatur ke nol dari dalam dompet, dan node menghapus hash kode setelah validasi berhasil. Hanya pemegang akun yang dapat menandatanganinya, dan dApp eksternal biasanya tidak dapat bertindak atas nama mereka.

Apakah delegasi kedaluwarsa, dan apakah persetujuan token sebelumnya tetap berlaku setelah pencabutan?

Delegasi tidak memiliki masa kedaluwarsa dan tetap aktif hingga ditimpa atau dicabut. Pencabutan hanya menghapus kode, sehingga penyimpanan, persetujuan ERC-20, dan tanda tangan Permit tetap tidak berubah.

Kunci saya tidak pernah bocor — apakah otorisasi EIP-7702 yang berbahaya masih dapat menguras akun?

Ya. Tanda tangan adalah pemindahan otoritas: dengannya, penyerang dapat menulis delegasi yang mengarah ke kontrak berbahaya dan memperoleh akses luas ke akun, memindahkan aset tanpa pernah menyentuh kunci privat.

Periksa ID chain dan alamat target dalam tuple, dan tanda tangani hanya untuk kontrak yang tidak dapat diubah; tim dompet juga harus memverifikasi tugas penanda tangan sebelum memberikan persetujuan internal terkait delegasi atas nama organisasi.