Pembaruan Pectra Ethereum EIP-7702: Perubahan Besar yang Memberdayakan EOA

Pendahuluan

Ethereum akan segera menyambut pembaruan Pectra, yang merupakan pembaruan yang sangat berarti. Di antara mereka, EIP-7702 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, yang membawa mode interaksi baru ke ekosistem Ethereum.

Pectra telah menyelesaikan penerapan di jaringan pengujian, dan diperkirakan akan segera diluncurkan di jaringan utama. Artikel ini akan mengupas mekanisme implementasi EIP-7702, membahas 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, dengan demikian mengatur kode untuknya. Dengan cara ini, EOA dapat mengeksekusi kode seperti kontrak pintar, sambil tetap mempertahankan kemampuan untuk memulai transaksi. Fitur ini memberikan EOA kemampuan pemrograman dan komposabilitas, memungkinkan pengguna untuk mengimplementasikan fungsi seperti pemulihan sosial, kontrol akses, manajemen multi-tanda tangan, verifikasi zk, pembayaran berbasis langganan, sponsor transaksi, dan pemrosesan batch transaksi. Perlu dicatat bahwa EIP-7702 dapat berfungsi dengan baik dengan dompet kontrak pintar yang diimplementasikan oleh EIP-4337, dan integrasi tanpa batas antara keduanya sangat menyederhanakan proses pengembangan dan aplikasi fitur baru.

Implementasi spesifik dari EIP-7702 adalah pengenalan 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 yang baru, selain field authorization_list, sisanya mengikuti makna yang sama dengan EIP-4844. Field ini adalah tipe daftar, yang dapat berisi beberapa entri otorisasi, di setiap entri otorisasi:

• field chain_id menunjukkan jalur yang berlaku untuk penugasan otorisasi ini.
• field address menunjukkan alamat tujuan dari delegasi
• field nonce harus cocok dengan nonce akun yang saat ini diotorisasi
• bidang y_parity, r, s adalah data tanda tangan yang ditandatangani oleh akun yang diberi wewenang.

Dalam satu transaksi, field authorization_list dapat berisi beberapa entri otorisasi yang ditandatangani oleh berbagai akun yang berbeda ( EOA ), yaitu penggagas transaksi dapat berbeda dengan pemberi otorisasi, untuk melakukan operasi pembayaran gas untuk pemberi otorisasi.

implementasi

Pemberi kuasa saat menandatangani data kuasa, perlu terlebih dahulu melakukan pengkodean RLP pada chain_id, address, dan nonce. Setelah itu, data yang telah dikodekan digabungkan dengan angka MAGIC dan dilakukan operasi hash keccak256, sehingga menghasilkan data yang akan ditandatangani. Terakhir, menggunakan kunci privat pemberi kuasa untuk menandatangani data yang telah di-hash, sehingga mendapatkan data y_parity, r, s. Di mana, MAGIC (0x05) digunakan sebagai pemisah domain, tujuannya adalah untuk memastikan bahwa hasil tanda tangan dari berbagai jenis tidak akan bertentangan.

Perlu dicatat bahwa ketika chain_id yang diberikan oleh pemberi otorisasi adalah 0, itu berarti pemberi otorisasi mengizinkan untuk melakukan replay otorisasi di semua rantai yang kompatibel EVM yang mendukung EIP-7702 (dengan syarat nonce juga cocok).

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

Sementara itu, transaksi semacam ini akan memaksa agar field authorization_list dalam transaksi harus setidaknya memiliki satu entri otorisasi. Jika ada beberapa entri otorisasi yang ditandatangani oleh otoriser yang sama, maka hanya entri otorisasi terakhir yang akan berlaku.

Kemudian, 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 otorisator, lalu menambah nonce dari otorisator. Ini berarti jika pengirim transaksi dan otorisator 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, untuk memastikan bahwa tidak ada risiko DoS dalam skenario otorisasi massal.

