Apa Itu Ethereum Frame Transactions?

Bagi para pemula yang menjumpai istilah “Transaksi Frame” dalam diskusi Ethereum dan Hegotá, cara termudah memahaminya adalah melihatnya sebagai transaksi yang terdiri atas beberapa langkah terkoordinasi. Satu frame dapat memverifikasi pengirim, frame lain mengotorisasi pembayaran, dan frame berikutnya mengeksekusi aksi pengguna. Artikel ini membahas struktur dasar tersebut, bukan cakupan proposal EIP-8141 secara menyeluruh.

Key Takeaways

• EIP-8141 memperkenalkan tipe Transaksi Frame baru yang saat ini ditetapkan sebagai tipe transaksi 0x06.

• Satu transaksi dapat terdiri hingga 64 frame, di mana tiap frame memiliki mode eksekusi dan batas gas masing-masing.

• Frame memisahkan proses validasi transaksi, pembayaran gas, dan eksekusi pengguna.

• Opcode APPROVE dapat memberi otorisasi pada eksekusi, pembayaran, atau keduanya secara terpisah.

• Abstraksi frame menghadirkan native account abstraction, atomic batching, sponsorship gas, serta verifikasi tanda tangan yang dapat diprogram.

Apa Itu Transaksi Frame EIP-8141?

Spesifikasi resmi Transaksi Frame EIP-8141 mendefinisikan transaksi baru yang validitas serta pembayaran gasnya dapat diatur secara abstrak. Spesifikasi EIP-8141

Payload transaksi ini meliputi alamat pengirim, tanda tangan, biaya, serta daftar frame. Setiap frame menentukan mode, flag, target, batas eksekusi dan state-gas, nilai, serta datanya sendiri. Spesifikasi terkini menetapkan MAX_FRAMES sebanyak 64 dan FRAME_TX_TYPE sebesar 0x06.

Singkatnya, transaksi legacy menggunakan skema pengirim-menandatangani-pengirim-membayar yang kaku, sedangkan abstraksi frame mengubahnya menjadi urutan yang dapat diprogram.

Bagaimana Cara Kerja Mode Eksekusi pada Transaksi Frame?

Setiap frame EIP-8141 memiliki salah satu dari tiga mode eksekusi berikut:

Mode eksekusi menentukan konteks eksekusi frame. Frame VERIFY dapat menjalankan logika verifikasi sebelum frame pengirim dieksekusi, mode SENDER memungkinkan operasi seolah-olah dipanggil dari alamat pengirim, sedangkan DEFAULT memberikan identitas eksekusi netral pada tingkat protokol.

Struktur modular ini sangat penting untuk native account abstraction karena proses validasi tak lagi terpaku pada satu kunci privat atau skema tanda tangan tertentu.

Apa Peran Opcode APPROVE?

EIP-8141 menambahkan opcode APPROVE untuk memperbarui konteks persetujuan dalam transaksi.

Logika validasi bisa mengatur cakupan persetujuan sebagai berikut:

• APPROVE_PAYMENT mengotorisasi pembayaran gas.

• APPROVE_EXECUTION mengotorisasi frame eksekusi berikutnya.

• APPROVE_EXECUTION_AND_PAYMENT mengotorisasi keduanya sekaligus.

Target frame yang telah diresolusikan wajib menjadi pemanggil APPROVE, sehingga hanya pihak tertentu yang dapat memberikan otorisasi. Setelah eksekusi disetujui, frame SENDER berikutnya dapat berjalan menggunakan konteks pengirim.

Pemisahan ini memungkinkan kontrak sponsor atau paymaster mengonfirmasi batas maksimum biaya gas, sementara validasi eksekusi tetap dikontrol logika pengguna.

Apa Saja Tujuh Opcode Frame EIP-8141?

Spesifikasi terkini memuat tujuh instruksi baru terkait frame:

Sebagai contoh, TXPARAM bisa menampilkan informasi berskala transaksi seperti pengirim, batas biaya maksimum, hash tanda tangan, dan jumlah frame. FRAMEPARAM menampilkan detail frame seperti mode eksekusi, flag, gas yang digunakan, serta status flag atomic batch. Operasi lookup dasarnya memiliki biaya gas sebesar 2.

Bagaimana Mekanisme Pembayaran dan Akuntansi Gas?

Transaksi Frame memisahkan pembayaran gas dari pengirim. Frame VERIFY dapat mengotorisasi akun lain atau kontrak sponsor untuk membayar, sehingga sponsorship gas bisa dilakukan secara native.

Contohnya, pengguna memegang stablecoin dan akun lain bertindak sebagai pembayar gas. Transaksi Frame dapat mentransfer token ERC-20 untuk membayar sponsor tersebut, sementara biaya transaksi Ethereum diselesaikan oleh akun pembayar yang ditunjuk.

