Abstraksi akun asli + perlindungan terhadap ancaman kuantum: Mengapa EIP-8141 belum menjadi unggulan utama Ethereum Hegotá?

Minggu lalu, dalam pertemuan resmi pengembang inti Ethereum, dibahas secara formal apakah EIP-8141 akan dimasukkan ke dalam upgrade Hegota. Hasilnya mengejutkan: proposal ini, yang dipromosikan langsung oleh Vitalik, tidak dicantumkan sebagai “fitur utama” Hegota, melainkan memperoleh status “dipertimbangkan untuk dimasukkan” (CFI).

Dan minggu ini, tim Google Quantum AI merilis white paper terbaru yang menyatakan bahwa, dengan asumsi perangkat keras yang mereka tetapkan, perkiraan jumlah qubit kuantum fisik yang diperlukan untuk memecahkan ECDLP-256 telah turun secara drastis dibanding sebelumnya, yaitu 20 kali. Meskipun ini tidak berarti serangan kuantum sudah dekat, hal ini benar-benar mengingatkan kita bahwa jika di masa depan sistem akun tidak dapat secara fleksibel mengganti logika verifikasi, maka banyak pembahasan tentang pengalaman dompet yang kita lakukan hari ini pada akhirnya bisa berubah menjadi masalah keamanan.

Meski dari sudut pandang realitas pendorongan protokol, EIP-8141 saat ini masih terlalu berat—terutama karena belum terbentuk konsensus yang cukup kuat pada implementasi klien, keamanan transaction pool, dan kompleksitas verifikasi.

Namun, pada titik waktu saat ini, tampaknya memang semakin banyak hal dalam EIP-8141 yang layak didiskusikan dan ditinjau secara serius.

I. EIP-8141 sebenarnya ingin menyelesaikan apa?

EIP-8141 didorong oleh Vitalik Buterin dan para kontributor inti seperti timbeiko, dengan nama resmi Frame Transactions (frame transactions).

Jika dirangkum dalam satu kalimat yang lebih mudah dipahami, yang ingin ia lakukan sebenarnya bukan sekadar menambah satu fungsi dompet tertentu, melainkan mencoba, dari lapisan protokol, agar setiap akun tidak lagi terikat oleh satu jalur tanda tangan ECDSA yang tunggal, melainkan dapat memiliki logika verifikasi dan eksekusi yang lebih fleksibel.

Ini juga berarti bahwa multisig, sponsor Gas, rotasi kunci, pemulihan sosial, bahkan di masa depan rencana integrasi skema tanda tangan anti-kuantum, tidak lagi sekadar kemampuan tambahan yang menempel di luar dompet, melainkan berpeluang menjadi “anggota asli” dalam sistem akun Ethereum.

Jika hanya dilihat dari permukaannya, pembahasan EIP-8141 adalah seperangkat kemampuan yang terlihat sangat spesifik: membayar Gas dengan stablecoin, menggabungkan operasi multi-langkah menjadi satu transaksi, mendukung cara tanda tangan yang lebih fleksibel, bahkan menyediakan ruang untuk skema tanda tangan anti-kuantum di masa depan. Bisa dibilang, selama bertahun-tahun, banyak perbaikan terkait pengalaman dompet—mulai dari ERC-4337 sampai EIP-7702—pada intinya semuanya bertujuan agar akun tidak lagi sekadar sebuah kunci privat, melainkan sebuah pintu masuk yang bisa dikustomisasi dengan aturan.

Masalahnya adalah, perbaikan-perbaikan ini memang membuat dompet semakin menyerupai akun pintar, tetapi tetap belum benar-benar menyentuh model akun default paling dasar di Ethereum.

Seperti yang sudah diketahui banyak orang, pada sistem yang ada saat ini, akun Ethereum secara garis besar terbagi menjadi dua jenis. Satu jenis adalah akun milik eksternal (external account), yaitu EOA—yang paling familiar bagi semua orang. EOA dikendalikan oleh private key, dapat memulai transaksi secara aktif, tetapi tidak memiliki kemampuan pemrograman; jenis lainnya adalah akun kontrak, yaitu kontrak itu sendiri, yang dapat mengeksekusi logika yang kompleks, tetapi tidak dapat memulai transaksi secara mandiri.

