Pengantar

EIP-7702 memungkinkan dompet Ethereum sederhana (EOA) untuk ditingkatkan menjadi dompet kontrak pintar, yang menawarkan keamanan yang lebih baik, fungsionalitas lanjutan, kesempatan untuk sponsor gas, dan manfaat lainnya. Secara historis, dompet pintar harus dibuat dari awal, tetapi dengan pengenalan EIP-7702, dompet tradisional, dengan semua aset dan riwayat onchain mereka, dapat ditingkatkan dan mempertahankan alamat dompet yang sama. Ini seperti beralih dari telepon tetap ke ponsel pintar tanpa harus mendapatkan nomor baru.

EOA diperbarui dengan menetapkan "penunjukan delegasi", sebuah pointer ke kontrak pintar deleGate, yang logikanya kemudian mengatur EOA. EOA yang diperbarui dapat memiliki fungsi, menetapkan penyimpanan, memancarkan peristiwa, dan melakukan semua hal lain yang dapat dilakukan oleh kontrak pintar. EOA dapat mengubah atau menghapus delegasi ini kapan saja dengan otorisasi EIP-7702 baru yang ditandatangani. Sementara ini membuka banyak kemungkinan baru, fitur kuat ini juga memperkenalkan tantangan keamanan baru yang memerlukan pertimbangan hati-hati dan solusi inovatif.

Untuk memungkinkan EOA bertindak sebagai dompet kontrak pintar, kami mengembangkan EIP7702Proxy, sebuah lightweight proksi ERC-1967kontrak yang dirancang untuk berfungsi sebagai deleGate EIP-7702 untuk EOA. Selain dari pengalihan logis dasar yang dilakukan oleh proxy, EIP7702Proxy memiliki fitur tambahan dan pilihan desain yang menyelesaikan beberapa tantangan yang unik untuk akun yang didelegasikan EIP-7702. Salah satu tujuan dalam merancang EIP7702Proxy adalah untuk memungkinkan kesetaraan yang sedekat mungkin antara "standard-deploy" Dompet Pintar Coinbase dan Dompet Pintar Coinbase yang didelegasikan EIP-7702, yang berarti mengabstraksi kompleksitas tambahan yang diminta oleh mekanik EIP-7702 ke dalam proxy yang ditujukan dan terus bergantung pada implementasi asli dari CoinbaseSmartWallet. Solusi untuk tantangan ini dapat diterapkan dengan berguna pada logika implementasi mana pun, tidak hanya pada implementasi CoinbaseSmartWallet, sambil membantu EOA tetap aman dalam lingkungan yang diaktifkan 7702.

Kami menjelaskan di bawah tantangan spesifik dan solusi desain yang sesuai yang memungkinkan kami untuk dengan aman mengadaptasi implementasi dompet kontrak pintar yang ada untuk digunakan pada pembaruan EIP-7702.

Tantangan #1: Menegakkan inisialisasi yang aman

Hurdle besar pertama dalam menerapkan EIP-7702 berasal dari batasan inisialisasinya. Dompet kontrak pintar tradisional, termasuk CoinbaseSmartWallet, biasanya menangani inisialisasi yang aman (penetapan kepemilikan akun) secara atomik selama penerapan mereka melalui kontrak pabrik terpisah. Atomisitas ini berarti banyak implementasi semacam itu memiliki fungsi inisialisasi yang tidak terlindungi yang dapat dipanggil tepat sekali. Namun, desain EIP-7702 tidak mengizinkan pelaksanaan calldata inisialisasi selama proses delegasi kode (langkah yang sebanding dengan "penerapan") dan oleh karena itu ini tidak dapat dilakukan secara atomik.

Pemisahan langkah-langkah ini menciptakan jendela kerentanan kritis. Ketika kontrak implementasi "dideploy" ke EOA melalui EIP-7702, tidak ada jaminan bahwa pembaruan 7702 ini dan transaksi EVM standar yang menginisialisasi dompet akan dieksekusi secara atomik. Kode yang mengatur otorisasi secara teknis dapat diterapkan secara independen dari transaksi inisialisasi, bahkan jika mereka diajukan secara bersamaan, dan ini bisa memungkinkan penyerang untuk mendahului transaksi inisialisasi dengan muatan mereka sendiri dan mengklaim kepemilikan akun pintar.

Solusi: Memerlukan tanda tangan EOA untuk secara atomik menetapkan implementasi dan menginisialisasi