Setelah aplikasi otorisasi selesai, 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 dimulai dengan byte 0xef dengan cara biasa, yang menjamin 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 tujuan yang didelegasikan ke alamat 0.

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

Praktik Terbaik

Meskipun EIP-7702 telah 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 menyelesaikan masalah kehilangan dana akibat kunci pribadi yang hilang dengan bantuan pemulihan sosial yang terintegrasi dalam kontrak pintar setelah melakukan delegasi, itu masih tidak dapat menghindari risiko kebocoran kunci pribadi EOA. Perlu ditekankan 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 menghapus sepenuhnya kunci pribadi yang disimpan di 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 mengutamakan perlindungan kunci privat, selalu ingat: Not your keys, not your coins.

pemutaran multi-rantai

Pengguna dapat memilih rantai yang dapat diterapkan untuk delegasi saat menandatangani otorisasi delegasi melalui chainId, tentu saja pengguna juga dapat memilih untuk menggunakan chainId 0 untuk delegasi, ini memungkinkan delegasi dapat diterapkan ulang di banyak rantai, sehingga memudahkan pengguna untuk melakukan delegasi dengan satu tanda tangan di banyak rantai. Namun perlu dicatat 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 berlaku 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 berbagai rantai tidak selalu memiliki kode kontrak yang sama, dan harus terlebih dahulu memahami tujuan dari delegasi.

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, sehingga menghindari masalah inisialisasi yang lebih awal. Namun, saat pengguna menggunakan EIP-7702 untuk delegasi, hanya akan memperbarui bidang kode alamatnya, dan tidak dapat menginisialisasi melalui pemanggilan alamat delegasi. Hal ini membuat EIP-7702 tidak dapat 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, harus diperhatikan untuk melakukan pemeriksaan izin dalam operasi inisialisasi dompet (misalnya dengan menggunakan ecrecover untuk memulihkan alamat tanda tangan untuk pemeriksaan izin), untuk 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, pembaruan 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, ada kemungkinan kontrak baru secara tidak sengaja menggunakan data dari kontrak lama, yang dapat menyebabkan penguncian akun, kehilangan dana, dan konsekuensi buruk lainnya.

Bagi pengguna, harus berhati-hati dalam menangani situasi delegasi ulang.

Untuk pengembang, selama proses pengembangan harus mengikuti Namespace Formula yang diusulkan oleh ERC-7201, untuk mengalokasikan variabel ke lokasi penyimpanan yang ditentukan secara independen, guna 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 akan dapat digunakan sebagai kontrak pintar, sehingga 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, sehingga akun dapat 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 merusak beberapa asumsi keamanan yang hanya memperbolehkan partisipasi EOA dalam proyek.

Bagi pengembang kontrak, mengasumsikan 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 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 tujuan yang dipercayakan 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, maka pencuri akan sangat mudah mencuri dana.

Bagi penyedia layanan dompet, sangat penting untuk segera mendukung transaksi jenis EIP-7702, dan saat pengguna melakukan tanda tangan delegasi, harus menampilkan kontrak tujuan delegasi dengan jelas kepada pengguna untuk mengurangi risiko serangan phishing yang mungkin dialami oleh pengguna.

Selain itu, analisis otomatis yang lebih mendalam terhadap kontrak tujuan yang didelegasikan oleh akun (pemeriksaan sumber terbuka, pemeriksaan izin, dll.) dapat lebih membantu pengguna menghindari risiko semacam ini.

Ringkasan

EIP-7702 dengan memperkenalkan jenis transaksi baru, membuat EOA memiliki kemampuan pemrograman dan komposabilitas, sehingga 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, maka dalam aplikasi nyata, berbagai peserta ekosistem, seperti pengguna, penyedia layanan dompet, pengembang, CEX, dan lain-lain, menghadapi banyak tantangan dan peluang. Konten praktik terbaik yang dijelaskan dalam artikel ini tidak dapat mencakup semua risiko potensial, tetapi tetap layak untuk dirujuk dan diterapkan oleh semua pihak dalam operasi nyata.