Ethereum akan segera menyambut pembaruan Pectra, yang merupakan pembaruan yang sangat signifikan dan akan memperkenalkan beberapa proposal perbaikan penting. Di antara proposal tersebut, EIP-7702 melakukan transformasi yang revolusioner terhadap 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 diharapkan segera diluncurkan di jaringan utama. Artikel ini akan menganalisis secara mendalam mekanisme implementasi EIP-7702, membahas peluang dan tantangan yang mungkin ditimbulkannya, serta memberikan panduan praktis bagi berbagai peserta.
Analisis Protokol
Ringkasan
EIP-7702 memperkenalkan jenis transaksi baru yang memungkinkan EOA untuk menentukan alamat kontrak pintar dan mengatur kode untuknya. Ini memungkinkan EOA untuk menjalankan kode seperti kontrak pintar, sambil mempertahankan kemampuan untuk memulai transaksi. Fitur ini memberikan EOA kemampuan pemrograman dan komposisi, di mana pengguna dapat menerapkan fungsi pemulihan sosial, kontrol izin, manajemen multi-tanda tangan, verifikasi zk, pembayaran berlangganan, sponsor transaksi, dan pemrosesan batch transaksi. Perlu dicatat bahwa EIP-7702 kompatibel sempurna dengan dompet kontrak pintar yang diimplementasikan oleh EIP-4337, dan integrasi tanpa hambatan 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:
chain_id menunjukkan rantai di mana kuasa delegasi ini berlaku
address menunjukkan alamat tujuan dari perwakilan
nonce harus cocok dengan nonce dari akun yang saat ini diotorisasi
y_parity, r, s adalah data tanda tangan yang ditandatangani oleh akun yang diberikan wewenang
Bidang authorization_list dalam satu transaksi dapat mencakup beberapa akun otorisasi yang berbeda. ( EOA ) menandatangani entri otorisasi, yaitu penggagas transaksi dapat berbeda dari pemberi otorisasi, untuk memungkinkan operasi otorisasi oleh pemberi otorisasi untuk dibayar dengan gas.
mewujudkan
Pemberi otorisasi harus melakukan pengkodean RLP pada chain_id, address, dan nonce sebelum menandatangani data otorisasi. Kemudian, data yang telah dikodekan dikombinasikan dengan angka MAGIC untuk melakukan operasi hash keccak256, menghasilkan data yang akan ditandatangani. Akhirnya, gunakan kunci privat pemberi otorisasi untuk menandatangani data yang telah di-hash, menghasilkan data y_parity, r, s. MAGIC (0x05) digunakan sebagai pemisah domain, dengan tujuan untuk memastikan bahwa hasil tanda tangan yang berbeda tidak akan bertabrakan.
Perlu dicatat bahwa ketika chain_id yang diberikan oleh pemberi otorisasi adalah 0, itu berarti pemberi otorisasi mengizinkan untuk mereplikasi otorisasi ( di semua rantai yang kompatibel dengan EVM yang mendukung EIP-7702 dengan syarat nonce juga tepat cocok ).
Setelah pemberi otorisasi menandatangani data otorisasi, penggagas transaksi akan mengumpulkannya di bidang authorization_list untuk ditandatangani dan disiarkan melalui RPC. Sebelum transaksi dieksekusi dan dimasukkan ke dalam blok, Proposer akan melakukan pemeriksaan awal terhadap transaksi, di mana alamat to akan diperiksa secara ketat untuk memastikan bahwa transaksi ini bukan transaksi pembuatan kontrak, yang berarti bahwa saat mengirim transaksi tipe EIP-7702, alamat to dari transaksi tidak boleh kosong.
Sementara itu, transaksi semacam itu akan mewajibkan bahwa field authorization_list dalam transaksi harus setidaknya berisi satu entri otorisasi. Jika ada beberapa entri otorisasi yang ditandatangani oleh otorisator yang sama, maka hanya entri otorisasi terakhir yang akan berlaku.
Selanjutnya, selama proses eksekusi transaksi, node akan terlebih dahulu menambah nilai nonce dari pengirim transaksi, kemudian melakukan operasi applyAuthorization untuk setiap entri otorisasi dalam authorization_list. Dalam operasi applyAuthorization, node akan terlebih dahulu memeriksa nonce dari pemberi otorisasi, lalu menambah nonce pemberi otorisasi. Ini berarti jika pengirim transaksi dan pemberi otorisasi adalah pengguna yang sama (EOA), 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 tidak ada risiko DoS dalam skenario otorisasi massal.
Setelah aplikasi otorisasi selesai, field code pada alamat pemberi otorisasi akan diatur menjadi 0xef0100 || address, di mana 0xef0100 adalah identifikasi tetap, dan address adalah alamat tujuan yang diwakilkan. Karena pembatasan EIP-3541, pengguna tidak dapat menerapkan kode kontrak yang dimulai dengan byte 0xef dengan cara biasa, yang menjamin bahwa identifikasi semacam ini hanya dapat diterapkan oleh transaksi tipe SET_CODE_TX_TYPE (0x04).
Setelah otorisasi selesai, jika pemberi otorisasi ingin menghapus otorisasi, cukup atur alamat tujuan yang dikuasakan ke alamat 0.
Melalui jenis transaksi baru yang diperkenalkan oleh EIP-7702, pemberi otorisasi (EOA) dapat menjalankan kode seperti kontrak pintar, sambil tetap 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 telah menginject energi baru ke dalam ekosistem Ethereum, namun skenario aplikasi baru juga akan membawa risiko baru. Berikut adalah aspek-aspek yang perlu diperhatikan oleh para peserta ekosistem dalam proses praktik:
penyimpanan kunci pribadi
Meskipun EOA dapat menggunakan metode pemulihan sosial bawaan dari kontrak pintar untuk mengatasi masalah kehilangan dana akibat kehilangan kunci pribadi setelah delegasi, itu masih tidak dapat menghindari risiko kebocoran kunci pribadi EOA. Perlu dipahami bahwa setelah melaksanakan delegasi, kunci pribadi EOA tetap memiliki kontrol tertinggi atas akun, dan siapa pun yang memiliki kunci pribadi dapat dengan bebas mengelola aset dalam akun. Pengguna atau penyedia layanan dompet, setelah menyelesaikan delegasi untuk EOA, meskipun sepenuhnya menghapus kunci pribadi yang disimpan secara lokal, tidak dapat sepenuhnya menghilangkan risiko kebocoran kunci pribadi, terutama dalam skenario yang berisiko serangan rantai pasokan.
Bagi pengguna, saat menggunakan akun setelah melakukan delegasi, pengguna tetap harus memprioritaskan perlindungan kunci pribadi, selalu ingat: Not your keys, not your coins.
Pemutaran Multi-Rantai
Pengguna saat menandatangani otorisasi delegasi, dapat memilih rantai yang dapat diaktifkan menggunakan chainId, tentu saja pengguna juga dapat memilih untuk menggunakan chainId 0 untuk melakukan delegasi, ini memungkinkan delegasi dapat direplikasi di banyak rantai, sehingga memudahkan pengguna untuk menandatangani sekali dan melakukan delegasi di banyak rantai. Namun perlu dicatat bahwa dalam alamat kontrak yang sama di banyak rantai, mungkin ada kode implementasi yang berbeda.
Bagi penyedia layanan dompet, saat pengguna melakukan penunjukan, mereka harus memeriksa apakah rantai yang berlaku untuk penunjukan sesuai dengan jaringan yang sedang terhubung, dan mengingatkan pengguna tentang risiko yang mungkin ditimbulkan dengan menandatangani penunjukan dengan chainId 0.
Pengguna juga harus memperhatikan bahwa alamat kontrak yang sama di berbagai rantai tidak selalu memiliki kode kontrak yang sama, dan harus memahami tujuan dari delegasi terlebih dahulu.
tidak dapat diinisialisasi
Dompet kontrak pintar yang saat ini populer sebagian besar menggunakan model proxy. Ketika dompet proxy diterapkan, ia akan memanggil fungsi inisialisasi kontrak melalui DELEGateCALL untuk mencapai operasi atomik antara inisialisasi dompet dan penerapan dompet proxy, sehingga menghindari masalah inisialisasi yang lebih awal. Namun, saat pengguna menggunakan EIP-7702 untuk delegasi, ia hanya akan memperbarui bidang kode alamatnya, dan tidak dapat melakukan inisialisasi melalui pemanggilan alamat delegasi. Ini membuat EIP-7702 tidak dapat memanggil fungsi inisialisasi dalam transaksi penerapan kontrak seperti kontrak proxy ERC-1967 yang umum.
Bagi pengembang, saat menggabungkan EIP-7702 dengan dompet EIP-4337 yang ada, perlu diperhatikan untuk melakukan pemeriksaan izin selama operasi inisialisasi dompet, misalnya dengan menggunakan ecrecover untuk memulihkan alamat tanda tangan untuk pemeriksaan izin, agar menghindari risiko operasi inisialisasi dompet yang terlewati.
( Manajemen Penyimpanan
Pengguna yang menggunakan fitur delegasi EIP-7702 mungkin perlu mendelegasikan ulang ke alamat kontrak yang berbeda karena perubahan kebutuhan fungsional, pembaruan dompet, dan alasan lainnya. Namun, struktur penyimpanan dari kontrak yang berbeda mungkin memiliki perbedaan, seperti slot0 dari kontrak yang berbeda mungkin mewakili jenis data yang berbeda. Dalam keadaan mendelegasikan ulang, ada kemungkinan kontrak baru secara tidak sengaja menggunakan data dari kontrak lama, yang dapat mengakibatkan penguncian akun, kehilangan dana, dan konsekuensi buruk lainnya.
Pengguna harus berhati-hati dalam menangani situasi delegasi ulang.
Bagi pengembang, selama proses pengembangan, harus mengikuti Namespace Formula yang diusulkan oleh ERC-7201, dengan mengalokasikan variabel ke lokasi penyimpanan independen yang ditentukan, untuk mengurangi risiko konflik penyimpanan. Selain itu, ERC-7779 )draft### juga menyediakan proses standar untuk delegasi ulang khusus untuk EIP-7702: termasuk menggunakan ERC-7201 untuk mencegah konflik penyimpanan, serta memverifikasi kompatibilitas penyimpanan sebelum delegasi ulang, dan memanggil antarmuka delegasi lama untuk membersihkan data lama dari penyimpanan.
( Pengisian Palsu
Setelah pengguna melakukan perintah, EOA juga akan dapat digunakan sebagai kontrak pintar, sehingga bursa mungkin akan menghadapi situasi umum di mana pengisian ulang kontrak pintar menjadi umum.
Bursa harus memeriksa status setiap transaksi deposit melalui trace untuk mencegah risiko deposit palsu pada kontrak pintar.
) Konversi akun
Setelah menerapkan delegasi EIP-7702, tipe akun pengguna dapat beralih bebas antara EOA dan SC, yang memungkinkan akun untuk melakukan transaksi serta dipanggil. Ini berarti bahwa ketika akun memanggil dirinya sendiri dan melakukan panggilan eksternal, msg.sender-nya juga akan menjadi tx.origin, yang akan menghancurkan beberapa asumsi keamanan yang hanya membatasi partisipasi proyek kepada EOA.
Bagi pengembang kontrak, mengasumsikan bahwa tx.origin selalu merupakan EOA tidak akan lagi berlaku. Demikian pula, pemeriksaan melalui msg.sender == tx.origin untuk mencegah serangan reentrancy juga akan gagal.
Pengembang seharusnya mengasumsikan bahwa peserta di masa depan mungkin semua adalah kontrak pintar.
( kompatibilitas kontrak
Token ERC-721 dan ERC-777 yang ada memiliki fungsi Hook saat melakukan transfer ke kontrak, yang berarti penerima harus mengimplementasikan fungsi callback yang sesuai untuk berhasil menerima token.
Bagi pengembang, kontrak target yang didelegasikan oleh pengguna seharusnya mengimplementasikan fungsi callback yang sesuai, untuk memastikan kompatibilitas dengan token utama.
) pemeriksaan pancing
Setelah menerapkan delegasi EIP-7702, aset dalam akun pengguna mungkin akan dikendalikan oleh kontrak pintar. Begitu pengguna mendelegasikan akunnya ke kontrak yang berbahaya, maka pencuri akan dengan mudah mencuri dana.
Bagi penyedia layanan dompet, sangat penting untuk segera mendukung transaksi tipe EIP-7702, dan saat pengguna melakukan tanda tangan delegasi, harus menampilkan kontrak tujuan delegasi kepada pengguna untuk mengurangi risiko serangan phishing yang mungkin mereka alami.
Selain itu, analisis otomatis yang lebih mendalam terhadap kontrak target yang dikuasakan oleh akun, termasuk pemeriksaan sumber terbuka, pemeriksaan izin, dan lainnya, ### dapat lebih baik membantu pengguna menghindari risiko semacam ini.
Ringkasan
Artikel ini membahas proposal EIP-7702 dalam pembaruan Pectra Ethereum yang akan datang. EIP-7702 memperkenalkan jenis transaksi baru yang memungkinkan EOA memiliki kemampuan pemrograman dan komposibilitas, sehingga mengaburkan batas antara EOA dan akun kontrak. Karena saat ini belum ada standar kontrak pintar yang kompatibel dengan jenis EIP-7702 yang telah teruji di lapangan, berbagai peserta ekosistem seperti pengguna, penyedia dompet, pengembang, bursa, dan lain-lain, menghadapi banyak tantangan dan peluang dalam aplikasi praktis. Konten praktik terbaik yang diuraikan dalam artikel ini tidak dapat mencakup semua risiko potensial, tetapi tetap layak untuk dijadikan rujukan dalam operasi nyata.
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.
6 Suka
Hadiah
6
5
Bagikan
Komentar
0/400
PermabullPete
· 19jam yang lalu
get on board just roll Buku Pesanan will explode again
Lihat AsliBalas0
StablecoinEnjoyer
· 19jam yang lalu
Sedikit terlalu maju, rasanya Vitalik Buterin lagi mengerjakan hal besar.
Lihat AsliBalas0
Token_Sherpa
· 19jam yang lalu
meh... proposal lain yang tidak akan memperbaiki masalah nyata eth sejujurnya
EIP-7702 Kedalaman analisis: Upgrade Pectra Ethereum akan mengaburkan batasan antara EOA dan CA
Ethereum Pectra Upgrade: EIP-7702 Kedalaman Analisis
Pendahuluan
Ethereum akan segera menyambut pembaruan Pectra, yang merupakan pembaruan yang sangat signifikan dan akan memperkenalkan beberapa proposal perbaikan penting. Di antara proposal tersebut, EIP-7702 melakukan transformasi yang revolusioner terhadap 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 diharapkan segera diluncurkan di jaringan utama. Artikel ini akan menganalisis secara mendalam mekanisme implementasi EIP-7702, membahas peluang dan tantangan yang mungkin ditimbulkannya, serta memberikan panduan praktis bagi berbagai peserta.
Analisis Protokol
Ringkasan
EIP-7702 memperkenalkan jenis transaksi baru yang memungkinkan EOA untuk menentukan alamat kontrak pintar dan mengatur kode untuknya. Ini memungkinkan EOA untuk menjalankan kode seperti kontrak pintar, sambil mempertahankan kemampuan untuk memulai transaksi. Fitur ini memberikan EOA kemampuan pemrograman dan komposisi, di mana pengguna dapat menerapkan fungsi pemulihan sosial, kontrol izin, manajemen multi-tanda tangan, verifikasi zk, pembayaran berlangganan, sponsor transaksi, dan pemrosesan batch transaksi. Perlu dicatat bahwa EIP-7702 kompatibel sempurna dengan dompet kontrak pintar yang diimplementasikan oleh EIP-4337, dan integrasi tanpa hambatan 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])
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:
Bidang authorization_list dalam satu transaksi dapat mencakup beberapa akun otorisasi yang berbeda. ( EOA ) menandatangani entri otorisasi, yaitu penggagas transaksi dapat berbeda dari pemberi otorisasi, untuk memungkinkan operasi otorisasi oleh pemberi otorisasi untuk dibayar dengan gas.
mewujudkan
Pemberi otorisasi harus melakukan pengkodean RLP pada chain_id, address, dan nonce sebelum menandatangani data otorisasi. Kemudian, data yang telah dikodekan dikombinasikan dengan angka MAGIC untuk melakukan operasi hash keccak256, menghasilkan data yang akan ditandatangani. Akhirnya, gunakan kunci privat pemberi otorisasi untuk menandatangani data yang telah di-hash, menghasilkan data y_parity, r, s. MAGIC (0x05) digunakan sebagai pemisah domain, dengan tujuan untuk memastikan bahwa hasil tanda tangan yang berbeda tidak akan bertabrakan.
Perlu dicatat bahwa ketika chain_id yang diberikan oleh pemberi otorisasi adalah 0, itu berarti pemberi otorisasi mengizinkan untuk mereplikasi otorisasi ( di semua rantai yang kompatibel dengan EVM yang mendukung EIP-7702 dengan syarat nonce juga tepat cocok ).
Setelah pemberi otorisasi menandatangani data otorisasi, penggagas transaksi akan mengumpulkannya di bidang authorization_list untuk ditandatangani dan disiarkan melalui RPC. Sebelum transaksi dieksekusi dan dimasukkan ke dalam blok, Proposer akan melakukan pemeriksaan awal terhadap transaksi, di mana alamat to akan diperiksa secara ketat untuk memastikan bahwa transaksi ini bukan transaksi pembuatan kontrak, yang berarti bahwa saat mengirim transaksi tipe EIP-7702, alamat to dari transaksi tidak boleh kosong.
Sementara itu, transaksi semacam itu akan mewajibkan bahwa field authorization_list dalam transaksi harus setidaknya berisi satu entri otorisasi. Jika ada beberapa entri otorisasi yang ditandatangani oleh otorisator yang sama, maka hanya entri otorisasi terakhir yang akan berlaku.
Selanjutnya, selama proses eksekusi transaksi, node akan terlebih dahulu menambah nilai nonce dari pengirim transaksi, kemudian melakukan operasi applyAuthorization untuk setiap entri otorisasi dalam authorization_list. Dalam operasi applyAuthorization, node akan terlebih dahulu memeriksa nonce dari pemberi otorisasi, lalu menambah nonce pemberi otorisasi. Ini berarti jika pengirim transaksi dan pemberi otorisasi adalah pengguna yang sama (EOA), 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 tidak ada risiko DoS dalam skenario otorisasi massal.
Setelah aplikasi otorisasi selesai, field code pada alamat pemberi otorisasi akan diatur menjadi 0xef0100 || address, di mana 0xef0100 adalah identifikasi tetap, dan address adalah alamat tujuan yang diwakilkan. Karena pembatasan EIP-3541, pengguna tidak dapat menerapkan kode kontrak yang dimulai dengan byte 0xef dengan cara biasa, yang menjamin bahwa identifikasi semacam ini hanya dapat diterapkan oleh transaksi tipe SET_CODE_TX_TYPE (0x04).
Setelah otorisasi selesai, jika pemberi otorisasi ingin menghapus otorisasi, cukup atur alamat tujuan yang dikuasakan ke alamat 0.
Melalui jenis transaksi baru yang diperkenalkan oleh EIP-7702, pemberi otorisasi (EOA) dapat menjalankan kode seperti kontrak pintar, sambil tetap 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 telah menginject energi baru ke dalam ekosistem Ethereum, namun skenario aplikasi baru juga akan membawa risiko baru. Berikut adalah aspek-aspek yang perlu diperhatikan oleh para peserta ekosistem dalam proses praktik:
penyimpanan kunci pribadi
Meskipun EOA dapat menggunakan metode pemulihan sosial bawaan dari kontrak pintar untuk mengatasi masalah kehilangan dana akibat kehilangan kunci pribadi setelah delegasi, itu masih tidak dapat menghindari risiko kebocoran kunci pribadi EOA. Perlu dipahami bahwa setelah melaksanakan delegasi, kunci pribadi EOA tetap memiliki kontrol tertinggi atas akun, dan siapa pun yang memiliki kunci pribadi dapat dengan bebas mengelola aset dalam akun. Pengguna atau penyedia layanan dompet, setelah menyelesaikan delegasi untuk EOA, meskipun sepenuhnya menghapus kunci pribadi yang disimpan secara lokal, tidak dapat sepenuhnya menghilangkan risiko kebocoran kunci pribadi, terutama dalam skenario yang berisiko serangan rantai pasokan.
Bagi pengguna, saat menggunakan akun setelah melakukan delegasi, pengguna tetap harus memprioritaskan perlindungan kunci pribadi, selalu ingat: Not your keys, not your coins.
Pemutaran Multi-Rantai
Pengguna saat menandatangani otorisasi delegasi, dapat memilih rantai yang dapat diaktifkan menggunakan chainId, tentu saja pengguna juga dapat memilih untuk menggunakan chainId 0 untuk melakukan delegasi, ini memungkinkan delegasi dapat direplikasi di banyak rantai, sehingga memudahkan pengguna untuk menandatangani sekali dan melakukan delegasi di banyak rantai. Namun perlu dicatat bahwa dalam alamat kontrak yang sama di banyak rantai, mungkin ada kode implementasi yang berbeda.
Bagi penyedia layanan dompet, saat pengguna melakukan penunjukan, mereka harus memeriksa apakah rantai yang berlaku untuk penunjukan sesuai dengan jaringan yang sedang terhubung, dan mengingatkan pengguna tentang risiko yang mungkin ditimbulkan dengan menandatangani penunjukan dengan chainId 0.
Pengguna juga harus memperhatikan bahwa alamat kontrak yang sama di berbagai rantai tidak selalu memiliki kode kontrak yang sama, dan harus memahami tujuan dari delegasi terlebih dahulu.
tidak dapat diinisialisasi
Dompet kontrak pintar yang saat ini populer sebagian besar menggunakan model proxy. Ketika dompet proxy diterapkan, ia akan memanggil fungsi inisialisasi kontrak melalui DELEGateCALL untuk mencapai operasi atomik antara inisialisasi dompet dan penerapan dompet proxy, sehingga menghindari masalah inisialisasi yang lebih awal. Namun, saat pengguna menggunakan EIP-7702 untuk delegasi, ia hanya akan memperbarui bidang kode alamatnya, dan tidak dapat melakukan inisialisasi melalui pemanggilan alamat delegasi. Ini membuat EIP-7702 tidak dapat memanggil fungsi inisialisasi dalam transaksi penerapan kontrak seperti kontrak proxy ERC-1967 yang umum.
Bagi pengembang, saat menggabungkan EIP-7702 dengan dompet EIP-4337 yang ada, perlu diperhatikan untuk melakukan pemeriksaan izin selama operasi inisialisasi dompet, misalnya dengan menggunakan ecrecover untuk memulihkan alamat tanda tangan untuk pemeriksaan izin, agar menghindari risiko operasi inisialisasi dompet yang terlewati.
( Manajemen Penyimpanan
Pengguna yang menggunakan fitur delegasi EIP-7702 mungkin perlu mendelegasikan ulang ke alamat kontrak yang berbeda karena perubahan kebutuhan fungsional, pembaruan dompet, dan alasan lainnya. Namun, struktur penyimpanan dari kontrak yang berbeda mungkin memiliki perbedaan, seperti slot0 dari kontrak yang berbeda mungkin mewakili jenis data yang berbeda. Dalam keadaan mendelegasikan ulang, ada kemungkinan kontrak baru secara tidak sengaja menggunakan data dari kontrak lama, yang dapat mengakibatkan penguncian akun, kehilangan dana, dan konsekuensi buruk lainnya.
Pengguna harus berhati-hati dalam menangani situasi delegasi ulang.
Bagi pengembang, selama proses pengembangan, harus mengikuti Namespace Formula yang diusulkan oleh ERC-7201, dengan mengalokasikan variabel ke lokasi penyimpanan independen yang ditentukan, untuk mengurangi risiko konflik penyimpanan. Selain itu, ERC-7779 )draft### juga menyediakan proses standar untuk delegasi ulang khusus untuk EIP-7702: termasuk menggunakan ERC-7201 untuk mencegah konflik penyimpanan, serta memverifikasi kompatibilitas penyimpanan sebelum delegasi ulang, dan memanggil antarmuka delegasi lama untuk membersihkan data lama dari penyimpanan.
( Pengisian Palsu
Setelah pengguna melakukan perintah, EOA juga akan dapat digunakan sebagai kontrak pintar, sehingga bursa mungkin akan menghadapi situasi umum di mana pengisian ulang kontrak pintar menjadi umum.
Bursa harus memeriksa status setiap transaksi deposit melalui trace untuk mencegah risiko deposit palsu pada kontrak pintar.
) Konversi akun
Setelah menerapkan delegasi EIP-7702, tipe akun pengguna dapat beralih bebas antara EOA dan SC, yang memungkinkan akun untuk melakukan transaksi serta dipanggil. Ini berarti bahwa ketika akun memanggil dirinya sendiri dan melakukan panggilan eksternal, msg.sender-nya juga akan menjadi tx.origin, yang akan menghancurkan beberapa asumsi keamanan yang hanya membatasi partisipasi proyek kepada EOA.
Bagi pengembang kontrak, mengasumsikan bahwa tx.origin selalu merupakan EOA tidak akan lagi berlaku. Demikian pula, pemeriksaan melalui msg.sender == tx.origin untuk mencegah serangan reentrancy juga akan gagal.
Pengembang seharusnya mengasumsikan bahwa peserta di masa depan mungkin semua adalah kontrak pintar.
( kompatibilitas kontrak
Token ERC-721 dan ERC-777 yang ada memiliki fungsi Hook saat melakukan transfer ke kontrak, yang berarti penerima harus mengimplementasikan fungsi callback yang sesuai untuk berhasil menerima token.
Bagi pengembang, kontrak target yang didelegasikan oleh pengguna seharusnya mengimplementasikan fungsi callback yang sesuai, untuk memastikan kompatibilitas dengan token utama.
) pemeriksaan pancing
Setelah menerapkan delegasi EIP-7702, aset dalam akun pengguna mungkin akan dikendalikan oleh kontrak pintar. Begitu pengguna mendelegasikan akunnya ke kontrak yang berbahaya, maka pencuri akan dengan mudah mencuri dana.
Bagi penyedia layanan dompet, sangat penting untuk segera mendukung transaksi tipe EIP-7702, dan saat pengguna melakukan tanda tangan delegasi, harus menampilkan kontrak tujuan delegasi kepada pengguna untuk mengurangi risiko serangan phishing yang mungkin mereka alami.
Selain itu, analisis otomatis yang lebih mendalam terhadap kontrak target yang dikuasakan oleh akun, termasuk pemeriksaan sumber terbuka, pemeriksaan izin, dan lainnya, ### dapat lebih baik membantu pengguna menghindari risiko semacam ini.
Ringkasan
Artikel ini membahas proposal EIP-7702 dalam pembaruan Pectra Ethereum yang akan datang. EIP-7702 memperkenalkan jenis transaksi baru yang memungkinkan EOA memiliki kemampuan pemrograman dan komposibilitas, sehingga mengaburkan batas antara EOA dan akun kontrak. Karena saat ini belum ada standar kontrak pintar yang kompatibel dengan jenis EIP-7702 yang telah teruji di lapangan, berbagai peserta ekosistem seperti pengguna, penyedia dompet, pengembang, bursa, dan lain-lain, menghadapi banyak tantangan dan peluang dalam aplikasi praktis. Konten praktik terbaik yang diuraikan dalam artikel ini tidak dapat mencakup semua risiko potensial, tetapi tetap layak untuk dijadikan rujukan dalam operasi nyata.