Perhatikan bahwa dompet pintar Coinbase yang ada dikerahkan di belakang sebuahproksi ERC-1967 dengan sebuah UUPSUpgradeable implementasi (logika CoinbaseSmartWallet yang sebenarnya). Kode di alamat akun yang sebenarnya adalah proxy, dan proxy menggunakan lokasi penyimpanan konvensional yang didefinisikan oleh ERC-1967 untuk menyimpan pointer ke logika implementasinya. Solusi kami untuk kerentanan inisialisasi dalam konteks 7702 melibatkan pengakuan bahwa logika implementasi hanya menjadi aktif (dan karenanya berbahaya) ketika proxy benar-benar menjalin koneksi dengannya. Oleh karena itu, jika kami tidak dapat menegakkan penerapan atomik dengan inisialisasi, kami dapat sebaliknya menegakkan pengaturan implementasi atomik dengan inisialisasi.

Arsitektur kontrak CoinbaseSmartWallet EIP-7702 dan alur delegasi logis

Dalam konteks EIP-7702, EOA itu sendiri adalah otoritas awal atas setiap perubahan pada akunnya, dan harus memberikan tanda tangan untuk mengizinkan inisialisasi dan menetapkan pemilik baru dari akun pintar yang baru. Kontrak EIP7702Proxy kami mengimplementasikan fungsi setImplementation yang dapat secara atomik menetapkan implementasi logis baru dan menginisialisasi akun. Fungsi setImplementation:

1. Memvalidasi tanda tangan dari EOA di seluruh data kunci seperti alamat kontrak implementasi baru, data inisialisasi calldata, alamat kontrak validator yang akan mengevaluasi keamanan dari status akun yang dihasilkan, dan perlindungan dasar terhadap pengulangan tanda tangan seperti nonce dan masa berlaku.
2. Mengatur nilai dari pointer ERC-1967 ke implementasi baru dan mengeksekusi calldata yang diberikan terhadap implementasi logis baru
3. Melakukan panggilan ke fungsi validateAccountState yang harus diimplementasikan oleh validator yang termasuk dalam tanda tangan.

Validator adalah kontrak khusus implementasi yang berisi logika untuk mengevaluasi apakah ia menganggap keadaan akun yang dihasilkan aman. Misalnya, dalam kasus CoinbaseSmartWallet, CoinbaseSmartWalletValidator akan memeriksa apakah keadaan kepemilikan akun tidak kosong, dan oleh karena itu tidak lagi rentan terhadap inisialisasi sembarangan.

Tantangan #2: Penyimpanan bersama di antara deleGates EIP-7702

Mungkin tantangan paling rumit dari EIP-7702 terkait dengan manajemen penyimpanan. EOA dapat dengan bebas mengalihkan logikanya ke kontrak yang berbeda, atau sepenuhnya menghapus delegasi kapan saja. Semua delegasi berbagi ruang penyimpanan yang sama di alamat EOA. Beberapa kontrak yang berbagi akses ke penyimpanan yang sama dari waktu ke waktu dapat menyebabkan masalah "tabrakan penyimpanan". Tabrakan penyimpanan terjadi ketika dua kontrak melakukan perubahan atau asumsi yang berbeda tentang lokasi penyimpanan yang sama, yang berpotensi menyebabkan bug yang tidak terduga.

Manajemen tabrakan penyimpanan sudah merupakan masalah yang akrab dalam ruang desain proxy, di mana logika implementasi yang dapat diubah digunakan untuk mengatur penyimpanan bersama. Meskipun proxy yang dapat diupgrade dapat mengubah implementasi, kode proxy itu sendiri (untuk alamat non-7702) tidak dapat diubah. Ini membawa kepastian dan jaminan pada proses upgrade. Delegasi ulang 7702 memperkenalkan lapisan total mutabilitas lain pada logika potensial yang dapat mengatur penyimpanan bersama ini. Ini pada dasarnya menghilangkan jaminan apa pun mengenai efek yang mungkin dimiliki oleh deleGate sembarang pada penyimpanan. Misalnya, jika EOA mendelegasikan dari deleGate A ke B dan kembali ke A lagi, deleGate yang kembali tidak dapat membuat asumsi tentang keadaan penyimpanannya, yang mungkin telah dihapus atau dimanipulasi oleh deleGate B ke dalam keadaan yang tidak mungkin dicapai melalui logika deleGate A saja. Ini berlaku untuk setiap deleGate 7702, terlepas dari pola delegasi, karena deleGate sebelumnya mungkin telah menyimpan atau menghapus apa pun di lokasi penyimpanan mana pun.

Contoh keadaan tidak valid untuk DeleGate A yang diinduksi oleh pola delegasi A → B → A

Solusi: Eksternalisasi nilai penyimpanan yang kritis untuk keamanan

Delegasi EOA dapat mempengaruhi keadaan akun secara sembarangan. Jika EOA mendelegasikan ke kontrak yang jahat atau merusak, tidak ada deleGate yang sedang menjabat yang dapat melindungi terhadap hal ini. Seperti menandatangani transaksi drainer, mengizinkan deleGate 7702 yang jahat bisa menjadi bencana, dan melindungi terhadap hasil ini berada di luar ruang lingkup desain kami.

