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

Ditulis oleh: imToken

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

Dan pada minggu ini, tim Google Quantum AI merilis white paper terbaru, yang menyatakan bahwa, berdasarkan asumsi perangkat keras yang mereka tetapkan, estimasi jumlah qubit kuantum fisik yang diperlukan untuk memecahkan ECDLP-256 telah turun secara drastis, hingga 20 kali lebih rendah dibanding sebelumnya. Walaupun ini tidak berarti serangan kuantum sudah tepat di depan mata, namun secara nyata mengingatkan kita: jika di masa depan sistem akun tidak dapat beralih secara fleksibel logika verifikasi, maka banyak perbincangan hari ini tentang pengalaman dompet pada akhirnya bisa berubah menjadi masalah keamanan.

Meski dari sudut pandang realitas dorongan terhadap perkembangan protokol, EIP-8141 saat ini masih terlalu berat, terutama dari sisi implementasi klien, keamanan transaction pool, dan kompleksitas verifikasi—belum terbentuk konsensus yang cukup kokoh.

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

I. EIP-8141 sebenarnya ingin menyelesaikan apa?

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

Jika dirangkum dengan satu kalimat yang lebih mudah dipahami, yang ingin dilakukan sebenarnya bukan sekadar menambah satu fitur dompet tertentu, melainkan mencoba membuat agar dari lapisan protokol mana pun, setiap akun tidak lagi terbelenggu pada jalur tanda tangan tunggal ECDSA, melainkan dapat memiliki logika verifikasi dan eksekusi yang lebih fleksibel.

Ini juga berarti, multi-tanda tangan, sponsor Gas, rotasi kunci, pemulihan sosial, bahkan akses di masa depan ke skema tanda tangan tahan kuantum, tidak lagi hanya sekadar kemampuan tambahan di luar dompet, melainkan berpeluang menjadi “anggota asli” dalam sistem akun Ethereum.

Jika hanya melihat permukaannya, pembahasan EIP-8141 adalah sekumpulan kemampuan yang terlihat sangat spesifik: membayar Gas dengan stablecoin, menggabungkan beberapa langkah menjadi satu transaksi, mendukung cara penandatanganan yang lebih fleksibel, bahkan menyiapkan ruang untuk tanda tangan tahan kuantum di masa depan. Bisa dibilang, selama bertahun-tahun dari ERC-4337 hingga EIP-7702, banyak perbaikan seputar pengalaman dompet pada dasarnya terus membuat akun tidak lagi hanya “sebuah kunci privat”, melainkan sebuah pintu masuk tempat aturan dapat disesuaikan.

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

Seperti yang diketahui, dalam sistem yang ada saat ini, akun Ethereum secara garis besar terbagi menjadi dua jenis. Satu jenis adalah akun yang dimiliki pihak eksternal, yaitu EOA yang paling familiar bagi banyak orang; akun ini dikendalikan oleh kunci privat, dapat memulai transaksi secara aktif, tetapi tidak memiliki kemampuan pemrograman. Jenis lainnya adalah akun kontrak, yaitu kontrak pintar itu sendiri; ia dapat menjalankan logika kompleks, tetapi tidak bisa memulai transaksi secara mandiri.

Hal ini menyebabkan kemampuan untuk memulai transaksi, serta tanda tangan dengan satu kunci privat, terikat erat dalam waktu yang lama. Selama prasyarat ini tidak berubah, banyak kemampuan yang saat ini dianggap wajar dimiliki oleh pengguna—misalnya mengganti aturan penandatanganan secara fleksibel, meminta pihak lain membayar Gas, memulihkan kendali akun setelah kunci privat hilang, atau bahkan melakukan migrasi yang mulus ke sistem sandi baru di masa depan—sulit untuk benar-benar menjadi kemampuan default akun.

Jika kamu pernah menggunakan imToken atau dompet Web3 lainnya, besar kemungkinan kamu juga pernah menghadapi titik sakit tersebut: misalnya di dompet ada banyak USDC, tetapi tanpa ETH kamu tidak bisa mengirim transaksi (karena Gas hanya bisa dibayar dengan ETH); jika kehilangan seed phrase, uang hilang total dan tidak bisa dipulihkan; operasi “otorisasi + pertukaran” perlu menandatangani dua kali, mengonfirmasi dua kali, dan seterusnya.

Masalah-masalah ini bukan karena produk dompetnya “kurang bagus”, 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 berjalan terlebih dulu di lapisan aplikasi; lalu EIP-7702 sekali lagi membuktikan bahwa EOA tidak sepenuhnya tidak bisa diperluas—setidaknya ia bisa memperoleh kemampuan sebagian yang mendekati akun cerdas untuk sementara.

