Ethereum Pectra Upgrade: EIP-7702 Membawa Perubahan Revolusioner untuk EOA
Pendahuluan
Ethereum akan segera menyambut upgrade Pectra, yang merupakan pembaruan yang sangat signifikan, dengan banyak proposal perbaikan penting yang akan diperkenalkan. Di antara mereka, EIP-7702 membawa transformasi yang revolusioner terhadap akun eksternal Ethereum (EOA). Proposal ini mengaburkan batasan antara EOA dan akun kontrak CA, menjadi langkah kunci menuju abstraksi akun asli setelah EIP-4337, membawa mode interaksi baru ke ekosistem Ethereum.
Pectra telah menyelesaikan penerapan di jaringan pengujian, dan diharapkan 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 berbasis langganan, sponsor transaksi, dan pemrosesan batch transaksi dalam EOA. Perlu dicatat bahwa EIP-7702 dapat berfungsi dengan baik dengan dompet kontrak pintar yang diimplementasikan oleh EIP-4337, integrasi tanpa batas keduanya sangat menyederhanakan proses pengembangan dan penerapan fitur baru.
EIP-7702 memperkenalkan jenis transaksi SET_CODE_TX_TYPE (0x04), dengan struktur data yang didefinisikan sebagai berikut:
Dalam struktur transaksi yang baru, selain field authorization_list, yang lainnya mengikuti makna yang sama dengan EIP-4844. Field ini adalah tipe daftar, yang dapat berisi beberapa entri otorisasi, masing-masing entri otorisasi:
chain_id menunjukkan rantai di mana delegasi otorisasi ini berlaku
address menunjukkan alamat tujuan dari delegasi
nonce harus sesuai dengan nonce dari akun yang saat ini diotorisasi
y_parity, r, s adalah data tanda tangan yang ditandatangani oleh akun yang memberikan otorisasi
Bidang authorization_list dalam sebuah transaksi dapat mencakup beberapa akun otorisasi yang berbeda, yaitu entri otorisasi yang ditandatangani oleh (EOA), sehingga penggagas transaksi dapat berbeda dengan pemberi otorisasi, untuk melakukan pembayaran gas atas operasi otorisasi pemberi otorisasi.
merealisasikan
Ketika pemberi otorisasi menandatangani data otorisasi, mereka harus terlebih dahulu melakukan pengkodean RLP terhadap chain_id, address, dan nonce. Kemudian, data yang telah dikodekan bersama dengan angka MAGIC dihitung menggunakan hash keccak256, menghasilkan data yang akan ditandatangani. Terakhir, gunakan kunci privat pemberi otorisasi untuk menandatangani data yang telah di-hash, mendapatkan data y_parity, r, dan s. MAGIC (0x05) digunakan sebagai pemisah domain, dengan tujuan untuk memastikan bahwa hasil tanda tangan dari berbagai jenis tidak akan menghasilkan konflik.
Perlu diperhatikan, ketika chain_id yang diberikan oleh pemberi otorisasi adalah 0, itu berarti pemberi otorisasi mengizinkan untuk melakukan replay otorisasi ( di semua rantai yang kompatibel dengan EVM yang mendukung EIP-7702 dengan syarat nonce juga cocok ).
Setelah pemberi kuasa menandatangani data kuasa, peng发起交易 akan mengumpulkan data tersebut dalam bidang authorization_list untuk ditandatangani dan menyebarkan transaksi melalui RPC. Sebelum transaksi dimasukkan ke dalam blok untuk dieksekusi, Proposer akan melakukan pemeriksaan awal terhadap 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 dari transaksi tidak boleh kosong.
Selain itu, transaksi semacam ini secara paksa mensyaratkan bahwa kolom authorization_list harus berisi setidaknya satu entri otorisasi. Jika ada beberapa entri otorisasi yang ditandatangani oleh otorisator yang sama, hanya entri otorisasi terakhir yang berlaku.
Dalam proses eksekusi transaksi, node akan terlebih dahulu menambah nilai nonce dari pengirim transaksi, kemudian melakukan operasi applyAuthorization pada setiap entri otorisasi dalam authorization_list. Dalam operasi applyAuthorization, node akan terlebih dahulu memeriksa nonce dari pihak yang memberikan otorisasi, lalu menambah nonce dari pihak tersebut. Ini berarti jika pengirim transaksi dan pihak yang memberikan otorisasi adalah pengguna yang sama (EOA), maka saat menandatangani transaksi otorisasi, nilai nonce harus ditambah 1.
Saat node menerapkan entri otorisasi tertentu, jika terjadi kesalahan, entri otorisasi tersebut akan dilewati, transaksi tidak akan gagal, dan entri otorisasi lainnya akan terus diterapkan untuk memastikan tidak ada risiko DoS 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 dikuasakan. Karena batasan EIP-3541, pengguna tidak dapat menerapkan kode kontrak yang diawali dengan byte 0xef dengan cara biasa, ini menjamin bahwa identifikasi semacam itu hanya dapat diterapkan oleh transaksi dengan tipe SET_CODE_TX_TYPE (0x04).
Setelah otorisasi selesai, jika pemberi otorisasi ingin mencabut otorisasi, mereka hanya perlu mengatur alamat target yang dikuasakan menjadi alamat 0.
Tipe transaksi baru yang diperkenalkan melalui EIP-7702 memungkinkan pemberi kuasa (EOA) untuk menjalankan kode seperti kontrak pintar, sekaligus mempertahankan kemampuan untuk memulai transaksi. Dibandingkan dengan EIP-4337, ini memberikan pengalaman yang lebih dekat dengan abstraksi akun asli (Native AA), yang secara signifikan mengurangi ambang penggunaan bagi pengguna.
Praktik Terbaik
Meskipun EIP-7702 memberikan semangat baru untuk 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 menggunakan metode pemulihan sosial bawaan kontrak pintar untuk mengatasi masalah kehilangan dana akibat kehilangan kunci pribadi setelah delegasi, risiko kebocoran kunci pribadi EOA tetap tidak dapat dihindari. Perlu ditegaskan bahwa setelah melakukan delegasi, kunci pribadi EOA tetap memiliki kontrol tertinggi atas akun, dan memiliki kunci pribadi memungkinkan untuk mengelola aset dalam akun dengan bebas. Setelah pengguna atau penyedia layanan dompet menyelesaikan delegasi untuk EOA, meskipun kunci pribadi yang disimpan secara lokal dihapus sepenuhnya, risiko kebocoran kunci pribadi masih tidak dapat sepenuhnya dihilangkan, terutama dalam skenario di mana terdapat risiko serangan rantai pasokan.
Bagi pengguna, saat menggunakan akun setelah penugasan, tetap harus mengutamakan perlindungan kunci pribadi, selalu ingat: Not your keys, not your coins.
replay multi-chain
Saat pengguna menandatangani otorisasi penugasan, mereka dapat memilih rantai yang dapat berlaku dengan menggunakan chainId, atau memilih untuk menggunakan chainId 0 untuk penugasan, sehingga penugasan dapat direproduksi dan berlaku di banyak rantai, memudahkan pengguna untuk melakukan penugasan hanya dengan satu tanda tangan. Namun, perlu dicatat bahwa di alamat kontrak yang sama di banyak rantai, mungkin terdapat kode implementasi yang berbeda.
Untuk penyedia layanan dompet, saat pengguna melakukan delegasi, harus memeriksa apakah rantai efektivitas delegasi sesuai dengan jaringan yang terhubung saat ini, dan memperingatkan pengguna tentang risiko yang mungkin ditimbulkan oleh penandatanganan delegasi 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 penugasan terlebih dahulu.
tidak dapat diinisialisasi
Dompet kontrak pintar yang saat ini populer sebagian besar menggunakan model proxy, di mana proxy dompet saat melakukan penyebaran akan memanggil fungsi inisialisasi kontrak melalui DELEGateCALL, untuk mencapai operasi atomik antara inisialisasi dompet dan penyebaran dompet proxy, sehingga menghindari masalah inisialisasi yang dilakukan lebih awal. Namun, ketika pengguna menggunakan EIP-7702 untuk 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 dengan memanggil fungsi inisialisasi dalam transaksi penyebaran kontrak seperti halnya kontrak proxy ERC-1967 yang umum.
Bagi pengembang, saat mengkombinasikan EIP-7702 dengan dompet EIP-4337 yang ada, perlu diperhatikan untuk melakukan pemeriksaan izin dalam operasi inisialisasi dompet (, misalnya dengan menggunakan ecrecover untuk memulihkan alamat tanda tangan sebagai pemeriksaan izin ), untuk menghindari risiko operasi inisialisasi dompet yang dapat dikejar.
Manajemen Penyimpanan
Saat pengguna menggunakan fungsi delegasi EIP-7702, mungkin perlu untuk mendelegasikan kembali ke alamat kontrak yang berbeda karena perubahan kebutuhan fungsi, pembaruan dompet, dan alasan lainnya. Namun, struktur penyimpanan kontrak yang berbeda mungkin memiliki perbedaan, seperti slot0 di kontrak yang berbeda mungkin mewakili jenis data yang berbeda. Dalam kasus mendelegasikan kembali, ini dapat menyebabkan kontrak baru secara tidak sengaja menggunakan data dari kontrak lama, yang dapat menyebabkan penguncian akun, kehilangan dana, dan konsekuensi buruk lainnya.
Pengguna harus berhati-hati dalam menangani situasi delegasi ulang.
Bagi pengembang, selama proses pengembangan, mereka harus mengikuti Namespace Formula yang diusulkan oleh ERC-7201, untuk mengalokasikan variabel ke lokasi penyimpanan terpisah 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 delegasi ulang, dan memanggil antarmuka delegasi lama untuk membersihkan data lama di penyimpanan.
( isi ulang palsu
Setelah pengguna melakukan delegasi, EOA juga akan 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 implementasi delegasi EIP-7702, jenis akun pengguna dapat beralih bebas antara EOA dan SC, yang memungkinkan akun untuk melakukan transaksi dan juga dipanggil. Ini berarti bahwa ketika akun memanggil dirinya sendiri dan melakukan panggilan eksternal, msg.sender-nya juga akan menjadi tx.origin, yang akan meruntuhkan beberapa asumsi keamanan yang hanya membolehkan partisipasi EOA dalam proyek.
Bagi pengembang kontrak, mengasumsikan tx.origin selalu merupakan EOA tidak akan lagi berlaku. Demikian pula, pemeriksaan msg.sender == tx.origin untuk mencegah serangan reentrancy juga akan gagal.
Pengembang seharusnya mengasumsikan bahwa peserta di masa depan mungkin adalah kontrak pintar.
) kompatibilitas kontrak
Token ERC-721 dan ERC-777 yang ada memiliki fungsi Hook saat mentransfer ke kontrak, yang berarti penerima harus mengimplementasikan fungsi callback yang sesuai untuk berhasil menerima token.
Bagi pengembang, kontrak tujuan yang didelegasikan oleh pengguna seharusnya memiliki 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, dan begitu pengguna mendelegasikan akunnya ke kontrak jahat, penyerang akan dengan mudah mencuri dana.
Bagi penyedia layanan dompet, sangat penting untuk segera mendukung transaksi jenis EIP-7702, dan saat pengguna melakukan tanda tangan delegasi, mereka harus secara jelas menunjukkan kontrak tujuan delegasi kepada pengguna, untuk mengurangi risiko serangan phishing yang mungkin dialami pengguna.
Selain itu, analisis otomatis yang lebih mendalam terhadap kontrak tujuan yang dikuasakan oleh akun ###, pemeriksaan sumber terbuka, pemeriksaan hak, 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 memungkinkan EOA memiliki kemampuan pemrograman dan komposabilitas, yang memburamkan batas antara EOA dan akun kontrak. Karena saat ini belum ada standar kontrak pintar yang kompatibel dengan jenis EIP-7702 yang telah teruji dalam praktik, berbagai peserta ekosistem, seperti pengguna, penyedia 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 patut dicontoh dan diterapkan oleh semua pihak 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.
17 Suka
Hadiah
17
9
Posting ulang
Bagikan
Komentar
0/400
notSatoshi1971
· 07-26 08:08
Sebelum pasar dibuka, sebaiknya kita sudah mulai berbaris, 7702 pasti To da moon.
Lihat AsliBalas0
0xSunnyDay
· 07-24 10:37
Peningkatan ini terlalu hebat 8 Maju
Lihat AsliBalas0
BasementAlchemist
· 07-23 13:37
Apakah datang lagi gelombang inovasi akun kontrak? Sangat tidak masuk akal.
Lihat AsliBalas0
MEVHunterX
· 07-23 13:21
Ini adalah cerita berikutnya dari 4337~ Harum, ayo kita serbu!
Lihat AsliBalas0
PanicSeller69
· 07-23 13:20
Satu lihat sudah harus pump ya, kapan mulai buy the dip V God?
Lihat AsliBalas0
FastLeaver
· 07-23 13:14
Ini adalah upgrade lagi?? Rug Pull peringatan
Lihat AsliBalas0
PerennialLeek
· 07-23 13:12
Naik beberapa gelombang, yang mengerti pasti mengerti.
Lihat AsliBalas0
WinterWarmthCat
· 07-23 13:12
ATM berbicara! Pembaruan baru? Kita bicarakan penarikan lagi nanti.
Lihat AsliBalas0
Web3ExplorerLin
· 07-23 13:07
menarik... eip-7702 mungkin saja menjadi lompatan kuantum yang dibutuhkan eth saat ini
Ethereum Pectra upgrade: EIP-7702 mengaburkan batas EOA dan CA, membuka era baru abstraksi akun
Ethereum Pectra Upgrade: EIP-7702 Membawa Perubahan Revolusioner untuk EOA
Pendahuluan
Ethereum akan segera menyambut upgrade Pectra, yang merupakan pembaruan yang sangat signifikan, dengan banyak proposal perbaikan penting yang akan diperkenalkan. Di antara mereka, EIP-7702 membawa transformasi yang revolusioner terhadap akun eksternal Ethereum (EOA). Proposal ini mengaburkan batasan antara EOA dan akun kontrak CA, menjadi langkah kunci menuju abstraksi akun asli setelah EIP-4337, membawa mode interaksi baru ke ekosistem Ethereum.
Pectra telah menyelesaikan penerapan di jaringan pengujian, dan diharapkan 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 berbasis langganan, sponsor transaksi, dan pemrosesan batch transaksi dalam EOA. Perlu dicatat bahwa EIP-7702 dapat berfungsi dengan baik dengan dompet kontrak pintar yang diimplementasikan oleh EIP-4337, integrasi tanpa batas keduanya sangat menyederhanakan proses pengembangan dan penerapan fitur baru.
EIP-7702 memperkenalkan jenis transaksi SET_CODE_TX_TYPE (0x04), dengan struktur data yang 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 field authorization_list, yang lainnya mengikuti makna yang sama dengan EIP-4844. Field ini adalah tipe daftar, yang dapat berisi beberapa entri otorisasi, masing-masing entri otorisasi:
Bidang authorization_list dalam sebuah transaksi dapat mencakup beberapa akun otorisasi yang berbeda, yaitu entri otorisasi yang ditandatangani oleh (EOA), sehingga penggagas transaksi dapat berbeda dengan pemberi otorisasi, untuk melakukan pembayaran gas atas operasi otorisasi pemberi otorisasi.
merealisasikan
Ketika pemberi otorisasi menandatangani data otorisasi, mereka harus terlebih dahulu melakukan pengkodean RLP terhadap chain_id, address, dan nonce. Kemudian, data yang telah dikodekan bersama dengan angka MAGIC dihitung menggunakan hash keccak256, menghasilkan data yang akan ditandatangani. Terakhir, gunakan kunci privat pemberi otorisasi untuk menandatangani data yang telah di-hash, mendapatkan data y_parity, r, dan s. MAGIC (0x05) digunakan sebagai pemisah domain, dengan tujuan untuk memastikan bahwa hasil tanda tangan dari berbagai jenis tidak akan menghasilkan konflik.
Perlu diperhatikan, ketika chain_id yang diberikan oleh pemberi otorisasi adalah 0, itu berarti pemberi otorisasi mengizinkan untuk melakukan replay otorisasi ( di semua rantai yang kompatibel dengan EVM yang mendukung EIP-7702 dengan syarat nonce juga cocok ).
Setelah pemberi kuasa menandatangani data kuasa, peng发起交易 akan mengumpulkan data tersebut dalam bidang authorization_list untuk ditandatangani dan menyebarkan transaksi melalui RPC. Sebelum transaksi dimasukkan ke dalam blok untuk dieksekusi, Proposer akan melakukan pemeriksaan awal terhadap 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 dari transaksi tidak boleh kosong.
Selain itu, transaksi semacam ini secara paksa mensyaratkan bahwa kolom authorization_list harus berisi setidaknya satu entri otorisasi. Jika ada beberapa entri otorisasi yang ditandatangani oleh otorisator yang sama, hanya entri otorisasi terakhir yang berlaku.
Dalam proses eksekusi transaksi, node akan terlebih dahulu menambah nilai nonce dari pengirim transaksi, kemudian melakukan operasi applyAuthorization pada setiap entri otorisasi dalam authorization_list. Dalam operasi applyAuthorization, node akan terlebih dahulu memeriksa nonce dari pihak yang memberikan otorisasi, lalu menambah nonce dari pihak tersebut. Ini berarti jika pengirim transaksi dan pihak yang memberikan otorisasi adalah pengguna yang sama (EOA), maka saat menandatangani transaksi otorisasi, nilai nonce harus ditambah 1.
Saat node menerapkan entri otorisasi tertentu, jika terjadi kesalahan, entri otorisasi tersebut akan dilewati, transaksi tidak akan gagal, dan entri otorisasi lainnya akan terus diterapkan untuk memastikan tidak ada risiko DoS 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 dikuasakan. Karena batasan EIP-3541, pengguna tidak dapat menerapkan kode kontrak yang diawali dengan byte 0xef dengan cara biasa, ini menjamin bahwa identifikasi semacam itu hanya dapat diterapkan oleh transaksi dengan tipe SET_CODE_TX_TYPE (0x04).
Setelah otorisasi selesai, jika pemberi otorisasi ingin mencabut otorisasi, mereka hanya perlu mengatur alamat target yang dikuasakan menjadi alamat 0.
Tipe transaksi baru yang diperkenalkan melalui EIP-7702 memungkinkan pemberi kuasa (EOA) untuk menjalankan kode seperti kontrak pintar, sekaligus mempertahankan kemampuan untuk memulai transaksi. Dibandingkan dengan EIP-4337, ini memberikan pengalaman yang lebih dekat dengan abstraksi akun asli (Native AA), yang secara signifikan mengurangi ambang penggunaan bagi pengguna.
Praktik Terbaik
Meskipun EIP-7702 memberikan semangat baru untuk 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 menggunakan metode pemulihan sosial bawaan kontrak pintar untuk mengatasi masalah kehilangan dana akibat kehilangan kunci pribadi setelah delegasi, risiko kebocoran kunci pribadi EOA tetap tidak dapat dihindari. Perlu ditegaskan bahwa setelah melakukan delegasi, kunci pribadi EOA tetap memiliki kontrol tertinggi atas akun, dan memiliki kunci pribadi memungkinkan untuk mengelola aset dalam akun dengan bebas. Setelah pengguna atau penyedia layanan dompet menyelesaikan delegasi untuk EOA, meskipun kunci pribadi yang disimpan secara lokal dihapus sepenuhnya, risiko kebocoran kunci pribadi masih tidak dapat sepenuhnya dihilangkan, terutama dalam skenario di mana terdapat risiko serangan rantai pasokan.
Bagi pengguna, saat menggunakan akun setelah penugasan, tetap harus mengutamakan perlindungan kunci pribadi, selalu ingat: Not your keys, not your coins.
replay multi-chain
Saat pengguna menandatangani otorisasi penugasan, mereka dapat memilih rantai yang dapat berlaku dengan menggunakan chainId, atau memilih untuk menggunakan chainId 0 untuk penugasan, sehingga penugasan dapat direproduksi dan berlaku di banyak rantai, memudahkan pengguna untuk melakukan penugasan hanya dengan satu tanda tangan. Namun, perlu dicatat bahwa di alamat kontrak yang sama di banyak rantai, mungkin terdapat kode implementasi yang berbeda.
Untuk penyedia layanan dompet, saat pengguna melakukan delegasi, harus memeriksa apakah rantai efektivitas delegasi sesuai dengan jaringan yang terhubung saat ini, dan memperingatkan pengguna tentang risiko yang mungkin ditimbulkan oleh penandatanganan delegasi 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 penugasan terlebih dahulu.
tidak dapat diinisialisasi
Dompet kontrak pintar yang saat ini populer sebagian besar menggunakan model proxy, di mana proxy dompet saat melakukan penyebaran akan memanggil fungsi inisialisasi kontrak melalui DELEGateCALL, untuk mencapai operasi atomik antara inisialisasi dompet dan penyebaran dompet proxy, sehingga menghindari masalah inisialisasi yang dilakukan lebih awal. Namun, ketika pengguna menggunakan EIP-7702 untuk 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 dengan memanggil fungsi inisialisasi dalam transaksi penyebaran kontrak seperti halnya kontrak proxy ERC-1967 yang umum.
Bagi pengembang, saat mengkombinasikan EIP-7702 dengan dompet EIP-4337 yang ada, perlu diperhatikan untuk melakukan pemeriksaan izin dalam operasi inisialisasi dompet (, misalnya dengan menggunakan ecrecover untuk memulihkan alamat tanda tangan sebagai pemeriksaan izin ), untuk menghindari risiko operasi inisialisasi dompet yang dapat dikejar.
Manajemen Penyimpanan
Saat pengguna menggunakan fungsi delegasi EIP-7702, mungkin perlu untuk mendelegasikan kembali ke alamat kontrak yang berbeda karena perubahan kebutuhan fungsi, pembaruan dompet, dan alasan lainnya. Namun, struktur penyimpanan kontrak yang berbeda mungkin memiliki perbedaan, seperti slot0 di kontrak yang berbeda mungkin mewakili jenis data yang berbeda. Dalam kasus mendelegasikan kembali, ini dapat menyebabkan kontrak baru secara tidak sengaja menggunakan data dari kontrak lama, yang dapat menyebabkan penguncian akun, kehilangan dana, dan konsekuensi buruk lainnya.
Pengguna harus berhati-hati dalam menangani situasi delegasi ulang.
Bagi pengembang, selama proses pengembangan, mereka harus mengikuti Namespace Formula yang diusulkan oleh ERC-7201, untuk mengalokasikan variabel ke lokasi penyimpanan terpisah 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 delegasi ulang, dan memanggil antarmuka delegasi lama untuk membersihkan data lama di penyimpanan.
( isi ulang palsu
Setelah pengguna melakukan delegasi, EOA juga akan 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 implementasi delegasi EIP-7702, jenis akun pengguna dapat beralih bebas antara EOA dan SC, yang memungkinkan akun untuk melakukan transaksi dan juga dipanggil. Ini berarti bahwa ketika akun memanggil dirinya sendiri dan melakukan panggilan eksternal, msg.sender-nya juga akan menjadi tx.origin, yang akan meruntuhkan beberapa asumsi keamanan yang hanya membolehkan partisipasi EOA dalam proyek.
Bagi pengembang kontrak, mengasumsikan tx.origin selalu merupakan EOA tidak akan lagi berlaku. Demikian pula, pemeriksaan msg.sender == tx.origin untuk mencegah serangan reentrancy juga akan gagal.
Pengembang seharusnya mengasumsikan bahwa peserta di masa depan mungkin adalah kontrak pintar.
) kompatibilitas kontrak
Token ERC-721 dan ERC-777 yang ada memiliki fungsi Hook saat mentransfer ke kontrak, yang berarti penerima harus mengimplementasikan fungsi callback yang sesuai untuk berhasil menerima token.
Bagi pengembang, kontrak tujuan yang didelegasikan oleh pengguna seharusnya memiliki 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, dan begitu pengguna mendelegasikan akunnya ke kontrak jahat, penyerang akan dengan mudah mencuri dana.
Bagi penyedia layanan dompet, sangat penting untuk segera mendukung transaksi jenis EIP-7702, dan saat pengguna melakukan tanda tangan delegasi, mereka harus secara jelas menunjukkan kontrak tujuan delegasi kepada pengguna, untuk mengurangi risiko serangan phishing yang mungkin dialami pengguna.
Selain itu, analisis otomatis yang lebih mendalam terhadap kontrak tujuan yang dikuasakan oleh akun ###, pemeriksaan sumber terbuka, pemeriksaan hak, 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 memungkinkan EOA memiliki kemampuan pemrograman dan komposabilitas, yang memburamkan batas antara EOA dan akun kontrak. Karena saat ini belum ada standar kontrak pintar yang kompatibel dengan jenis EIP-7702 yang telah teruji dalam praktik, berbagai peserta ekosistem, seperti pengguna, penyedia 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 patut dicontoh dan diterapkan oleh semua pihak dalam operasi nyata.