Account Abstraction (AA) adalah arah penting dari eksplorasi jangka panjang dalam ekosistem Ethereum, yang bertujuan untuk mendobrak batas antara akun eksternal (EOA) dan akun kontrak, sehingga dompet memiliki kemampuan program, keamanan, dan peningkatan yang lebih kuat. EIP-4337, sebagai solusi implementasi AA yang paling utama, telah banyak digunakan di sejumlah dompet kontrak pintar berbasis EntryPoint (seperti Safe, Stacks, dan Argent). Namun, EIP-4337 masih memiliki keterbatasan tertentu dalam hal keaslian on-chain, kompleksitas operasional, dan kompatibilitas ekologis karena diperkenalkannya kumpulan transaksi independen dan mekanisme kontrak on-ramp.
Untuk lebih lanjut menurunkan ambang penggunaan abstraksi akun dan meningkatkan dukungan keaslian, Vitalik mengusulkan EIP-7702 pada tahun 2024 dan mengintegrasikan proposal tersebut dalam pembaruan Pectra. Inti dari EIP-7702 adalah: memungkinkan EOA asli untuk mengeksekusi kode kontrak (contract_code) dari alamat tertentu saat memulai transaksi, dengan kode ini mendefinisikan logika pelaksanaan transaksi tersebut.
EIP-7702 memperkenalkan mekanisme baru "injeksi kode tingkat transaksi", yang memungkinkan akun pengguna untuk secara dinamis menentukan logika eksekusi di setiap transaksi, daripada mengandalkan kode kontrak yang telah disebarkan sebelumnya. Ini merusak model izin berbasis kode statis tradisional, membawa fleksibilitas yang lebih besar, dan memperkenalkan tantangan keamanan baru: kontrak yang mengandalkan logika penilaian seperti isContract dan extcodehash mungkin menjadi tidak valid, dan beberapa sistem yang mengasumsikan bahwa pemanggil adalah EOA murni dapat dilewati. Bagi auditor, penting tidak hanya untuk memverifikasi keamanan kode yang disuntikkan itu sendiri, tetapi juga untuk menilai potensi dampaknya pada sistem kontrak lain dalam konteks dinamis.
Artikel ini akan mengulas prinsip desain dan fitur kunci dari EIP-7702 oleh tim keamanan Beosin, secara sistematis mengidentifikasi risiko keamanan yang mungkin dihadapi oleh dompet AA yang dibangun berdasarkan EIP-7702 dalam proses audit, serta menyajikan proses audit dan saran dari perspektif praktis, untuk membantu peneliti keamanan menghadapi tantangan teknis baru dalam paradigma ini.
Satu, EIP-7702 Pengantar
Ringkasan Teknis EIP-7702
EIP-7702 memperkenalkan jenis transaksi baru 0x04 (SetCode), yang memungkinkan EOA untuk memberikan otorisasi kode kontrak yang perlu dieksekusi melalui transaksi ini, dengan struktur transaksi sebagai berikut:
Di mana authorization_list berisi beberapa daftar otorisasi, juga dapat mencakup tindakan otorisasi dari non-pelaksana transaksi, struktur internalnya adalah:
Di antaranya, chain_id menunjukkan rantai di mana otorisasi pengguna berlaku, yang mengharuskan nilainya sama dengan ID rantai dari rantai yang dieksekusi atau 0. Ketika chain_id adalah 0, itu berarti otorisasi berlaku untuk semua rantai EVM yang mendukung EIP-7702, dengan syarat bahwa parameter lain (seperti nonce) harus cocok. address menunjukkan alamat kontrak tujuan yang diotorisasi oleh pengguna.
Setelah otorisasi selesai, sistem akan mengubah field code pengguna yang diotorisasi menjadi 0xef0100 || address, di mana address adalah alamat kontrak yang diotorisasi. Jika ingin membatalkan otorisasi, cukup lakukan transaksi SetCode dengan mengatur address menjadi 0 address.
Keunggulan EIP7702
(1) Fleksibilitas dan Kustomisasi
Akun abstrak dapat disesuaikan fungsinya secara fleksibel sesuai kebutuhan dengan menulis logika akun dalam kontrak pintar. Misalnya, pengguna dapat mengonfigurasi tanda tangan ganda, pemulihan sosial, kontrol batas, dan lain-lain, untuk memenuhi kebutuhan berbagai skenario pribadi atau perusahaan. Desain ini secara signifikan meningkatkan kemampuan perluasan fungsi akun, melampaui batasan akun eksternal tradisional (EOA).
(2) Meningkatkan Keamanan
Akun abstrak menyediakan mekanisme keamanan bertingkat, termasuk autentikasi multi, batas transaksi, dan pemulihan sosial. Bahkan jika pengguna kehilangan kunci pribadi, mereka dapat memulihkan akun melalui kontak terpercaya atau verifikasi ganda, menghindari kerugian aset permanen yang disebabkan oleh kehilangan kunci pribadi pada akun tradisional. Sementara itu, fitur seperti kontrol batas juga dapat mencegah pencurian dana besar secara jahat.
(3) Gas optimasi
Akun abstrak mendukung mekanisme abstraksi Gas yang fleksibel, memungkinkan pengguna untuk membayar Gas melalui pihak ketiga, bahkan langsung menggunakan token lain untuk membayar biaya transaksi. Mekanisme ini tidak hanya mengurangi biaya operasional pengguna, tetapi juga lebih lanjut menyederhanakan proses penggunaan blockchain, terutama cocok untuk pengguna pemula atau skenario transaksi multi-langkah yang kompleks.
(4) Mendorong penyebaran Web3
Dengan mengoptimalkan pengalaman dan keamanan, akun abstrak menyembunyikan kompleksitas blockchain di tempat yang tidak terlihat oleh pengguna, memberikan operasi yang lebih nyaman mendekati Web2. Desain ini mengurangi biaya pembelajaran bagi pengguna biasa, memungkinkan lebih banyak orang untuk berpartisipasi dalam aplikasi Web3 tanpa hambatan, mendorong penyebaran teknologi desentralisasi.
II. Analisis Risiko Keamanan dalam Praktik EIP-7702
Meskipun EIP-7702 telah memberikan dorongan baru bagi ekosistem Ethereum dan memperluas beragam skenario aplikasi, pada saat yang sama, ia juga tak terelakkan memperkenalkan beberapa risiko keamanan baru:
Serangan Replaying Terotorisasi
Dalam model EIP-7702, jika pengguna mengatur field chain_id dalam otorisasi menjadi 0, itu berarti otorisasi tersebut berlaku di beberapa rantai. Desain "otorisasi lintas rantai yang umum" ini, meskipun meningkatkan fleksibilitas dalam beberapa skenario, juga membawa risiko keamanan yang signifikan.
Perlu diperhatikan bahwa meskipun identifikasi akun pada alamat yang sama di berbagai rantai adalah sama, implementasi kontrak di belakangnya mungkin sangat berbeda. Ini berarti bahwa penyerang dapat menerapkan versi jahat dari kontrak di rantai lain, memanfaatkan tindakan otorisasi dari alamat yang sama di rantai tersebut untuk melakukan operasi yang tidak diharapkan, sehingga menimbulkan risiko terhadap aset pengguna.
Oleh karena itu, bagi penyedia layanan dompet atau platform interaksi frontend, saat pengguna melakukan operasi otorisasi semacam ini, harus jelas memverifikasi apakah chainId yang dinyatakan dalam otorisasi pengguna konsisten dengan jaringan yang terhubung saat ini; jika terdeteksi bahwa pengguna mengatur chainId ke 0, harus diberikan peringatan risiko yang jelas, mengingatkan pengguna bahwa otorisasi ini akan berlaku di semua rantai yang kompatibel EVM dan dapat disalahgunakan oleh kontrak jahat.
Selain itu, penyedia layanan juga harus mengevaluasi apakah pada lapisan UI secara default membatasi atau melarang chainId yang bernilai 0 untuk mengurangi risiko kesalahan operasional atau serangan phishing.
Masalah kompatibilitas kontrak
(1) Kompatibilitas Callback Kontrak
Kontrak token seperti ERC-721, ERC-777, dan ERC-1155 saat mentransfer ke alamat kontrak akan memanggil antarmuka callback standar (seperti onERC721Received, tokensReceived) untuk menyelesaikan operasi transfer. Jika alamat penerima tidak mengimplementasikan antarmuka yang sesuai, transfer akan gagal bahkan dapat menyebabkan aset terkunci.
Dalam EIP-7702, alamat pengguna dapat diberikan kode kontrak melalui operasi "set_code", sehingga bertransformasi menjadi akun kontrak. Pada saat ini:
Alamat pengguna akan dianggap sebagai kontrak;
Jika kontrak tersebut tidak mengimplementasikan antarmuka callback yang diperlukan, akan menyebabkan kegagalan transfer token;
Pengguna mungkin tidak dapat menerima token mainstream tanpa pengetahuan.
Oleh karena itu, pengembang harus memastikan bahwa kontrak tujuan yang didelegasikan oleh pengguna mengimplementasikan antarmuka callback yang relevan untuk memastikan kompatibilitas dengan token utama.
(2) Validasi "tx.origin" tidak berlaku
Dalam kontrak tradisional, "tx.origin" sering digunakan untuk menentukan apakah transaksi dimulai langsung oleh pengguna, digunakan untuk mencegah pemanggilan kontrak dan kontrol keamanan lainnya.
Namun dalam skenario EIP-7702:
Pengguna menandatangani transaksi otorisasi, yang sebenarnya disiarkan oleh perantara atau layanan bundling (bundler); saat transaksi dieksekusi, "tx.origin" adalah alamat perantara, bukan alamat pengguna.
"msg.sender" adalah kontrak dompet yang mewakili identitas pengguna.
Oleh karena itu, verifikasi izin berdasarkan "tx.origin == msg.sender" akan menyebabkan operasi pengguna yang sah ditolak dan kehilangan keandalan, dan panggilan kontrak terbatas yang sama seperti "tx.origin == user" juga akan dibatalkan. Disarankan untuk meninggalkan "tx.origin" sebagai dasar untuk penilaian keamanan dan menggunakan verifikasi tanda tangan atau mekanisme otorisasi sebagai gantinya.
(3) "isContract" salah penilaian
Banyak kontrak menggunakan 「isContract (address)」（memeriksa panjang kode alamat）untuk mencegah akun kontrak terlibat dalam beberapa operasi, seperti airdrop, pembelian terburu-buru, dll:
Di bawah mekanisme EIP-7702, alamat pengguna dapat berubah menjadi akun kontrak melalui transaksi "set_code", "isContract" mengembalikan true, kontrak akan salah menilai pengguna yang sah sebagai akun kontrak, menolak partisipasinya dalam operasi, menyebabkan pengguna tidak dapat menggunakan layanan tertentu, dan pengalaman mereka terhambat.
Dengan semakin populernya dompet kontrak, desain yang bergantung pada "isContract" untuk menentukan "apakah itu pengguna manusia" tidak lagi aman, disarankan untuk menggunakan metode identifikasi pengguna yang lebih akurat seperti verifikasi tanda tangan.
Serangan Phishing
Setelah menerapkan mekanisme delegasi EIP-7702, aset dalam akun pengguna akan sepenuhnya dikendalikan oleh kontrak pintar yang didelegasikan. Begitu pengguna memberikan izin kepada kontrak jahat, penyerang dapat memperoleh kontrol penuh atas aset akun, yang dapat menyebabkan dana dipindahkan atau dicuri dengan cepat, sehingga risiko keamanannya sangat tinggi.
Oleh karena itu, penting bagi penyedia layanan dompet untuk mendukung resolusi transaksi EIP-7702 dan mekanisme identifikasi risiko sesegera mungkin. Ketika pengguna menandatangani transaksi titipan, front-end harus dengan jelas dan mencolok menampilkan alamat kontrak target, dan menggabungkan informasi pendukung seperti sumber kontrak dan informasi penerapan untuk membantu pengguna mengidentifikasi potensi phishing atau perilaku penipuan, sehingga mengurangi risiko kesalahan penandatanganan. Selanjutnya, layanan dompet harus mengintegrasikan kemampuan analisis keamanan otomatis untuk kontrak target, seperti pemeriksaan status open source kode kontrak, analisis model izin, dan identifikasi operasi yang berpotensi berbahaya, untuk membantu pengguna membuat penilaian yang lebih aman sebelum otorisasi.
Hal yang perlu diperhatikan adalah bahwa format tanda tangan delegasi yang diperkenalkan oleh EIP-7702 tidak kompatibel dengan standar tanda tangan EIP-191 dan EIP-712 yang ada. Tanda tangannya sangat mudah untuk menghindari peringatan tanda tangan dan pengingat interaksi yang ada di dompet, yang lebih lanjut meningkatkan risiko pengguna terjebak untuk menandatangani tindakan jahat. Oleh karena itu, pengenalan dan mekanisme penanganan untuk struktur tanda tangan ini dalam implementasi dompet akan menjadi langkah kunci dalam menjaga keamanan pengguna.
Risiko Kontrak Dompet
(1) Manajemen Hak Kontrak Dompet
Banyak kontrak dompet EIP-7702 menggunakan arsitektur proxy ( atau memiliki izin manajemen bawaan ) untuk mendukung peningkatan logika. Namun, ini juga membawa risiko manajemen izin yang lebih tinggi. Jika izin peningkatan tidak dibatasi secara ketat, penyerang dapat mengganti kontrak implementasi dan menyuntikkan kode berbahaya, yang dapat mengakibatkan modifikasi akun pengguna atau pencurian dana.
Saran Keamanan:
Menggunakan tanda tangan ganda, autentikasi multi faktor, atau mekanisme kunci waktu untuk mengontrol hak akses upgrade.
Perubahan kode dan izin harus melalui audit ketat dan verifikasi keamanan.
Proses peningkatan yang terbuka dan transparan, menjamin hak pengguna untuk mengetahui dan berpartisipasi.
(2) Risiko konflik penyimpanan dan isolasi data
Versi kontrak dompet atau penyedia layanan dompet yang berbeda mungkin menggunakan slot penyimpanan yang sama. Jika pengguna mengganti penyedia layanan dompet atau memperbarui logika dompet, penggunaan ulang slot penyimpanan dapat menyebabkan konflik variabel status, menghasilkan masalah seperti penimpaan data dan pembacaan yang tidak normal. Ini tidak hanya dapat merusak fungsi normal dompet, tetapi juga dapat menyebabkan kehilangan dana atau anomali hak akses.
Saran Keamanan:
Menggunakan solusi pemisahan penyimpanan khusus (seperti standar EIP-1967) atau memanfaatkan ruang nama unik untuk mengelola slot penyimpanan.
Saat mengupgrade kontrak, pastikan tata letak penyimpanan kompatibel dan hindari tumpang tindih variabel.
Menguji secara ketat kewajaran status penyimpanan dalam proses upgrade.
(3) Pengelolaan nonce di dalam dompet
Kontrak dompet biasanya mengatur nonce secara internal dan mengelolanya sendiri, untuk memastikan urutan eksekusi operasi pengguna dan mencegah serangan replay. Jika nonce digunakan secara tidak tepat, hal itu akan menyebabkan operasi pengguna tidak dapat dieksekusi dengan normal.
Saran Keamanan:
nonce harus diperiksa dengan ketat sama (atau meningkat), tidak boleh dilewati.
Fungsi dilarang mengubah nonce secara langsung, nonce hanya akan diperbarui saat tindakan pengguna dilakukan.
Merancang mekanisme toleransi kesalahan dan pemulihan untuk situasi abnormal nonce, menghindari deadlock nonce.
(4) pemeriksaan izin pemanggil fungsi
Untuk memastikan keamanan, kontrak dompet harus memastikan bahwa pemanggil fungsi kunci adalah akun pemilik dompet. Dua cara yang umum digunakan termasuk:
Otorisasi tanda tangan di luar rantai
Pengguna menandatangani serangkaian operasi dengan kunci privat, kontrak dompet memverifikasi di blockchain apakah tanda tangan tersebut sah, tidak kedaluwarsa, dan memenuhi nonce yang sesuai. Cara ini cocok untuk model transaksi perantara yang dianjurkan oleh EIP-7702 (tanda tangan offline pengguna + perantara mengirimkan transaksi).
Fungsi operasi pengguna hanya diizinkan untuk dipanggil oleh kontrak itu sendiri, pada dasarnya merupakan mekanisme kontrol jalur pemanggilan, memastikan bahwa pemula eksternal harus merupakan akun itu sendiri. Ini pada dasarnya setara dengan mensyaratkan bahwa pemanggil adalah EOA asli, karena saat ini alamat kontrak adalah alamat EOA.
Tiga, Perspektif: EIP-7702 dan Standar Dompet AA di Masa Depan
Pengenalan EIP-7702 tidak hanya merupakan inovasi terhadap model akun tradisional, tetapi juga merupakan dorongan besar bagi ekosistem abstraksi akun (Account Abstraction). Kemampuan yang diperkenalkan untuk memuat kode kontrak oleh pengguna memberikan ruang eksplorasi yang luas untuk desain dompet dan sistem kontrak di masa depan, serta mengajukan tuntutan baru terhadap standar audit keamanan.
Evolusi bersama dengan EIP-4337: Menuju kompatibilitas mode ganda
Meskipun EIP-7702 dan EIP-4337 memiliki tujuan desain yang berbeda, yang pertama merekonstruksi mekanisme pemuatan kode akun, sementara yang kedua membangun pintu masuk transaksi yang lengkap dan ekosistem peng打包. Namun, keduanya tidak bertentangan, melainkan memiliki komplementaritas yang kuat:
EIP-4337 menyediakan "Saluran Transaksi Umum" dan "Antarmuka Eksekusi Akun Abstrak";
EIP-7702 memungkinkan akun pengguna untuk secara dinamis memberikan kemampuan logika kontrak tanpa mengubah alamat.
Oleh karena itu, dompet di masa depan mungkin akan mengadopsi "arsitektur dukungan ganda": menggunakan EIP-7702 sebagai alternatif ringan di rantai yang tidak mendukung EIP-4337, sementara terus bergantung pada tumpukan protokol lengkap EIP-4337 dalam skenario yang memerlukan pengemasan off-chain dan agregasi pengguna multi.
Mekanisme dual-mode ini juga akan mendorong dompet untuk mendukung model izin akun yang lebih fleksibel, mekanisme penurunan, dan skema rollback di tingkat kernel.
Dukungan dan inspirasi untuk logika dompet baru seperti MPC dan ZK
Mekanisme kontrak akun yang diusulkan oleh EIP-7702 memiliki potensi integrasi yang alami dengan arsitektur baru seperti dompet MPC, dompet ZK, dan dompet modular yang sedang populer saat ini:
Dalam mode MPC, perilaku penandatanganan tidak lagi bergantung pada satu kunci pribadi, melainkan keputusan kolaboratif dari beberapa pihak. Tanda tangan yang dihasilkan melalui penggabungan EIP-7702 dan MPC dapat mengontrol logika kontrak yang dimuat secara dinamis, sehingga memungkinkan strategi eksekusi yang lebih fleksibel.
Dompet ZK memverifikasi identitas atau otorisasi pengguna melalui bukti nol pengetahuan, tanpa perlu mengekspos informasi kunci pribadi. Setelah menggabungkan EIP-7702, dompet ZK dapat menyuntikkan kontrak logika tertentu secara temporer setelah verifikasi selesai, sehingga memungkinkan penempatan perilaku yang dipersonalisasi setelah perhitungan privasi, seperti hanya mengeksekusi logika tertentu secara otomatis setelah memenuhi kondisi privasi tertentu.
Dompet Modular (Modular Wallets) dapat memanfaatkan EIP-7702 untuk membongkar logika akun menjadi beberapa modul, yang dapat dimuat secara dinamis saat diperlukan.
Oleh karena itu, EIP-7702 menyediakan "wadah eksekusi" yang lebih asli untuk dompet canggih yang disebutkan di atas: logika kontrak yang berbeda dapat disuntikkan dengan alamat pengguna yang sama, menghindari masalah ketergantungan alamat dalam proses penerapan kontrak tradisional, dan tidak perlu pra-penyebaran, sangat meningkatkan fleksibilitas dan kemampuan kombinasi perilaku akun.
Inspirasi untuk Pengembang Kontrak dan Auditor
EIP-7702 akan mendorong perubahan mendalam dalam paradigma pengembangan. Pengembang kontrak tidak lagi hanya melihat pemanggil sebagai EOA tradisional atau akun kontrak tetap, tetapi harus menyesuaikan diri dengan mekanisme baru yang sepenuhnya: identitas pemanggil dapat beralih secara dinamis antara EOA dan status kontrak selama proses transaksi, logika perilaku akun tidak lagi terikat secara statis, tetapi dapat berubah secara fleksibel sesuai kebutuhan. Ini mengharuskan pengembang dan auditor untuk memiliki:
Memperkenalkan logika verifikasi caller dan penilaian hak akses yang lebih ketat;
Periksa apakah jalur pemanggilan dipengaruhi oleh logika kontrak dinamis;
Identifikasi potensi kerentanan perilaku seperti msg.sender.code.length == 0, isContract () dan lainnya;
Jelaskan logika kontrak "ketergantungan konteks", seperti pemanggilan statis, kontrol batas deleGatecall;
Mendukung simulasi dan analisis pemulihan untuk skenario setCode di tingkat rantai alat.
Dengan kata lain, keamanan kode tidak lagi hanya merupakan "masalah sebelum penerapan", tetapi telah berubah menjadi "proses dinamis yang juga harus diverifikasi selama pemanggilan dan transaksi."
Empat, Kesimpulan
EIP-7702 memperkenalkan cara yang lebih ringan, asli, dan fleksibel untuk abstraksi akun (AA), memungkinkan EOA biasa untuk membawa logika kontrak dan mengeksekusinya dalam satu transaksi. Mekanisme ini memecahkan asumsi statis tradisional tentang perilaku akun, sehingga pengembang tidak lagi dapat dengan mudah bergantung pada status kode alamat akun untuk menilai model perilakunya, tetapi perlu membangun kembali pemahaman tentang identitas dan batas kewenangan pemanggil. Disertai dengan itu adalah perubahan paradigma analisis keamanan. Fokus audit tidak lagi terbatas pada "apakah alamat tertentu memiliki izin", tetapi beralih ke "apa yang dapat dilakukan logika kontrak yang dibawa dalam transaksi dalam konteks saat ini". Setiap transaksi dapat memuat definisi perilaku yang independen, yang memberikan akun fungsi yang lebih kuat sekaligus meningkatkan tuntutan terhadap audit keamanan.
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
Beosin: Analisis audit keamanan EIP-7702 dan dompet AA generasi berikutnya
Ditulis oleh: Beosin
Account Abstraction (AA) adalah arah penting dari eksplorasi jangka panjang dalam ekosistem Ethereum, yang bertujuan untuk mendobrak batas antara akun eksternal (EOA) dan akun kontrak, sehingga dompet memiliki kemampuan program, keamanan, dan peningkatan yang lebih kuat. EIP-4337, sebagai solusi implementasi AA yang paling utama, telah banyak digunakan di sejumlah dompet kontrak pintar berbasis EntryPoint (seperti Safe, Stacks, dan Argent). Namun, EIP-4337 masih memiliki keterbatasan tertentu dalam hal keaslian on-chain, kompleksitas operasional, dan kompatibilitas ekologis karena diperkenalkannya kumpulan transaksi independen dan mekanisme kontrak on-ramp.
Untuk lebih lanjut menurunkan ambang penggunaan abstraksi akun dan meningkatkan dukungan keaslian, Vitalik mengusulkan EIP-7702 pada tahun 2024 dan mengintegrasikan proposal tersebut dalam pembaruan Pectra. Inti dari EIP-7702 adalah: memungkinkan EOA asli untuk mengeksekusi kode kontrak (contract_code) dari alamat tertentu saat memulai transaksi, dengan kode ini mendefinisikan logika pelaksanaan transaksi tersebut.
EIP-7702 memperkenalkan mekanisme baru "injeksi kode tingkat transaksi", yang memungkinkan akun pengguna untuk secara dinamis menentukan logika eksekusi di setiap transaksi, daripada mengandalkan kode kontrak yang telah disebarkan sebelumnya. Ini merusak model izin berbasis kode statis tradisional, membawa fleksibilitas yang lebih besar, dan memperkenalkan tantangan keamanan baru: kontrak yang mengandalkan logika penilaian seperti isContract dan extcodehash mungkin menjadi tidak valid, dan beberapa sistem yang mengasumsikan bahwa pemanggil adalah EOA murni dapat dilewati. Bagi auditor, penting tidak hanya untuk memverifikasi keamanan kode yang disuntikkan itu sendiri, tetapi juga untuk menilai potensi dampaknya pada sistem kontrak lain dalam konteks dinamis.
Artikel ini akan mengulas prinsip desain dan fitur kunci dari EIP-7702 oleh tim keamanan Beosin, secara sistematis mengidentifikasi risiko keamanan yang mungkin dihadapi oleh dompet AA yang dibangun berdasarkan EIP-7702 dalam proses audit, serta menyajikan proses audit dan saran dari perspektif praktis, untuk membantu peneliti keamanan menghadapi tantangan teknis baru dalam paradigma ini.
Satu, EIP-7702 Pengantar
EIP-7702 memperkenalkan jenis transaksi baru 0x04 (SetCode), yang memungkinkan EOA untuk memberikan otorisasi kode kontrak yang perlu dieksekusi melalui transaksi ini, dengan struktur transaksi sebagai berikut:
Di mana authorization_list berisi beberapa daftar otorisasi, juga dapat mencakup tindakan otorisasi dari non-pelaksana transaksi, struktur internalnya adalah:
Di antaranya, chain_id menunjukkan rantai di mana otorisasi pengguna berlaku, yang mengharuskan nilainya sama dengan ID rantai dari rantai yang dieksekusi atau 0. Ketika chain_id adalah 0, itu berarti otorisasi berlaku untuk semua rantai EVM yang mendukung EIP-7702, dengan syarat bahwa parameter lain (seperti nonce) harus cocok. address menunjukkan alamat kontrak tujuan yang diotorisasi oleh pengguna.
Setelah otorisasi selesai, sistem akan mengubah field code pengguna yang diotorisasi menjadi 0xef0100 || address, di mana address adalah alamat kontrak yang diotorisasi. Jika ingin membatalkan otorisasi, cukup lakukan transaksi SetCode dengan mengatur address menjadi 0 address.
(1) Fleksibilitas dan Kustomisasi
Akun abstrak dapat disesuaikan fungsinya secara fleksibel sesuai kebutuhan dengan menulis logika akun dalam kontrak pintar. Misalnya, pengguna dapat mengonfigurasi tanda tangan ganda, pemulihan sosial, kontrol batas, dan lain-lain, untuk memenuhi kebutuhan berbagai skenario pribadi atau perusahaan. Desain ini secara signifikan meningkatkan kemampuan perluasan fungsi akun, melampaui batasan akun eksternal tradisional (EOA).
(2) Meningkatkan Keamanan
Akun abstrak menyediakan mekanisme keamanan bertingkat, termasuk autentikasi multi, batas transaksi, dan pemulihan sosial. Bahkan jika pengguna kehilangan kunci pribadi, mereka dapat memulihkan akun melalui kontak terpercaya atau verifikasi ganda, menghindari kerugian aset permanen yang disebabkan oleh kehilangan kunci pribadi pada akun tradisional. Sementara itu, fitur seperti kontrol batas juga dapat mencegah pencurian dana besar secara jahat.
(3) Gas optimasi
Akun abstrak mendukung mekanisme abstraksi Gas yang fleksibel, memungkinkan pengguna untuk membayar Gas melalui pihak ketiga, bahkan langsung menggunakan token lain untuk membayar biaya transaksi. Mekanisme ini tidak hanya mengurangi biaya operasional pengguna, tetapi juga lebih lanjut menyederhanakan proses penggunaan blockchain, terutama cocok untuk pengguna pemula atau skenario transaksi multi-langkah yang kompleks.
(4) Mendorong penyebaran Web3
Dengan mengoptimalkan pengalaman dan keamanan, akun abstrak menyembunyikan kompleksitas blockchain di tempat yang tidak terlihat oleh pengguna, memberikan operasi yang lebih nyaman mendekati Web2. Desain ini mengurangi biaya pembelajaran bagi pengguna biasa, memungkinkan lebih banyak orang untuk berpartisipasi dalam aplikasi Web3 tanpa hambatan, mendorong penyebaran teknologi desentralisasi.
II. Analisis Risiko Keamanan dalam Praktik EIP-7702
Meskipun EIP-7702 telah memberikan dorongan baru bagi ekosistem Ethereum dan memperluas beragam skenario aplikasi, pada saat yang sama, ia juga tak terelakkan memperkenalkan beberapa risiko keamanan baru:
Dalam model EIP-7702, jika pengguna mengatur field chain_id dalam otorisasi menjadi 0, itu berarti otorisasi tersebut berlaku di beberapa rantai. Desain "otorisasi lintas rantai yang umum" ini, meskipun meningkatkan fleksibilitas dalam beberapa skenario, juga membawa risiko keamanan yang signifikan.
Perlu diperhatikan bahwa meskipun identifikasi akun pada alamat yang sama di berbagai rantai adalah sama, implementasi kontrak di belakangnya mungkin sangat berbeda. Ini berarti bahwa penyerang dapat menerapkan versi jahat dari kontrak di rantai lain, memanfaatkan tindakan otorisasi dari alamat yang sama di rantai tersebut untuk melakukan operasi yang tidak diharapkan, sehingga menimbulkan risiko terhadap aset pengguna.
Oleh karena itu, bagi penyedia layanan dompet atau platform interaksi frontend, saat pengguna melakukan operasi otorisasi semacam ini, harus jelas memverifikasi apakah chainId yang dinyatakan dalam otorisasi pengguna konsisten dengan jaringan yang terhubung saat ini; jika terdeteksi bahwa pengguna mengatur chainId ke 0, harus diberikan peringatan risiko yang jelas, mengingatkan pengguna bahwa otorisasi ini akan berlaku di semua rantai yang kompatibel EVM dan dapat disalahgunakan oleh kontrak jahat.
Selain itu, penyedia layanan juga harus mengevaluasi apakah pada lapisan UI secara default membatasi atau melarang chainId yang bernilai 0 untuk mengurangi risiko kesalahan operasional atau serangan phishing.
(1) Kompatibilitas Callback Kontrak
Kontrak token seperti ERC-721, ERC-777, dan ERC-1155 saat mentransfer ke alamat kontrak akan memanggil antarmuka callback standar (seperti onERC721Received, tokensReceived) untuk menyelesaikan operasi transfer. Jika alamat penerima tidak mengimplementasikan antarmuka yang sesuai, transfer akan gagal bahkan dapat menyebabkan aset terkunci.
Dalam EIP-7702, alamat pengguna dapat diberikan kode kontrak melalui operasi "set_code", sehingga bertransformasi menjadi akun kontrak. Pada saat ini:
Alamat pengguna akan dianggap sebagai kontrak;
Jika kontrak tersebut tidak mengimplementasikan antarmuka callback yang diperlukan, akan menyebabkan kegagalan transfer token;
Pengguna mungkin tidak dapat menerima token mainstream tanpa pengetahuan.
Oleh karena itu, pengembang harus memastikan bahwa kontrak tujuan yang didelegasikan oleh pengguna mengimplementasikan antarmuka callback yang relevan untuk memastikan kompatibilitas dengan token utama.
(2) Validasi "tx.origin" tidak berlaku
Dalam kontrak tradisional, "tx.origin" sering digunakan untuk menentukan apakah transaksi dimulai langsung oleh pengguna, digunakan untuk mencegah pemanggilan kontrak dan kontrol keamanan lainnya. Namun dalam skenario EIP-7702:
Pengguna menandatangani transaksi otorisasi, yang sebenarnya disiarkan oleh perantara atau layanan bundling (bundler); saat transaksi dieksekusi, "tx.origin" adalah alamat perantara, bukan alamat pengguna.
"msg.sender" adalah kontrak dompet yang mewakili identitas pengguna.
Oleh karena itu, verifikasi izin berdasarkan "tx.origin == msg.sender" akan menyebabkan operasi pengguna yang sah ditolak dan kehilangan keandalan, dan panggilan kontrak terbatas yang sama seperti "tx.origin == user" juga akan dibatalkan. Disarankan untuk meninggalkan "tx.origin" sebagai dasar untuk penilaian keamanan dan menggunakan verifikasi tanda tangan atau mekanisme otorisasi sebagai gantinya.
(3) "isContract" salah penilaian
Banyak kontrak menggunakan 「isContract (address)」（memeriksa panjang kode alamat）untuk mencegah akun kontrak terlibat dalam beberapa operasi, seperti airdrop, pembelian terburu-buru, dll:
Di bawah mekanisme EIP-7702, alamat pengguna dapat berubah menjadi akun kontrak melalui transaksi "set_code", "isContract" mengembalikan true, kontrak akan salah menilai pengguna yang sah sebagai akun kontrak, menolak partisipasinya dalam operasi, menyebabkan pengguna tidak dapat menggunakan layanan tertentu, dan pengalaman mereka terhambat. Dengan semakin populernya dompet kontrak, desain yang bergantung pada "isContract" untuk menentukan "apakah itu pengguna manusia" tidak lagi aman, disarankan untuk menggunakan metode identifikasi pengguna yang lebih akurat seperti verifikasi tanda tangan.
Setelah menerapkan mekanisme delegasi EIP-7702, aset dalam akun pengguna akan sepenuhnya dikendalikan oleh kontrak pintar yang didelegasikan. Begitu pengguna memberikan izin kepada kontrak jahat, penyerang dapat memperoleh kontrol penuh atas aset akun, yang dapat menyebabkan dana dipindahkan atau dicuri dengan cepat, sehingga risiko keamanannya sangat tinggi.
Oleh karena itu, penting bagi penyedia layanan dompet untuk mendukung resolusi transaksi EIP-7702 dan mekanisme identifikasi risiko sesegera mungkin. Ketika pengguna menandatangani transaksi titipan, front-end harus dengan jelas dan mencolok menampilkan alamat kontrak target, dan menggabungkan informasi pendukung seperti sumber kontrak dan informasi penerapan untuk membantu pengguna mengidentifikasi potensi phishing atau perilaku penipuan, sehingga mengurangi risiko kesalahan penandatanganan. Selanjutnya, layanan dompet harus mengintegrasikan kemampuan analisis keamanan otomatis untuk kontrak target, seperti pemeriksaan status open source kode kontrak, analisis model izin, dan identifikasi operasi yang berpotensi berbahaya, untuk membantu pengguna membuat penilaian yang lebih aman sebelum otorisasi.
Hal yang perlu diperhatikan adalah bahwa format tanda tangan delegasi yang diperkenalkan oleh EIP-7702 tidak kompatibel dengan standar tanda tangan EIP-191 dan EIP-712 yang ada. Tanda tangannya sangat mudah untuk menghindari peringatan tanda tangan dan pengingat interaksi yang ada di dompet, yang lebih lanjut meningkatkan risiko pengguna terjebak untuk menandatangani tindakan jahat. Oleh karena itu, pengenalan dan mekanisme penanganan untuk struktur tanda tangan ini dalam implementasi dompet akan menjadi langkah kunci dalam menjaga keamanan pengguna.
(1) Manajemen Hak Kontrak Dompet
Banyak kontrak dompet EIP-7702 menggunakan arsitektur proxy ( atau memiliki izin manajemen bawaan ) untuk mendukung peningkatan logika. Namun, ini juga membawa risiko manajemen izin yang lebih tinggi. Jika izin peningkatan tidak dibatasi secara ketat, penyerang dapat mengganti kontrak implementasi dan menyuntikkan kode berbahaya, yang dapat mengakibatkan modifikasi akun pengguna atau pencurian dana.
Saran Keamanan:
Menggunakan tanda tangan ganda, autentikasi multi faktor, atau mekanisme kunci waktu untuk mengontrol hak akses upgrade.
Perubahan kode dan izin harus melalui audit ketat dan verifikasi keamanan.
Proses peningkatan yang terbuka dan transparan, menjamin hak pengguna untuk mengetahui dan berpartisipasi.
(2) Risiko konflik penyimpanan dan isolasi data
Versi kontrak dompet atau penyedia layanan dompet yang berbeda mungkin menggunakan slot penyimpanan yang sama. Jika pengguna mengganti penyedia layanan dompet atau memperbarui logika dompet, penggunaan ulang slot penyimpanan dapat menyebabkan konflik variabel status, menghasilkan masalah seperti penimpaan data dan pembacaan yang tidak normal. Ini tidak hanya dapat merusak fungsi normal dompet, tetapi juga dapat menyebabkan kehilangan dana atau anomali hak akses.
Saran Keamanan:
Menggunakan solusi pemisahan penyimpanan khusus (seperti standar EIP-1967) atau memanfaatkan ruang nama unik untuk mengelola slot penyimpanan.
Saat mengupgrade kontrak, pastikan tata letak penyimpanan kompatibel dan hindari tumpang tindih variabel.
Menguji secara ketat kewajaran status penyimpanan dalam proses upgrade.
(3) Pengelolaan nonce di dalam dompet
Kontrak dompet biasanya mengatur nonce secara internal dan mengelolanya sendiri, untuk memastikan urutan eksekusi operasi pengguna dan mencegah serangan replay. Jika nonce digunakan secara tidak tepat, hal itu akan menyebabkan operasi pengguna tidak dapat dieksekusi dengan normal.
Saran Keamanan:
nonce harus diperiksa dengan ketat sama (atau meningkat), tidak boleh dilewati.
Fungsi dilarang mengubah nonce secara langsung, nonce hanya akan diperbarui saat tindakan pengguna dilakukan.
Merancang mekanisme toleransi kesalahan dan pemulihan untuk situasi abnormal nonce, menghindari deadlock nonce.
(4) pemeriksaan izin pemanggil fungsi
Untuk memastikan keamanan, kontrak dompet harus memastikan bahwa pemanggil fungsi kunci adalah akun pemilik dompet. Dua cara yang umum digunakan termasuk:
Otorisasi tanda tangan di luar rantai
Pengguna menandatangani serangkaian operasi dengan kunci privat, kontrak dompet memverifikasi di blockchain apakah tanda tangan tersebut sah, tidak kedaluwarsa, dan memenuhi nonce yang sesuai. Cara ini cocok untuk model transaksi perantara yang dianjurkan oleh EIP-7702 (tanda tangan offline pengguna + perantara mengirimkan transaksi).
Panggilan pembatasan (msg.sender == address (this))
Fungsi operasi pengguna hanya diizinkan untuk dipanggil oleh kontrak itu sendiri, pada dasarnya merupakan mekanisme kontrol jalur pemanggilan, memastikan bahwa pemula eksternal harus merupakan akun itu sendiri. Ini pada dasarnya setara dengan mensyaratkan bahwa pemanggil adalah EOA asli, karena saat ini alamat kontrak adalah alamat EOA.
Tiga, Perspektif: EIP-7702 dan Standar Dompet AA di Masa Depan
Pengenalan EIP-7702 tidak hanya merupakan inovasi terhadap model akun tradisional, tetapi juga merupakan dorongan besar bagi ekosistem abstraksi akun (Account Abstraction). Kemampuan yang diperkenalkan untuk memuat kode kontrak oleh pengguna memberikan ruang eksplorasi yang luas untuk desain dompet dan sistem kontrak di masa depan, serta mengajukan tuntutan baru terhadap standar audit keamanan.
Meskipun EIP-7702 dan EIP-4337 memiliki tujuan desain yang berbeda, yang pertama merekonstruksi mekanisme pemuatan kode akun, sementara yang kedua membangun pintu masuk transaksi yang lengkap dan ekosistem peng打包. Namun, keduanya tidak bertentangan, melainkan memiliki komplementaritas yang kuat:
EIP-4337 menyediakan "Saluran Transaksi Umum" dan "Antarmuka Eksekusi Akun Abstrak";
EIP-7702 memungkinkan akun pengguna untuk secara dinamis memberikan kemampuan logika kontrak tanpa mengubah alamat.
Oleh karena itu, dompet di masa depan mungkin akan mengadopsi "arsitektur dukungan ganda": menggunakan EIP-7702 sebagai alternatif ringan di rantai yang tidak mendukung EIP-4337, sementara terus bergantung pada tumpukan protokol lengkap EIP-4337 dalam skenario yang memerlukan pengemasan off-chain dan agregasi pengguna multi.
Mekanisme dual-mode ini juga akan mendorong dompet untuk mendukung model izin akun yang lebih fleksibel, mekanisme penurunan, dan skema rollback di tingkat kernel.
Mekanisme kontrak akun yang diusulkan oleh EIP-7702 memiliki potensi integrasi yang alami dengan arsitektur baru seperti dompet MPC, dompet ZK, dan dompet modular yang sedang populer saat ini:
Dalam mode MPC, perilaku penandatanganan tidak lagi bergantung pada satu kunci pribadi, melainkan keputusan kolaboratif dari beberapa pihak. Tanda tangan yang dihasilkan melalui penggabungan EIP-7702 dan MPC dapat mengontrol logika kontrak yang dimuat secara dinamis, sehingga memungkinkan strategi eksekusi yang lebih fleksibel.
Dompet ZK memverifikasi identitas atau otorisasi pengguna melalui bukti nol pengetahuan, tanpa perlu mengekspos informasi kunci pribadi. Setelah menggabungkan EIP-7702, dompet ZK dapat menyuntikkan kontrak logika tertentu secara temporer setelah verifikasi selesai, sehingga memungkinkan penempatan perilaku yang dipersonalisasi setelah perhitungan privasi, seperti hanya mengeksekusi logika tertentu secara otomatis setelah memenuhi kondisi privasi tertentu.
Dompet Modular (Modular Wallets) dapat memanfaatkan EIP-7702 untuk membongkar logika akun menjadi beberapa modul, yang dapat dimuat secara dinamis saat diperlukan.
Oleh karena itu, EIP-7702 menyediakan "wadah eksekusi" yang lebih asli untuk dompet canggih yang disebutkan di atas: logika kontrak yang berbeda dapat disuntikkan dengan alamat pengguna yang sama, menghindari masalah ketergantungan alamat dalam proses penerapan kontrak tradisional, dan tidak perlu pra-penyebaran, sangat meningkatkan fleksibilitas dan kemampuan kombinasi perilaku akun.
EIP-7702 akan mendorong perubahan mendalam dalam paradigma pengembangan. Pengembang kontrak tidak lagi hanya melihat pemanggil sebagai EOA tradisional atau akun kontrak tetap, tetapi harus menyesuaikan diri dengan mekanisme baru yang sepenuhnya: identitas pemanggil dapat beralih secara dinamis antara EOA dan status kontrak selama proses transaksi, logika perilaku akun tidak lagi terikat secara statis, tetapi dapat berubah secara fleksibel sesuai kebutuhan. Ini mengharuskan pengembang dan auditor untuk memiliki:
Memperkenalkan logika verifikasi caller dan penilaian hak akses yang lebih ketat;
Periksa apakah jalur pemanggilan dipengaruhi oleh logika kontrak dinamis;
Identifikasi potensi kerentanan perilaku seperti msg.sender.code.length == 0, isContract () dan lainnya;
Jelaskan logika kontrak "ketergantungan konteks", seperti pemanggilan statis, kontrol batas deleGatecall;
Mendukung simulasi dan analisis pemulihan untuk skenario setCode di tingkat rantai alat.
Dengan kata lain, keamanan kode tidak lagi hanya merupakan "masalah sebelum penerapan", tetapi telah berubah menjadi "proses dinamis yang juga harus diverifikasi selama pemanggilan dan transaksi."
Empat, Kesimpulan
EIP-7702 memperkenalkan cara yang lebih ringan, asli, dan fleksibel untuk abstraksi akun (AA), memungkinkan EOA biasa untuk membawa logika kontrak dan mengeksekusinya dalam satu transaksi. Mekanisme ini memecahkan asumsi statis tradisional tentang perilaku akun, sehingga pengembang tidak lagi dapat dengan mudah bergantung pada status kode alamat akun untuk menilai model perilakunya, tetapi perlu membangun kembali pemahaman tentang identitas dan batas kewenangan pemanggil. Disertai dengan itu adalah perubahan paradigma analisis keamanan. Fokus audit tidak lagi terbatas pada "apakah alamat tertentu memiliki izin", tetapi beralih ke "apa yang dapat dilakukan logika kontrak yang dibawa dalam transaksi dalam konteks saat ini". Setiap transaksi dapat memuat definisi perilaku yang independen, yang memberikan akun fungsi yang lebih kuat sekaligus meningkatkan tuntutan terhadap audit keamanan.