EIP-8141: Mengapa Abstraksi Akaun Asli Bukan Ciri Utama dalam Peningkatan Hegota Ethereum

Ditulis oleh: imToken

Pekan lalu, EIP-8141 secara rasmi dibincangkan dalam pertemuan pengembang inti Ethereum mengenai pemasukannya ke dalam peningkatan Hegota, dengan hasil yang mengejutkan: usulan yang didorong langsung oleh Vitalik tidak disenaraikan sebagai "ciri utama" Hegota, tetapi diberi status "dipertimbangkan untuk dimasukkan" (CFI).

Pada minggu ini, pasukan Google Quantum AI mengeluarkan kertas kerja terkini, menyatakan bahawa anggaran qubit fizikal yang diperlukan untuk memecahkan ECDLP-256, berdasarkan andaian peranti yang diberikan, telah menurun sebanyak 20 kali ganda berbanding sebelum ini. Walaupun ini tidak bermakna serangan kuantum berada di ambang pintu, ia secara nyata mengingatkan kita bahawa jika sistem akaun tidak mampu menukar logik pengesahan secara fleksibel pada masa depan, banyak perbincangan tentang pengalaman dompet hari ini akhirnya mungkin berubah menjadi isu keselamatan.

Walaupun dari sudut realiti kemajuan protokol, EIP-8141 masih terlalu berat, terutamanya dalam pelaksanaan klien, keselamatan kolam transaksi, dan kerumitan pengesahan, belum terbentuk konsensus yang cukup kukuh.

Namun, pada titik masa kini, perkara yang perlu dibincangkan dan ditinjau dengan serius mengenai EIP-8141 kelihatannya semakin bertambah.

EIP-8141 yang didorong oleh Vitalik Buterin dan penyumbang utama seperti timbeiko, secara rasmi dikenali sebagai Frame Transactions.

Secara ringkas, tujuannya bukan sekadar menambahkan fungsi dompet tertentu, tetapi mencuba untuk membebaskan sebarang akaun dari ketergantungan kepada laluan tanda tangan ECDSA tunggal pada tingkat protokol, membolehkannya memiliki logik pengesahan dan pelaksanaan yang lebih fleksibel.

Ini juga bermakna bahawa tanda tangan ganda, penyertaan gas, pergantian kunci, pemulihan sosial, dan bahkan integrasi masa depan dengan skema tanda tangan anti-kuantum tidak lagi menjadi kemampuan luaran yang dipasang di luar dompet, tetapi berpeluang menjadi “ahli asli” dalam sistem akaun Ethereum.

Jika dilihat secara permukaan, EIP-8141 membincangkan satu set kemampuan yang kelihatan sangat spesifik: membayar Gas dengan mata wang stabil, menggabungkan operasi berperingkat menjadi satu transaksi, menyokong cara tanda tangan yang lebih fleksibel, dan bahkan menyediakan ruang untuk tanda tangan anti-kuantum di masa depan. Boleh dikatakan, selama bertahun-tahun, dari ERC-4337 hingga EIP-7702, banyak peningkatan yang berkaitan dengan pengalaman dompet pada dasarnya bertujuan menjadikan akaun bukan sekadar kunci peribadi, tetapi satu pintu masuk yang boleh disesuaikan peraturannya.

Masalahnya ialah, peningkatan ini memang menjadikan dompet semakin menyerupai akaun pintar, tetapi tidak pernah benar-benar menyentuh model akaun lalai paling asas Ethereum.

Seperti yang diketahui umum, di bawah sistem semasa, akaun Ethereum dibahagikan kepada dua kategori utama. Satu ialah akaun yang dimiliki luaran, iaitu EOA yang paling dikenali, yang dikawal oleh kunci peribadi dan boleh menginisiasi transaksi secara aktif, tetapi tidak mempunyai keupayaan pengaturcaraan; kategori lain ialah akaun kontrak, iaitu kontrak pintar itu sendiri, yang boleh menjalankan logik yang kompleks tetapi tidak boleh menginisiasi transaksi secara aktif.

