Ethereum Mengeksplorasi FOCIL dan FairFIL untuk Meningkatkan Mekanisme Anti-Sensor

Di dunia blockchain, kita sering mendengar sebuah istilah: "anti-sensor".

Banyak orang mungkin langsung menganggapnya seperti slogan yang bersifat politis, bahkan memiliki nuansa anarkis, tetapi bagi jaringan penyelesaian terbuka untuk pengguna global seperti Ethereum, ketahanan terhadap sensor pertama-tama bukanlah posisi politik, melainkan kemampuan teknis yang sangat spesifik.

Bayangkan Anda memulai transaksi di dompet imToken.

Tanda tangan benar, saldo akun cukup, biaya Gas juga tidak rendah, tetapi transaksi belum juga ditulis ke dalam blok, status di dompet tetap berada di «Pending», sementara transaksi lain dengan biaya serupa bahkan lebih rendah terus-menerus ditambahkan ke rantai.

Masalahnya kemudian menjadi siapa yang berhak menentukan apakah sebuah transaksi dapat dimasukkan ke dalam blok? Toh, jika Ethereum tetap memerlukan beberapa peserta terpusat untuk menentukan transaksi mana yang dapat dimasukkan ke dalam rantai, maka tidak ada perbedaan mendasar antara Ethereum dan sistem keuangan tradisional.

Oleh karena itu, Ethereum dalam beberapa tahun terakhir sedang mengeksplorasi serangkaian mekanisme anti-sensorship seperti FOCIL dan FairFIL, yang berusaha menjawab pertanyaan yang tampak sederhana tetapi sebenarnya sangat penting: bagaimana cara menjamin bahwa setiap transaksi yang memenuhi aturan protokol memiliki kesempatan yang adil untuk masuk ke dalam blok?

Untuk memahami mengapa Ethereum memerlukan mekanisme ini, pertama-tama perlu dipahami apa yang terjadi setelah sebuah transaksi dikirim dari dompet.

Ketika pengguna menandatangani dan mengirim transaksi dari dompetnya, transaksi tersebut biasanya masuk terlebih dahulu ke dalam pool transaksi publik Ethereum, yaitu mempool, yang lebih seperti area tunggu yang menyimpan sejumlah besar transaksi yang belum ditulis ke dalam blok.

Namun, masuk ke area tunggu tidak berarti transaksi telah tercatat di blockchain; masih diperlukan seseorang untuk memilih transaksi tersebut, menentukan urutannya, menyusunnya menjadi satu blok lengkap, lalu menyerahkannya ke jaringan untuk dikonfirmasi.

Masalah justru muncul di tahap ini.

Setelah Ethereum meningkat ke mekanisme PoS (Proof of Stake), untuk mencegah kolam staking besar memanfaatkan MEV (Maximal Extractable Value) untuk membentuk monopoli ekonomi, Ethereum memperkenalkan sistem PBS (Proposer-Builder Separation, Pemisahan Pengusul dan Pembangun), di mana dalam arsitektur ini, proses penanganan setiap transaksi Ethereum dibagi menjadi dua peran:

• Builder: Bertanggung jawab mengumpulkan transaksi, mengatur urutan transaksi, mencari peluang arbitrase dan likuidasi, serta membangun blok dengan keuntungan seoptimal mungkin;
• Proposer: Bertanggung jawab memilih satu blok kandidat dari yang disubmit oleh Builder dan mengirimkannya ke jaringan;

Pembagian tugas ini memiliki manfaat yang sangat nyata.

Seperti diketahui, dalam beberapa tahun terakhir, strategi MEV menjadi semakin kompleks; jika setiap validator biasa diminta untuk secara mandiri melakukan pengurutan transaksi dan optimasi blok, maka node-node besar yang memiliki lebih banyak modal, data, dan kemampuan teknis akan mendapatkan keunggulan.

Jadi, serahkan pekerjaan kompleks pembangunan blok kepada Builder profesional; bahkan node verifikasi biasa yang tidak memiliki kemampuan arbitrase tingkat lanjut dapat berpartisipasi dalam usulan blok dan memperoleh imbalan yang sesuai, sehingga mengurangi dampak MEV terhadap desentralisasi staking.

Namun, hal ini juga secara tidak sengaja membawa efek samping lain, yaitu konsentrasi berlebihan atas hak pembangunan blok. Misalnya, saat ini lebih dari 90% blok Ethereum di seluruh jaringan hanya diproduksi oleh beberapa Builder profesional saja, dan karena Builder-builder ini biasanya memiliki latar belakang operasional entitas yang jelas, mereka sangat rentan terhadap tekanan eksternal terkait kepatuhan hukum di negara atau wilayah tertentu (misalnya, daftar sanksi OFAC), sehingga pada dasarnya telah menciptakan risiko sentralisasi.