Kami merancang EIP7702Proxy agar dapat mempertahankan diri terhadap masalah yang dapat diperkirakan dalam ekosistem multi-dompet yang didukung 7702, yang terdiri dari aktor-aktor baik yang berpotensi kacau. Ini tidak dapat melindungi EOA yang mengizinkan deleGates yang benar-benar jahat atau memiliki bug.

Salah satu masalah yang dapat diprediksi melibatkan tanda tangan untuk panggilan setImplementation dan risiko yang diperkenalkan oleh keadaan akun yang dapat diubah. EIP7702Proxy bergantung pada tanda tangan EOA untuk menetapkan logika implementasi dan menginisialisasi ke keadaan yang aman. Tanda tangan ini bisa menjadi liabilitas jika suatu saat dapat diputar ulang. Misalnya, jika tanda tangan mengotorisasi pemilik awal yang kemudian terkompromikan dan dihapus, tanda tangan yang dapat diputar ulang bisa mengembalikan pemilik yang terkompromikan atau memaksa penurunan implementasi.

Perlindungan umum terhadap replay tanda tangan menggunakan nonce dalam pesan yang ditandatangani, ditandai sebagai dikonsumsi saat diverifikasi. Risiko untuk akun 7702: deleGates lain dapat mengkompromikan penyimpanan pelacakan nonce ini. Jika penyimpanan pelacakan penggunaan nonce terhapus, tanda tangan setImplementation EOA (tersedia secara publik di mempool) dapat diterapkan kembali saat mendelegasikan kembali ke EIP7702Proxy.

Untuk menjamin ketidakulangan tanda tangan, kami menerapkan singleton NonceTracker terpisah yang mempertahankan status nonce di lokasi kontrak yang tidak dapat diubah di luar penyimpanan akun. Hanya EOA yang dapat memengaruhi nonce mereka (hanya secara inkremental), mencegah deleGates lain dari memanipulasi nilai-nilai penting untuk keamanan ini. NonceTracker memastikan setiap tanda tangan setImplementation hanya berfungsi sekali, terlepas dari perubahan penyimpanan akun.

Tantangan #3: Risiko yang meningkat dari lokasi penyimpanan konvensional yang dibagikan

Slot penyimpanan yang distandarisasi seperti yang didefinisikan oleh ERC-1967 sangat rentan terhadap kemungkinan tabrakan penyimpanan karena merupakan lokasi konvensional yang kemungkinan besar akan digunakan oleh beberapa implementasi deleGate. Slot penyimpanan ERC-1967 adalah satu-satunya lokasi penyimpanan standar yang digunakan dalam EIP7702Proxy dan itu menyimpan alamat implementasi logis yang ditunjuk oleh proxy. Desain kami menjamin bahwa terlepas dari nilai di lokasi penyimpanan ini (yang menentukan sebagian besar logika yang tersedia di akun), EIP7702Proxy akan selalu dapat berhasil mengatur logika implementasinya ke kontrak yang diinginkan oleh EOA.

Untuk menggambarkan masalah yang sedang dipecahkan dengan lebih jelas, perhatikan bahwa ketika sebuah akun bertransisi antara deleGates yang berbeda (A→B→A) di mana kedua deleGates menerapkan pola proxy ERC-1967, deleGate B secara alami akan menggunakan slot penyimpanan yang sama yang digunakan deleGate A untuk menyimpan alamat implementasinya. Selama masa jabatannya, deleGate B dapat memodifikasi atau menimpa slot ini, baik secara sengaja atau sebagai bagian normal dari operasi proxynya sendiri. Dalam pola proxy UUPSUpgradeable, logika untuk meningkatkan implementasi ditentukan pada kontrak implementasi itu sendiri. Jika implementasi yang ditempatkan di lokasi penunjuk ini oleh deleGate B tidak mengandung antarmuka upgradeToAndCall yang diharapkan pada sebuah implementasi, maka saat kembali ke deleGate A, mekanisme untuk mengubah implementasinya mungkin tidak ada pada logika yang tersedia saat ini.

Contoh menimpa lokasi penyimpanan konvensional bersama dengan deleGate baru

Solusi: Mekanisme upgrade tersedia di EIP7702Proxy

EIP7702Proxy kami mengatasi hal ini melalui fungsi setImplementation-nya, yang menyediakan mekanisme upgrade yang independen dari implementasi secara langsung pada proxy itu sendiri. Ini memastikan bahwa bahkan jika deleGate yang terlibat telah menunjuk implementasi ERC-1967 ke implementasi yang tidak valid (atau menghapusnya sepenuhnya), EOA asli, setelah mendelegasikan kembali ke EIP7702Proxy, mempertahankan kemampuan untuk mengonfigurasi kembali pointer ERC-1967 proxy ke implementasi logis pilihan mereka.