Akibatnya, kemampuan untuk memulai transaksi—dan tanda tangan transaksi tersebut dengan private key tunggal—terikat dalam satu prasyarat yang sama dalam jangka panjang. Selama prasyarat itu tidak berubah, banyak kemampuan yang hari ini terasa “seharusnya” dimiliki oleh pengguna, seperti mengganti aturan tanda tangan secara fleksibel, meminta orang lain membayar Gas, memulihkan kontrol atas akun setelah private key hilang, atau di masa depan melakukan migrasi yang mulus ke sistem sandi baru, akan sulit benar-benar menjadi kemampuan default akun.

Jika Anda pernah menggunakan imToken atau dompet Web3 lainnya, kemungkinan besar Anda juga pernah menghadapi masalah-masalah ini: misalnya, dompet Anda berisi banyak USDC tetapi tidak ada ETH sehingga Anda tidak bisa mengirim transaksi (karena Gas hanya bisa dibayar dengan ETH); jika seed phrase hilang, uang pun hilang sepenuhnya dan tidak bisa dipulihkan; sebuah tindakan “otorisasi + pertukaran” perlu menandatangani dua kali, mengonfirmasi dua kali, dan seterusnya.

Masalah-masalah ini bukan karena produk dompet “kurang baik”, melainkan karena desain dari model akun Ethereum itu sendiri.

Dari sudut pandang ini, evolusi dua tahun terakhir sebenarnya sudah sangat jelas: ERC-4337, tanpa mengubah protokol, membuat abstraksi akun dijalankan lebih dulu di lapisan aplikasi; EIP-7702 juga membuktikan lebih lanjut bahwa EOA tidak sepenuhnya tidak bisa diperluas—setidaknya EOA bisa memperoleh sebagian kemampuan yang mendekati akun pintar untuk sementara.

Artinya, Ethereum sebenarnya bukan tidak ingin membuat abstraksi akun, melainkan terus melakukannya dengan cara yang lebih lembut dan konservatif, secara bertahap mendekati hal tersebut. Dan kemunculan EIP-8141 menunjukkan bahwa jalur itu telah mencapai titik baru. Ia tidak lagi puas dengan menumpuk satu lapisan kemampuan akun pintar di luar sistem yang ada, melainkan berusaha menyematkan abstraksi akun langsung ke dalam model transaksi itu sendiri, sehingga sejak lapisan protokol, akun sudah memiliki logika verifikasi dan eksekusi yang bisa diprogram.

Inilah juga mengapa EIP-8141 kembali mendapatkan perhatian dan pembahasan hangat saat ini. Di satu sisi, pengalaman dompet di lapisan atas sudah semakin mendekati abstraksi akun native; lambat laun lapisan protokol harus menyusul. Di sisi lain, tekanan jangka panjang yang dibawa komputasi kuantum juga sedang mengubah “apakah akun bisa mengganti cara tanda tangan secara fleksibel” dari topik teknis yang jauh menjadi masalah nyata yang harus dipertimbangkan lebih awal secara serius.

II. Bagaimana EIP-8141 bekerja?

Pada intinya, EIP-8141 memperkenalkan jenis transaksi yang benar-benar baru—Frame Transaction (frame transaction), dengan nomor jenis transaksi 0x06.

Jika logika dasar transaksi Ethereum tradisional adalah satu transaksi berpadanan dengan satu pemanggilan, maka yang ingin dilakukan EIP-8141 adalah memecah satu transaksi menjadi sekumpulan “frame” yang dapat dieksekusi menurut urutan tertentu berdasarkan aturan, sehingga tiga hal—verifikasi, pembayaran, dan eksekusi—yang sebelumnya terikat bersama dapat ditangani secara terpisah.

Setiap “frame” memiliki tiga mode eksekusi:

• VERIFY (frame verifikasi): bertugas memverifikasi apakah transaksi itu sah. Ia akan menjalankan logika verifikasi yang dikustomisasi oleh akun; jika lolos, ia akan memanggil kode operasi APPROVE yang baru diperkenalkan untuk mengotorisasi eksekusi dan menentukan batas Gas.
• SENDER (frame pengirim): menjalankan operasi aktual, seperti transfer, pemanggilan kontrak, dan sebagainya. Alamat pemanggil adalah pengirim transaksi itu sendiri.
• DEFAULT (frame pintu masuk): menggunakan alamat pintu masuk sistem sebagai pemanggil, untuk skenario seperti deployment kontrak, validasi Paymaster, dan lain-lain;

Makna mekanisme ini bukanlah membuat transaksi menjadi lebih rumit, melainkan untuk pertama kalinya memisahkan “verifikasi, pembayaran, eksekusi” dari tindakan akun, lalu menyerahkannya agar dijadwalkan secara native oleh protokol.

Bagaimanapun, sebelumnya siapa yang memverifikasi transaksi, siapa yang membayar Gas, dan siapa yang menjalankan operasi sesungguhnya—pada dasarnya semuanya terikat dalam satu tindakan akun yang sama. Namun dalam desain EIP-8141, ketiga hal ini dapat dipecah menjadi frame yang berbeda; protokol akan mengeksekusinya secara berurutan sesuai urutan yang jelas. Dan karena itulah, akun tidak lagi harus bergantung pada private key tunggal untuk menandatangani semuanya secara “utuh”, melainkan mulai memiliki bentuk yang lebih mirip dengan entitas eksekusi yang bisa diprogram.

Berikut contoh yang konkret: anggap saja Anda ingin menggunakan USDC untuk membayar Gas guna menyelesaikan satu Swap. Dalam kerangka EIP-8141, secara teori hal ini bisa diorganisasi menjadi satu rangkaian proses frame yang lengkap: mula-mula akun memverifikasi tanda tangan dan hak eksekusi, lalu pihak pembayaran atau Paymaster memverifikasi kondisi bahwa mereka bersedia menanggung biaya, setelah itu menyelesaikan pembayaran biaya untuk aset terkait, dan akhirnya menjalankan operasi swap yang sesungguhnya.

Dengan demikian, pembayaran Gas dan transaksi utama dapat dimasukkan ke dalam satu alur atomik: atau semuanya berhasil, atau semuanya dibatalkan (di-rollback).

Bagi pengguna, perubahan yang paling mudah dipahami secara langsung adalah bahwa banyak operasi yang sebelumnya harus dipecah menjadi dua-tiga langkah—dan di antaranya ada risiko kegagalan—di masa depan dapat menjadi seperti satu tindakan yang lengkap. Oleh karena itu, sifat atomik inilah yang ingin diatasi EIP-8141 sebagai salah satu kunci untuk masalah fragmentasi pengalaman pengguna.

Lalu, apa artinya ini bagi pengguna dompet? Dari hasilnya, perubahan yang paling intuitif setidaknya memiliki empat lapisan:

• Pembayaran Gas diabstraksikan: Jika di dalam dompet ada stablecoin, berarti Anda tidak lagi harus menyiapkan sedikit ETH tambahan agar bisa beroperasi. Ke depannya, pembayaran Gas oleh DApp, Paymaster, atau sponsor lain akan menjadi lebih natural;
• Operasi multi-langkah digabung: proses seperti “otorisasi + Swap” atau “otorisasi + staking” yang saat ini sering membutuhkan beberapa tanda tangan, berpeluang untuk dikemas menjadi satu operasi yang lebih lengkap;
• Aturan keamanan akun dibuka: multisig, pemulihan sosial, batas harian, time lock, rotasi kunci—semua ini tidak lagi hanya kemampuan lanjutan yang disediakan oleh produk dompet tertentu, melainkan berpeluang untuk dibangun di atas logika akun yang lebih native;
• Skema tanda tangan tidak lagi harus dikunci ke jalur tunggal ECDSA: ini memberi kemungkinan, untuk pertama kalinya, agar akun dapat bermigrasi ke sistem sandi yang berbeda, termasuk skema tanda tangan pasca-kuantum, dan itu memiliki makna pada tingkat protokol;

