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

Pendahuluan

Ethereum akan segera menyambut pembaruan Pectra, yang merupakan pembaruan penting dengan banyak proposal peningkatan Ethereum yang signifikan akan diperkenalkan. Di antaranya, EIP-7702 melakukan transformasi 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 mode interaksi baru ke ekosistem Ethereum.

Pectra telah menyelesaikan penerapan 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, sehingga dapat mengatur kode untuknya. Dengan cara ini, EOA dapat menjalankan kode seperti kontrak pintar, sambil tetap mempertahankan kemampuan untuk memulai transaksi. Fitur ini memberi EOA kemampuan untuk diprogram dan digabungkan, sehingga pengguna dapat mengimplementasikan fungsi-fungsi seperti pemulihan sosial, kontrol akses, manajemen multi-tanda tangan, verifikasi zk, pembayaran berlangganan, sponsor transaksi, dan pemrosesan batch transaksi di dalam EOA. Perlu dicatat bahwa EIP-7702 dapat berintegrasi dengan dompet kontrak pintar yang diimplementasikan oleh EIP-4337, dan integrasi yang mulus antara keduanya sangat menyederhanakan proses pengembangan dan penerapan fitur baru.

Implementasi spesifik 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 bidang authorization_list, yang lainnya mengikuti makna yang sama dengan EIP-4844. Bidang ini adalah tipe daftar, dan daftar tersebut dapat berisi beberapa entri otorisasi, di mana setiap entri otorisasi:

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

Di dalam transaksi, field authorization_list dapat berisi beberapa entri otorisasi yang ditandatangani oleh akun yang berbeda (EOA), yaitu penggagas transaksi dapat berbeda dari pemberi otorisasi, untuk memungkinkan pembayaran gas untuk operasi otorisasi oleh pemberi otorisasi.

implementasi

Pemberi wewenang perlu melakukan pengkodean RLP pada chain_id, address, dan nonce saat menandatangani data wewenang. Selanjutnya, data yang telah dikodekan dikombinasikan dengan angka MAGIC untuk melakukan perhitungan hash keccak256, sehingga menghasilkan data yang akan ditandatangani. Terakhir, gunakan kunci pribadi pemberi wewenang untuk menandatangani data yang telah di-hash, sehingga diperoleh data y_parity, r, dan 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 mereplay otorisasi ( di semua rantai EVM yang mendukung EIP-7702 dengan syarat nonce juga tepat cocok dengan ).

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

Pada saat yang sama, transaksi semacam itu akan memaksa kolom authorization_list dalam transaksi tersebut harus setidaknya mencakup satu entri otorisasi. Jika ada beberapa entri otorisasi yang ditandatangani oleh otoriser yang sama, maka akhirnya hanya entri otorisasi terakhir yang akan berlaku.

Kemudian, selama proses eksekusi transaksi, node akan terlebih dahulu menambah nilai nonce dari pengirim transaksi, lalu 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), maka saat menandatangani transaksi otorisasi, nilai nonce harus ditambah 1.

Saat node menerapkan entri otorisasi tertentu, jika terjadi kesalahan, entri otorisasi ini akan dilewati, transaksi tidak akan gagal, entri otorisasi lainnya akan terus diterapkan, sehingga memastikan 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, address adalah alamat tujuan delegasi. Karena batasan EIP-3541, pengguna tidak dapat mengimplementasikan kode kontrak yang dimulai dengan byte 0xef dengan cara biasa, yang memastikan bahwa identifikasi semacam itu hanya dapat diterapkan oleh transaksi tipe SET_CODE_TX_TYPE (0x04).

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

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

Praktik Terbaik

Meskipun EIP-7702 telah memberikan kehidupan baru bagi ekosistem Ethereum, tetapi 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 memanfaatkan metode pemulihan sosial yang terintegrasi dalam kontrak pintar untuk mengatasi masalah kehilangan dana akibat kehilangan kunci pribadi setelah penugasan, risiko kebocoran kunci pribadi EOA tetap tidak dapat dihindari. Perlu ditegaskan bahwa setelah melakukan penugasan, kunci pribadi EOA tetap memiliki kontrol tertinggi atas akun, dan memiliki kunci pribadi memungkinkan untuk mengelola aset dalam akun dengan bebas. Bahkan setelah pengguna atau penyedia layanan dompet menyelesaikan penugasan untuk EOA, 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 melakukan delegasi, pengguna tetap harus mengutamakan perlindungan kunci pribadi, selalu ingat: Not your keys, not your coins.

Multi-chain Replay

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

tidak dapat diinisialisasi

Dompet kontrak pintar yang saat ini populer sebagian besar menggunakan model proksi. Saat dompet proksi dideploy, ia akan memanggil fungsi inisialisasi kontrak melalui DELEGateCALL untuk mencapai operasi atomik antara inisialisasi dompet dan deployment dompet proksi, sehingga menghindari masalah inisialisasi yang terlewat. Namun, saat pengguna menggunakan EIP-7702 untuk melakukan delegasi, hanya field code dari alamatnya yang akan diperbarui, dan tidak dapat melakukan inisialisasi melalui pemanggilan alamat delegasi. Ini membuat EIP-7702 tidak dapat memanggil fungsi inisialisasi untuk inisialisasi dompet dalam transaksi deployment kontrak seperti halnya kontrak proksi ERC-1967 yang umum.

Bagi pengembang, saat mengkombinasikan EIP-7702 dengan dompet EIP-4337 yang ada, perlu diperhatikan untuk melakukan pemeriksaan hak akses dalam operasi inisialisasi dompet, misalnya dengan menggunakan ecrecover untuk memulihkan alamat tanda tangan sebagai pemeriksaan hak akses, untuk menghindari risiko operasi inisialisasi dompet yang terganggu.

( 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 akibat buruk lainnya.

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

Bagi pengembang, selama proses pengembangan, mereka harus mengikuti Namespace Formula yang diusulkan oleh ERC-7201, yang 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, memverifikasi kompatibilitas penyimpanan sebelum delegasi ulang, serta 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, 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 menerapkan delegasi EIP-7702, jenis akun pengguna dapat beralih 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 untuk EOA.

Bagi pengembang kontrak, mengasumsikan bahwa tx.origin selalu merupakan EOA tidak akan lagi berlaku. Demikian juga, 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 kontrak, yang berarti penerima harus mengimplementasikan fungsi callback yang sesuai untuk berhasil menerima token.

Bagi pengembang, kontrak tujuan yang dikuasakan pengguna seharusnya mengimplementasikan fungsi callback yang sesuai, untuk memastikan kompatibilitas dengan token mainstream.

pemeriksaan memancing

Setelah menerapkan delegasi EIP-7702, aset dalam akun pengguna mungkin akan dikontrol oleh kontrak pintar. Begitu pengguna mendelegasikan akunnya ke kontrak jahat, maka penyerang 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 pengguna yang mungkin mengalami serangan phishing.

Selain itu, melakukan analisis otomatis yang lebih mendalam terhadap kontrak target yang didelegasikan akun ###, pemeriksaan sumber terbuka, pemeriksaan izin, dll ### dapat lebih baik membantu pengguna menghindari risiko semacam itu.

Ringkasan

Artikel ini membahas proposal EIP-7702 dalam pembaruan Pectra yang akan datang di Ethereum. 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 layanan dompet, pengembang, dan CEX, 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 dalam operasional nyata.