Tantangan #4: Kompatibilitas mundur dengan perilaku EOA standar

Tujuan desain dari EIP7702Proxy adalah untuk mempertahankan kompatibilitas ke belakang dengan fungsi EOA akun selain dari fungsi kontrak pintar yang baru. Kehadiran atau ketidakberadaan kode di sebuah alamat dapat mempengaruhi alur eksekusi protokol yang berinteraksi dengan alamat tersebut, karena mereka berpredikat pada kualitas ini untuk membedakan antara EOA dan kontrak pintar. Ini memerlukan pertimbangan terhadap dua perilaku utama: verifikasi tanda tangan dan perilaku penerimaan token.

Verifikasi tanda tangan

Kontrak pintar memiliki standar yang berbeda untuk validasi tanda tangan dibandingkan dengan EOA standar. Kontrak pintar mengimplementasikan antarmuka isValidSignature yang didefinisikan oleh ERC-1271dan bebas untuk mendefinisikan logika arbitrer yang menentukan apakah kontrak menganggap tanda tangan sebagai valid. Untuk EOA standar, tanda tangan divalidasi dengan pemeriksaan ecrecover standar yang memastikan penandatangan memulihkan alamat EOA yang diharapkan.

Untuk memastikan bahwa tanda tangan EOA yang ada atau di masa depan akan terus dihormati di EOA setelah peningkatan 7702, EIP7702Proxy menerapkan versi dari isValidSignature yang pertama-tama mendelegasikan validasi tanda tangan ke fungsi isValidSignature yang harus didefinisikan pada implementasi logis, tetapi mengikuti validasi yang gagal dengan pemeriksaan ecrecover terakhir. Jika ini berhasil, tanda tangan dianggap valid. Dengan cara ini, EOA yang menggunakan EIP7702Proxy dapat menjamin bahwa tanda tangan EOA sederhana akan selalu dihormati di alamat mereka terlepas dari implementasi isValidSignature dari dompet kontrak pintar mereka.

Penerimaan token

Beberapa standar token (khususnya ERC-1155 dan ERC-721) upaya untuk melindungi terhadap token yang terjebak dalam kontrak pintar yang mungkin tidak memiliki kemampuan untuk mengelolanya. Token ini memerlukan setiap kontrak pintar yang akan menerima token tersebut untuk menyatakan kemampuan ini dengan mengimplementasikan antarmuka penerima token standar yang dipanggil oleh kontrak token selama pengiriman token. Sangat penting juga bahwa logika di EOA yang diperbarui mengandung fungsi penerima standar atau fallback yang dapat dibayar untuk dapat menerima token asli. Sebuah akun tidak boleh pernah berada dalam keadaan yang membuatnya tidak mampu menerima ETH atau token lainnya, betapapun singkatnya.

Karena proksi kami tidak memiliki implementasi awal, kami menyertakan implementasi DefaultReceiver yang tidak dapat diubah sebagai logika default untuk EIP7702Proxy jika tidak ada pointer ERC-1967. Penerima ini mengimplementasikan fungsi terima dan pengait penerima untuk standar token umum ini, memastikan akun dapat menerima transfer token sebelum secara eksplisit menetapkan implementasi baru.

Kesimpulan

Desain EIP7702Proxy memungkinkan kami untuk mempertahankan paritas yang dekat dengan CoinbaseSmartWallets yang dideploy secara standar dan untuk terus menggunakan implementasi CoinbaseSmartWallet yang ada sambil menyelesaikan tantangan keamanan unik yang muncul dalam konteks EIP-7702. Dengan mempertimbangkan dengan cermat keamanan inisialisasi, implikasi dari ketidakpastian penyimpanan dan interferensi, kebutuhan untuk penanganan token yang tidak terputus dan kompatibilitas mundur dengan verifikasi tanda tangan EOA standar, kami telah menciptakan sebuah proxy untuk mendelegasikan dan mengelola dompet kontrak pintar EIP-7702 dengan aman. Meskipun EIP7702Proxy dirancang dengan implementasi CoinbaseSmartWallet V1 dalam pikiran, proxy ini pada akhirnya agnostik terhadap implementasi. Kami mendorong pengembang untuk mengevaluasi solusi ini untuk membuktikan 7702 terhadap implementasi dompet kontrak pintar lainnya.

Disclaimer:

1. Artikel ini dicetak ulang dari [Blog Teknik Dasar]. Semua hak cipta milik penulis asli [Amie Corso]. Jika ada keberatan terhadap cetakan ulang ini, silakan hubungi Gate Learn tim, dan mereka akan menanganinya dengan cepat.
2. Pernyataan Penafian Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini hanya merupakan pendapat penulis dan tidak merupakan nasihat investasi.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan adalah dilarang.