Ini menyebabkan kemampuan untuk memulakan transaksi terus dikaitkan dengan tanda tangan kunci peribadi tunggal. Selama prasyarat ini tidak berubah, banyak kemampuan yang pengguna hari ini anggap sebagai hak biasa—seperti menukar peraturan tanda tangan dengan fleksibel, membenarkan orang lain membayar Gas, memulihkan kuasa atas akaun selepas kunci peribadi hilang, atau berpindah lancar ke sistem kriptografi baru di masa depan—sukar untuk menjadi kemampuan lalai akaun.

Jika anda pernah menggunakan imToken atau dompet Web3 lain, kemungkinan besar anda juga pernah mengalami masalah-masalah ini, seperti memiliki banyak USDC di dompet tetapi tidak dapat menghantar transaksi kerana tidak ada ETH (kerana Gas hanya boleh dibayar dengan ETH); kehilangan kata sandi pemulihan bererti kehilangan dana selamanya dan tidak boleh dipulihkan; operasi "kuasa + pertukaran" memerlukan tanda tangan dan pengesahan dua kali, dan sebagainya.

Masalah-masalah ini bukan disebabkan oleh produk dompet yang "tidak cukup baik", tetapi merupakan hasil daripada reka bentuk model akaun Ethereum itu sendiri.

Dari sudut pandang ini, perkembangan dua tahun terakhir sebenarnya sudah sangat jelas: ERC-4337 telah menjalankan abstraksi akaun di lapisan aplikasi tanpa mengubah protokol; EIP-7702 pula membuktikan bahawa EOA tidak sepenuhnya tidak boleh dikembangkan, setidak-tidaknya boleh mendapatkan sementara sebahagian kemampuan yang hampir sama dengan akaun pintar.

Dengan kata lain, Ethereum bukan tidak ingin melakukan abstraksi akaun, tetapi terus mendekati perkara ini dengan cara yang lebih perlahan dan konservatif. Kehadiran EIP-8141 bermakna jalan ini telah sampai pada titik baru—ia tidak lagi puas dengan menambahkan kemampuan akaun pintar di luar sistem yang sedia ada, tetapi cuba memasukkan abstraksi akaun secara langsung ke dalam model transaksi, membolehkan akaun memiliki logik pengesahan dan pelaksanaan yang boleh diprogramkan sejak dari peringkat protokol.

Inilah sebab mengapa EIP-8141 kembali mendapat perhatian hari ini. Di satu sisi, pengalaman dompet tingkat atas semakin mendekati abstraksi akaun asli, dan lapisan protokol pasti perlu mengejar ketertinggalan; di sisi lain, tekanan jangka panjang daripada komputasi kuantum sedang mengubah soalan teknikal yang jauh tentang “kebolehan akaun menukar cara tanda tangan” menjadi isu praktikal yang perlu dipertimbangkan dengan serius.

Pada akhirnya, EIP-8141 memperkenalkan jenis transaksi baharu—Frame Transaction, dengan nombor jenis transaksi 0x06.

Jika logik asas transaksi Ethereum tradisional adalah satu transaksi sepadan dengan satu panggilan, maka yang ingin dicapai oleh EIP-8141 ialah memecahkan satu transaksi menjadi sekumpulan "bingkai" yang boleh dijalankan mengikut urutan peraturan, dengan demikian memisahkan tiga perkara yang sebelumnya terikat bersama—pengesahan, pembayaran, dan pelaksanaan.

Setiap «frame» mempunyai tiga mod eksekusi:

• VERIFY (mengesahkan kerangka): Bertanggungjawab untuk mengesahkan sama ada transaksi adalah sah, ia akan menjalankan logik pengesahan yang disesuaikan akaun, dan jika berjaya, ia akan memanggil opcode APPROVE yang diperkenalkan baharu untuk mengizinkan pelaksanaan dan menentukan had Gas.
• PENGIRIM (menghantar kerangka): Melaksanakan tindakan sebenar, seperti pemindahan dana, memanggil kontrak, dll. Alamat pemanggil ialah pengirim transaksi itu sendiri.
• DEFAULT (bingkai masuk): Menggunakan alamat masuk sistem sebagai pemanggil, digunakan dalam skenario seperti penghuraian kontrak, pengesahan Paymaster, dll;

Makna mekanisme ini bukanlah membuat perdagangan menjadi lebih kompleks, tetapi pertama kalinya tiga perkara—“pengesahan, pembayaran, pelaksanaan”—dipisahkan daripada tindakan akaun dan diserahkan kepada penjadualan asli protokol.

Pada masa lalu, siapa yang mengesahkan transaksi, siapa yang membayar Gas, dan siapa yang melaksanakan operasi sebenar, semuanya biasanya terikat dalam satu tindakan akaun yang sama. Dalam reka bentuk EIP-8141, ketiga-tiga perkara ini boleh dipisahkan menjadi bingkai yang berbeza, dan dilaksanakan oleh protokol mengikut urutan yang jelas. Oleh sebab itu, akaun tidak lagi hanya bergantung pada kunci peribadi tunggal untuk «menandatangani keseluruhan» tetapi mula mempunyai bentuk yang lebih hampir dengan subjek pelaksanaan yang boleh diprogramkan.

Sebagai contoh spesifik, andaikan anda ingin menggunakan USDC untuk membayar Gas bagi menyelesaikan satu Swap, dalam kerangka EIP-8141, perkara ini secara teori boleh diatur sebagai satu aliran bingkai penuh: terlebih dahulu akaun mengesahkan tanda tangan dan kebenaran pelaksanaan, kemudian pihak pembayar atau Paymaster mengesahkan syarat kesediaan mereka untuk menanggung kos, seterusnya menyelesaikan pembayaran kos untuk aset yang berkaitan, dan akhirnya melaksanakan operasi Swap sebenar.

Dengan cara ini, pembayaran Gas dan transaksi utama boleh dimasukkan ke dalam satu proses atomik yang sama, iaitu semua berjaya atau semua dibatalkan.

Perubahan yang paling intuitif bagi pengguna ialah banyak operasi yang sebelumnya mesti dibahagikan kepada dua atau tiga langkah, dengan risiko kegagalan di antara langkah-langkah tersebut, akan menjadi lebih seperti satu tindakan penuh di masa depan. Oleh itu, atomisiti ini juga merupakan salah satu perkara utama yang ingin diselesaikan oleh EIP-8141 bagi mengatasi masalah pengalaman pengguna yang terpecah.

Apakah ini bermakna apa untuk pengguna dompet? Dari hasilnya, perubahan paling langsung sekurang-kurangnya ada empat lapisan:

• Pembayaran gas diabstraksikan: memiliki stablecoin di dompet tidak lagi bererti anda perlu menyediakan ETH tambahan untuk melakukan tindakan; pada masa depan, pembayaran gas akan menjadi lebih asli apabila dibayar oleh dapp, Paymaster, atau pihak penyokong lainnya;
• Operasi berbilang langkah telah digabungkan: proses yang biasanya memerlukan beberapa tanda tangan, seperti "授权 + Swap" dan "授权 + 质押", kini berpeluang dipadukan menjadi satu operasi yang lebih lengkap;
• Peraturan keselamatan akaun telah diaktifkan: multi-signature, pemulihan sosial, had harian, time lock, dan pergantian kunci—ini bukan lagi hanya fungsi lanjutan yang disediakan secara tambahan oleh produk dompet tertentu, tetapi mulai berpeluang dibina atas logik akaun yang lebih asli;
• Skema tanda tangan tidak lagi terperangkap dalam laluan tunggal ECDSA: Ini memberikan kemungkinan pertama pada peringkat protokol untuk akaun berpindah ke sistem kriptografi yang berbeza, termasuk skema tanda tangan pasca-kuantum;

