Beosin: EIP-7702 dan analisis audit keamanan dompet AA generasi berikutnya

Abstraksi Akun (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 pemrograman, keamanan, dan peningkatan yang lebih kuat. EIP-4337 saat ini merupakan solusi implementasi AA paling arus utama, dan 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 pengenalan kumpulan transaksi independen dan mekanisme kontrak on-ramp.

Untuk lebih menurunkan hambatan masuk dan meningkatkan dukungan asli untuk abstraksi akun, Vitalik mengusulkan EIP-7702 pada tahun 2024 dan memasukkannya ke dalam peningkatan Pestra. Ide inti EIP-7702 adalah untuk memungkinkan EOA asli untuk mengeksekusi kode kontrak (contract_code) dari alamat tertentu saat memulai transaksi, dan menggunakan kode ini untuk menentukan logika eksekusi transaksi.

EIP-7702 memperkenalkan mekanisme baru untuk "injeksi kode tingkat transaksi", yang memungkinkan akun pengguna untuk secara dinamis menentukan logika eksekusi dalam setiap transaksi, daripada mengandalkan kode kontrak yang telah diterapkan sebelumnya. Ini mematahkan model izin berbasis kode statis tradisional, menghadirkan 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 juga 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.

Dalam artikel ini, tim keamanan Beosin akan fokus pada prinsip desain dan fitur utama EIP-7702, secara sistematis memilah risiko keamanan yang mungkin dihadapi dompet AA yang dibangun berdasarkan dompet tersebut dalam audit, dan mengajukan proses audit dan saran dari perspektif praktis untuk membantu peneliti keamanan mengatasi tantangan teknis dengan lebih baik di bawah paradigma baru ini.

1. Pengantar EIP-77021

. Ikhtisar Teknis EIP-7702EIP-7702

memperkenalkan jenis transaksi baru, 0x 04 (SetCode), yang memungkinkan EOA untuk mengotorisasi kode kontrak yang perlu dieksekusi melalui transaksi ini, dengan struktur transaksi berikut:

1. rlp([chain_id, nonce, max_priority_fee_per_gas, max_ fee_per_gas, gas_limit,

2. tujuan, nilai, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

Jika authorization_list berisi beberapa daftar otorisasi, dan juga dapat berisi tindakan otorisasi pemrakarsa non-transaksi, struktur internalnya adalah:

1. authorization_list = [[chain_id, alamat, nonce, y_parity, r, s]].

di mana chain_id mewakili rantai di mana otorisasi pengguna berlaku, dan nilainya harus sama dengan ID rantai rantai eksekusi atau 0. Ketika chain_id adalah 0, otorisasi berlaku untuk semua rantai EVM yang mendukung EIP-7702, tetapi hanya jika parameter lain (seperti nonce) cocok. Alamat menunjukkan alamat kontrak target yang disahkan oleh pengguna.

Setelah otorisasi selesai, sistem akan mengubah bidang kode pengguna yang berwenang menjadi 0x ef 0100 || alamat, di mana alamat adalah alamat kontrak resmi. Jika Anda ingin membatalkan otorisasi, cukup mulai transaksi SetCode dengan alamat yang diatur ke 0.

2. Keuntungan dari EIP 7702

(1) Fleksibilitas & Kustomisasi

Akun AbstrakDengan menulis logika akun ke dalam kontrak pintar, Anda dapat secara fleksibel menyesuaikan fungsi sesuai dengan kebutuhan Anda. Misalnya, pengguna dapat mengonfigurasi multi-tanda tangan, pemulihan sosial, dan kontrol kuota untuk memenuhi kebutuhan individu atau perusahaan dalam skenario yang berbeda. Desain ini sangat meningkatkan skalabilitas fungsional akun dan menembus keterbatasan akun eksternal tradisional (EOA).

(2) Keamanan yang DitingkatkanAkun

Abstrak menyediakan mekanisme keamanan berlapis-lapis, termasuk autentikasi multi-faktor, batas transaksi, dan pemulihan sosial. Bahkan jika pengguna kehilangan kunci pribadinya, mereka dapat memulihkan akun mereka melalui kontak tepercaya atau autentikasi multi-faktor, menghindari hilangnya aset permanen yang disebabkan oleh hilangnya kunci pribadi di akun tradisional. Pada saat yang sama, fungsi seperti kontrol batas juga dapat mencegah sejumlah besar dana dicuri dengan jahat.

(3) Akun Abstraksi yang Dioptimalkan Gas

mendukung mekanisme abstraksi gas yang fleksibel, memungkinkan pengguna untuk membayar Gas melalui pihak ketiga, dan bahkan langsung menggunakan token lain untuk membayar biaya transaksi. Mekanisme ini tidak hanya mengurangi biaya operasi pengguna, tetapi juga semakin menyederhanakan penggunaan blockchain, terutama cocok untuk pengguna pemula atau skenario transaksi multi-langkah yang kompleks.

(4) Mempromosikan mempopulerkan Web3Dengan

mengoptimalkan pengalaman dan keamanan, akun abstrak menyembunyikan kompleksitas blockchain di tempat-tempat yang tidak dapat dilihat pengguna, memberikan operasi yang nyaman lebih dekat dengan Web2. Desain ini mengurangi biaya belajar pengguna biasa, memungkinkan lebih banyak orang untuk berpartisipasi dalam aplikasi Web3 tanpa hambatan, dan mempromosikan mempopulerkan teknologi terdesentralisasi.

2. Analisis Risiko Keamanan di EIP-7702 Dalam Praktiknya

Meskipun EIP-7702 telah menyuntikkan dorongan baru ke dalam ekosistem Ethereum dan memperluas banyak skenario aplikasi, pada saat yang sama, ia pasti memperkenalkan beberapa risiko keamanan baru:

1. Serangan pemutaran ulang otorisasi

Di bawah model EIP-7702, jika pengguna mengizinkan chain_ Jika bidang id diatur ke 0, otorisasi dapat diterapkan pada beberapa rantai. Meskipun desain "otorisasi universal lintas rantai" ini meningkatkan fleksibilitas dalam beberapa skenario, ini juga memperkenalkan risiko keamanan yang jelas.

Penting untuk dicatat bahwa meskipun identitas akun dari alamat yang sama sama pada rantai yang berbeda, implementasi kontrak di baliknya mungkin sama sekali berbeda. Ini berarti bahwa penyerang dapat menyebarkan versi berbahaya dari kontrak di rantai lain dan melakukan tindakan yang tidak diinginkan menggunakan otorisasi alamat yang sama di rantai, sehingga menimbulkan risiko terhadap aset pengguna.

Oleh karena itu, untuk penyedia layanan dompet atau platform interaksi front-end, ketika pengguna melakukan operasi otorisasi tersebut, mereka harus memverifikasi dengan jelas apakah chainId yang dinyatakan dalam otorisasi pengguna konsisten dengan jaringan koneksi saat ini; Jika pengguna terdeteksi mengatur chainId ke 0, peringatan risiko yang jelas harus diberikan untuk mengingatkan pengguna bahwa otorisasi akan berlaku pada semua rantai yang kompatibel dengan EVM dan dapat disalahgunakan oleh kontrak berbahaya.

Selain itu, penyedia layanan juga harus mengevaluasi apakah akan membatasi atau melarang otorisasi dengan chainId 0 secara default di lapisan UI untuk mengurangi risiko kesalahan pengoperasian atau serangan phishing.

2. Kompatibilitas Kontrak

1) Kompatibilitas Callback Kontrak

mentransfer uang ke alamat kontrak untuk kontrak token yang ada seperti ERC-721, ERC-777, dan ERC 1155, mereka akan memanggil antarmuka callback standar (seperti onERC 721 Received, tokensReceived) untuk menyelesaikan operasi transfer. Jika alamat penerima tidak mengimplementasikan antarmuka yang sesuai, transfer akan gagal atau bahkan menyebabkan aset terkunci.

Di EIP-7702, alamat pengguna dapat diubah menjadi akun kontrak dengan diberi kode kontrak melalui operasi "set_code". Dalam hal ini:

• Alamat pengguna dianggap sebagai kontrak;

• Jika kontrak tidak mengimplementasikan antarmuka callback yang diperlukan, transfer token akan gagal;

• Pengguna mungkin tidak dapat menerima token arus utama tanpa sepengetahuan mereka.

Oleh karena itu, pengembang harus memastikan bahwa kontrak target yang didelegasikan oleh pengguna mengimplementasikan antarmuka panggilan balik yang relevan untuk memastikan kompatibilitas dengan token arus utama.

(2) Verifikasi "tx.origin" gagalDalam

kontrak tradisional, "tx.origin" sering digunakan untuk menentukan apakah transaksi dimulai secara langsung oleh pengguna, dan digunakan untuk mencegah kontrol keamanan seperti panggilan kontrak.

Namun, dalam skenario EIP-7702,

• pengguna menandatangani transaksi otorisasi, dan relayer atau bundler menyiarkannya atas nama pengguna. Saat transaksi dieksekusi, "tx.origin" adalah alamat relayer, 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 penilaian keamanan dan menggunakan verifikasi tanda tangan atau mekanisme otorisasi sebagai gantinya.

(3) "isContract" salah menilaiBanyak

kontrak mencegah akun kontrak berpartisipasi dalam operasi tertentu, seperti airdrop, flash sales, dll., melalui "isContract(address)":

require(!isContract(msg.sender), "Kontrak tidak diperbolehkan"

). Di bawah mekanisme EIP-7702, alamat pengguna dapat diubah menjadi akun kontrak melalui transaksi "set_code", dan "isContract" mengembalikan true, dan kontrak akan secara keliru mengidentifikasi pengguna yang sah sebagai akun kontrak dan menolak untuk berpartisipasi dalam operasi, mengakibatkan pengguna tidak dapat menggunakan layanan tertentu dan pengalaman diblokir.

Dengan mempopulerkan dompet kontrak secara bertahap, desain mengandalkan "isContract" untuk menentukan apakah "pengguna manusia" tidak lagi aman, dan disarankan untuk menggunakan metode identifikasi pengguna yang lebih akurat seperti verifikasi tanda tangan.

3. Serangan PhishingSetelah

penerapan mekanisme delegasi EIP-7702, aset di akun pengguna akan dikendalikan sepenuhnya oleh kontrak pintar yang didelegasikan. Setelah pengguna mengotorisasi kontrak berbahaya, penyerang dapat memperoleh kendali penuh atas aset akun, yang mengakibatkan transfer atau pencurian dana yang cepat, yang sangat berisiko.

Oleh karena itu, bagi penyedia layanan dompet, perlu untuk mendukung resolusi transaksi EIP-7702 dan mekanisme identifikasi risiko sesegera mungkinKrusial. Saat pengguna menandatangani transaksi kepercayaan, front-end harus menampilkan alamat kontrak target dengan jelas dan mencolok, 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.

Secara khusus, EIP-7702 memperkenalkan format tanda tangan yang didelegasikan yang tidak kompatibel dengan standar tanda tangan EIP-191 dan EIP-712 yang ada. Tanda tangannya dapat dengan mudah melewati peringatan tanda tangan asli dan prompt interaksi dompet, yang semakin meningkatkan risiko pengguna tertipu untuk menandatangani operasi berbahaya. Oleh karena itu, pengenalan mekanisme identifikasi dan pemrosesan struktur tanda tangan dalam implementasi dompet akan menjadi tautan utama untuk memastikan keamanan pengguna.

4. Risiko Kontrak Dompet(

1) Manajemen Otoritas Kontrak Dompet

Banyak kontrak dompet EIP-7702 mengadopsi arsitektur proxy (atau izin manajemen bawaan) untuk mendukung peningkatan logis. Namun, hal ini juga menimbulkan risiko pengelolaan hak yang lebih tinggi. Jika hak istimewa eskalasi tidak dibatasi secara ketat, penyerang dapat mengganti kontrak implementasi dan menyuntikkan kode berbahaya, yang mengakibatkan akun pengguna dirusak atau dana dicuri.

Rekomendasi keamanan

• : Gunakan mekanisme multi-tanda tangan, autentikasi multi-faktor, atau timelock untuk mengontrol hak istimewa eskalasi.

• Perubahan kode dan izin tunduk pada audit ketat dan validasi keamanan.

• Proses peningkatan terbuka dan transparan untuk memastikan hak pengguna untuk mengetahui dan berpartisipasi.

(2) Risiko konflik penyimpanan dan isolasi data,

versi kontrak dompet, atau penyedia layanan dompet yang berbeda dapat menggunakan kembali slot penyimpanan yang sama. Jika pengguna mengubah penyedia layanan dompet atau meningkatkan logika dompet, penggunaan kembali slot penyimpanan akan menyebabkan konflik variabel status, penimpaan data, pengecualian pembacaan, dan masalah lainnya. Ini tidak hanya dapat mengganggu fungsi normal dompet, tetapi juga dapat menyebabkan hilangnya dana atau izin abnormal.

Rekomendasi keamanan:

• Gunakan skema isolasi penyimpanan khusus, seperti standar EIP-1967, atau manfaatkan namespace unik untuk mengelola slot penyimpanan.

• Saat memutakhirkan kontrak, pastikan tata letak penyimpanan kompatibel dan hindari variabel yang tumpang tindih.

• Uji secara ketat kemungkinan status tersimpan selama proses peningkatan.

(3) Manajemen nonce di dalam dompet

Kontrak dompet biasanya menyiapkan nonce di dalam dan mengelola dirinya sendiri untuk memastikan urutan eksekusi operasi pengguna dan mencegah serangan pemutaran ulang. Jika nonce digunakan secara tidak benar, operasi pengguna tidak akan dijalankan dengan benar.

Rekomendasi Keamanan:

• Nuse harus diperiksa secara paksa untuk nilai yang setara (atau peningkatan) dan tidak dapat dilewati.

• Dilarang bagi fungsi untuk memodifikasi nonce secara langsung, dan nonce hanya akan diperbarui saat operasi pengguna dijalankan.

• Rancang toleransi kesalahan dan mekanisme pemulihan untuk pengecualian nonce untuk menghindari kebuntuan nonce.

(4) Pemeriksaan izin penelepon fungsiUntuk

memastikan keamanan, kontrak dompet harus memastikan bahwa penelepon fungsi kunci adalah akun pemilik dompet. Dua metode umum meliputi:

• penandatanganan off-chain mengizinkan

pengguna untuk menandatangani serangkaian operasi melalui kunci pribadi, dan kontrak dompet memverifikasi apakah tanda tangan itu sah, kedaluwarsa, dan memenuhi nonce yang sesuai pada rantai. Metode ini berlaku untuk mode transaksi relai yang dianjurkan oleh EIP-7702 (tanda tangan offline pengguna + relayer mengirim transaksi atas nama pengguna).

• pembatasan panggilan (msg.sender == address(this))

hanya diizinkan untuk dipicu oleh kontrak itu sendiri, yang pada dasarnya merupakan mekanisme kontrol jalur panggilan yang memastikan bahwa inisiator eksternal harus menjadi akun itu sendiri. Ini secara efektif setara dengan mengharuskan penelepon menjadi EOA asli, karena alamat kontrak adalah alamat EOA.

3. Prospek: Proposal EIP-7702 dan standar dompet AA masa depan

EIP-7702 bukan hanya inovasi dari model akun tradisional, tetapi juga promosi besar ekosistem abstraksi akun. Kemampuan untuk memuat kode kontrak yang diperkenalkan olehnya membawa ruang yang luas untuk eksplorasi untuk desain dompet dan sistem kontrak di masa depan, dan juga mengedepankan persyaratan baru untuk standar audit keamanan.

1. Evolusi bersama dengan EIP-4337: Menuju kompatibilitas mode gandaMeskipun

EIP-7702 dan EIP-4337 memiliki tujuan desain yang berbeda, yang pertama merekonstruksi mekanisme pemuatan kode akun, dan yang terakhir membangun ekosistem entri dan pengemasan transaksi yang lengkap. Namun, keduanya tidak bertentangan, tetapi memiliki saling melengkapi 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, di masa mendatang, dompet dapat mengadopsi "arsitektur dukungan mode ganda": gunakan EIP-7702 sebagai pengganti ringan pada rantai yang tidak mendukung EIP-4337, dan terus mengandalkan tumpukan protokol penuh EIP-4337 dalam skenario yang memerlukan pengemasan off-chain dan agregasi multi-pengguna.

Mekanisme mode ganda ini juga akan memungkinkan dompet untuk mendukung model izin akun yang lebih fleksibel, mekanisme downgrade, dan skema rollback di lapisan kernel.

2. Dukungan dan inspirasi untuk logika dompet baru seperti MPC dan ZK, dan

mekanisme kontrak akun yang dianjurkan oleh EIP-7702 memiliki potensi integrasi alami dengan dompet MPC populer saat ini, dompet ZK, dompet modular, dan arsitektur baru lainnya:

● Dalam model MPC, perilaku tanda tangan tidak lagi bergantung pada kunci pribadi tunggal, tetapi merupakan pengambilan keputusan kolaboratif multi-pihak. Tanda tangan yang dihasilkan melalui konvergensi EIP-7702 dan MPC mengontrol logika kontrak yang dimuat secara dinamis, memungkinkan strategi eksekusi yang lebih fleksibel.

● Dompet ZK memverifikasi identitas atau otorisasi pengguna melalui bukti tanpa pengetahuan, tanpa mengekspos informasi kunci pribadi. Dikombinasikan dengan EIP-7702, dompet ZK dapat menyuntikkan kontrak logika tertentu untuk sementara setelah verifikasi selesai, untuk mewujudkan penyebaran perilaku yang dipersonalisasi setelah komputasi privasi, seperti secara otomatis mengeksekusi logika tertentu hanya setelah kondisi privasi tertentu terpenuhi.

● Dompet Modular dapat menggunakan EIP-7702 untuk membongkar logika akun menjadi beberapa modul dan memuatnya secara dinamis bila diperlukan.

Oleh karena itu, EIP-7702 menyediakan "wadah eksekusi" yang lebih asli untuk dompet lanjutan 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 menghilangkan kebutuhan untuk pra-penerapan, sangat meningkatkan fleksibilitas dan kombinasi perilaku akun.

3. Implikasi bagi Pengembang dan

akan mendorong perubahan besar dalam paradigma pembangunan. Pengembang kontrak tidak lagi hanya memperlakukan penelepon sebagai EOA tradisional atau akun kontrak tetap, tetapi harus beradaptasi dengan mekanisme baru: identitas penelepon dapat dialihkan secara dinamis antara EOA dan status kontrak selama transaksi, dan logika perilaku akun tidak lagi dipadatkan secara statis, tetapi dapat diubah secara fleksibel sesuai dengan permintaan. Ini mengharuskan pengembang dan auditor untuk:

• memperkenalkan verifikasi penelepon yang lebih ketat dan logika penilaian izin;

• Periksa apakah jalur panggilan dipengaruhi oleh logika kontrak dinamis;

• mengidentifikasi potensi kerentanan yang bergantung pada perilaku seperti msg.sender.code.length == 0, isContract(), dll.;

• Klarifikasi "dependensi konteks" logika kontrak, seperti kontrol batas panggilan statis dan panggilan delegasi;

• Pada tingkat toolchain, simulasi dan analisis pengembalian skenario setCode didukung.

Dengan kata lain, keamanan kode bukan lagi hanya "masalah pra-penyebaran" tetapi "proses dinamis yang harus diverifikasi selama pemanggilan dan transaksi".

4.

memperkenalkan implementasi Abstraksi Akun (AA) yang lebih ringan, asli, dan fleksibel, sehingga EOA biasa dapat membawa logika kontrak dan menjalankannya dalam satu transaksi. Mekanisme ini mematahkan asumsi statis tradisional tentang perilaku akun, dan pengembang tidak lagi dapat hanya mengandalkan status kode alamat akun untuk menilai model perilakunya, tetapi perlu merekonstruksi pemahaman tentang batas identitas dan otoritas penelepon.

Dengan itu muncul perubahan paradigma dalam analitik keamanan. Fokus audit tidak lagi terbatas pada "apakah alamat memiliki izin", tetapi pada "apa yang dapat dilakukan oleh logika kontrak yang dibawa dalam transaksi dalam konteks saat ini". Setiap transaksi mungkin membawa definisi perilaku independen, yang memberikan fungsionalitas yang lebih besar kepada akun dan mengajukan persyaratan yang lebih tinggi untuk audit keamanan.