Ethereum Pectra Upgrade dan EIP-7702: Langkah Penting untuk Mengaburkan Batas EOA dan Akun Kontrak

Pendahuluan

Ethereum akan segera menyambut upgrade Pectra, yang merupakan pembaruan yang sangat berarti, dengan banyak proposal perbaikan penting Ethereum yang akan diperkenalkan. Di antaranya, EIP-7702 telah melakukan transformasi yang 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 pola interaksi baru bagi ekosistem Ethereum.

Pectra telah menyelesaikan penyebaran di jaringan pengujian, diperkirakan akan 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, 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 mengimplementasikan pemulihan sosial, kontrol izin, manajemen multisig, verifikasi zk, pembayaran berlangganan, sponsor transaksi, dan pemrosesan batch transaksi dalam EOA. EIP-7702 dapat dengan sempurna kompatibel dengan dompet kontrak pintar yang diimplementasikan oleh EIP-4337, integrasi tanpa hambatan antara keduanya sangat menyederhanakan proses pengembangan dan aplikasi 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])

Di mana bidang 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, setiap entri otorisasi mencakup:

• chain_id: rantai yang diberi kuasa ini berlaku
• alamat: alamat tujuan yang ditugaskan
• nonce: harus cocok dengan nonce dari akun yang terotorisasi saat ini
• y_parity, r, s: akun yang diotorisasi menandatangani data tanda tangan yang diotorisasi

Field authorization_list dalam satu transaksi dapat mencakup beberapa akun otorisasi yang berbeda, dengan entri otorisasi yang ditandatangani oleh (EOA). Peng发起 transaksi dapat berbeda dari pemberi otorisasi, memungkinkan penggantian biaya gas untuk tindakan otorisasi.

mewujudkan

Ketika pemberi otorisasi menandatangani data otorisasi, mereka harus terlebih dahulu melakukan pengkodean RLP pada chain_id, address, dan nonce. Kemudian, data yang telah dikodekan digabungkan dengan MAGIC untuk melakukan operasi hash keccak256, menghasilkan data yang akan ditandatangani. Terakhir, gunakan kunci pribadi pemberi otorisasi untuk menandatangani data yang telah di-hash, dan peroleh data y_parity, r, s. MAGIC (0x05) digunakan sebagai pemisah domain, memastikan bahwa hasil tanda tangan dari berbagai jenis tidak akan terjadi konflik.

Ketika chain_id yang diberikan oleh pemberi otorisasi adalah 0, itu berarti pemberi otorisasi mengizinkan untuk mereplay otorisasi ( di semua rantai yang kompatibel EVM yang mendukung EIP-7702, asalkan nonce juga cocok dengan ).

Setelah pemberi kuasa menandatangani data kuasa, peng发起 transaksi akan mengumpulkannya dalam field authorization_list untuk ditandatangani dan disiarkan transaksi melalui RPC. Sebelum transaksi dieksekusi dan dimasukkan ke dalam blok, Proposer terlebih dahulu akan melakukan pemeriksaan awal terhadap transaksi, melakukan pemeriksaan ketat pada alamat to untuk memastikan bahwa transaksi ini bukan transaksi pembuatan kontrak, yaitu saat mengirim transaksi tipe EIP-7702, alamat to dari transaksi tidak boleh kosong.

Pada saat yang sama, transaksi semacam ini mengharuskan bahwa bidang authorization_list harus setidaknya mencakup satu entri otorisasi, jika ada beberapa entri otorisasi yang ditandatangani oleh otoriser yang sama, hanya entri otorisasi terakhir yang akan berlaku.

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 dari pemberi otorisasi. Ini berarti jika pengirim transaksi dan pemberi otorisasi adalah pengguna yang sama (EOA), maka saat menandatangani transaksi otorisasi, nilai nonce harus ditambah 1.

Ketika node menerapkan suatu entri otorisasi, jika terjadi kesalahan, entri otorisasi tersebut akan dilewati, transaksi tidak akan gagal, entri otorisasi lainnya akan terus diterapkan, untuk memastikan bahwa tidak ada risiko DoS dalam skenario otorisasi massal.

Setelah aplikasi diotorisasi, field code pada alamat pemberi otorisasi akan diatur menjadi 0xef0100 || address, di mana 0xef0100 adalah identifikasi tetap, dan address adalah alamat tujuan yang didelegasikan. Karena pembatasan EIP-3541, pengguna tidak dapat mengdeploy kode kontrak yang diawali dengan byte 0xef dengan cara biasa, ini memastikan bahwa identifikasi semacam itu hanya dapat dideploy oleh transaksi bertipe SET_CODE_TX_TYPE (0x04).

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