Oleh karena itu, ketika beberapa Builder utama ini secara selektif menyaring transaksi kontrak sensitif tertentu (seperti Tornado Cash) atau alamat tertentu, transaksi-transaksi tersebut akan terjebak dalam kondisi yang tidak dapat diproses dalam waktu lama, bahkan berisiko mengalami "pemblokiran implisit".

Secara keseluruhan, bagi pengguna biasa, Ethereum adalah jaringan terbuka yang dapat dihubungkan, ditransfer, dan dipanggil kontrak cerdas oleh siapa pun, tetapi dari sudut pandang operasi protokol, mengirim transaksi hanyalah langkah pertama; keberhasilan transaksi benar-benar terwujud tergantung pada apakah ia dipilih, diurutkan, dan dimasukkan ke dalam blok oleh pembuat blok tertentu.

Oleh karena itu, "anti-sensorship" yang dibahas dalam konteks Ethereum bukan hanya konsep besar yang terkait dengan politik, regulasi, atau sanksi, tetapi pertama-tama merupakan masalah teknis yang sangat spesifik:

Ketika sebuah transaksi memenuhi aturan protokol, apakah jaringan dapat menjamin kesempatan untuk dimasukkan ke dalam blok dalam waktu yang wajar?

Sebenarnya, sampai di sini, masalahnya sudah jelas: Builder dapat meningkatkan efisiensi pembangunan blok, tetapi jika hak memasukkan transaksi tetap terkonsentrasi di tangan beberapa Builder saja, Ethereum akan kembali menghadapi risiko monopoli terpusat.

For this, Ethereum researchers proposed Inclusion Lists, commonly known as "inclusion lists."

Nama ini terdengar agak abstrak, tetapi logika intinya tidak rumit—Builder tetap bertanggung jawab membuat blok, tetapi tidak dapat memutuskan sendiri nasib semua transaksi; node verifikasi yang berpartisipasi secara normal dalam staking Ethereum juga perlu mempertahankan sebagian wewenang untuk dapat mencantumkan beberapa transaksi yang harus diproses.

Sebagai contoh stasiun bus, sebuah blok dapat dipahami sebagai sebuah perjalanan dengan jumlah kursi terbatas.

Builder menentukan bagaimana sebagian besar penumpang antri dan duduk di mana, untuk meningkatkan pendapatan keseluruhan kereta melalui pengaturan yang lebih efisien; namun, node verifikasi juga dapat mengajukan daftar "wajib naik", di mana transaksi dalam daftar tersebut tetap valid, bersedia membayar biaya yang wajar, dan masih ada ruang cukup di blok, sehingga Builder tidak dapat terus-menerus menolaknya hanya berdasarkan preferensi pribadi.

Namun, siapa yang seharusnya membuat daftar tersebut, serta apa yang harus dilakukan jika seseorang sengaja melewatkan transaksi, tetap merupakan dua masalah yang perlu diselesaikan lebih lanjut.

FOCIL dan FairFIL, tepatnya dikembangkan sepanjang dua arah ini.

1. FOCIL: Jangan biarkan seorang Proposer sendirian membuka daftar yang berisi

FOCIL (Fork-Choice Enforced Inclusion Lists) memindahkan kekuasaan untuk menentukan apakah transaksi harus dimasukkan, dari proposer tunggal ke komite validator yang terdiri dari banyak pihak.

Dalam setiap siklus blok, jaringan akan memilih secara acak sekelompok node verifikasi untuk membentuk komite sementara, di mana setiap anggota komite akan secara independen mengamati mempool jaringan dan mengirimkan daftar lokal masing-masing.

Ini berarti bahwa meskipun 99% dari Builder dan proposer di seluruh jaringan berusaha melakukan sensor terhadap transaksi tertentu, selama ada satu node jujur di komite yang memasukkan transaksi tersebut ke dalam daftar, transaksi tersebut masih memiliki peluang untuk dimasukkan ke dalam protokol. Jika para penyensor ingin terus mengecualikannya, mereka tidak lagi hanya memengaruhi satu orang, tetapi harus melewati beberapa peserta independen secara bersamaan.

Jadi keunggulannya adalah, Anda tidak perlu percaya bahwa setiap anggota komite tetap netral.

Namun, daftar saja tidak cukup; jika Builder menerima daftar tersebut tetapi tetap memilih untuk tidak melaksanakannya, daftar tersebut akan menjadi saran yang tidak mengikat.