Artinya, Ethereum sebenarnya tidak ingin melakukan abstraksi akun, namun terus melakukannya dengan cara yang lebih lembut dan konservatif, secara bertahap mendekati hal tersebut. Dan kemunculan EIP-8141 berarti jalur ini telah mencapai sebuah titik baru. Ia tidak lagi puas menambahkan lapisan kemampuan akun cerdas di luar sistem yang ada, melainkan berupaya menyematkan abstraksi akun langsung ke dalam model transaksi itu sendiri—sehingga sejak lapisan protokol, akun sudah memiliki logika verifikasi dan eksekusi yang dapat diprogram.

Inilah juga mengapa EIP-8141 kembali memanas pada masa sekarang. Di satu sisi, pengalaman dompet di lapisan atas sudah semakin mendekati abstraksi akun native, sehingga lapisan protokol pada akhirnya harus menyusul; di sisi lain, tekanan jangka panjang akibat komputasi kuantum juga sedang mengubah “apakah akun bisa mengganti metode penandatanganan secara fleksibel” dari isu teknis yang jauh menjadi masalah nyata yang harus dipertimbangkan dengan serius sejak sekarang.

II. Bagaimana EIP-8141 bekerja?

Pada akhirnya, 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 berarti satu pemanggilan”, maka yang ingin dilakukan oleh EIP-8141 adalah memecah satu transaksi menjadi serangkaian “frame” yang dapat dieksekusi sesuai urutan aturan, sehingga tiga hal yang tadinya terikat bersama—verifikasi, pembayaran, dan eksekusi—dipisahkan untuk diproses.

Setiap “frame” memiliki tiga mode eksekusi:

VERIFY (frame verifikasi): bertanggung jawab memverifikasi apakah transaksi legal; ia akan menjalankan logika verifikasi yang disesuaikan oleh akun. Jika lolos, ia akan memanggil opcode APPROVE yang baru diperkenalkan untuk mengotorisasi eksekusi dan menetapkan batas atas Gas.

SENDER (frame pengirim): menjalankan operasi nyata, seperti transfer, memanggil kontrak, dan lain-lain. Alamat pemanggil adalah pengirim transaksi itu sendiri.

DEFAULT (frame pintu masuk): menggunakan alamat pintu masuk sistem sebagai pemanggil, untuk skenario seperti deploy kontrak, verifikasi Paymaster, dan sebagainya;

Makna dari mekanisme ini bukanlah membuat transaksi bisa menjadi lebih kompleks, melainkan untuk pertama kalinya memisahkan ketiga hal—verifikasi, pembayaran, dan eksekusi—dari aksi akun, lalu menyerahkan penjadwalan dasarnya kepada protokol secara native.

Pasalnya, sebelumnya, siapa yang memverifikasi transaksi, siapa yang membayar Gas, dan siapa yang menjalankan operasi nyata, pada dasarnya selalu terikat ke dalam aksi akun yang sama. Namun dalam desain EIP-8141, ketiga hal ini bisa diurai menjadi frame yang berbeda, lalu dieksekusi oleh protokol secara berurutan sesuai urutan yang jelas. Dan justru karena itulah, akun tidak lagi hanya bergantung pada satu kunci privat untuk “menandatangani secara keseluruhan”, melainkan mulai memiliki bentuk yang lebih mirip entitas eksekusi yang dapat diprogram.

Ambil contoh yang konkret. Misalnya kamu ingin memakai USDC untuk membayar Gas guna menyelesaikan sebuah Swap. Dalam kerangka EIP-8141, secara teori hal ini bisa diorganisasi menjadi satu rangkaian alur frame yang lengkap: pertama akun memverifikasi tanda tangan dan izin eksekusi, lalu pihak pembayaran atau Paymaster memverifikasi kondisi bahwa ia bersedia menanggung biaya, kemudian menyelesaikan pembayaran biaya untuk aset terkait, dan akhirnya menjalankan operasi swap yang sesungguhnya.

Dengan begitu, pembayaran Gas dan transaksi utama bisa masuk ke dalam satu alur atomik yang sama: atau semuanya berhasil, atau semuanya dibatalkan (rollback).

Bagi pengguna, perubahan yang paling langsung adalah: banyak operasi yang sebelumnya harus dipecah menjadi dua atau tiga langkah, serta memiliki risiko kegagalan di antaranya, ke depan bisa dibuat menjadi seperti satu tindakan utuh. Karena itu, atomisitas inilah salah satu kunci yang ingin ditangani EIP-8141 untuk masalah fragmentasi pengalaman pengguna.

Lalu, apa artinya bagi pengguna dompet? Dari hasilnya, perubahan yang paling langsung setidaknya ada empat lapisan:

Gas dibatasi/diabstraksikan: jika di dompet ada stablecoin, itu tidak lagi berarti kamu harus menyiapkan ETH tambahan untuk melakukan transaksi. Ke depan, membayar Gas oleh DApp, Paymaster, atau pihak sponsor lain akan menjadi lebih native;

