Ethereum Pectra Upgrade: EIP-7702 Kedalaman Analisis dan Panduan Praktik Terbaik

Pendahuluan

Ethereum akan segera menyambut peningkatan Pectra, yang merupakan pembaruan yang sangat signifikan. Di antaranya, EIP-7702 melakukan transformasi revolusioner terhadap akun eksternal Ethereum (EOA). Proposal ini mengaburkan batas antara EOA dan akun kontrak CA, merupakan langkah kunci menuju abstraksi akun asli, dan membawa model interaksi baru ke ekosistem Ethereum.

Pectra telah menyelesaikan penerapan di jaringan pengujian, dan diharapkan segera diluncurkan di jaringan utama. Artikel ini akan menganalisis secara mendalam mekanisme implementasi EIP-7702, mengeksplorasi peluang dan tantangan yang mungkin dihadirkannya, 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 komposabilitas, sehingga pengguna dapat menerapkan fungsi seperti pemulihan sosial, kontrol izin, manajemen multisig, verifikasi zk, pembayaran berbasis langganan, sponsor transaksi, dan pemrosesan batch transaksi dalam EOA. Perlu dicatat bahwa EIP-7702 dapat berintegrasi dengan dompet kontrak pintar yang diimplementasikan oleh EIP-4337, menyederhanakan proses pengembangan dan penerapan fitur baru.

EIP-7702 memperkenalkan jenis 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 baru, kecuali bidang authorization_list, yang lainnya mengikuti semantik yang sama dengan EIP-4844. authorization_list adalah tipe daftar yang dapat berisi beberapa entri otorisasi. Setiap entri otorisasi:

• chain_id menunjukkan rantai tempat otorisasi delegasi berlaku
• address menunjukkan alamat target untuk delegasi
• nonce harus cocok dengan nonce akun yang saat ini diotorisasi
• y_parity, r, s adalah data tanda tangan yang ditandatangani oleh akun yang diberi wewenang

Daftar otorisasi dari sebuah transaksi dapat berisi beberapa akun otorisasi yang berbeda. ( EOA ) menandatangani entri otorisasi untuk melakukan pembayaran gas atas nama pemberi otorisasi.

implementasi

Saat pemberi kuasa menandatangani data kuasa, ia perlu terlebih dahulu melakukan pengkodean RLP pada chain_id, address, nonce. Kemudian, data yang telah dikodekan digabungkan dengan angka MAGIC dan dilakukan operasi hash keccak256 untuk mendapatkan data yang akan ditandatangani. Akhirnya, dengan menggunakan kunci pribadi pemberi kuasa untuk menandatangani data yang telah di-hash, diperoleh data y_parity, r, s. MAGIC (0x05) digunakan sebagai pemisah domain, memastikan bahwa hasil tanda tangan dari berbagai jenis tidak akan bertabrakan.

Ketika chain_id yang diberikan oleh pemberi wewenang adalah 0, ini menunjukkan bahwa pemberi wewenang mengizinkan replay wewenang di semua rantai yang kompatibel dengan EVM yang mendukung EIP-7702 (dengan syarat bahwa nonce juga cocok).

Setelah pemberi kuasa menandatangani data kuasa, penggagas transaksi akan mengumpulkannya dalam bidang authorization_list untuk ditandatangani dan disiarkan melalui RPC. Sebelum eksekusi transaksi, Proposer akan melakukan pemeriksaan awal untuk memastikan transaksi ini bukan transaksi pembuatan kontrak, yaitu saat mengirim transaksi tipe EIP-7702, alamat to dari transaksi tidak boleh kosong.

Transaksi semacam ini mengharuskan bahwa field authorization_list setidaknya berisi satu entri otorisasi. Jika beberapa entri otorisasi ditandatangani oleh otorisator yang sama, hanya entri otorisasi terakhir yang akan berlaku.

Saat eksekusi transaksi, node terlebih dahulu menambah nilai nonce pengirim transaksi, kemudian melakukan operasi applyAuthorization pada setiap entri otorisasi dalam authorization_list. Dalam operasi applyAuthorization, node terlebih dahulu memeriksa nonce dari pemberi otorisasi, kemudian menambah nonce pemberi otorisasi. Ini berarti jika pengirim transaksi dan pemberi otorisasi adalah pengguna yang sama (EOA), nilai nonce saat menandatangani transaksi otorisasi harus ditambah 1.

Saat menerapkan entri otorisasi node, jika terjadi kesalahan, entri tersebut akan dilewati, transaksi tidak akan gagal, entri otorisasi lainnya akan terus diterapkan untuk menghindari risiko DoS dalam skenario otorisasi massal.

Setelah aplikasi diotorisasi, bidang code dari alamat pemberi otorisasi akan diatur menjadi 0xef0100 || address, di mana 0xef0100 adalah identifikasi tetap, dan address adalah alamat target yang didelegasikan. Pembatasan EIP-3541 memastikan bahwa identifikasi semacam ini hanya dapat diterapkan oleh transaksi dari tipe SET_CODE_TX_TYPE (0x04).

Setelah otorisasi selesai, jika pemberi otorisasi ingin mencabut otorisasi, cukup atur alamat tujuan yang didelegasikan ke alamat 0.

Melalui jenis transaksi baru yang diperkenalkan oleh EIP-7702, pemberi wewenang (EOA) dapat menjalankan kode seperti kontrak pintar, sambil tetap mempertahankan kemampuan untuk memulai transaksi. Dibandingkan dengan EIP-4337, ini memberikan pengalaman yang lebih mendekati abstraksi akun asli (Native AA) bagi pengguna, secara signifikan mengurangi batasan penggunaan.