Oleh karena itu, FOCIL menambahkan lapisan desain kedua, memperkenalkan aturan pemilihan fork untuk memberikan batasan ketat, sehingga node-node yang bertanggung jawab atas voting dan verifikasi secara ketat memeriksa blok yang disubmit oleh Builder; jika ditemukan Builder melanggar daftar inklusif yang diintegrasikan oleh komite, seluruh jaringan akan langsung menolak untuk memberikan voting pada blok tersebut.

Ini berarti blok yang melanggar peraturan akan langsung dianggap tidak valid oleh protokol, dan Builder akan menanggung biaya kegagalan blok yang sangat besar.

2. FairFIL: Tidak hanya memperbaiki kekurangan, tetapi juga memastikan kekurangan tersebut dapat diverifikasi

Jika FOCIL secara paksa melarang sensor melalui aturan konsensus, maka FairFIL (Fair Forward Inclusion Lists) dan mekanisme akuntabilitas membuat tindakan sensor menjadi sangat mahal dan tidak berkelanjutan dari sudut pandang ekonomi.

Secara sederhana, ia menuntut persyaratan lebih lanjut, misalnya mengapa sebuah transaksi tidak masuk ke blok, sebaiknya meninggalkan catatan yang dapat diperiksa secara publik.

Dalam operasi jaringan nyata, Builder mungkin memerlukan periode penundaan sangat singkat untuk mengoptimalkan urutan transaksi dan arbitrase MEV; FairFIL memungkinkan Builder melakukan penyesuaian fleksibel di bawah batasan tertentu, tetapi jika Builder mencoba melanjutkan perilaku sensoris ke blok berikutnya, protokol akan segera memicu proses akuntabilitas.

Logikanya secara umum dapat dipahami dalam tiga langkah.

• Pertama, protokol akan menetapkan seperangkat aturan referensi publik dan dapat diverifikasi untuk menentukan transaksi mana di kolam transaksi publik yang secara normal memenuhi syarat untuk dimasukkan ke dalam blok saat ini; jika beberapa transaksi yang seharusnya memenuhi syarat berdasarkan aturan referensi akhirnya tidak diproses, Builder harus mempublikasikannya dalam FairFIL;
• Selanjutnya, validator akan memeriksa apakah daftar ini lengkap; jika Builder jelas melewatkan transaksi yang memenuhi syarat tetapi tidak memasukkannya ke dalam daftar, tindakan ini dapat terdeteksi dan memengaruhi apakah node validator akan mendukung blok tersebut;
• Terakhir, transaksi valid di FairFIL akan menjadi tugas yang harus diprioritaskan oleh blok berikutnya, pembangun berikutnya masih dapat menentukan posisi spesifiknya dalam blok, tetapi tidak dapat lagi berpura-pura tidak melihatnya;

Jika sebuah transaksi terus-menerus dilewati, blok terkait mungkin kehilangan dukungan dari validator, dan Builder juga berisiko kehilangan seluruh pendapatan blok.

Dengan kata lain, "akuntabilitas" yang ditekankan oleh FairFIL sebenarnya dicapai melalui penerapan hukuman ekonomi bertingkat, di mana Builder yang terus-menerus ditinjau karena transaksi dapat menghadapi risiko kehilangan seluruh hadiah blok, bahkan kehilangan jaminan staking.

Ini juga merupakan arah pengembangan mekanisme anti-sensorship Ethereum, yang bertujuan untuk membangun serangkaian batasan yang lebih realistis, sehingga bahkan jika sejumlah kecil peserta memiliki niat sensor, sulit untuk mengendalikan akses transaksi dalam jangka panjang; bahkan jika seseorang sengaja melewatkan transaksi, mereka harus meninggalkan jejak dan membayar harga yang semakin tinggi untuk sensor berkelanjutan.

Bagi pengguna biasa yang setiap hari mentransfer, menukar, atau menggunakan DeFi melalui dompet, mekanisme dasar ini tidak perlu mengubah kebiasaan operasional mereka, bahkan jika diimplementasikan di masa depan.

Pengguna tetap mengisi jumlah di dompet, mengonfirmasi Gas, menyelesaikan tanda tangan, lalu menunggu transaksi masuk ke rantai, tetapi di lapisan protokol yang tak terlihat, logika apakah transaksi dapat masuk ke blok mungkin mengalami perubahan penting.

Yang benar-benar ditingkatkan adalah kepastian proses pencantuman perdagangan.

