Crypto · 7 min read · 9 views
Hegotá Ethereum: Cara FOCIL dan Frame Transactions Mengubah Inklusi Transaksi dan Wallet
Hegotá menempatkan FOCIL dan Frame Transactions sebagai dua perubahan inti Ethereum berikutnya. Pelajari cara keduanya memperkuat ketahanan sensor, account abstraction, serta kesiapan wallet dan infrastruktur.
GD
I Gusti Agung Ganes Satsangga Dipa
Backend & Software Developer
# Pembukaan
Ethereum sedang menyusun **Hegotá**, upgrade jaringan yang diproyeksikan mengikuti Glamsterdam. Fokusnya bukan sekadar menaikkan kapasitas, melainkan memperbaiki dua lapisan pengalaman yang sangat mendasar: siapa yang dapat memengaruhi transaksi agar masuk ke blok dan bagaimana sebuah akun membuktikan bahwa transaksi memang sah. Halaman roadmap resmi menempatkan Hegotá dalam tahap perencanaan dengan target sementara mainnet pada kuartal II 2027—tanggalnya belum dikonfirmasi—sehingga detail selain fitur utama masih dapat berubah [ethereum.org](https://ethereum.org/roadmap/hegota/).
Dua kandidat yang sudah dijadwalkan untuk masuk adalah **FOCIL** atau *fork-choice enforced inclusion lists* (EIP-7805) dan **Frame Transactions** (EIP-8141). FOCIL menyebarkan pengaruh atas inklusi transaksi ke sebuah komite validator, sedangkan Frame Transactions membuat validasi, eksekusi, dan pembayaran gas dapat diprogram sebagai rangkaian *frame*. Kombinasi ini berpotensi memperkuat ketahanan sensor sekaligus membawa fitur wallet seperti social recovery, multisig, spending limit, dan sponsored gas lebih dekat ke protokol dasar.
Namun, “dijadwalkan” bukan berarti spesifikasinya beku atau manfaatnya otomatis terasa pada pengguna biasa. Artikel ini membedah mekanisme kedua EIP, hubungan keduanya, dampak praktis bagi wallet, dApp, validator, dan infrastruktur, serta cara mengevaluasi Hegotá tanpa terjebak narasi bahwa semua persoalan account abstraction atau sensor langsung selesai dalam satu hard fork.
---
## Daftar Isi
01. [Apa Itu Hegotá, FOCIL, dan Frame Transactions?](#01--apa-itu-hegotá-focil-dan-frame-transactions)
02. [Mengapa Hal Ini Penting?](#02--mengapa-hal-ini-penting)
03. [Bagaimana Cara Kerjanya?](#03--bagaimana-cara-kerjanya)
04. [Kesalahan yang Sering Terjadi](#04--kesalahan-yang-sering-terjadi)
05. [Tips Tambahan](#05--tips-tambahan)
06. [Kesimpulan](#kesimpulan)
---
## 01 — Apa Itu Hegotá, FOCIL, dan Frame Transactions?
Hegotá adalah nama gabungan Heze untuk sisi konsensus dan Bogotá untuk sisi eksekusi. Headliner konsensusnya, FOCIL, mencoba mengurangi ketergantungan pada satu pihak pembangun blok dalam menentukan transaksi mana yang tampil. Dalam rancangan [EIP-7805](https://eips.ethereum.org/EIPS/eip-7805), beberapa validator dipilih sebagai anggota komite *inclusion list* (IL); masing-masing menyusun dan menyebarkan daftar transaksi berdasarkan pandangan mempool-nya. Proposer atau builder berikutnya harus memenuhi daftar yang tersedia, sementara attester hanya memberi suara pada blok yang memenuhi kondisi IL. Karena kepatuhannya dikaitkan dengan *fork choice*, blok yang mengabaikan transaksi yang wajib dimasukkan berisiko tidak memperoleh dukungan untuk menjadi bagian rantai kanonis.
Pada sisi eksekusi, [EIP-8141](https://eips.ethereum.org/EIPS/eip-8141) memperkenalkan tipe transaksi baru yang diurai menjadi rangkaian *frame*: panggilan kontrak dengan peran untuk memverifikasi otorisasi, menyetujui pembayaran gas, dan menjalankan operasi pengguna. Alih-alih selalu menganggap “satu private key ECDSA = satu akun”, akun dapat menjalankan aturan validasinya sendiri—misalnya beberapa persetujuan, pemulihan sosial, payer gas terpisah, atau skema tanda tangan baru. Ethereum Foundation menempatkan FOCIL dan Frames sebagai komitmen rekayasa inti Hegotá, serta menekankan bahwa interaksi keduanya harus diuji bersama karena transaksi dengan validasi yang dapat diprogram lebih sulit dinilai kelayakannya untuk dipaksa masuk [EF Protocol priorities](https://blog.ethereum.org/2026/09/07/protocol-priorities).
> **Highlight:** Hegotá memasangkan hak kolektif validator untuk menuntut inklusi transaksi dengan kemampuan akun menentukan sendiri cara transaksi divalidasi dan dibayar.
---
## 02 — Mengapa Hal Ini Penting?
Pemisahan antara proposer dan builder membantu pasar pembuatan blok menjadi efisien, tetapi konsentrasi builder dapat memperbesar risiko transaksi tertentu ditunda. FOCIL membuat keputusan inklusi tidak sepenuhnya berada di satu builder, sedangkan Frames mengurangi kebutuhan wallet pintar untuk menumpuk logika di atas jalur transaksi lama. Roadmap Ethereum juga mengaitkan Frames dengan jalur menuju tanda tangan tahan-kuantum karena akun dapat memilih verifier baru tanpa menunggu protokol menetapkan satu skema universal; ini adalah jalur kesiapan, bukan klaim bahwa Ethereum sudah sepenuhnya post-quantum. EF sendiri menyebut Hegotá bukan “fork post-quantum”, melainkan tahap yang menentukan apakah rangkaian upgrade menuju kesiapan tersebut bisa dikirim tepat waktu [EF Protocol priorities](https://blog.ethereum.org/2026/09/07/protocol-priorities).
- **Untuk pengguna wallet:** pemulihan sosial, batas pengeluaran, beberapa signer, dan gas yang dibayar pihak lain dapat memperoleh fondasi protokol yang lebih langsung.
- **Untuk dApp:** integrasi perlu mengenali tipe transaksi serta pola otorisasi baru; asumsi bahwa `sender` selalu identik dengan satu kunci menjadi makin rapuh.
- **Untuk validator dan builder:** ada data IL, aturan gossip, pemeriksaan pemenuhan daftar, dan kewajiban attestation baru yang perlu diimplementasikan konsisten.
- **Untuk relayer dan bundler:** sebagian fungsi account abstraction berpotensi menjadi lebih native, tetapi layanan tersebut belum tentu hilang karena masih berguna untuk routing, sponsorship, agregasi, dan kebijakan aplikasi.
- **Untuk ketahanan sensor:** serangan tidak cukup hanya menguasai atau memengaruhi satu builder; penyerang harus menghadapi komite dan aturan fork-choice, meski transaksi tetap wajib valid dan mampu membayar biaya yang berlaku.
---
## 03 — Bagaimana Cara Kerjanya?
### Step 01 — Komite membentuk inclusion list
Pada setiap slot, anggota komite IL mengamati mempool lalu menggossip daftar transaksi yang menurut mereka layak dimasukkan. Proposer, builder, dan attester menyimpan daftar yang tersedia; mekanisme juga perlu menangani anggota yang mengirim daftar bertentangan. FOCIL tidak memberikan jalur gratis atau memaksa transaksi invalid: nonce, saldo, fee, batas gas, dan kondisi validitas lain tetap diperiksa. Tujuannya adalah membedakan “tidak dimasukkan karena memang tidak valid atau blok tidak memiliki kapasitas” dari “sengaja dihilangkan meski layak”.
### Step 02 — Builder menyusun blok, attester menegakkan aturan
Builder menyusun payload dengan transaksi biasa sekaligus transaksi IL yang wajib dipenuhi. Ketika blok tiba, attester membandingkannya dengan IL yang mereka simpan dan menahan suara apabila kondisi tidak terpenuhi; inilah alasan istilah *fork-choice enforced*. Sementara itu, Frame Transaction membawa urutan instruksi yang memisahkan validasi, persetujuan pembayaran, dan eksekusi. Pemisahan ini memungkinkan payer berbeda dari sender dan aturan autentikasi berbasis kontrak, tetapi juga menambah permukaan kegagalan—mulai dari estimasi gas, semantik revert, sampai validasi yang bergantung pada state.
### Step 03 — Wallet dan infrastruktur menguji interaksi keduanya
Tantangan utama muncul ketika FOCIL harus menentukan apakah Frame Transaction dengan logika validasi fleksibel benar-benar dapat dipaksakan masuk. Tim protokol karena itu memperlakukan integrasi FOCIL–Frames sebagai satu *testing surface*, bukan dua fitur terisolasi. Sebelum mainnet, wallet perlu menguji signing dan replacement, RPC perlu mem-parsing tipe transaksi baru, explorer perlu menampilkan sender serta payer secara benar, dan validator perlu menguji jalur IL pada devnet/testnet. Publikasi tier list EF menunjukkan proses penyaringan scope yang ketat: dari 62 proposal yang dievaluasi, dua berstatus “must ship”, 15 “expected to ship”, sementara 28 ditolak untuk fork ini agar kompleksitas tidak menggerus waktu pengujian [tier list Hegotá](https://blog.ethereum.org/2026/09/07/protocol-hegota-eips).
| Komponen | Input utama | Aturan inti | Dampak bila gagal |
|---|---|---|---|
| Komite IL | Transaksi yang terlihat di mempool | Menyusun dan menggossip daftar | Jaminan inklusi melemah atau pandangan antar-node berbeda |
| Builder/proposer | IL dan transaksi biasa | Memenuhi transaksi IL yang masih valid | Blok berisiko tidak di-attest |
| Attester | Blok kandidat dan IL tersimpan | Memeriksa pemenuhan sebelum voting | Blok nonpatuh dapat gagal menjadi kanonis |
| Frame validator | Data frame dan state akun | Menjalankan aturan autentikasi akun | Transaksi ditolak bila validasi gagal |
| Gas payer | Persetujuan pembayaran | Menanggung biaya sesuai scope | Eksekusi tidak berjalan bila approval tidak sah |
```text
Mempool → Komite IL → daftar wajib ─┐
├→ Builder menyusun blok → Attester memeriksa → Fork choice
Frame tx → verify → approve gas ───┘ │
→ execute operasi └→ blok kanonis / ditolak
```
---
## 04 — Kesalahan yang Sering Terjadi
> ⚠️ **Kesalahan #1 — Menganggap Hegotá dan tanggal mainnet sudah final**
> Hegotá masih dalam perencanaan; target Q2 2027 di roadmap belum dikonfirmasi dan scope di luar fitur terjadwal masih dapat berubah. Hindari membangun deadline produksi hanya dari target sementara.
> ⚠️ **Kesalahan #2 — Mengira FOCIL memaksa semua transaksi masuk**
> FOCIL berupaya menjamin inklusi transaksi yang memenuhi syarat, bukan mengabaikan nonce, saldo, base fee, gas, atau validitas. Pantau aturan eligibility final sebelum menyimpulkan transaksi tertentu dilindungi.
> ⚠️ **Kesalahan #3 — Menganggap Frames otomatis menghapus bundler dan seluruh risiko wallet**
> Validasi native mengurangi beberapa lapisan tambahan, tetapi sponsorship, routing, kebijakan mempool, verifier contract, dan integrasi aplikasi tetap membawa risiko. Audit logika akun dan siapkan fallback operasional.
---
## 05 — Tips Tambahan
- **Tip 01 — Pisahkan status proposal dari status aktivasi.** Tandai fitur sebagai draft, scheduled, testnet, atau mainnet agar pengguna tidak salah mengira kemampuan sudah tersedia.
- **Tip 02 — Inventarisasi asumsi integrasi.** Cari kode yang menganggap satu sender, satu nonce linear, satu signature, payer selalu sender, atau tipe transaksi selalu lama.
- **Tip 03 — Uji perilaku gagal, bukan hanya happy path.** Simulasikan frame validation gagal, sponsor kehabisan saldo, transaksi IL menjadi invalid, node melihat IL berbeda, dan blok tidak memenuhi daftar.
---
## Kesimpulan
Hegotá penting karena mencoba menyelesaikan dua masalah yang saling bersinggungan: ketergantungan pada builder dalam inklusi transaksi dan keterbatasan model transaksi berbasis satu kunci. FOCIL membuat komite validator dapat menetapkan batas minimum inklusi yang ditegakkan melalui fork choice, sedangkan Frame Transactions memberi akun bahasa yang lebih fleksibel untuk validasi, pembayaran gas, dan eksekusi. Potensinya besar untuk wallet yang lebih aman, UX yang lebih baik, dan ketahanan sensor yang lebih kuat, tetapi manfaat riil bergantung pada spesifikasi final, interoperabilitas client, pengujian gabungan, serta kesiapan aplikasi—jadi perlakukan roadmap sebagai arah teknis yang perlu dipantau, bukan janji fitur atau tanggal yang sudah pasti.
*Disclaimer: Artikel ini bersifat informatif dan bukan nasihat keuangan atau rekomendasi investasi.*
---
## Sumber
- [Hegotá — ethereum.org](https://ethereum.org/roadmap/hegota/) — status perencanaan, target sementara, serta ringkasan FOCIL dan Frame Transactions.
- [EIP-7805: Fork-choice Enforced Inclusion Lists — Ethereum Improvement Proposals](https://eips.ethereum.org/EIPS/eip-7805) — spesifikasi mekanisme komite IL dan penegakan melalui attestation/fork choice.
- [EIP-8141: Frame Transaction — Ethereum Improvement Proposals](https://eips.ethereum.org/EIPS/eip-8141) — spesifikasi tipe transaksi berbasis frame untuk validasi, eksekusi, dan pembayaran gas.
- [EF Protocol: Current and Emerging Priorities — Ethereum Foundation](https://blog.ethereum.org/2026/09/07/protocol-priorities) — prioritas Hegotá, hubungan FOCIL–Frames, dan jalur kesiapan post-quantum.
- [The Hegotá EIP Opinion Post and Tier List — Ethereum Foundation](https://blog.ethereum.org/2026/09/07/protocol-hegota-eips) — metode pemeringkatan dan hasil evaluasi 62 proposal Hegotá.
Tags: #Ethereum#Hegotá#FOCIL#EIP-7805#Frame Transactions#EIP-8141#account abstraction#censorship resistance#smart wallet#post-quantum
GD
Tentang Penulis — Ganes Satsangga
Backend Developer berpengalaman membangun aplikasi web, sistem ERP/CMS, integrasi API, dan database menggunakan Laravel, PHP, dan Go.
