Crypto · 5 min read · 4 views
EIP-7702 dan Account Abstraction Ethereum: Delegasi Akun, Manfaat UX, dan Risiko Keamanannya
EIP-7702 membawa kemampuan account abstraction ke akun Ethereum yang sudah ada. Artikel ini mengurai mekanisme delegasi, manfaat UX, risiko keamanan, dan checklist implementasi tanpa hype investasi.
GD
I Gusti Agung Ganes Satsangga Dipa
Backend & Software Developer
# Pembukaan
Account abstraction sering dijelaskan sebagai upaya membuat dompet Ethereum terasa seperti aplikasi modern, bukan sekadar pasangan alamat dan private key. Gagasan ini menjadi semakin konkret setelah EIP-7702 memungkinkan externally owned account (EOA) menetapkan kode akun untuk dipakai dalam transaksi. Dampaknya bukan perubahan harga aset, melainkan perubahan lapisan pengalaman pengguna: transaksi dapat dibundel, biaya gas bisa disponsori, dan kebijakan otorisasi dapat dibuat lebih lentur tanpa memaksa pengguna segera memindahkan aset ke alamat baru.
Namun, kemudahan itu datang bersama model risiko baru. Ketika sebuah akun dapat mendelegasikan eksekusi kepada kode, keamanan tidak lagi berhenti pada pertanyaan “apakah seed phrase tersimpan aman?” Pengguna, wallet, auditor, dan aplikasi perlu memahami kode delegasi, cakupan izin, mekanisme pencabutan, serta kemungkinan tanda tangan dipakai ulang. Spesifikasi resmi [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) sendiri memuat pertimbangan keamanan seperti delegation designation, akses storage, dan risiko rantai otorisasi.
Artikel ini membedah mekanisme tersebut secara teknis tetapi praktis: apa yang berubah, apa yang tidak berubah, manfaat yang realistis, permukaan serangan baru, dan standar implementasi yang seharusnya dituntut. Fokusnya adalah infrastruktur dan keamanan, bukan promosi token atau nasihat investasi.
## Daftar Isi
- [01 — Dari EOA Sederhana ke Akun yang Dapat Diprogram](#bagian-01)
- [02 — Cara Kerja Delegasi EIP-7702](#bagian-02)
- [03 — Manfaat Nyata bagi Pengguna dan Aplikasi](#bagian-03)
- [04 — Risiko Keamanan yang Bergeser](#bagian-04)
- [05 — Checklist Implementasi yang Bertanggung Jawab](#bagian-05)
- [Kesimpulan](#kesimpulan-artikel)
- [Sumber](#sumber-artikel)
<a id="bagian-01"></a>
## 01 — Dari EOA Sederhana ke Akun yang Dapat Diprogram
Ethereum membedakan EOA yang dikendalikan private key dan contract account yang perilakunya ditentukan kode. Dokumentasi [Ethereum tentang akun](https://ethereum.org/en/developers/docs/accounts/) menjelaskan bahwa EOA dapat memulai transaksi, sedangkan contract account bereaksi sesuai logika kontraknya. Account abstraction berusaha memperkecil jurang tersebut: akun pengguna tetap mudah dikenali oleh ekosistem, tetapi memperoleh kemampuan seperti aturan otorisasi, pemulihan, batching, atau pembayaran gas yang lebih fleksibel. EIP-7702 tidak menghapus private key dan tidak otomatis membuat setiap akun aman; ia menyediakan primitif agar sebuah EOA dapat menunjuk kode yang mengeksekusi perilaku tambahan.
> **Highlight:** EIP-7702 bukan “password reset untuk blockchain”; ia adalah fondasi delegasi kode yang baru berguna bila wallet menyajikan izin secara jelas dan implementasinya diaudit.
<a id="bagian-02"></a>
## 02 — Cara Kerja Delegasi EIP-7702
Secara ringkas, EIP-7702 memperkenalkan tipe transaksi dengan daftar otorisasi. Otorisasi yang valid membuat kode akun EOA berisi penunjuk ke alamat implementasi tertentu; ketika akun dipanggil, logika pada alamat delegasi itu dijalankan dalam konteks akun pengguna. Desain ini memungkinkan kompatibilitas dengan aset dan identitas alamat lama, tetapi storage tetap perlu diperlakukan hati-hati karena implementasi berbeda dapat membaca atau menulis slot yang sama. Spesifikasi juga menerangkan bahwa delegasi dapat diganti atau dikosongkan melalui otorisasi berikutnya, sehingga pencabutan adalah bagian penting dari siklus hidup, bukan fitur tambahan.
| Lapisan | Sebelum delegasi | Setelah delegasi EIP-7702 | Kontrol yang diperlukan |
|---|---|---|---|
| Otorisasi | Satu private key menandatangani transaksi | Key mengotorisasi kode delegasi | Tampilkan target, chain, nonce, dan masa berlaku |
| Eksekusi | EOA memulai panggilan biasa | Kode delegasi menjalankan kebijakan akun | Audit implementasi dan batasi fungsi |
| Gas | Umumnya dibayar pengirim | Dapat didesain untuk sponsor atau pembayaran alternatif | Kuota, rate limit, dan proteksi penyalahgunaan |
| Pemulihan | Bergantung pada backup key | Bisa ditambah guardian atau multi-factor | Delay, threshold, dan proses pembatalan |
| Pencabutan | Rotasi akun biasanya rumit | Delegasi dapat diganti/dihapus | Tombol revoke yang mudah ditemukan |
<a id="bagian-03"></a>
## 03 — Manfaat Nyata bagi Pengguna dan Aplikasi
Manfaat paling mudah dirasakan adalah batching: approval dan aksi utama dapat dirangkai sehingga pengguna tidak melewati beberapa dialog terpisah. Aplikasi juga dapat mensponsori gas untuk onboarding, sementara wallet dapat menerapkan session key dengan batas waktu atau ruang lingkup tertentu. Halaman resmi [roadmap account abstraction Ethereum](https://ethereum.org/en/roadmap/account-abstraction/) menempatkan tujuan ini dalam agenda yang lebih luas: mengurangi ketergantungan pada satu kredensial, mendukung pemulihan sosial, dan membuat interaksi wallet lebih aman serta sederhana. Semua manfaat tersebut tetap bergantung pada implementasi; protokol menyediakan kemampuan, sedangkan produk menentukan apakah pengguna memahami konsekuensinya.
- **Batching:** beberapa operasi terkait menjadi satu alur yang dapat diprediksi.
- **Gas sponsorship:** layanan dapat menanggung biaya untuk tindakan yang dibatasi.
- **Session key:** akses sementara hanya untuk fungsi, nilai, atau periode tertentu.
- **Kebijakan berlapis:** transaksi bernilai besar dapat memerlukan faktor atau penandatangan tambahan.
- **Pemulihan:** guardian dan masa tunggu dapat menggantikan pola “kehilangan seed berarti selesai”.
<a id="bagian-04"></a>
## 04 — Risiko Keamanan yang Bergeser
Permukaan serangan berpindah dari key tunggal menuju kombinasi key, antarmuka persetujuan, kode delegasi, dan storage akun. Tanda tangan yang membolehkan delegasi berbahaya dapat memberi penyerang kemampuan persisten; implementasi yang dapat di-upgrade menambah risiko administrator; konflik layout storage dapat merusak keadaan akun; dan sponsor gas dapat menjadi sasaran spam. Karena kode berjalan dalam konteks akun, audit harus memeriksa bukan hanya fungsi yang terlihat, tetapi juga jalur `delegatecall`, validasi replay lintas chain, nonce, serta perilaku saat implementasi berubah atau tidak tersedia. Sinyal komunikasi dari [akun resmi Ethereum di X](https://x.com/ethereum) berguna untuk mengikuti pengumuman ekosistem, tetapi klaim teknis dalam artikel ini diverifikasi terhadap dokumentasi Ethereum dan spesifikasi EIP, bukan mengandalkan unggahan sosial.
**Model ancaman minimum:**
1. Pengguna menandatangani otorisasi tanpa memahami alamat implementasi.
2. Front-end atau wallet menampilkan ringkasan yang tidak lengkap.
3. Kode delegasi memiliki bug, jalur upgrade berbahaya, atau dependency rapuh.
4. Izin sementara ternyata tidak memiliki batas nilai, fungsi, chain, atau waktu.
5. Proses revoke gagal ketika layanan utama sedang tidak tersedia.
<a id="bagian-05"></a>
## 05 — Checklist Implementasi yang Bertanggung Jawab
Wallet sebaiknya memperlakukan otorisasi delegasi seperti perubahan kontrol akun, bukan transaksi rutin. Dialog harus menampilkan identitas implementasi, chain, nonce, fungsi yang diizinkan, batas pengeluaran, waktu kedaluwarsa, dan cara mencabut izin. Pengembang perlu mempublikasikan kode terverifikasi, laporan audit, mekanisme upgrade, serta prosedur insiden. Pengguna tetap perlu menguji dengan nilai kecil, menolak permintaan yang tidak dipahami, dan memeriksa izin aktif secara berkala. Tidak ada label “smart account” yang menggantikan verifikasi independen.
- [ ] Implementasi memiliki source code terverifikasi dan audit yang relevan.
- [ ] Delegasi terikat pada chain dan nonce yang benar untuk mencegah replay.
- [ ] Session key dibatasi fungsi, nilai, tujuan, dan waktu.
- [ ] Upgrade memakai delay serta pemberitahuan yang dapat diawasi.
- [ ] Revoke dapat dilakukan tanpa bergantung pada satu front-end.
- [ ] Sponsor gas memiliki kuota dan perlindungan denial-of-service.
- [ ] Wallet mensimulasikan hasil transaksi sebelum meminta tanda tangan.
- [ ] Dokumentasi menjelaskan skenario kehilangan key dan kompromi guardian.
<a id="kesimpulan-artikel"></a>
## Kesimpulan
EIP-7702 membuat account abstraction lebih dekat dengan akun Ethereum yang sudah digunakan, sehingga peningkatan pengalaman tidak selalu menuntut migrasi alamat. Nilai utamanya ada pada kebijakan yang dapat diprogram: batching, sponsorship, session key, dan pemulihan. Pada saat yang sama, kepercayaan bergeser ke kode delegasi dan cara wallet menjelaskan izin. Tolok ukur keberhasilan bukan banyaknya fitur, melainkan apakah pengguna dapat memahami, membatasi, mengaudit, dan mencabut kewenangan tersebut tanpa gesekan yang berbahaya.
<a id="sumber-artikel"></a>
## Sumber
1. [Ethereum Improvement Proposals — EIP-7702: Set Code for EOAs](https://eips.ethereum.org/EIPS/eip-7702) — spesifikasi mekanisme, format otorisasi, dan pertimbangan keamanan.
2. [Ethereum.org — Account Abstraction Roadmap](https://ethereum.org/en/roadmap/account-abstraction/) — tujuan UX, pemulihan, dan arah pengembangan akun pintar.
3. [Ethereum.org — Ethereum Accounts](https://ethereum.org/en/developers/docs/accounts/) — perbedaan dasar EOA dan contract account.
4. [Ethereum (@ethereum) di X](https://x.com/ethereum) — sinyal komunikasi resmi; detail teknis diverifikasi melalui tiga sumber primer di atas.
Tags: #Ethereum#EIP-7702#account abstraction#smart account#wallet security#blockchain infrastructure
GD
Tentang Penulis — Ganes Satsangga
Backend Developer berpengalaman membangun aplikasi web, sistem ERP/CMS, integrasi API, dan database menggunakan Laravel, PHP, dan Go.