• Pertama, sebuah transaksi yang memenuhi aturan tidak lagi sepenuhnya bergantung pada pilihan Builder tertentu: bahkan jika Builder saat ini tidak bersedia memprosesnya, validator lain dapat menetapkan persyaratan inklusi pada tingkat protokol melalui daftar inklusi;
• Selanjutnya, hak transaksi dan hak urutan transaksi mungkin secara bertahap terpisah: Builder tetap dapat memanfaatkan algoritma profesional untuk mengatur urutan transaksi, meningkatkan keuntungan blok, dan tetap bersaing dalam arbitrase dan likuidasi, tetapi kekuasaannya untuk menentukan "siapa yang berhak masuk ke pasar" akan dibatasi;

Lebih jauh lagi, netralitas tepercaya Ethereum juga bisa berubah dari sebuah nilai yang bergantung pada komitmen peserta menjadi aturan protokol yang dieksekusi secara otomatis oleh klien.

Pengguna tidak perlu mengetahui Builder mana yang membangun blok saat ini, dan tidak perlu secara individu mempercayai bahwa Builder-builder ini akan secara aktif tetap netral; node verifikasi akan memeriksa blok sesuai aturan yang sama, sehingga blok yang melanggar kewajiban pencantuman sulit mendapatkan pengakuan dari jaringan.

Di masa depan, dompet dan block explorer bahkan mungkin menyediakan status transaksi yang lebih rinci berdasarkan ini.

Sebuah transaksi tidak lagi hanya ditampilkan secara umum sebagai «sedang diproses», tetapi juga dapat memberi tahu pengguna apakah transaksi tersebut telah masuk ke dalam daftar, apakah telah mendapatkan kewajiban untuk dimasukkan ke dalam blok berikutnya, serta alasan pasti mengapa masih menunggu—apakah karena gas tidak cukup, transaksi sudah kedaluwarsa, atau terjadi gangguan pada proses pembuatan blok.

Namun, mekanisme anti-sensorship tidak berarti setiap transaksi akan berhasil segera.

Transaksi yang gagal karena saldo tidak mencukupi, konflik Nonce, gas terlalu rendah, atau syarat eksekusi kontrak sudah kedaluwarsa, tetap mungkin tidak masuk ke blok. Saat jaringan ramai atau ruang blok tidak mencukupi, pengguna masih perlu menunggu konfirmasi melalui persaingan biaya.

Namun, yang secara utama diperbaiki adalah transaksi yang awalnya valid, memiliki biaya wajar, dan telah tersebar ke pool transaksi publik, seharusnya tidak ditunda tanpa batas waktu karena pilihan subjektif dari sejumlah kecil pembangun blok.

Dari perkembangannya, hingga Agustus 2026, EIP-7805 yang terkait dengan FOCIL masih berstatus Draft, namun telah dipilih oleh pengembang inti Ethereum sebagai Headliner lapisan konsensus untuk upgrade Hegotá dan memasuki tahap Scheduled for Inclusion, yang berarti tim klien telah setuju untuk memajukan implementasi dan pengembangan pengujian jaringan di sekitarnya, tetapi waktu peluncuran resmi di mainnet belum ditentukan secara pasti.

FairFIL lebih awal, saat ini primarily merupakan rencana penelitian yang akan dirilis pada Juli 2026, dan apakah akan dimasukkan ke dalam roadmap Ethereum masih memerlukan diskusi yang lebih luas, implementasi, serta verifikasi keamanan.

Secara objektif, Ethereum tidak dapat menjamin setiap Builder, validator, dan operator infrastruktur akan selalu tetap netral.

Peserta mungkin mengalami tekanan regulasi, mengejar kepentingan pribadi, atau menerima insentif eksternal; jaringan terdesentralisasi yang benar-benar tangguh tidak dapat dibangun atas asumsi ideal bahwa semua orang akan melakukan hal yang benar.

Pemeriksaan yang benar-benar tahan terhadap sensor adalah ketika, meskipun sebagian peserta mencoba mengganggu transaksi, peserta lain tetap mampu memecahkan kendali tersebut; bahkan jika seseorang memilih menyimpang dari prinsip netralitas, protokol akan membuat perilaku tersebut terlihat, mahal, dan sulit dipertahankan.

Dari daftar awal yang berisi, hingga FOCIL yang mengatur Builder secara kolektif oleh komite terdistribusi, hingga FairFIL yang menuntut bahwa perilaku pengabaian dapat diverifikasi secara publik, dari memungkinkan siapa pun mengirim transaksi, hingga menjamin bahwa transaksi siapa pun memiliki kesempatan untuk dilihat.

Dari sudut pandang ini, Ethereum memang sedang berusaha mewujudkan janji ini, langkah demi langkah, ke dalam protokol itu sendiri.

Patut ditunggu.