III. Kenapa tidak menjadi andalan Hegotá?

Satu hal yang mudah diabaikan, tetapi sangat penting bagi pengguna dompet, adalah: meskipun EIP-8141 pada akhirnya benar-benar diimplementasikan, sistem akun yang ada tidak akan secara keseluruhan dibongkar.

Bahkan jika saat ini Anda menggunakan dompet Web3 yang sudah ada seperti imToken, Anda tidak perlu pindah karena ia kompatibel ke belakang; alamat EOA yang ada dapat terus digunakan, hanya perlu memilih logika verifikasi “upgrade” pada waktu yang tepat.

Namun, justru karena perubahan yang dilakukan cukup mendalam, ia tidak langsung menjadi fitur andalan Hegotá dalam putaran pembahasan terbaru. Meski begitu, sesuai alur proses EIP champion tahun 2026, arti CFI (Considered for Inclusion) bukanlah ditolak, melainkan masuk ke tahap pertimbangan yang serius—tetapi belum sampai pada tahap keputusan final untuk diluncurkan.

Dengan kata lain, pengembang inti bukan berarti tidak mengakui arah EIP-8141; mereka mengakui nilainya, tetapi juga menilai bahwa saat ini EIP-8141 masih terlalu “berat”.

Bagaimanapun, abstraksi akun native tidak seperti ERC-4337 yang dapat didorong dulu oleh segelintir dompet, infrastruktur, dan aplikasi secara bertahap. Begitu ia masuk ke lapisan protokol, artinya semua klien pada lapisan eksekusi harus benar-benar memahami, menguji, dan berkolaborasi. Ini secara alami akan meningkatkan ambang batas untuk mendorongnya, dan membuat pengembang inti cenderung lebih berhati-hati saat merencanakan fork.

Lalu apa yang akan terjadi ke depannya? Bisa dilihat dari dua jalur:

• Karena EIP-8141 berada pada status CFI, itu berarti ia tetap dievaluasi secara berkelanjutan. Penulis proposal akan terus melengkapi detail-detail kunci seputar keamanan transaction pool, aturan verifikasi, dan implementasi klien; rapat ACD berikutnya juga akan meninjau kembali apakah ia memenuhi syarat untuk didorong lebih lanjut;
• Jika ketidakpastian ini terus bisa dipersempit, ia berpeluang untuk masuk ke tahap “dimasukkan” yang lebih substansial pada upgrade berikutnya; jika tidak, ia juga sepenuhnya bisa ditunda ke siklus upgrade yang lebih lambat;

Secara jujur, EIP-8141 tidaklah satu-satunya proposal abstraksi akun native; bahkan, ia sendiri bukanlah skema tanda tangan pasca-kuantum yang siap pakai dan tidak bisa langsung menyelesaikan masalah komputasi kuantum. Namun kepentingannya terletak pada kenyataan bahwa ini untuk pertama kalinya menyediakan jalan keluar pada tingkat protokol agar akun terbebas dari jalur tunggal ECDSA.

Dari sudut pandang ini, nilai sesungguhnya EIP-8141 bukan pada apakah ia jawaban yang unik dan benar, melainkan pada fakta bahwa untuk pertama kalinya ia menempatkan dengan sangat lengkap pertanyaan tentang bagaimana “wujud akhir abstraksi akun native” seharusnya pada meja diskusi protokol Ethereum.

Ia bukan satu-satunya solusi, tetapi memang salah satu solusi yang paling ambisius saat ini, sekaligus paling mendekati batas imajinasi tertinggi dari “native AA” yang lengkap.

Terlepas dari apakah EIP-8141 pada akhirnya bisa menyusul Hegotá atau tidak, diskusi ini setidaknya sudah menunjukkan satu hal:

Ethereum tidak sedang menunggu masalah membusuk di tempat; Ethereum sedang menyiapkan jalan lebih awal untuk sistem akun generasi berikutnya dengan langkah demi langkah yang tekun.