Praktik Terbaik

EIP-7702 memberi energi baru untuk ekosistem Ethereum, namun, skenario aplikasi baru juga 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 yang terintegrasi dalam kontrak pintar untuk mengatasi masalah kerugian dana akibat kehilangan kunci pribadi setelah delegasi, risiko kebocoran kunci pribadi EOA tetap tidak dapat dihindari. Setelah melakukan delegasi, kunci pribadi EOA masih memiliki kontrol tertinggi atas akun, dan siapa pun yang memiliki kunci pribadi dapat dengan bebas mengelola aset di dalam akun. Pengguna atau penyedia layanan dompet, setelah menyelesaikan delegasi untuk EOA, bahkan jika sepenuhnya menghapus kunci pribadi yang disimpan secara lokal, tidak dapat sepenuhnya menghilangkan risiko kebocoran kunci pribadi, terutama dalam skenario yang memiliki risiko serangan rantai pasokan.

Bagi pengguna, saat menggunakan akun setelah delegasi, perlindungan kunci pribadi harus tetap menjadi prioritas utama, selalu ingat: Not your keys, not your coins.

Pemutaran Multi-Rantai

Saat pengguna menandatangani otorisasi delegasi, mereka dapat memilih chainId untuk menentukan rantai di mana delegasi akan berlaku, atau mereka juga dapat memilih chainId sebagai 0 untuk melakukan delegasi, sehingga delegasi dapat direplikasi di banyak rantai, memudahkan pengguna untuk melakukan delegasi dengan satu tanda tangan di banyak rantai. Namun, perlu dicatat bahwa dalam alamat kontrak yang sama di banyak rantai, mungkin terdapat kode implementasi yang berbeda.

Penyedia layanan dompet harus memeriksa apakah rantai efektif pesanan sesuai dengan jaringan yang terhubung saat pengguna melakukan penunjukan, dan mengingatkan pengguna tentang risiko yang mungkin ditimbulkan oleh 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 penugasan terlebih dahulu.

Tidak dapat diinisialisasi

Dompet kontrak pintar yang umum saat ini banyak menggunakan model proxy, di mana proxy dompet saat penerapan, melalui DELEGateCALL memanggil fungsi inisialisasi kontrak, mencapai operasi atomik antara inisialisasi dompet dan penerapan dompet proxy, menghindari masalah inisialisasi yang dilakukan lebih awal. Namun, ketika pengguna menggunakan EIP-7702 untuk mendelegasikan, hanya akan memperbarui bidang code alamatnya, dan tidak dapat melakukan inisialisasi melalui pemanggilan alamat delegasi. Ini membuat EIP-7702 tidak dapat memanggil fungsi inisialisasi untuk inisialisasi dompet dalam transaksi penerapan kontrak seperti kontrak proxy ERC-1967 yang umum.

Pengembang harus melakukan pemeriksaan izin (seperti melalui ecrecover untuk memulihkan alamat tanda tangan) saat menggabungkan EIP-7702 dengan dompet EIP-4337 yang ada dalam operasi inisialisasi dompet, untuk menghindari risiko operasi inisialisasi dompet yang direbut.

Manajemen Penyimpanan

Ketika pengguna menggunakan fitur delegasi EIP-7702, mungkin karena perubahan kebutuhan fungsi, pembaruan dompet, dan alasan lainnya, perlu untuk mendelegasikan ulang ke alamat kontrak yang berbeda. Namun, struktur penyimpanan kontrak yang berbeda mungkin memiliki perbedaan (misalnya, slot0 dari kontrak yang berbeda mungkin mewakili jenis data yang berbeda), mendelegasikan ulang 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 penugasan ulang.

Pengembang harus mengikuti Namespace Formula yang diusulkan oleh ERC-7201 selama proses pengembangan, 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 yang dirancang khusus untuk EIP-7702: termasuk menggunakan 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 delegasi, EOA juga dapat digunakan sebagai kontrak pintar, sehingga bursa terpusat (CEX) mungkin 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 EIP-7702, tipe akun pengguna dapat beralih bebas antara EOA dan SC, akun dapat memulai transaksi dan juga dapat dipanggil. Ini berarti bahwa 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 mengizinkan EOA untuk berpartisipasi dalam proyek.

Pengembang kontrak tidak boleh lagi mengasumsikan bahwa tx.origin selalu merupakan EOA. Demikian pula, pemeriksaan melalui msg.sender == tx.origin untuk melawan serangan reentrancy juga akan gagal.

Pengembang harus mengasumsikan bahwa peserta di masa depan mungkin semuanya merupakan 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.

Pengembang harus memastikan bahwa kontrak tujuan yang didelegasikan oleh pengguna mengimplementasikan fungsi callback yang sesuai, untuk memastikan kompatibilitas dengan token utama.

Pemeriksaan Penipuan

Setelah menerapkan 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.

Penyedia layanan dompet harus segera mendukung transaksi jenis EIP-7702, dan saat pengguna melakukan penandatanganan delegasi, harus menampilkan kontrak tujuan delegasi dengan jelas kepada pengguna untuk mengurangi risiko serangan phishing yang mungkin dialami pengguna.

Selain itu, melakukan analisis otomatis yang lebih mendalam terhadap kontrak target yang dikuasakan oleh akun (pemeriksaan sumber terbuka, pemeriksaan izin, dll.) dapat membantu pengguna menghindari risiko semacam itu dengan lebih baik.

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, memburamkan 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 layanan dompet, pengembang, CEX, dll., 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 diterapkan oleh semua pihak dalam operasi nyata.