Ethereum Pectra Upgrade: Transformasi dan Tantangan yang Dibawa oleh EIP-7702

Pendahuluan

Ethereum akan segera menyambut pembaruan Pectra, yang merupakan pembaruan yang sangat signifikan, di mana sejumlah proposal perbaikan Ethereum yang penting akan diperkenalkan. Di antaranya, 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, dan membawa model interaksi baru bagi ekosistem Ethereum.

Pectra telah menyelesaikan penyebaran di jaringan pengujian dan diperkirakan akan segera diluncurkan di jaringan utama. Artikel ini akan menganalisis secara mendalam mekanisme implementasi EIP-7702, membahas peluang dan tantangan yang mungkin timbul, serta memberikan saran praktis untuk 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 mengeksekusi kode seperti kontrak pintar, sambil mempertahankan kemampuan untuk memulai transaksi. Fitur ini memberikan EOA kemampuan pemrograman dan kombinasi, memungkinkan pengguna untuk menerapkan pemulihan sosial, kontrol izin, manajemen multi-tanda tangan, verifikasi zk, pembayaran berbasis langganan, sponsor transaksi, dan pemrosesan batch transaksi. Perlu dicatat bahwa EIP-7702 dapat sepenuhnya kompatibel dengan dompet kontrak pintar yang diimplementasikan oleh EIP-4337, dan integrasi seamless antara 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, kecuali bidang authorization_list, yang lainnya mengikuti makna yang sama dengan EIP-4844. Bidang ini adalah tipe daftar, yang dapat berisi beberapa entri otorisasi, di mana setiap entri otorisasi:

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

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

implementasi

Saat pemberi kuasa menandatangani data kuasa, perlu terlebih dahulu melakukan pengkodean RLP pada chain_id, address, nonce. Kemudian, data yang telah dikodekan tersebut digabungkan dengan MAGIC untuk melakukan perhitungan hash keccak256, menghasilkan data yang akan ditandatangani. Terakhir, gunakan kunci pribadi pemberi kuasa untuk menandatangani data yang telah di-hash, mendapatkan data y_parity, r, s. MAGIC (0x05) digunakan sebagai pemisah domain, memastikan bahwa hasil tanda tangan dari jenis yang berbeda tidak akan terjadi konflik.

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

Setelah pemberi kuasa menandatangani data kuasa, peng发起 transaksi akan mengumpulkannya di field authorization_list untuk ditandatangani dan disiarkan transaksi melalui RPC. Sebelum transaksi dieksekusi dan dimasukkan ke dalam blok, Proposer akan terlebih dahulu melakukan pra-pemeriksaan transaksi, di mana alamat to akan diperiksa secara ketat untuk memastikan bahwa transaksi ini bukan merupakan transaksi pembuatan kontrak.

Sementara itu, transaksi semacam itu mengharuskan kolom authorization_list harus mencakup setidaknya satu entri otorisasi, jika ada beberapa entri otorisasi yang ditandatangani oleh otorisator yang sama, hanya entri otorisasi terakhir yang berlaku.

Dalam proses pelaksanaan 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 pihak yang memberikan otorisasi. 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 aplikasi node menggunakan suatu entri otorisasi, jika terjadi kesalahan, entri otorisasi tersebut akan dilewati, transaksi tidak akan gagal, dan entri otorisasi lainnya akan terus diterapkan, sehingga 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 target yang dikuasakan. Karena batasan EIP-3541, pengguna tidak dapat menggunakan cara biasa untuk menyebarkan kode kontrak yang dimulai dengan byte 0xef, yang menjamin bahwa identifikasi semacam itu hanya dapat disebarkan oleh transaksi tipe SET_CODE_TX_TYPE (0x04).

Setelah otorisasi selesai, jika pemberi otorisasi ingin mencabut otorisasi, cukup atur alamat tujuan yang dikuasakan menjadi 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 ), yang secara signifikan mengurangi hambatan penggunaan bagi pengguna.

Praktik Terbaik

Meskipun EIP-7702 telah menghidupkan kembali ekosistem Ethereum, namun skenario aplikasi baru juga akan membawa risiko baru. Berikut adalah aspek-aspek yang perlu diperhatikan oleh para peserta ekosistem dalam proses praktik:

penyimpanan kunci pribadi

Meskipun EOA dapat mengatasi masalah kehilangan dana akibat kunci privat yang hilang dengan menggunakan metode pemulihan sosial yang terintegrasi dalam kontrak pintar setelah delegasi, risiko kebocoran kunci privat EOA tetap tidak dapat dihindari. Perlu dicatat bahwa setelah menjalankan delegasi, kunci privat EOA masih memiliki kontrol tertinggi atas akun, dan memiliki kunci privat memungkinkan untuk mengelola aset dalam akun tersebut sesuka hati. Pengguna atau penyedia layanan dompet, setelah menyelesaikan delegasi untuk EOA, meskipun sepenuhnya menghapus kunci privat yang disimpan secara lokal, tidak dapat sepenuhnya menghilangkan risiko kebocoran kunci privat, terutama dalam skenario yang berisiko serangan rantai pasokan.

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

pemutaran multi rantai

Pengguna dapat memilih chainId saat menandatangani otorisasi delegasi untuk menentukan rantai tempat delegasi dapat berlaku. Pengguna juga dapat memilih untuk menggunakan chainId 0 untuk delegasi, sehingga delegasi dapat direplikasi dan berlaku di beberapa rantai, memudahkan pengguna untuk melakukan delegasi dengan hanya satu tanda tangan. Namun, perlu diperhatikan bahwa mungkin ada kode implementasi yang berbeda di alamat kontrak yang sama di beberapa rantai.

Untuk 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 rantai yang berbeda 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. Proxy dompet saat penggelaran, akan memanggil fungsi inisialisasi kontrak melalui DELEGateCALL untuk mencapai operasi atomik antara inisialisasi dompet dan penggelaran dompet proxy, menghindari masalah inisialisasi yang lebih awal. Namun, saat pengguna menggunakan EIP-7702 untuk delegasi, hanya field code dari alamatnya yang akan diperbarui, dan tidak dapat melakukan inisialisasi melalui pemanggilan alamat delegasi. Hal ini membuat EIP-7702 tidak dapat memanggil fungsi inisialisasi untuk inisialisasi dompet dalam transaksi penggelaran kontrak seperti kontrak proxy ERC-1967 yang umum.

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

Manajemen Penyimpanan

Saat 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), dalam kasus mendelegasikan 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 re-delegasi.

Bagi para pengembang, selama proses pengembangan harus mengikuti Namespace Formula yang diajukan oleh ERC-7201, dengan mendistribusikan 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, serta memverifikasi kompatibilitas penyimpanan sebelum delegasi ulang, dan memanggil antarmuka delegasi lama untuk membersihkan data lama dari penyimpanan.

Isi Ulang Palsu

Setelah pengguna melakukan penugasan, EOA juga akan dapat digunakan sebagai kontrak pintar, sehingga beberapa bursa mungkin akan menghadapi situasi di mana pengisian ulang kontrak pintar menjadi umum.

Bursa 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 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 merusak beberapa asumsi keamanan yang hanya membolehkan partisipasi EOA dalam proyek.

Bagi pengembang kontrak, anggapan bahwa tx.origin selalu merupakan EOA tidak lagi dapat diterapkan. Begitu juga, pemeriksaan melalui msg.sender == tx.origin untuk melindungi dari 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 saat ini memiliki fungsi Hook saat mentransfer 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 pancing

Setelah menerapkan delegasi EIP-7702, aset dalam akun pengguna mungkin akan dikendalikan oleh kontrak pintar. Begitu pengguna mendelegasikan akun ke kontrak yang jahat, maka penyerang akan dengan mudah mencuri dana.

Untuk 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 mungkin menjadi korban serangan phishing.

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

Ringkasan

Artikel ini membahas usulan EIP-7702 dalam pembaruan Pectra Ethereum yang akan datang. EIP-7702 memperkenalkan jenis transaksi baru, memberikan EOA kemampuan untuk diprogram dan dapat digabungkan, sehingga membingungkan batasan 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, dan bursa 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 dipertimbangkan dan diterapkan oleh semua pihak dalam praktik.