Jenis transaksi baru yang diperkenalkan melalui EIP-7702 memungkinkan pemberi wewenang (EOA) untuk menjalankan kode seperti kontrak pintar, sambil tetap mempertahankan kemampuan untuk memulai transaksi. Dibandingkan dengan EIP-4337, ini memberikan pengalaman yang lebih mendekati pengabstrakan akun asli (Native AA) untuk pengguna, secara signifikan mengurangi ambang penggunaan bagi pengguna.

Praktik Terbaik

Meskipun EIP-7702 telah memberikan energi baru bagi ekosistem Ethereum, tetapi skenario aplikasi baru juga akan membawa risiko baru. Berikut adalah aspek-aspek yang perlu diwaspadai oleh peserta ekosistem dalam proses praktik:

penyimpanan kunci pribadi

Meskipun EOA dapat memanfaatkan pemulihan sosial yang terintegrasi dalam kontrak pintar setelah delegasi untuk mengatasi masalah kehilangan dana akibat kehilangan kunci pribadi, risiko kebocoran kunci pribadi EOA tetap tidak dapat dihindari. Penting untuk diperjelas bahwa setelah melakukan delegasi, kunci pribadi EOA tetap memiliki kontrol tertinggi atas akun, dan siapa pun yang memiliki kunci pribadi dapat dengan bebas mengelola aset dalam akun tersebut. Pengguna atau penyedia layanan dompet, setelah menyelesaikan delegasi untuk EOA, meskipun sepenuhnya menghapus kunci pribadi yang disimpan secara lokal, tetap tidak dapat sepenuhnya menghilangkan risiko kebocoran kunci pribadi, terutama dalam skenario yang memiliki risiko serangan rantai pasokan.

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

replay multi-chain

Pengguna dapat memilih chain yang dapat diaktifkan untuk penugasan saat menandatangani otorisasi penugasan, dan juga dapat memilih untuk menggunakan chainId 0 untuk melakukan penugasan, sehingga penugasan dapat diputar ulang dan diaktifkan di banyak chain, memudahkan pengguna untuk melakukan penugasan dengan sekali tanda tangan. Namun perlu diperhatikan bahwa, dalam alamat kontrak yang sama di banyak chain, mungkin terdapat kode implementasi yang berbeda.

Untuk penyedia layanan dompet, saat pengguna melakukan delegasi, mereka harus memeriksa apakah rantai efektif delegasi sesuai dengan jaringan yang sedang terhubung, dan mengingatkan pengguna tentang risiko yang mungkin ditimbulkan oleh penandatanganan delegasi dengan chainId 0.

Pengguna juga harus memperhatikan bahwa alamat kontrak yang sama di berbagai rantai, kode kontraknya tidak selalu sama, dan harus memahami dengan jelas tujuan dari delegasi.

tidak dapat diinisialisasi

Dompet kontrak pintar yang umum saat ini sebagian besar menggunakan model proxy. Proxy dompet, saat diterapkan, 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, ketika pengguna menggunakan EIP-7702 untuk delegasi, hanya akan memperbarui bidang code dari alamatnya, dan tidak dapat menginisialisasi dengan memanggil 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.

Bagi pengembang, saat mengkombinasikan EIP-7702 dengan dompet EIP-4337 yang ada, harus diperhatikan untuk melakukan pengecekan izin dalam operasi inisialisasi dompet, misalnya dengan menggunakan ecrecover untuk memulihkan alamat tanda tangan untuk melakukan pengecekan izin, agar menghindari risiko operasi inisialisasi dompet yang terlewat.

( Manajemen Penyimpanan

Pengguna yang menggunakan fungsi delegasi EIP-7702 mungkin perlu mendelegasikan ulang 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 hal delegasi ulang, ada kemungkinan kontrak baru secara tidak sengaja menggunakan data dari kontrak lama, yang dapat mengakibatkan penguncian akun, kehilangan dana, dan konsekuensi negatif lainnya.

Bagi pengguna, harus 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 yang 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 ulang palsu

Setelah pengguna melakukan penugasan, EOA juga akan dapat digunakan sebagai kontrak pintar, sehingga bursa )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.

( 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 dapat dipanggil. Ini berarti 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, anggapan bahwa tx.origin selalu merupakan EOA tidak lagi dapat diterima. Demikian juga, pemeriksaan melalui 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 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 memancing

Setelah menerapkan delegasi EIP-7702, aset dalam akun pengguna mungkin akan dikendalikan oleh kontrak pintar. Begitu pengguna mendelegasikan akunnya ke kontrak jahat, 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 dengan jelas, untuk mengurangi risiko serangan phishing yang mungkin dialami pengguna.

Selain itu, analisis otomatis yang lebih mendalam terhadap kontrak target yang didelegasikan oleh akun, seperti pemeriksaan sumber terbuka, pemeriksaan izin, dan lain-lain, ### 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 memungkinkan EOA memiliki kemampuan pemrograman dan komposabilitas, 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 layanan dompet, pengembang, CEX, dll, 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 dan diterapkan dalam operasi praktis.