Dalam peningkatan Pectra, muncul masalah sengketa tata kelola yang paling kompleks. Ketika EIP3074 dimasukkan ke dalam peningkatan Pectra, menyebabkan perdebatan yang besar, terutama dari tim ERC4337 yang menentang.
EIP3074 terjebak dalam kesulitan, proses pemerintahan tidak dapat dilanjutkan. Sampai Vitalik mengajukan EIP7702 yang mengakhiri keraguan tim ERC4337 terhadap EIP3074.
GCC Research menemukan bahwa ada sedikit diskusi tentang masalah tata kelola EIP3074 dan ERC7702 dalam peningkatan Pectra di dunia berbahasa Mandarin. Namun, masalah tata kelola ini juga mencerminkan masalah mendalam dalam tata kelola Ethereum, yaitu siapa yang dapat mengontrol isi spesifik dari kode di bawah premis code is law. Masalah tata kelola EIP3074 dan ERC7702 dapat memberikan kita perspektif yang baik untuk mengamati proses tata kelola nyata di dalam Ethereum.
Kesimpulan akhir dari artikel ini diambil dari komentar yang diterbitkan oleh ZeroDev, yang menunjukkan bahwa sistem pemerintahan Ethereum adalah model VVRC, di mana setiap proposal yang dimasukkan harus terlebih dahulu sesuai dengan nilai-nilai Ethereum (Value), kemudian proposal tersebut harus mencerminkan visi yang dirancang oleh Vitalik (Vision), akhirnya proposal tersebut harus tercermin dalam peta jalan (Roadmap), dan terakhir setelah diskusi oleh pengembang inti, proposal tersebut akan dimasukkan ke dalam implementasi klien (Client).
GCC Research dalam artikel sebelumnya memperkenalkan EIP2537 yang hanya mengalami masalah implementasi di tingkat Client yang menyebabkan penundaan akhirnya untuk bergabung dalam hard fork, sedangkan EIP3074 tidak dimasukkan ke dalam hard fork karena masalah Visi dan Peta Jalan, dan para pengembang inti Ethereum langsung memilih EIP7702 yang ditulis oleh Vitalik sebagai proposal abstraksi akun akhir.
Ringkasan Isi Proposal
Sebelum memperkenalkan proses tata kelola secara spesifik, kita terlebih dahulu perlu memperkenalkan secara singkat tentang EIP3074, EIP7702, dan ERC4337 yang dibahas dalam artikel ini.
EIP3074 adalah proposal lapisan eksekusi yang eksekusinya memerlukan peningkatan perangkat lunak node. Tujuan inti dari EIP3074 adalah untuk memungkinkan sponsor gas dan perdagangan massal. Yang disebut sponsor gas berarti bahwa pengguna dapat membayar biaya gas dengan token apa pun, atau pengguna dapat membayar biaya gas secara offline. Namun, perlu dicatat bahwa EIP3074 tidak mengizinkan pengguna untuk menggunakan algoritma tanda tangan apa pun selain secp256k1, dibandingkan dengan proposal abstraksi akun lain yang memungkinkan perubahan pada algoritma verifikasi tanda tangan. Dengan kata lain, EIP3074 bukanlah proposal yang memenuhi semua abstraksi akun. Ini juga merupakan poin yang EIP3074 telah dikritik.
Untuk mencapai tujuan yang diharapkan, EIP3074 memperkenalkan dua opcode, yaitu AUTH dan AUTHCALL. Opcode AUTH dapat memverifikasi tanda tangan, dan setelah verifikasi tanda tangan berhasil, opcode ini akan mengonfigurasi authorized dalam konteks EVM saat ini menjadi alamat penandatangan. Setelah mengonfigurasi authorized dalam konteks, AUTHCALL dapat menggunakan alamat authorized sebagai msg.sender untuk memulai transaksi. Dalam arti tertentu, pengguna dapat mendelegasikan akun mereka untuk digunakan oleh kontrak pintar dalam sebuah transaksi melalui tanda tangan. Kontrak pintar yang didelegasikan oleh pengguna ini biasanya disebut sebagai kontrak invoker.
Apa isi tanda tangan spesifik pengguna itu? Pengguna perlu menandatangani konten berikut:
Alamat invoker yang disebutkan di atas merujuk pada alamat kontrak invoker yang ingin didelegasikan oleh pengguna. EVM akan memverifikasi apakah konten tanda tangan pengguna sesuai dengan kontrak yang benar-benar memverifikasi tanda tangan, untuk menghindari penggunaan konten tanda tangan AUTH pengguna oleh kontrak lain.
Nonce adalah sebuah penanda untuk mencegah pengulangan transaksi. Namun, perlu diperhatikan bahwa kode operasi AUTH akan memeriksa apakah nonce dalam tanda tangan sesuai dengan nonce EOA dari tanda tangan saat ini. Secara teoritis, selama pengguna tidak menggunakan akun EOA untuk memulai transaksi yang meningkatkan nilai nonce, maka tanda tangan AUTH yang dikeluarkan oleh pengguna dapat terus digunakan oleh kontrak invoker. Ini adalah celah keamanan yang besar, yang berarti pengguna yang menggunakan EIP3074 harus mempercayai penyedia layanan relai yang mendapatkan tanda tangan. Jika penyedia layanan relai yang mendapatkan tanda tangan pengguna adalah jahat, penyedia tersebut dapat pada suatu saat mengulang tanda tangan AUTH pengguna untuk mencuri aset pengguna.
Masalah lain yang memiliki isu keamanan adalah field commit. Field commit digunakan untuk memastikan operasi tertentu, pengguna dapat mengontrol hak tanda tangan mereka secara rinci dalam commit, seperti menulis beberapa konten dalam commit untuk mencegah konten tanda tangan mereka digunakan untuk transfer ETH. Dalam dokumen EIP3074, pengusul memberikan serangkaian contoh penggunaan field commit. Namun, masalahnya adalah fungsi commit sepenuhnya bergantung pada definisi kontrak pintar, yang pada dasarnya adalah konten opsional. Kontrak pintar yang berbeda mungkin memiliki interpretasi yang sama sekali tidak konsisten terhadap konten dalam commit, bahkan mungkin beberapa kontrak tidak membaca sama sekali konten dalam commit. Jika pengguna ingin menggunakan EIP3074 dengan aman, mereka harus melakukan pemeriksaan sederhana terhadap kontrak pintar.
Akhirnya, kami memperkenalkan dampak EIP3074 terhadap mempool transaksi Ethereum saat ini. Setelah pengenalan EIP3074, mungkin akan muncul metode serangan terhadap mempool, di mana peretas dapat menggunakan banyak akun untuk melakukan transaksi, dan kemudian saat transaksi tersebut akan dip打包, menggunakan EIP3074 untuk sekaligus menguras ETH dari akun-akun tersebut, yang akan menyebabkan semua transaksi yang telah diajukan sebelumnya gagal. Metode serangan ini akan berdampak cukup besar pada node lapisan eksekusi, pada dasarnya merupakan jenis serangan DoS. Namun perlu dicatat bahwa EIP7702 yang menggantikan EIP3074 juga mengalami masalah ini, tetapi EIP7702 memperkenalkan beberapa batasan untuk mencegah masalah ini muncul, yang akan kami bahas lebih lanjut.
Selain masalah yang ada pada EIP3074 yang telah dijelaskan di atas, penulis ERC4337, Yova, dalam artikel Implications of EIP-3074 inclusion menjelaskan lebih banyak opini yang menentang. Secara singkat, opini-opini ini terutama mencakup:
Risiko sentralisasi. Karena sifat khusus dari tanda tangan AUTH, pengguna harus sepenuhnya mempercayai penyedia layanan relai EIP3074 dan infrastruktur dasar. Saat ini, infrastruktur yang dibangun oleh protokol abstraksi akun seperti ERC4337 sepenuhnya tidak kompatibel dengan EIP3074.
Keamanan pengguna. Seperti yang disebutkan di atas, EIP3074 tidak memiliki metode kontrol akses yang dirancang secara seragam, dan desain nonce tanda tangan juga memiliki risiko keamanan, yang sangat mungkin menyebabkan masalah keamanan yang serius.
Fitur abstraksi akun yang tidak lengkap. Dibandingkan dengan proposal abstraksi akun lainnya, EIP3074 tidak lengkap dan tidak dapat mengimplementasikan fungsi-fungsi seperti mengganti algoritma tanda tangan pengguna.
Masalah pengalaman pengguna. Ketika pengguna perlu mendelegasikan akunnya kepada kontrak pintar, pengguna perlu melakukan satu tanda tangan AUTH, kemudian menerbitkan panggilan yang berisi tanda tangan AUTH ke blockchain. Pengguna perlu melakukan dua tanda tangan.
EIP7702 adalah sebuah proposal yang diajukan oleh Vitalik untuk menggantikan EIP3074. Proposal ini tidak memperkenalkan opcode EVM baru, melainkan memperkenalkan jenis transaksi baru yang disebut SET_CODE_TX_TYPE. Setelah pengguna memulai transaksi jenis EIP7702, pengguna dapat menambahkan fungsi kontrak pintar ke EOA mereka tanpa menghilangkan fungsi dasar EOA. Singkatnya, pengguna dapat terus menggunakan dompet seperti MetaMask untuk memulai transaksi, atau pengguna lain dapat memanggil alamat EOA dalam bentuk kontrak pintar.
Mari kita lihat fitur EIP7702 dengan contoh sederhana perdagangan massal. Pengguna dapat menggunakan EIP7702 untuk mendelegasikan alamat EOA mereka ke kontrak pintar yang dapat melakukan panggilan massal, dan kemudian pengguna dapat langsung memanggil alamat EOA mereka dalam bentuk kontrak pintar untuk memulai transaksi massal.
Dalam hal implementasi teknis, dibandingkan dengan transaksi tradisional, EIP7702 memperkenalkan daftar jenis transaksi otor_list isasi, yaitu [[chain_id, address, nonce, y_parity, r, s], ...]. di mana alamat adalah alamat kontrak pintar yang ingin didelegasikan pengguna, dan nonce adalah nilai nonce pengguna saat ini. Sisa y_parity, r, dan s adalah hasil dari tanda tangan pengguna. Dalam proses eksekusi tertentu, pertama-tama kita akan mengulangi setiap item dalam otorisasi \ _list untuk diproses, dan metode pemrosesan adalah mengembalikan alamat EOA melalui parameter tanda tangan seperti y \ _parity, dan kemudian arahkan alamat EOA ke kontrak pintar dengan alamat alamat. Setelah itu, alamat EOA dapat menerima panggilan untuk memainkan fungsi kontrak.
Keuntungan EIP7702 sangat jelas, di mana keuntungan inti adalah EIP7702 pada dasarnya memungkinkan EOA memiliki fungsi kontrak pintar. Ini konsisten dengan aturan dasar abstraksi akun seperti ERC4337, yang berarti EIP7702 dapat memanfaatkan semua eksplorasi saat ini di bidang abstraksi akun dan menggunakan kembali infrastruktur yang ada, misalnya EIP7702 dapat langsung menggunakan infrastruktur ERC4337. Saat ini, ERC4337 telah meluncurkan EntryPoint v0.8 yang mendukung panggilan EIP7702. Dari sudut pandang pemanfaatan infrastruktur yang ada, EIP7702 memiliki tingkat desentralisasi yang sama dengan ERC4337.
Tentu saja, EIP7702 sebenarnya juga tidak sepenuhnya memperbaiki masalah yang muncul di EIP3074. Sebagian besar masalah yang ada di EIP3074 masih ada. EIP7702 mengharuskan kontrak akun memiliki implementasi yang aman, sedangkan protokol itu sendiri tidak menjamin keamanan apapun. Pada awal diusulkannya EIP7702, ada beberapa pengembang yang mengusulkan untuk menstandarisasi nonce tanda tangan untuk menghindari kemungkinan serangan replay, tetapi EIP7702 akhirnya tidak menerima saran-saran tersebut. Jadi jika pengguna ingin menggunakan EIP7702 dengan aman, maka pengguna perlu memeriksa keamanan kontrak sendiri.
Sementara itu, EIP7702 juga akan membawa serangkaian masalah bagi lapisan eksekusi. Dalam pembahasan sebelumnya, kami telah memperkenalkan salah satu kemungkinan cara untuk melakukan serangan DoS pada mempool lapisan eksekusi menggunakan EIP3074. Metode ini juga berlaku untuk EIP7702. Oleh karena itu, EIP7702 menyarankan agar semua alamat EOA yang menggunakan EIP7702 hanya dapat memiliki satu transaksi yang menunggu di dalam mempool, untuk menghindari munculnya serangan DoS dalam skala besar.
Secara keseluruhan, masalah terbesar EIP3074 adalah EIP3074 tidak menerapkan fungsi abstraksi akun yang lengkap, sementara EIP7702 telah menerapkan fungsi abstraksi akun yang lengkap. Dan definisi "abstraksi akun yang lengkap" mencakup konten yang ditentukan oleh penulis ERC4337. Setelah membaca ini, pembaca seharusnya dapat memahami mengapa EIP3074 ditentang oleh tim ERC4337 dan akhirnya digantikan oleh EIP7702. Kami akan memperkenalkan seluruh proses pemerintahan dan diskusi di bagian selanjutnya.
Proses tata kelola EIP3074 dan EIP7702
EIP3074 disebutkan sangat awal dalam pertemuan pengembang inti Ethereum. Pada 2 April 2021 dalam Pertemuan #109, para pengembang inti Ethereum melakukan diskusi sederhana mengenai EIP3074. Hasil diskusinya sangat sederhana:
Alexey mengemukakan bahwa konten tanda tangan EIP3074 memiliki risiko keamanan, yang dapat menyebabkan kerugian keamanan yang serius bagi pengguna, dan menyarankan agar EIP3074 lebih lanjut menstandarkan konten spesifik dari tanda tangan AUTH, usulan ini didukung oleh Martin.
James mengusulkan bahwa EIP3074 dapat membawa potensi kerentanan lapisan eksekusi, seperti serangan DoS, dan menyarankan agar EIP3074 memberikan analisis ancaman secara tertulis.
Alexey dan Martin mengeluh bahwa kualitas dokumen EIP3074 biasa saja, menghabiskan banyak waktu untuk membaca dan memahaminya.
Martin percaya bahwa inti dari EIP3074 adalah kolaborasi dan implementasi dengan aplikasi, terutama pengembang dompet. Penulis EIP3074 menyatakan bahwa mereka telah melakukan serangkaian komunikasi dengan pengembang aplikasi.
Menariknya, Vitalik dalam konferensi ini berpendapat bahwa bagaimanapun juga, Ethereum memerlukan sebuah solusi teknis yang dirancang untuk menghasilkan beberapa panggilan dari satu transaksi untuk EOA. Meskipun EIP3074 memiliki potensi masalah keamanan, EIP3074 memberikan sebuah solusi teknis yang mungkin, dan para pengembang perlu maju berdasarkan EIP3074.
Jelas, karena EIP3074 memiliki masalah keamanan, pertemuan kali ini tidak memasukkan EIP3074 ke dalam pembaruan London.
Pada Meeting #115 tanggal 11 Juni 2021, pengembang EIP3074 mengajukan laporan terkait audit keamanan, dan pertemuan ini terutama membahas masalah keamanan EIP3074. Kesimpulan sederhana adalah bahwa kontrak invoker EIP3074 sangat penting dalam sistem, sehingga apakah perlu mengelola kontrak invoker adalah sebuah pertanyaan. Pengembang EIP3074 berharap untuk melakukan pembuktian formal terhadap kontrak invoker untuk meningkatkan keamanan.
Tentu, ada beberapa diskusi tentang beberapa kontrak yang menggunakan msg.sender == tx.origin untuk menentukan apakah alamat pemanggil adalah EOA. Ketika EIP3074 diperkenalkan, semua pemeriksaan ini akan menjadi tidak berlaku, tetapi kesimpulannya adalah bahwa kegagalan pemeriksaan ini tidak akan menimbulkan masalah keamanan yang serius. Singkatnya, pertemuan kali ini terutama adalah tentang pengenalan hasil audit keamanan 3074 oleh pengusul EIP3074 kepada para pengembang inti. Kesimpulan akhir dari pertemuan adalah bahwa 3074 masih perlu mempertimbangkan masalah kontrak invoker, disarankan untuk tidak memasukkannya dalam hard fork London.
Dalam Pertemuan #116 pada 25 Juni 2021, Yova, penulis inti ERC4337, mengajukan kasus untuk alternatif yang lebih sederhana untuk EIP 3074, yang menunjukkan bahwa ada banyak masalah keamanan di EIP3074 dan menyarankan agar beberapa di antaranya dimodifikasi, seperti membatasi konten bidang komit di tanda tangan, mengharuskan bidang komit menjadi {nonce,to,gas, calldata,nilai,chainid}. Dengan pola tanda tangan ini, EIP3074 hanya dapat digunakan untuk melakukan transaksi tertentu agar tetap aman.
Dalam pertemuan ini, penulis EIP3074 memberikan tanggapan terhadap materi yang diajukan oleh Yova:
Harap memasukkan alamat kontrak invoker ke dalam spesifikasi EIP, kemudian oleh pengembang inti Ethereum menulis kontrak invoker yang aman untuk menghindari masalah keamanan.
Mengenai konten commit dalam tanda tangan, pengembang EIP3074 berpendapat bahwa ini sepenuhnya merupakan masalah pengguna dan perangkat lunak dompet, dan tidak perlu dinyatakan dalam EIP.
Vitalik mengemukakan tiga poin berikut dalam konferensi ini:
EIP3074 masih menggunakan skema tanda tangan tradisional secp256k1 yang tidak dapat mencapai karakteristik tahan kuantum.
EIP3074 tidak memiliki kompatibilitas masa depan, menggunakan EIP3074 juga tidak dapat membuat EOA berevolusi menjadi akun kontrak pintar.
EIP3074 memiliki siklus hidup yang terbatas. 3074 memperkenalkan dua kode pra-assembly AUTH dan AUTHCALL, tetapi sesuai dengan peta jalan abstraksi akun, di masa depan semua dompet di Ethereum mungkin akan menjadi dompet kontrak pintar, kode pra-assembly EIP3074 akan dihapus di masa depan.
Dalam Meeting #131 pada 4 Februari 2022, para pengembang mendiskusikan jenis EIP yang harus disertakan dalam upgrade ShangHai. EIP3074 dimasukkan dalam ruang diskusi, tetapi para pengembang hanya menyinkronkan perkembangan EIP3074 secara sederhana. Perlu dicatat, sebelum rapat dimulai, nethermind menulis artikel Ethereum wallets today and tomorrow — EIP-3074 vs. ERC-4337, yang tidak mencakup pendapat yang menentang EIP3074.
Pada Meeting #167 yang diadakan pada 3 Agustus 2023, pengembang inti menyebutkan EIP3074 saat membahas EIP5806. EIP5806 adalah sebuah proposal yang memungkinkan EOA untuk memanggil kontrak eksternal dengan menggunakan cara deleGate.io call selama proses transaksi. Skema ini mirip dengan EIP7702 dalam beberapa hal. Namun, pengembang inti juga mengungkapkan keraguan mengenai keamanan skema ini, Ansgar menunjuk bahwa EIP3074 tidak dapat dimasukkan ke dalam hard fork karena masalah keamanan yang mungkin ada, sementara EIP5806 adalah skema yang jauh lebih agresif.
Pada Meeting #182 yang diadakan pada 29 Februari 2024, para pengembang secara rinci membahas apakah EIP3074 harus dimasukkan dalam peningkatan Pectra. Vitalik mengusulkan bahwa standar abstraksi akun mana pun harus memiliki tiga fungsi berikut:
Rotasi Kunci
Pembuangan Kunci
Dapat kompatibel dengan tanda tangan anti-kuantum
Vitalik menunjukkan bahwa EIP5806 mungkin merupakan pilihan yang lebih baik dibandingkan EIP3074. Andrew berpendapat bahwa EIP3074 lebih umum dibandingkan EIP5806, dan menyarankan untuk menggunakan EIP3074. Vitalik membantah Andrew, berpendapat bahwa di masa depan semua dompet mungkin akan menjadi dompet kontrak pintar, dan begitu hal ini terjadi, opcode pre-assembly yang diperkenalkan oleh EIP3074 akan menjadi tidak berlaku. Yoav, sebagai penulis ERC4337, memberikan pernyataan yang cukup panjang dalam pertemuan kali ini, yang terutama mencakup:
EIP3074 dapat menyebabkan serangan DoS pada mempool Ethereum, sementara ERC4337 melakukan banyak penelitian pada bagian ini dan memberikan beberapa aturan untuk menghindari serangan.
EIP3074 memerlukan tanda tangan dua kali saat pengguna menginisiasi transaksi massal, ini tidak wajar.
EIP3074 mengharuskan penggunaan perantara terpusat
Yova lebih cenderung menggunakan EIP5806 sebagai skema abstraksi akun.
Inside Meeting #183 pada 14 Maret 2024, pengembang inti mengundang Dan Finlay dari MetaMask untuk membahas apa pendapat dompet tentang EIP3074. Dan mendukung EIP3074, mencatat bahwa MetaMask juga akan mendukung pengujian EIP3074. MetaMask percaya bahwa EIP3074 dapat secara fungsional memungkinkan EOA untuk menikmati fungsionalitas penuh abstraksi akun. Dalam hal keamanan, EIP3074 memberikan solusi bagi penyedia layanan dompet, yaitu pemisahan kunci panas dan dingin. Penyedia layanan dompet dapat menyimpan tanda tangan EIP3074 EOA untuk memulai transaksi, dan pengguna dapat menggunakan kunci pribadi panas dalam transaksi normal, tetapi kunci pribadi dingin dapat disimpan di dompet perangkat keras pengguna, dan ketika keadaan darurat ditemukan, pengguna dapat menggunakan kunci pribadi dingin di dompet dingin untuk memulai transaksi untuk mencabut tanda tangan EIP3074. Solusi pemisahan kunci pribadi panas dan dingin ini memberikan fleksibilitas kepada penyedia dompet.
Vitalik menunjukkan bahwa dalam EIP3074, perancang dompet harus merancang logika otorisasi yang ketat untuk menghindari penyalahgunaan tanda tangan EIP3074 pengguna. Menariknya, dalam diskusi tentang penambahan dukungan fitur EIP3074 di MetaMask, Vitalik menunjukkan bahwa L2 dapat digunakan sebagai solusi transisi, yaitu setiap modifikasi lapisan eksekusi baru harus dilakukan terlebih dahulu di L2, karena jumlah dana di L2 terbatas, meskipun terjadi masalah serius, kerugian yang dialami akan sangat besar.
Dror Tiros dalam diskusi menunjukkan bahwa cara terbaik untuk memastikan keamanan EIP3074 adalah dengan memberikan kontrak invoker secara langsung oleh Ethereum resmi. Namun, Dan Finlay menentang pendapat bahwa kontrak tersebut harus diberikan secara resmi, Dan percaya bahwa kontrak invoker seharusnya sepenuhnya ditentukan oleh pengguna, pasar pada akhirnya akan memilih kontrak invoker yang paling aman.
Ansgar tetap berpegang pada EIP3074 bahwa satu tanda tangan seharusnya hanya berkaitan dengan satu transaksi, penyedia dompet tidak seharusnya menggunakan kembali tanda tangan pengguna untuk memulai transaksi, tetapi Dan Finlay juga menyatakan keberatan. Dan Finlay berpendapat bahwa EIP3074 seharusnya ditandatangani oleh dompet dingin, kemudian penyedia dompet dapat menggunakan kembali tanda tangan tersebut untuk langsung memulai transaksi bagi pengguna. Jika setiap kali pengguna diminta untuk menandatangani ulang, ini dapat menyebabkan kunci privat dingin digunakan berkali-kali. Ini tidak sejalan dengan pemisahan antara kunci privat dingin dan panas.
Dalam pertemuan ini, pengembang inti membahas topik penting lainnya yaitu daftar inklusi. Daftar inklusi adalah cara untuk meningkatkan sifat anti-sensor Ethereum. Secara sederhana, daftar inklusi memungkinkan beberapa transaksi dijanjikan untuk langsung dimasukkan ke dalam blok berikutnya. Namun, pengembang inti menunjukkan bahwa EIP3074 bertentangan dengan daftar inklusi.
Pada pertemuan Meeting #185 pada 11 April 2024, sebagian besar implementasi klien di dalamnya setuju untuk memasukkan EIP3074 ke dalam hard fork Pectra, tetapi Geth menyatakan keberatan karena EIP3074 dapat menyebabkan masalah pada Verkle tree. Danno tetap menyatakan keberatan karena EIP3074 dapat menyebabkan masalah penggunaan ulang tanda tangan. Yoav juga menyatakan keberatan, memberikan skema yang menggunakan EIP3074 dan transaksi Blob untuk menyerang mempool. Singkatnya, penyerang dapat meluncurkan sejumlah besar transaksi Blob, yang semuanya mengandung sejumlah besar data, kemudian menggunakan EIP3074 untuk membuat semua transaksi Blob ini tidak berlaku.
Singkatnya, dalam pertemuan ini, semua pengembang klien sepakat bahwa EIP3074 akan dimasukkan ke dalam pembaruan akhir.
Dalam Meeting #187 pada 9 Mei 2024, para pengembang inti membahas masalah penggantian EIP3074 EIP7702 untuk pertama kalinya. EIP7702 dilakukan dalam 90 menit pertama pertemuan pengembang inti Vitalik. Selama konferensi, pengembang inti mengakui EIP7702 sebagai standar yang lebih baik daripada EIP3074. Tidak ada oposisi terhadap EIP7702 pada pertemuan ini, tetapi beberapa peneliti percaya bahwa EIP7702 juga memiliki atribut yang tidak dapat dibatalkan yang mirip dengan EIP3074, yang dapat menyebabkan masalah keamanan finansial.
Pada pertemuan Meeting #188 yang diadakan pada 23 Mei 2024, pengembang inti mendiskusikan kemungkinan EIP7702 menggantikan EIP3074. Kesimpulan akhir dari pertemuan ini adalah menggunakan EIP7702 sebagai standar abstraksi akun dalam hard fork Pectra untuk menggantikan EIP3074. Vitalik menunjukkan bahwa EIP7702 juga memiliki beberapa sifat yang tidak dapat dibatalkan yang konsisten dengan EIP3074, dan sifat-sifat ini telah banyak dibahas saat mendiskusikan EIP3074. Menariknya, terdapat banyak perwakilan ERC4337 yang berpartisipasi dalam diskusi di pertemuan ini.
Sebenarnya, diskusi tentang EIP3074 yang akan digantikan oleh EIP7702 telah dibahas secara luas sebelum 188 pertemuan pengembang inti, dan hasil diskusinya adalah bahwa 3074 akan digantikan, jadi tidak ada banyak perselisihan dalam pertemuan pengembang inti.
Peta Jalan dan Keputusan
Infrastruktur inti dari abstraksi akun Zerodev, setelah mengetahui bahwa EIP3074 akan digantikan, menerbitkan sebuah artikel menarik yang berjudul Reflections on Ethereum Governance Following the 3074 Saga. Kesimpulan dari artikel tersebut adalah EIP7702 adalah proposal yang baik, yang dapat memberikan manfaat bagi semua pengguna. Namun, proses tata kelola EIP7702 yang menggantikan EIP3074 bukanlah yang terbaik, alasannya termasuk:
EIP3074 telah melalui proses diskusi yang panjang, dalam teks di atas kami telah memperkenalkan beberapa diskusi EIP3074 dalam pertemuan pengembang inti.
EIP3074 menerima banyak penolakan dari komunitas ERC4337 setelah ditentukan untuk dimasukkan dalam peningkatan Pectra. Tentu saja, seperti yang telah kami sebutkan di atas, pengembang inti ERC4337 yova telah beberapa kali mengungkapkan penolakannya terhadap EIP3074 dalam pertemuan pengembang inti.
Zerodev berpendapat bahwa jalur tata kelola terbaik seharusnya melibatkan partisipasi luas dari komunitas ERC4337 dan mengungkapkan pendapat mereka dalam proses diskusi pengembang inti EIP3074 yang panjang.
Pengembang EIP3074 percaya bahwa ERC4337 seharusnya bertanggung jawab atas kegagalan tata kelola. Karena EIP3074 telah aktif terlibat dalam tata kelola selama beberapa tahun terakhir dan telah berkomunikasi beberapa kali dengan pengembang inti ERC4337 yova.
Komunitas ERC4337 percaya bahwa EIP3074 harus bertanggung jawab atas kegagalan dalam pengelolaan. Anggota komunitas ERC4337 berpendapat bahwa Yova, sebagai pengembang inti ERC4337, telah menyampaikan keberatan terhadap EIP3074 dalam beberapa pertemuan pengembang inti, tetapi pengembang inti tampaknya tidak mendengarkan pendapat tersebut. Sebagian besar anggota komunitas ERC4337 tidak memperhatikan dinamika pengelolaan EIP3074, dan sebagian besar anggota menganggap EIP3074 sebagai standar yang sudah mati. Komunitas ERC4337 juga berpendapat bahwa pengembang inti tidak secara aktif berkomunikasi dengan komunitas ERC4337.
EIP3074 dan ERC4337 sama-sama mengklaim telah melakukan pekerjaan tata kelola yang benar, sementara pihak lainnya harus menanggung tanggung jawab utama atas kegagalan tata kelola. Jelas bahwa ada suatu alasan yang lebih mendalam yang berperan dalam proses tata kelola ini.
Secara sederhana, alasan yang lebih mendalam ini sebenarnya adalah peta jalan Ethereum. Peta jalan Ethereum memiliki kekuatan yang melebihi pertemuan pengembang inti. Peta jalan abstraksi akun berfokus pada ERC4337. EIP7702 sepenuhnya kompatibel dengan standar ERC4337, tetapi EIP3074 tidak sepenuhnya kompatibel dengan standar ERC4337. Jadi, dari sudut pandang peta jalan Ethereum, penggantian EIP3074 pasti akan terjadi.
Tentu saja, peta jalan Ethereum adalah representasi dari visi masa depan Ethereum yang dipaparkan oleh Vitalik secara pribadi. Jika terjadi perdebatan serius dalam proses tata kelola Ethereum, maka sebagai pendefinisi peta jalan, Vitalik memiliki hak keputusan terakhir. Dan keputusan Vitalik lah yang menyebabkan EIP3074 digantikan.
Model pemerintahan Ethereum adalah model values ⇒ vision ⇒ roadmaps ⇒ clients, atau disingkat model VVRC. Proses pemerintahan adalah sebagai berikut:
nilai-nilai, terutama nilai-nilai komunitas, nilai-nilai komunitas Ethereum mencakup desentralisasi, anti-pencensuran, dan lain-lain
visi, sebenarnya adalah pemikiran pribadi Vitalik tentang masa depan Ethereum
roadmaps, peneliti memberikan beberapa pertimbangan teknis berdasarkan visi untuk memberikan peta jalan implementasi yang lebih lengkap.
klien Implementasi klien, pengembang inti klien menggunakan alat seperti pertemuan pengembang inti untuk mendiskusikan peta jalan, dan menerapkan kebutuhan yang ada dalam peta jalan tersebut.
Proses di atas adalah proses pemerintahan yang sebenarnya dari Ethereum. Kita dapat melihat bahwa visi pribadi Vitalik terletak di bagian dasar model pemerintahan Ethereum, jadi begitu ada perdebatan serius dalam implementasi klien, pendapat pribadi Vitalik akan menjadi keputusan akhir.
Referensi
Pengenalan ZeroDev
null
Pengenalan ZeroDev
null
Catatan tentang roadmap Abstraksi Akun - HackMD
Catatan tentang roadmap Abstraksi Akun *Ucapan terima kasih khusus kepada Vitalik dan tim AA atas umpan balik
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
Perang tata kelola Ethereum: EIP3074, ERC4337 dan EIP7702
Penulis: shew
Ringkasan
Dalam peningkatan Pectra, muncul masalah sengketa tata kelola yang paling kompleks. Ketika EIP3074 dimasukkan ke dalam peningkatan Pectra, menyebabkan perdebatan yang besar, terutama dari tim ERC4337 yang menentang.
EIP3074 terjebak dalam kesulitan, proses pemerintahan tidak dapat dilanjutkan. Sampai Vitalik mengajukan EIP7702 yang mengakhiri keraguan tim ERC4337 terhadap EIP3074.
GCC Research menemukan bahwa ada sedikit diskusi tentang masalah tata kelola EIP3074 dan ERC7702 dalam peningkatan Pectra di dunia berbahasa Mandarin. Namun, masalah tata kelola ini juga mencerminkan masalah mendalam dalam tata kelola Ethereum, yaitu siapa yang dapat mengontrol isi spesifik dari kode di bawah premis code is law. Masalah tata kelola EIP3074 dan ERC7702 dapat memberikan kita perspektif yang baik untuk mengamati proses tata kelola nyata di dalam Ethereum.
Kesimpulan akhir dari artikel ini diambil dari komentar yang diterbitkan oleh ZeroDev, yang menunjukkan bahwa sistem pemerintahan Ethereum adalah model VVRC, di mana setiap proposal yang dimasukkan harus terlebih dahulu sesuai dengan nilai-nilai Ethereum (Value), kemudian proposal tersebut harus mencerminkan visi yang dirancang oleh Vitalik (Vision), akhirnya proposal tersebut harus tercermin dalam peta jalan (Roadmap), dan terakhir setelah diskusi oleh pengembang inti, proposal tersebut akan dimasukkan ke dalam implementasi klien (Client).
GCC Research dalam artikel sebelumnya memperkenalkan EIP2537 yang hanya mengalami masalah implementasi di tingkat Client yang menyebabkan penundaan akhirnya untuk bergabung dalam hard fork, sedangkan EIP3074 tidak dimasukkan ke dalam hard fork karena masalah Visi dan Peta Jalan, dan para pengembang inti Ethereum langsung memilih EIP7702 yang ditulis oleh Vitalik sebagai proposal abstraksi akun akhir.
Ringkasan Isi Proposal
Sebelum memperkenalkan proses tata kelola secara spesifik, kita terlebih dahulu perlu memperkenalkan secara singkat tentang EIP3074, EIP7702, dan ERC4337 yang dibahas dalam artikel ini.
EIP3074 adalah proposal lapisan eksekusi yang eksekusinya memerlukan peningkatan perangkat lunak node. Tujuan inti dari EIP3074 adalah untuk memungkinkan sponsor gas dan perdagangan massal. Yang disebut sponsor gas berarti bahwa pengguna dapat membayar biaya gas dengan token apa pun, atau pengguna dapat membayar biaya gas secara offline. Namun, perlu dicatat bahwa EIP3074 tidak mengizinkan pengguna untuk menggunakan algoritma tanda tangan apa pun selain secp256k1, dibandingkan dengan proposal abstraksi akun lain yang memungkinkan perubahan pada algoritma verifikasi tanda tangan. Dengan kata lain, EIP3074 bukanlah proposal yang memenuhi semua abstraksi akun. Ini juga merupakan poin yang EIP3074 telah dikritik.
Untuk mencapai tujuan yang diharapkan, EIP3074 memperkenalkan dua opcode, yaitu AUTH dan AUTHCALL. Opcode AUTH dapat memverifikasi tanda tangan, dan setelah verifikasi tanda tangan berhasil, opcode ini akan mengonfigurasi authorized dalam konteks EVM saat ini menjadi alamat penandatangan. Setelah mengonfigurasi authorized dalam konteks, AUTHCALL dapat menggunakan alamat authorized sebagai msg.sender untuk memulai transaksi. Dalam arti tertentu, pengguna dapat mendelegasikan akun mereka untuk digunakan oleh kontrak pintar dalam sebuah transaksi melalui tanda tangan. Kontrak pintar yang didelegasikan oleh pengguna ini biasanya disebut sebagai kontrak invoker.
Apa isi tanda tangan spesifik pengguna itu? Pengguna perlu menandatangani konten berikut:
Alamat invoker yang disebutkan di atas merujuk pada alamat kontrak invoker yang ingin didelegasikan oleh pengguna. EVM akan memverifikasi apakah konten tanda tangan pengguna sesuai dengan kontrak yang benar-benar memverifikasi tanda tangan, untuk menghindari penggunaan konten tanda tangan AUTH pengguna oleh kontrak lain.
Nonce adalah sebuah penanda untuk mencegah pengulangan transaksi. Namun, perlu diperhatikan bahwa kode operasi AUTH akan memeriksa apakah nonce dalam tanda tangan sesuai dengan nonce EOA dari tanda tangan saat ini. Secara teoritis, selama pengguna tidak menggunakan akun EOA untuk memulai transaksi yang meningkatkan nilai nonce, maka tanda tangan AUTH yang dikeluarkan oleh pengguna dapat terus digunakan oleh kontrak invoker. Ini adalah celah keamanan yang besar, yang berarti pengguna yang menggunakan EIP3074 harus mempercayai penyedia layanan relai yang mendapatkan tanda tangan. Jika penyedia layanan relai yang mendapatkan tanda tangan pengguna adalah jahat, penyedia tersebut dapat pada suatu saat mengulang tanda tangan AUTH pengguna untuk mencuri aset pengguna.
Masalah lain yang memiliki isu keamanan adalah field commit. Field commit digunakan untuk memastikan operasi tertentu, pengguna dapat mengontrol hak tanda tangan mereka secara rinci dalam commit, seperti menulis beberapa konten dalam commit untuk mencegah konten tanda tangan mereka digunakan untuk transfer ETH. Dalam dokumen EIP3074, pengusul memberikan serangkaian contoh penggunaan field commit. Namun, masalahnya adalah fungsi commit sepenuhnya bergantung pada definisi kontrak pintar, yang pada dasarnya adalah konten opsional. Kontrak pintar yang berbeda mungkin memiliki interpretasi yang sama sekali tidak konsisten terhadap konten dalam commit, bahkan mungkin beberapa kontrak tidak membaca sama sekali konten dalam commit. Jika pengguna ingin menggunakan EIP3074 dengan aman, mereka harus melakukan pemeriksaan sederhana terhadap kontrak pintar.
Akhirnya, kami memperkenalkan dampak EIP3074 terhadap mempool transaksi Ethereum saat ini. Setelah pengenalan EIP3074, mungkin akan muncul metode serangan terhadap mempool, di mana peretas dapat menggunakan banyak akun untuk melakukan transaksi, dan kemudian saat transaksi tersebut akan dip打包, menggunakan EIP3074 untuk sekaligus menguras ETH dari akun-akun tersebut, yang akan menyebabkan semua transaksi yang telah diajukan sebelumnya gagal. Metode serangan ini akan berdampak cukup besar pada node lapisan eksekusi, pada dasarnya merupakan jenis serangan DoS. Namun perlu dicatat bahwa EIP7702 yang menggantikan EIP3074 juga mengalami masalah ini, tetapi EIP7702 memperkenalkan beberapa batasan untuk mencegah masalah ini muncul, yang akan kami bahas lebih lanjut.
Selain masalah yang ada pada EIP3074 yang telah dijelaskan di atas, penulis ERC4337, Yova, dalam artikel Implications of EIP-3074 inclusion menjelaskan lebih banyak opini yang menentang. Secara singkat, opini-opini ini terutama mencakup:
EIP7702 adalah sebuah proposal yang diajukan oleh Vitalik untuk menggantikan EIP3074. Proposal ini tidak memperkenalkan opcode EVM baru, melainkan memperkenalkan jenis transaksi baru yang disebut SET_CODE_TX_TYPE. Setelah pengguna memulai transaksi jenis EIP7702, pengguna dapat menambahkan fungsi kontrak pintar ke EOA mereka tanpa menghilangkan fungsi dasar EOA. Singkatnya, pengguna dapat terus menggunakan dompet seperti MetaMask untuk memulai transaksi, atau pengguna lain dapat memanggil alamat EOA dalam bentuk kontrak pintar.
Mari kita lihat fitur EIP7702 dengan contoh sederhana perdagangan massal. Pengguna dapat menggunakan EIP7702 untuk mendelegasikan alamat EOA mereka ke kontrak pintar yang dapat melakukan panggilan massal, dan kemudian pengguna dapat langsung memanggil alamat EOA mereka dalam bentuk kontrak pintar untuk memulai transaksi massal.
Dalam hal implementasi teknis, dibandingkan dengan transaksi tradisional, EIP7702 memperkenalkan daftar jenis transaksi otor_list isasi, yaitu [[chain_id, address, nonce, y_parity, r, s], ...]. di mana alamat adalah alamat kontrak pintar yang ingin didelegasikan pengguna, dan nonce adalah nilai nonce pengguna saat ini. Sisa y_parity, r, dan s adalah hasil dari tanda tangan pengguna. Dalam proses eksekusi tertentu, pertama-tama kita akan mengulangi setiap item dalam otorisasi \ _list untuk diproses, dan metode pemrosesan adalah mengembalikan alamat EOA melalui parameter tanda tangan seperti y \ _parity, dan kemudian arahkan alamat EOA ke kontrak pintar dengan alamat alamat. Setelah itu, alamat EOA dapat menerima panggilan untuk memainkan fungsi kontrak.
Keuntungan EIP7702 sangat jelas, di mana keuntungan inti adalah EIP7702 pada dasarnya memungkinkan EOA memiliki fungsi kontrak pintar. Ini konsisten dengan aturan dasar abstraksi akun seperti ERC4337, yang berarti EIP7702 dapat memanfaatkan semua eksplorasi saat ini di bidang abstraksi akun dan menggunakan kembali infrastruktur yang ada, misalnya EIP7702 dapat langsung menggunakan infrastruktur ERC4337. Saat ini, ERC4337 telah meluncurkan EntryPoint v0.8 yang mendukung panggilan EIP7702. Dari sudut pandang pemanfaatan infrastruktur yang ada, EIP7702 memiliki tingkat desentralisasi yang sama dengan ERC4337.
Tentu saja, EIP7702 sebenarnya juga tidak sepenuhnya memperbaiki masalah yang muncul di EIP3074. Sebagian besar masalah yang ada di EIP3074 masih ada. EIP7702 mengharuskan kontrak akun memiliki implementasi yang aman, sedangkan protokol itu sendiri tidak menjamin keamanan apapun. Pada awal diusulkannya EIP7702, ada beberapa pengembang yang mengusulkan untuk menstandarisasi nonce tanda tangan untuk menghindari kemungkinan serangan replay, tetapi EIP7702 akhirnya tidak menerima saran-saran tersebut. Jadi jika pengguna ingin menggunakan EIP7702 dengan aman, maka pengguna perlu memeriksa keamanan kontrak sendiri.
Sementara itu, EIP7702 juga akan membawa serangkaian masalah bagi lapisan eksekusi. Dalam pembahasan sebelumnya, kami telah memperkenalkan salah satu kemungkinan cara untuk melakukan serangan DoS pada mempool lapisan eksekusi menggunakan EIP3074. Metode ini juga berlaku untuk EIP7702. Oleh karena itu, EIP7702 menyarankan agar semua alamat EOA yang menggunakan EIP7702 hanya dapat memiliki satu transaksi yang menunggu di dalam mempool, untuk menghindari munculnya serangan DoS dalam skala besar.
Secara keseluruhan, masalah terbesar EIP3074 adalah EIP3074 tidak menerapkan fungsi abstraksi akun yang lengkap, sementara EIP7702 telah menerapkan fungsi abstraksi akun yang lengkap. Dan definisi "abstraksi akun yang lengkap" mencakup konten yang ditentukan oleh penulis ERC4337. Setelah membaca ini, pembaca seharusnya dapat memahami mengapa EIP3074 ditentang oleh tim ERC4337 dan akhirnya digantikan oleh EIP7702. Kami akan memperkenalkan seluruh proses pemerintahan dan diskusi di bagian selanjutnya.
Proses tata kelola EIP3074 dan EIP7702
EIP3074 disebutkan sangat awal dalam pertemuan pengembang inti Ethereum. Pada 2 April 2021 dalam Pertemuan #109, para pengembang inti Ethereum melakukan diskusi sederhana mengenai EIP3074. Hasil diskusinya sangat sederhana:
Menariknya, Vitalik dalam konferensi ini berpendapat bahwa bagaimanapun juga, Ethereum memerlukan sebuah solusi teknis yang dirancang untuk menghasilkan beberapa panggilan dari satu transaksi untuk EOA. Meskipun EIP3074 memiliki potensi masalah keamanan, EIP3074 memberikan sebuah solusi teknis yang mungkin, dan para pengembang perlu maju berdasarkan EIP3074.
Jelas, karena EIP3074 memiliki masalah keamanan, pertemuan kali ini tidak memasukkan EIP3074 ke dalam pembaruan London.
Pada Meeting #115 tanggal 11 Juni 2021, pengembang EIP3074 mengajukan laporan terkait audit keamanan, dan pertemuan ini terutama membahas masalah keamanan EIP3074. Kesimpulan sederhana adalah bahwa kontrak invoker EIP3074 sangat penting dalam sistem, sehingga apakah perlu mengelola kontrak invoker adalah sebuah pertanyaan. Pengembang EIP3074 berharap untuk melakukan pembuktian formal terhadap kontrak invoker untuk meningkatkan keamanan.
Tentu, ada beberapa diskusi tentang beberapa kontrak yang menggunakan msg.sender == tx.origin untuk menentukan apakah alamat pemanggil adalah EOA. Ketika EIP3074 diperkenalkan, semua pemeriksaan ini akan menjadi tidak berlaku, tetapi kesimpulannya adalah bahwa kegagalan pemeriksaan ini tidak akan menimbulkan masalah keamanan yang serius. Singkatnya, pertemuan kali ini terutama adalah tentang pengenalan hasil audit keamanan 3074 oleh pengusul EIP3074 kepada para pengembang inti. Kesimpulan akhir dari pertemuan adalah bahwa 3074 masih perlu mempertimbangkan masalah kontrak invoker, disarankan untuk tidak memasukkannya dalam hard fork London.
Dalam Pertemuan #116 pada 25 Juni 2021, Yova, penulis inti ERC4337, mengajukan kasus untuk alternatif yang lebih sederhana untuk EIP 3074, yang menunjukkan bahwa ada banyak masalah keamanan di EIP3074 dan menyarankan agar beberapa di antaranya dimodifikasi, seperti membatasi konten bidang komit di tanda tangan, mengharuskan bidang komit menjadi {nonce,to,gas, calldata,nilai,chainid}. Dengan pola tanda tangan ini, EIP3074 hanya dapat digunakan untuk melakukan transaksi tertentu agar tetap aman.
Dalam pertemuan ini, penulis EIP3074 memberikan tanggapan terhadap materi yang diajukan oleh Yova:
Vitalik mengemukakan tiga poin berikut dalam konferensi ini:
Dalam Meeting #131 pada 4 Februari 2022, para pengembang mendiskusikan jenis EIP yang harus disertakan dalam upgrade ShangHai. EIP3074 dimasukkan dalam ruang diskusi, tetapi para pengembang hanya menyinkronkan perkembangan EIP3074 secara sederhana. Perlu dicatat, sebelum rapat dimulai, nethermind menulis artikel Ethereum wallets today and tomorrow — EIP-3074 vs. ERC-4337, yang tidak mencakup pendapat yang menentang EIP3074.
Pada Meeting #167 yang diadakan pada 3 Agustus 2023, pengembang inti menyebutkan EIP3074 saat membahas EIP5806. EIP5806 adalah sebuah proposal yang memungkinkan EOA untuk memanggil kontrak eksternal dengan menggunakan cara deleGate.io call selama proses transaksi. Skema ini mirip dengan EIP7702 dalam beberapa hal. Namun, pengembang inti juga mengungkapkan keraguan mengenai keamanan skema ini, Ansgar menunjuk bahwa EIP3074 tidak dapat dimasukkan ke dalam hard fork karena masalah keamanan yang mungkin ada, sementara EIP5806 adalah skema yang jauh lebih agresif.
Pada Meeting #182 yang diadakan pada 29 Februari 2024, para pengembang secara rinci membahas apakah EIP3074 harus dimasukkan dalam peningkatan Pectra. Vitalik mengusulkan bahwa standar abstraksi akun mana pun harus memiliki tiga fungsi berikut:
Vitalik menunjukkan bahwa EIP5806 mungkin merupakan pilihan yang lebih baik dibandingkan EIP3074. Andrew berpendapat bahwa EIP3074 lebih umum dibandingkan EIP5806, dan menyarankan untuk menggunakan EIP3074. Vitalik membantah Andrew, berpendapat bahwa di masa depan semua dompet mungkin akan menjadi dompet kontrak pintar, dan begitu hal ini terjadi, opcode pre-assembly yang diperkenalkan oleh EIP3074 akan menjadi tidak berlaku. Yoav, sebagai penulis ERC4337, memberikan pernyataan yang cukup panjang dalam pertemuan kali ini, yang terutama mencakup:
Yova lebih cenderung menggunakan EIP5806 sebagai skema abstraksi akun.
Inside Meeting #183 pada 14 Maret 2024, pengembang inti mengundang Dan Finlay dari MetaMask untuk membahas apa pendapat dompet tentang EIP3074. Dan mendukung EIP3074, mencatat bahwa MetaMask juga akan mendukung pengujian EIP3074. MetaMask percaya bahwa EIP3074 dapat secara fungsional memungkinkan EOA untuk menikmati fungsionalitas penuh abstraksi akun. Dalam hal keamanan, EIP3074 memberikan solusi bagi penyedia layanan dompet, yaitu pemisahan kunci panas dan dingin. Penyedia layanan dompet dapat menyimpan tanda tangan EIP3074 EOA untuk memulai transaksi, dan pengguna dapat menggunakan kunci pribadi panas dalam transaksi normal, tetapi kunci pribadi dingin dapat disimpan di dompet perangkat keras pengguna, dan ketika keadaan darurat ditemukan, pengguna dapat menggunakan kunci pribadi dingin di dompet dingin untuk memulai transaksi untuk mencabut tanda tangan EIP3074. Solusi pemisahan kunci pribadi panas dan dingin ini memberikan fleksibilitas kepada penyedia dompet.
Vitalik menunjukkan bahwa dalam EIP3074, perancang dompet harus merancang logika otorisasi yang ketat untuk menghindari penyalahgunaan tanda tangan EIP3074 pengguna. Menariknya, dalam diskusi tentang penambahan dukungan fitur EIP3074 di MetaMask, Vitalik menunjukkan bahwa L2 dapat digunakan sebagai solusi transisi, yaitu setiap modifikasi lapisan eksekusi baru harus dilakukan terlebih dahulu di L2, karena jumlah dana di L2 terbatas, meskipun terjadi masalah serius, kerugian yang dialami akan sangat besar.
Dror Tiros dalam diskusi menunjukkan bahwa cara terbaik untuk memastikan keamanan EIP3074 adalah dengan memberikan kontrak invoker secara langsung oleh Ethereum resmi. Namun, Dan Finlay menentang pendapat bahwa kontrak tersebut harus diberikan secara resmi, Dan percaya bahwa kontrak invoker seharusnya sepenuhnya ditentukan oleh pengguna, pasar pada akhirnya akan memilih kontrak invoker yang paling aman.
Ansgar tetap berpegang pada EIP3074 bahwa satu tanda tangan seharusnya hanya berkaitan dengan satu transaksi, penyedia dompet tidak seharusnya menggunakan kembali tanda tangan pengguna untuk memulai transaksi, tetapi Dan Finlay juga menyatakan keberatan. Dan Finlay berpendapat bahwa EIP3074 seharusnya ditandatangani oleh dompet dingin, kemudian penyedia dompet dapat menggunakan kembali tanda tangan tersebut untuk langsung memulai transaksi bagi pengguna. Jika setiap kali pengguna diminta untuk menandatangani ulang, ini dapat menyebabkan kunci privat dingin digunakan berkali-kali. Ini tidak sejalan dengan pemisahan antara kunci privat dingin dan panas.
Dalam pertemuan ini, pengembang inti membahas topik penting lainnya yaitu daftar inklusi. Daftar inklusi adalah cara untuk meningkatkan sifat anti-sensor Ethereum. Secara sederhana, daftar inklusi memungkinkan beberapa transaksi dijanjikan untuk langsung dimasukkan ke dalam blok berikutnya. Namun, pengembang inti menunjukkan bahwa EIP3074 bertentangan dengan daftar inklusi.
Pada pertemuan Meeting #185 pada 11 April 2024, sebagian besar implementasi klien di dalamnya setuju untuk memasukkan EIP3074 ke dalam hard fork Pectra, tetapi Geth menyatakan keberatan karena EIP3074 dapat menyebabkan masalah pada Verkle tree. Danno tetap menyatakan keberatan karena EIP3074 dapat menyebabkan masalah penggunaan ulang tanda tangan. Yoav juga menyatakan keberatan, memberikan skema yang menggunakan EIP3074 dan transaksi Blob untuk menyerang mempool. Singkatnya, penyerang dapat meluncurkan sejumlah besar transaksi Blob, yang semuanya mengandung sejumlah besar data, kemudian menggunakan EIP3074 untuk membuat semua transaksi Blob ini tidak berlaku.
Singkatnya, dalam pertemuan ini, semua pengembang klien sepakat bahwa EIP3074 akan dimasukkan ke dalam pembaruan akhir.
Dalam Meeting #187 pada 9 Mei 2024, para pengembang inti membahas masalah penggantian EIP3074 EIP7702 untuk pertama kalinya. EIP7702 dilakukan dalam 90 menit pertama pertemuan pengembang inti Vitalik. Selama konferensi, pengembang inti mengakui EIP7702 sebagai standar yang lebih baik daripada EIP3074. Tidak ada oposisi terhadap EIP7702 pada pertemuan ini, tetapi beberapa peneliti percaya bahwa EIP7702 juga memiliki atribut yang tidak dapat dibatalkan yang mirip dengan EIP3074, yang dapat menyebabkan masalah keamanan finansial.
Pada pertemuan Meeting #188 yang diadakan pada 23 Mei 2024, pengembang inti mendiskusikan kemungkinan EIP7702 menggantikan EIP3074. Kesimpulan akhir dari pertemuan ini adalah menggunakan EIP7702 sebagai standar abstraksi akun dalam hard fork Pectra untuk menggantikan EIP3074. Vitalik menunjukkan bahwa EIP7702 juga memiliki beberapa sifat yang tidak dapat dibatalkan yang konsisten dengan EIP3074, dan sifat-sifat ini telah banyak dibahas saat mendiskusikan EIP3074. Menariknya, terdapat banyak perwakilan ERC4337 yang berpartisipasi dalam diskusi di pertemuan ini.
Sebenarnya, diskusi tentang EIP3074 yang akan digantikan oleh EIP7702 telah dibahas secara luas sebelum 188 pertemuan pengembang inti, dan hasil diskusinya adalah bahwa 3074 akan digantikan, jadi tidak ada banyak perselisihan dalam pertemuan pengembang inti.
Peta Jalan dan Keputusan
Infrastruktur inti dari abstraksi akun Zerodev, setelah mengetahui bahwa EIP3074 akan digantikan, menerbitkan sebuah artikel menarik yang berjudul Reflections on Ethereum Governance Following the 3074 Saga. Kesimpulan dari artikel tersebut adalah EIP7702 adalah proposal yang baik, yang dapat memberikan manfaat bagi semua pengguna. Namun, proses tata kelola EIP7702 yang menggantikan EIP3074 bukanlah yang terbaik, alasannya termasuk:
Zerodev berpendapat bahwa jalur tata kelola terbaik seharusnya melibatkan partisipasi luas dari komunitas ERC4337 dan mengungkapkan pendapat mereka dalam proses diskusi pengembang inti EIP3074 yang panjang.
Pengembang EIP3074 percaya bahwa ERC4337 seharusnya bertanggung jawab atas kegagalan tata kelola. Karena EIP3074 telah aktif terlibat dalam tata kelola selama beberapa tahun terakhir dan telah berkomunikasi beberapa kali dengan pengembang inti ERC4337 yova.
Komunitas ERC4337 percaya bahwa EIP3074 harus bertanggung jawab atas kegagalan dalam pengelolaan. Anggota komunitas ERC4337 berpendapat bahwa Yova, sebagai pengembang inti ERC4337, telah menyampaikan keberatan terhadap EIP3074 dalam beberapa pertemuan pengembang inti, tetapi pengembang inti tampaknya tidak mendengarkan pendapat tersebut. Sebagian besar anggota komunitas ERC4337 tidak memperhatikan dinamika pengelolaan EIP3074, dan sebagian besar anggota menganggap EIP3074 sebagai standar yang sudah mati. Komunitas ERC4337 juga berpendapat bahwa pengembang inti tidak secara aktif berkomunikasi dengan komunitas ERC4337.
EIP3074 dan ERC4337 sama-sama mengklaim telah melakukan pekerjaan tata kelola yang benar, sementara pihak lainnya harus menanggung tanggung jawab utama atas kegagalan tata kelola. Jelas bahwa ada suatu alasan yang lebih mendalam yang berperan dalam proses tata kelola ini.
Secara sederhana, alasan yang lebih mendalam ini sebenarnya adalah peta jalan Ethereum. Peta jalan Ethereum memiliki kekuatan yang melebihi pertemuan pengembang inti. Peta jalan abstraksi akun berfokus pada ERC4337. EIP7702 sepenuhnya kompatibel dengan standar ERC4337, tetapi EIP3074 tidak sepenuhnya kompatibel dengan standar ERC4337. Jadi, dari sudut pandang peta jalan Ethereum, penggantian EIP3074 pasti akan terjadi.
Tentu saja, peta jalan Ethereum adalah representasi dari visi masa depan Ethereum yang dipaparkan oleh Vitalik secara pribadi. Jika terjadi perdebatan serius dalam proses tata kelola Ethereum, maka sebagai pendefinisi peta jalan, Vitalik memiliki hak keputusan terakhir. Dan keputusan Vitalik lah yang menyebabkan EIP3074 digantikan.
Model pemerintahan Ethereum adalah model values ⇒ vision ⇒ roadmaps ⇒ clients, atau disingkat model VVRC. Proses pemerintahan adalah sebagai berikut:
Proses di atas adalah proses pemerintahan yang sebenarnya dari Ethereum. Kita dapat melihat bahwa visi pribadi Vitalik terletak di bagian dasar model pemerintahan Ethereum, jadi begitu ada perdebatan serius dalam implementasi klien, pendapat pribadi Vitalik akan menjadi keputusan akhir.