Operasi bertahap digabung: seperti proses yang sering butuh banyak tanda tangan saat ini, misalnya “otorisasi + Swap” atau “otorisasi + staking”, berpeluang untuk dibungkus menjadi satu operasi yang lebih lengkap;

Aturan keamanan akun dibuka: multi-tanda tangan, pemulihan sosial, batas harian, time lock, rotasi kunci—semuanya tidak lagi hanya kemampuan tingkat lanjut tambahan yang diberikan oleh produk dompet tertentu, melainkan berpeluang dibangun di atas logika akun yang lebih native;

Skema penandatanganan tidak lagi harus terkunci pada jalur tunggal ECDSA: ini membuat migrasi akun ke berbagai sistem sandi di masa depan, termasuk skema tanda tangan tahan kuantum, untuk pertama kalinya memiliki kemungkinan bermakna di tingkat protokol;

III. Mengapa tidak menjadi unggulan Hegotá?

Poin yang sangat mudah terlewatkan, namun sangat penting bagi pengguna dompet, adalah: sekalipun EIP-8141 pada akhirnya benar-benar terealisasi, sistem akun yang ada tidak akan langsung dihancurkan secara keseluruhan.

Bahkan jika saat ini kamu menggunakan dompet Web3 yang sudah ada seperti imToken, kamu tidak perlu bermigrasi karena kompatibel ke belakang: alamat EOA yang ada dapat terus digunakan, dan hanya perlu memilih, pada waktu yang tepat, untuk “meng-upgrade” logika verifikasi akun.

Namun justru sebaliknya, karena perubahan yang dibuatnya cukup dalam, ia tidak menjadi fitur unggulan utama Hegotá dalam putaran diskusi terbaru. Akan tetapi, mengacu pada alur EIP champion 2026, arti CFI (Considered for Inclusion) tidaklah berarti ditolak, melainkan masuk tahap pertimbangan serius—namun belum sampai pada keputusan akhir untuk ditayangkan.

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

Pasalnya, abstraksi akun native tidak seperti ERC-4337 yang bisa didorong secara bertahap terlebih dahulu oleh sejumlah kecil dompet, infrastruktur, dan aplikasi. Begitu ia masuk ke lapisan protokol, itu berarti semua klien di lapisan eksekusi harus benar-benar memahami, menguji, dan berkoordinasi. Ini secara alami meningkatkan ambang dorongan, dan membuat pengembang inti cenderung lebih berhati-hati dalam perencanaan fork.

Lalu, apa yang akan terjadi berikutnya? Kita bisa melihatnya dalam dua jalur:

Karena EIP-8141 berada pada status CFI, itu berarti ia masih terus dinilai. Penulis proposal akan terus melengkapi detail-detail kunci yang terkait dengan keamanan transaction pool, aturan verifikasi, dan implementasi klien. Lalu pertemuan ACD berikutnya akan meninjau lagi apakah ia memenuhi syarat untuk didorong lebih lanjut;

Jika ketidakpastian tersebut dapat terus ditekan dan diperkecil, maka ada kesempatan untuk masuk ke tahap yang lebih substansial pada upgrade berikutnya; jika tidak, ia juga sepenuhnya bisa ditunda ke siklus upgrade yang lebih lambat;

Secara jujur, EIP-8141 bukanlah satu-satunya proposal abstraksi akun native. Bahkan, ia sendiri bukan semacam skema tanda tangan tahan kuantum yang sudah jadi dan tidak bisa langsung menyelesaikan masalah komputasi kuantum. Tetapi pentingnya terletak pada fakta bahwa ini pertama kalinya menyediakan “jalan keluar” bermakna di tingkat protokol bagi akun untuk melepaskan diri dari jalur tunggal ECDSA.

Dari sudut pandang ini, nilai sebenarnya dari EIP-8141 tidak terletak pada apakah ia jawaban yang satu-satunya, melainkan pada kenyataan bahwa untuk pertama kalinya, pertanyaan tentang seperti apa “akhir (final state) abstraksi akun native” seharusnya diwujudkan, dibawa dengan sangat lengkap ke meja diskusi protokol Ethereum.

Ini bukan satu-satunya solusi, tetapi memang salah satu yang paling ambisius saat ini, dan paling mendekati batas imajinasi “full native AA”.

Apa pun apakah EIP-8141 pada akhirnya bisa menyusul Hegotá, diskusi ini setidaknya sudah menunjukkan satu hal:

Ethereum tidak menunggu masalah membusuk di tempat. Sebaliknya, Ethereum sedang membuka jalan untuk sistem akun generasi berikutnya lebih awal, dengan langkah kecil yang konsisten, satu langkah demi satu.