Upgrade Pectra Ethereum: Analisis Mendalam EIP-7702 dan Praktik Terbaik
Pendahuluan
Ethereum akan segera menyambut pembaruan Pectra, yang merupakan pembaruan yang sangat signifikan, dengan pengenalan beberapa proposal peningkatan Ethereum yang penting. Di antaranya, EIP-7702 melakukan transformasi revolusioner pada akun eksternal Ethereum (EOA). Proposal ini mengaburkan batas antara EOA dan akun kontrak CA, merupakan langkah kunci menuju abstraksi akun asli setelah EIP-4337, dan membawa mode interaksi baru ke dalam ekosistem Ethereum.
Pectra telah menyelesaikan penyebaran di jaringan pengujian, dan diperkirakan akan segera diluncurkan di jaringan utama. Artikel ini akan menganalisis secara mendalam mekanisme implementasi EIP-7702, mengeksplorasi peluang dan tantangan yang mungkin dihadirkan, serta memberikan panduan praktis untuk berbagai peserta.
Analisis Protokol
Ringkasan
EIP-7702 memperkenalkan jenis transaksi baru yang memungkinkan EOA untuk menentukan alamat kontrak pintar, untuk mengatur kode. Ini memungkinkan EOA untuk menjalankan kode seperti kontrak pintar, sambil mempertahankan kemampuan untuk memulai transaksi. Fitur ini memberikan EOA kemampuan pemrograman dan komposabilitas, pengguna dapat menerapkan pemulihan sosial, kontrol izin, manajemen multi-tanda tangan, verifikasi zk, pembayaran berlangganan, sponsor transaksi, dan pemrosesan batch transaksi dalam EOA. Perlu dicatat bahwa EIP-7702 dapat berintegrasi sempurna dengan dompet kontrak pintar yang diimplementasikan oleh EIP-4337, integrasi tanpa batas antara keduanya sangat menyederhanakan proses pengembangan dan penerapan fitur baru.
EIP-7702 memperkenalkan tipe transaksi SET_CODE_TX_TYPE (0x04), yang struktur datanya didefinisikan sebagai berikut:
Dalam struktur transaksi yang baru, selain bidang authorization_list, yang lainnya mengikuti semantik yang sama dengan EIP-4844. Bidang ini adalah tipe daftar, yang dapat berisi beberapa entri otorisasi, di mana setiap entri otorisasi berisi:
chain_id menunjukkan rantai tempat otorisasi delegasi ini berlaku
address menunjukkan alamat tujuan dari delegasi
nonce harus cocok dengan nonce akun yang saat ini diotorisasi
y_parity, r, s adalah data tanda tangan yang ditandatangani oleh akun yang memberi otorisasi
Field authorization_list dalam satu transaksi dapat berisi beberapa akun yang diotorisasi berbeda yang ditandatangani oleh (EOA), yaitu penggagas transaksi dapat berbeda dari yang memberikan otorisasi, untuk memungkinkan operasi otorisasi di mana gas dibayar oleh yang memberikan otorisasi.
mewujudkan
Saat pemberi kuasa menandatangani data kuasa, mereka harus terlebih dahulu melakukan pengkodean RLP pada chain_id, address, dan nonce. Kemudian, data yang telah dikodekan akan dihitung dengan fungsi hash keccak256 bersama dengan angka MAGIC, untuk mendapatkan data yang akan ditandatangani. Terakhir, menggunakan kunci privat pemberi kuasa untuk menandatangani data yang telah di-hash, menghasilkan data y_parity, r, dan s. MAGIC (0x05) digunakan sebagai pemisah domain, tujuannya adalah untuk memastikan bahwa hasil tanda tangan yang berbeda jenis tidak akan bertabrakan.
Ketika chain_id yang diberikan oleh pemberi otorisasi adalah 0, itu berarti pemberi otorisasi mengizinkan untuk mereplay otorisasi ( di semua rantai EVM yang mendukung EIP-7702 dengan syarat nonce juga tepat cocok ).
Setelah pemberi kuasa menandatangani data kuasa, peng发起交易 akan mengumpulkannya dalam bidang authorization_list untuk ditandatangani dan disiarkan transaksi melalui RPC. Sebelum transaksi dimasukkan ke dalam blok untuk dieksekusi, Proposer akan terlebih dahulu melakukan pemeriksaan awal pada transaksi, di mana alamat to akan diperiksa secara ketat untuk memastikan bahwa transaksi ini bukan transaksi pembuatan kontrak, yaitu ketika mengirim transaksi tipe EIP-7702, alamat to transaksi tidak boleh kosong.
Pada saat yang sama, transaksi semacam ini mengharuskan bidang authorization_list untuk setidaknya menyertakan satu item otorisasi. Jika ada beberapa item otorisasi yang ditandatangani oleh otorisator yang sama, hanya item otorisasi terakhir yang akan berlaku.
Selama proses eksekusi transaksi, node akan terlebih dahulu menambah nilai nonce pengirim transaksi, lalu melakukan operasi applyAuthorization pada setiap entri otorisasi dalam authorization_list. Dalam operasi applyAuthorization, node akan terlebih dahulu memeriksa nonce pemberi otorisasi, kemudian menambah nonce pemberi otorisasi. Ini berarti bahwa jika pengirim transaksi dan pemberi otorisasi adalah pengguna yang sama (EOA), maka saat menandatangani transaksi otorisasi, nilai nonce harus ditambah 1.
Saat node menerapkan suatu entri otorisasi, jika terjadi kesalahan, entri otorisasi tersebut akan dilewati, transaksi tidak akan gagal, dan entri otorisasi lainnya akan terus diterapkan, sehingga memastikan bahwa risiko DoS tidak muncul dalam skenario otorisasi massal.
Setelah aplikasi diotorisasi, field code dari alamat pemberi otorisasi akan diatur menjadi 0xef0100 || address, di mana 0xef0100 adalah identifikasi tetap, dan address adalah alamat tujuan yang didelegasikan. Karena batasan EIP-3541, pengguna tidak dapat menerapkan kode kontrak yang diawali dengan byte 0xef dengan cara biasa, ini memastikan bahwa identifikasi semacam itu hanya dapat diterapkan oleh transaksi tipe SET_CODE_TX_TYPE (0x04).
Setelah otorisasi selesai, jika pemberi otorisasi ingin menghapus otorisasi, cukup atur alamat target yang didelegasikan ke alamat 0.
Jenis transaksi baru yang diperkenalkan melalui EIP-7702 memungkinkan pemberi otorisasi (EOA) untuk mengeksekusi kode seperti kontrak pintar, sekaligus mempertahankan kemampuan untuk memulai transaksi. Dibandingkan dengan EIP-4337, ini memberikan pengguna pengalaman yang lebih mendekati abstraksi akun asli (Native AA), yang secara signifikan mengurangi ambang penggunaan bagi pengguna.
Praktik Terbaik
Meskipun EIP-7702 memberikan energi baru bagi ekosistem Ethereum, namun skenario aplikasi baru juga akan membawa risiko baru. Berikut adalah aspek-aspek yang perlu diwaspadai oleh para peserta ekosistem dalam proses praktik:
penyimpanan kunci pribadi
Meskipun EOA dapat memanfaatkan metode pemulihan sosial yang tertanam dalam kontrak pintar untuk mengatasi masalah kehilangan dana akibat kunci privat yang hilang setelah penugasan, tetap ada risiko kebocoran kunci privat EOA yang tidak dapat dihindari. Perlu ditegaskan bahwa setelah melakukan penugasan, kunci privat EOA tetap memiliki kontrol tertinggi atas akun, dan siapa pun yang memegang kunci privat dapat dengan bebas mengelola aset dalam akun tersebut. Pengguna atau penyedia layanan dompet, setelah menyelesaikan penugasan untuk EOA, meskipun sepenuhnya menghapus kunci privat yang disimpan secara lokal, tidak dapat sepenuhnya menghilangkan risiko kebocoran kunci privat, terutama dalam skenario yang memiliki risiko serangan rantai pasokan.
Bagi pengguna, saat menggunakan akun setelah melakukan delegasi, tetap harus mengutamakan perlindungan kunci privat, selalu ingat: Not your keys, not your coins.
Multi-chain replay
Pengguna dapat memilih rantai yang dapat berfungsi melalui chainId saat menandatangani otorisasi delegasi, tentu saja pengguna juga dapat memilih untuk menggunakan chainId 0 untuk delegasi, ini memungkinkan delegasi dapat direplikasi dan berfungsi di banyak rantai, sehingga memudahkan pengguna untuk melakukan delegasi dengan satu tanda tangan di banyak rantai. Namun perlu diperhatikan, bahwa di alamat kontrak yang sama di banyak rantai, mungkin juga terdapat kode implementasi yang berbeda.
Bagi penyedia layanan dompet, saat pengguna melakukan delegasi, mereka harus memeriksa apakah rantai yang efektif untuk delegasi sesuai dengan jaringan yang terhubung saat ini, dan mengingatkan pengguna tentang risiko yang mungkin timbul dari menandatangani delegasi dengan chainId 0.
Pengguna juga harus memperhatikan bahwa alamat kontrak yang sama di rantai yang berbeda tidak selalu memiliki kode kontrak yang sama, dan harus terlebih dahulu memahami tujuan penugasan.
tidak dapat diinisialisasi
Dompet kontrak pintar yang saat ini populer sebagian besar menggunakan model proxy, di mana proxy dompet saat penyebaran akan memanggil fungsi inisialisasi kontrak melalui DELEGateCALL, untuk mencapai operasi atomik antara inisialisasi dompet dan penyebaran dompet proxy, menghindari masalah inisialisasi yang dilakukan lebih dahulu. Namun, saat pengguna menggunakan EIP-7702 untuk melakukan delegasi, hanya akan memperbarui field code dari alamatnya, dan tidak dapat melakukan inisialisasi melalui pemanggilan alamat delegasi. Ini membuat EIP-7702 tidak dapat melakukan inisialisasi dompet dalam transaksi penyebaran kontrak seperti kontrak proxy ERC-1967 yang umum.
Bagi pengembang, saat menggabungkan EIP-7702 dengan dompet EIP-4337 yang ada, harus diperhatikan untuk melakukan pemeriksaan izin dalam operasi inisialisasi dompet, misalnya dengan menggunakan ecrecover untuk memulihkan alamat tanda tangan untuk melakukan pemeriksaan izin, untuk menghindari risiko operasi inisialisasi dompet yang dapat dikejar.
( Manajemen Penyimpanan
Pengguna yang menggunakan fungsi delegasi EIP-7702 mungkin perlu mendelegasikan kembali ke alamat kontrak yang berbeda karena perubahan kebutuhan fungsi, peningkatan dompet, dan alasan lainnya. Namun, struktur penyimpanan kontrak yang berbeda mungkin memiliki perbedaan. ) Misalnya, slot0 dari kontrak yang berbeda mungkin mewakili jenis data yang berbeda. ### Dalam kasus delegasi ulang, mungkin saja kontrak baru secara tidak sengaja menggunakan data dari kontrak lama, yang dapat menyebabkan penguncian akun, kerugian dana, dan konsekuensi buruk lainnya.
Bagi pengguna, perlu berhati-hati dalam menangani situasi delegasi ulang.
Bagi pengembang, selama proses pengembangan harus mengikuti Namespace Formula yang diusulkan oleh ERC-7201, untuk mengalokasikan variabel ke lokasi penyimpanan independen yang ditentukan, guna mengurangi risiko konflik penyimpanan. Selain itu, ERC-7779 (draft) juga menyediakan proses standar untuk delegasi ulang khusus untuk EIP-7702: termasuk penggunaan ERC-7201 untuk mencegah konflik penyimpanan, serta memverifikasi kompatibilitas penyimpanan sebelum melakukan delegasi ulang, dan memanggil antarmuka delegasi lama untuk membersihkan data lama dari penyimpanan.
( Isi Ulang Palsu
Setelah pengguna melakukan penugasan, EOA juga dapat digunakan sebagai kontrak pintar, oleh karena itu bursa terpusat )CEX### mungkin akan menghadapi situasi di mana pengisian ulang kontrak pintar menjadi umum.
CEX harus memeriksa status setiap transaksi deposit melalui trace, untuk mencegah risiko deposit palsu pada kontrak pintar.
( Konversi Akun
Setelah menerapkan delegasi EIP-7702, jenis akun pengguna dapat beralih dengan bebas antara EOA dan SC, yang memungkinkan akun untuk melakukan transaksi dan juga dipanggil. Ini berarti ketika akun memanggil dirinya sendiri dan melakukan panggilan eksternal, msg.sender-nya juga akan menjadi tx.origin, yang akan mematahkan beberapa asumsi keamanan yang hanya membatasi partisipasi proyek kepada EOA.
Bagi pengembang kontrak, mengasumsikan tx.origin selalu merupakan EOA tidak lagi dapat diterima. Begitu pula, pemeriksaan msg.sender == tx.origin untuk mencegah serangan reentrancy juga akan gagal.
Pengembang seharusnya menganggap bahwa peserta di masa depan mungkin semuanya adalah kontrak pintar.
) Kompatibilitas kontrak
Token ERC-721 dan ERC-777 yang ada memiliki fungsi Hook saat melakukan transfer kontrak, yang berarti penerima harus mengimplementasikan fungsi callback yang sesuai untuk berhasil menerima token.
Bagi pengembang, kontrak tujuan yang didelegasikan oleh pengguna seharusnya mengimplementasikan fungsi callback yang sesuai, untuk memastikan kompatibilitas dengan token mainstream.
Pemeriksaan Memancing
Setelah mengimplementasikan EIP-7702, aset dalam akun pengguna mungkin akan dikendalikan oleh kontrak pintar. Begitu pengguna mendelegasikan akunnya ke kontrak jahat, penyerang akan dapat mencuri dana dengan sangat mudah.
Bagi penyedia layanan dompet, sangat penting untuk segera mendukung transaksi jenis EIP-7702, dan saat pengguna melakukan tanda tangan delegasi, harus menampilkan secara jelas kontrak tujuan delegasi kepada pengguna, untuk mengurangi risiko yang mungkin dialami pengguna akibat serangan phishing.
Selain itu, melakukan analisis otomatis yang lebih mendalam terhadap kontrak target yang ditugaskan ke akun ###, pemeriksaan sumber terbuka, pemeriksaan izin, dan lain-lain ### dapat lebih baik membantu pengguna menghindari risiko semacam itu.
Ringkasan
Artikel ini membahas proposal EIP-7702 dalam peningkatan Pectra Ethereum yang akan datang. EIP-7702 memperkenalkan jenis transaksi baru yang memberikan EOA kemampuan pemrograman dan komposabilitas, yang mengaburkan batas antara EOA dan akun kontrak. Karena saat ini belum ada standar kontrak pintar kompatibel EIP-7702 yang teruji dalam praktik, berbagai peserta ekosistem, seperti pengguna, penyedia layanan dompet, pengembang, CEX, dan lainnya, menghadapi banyak tantangan dan peluang dalam aplikasi praktis. Konten praktik terbaik yang dijelaskan dalam artikel ini tidak dapat mencakup semua risiko potensial, tetapi tetap layak untuk dijadikan referensi dalam operasi praktis oleh semua pihak.
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
14 Suka
Hadiah
14
5
Bagikan
Komentar
0/400
ser_ngmi
· 07-21 20:33
Menyalin pekerjaan rumah sudah terlampau banyak, bukankah hanya ingin mendapatkan eoa dan ca?
Lihat AsliBalas0
ParanoiaKing
· 07-20 23:50
Sekali lagi, tumpukan peningkatan yang sulit dipahami, tidak ada kata-kata.
Lihat AsliBalas0
YieldHunter
· 07-20 23:49
secara teknis, EIP ini terlihat agak mencurigakan... ada data tentang biaya tx testnet?
Lihat AsliBalas0
EyeOfTheTokenStorm
· 07-20 23:26
Apakah ini lagi kesempatan untuk penempatan awal? Dari data sejarah, setelah peningkatan serupa, eth biasanya akan big pump. Namun, pasar sedikit berbuih.
Lihat AsliBalas0
SchrodingerPrivateKey
· 07-20 23:23
Ada EIP baru lagi, akun kontrak versi gratis telah datang.
Analisis EIP-7702: bagaimana Pembaruan Pectra Ethereum memberikan Programmabilitas kepada EOA
Upgrade Pectra Ethereum: Analisis Mendalam EIP-7702 dan Praktik Terbaik
Pendahuluan
Ethereum akan segera menyambut pembaruan Pectra, yang merupakan pembaruan yang sangat signifikan, dengan pengenalan beberapa proposal peningkatan Ethereum yang penting. Di antaranya, EIP-7702 melakukan transformasi revolusioner pada akun eksternal Ethereum (EOA). Proposal ini mengaburkan batas antara EOA dan akun kontrak CA, merupakan langkah kunci menuju abstraksi akun asli setelah EIP-4337, dan membawa mode interaksi baru ke dalam ekosistem Ethereum.
Pectra telah menyelesaikan penyebaran di jaringan pengujian, dan diperkirakan akan segera diluncurkan di jaringan utama. Artikel ini akan menganalisis secara mendalam mekanisme implementasi EIP-7702, mengeksplorasi peluang dan tantangan yang mungkin dihadirkan, serta memberikan panduan praktis untuk berbagai peserta.
Analisis Protokol
Ringkasan
EIP-7702 memperkenalkan jenis transaksi baru yang memungkinkan EOA untuk menentukan alamat kontrak pintar, untuk mengatur kode. Ini memungkinkan EOA untuk menjalankan kode seperti kontrak pintar, sambil mempertahankan kemampuan untuk memulai transaksi. Fitur ini memberikan EOA kemampuan pemrograman dan komposabilitas, pengguna dapat menerapkan pemulihan sosial, kontrol izin, manajemen multi-tanda tangan, verifikasi zk, pembayaran berlangganan, sponsor transaksi, dan pemrosesan batch transaksi dalam EOA. Perlu dicatat bahwa EIP-7702 dapat berintegrasi sempurna dengan dompet kontrak pintar yang diimplementasikan oleh EIP-4337, integrasi tanpa batas antara keduanya sangat menyederhanakan proses pengembangan dan penerapan fitur baru.
EIP-7702 memperkenalkan tipe transaksi SET_CODE_TX_TYPE (0x04), yang struktur datanya didefinisikan sebagai berikut:
rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])
Dimana field authorization_list didefinisikan sebagai:
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
Dalam struktur transaksi yang baru, selain bidang authorization_list, yang lainnya mengikuti semantik yang sama dengan EIP-4844. Bidang ini adalah tipe daftar, yang dapat berisi beberapa entri otorisasi, di mana setiap entri otorisasi berisi:
Field authorization_list dalam satu transaksi dapat berisi beberapa akun yang diotorisasi berbeda yang ditandatangani oleh (EOA), yaitu penggagas transaksi dapat berbeda dari yang memberikan otorisasi, untuk memungkinkan operasi otorisasi di mana gas dibayar oleh yang memberikan otorisasi.
mewujudkan
Saat pemberi kuasa menandatangani data kuasa, mereka harus terlebih dahulu melakukan pengkodean RLP pada chain_id, address, dan nonce. Kemudian, data yang telah dikodekan akan dihitung dengan fungsi hash keccak256 bersama dengan angka MAGIC, untuk mendapatkan data yang akan ditandatangani. Terakhir, menggunakan kunci privat pemberi kuasa untuk menandatangani data yang telah di-hash, menghasilkan data y_parity, r, dan s. MAGIC (0x05) digunakan sebagai pemisah domain, tujuannya adalah untuk memastikan bahwa hasil tanda tangan yang berbeda jenis tidak akan bertabrakan.
Ketika chain_id yang diberikan oleh pemberi otorisasi adalah 0, itu berarti pemberi otorisasi mengizinkan untuk mereplay otorisasi ( di semua rantai EVM yang mendukung EIP-7702 dengan syarat nonce juga tepat cocok ).
Setelah pemberi kuasa menandatangani data kuasa, peng发起交易 akan mengumpulkannya dalam bidang authorization_list untuk ditandatangani dan disiarkan transaksi melalui RPC. Sebelum transaksi dimasukkan ke dalam blok untuk dieksekusi, Proposer akan terlebih dahulu melakukan pemeriksaan awal pada transaksi, di mana alamat to akan diperiksa secara ketat untuk memastikan bahwa transaksi ini bukan transaksi pembuatan kontrak, yaitu ketika mengirim transaksi tipe EIP-7702, alamat to transaksi tidak boleh kosong.
Pada saat yang sama, transaksi semacam ini mengharuskan bidang authorization_list untuk setidaknya menyertakan satu item otorisasi. Jika ada beberapa item otorisasi yang ditandatangani oleh otorisator yang sama, hanya item otorisasi terakhir yang akan berlaku.
Selama proses eksekusi transaksi, node akan terlebih dahulu menambah nilai nonce pengirim transaksi, lalu melakukan operasi applyAuthorization pada setiap entri otorisasi dalam authorization_list. Dalam operasi applyAuthorization, node akan terlebih dahulu memeriksa nonce pemberi otorisasi, kemudian menambah nonce pemberi otorisasi. Ini berarti bahwa jika pengirim transaksi dan pemberi otorisasi adalah pengguna yang sama (EOA), maka saat menandatangani transaksi otorisasi, nilai nonce harus ditambah 1.
Saat node menerapkan suatu entri otorisasi, jika terjadi kesalahan, entri otorisasi tersebut akan dilewati, transaksi tidak akan gagal, dan entri otorisasi lainnya akan terus diterapkan, sehingga memastikan bahwa risiko DoS tidak muncul dalam skenario otorisasi massal.
Setelah aplikasi diotorisasi, field code dari alamat pemberi otorisasi akan diatur menjadi 0xef0100 || address, di mana 0xef0100 adalah identifikasi tetap, dan address adalah alamat tujuan yang didelegasikan. Karena batasan EIP-3541, pengguna tidak dapat menerapkan kode kontrak yang diawali dengan byte 0xef dengan cara biasa, ini memastikan bahwa identifikasi semacam itu hanya dapat diterapkan oleh transaksi tipe SET_CODE_TX_TYPE (0x04).
Setelah otorisasi selesai, jika pemberi otorisasi ingin menghapus otorisasi, cukup atur alamat target yang didelegasikan ke alamat 0.
Jenis transaksi baru yang diperkenalkan melalui EIP-7702 memungkinkan pemberi otorisasi (EOA) untuk mengeksekusi kode seperti kontrak pintar, sekaligus mempertahankan kemampuan untuk memulai transaksi. Dibandingkan dengan EIP-4337, ini memberikan pengguna pengalaman yang lebih mendekati abstraksi akun asli (Native AA), yang secara signifikan mengurangi ambang penggunaan bagi pengguna.
Praktik Terbaik
Meskipun EIP-7702 memberikan energi baru bagi ekosistem Ethereum, namun skenario aplikasi baru juga akan membawa risiko baru. Berikut adalah aspek-aspek yang perlu diwaspadai oleh para peserta ekosistem dalam proses praktik:
penyimpanan kunci pribadi
Meskipun EOA dapat memanfaatkan metode pemulihan sosial yang tertanam dalam kontrak pintar untuk mengatasi masalah kehilangan dana akibat kunci privat yang hilang setelah penugasan, tetap ada risiko kebocoran kunci privat EOA yang tidak dapat dihindari. Perlu ditegaskan bahwa setelah melakukan penugasan, kunci privat EOA tetap memiliki kontrol tertinggi atas akun, dan siapa pun yang memegang kunci privat dapat dengan bebas mengelola aset dalam akun tersebut. Pengguna atau penyedia layanan dompet, setelah menyelesaikan penugasan untuk EOA, meskipun sepenuhnya menghapus kunci privat yang disimpan secara lokal, tidak dapat sepenuhnya menghilangkan risiko kebocoran kunci privat, terutama dalam skenario yang memiliki risiko serangan rantai pasokan.
Bagi pengguna, saat menggunakan akun setelah melakukan delegasi, tetap harus mengutamakan perlindungan kunci privat, selalu ingat: Not your keys, not your coins.
Multi-chain replay
Pengguna dapat memilih rantai yang dapat berfungsi melalui chainId saat menandatangani otorisasi delegasi, tentu saja pengguna juga dapat memilih untuk menggunakan chainId 0 untuk delegasi, ini memungkinkan delegasi dapat direplikasi dan berfungsi di banyak rantai, sehingga memudahkan pengguna untuk melakukan delegasi dengan satu tanda tangan di banyak rantai. Namun perlu diperhatikan, bahwa di alamat kontrak yang sama di banyak rantai, mungkin juga terdapat kode implementasi yang berbeda.
Bagi penyedia layanan dompet, saat pengguna melakukan delegasi, mereka harus memeriksa apakah rantai yang efektif untuk delegasi sesuai dengan jaringan yang terhubung saat ini, dan mengingatkan pengguna tentang risiko yang mungkin timbul dari menandatangani delegasi dengan chainId 0.
Pengguna juga harus memperhatikan bahwa alamat kontrak yang sama di rantai yang berbeda tidak selalu memiliki kode kontrak yang sama, dan harus terlebih dahulu memahami tujuan penugasan.
tidak dapat diinisialisasi
Dompet kontrak pintar yang saat ini populer sebagian besar menggunakan model proxy, di mana proxy dompet saat penyebaran akan memanggil fungsi inisialisasi kontrak melalui DELEGateCALL, untuk mencapai operasi atomik antara inisialisasi dompet dan penyebaran dompet proxy, menghindari masalah inisialisasi yang dilakukan lebih dahulu. Namun, saat pengguna menggunakan EIP-7702 untuk melakukan delegasi, hanya akan memperbarui field code dari alamatnya, dan tidak dapat melakukan inisialisasi melalui pemanggilan alamat delegasi. Ini membuat EIP-7702 tidak dapat melakukan inisialisasi dompet dalam transaksi penyebaran kontrak seperti kontrak proxy ERC-1967 yang umum.
Bagi pengembang, saat menggabungkan EIP-7702 dengan dompet EIP-4337 yang ada, harus diperhatikan untuk melakukan pemeriksaan izin dalam operasi inisialisasi dompet, misalnya dengan menggunakan ecrecover untuk memulihkan alamat tanda tangan untuk melakukan pemeriksaan izin, untuk menghindari risiko operasi inisialisasi dompet yang dapat dikejar.
( Manajemen Penyimpanan
Pengguna yang menggunakan fungsi delegasi EIP-7702 mungkin perlu mendelegasikan kembali ke alamat kontrak yang berbeda karena perubahan kebutuhan fungsi, peningkatan dompet, dan alasan lainnya. Namun, struktur penyimpanan kontrak yang berbeda mungkin memiliki perbedaan. ) Misalnya, slot0 dari kontrak yang berbeda mungkin mewakili jenis data yang berbeda. ### Dalam kasus delegasi ulang, mungkin saja kontrak baru secara tidak sengaja menggunakan data dari kontrak lama, yang dapat menyebabkan penguncian akun, kerugian dana, dan konsekuensi buruk lainnya.
Bagi pengguna, perlu berhati-hati dalam menangani situasi delegasi ulang.
Bagi pengembang, selama proses pengembangan harus mengikuti Namespace Formula yang diusulkan oleh ERC-7201, untuk mengalokasikan variabel ke lokasi penyimpanan independen yang ditentukan, guna mengurangi risiko konflik penyimpanan. Selain itu, ERC-7779 (draft) juga menyediakan proses standar untuk delegasi ulang khusus untuk EIP-7702: termasuk penggunaan ERC-7201 untuk mencegah konflik penyimpanan, serta memverifikasi kompatibilitas penyimpanan sebelum melakukan delegasi ulang, dan memanggil antarmuka delegasi lama untuk membersihkan data lama dari penyimpanan.
( Isi Ulang Palsu
Setelah pengguna melakukan penugasan, EOA juga dapat digunakan sebagai kontrak pintar, oleh karena itu bursa terpusat )CEX### mungkin akan menghadapi situasi di mana pengisian ulang kontrak pintar menjadi umum.
CEX harus memeriksa status setiap transaksi deposit melalui trace, untuk mencegah risiko deposit palsu pada kontrak pintar.
( Konversi Akun
Setelah menerapkan delegasi EIP-7702, jenis akun pengguna dapat beralih dengan bebas antara EOA dan SC, yang memungkinkan akun untuk melakukan transaksi dan juga dipanggil. Ini berarti ketika akun memanggil dirinya sendiri dan melakukan panggilan eksternal, msg.sender-nya juga akan menjadi tx.origin, yang akan mematahkan beberapa asumsi keamanan yang hanya membatasi partisipasi proyek kepada EOA.
Bagi pengembang kontrak, mengasumsikan tx.origin selalu merupakan EOA tidak lagi dapat diterima. Begitu pula, pemeriksaan msg.sender == tx.origin untuk mencegah serangan reentrancy juga akan gagal.
Pengembang seharusnya menganggap bahwa peserta di masa depan mungkin semuanya adalah kontrak pintar.
) Kompatibilitas kontrak
Token ERC-721 dan ERC-777 yang ada memiliki fungsi Hook saat melakukan transfer kontrak, yang berarti penerima harus mengimplementasikan fungsi callback yang sesuai untuk berhasil menerima token.
Bagi pengembang, kontrak tujuan yang didelegasikan oleh pengguna seharusnya mengimplementasikan fungsi callback yang sesuai, untuk memastikan kompatibilitas dengan token mainstream.
Pemeriksaan Memancing
Setelah mengimplementasikan EIP-7702, aset dalam akun pengguna mungkin akan dikendalikan oleh kontrak pintar. Begitu pengguna mendelegasikan akunnya ke kontrak jahat, penyerang akan dapat mencuri dana dengan sangat mudah.
Bagi penyedia layanan dompet, sangat penting untuk segera mendukung transaksi jenis EIP-7702, dan saat pengguna melakukan tanda tangan delegasi, harus menampilkan secara jelas kontrak tujuan delegasi kepada pengguna, untuk mengurangi risiko yang mungkin dialami pengguna akibat serangan phishing.
Selain itu, melakukan analisis otomatis yang lebih mendalam terhadap kontrak target yang ditugaskan ke akun ###, pemeriksaan sumber terbuka, pemeriksaan izin, dan lain-lain ### dapat lebih baik membantu pengguna menghindari risiko semacam itu.
Ringkasan
Artikel ini membahas proposal EIP-7702 dalam peningkatan Pectra Ethereum yang akan datang. EIP-7702 memperkenalkan jenis transaksi baru yang memberikan EOA kemampuan pemrograman dan komposabilitas, yang mengaburkan batas antara EOA dan akun kontrak. Karena saat ini belum ada standar kontrak pintar kompatibel EIP-7702 yang teruji dalam praktik, berbagai peserta ekosistem, seperti pengguna, penyedia layanan dompet, pengembang, CEX, dan lainnya, menghadapi banyak tantangan dan peluang dalam aplikasi praktis. Konten praktik terbaik yang dijelaskan dalam artikel ini tidak dapat mencakup semua risiko potensial, tetapi tetap layak untuk dijadikan referensi dalam operasi praktis oleh semua pihak.