Satu perkara yang sering diabaikan tetapi sangat penting bagi pengguna dompet ialah: walaupun EIP-8141 akhirnya dilaksanakan, sistem akaun yang sedia ada tidak akan ditolak keseluruhannya.

Walaupun anda sedang menggunakan dompet Web3 sedia ada seperti imToken, anda tidak perlu berpindah, kerana ia kompatibel ke belakang, alamat EOA yang sedia ada boleh terus digunakan, hanya perlu memilih "naik taraf" logik pengesahan akaun pada masa yang sesuai.

Namun, sebaliknya, justeru kerana perubahan itu cukup mendalam, ia tidak langsung menjadi ciri utama Hegotá dalam perbincangan terkini. Namun, mengikut prosedur EIP champion pada tahun 2026, maksud CFI (Considered for Inclusion) bukanlah ditolak, tetapi memasuki peringkat pertimbangan serius, tetapi belum sampai ke peringkat keputusan akhir untuk dilancarkan.

Dengan kata lain, pengembang inti bukan tidak mengiktiraf arah EIP-8141, tetapi mengiktiraf nilainya sambil mempertimbangkan bahawa ia masih terlalu "berat" pada masa ini.

Sebenarnya, abstraksi akaun asli tidak seperti ERC-4337 yang boleh didorong secara berperingkat oleh sedikit dompet, infrastruktur, dan aplikasi; apabila ia memasuki lapisan protokol, ia bermakna semua klien lapisan pelaksanaan perlu melaksanakan, menguji, dan bekerjasama secara serius, yang secara semula jadi meningkatkan rintangan untuk kemajuan dan membuat pengembang inti lebih cenderung memilih pendekatan berhati-hati semasa perancangan cabang.

Apa yang akan berlaku seterusnya? Ia boleh dibahagikan kepada dua garis:

• EIP-8141, kerana berada dalam status CFI, bermakna ia masih sedang dinilai secara berterusan; penulis usulan akan terus melengkapi butiran penting mengenai keselamatan kolam transaksi, peraturan pengesahan, dan pelaksanaan klien, dan mesyuarat ACD akan meninjau semula sama ada ia memenuhi syarat untuk diteruskan lebih lanjut;
• Jika ketidakpastian ini dapat ditekan secara berterusan, ia berpeluang memasuki peringkat penglibatan yang lebih bermakna dalam peningkatan seterusnya; jika tidak, ia juga sepenuhnya mungkin ditangguhkan ke kitaran peningkatan yang lebih lewat;

Secara jujur, EIP-8141 bukanlah satu-satunya cadangan abstraksi akaun asli, dan ia sendiri bukanlah skema tanda tangan pasca-kuantum yang sudah siap yang boleh menyelesaikan masalah pengiraan kuantum secara langsung, tetapi kepentingannya terletak pada fakta bahawa ia pertama kali menyediakan jalan keluar pada peringkat protokol untuk akaun keluar daripada laluan tunggal ECDSA.

Dari sudut pandang ini, nilai sebenar EIP-8141 bukan terletak pada sama ada ia satu-satunya jawapan yang betul, tetapi pada fakta bahawa ia pertama kali meletakkan soalan "akhir yang sebenar bagi pengabstrakan akaun asli seharusnya seperti apa" secara lengkap di atas meja perbincangan protokol Ethereum.

Ia bukan satu-satunya penyelesaian, tetapi ia salah satu penyelesaian yang paling ambisius dan paling dekat dengan had imajinasi "AA asli penuh" pada masa ini.

Sama ada EIP-8141 akhirnya dapat menyusul Hegotá atau tidak, perbincangan ini sekurang-kurangnya telah menunjukkan satu perkara:

Ethereum tidak duduk menunggu masalah memburuk, tetapi secara perlahan-lahan membina jalan untuk sistem akaun generasi seterusnya.