Setiap frame memiliki batas eksekusi dan state-gas. Gas yang tidak terpakai akan mengurangi beban biaya akhir pada pembayar, bukan menambah kapasitas eksekusi untuk frame-frame berikutnya.

Bagaimana Atomic Batch Membuat Semua Frame Berhasil atau Gagal Bersama?

Atomic batch menghubungkan beberapa frame eksekusi agar seluruhnya berhasil atau gagal secara bersamaan.

Misalnya, persetujuan ERC-20 diikuti swap. Jika flag atomic batch diaktifkan dan frame swap gagal, persetujuan token sebelumnya pun ikut digagalkan. Ini mencegah allowance token yang tidak diinginkan tertinggal jika transaksi utama gagal.

Inilah alasan praktis mengapa Transaksi Frame membantu menyederhanakan interaksi smart contract yang terdiri dari banyak langkah.

Mengapa Transaksi Frame Penting untuk Account Abstraction?

Kerangka kerja account abstraction ERC-4337 di Ethereum menggunakan smart account, bundler, UserOperation, dan paymaster untuk menghadirkan perilaku dompet yang dapat diprogram. Transaksi Frame membawa fleksibilitas ini langsung ke lapisan protokol.

Validasi yang dapat diprogram pada EIP-8141 juga mendukung skema tanda tangan beragam, rotasi kunci, agregasi tanda tangan di masa depan, serta kesiapan post-kuantum. Kode default memungkinkan akun tanpa kontrak yang telah di-deploy tetap bisa berpartisipasi, sementara frame deploy mendukung deployment akun sebelum tahap verifikasi.

Fleksibilitas ini juga membawa konsekuensi. Logika validasi arbitrer dapat menimbulkan risiko denial-of-service atau mass invalidation pada transaction pool, sehingga aturan mempool publik membatasi prefiks validasi dan tata kelola Transaksi Frame yang menunggu konfirmasi.

Kesimpulan

Transaksi Frame di Ethereum pada intinya adalah satu transaksi yang terdiri dari beberapa frame yang dapat diprogram. Alih-alih memadukan validasi, pembayaran gas, dan eksekusi dalam satu peran transaksi, EIP-8141 membagi tiap fungsi ke frame berbeda.

Inilah pembeda utamanya: EIP-8141 adalah proposal protokol; Transaksi Frame adalah format transaksi baru yang diperkenalkan. Struktur modular tersebut memungkinkan sponsorship gas, atomic batching, validasi dinamis, tanda tangan fleksibel, dan native account abstraction tanpa membuat tiap fitur menjadi sistem transaksi terpisah.

Pertanyaan yang Sering Diajukan

Apakah Mode VERIFY Bersifat Read-Only dalam Transaksi Frame?

Benar. Mode VERIFY digunakan untuk validasi transaksi dan dirancang agar tidak melakukan perubahan status yang persisten. Hal ini memudahkan node melakukan simulasi validasi secara aman sebelum menentukan apakah Transaksi Frame yang tertunda masuk atau tetap di mempool publik.

Bisakah Ethereum Mengetahui Pembayar Gas Sebelum Transaksi Frame Dieksekusi?

Tidak selalu. Dalam EIP-8141, pembayar dapat ditentukan secara dinamis melalui logika validasi yang dapat diprogram, sehingga tidak dapat dipastikan hanya dari data transaksi. Persetujuan pembayaran dilakukan pada proses validasi transaksi.

Kapan Pembayar Gas Disetujui dalam Transaksi Frame EIP-8141?

Otorisasi pengirim dilakukan lebih dulu, lalu otorisasi pembayaran dapat dikonfirmasi untuk akun atau paymaster yang akan menanggung biaya gas. Pemisahan ini memungkinkan satu pihak mengotorisasi eksekusi, sementara pihak lain mengotorisasi pembayaran gas.

Apakah Transaksi Frame Bisa Menggunakan Sisa Gas dari Frame Lain?

Tidak. Akuntansi gas Transaksi Frame mencegah satu frame meminjam sisa gas frame lain. Tiap frame memiliki batas eksekusi dan state-gas sendiri, sedangkan total limit gas transaksi mencakup gas intrinsik dan total limit eksekusi frame terkait.

Apa Bedanya Canonical dan Non-Canonical Paymaster?

Canonical paymaster menggunakan kode kontrak yang sesuai spesifikasi protokol dan dapat dipantau prediksi komitmen gasnya oleh node. Sementara non-canonical paymaster dikenai pembatasan mempool lebih ketat, termasuk hanya dapat memiliki satu transaksi tertunda, untuk mengurangi risiko mass invalidation dan denial-of-service.

Konten ini hanya untuk tujuan edukasi. EIP-8141 masih merupakan bagian dari roadmap protokol Ethereum yang berkembang, dan detail spesifikasi dapat berubah sebelum aktivasi mainnet.