Crypto · 5 min read · 5 views
FOCIL Ethereum: Cara EIP-7805 Memperkuat Resistansi Sensor Menuju Hegotá
FOCIL (EIP-7805) dirancang untuk memperkuat resistansi sensor Ethereum dengan melibatkan komite validator dalam inklusi transaksi. Artikel ini mengurai mekanisme, hubungannya dengan ePBS, risiko implementasi, dan indikator menuju Hegotá.
GD
I Gusti Agung Ganes Satsangga Dipa
Backend & Software Developer
# Pembukaan
Ethereum memasuki fase ketika penskalaan tidak cukup diukur dari banyaknya transaksi, tetapi juga dari kemampuan jaringan menjaga transaksi sah tetap dapat masuk ke blok. Salah satu rancangan yang sedang dikembangkan adalah *Fork-choice enforced Inclusion Lists* (FOCIL/EIP-7805): sekelompok validator menyusun daftar transaksi tertunda yang wajib dipertimbangkan pembuat blok. Dalam peta jalan resmi, FOCIL diposisikan sebagai fitur utama lapisan konsensus untuk peningkatan Hegotá setelah Glamsterdam, dengan target yang masih dapat berubah pada 2027 ([Ethereum.org — Security Roadmap](https://ethereum.org/roadmap/security/)).
Topik ini penting karena produksi blok Ethereum kini melibatkan spesialisasi antara pihak yang mengusulkan dan menyusun blok. Spesialisasi dapat meningkatkan efisiensi, namun konsentrasi infrastruktur juga memunculkan pertanyaan: bagaimana protokol memastikan satu pembuat blok tidak terus-menerus mengabaikan transaksi valid? FOCIL menawarkan jawaban di tingkat protokol, bukan janji bahwa setiap transaksi pasti langsung masuk. Artikel ini membedah mekanisme, kaitannya dengan ePBS, kompromi desain, dan indikator yang perlu dipantau—tanpa membahas harga ETH atau memberi nasihat investasi.
## Daftar Isi
- [01 — FOCIL dalam Bahasa Sederhana](#bagian-01)
- [02 — Mengapa Inclusion List Dibutuhkan](#bagian-02)
- [03 — Hubungan FOCIL dengan ePBS](#bagian-03)
- [04 — Kompromi Teknis dan Risiko Implementasi](#bagian-04)
- [05 — Indikator yang Perlu Dipantau](#bagian-05)
- [Kesimpulan](#kesimpulan-artikel)
- [Sumber](#sumber-artikel)
<a id="bagian-01"></a>
## 01 — FOCIL dalam Bahasa Sederhana
FOCIL dapat dibayangkan sebagai mekanisme “saksi kolektif” atas isi mempool. Beberapa validator dalam sebuah komite menerbitkan daftar transaksi valid yang telah mereka lihat; blok berikutnya diharapkan memasukkan transaksi dari daftar tersebut, sementara aturan *fork choice* memberi konsekuensi ketika kewajiban itu diabaikan. Dengan demikian, keputusan inklusi tidak hanya bergantung pada satu pembuat blok. EIP-7805 menjelaskan tujuan desain ini sebagai peningkatan ketahanan sensor dengan beban tambahan yang tetap terbatas ([EIP-7805](https://eips.ethereum.org/EIPS/eip-7805)).
> **Highlight:** FOCIL bukan tombol anti-sensor absolut; ia memperluas jumlah pihak yang dapat menuntut inklusi transaksi dan membuat pengabaian transaksi valid lebih sulit dilakukan secara diam-diam.
<a id="bagian-02"></a>
## 02 — Mengapa Inclusion List Dibutuhkan
Pada arsitektur blok yang makin terspesialisasi, pembuat blok mengoptimalkan susunan transaksi, sementara validator memilih dan mengesahkan hasilnya. Efisiensi ini membawa risiko ketergantungan pada sedikit pelaku atau relay yang dominan. Jika satu pihak menolak transaksi tertentu—karena kebijakan, tekanan yurisdiksi, atau insentif ekonomi—pengguna membutuhkan jalur protokol agar transaksi valid tetap terlihat oleh validator lain. Roadmap keamanan Ethereum menyebut resistansi sensor sebagai kemampuan mencegah satu aktor menghentikan transaksi valid mencapai rantai; FOCIL menambah suara banyak validator terhadap isi yang semestinya masuk ke blok ([Ethereum.org — A More Secure Ethereum](https://ethereum.org/roadmap/security/)).
| Aspek | Tanpa inclusion list protokol | Dengan rancangan FOCIL |
|---|---|---|
| Sumber keputusan inklusi | Sangat bergantung pada pembuat blok | Pembuat blok plus masukan komite validator |
| Visibilitas transaksi yang diabaikan | Sulit dibedakan dari keterlambatan biasa | Ada daftar transaksi yang telah disaksikan komite |
| Penegakan | Mayoritas berupa insentif pasar/off-protocol | Dikaitkan dengan aturan fork choice |
| Jaminan | Tidak ada kepastian transaksi langsung masuk | Tetap bukan jaminan instan; peluang sensor berulang dipersempit |
<a id="bagian-03"></a>
## 03 — Hubungan FOCIL dengan ePBS
FOCIL dirancang dalam urutan yang berkaitan dengan *enshrined Proposer-Builder Separation* (ePBS/EIP-7732). ePBS membawa pemisahan peran proposer dan builder ke dalam protokol, mengurangi ketergantungan pada relay pihak ketiga serta memberi waktu propagasi payload lebih panjang. Ethereum menempatkan ePBS sebagai fitur utama Glamsterdam, sedangkan FOCIL dijadwalkan setelahnya agar dua perubahan besar tidak diluncurkan sekaligus tanpa pengujian bertahap. Pembaruan prioritas protokol 2026 juga mengelompokkan penskalaan, pengalaman pengguna, dan penguatan L1 sebagai jalur kerja terkoordinasi—indikasi bahwa kapasitas dan ketahanan sensor diperlakukan sebagai sasaran yang harus tumbuh bersama ([Ethereum Foundation, 18 Februari 2026](https://blog.ethereum.org/2026/02/18/protocol-priorities-update-2026)).
- **ePBS:** mengatur pembagian tugas pembangunan dan pengusulan blok di tingkat protokol.
- **FOCIL:** memperluas pihak yang dapat menyatakan transaksi valid perlu dimasukkan.
- **Urutan pengembangan:** ePBS diuji lebih dulu dalam Glamsterdam; FOCIL menjadi *headliner* konsensus Hegotá.
- **Tujuan bersama:** menambah kapasitas tanpa menyerahkan akses transaksi kepada satu titik keputusan.
<a id="bagian-04"></a>
## 04 — Kompromi Teknis dan Risiko Implementasi
Setiap daftar inklusi membawa biaya: validator perlu menyebarkan daftar tepat waktu, node harus memverifikasi validitas transaksi, dan protokol harus menghadapi daftar yang tumpang tindih atau kondisi jaringan terfragmentasi. Aturan juga perlu mencegah komite memasukkan transaksi tidak valid, kedaluwarsa, atau sengaja memenuhi kapasitas blok. Karena itu, parameter jumlah anggota komite, batas ukuran daftar, tenggat propagasi, serta interaksi dengan biaya gas tidak boleh diperlakukan sebagai detail kecil. Statusnya masih pengembangan aktif; target fork, cakupan final, dan parameter dapat berubah setelah devnet, audit, serta evaluasi klien.
**Checklist risiko sebelum aktivasi mainnet:**
- [ ] Implementasi lintas klien menghasilkan keputusan yang konsisten.
- [ ] Batas daftar tidak membuka serangan spam atau pembengkakan blok.
- [ ] Validator rumahan tetap dapat mengikuti kebutuhan bandwidth dan komputasi.
- [ ] Kondisi *reorg*, keterlambatan jaringan, dan transaksi konflik diuji secara adversarial.
- [ ] Metrik sensor dapat membedakan penolakan sengaja dari kegagalan propagasi biasa.
<a id="bagian-05"></a>
## 05 — Indikator yang Perlu Dipantau
Pembaca sebaiknya tidak terpaku pada tanggal target. Ukuran kemajuan yang lebih bermakna adalah apakah EIP-7805 stabil, tersedia implementasi interoperabel pada beberapa klien, dan devnet memperlihatkan daftar dapat tersebar tanpa mengganggu stabilitas fork choice. Perhatikan pula perubahan status Hegotá di kanal resmi, hasil audit, pengujian terhadap skenario komite jahat, dan bukti bahwa operator node kecil tidak tersingkir. Unggahan akun resmi Ethereum di X dapat menjadi sinyal awal, tetapi bukan dasar final; untuk artikel ini, temuan X tidak dipakai sebagai sumber fakta karena detail teknis telah diverifikasi melalui dokumentasi Ethereum dan EIP resmi.
**Timeline pemantauan:**
1. **Spesifikasi:** revisi EIP-7805 dan penyelesaian parameter inti.
2. **Devnet:** interoperabilitas klien serta pengujian kondisi jaringan buruk.
3. **Testnet:** pengukuran propagasi, beban validator, dan perilaku fork choice.
4. **Keputusan fork:** konfirmasi cakupan Hegotá dan tanggal aktivasi.
5. **Pascapeluncuran:** rasio transaksi terlewat, insiden reorg, dan konsentrasi builder.
<a id="kesimpulan-artikel"></a>
## Kesimpulan
FOCIL adalah upaya memasukkan resistansi sensor ke jalur keputusan protokol: banyak validator dapat menyatakan transaksi valid yang seharusnya tidak diabaikan oleh pembuat blok. Nilainya bukan pada slogan “anti-sensor”, melainkan pada apakah implementasi nyata meningkatkan peluang inklusi tanpa membebani jaringan atau menciptakan vektor serangan baru. Hubungannya dengan ePBS menunjukkan strategi berlapis—benahi struktur produksi blok, lalu tambahkan mekanisme pengawasan inklusi. Sampai spesifikasi, pengujian lintas klien, dan jadwal fork benar-benar final, semua target waktu harus dibaca sebagai rencana teknis yang dapat berubah, bukan kepastian ataupun sinyal investasi.
<a id="sumber-artikel"></a>
## Sumber
1. [Ethereum.org — A More Secure Ethereum](https://ethereum.org/roadmap/security/) — status FOCIL, relasinya dengan ePBS, dan posisi Hegotá dalam roadmap keamanan.
2. [EIP-7805 — Fork-choice enforced Inclusion Lists](https://eips.ethereum.org/EIPS/eip-7805) — spesifikasi dan motivasi teknis inclusion list.
3. [Ethereum Foundation — Protocol Priorities Update for 2026](https://blog.ethereum.org/2026/02/18/protocol-priorities-update-2026) — prioritas Scale, Improve UX, dan Harden the L1.
4. [Ethereum.org — Glamsterdam](https://ethereum.org/roadmap/glamsterdam/) — konteks ePBS dan urutan peningkatan protokol sebelum Hegotá.
GD
Tentang Penulis — Ganes Satsangga
Backend Developer berpengalaman membangun aplikasi web, sistem ERP/CMS, integrasi API, dan database menggunakan Laravel, PHP, dan Go.
