Di dunia blockchain, kita sering mendengar sebuah kata: 'anti-sensor'.
Banyak orang mungkin merasa itu terdengar seperti slogan yang terkesan politis, bahkan bernada anarkis. Tapi bagi jaringan penyelesaian global seperti Ethereum, anti-sensor pertama-tama bukanlah posisi politik, melainkan kemampuan teknis yang sangat konkret.
Bayangkan, Anda mengirim transaksi di dompet imToken.
Tanda tangan benar, saldo akun cukup, biaya Gas juga tidak rendah, tetapi transaksi tersebut lama tidak tertulis ke dalam blok, status di dompet tetap di "Pending". Sementara itu, transaksi lain dengan biaya yang mirip atau bahkan lebih rendah terus masuk ke chain.
Pada titik ini, masalahnya menjadi siapa yang berhak menentukan apakah sebuah transaksi dapat masuk ke dalam blok? Bagaimanapun juga, jika Ethereum pada akhirnya masih memerlukan beberapa partisipan terpusat untuk memutuskan transaksi mana yang bisa masuk chain, maka tidak ada perbedaan mendasar dengan sistem keuangan tradisional.
Oleh karena itu, Ethereum dalam beberapa tahun terakhir mengeksplorasi serangkaian mekanisme anti-sensor seperti FOCIL, FairFIL, untuk menjawab pertanyaan yang tampak sederhana namun sebenarnya sangat krusial: bagaimana memastikan setiap transaksi yang mematuhi aturan protokol memiliki kesempatan yang adil untuk masuk ke dalam blok?
I. Dari Mana Sebenarnya "Sensor" Itu Berasal?
Untuk memahami mengapa Ethereum memerlukan mekanisme ini, pertama-tama kita perlu memahami apa yang dialami sebuah transaksi setelah dikirim dari dompet.
Saat pengguna menandatangani dan mengirim transaksi di dompet, transaksi itu biasanya akan masuk ke kolam transaksi publik Ethereum terlebih dahulu, yaitu mempool (memory pool), yang lebih seperti area tunggu, berisi banyak transaksi yang belum ditulis ke dalam blok.
Tapi masuk ke area tunggu, tidak berarti transaksi sudah masuk chain. Masih perlu ada yang memilih transaksi dari sana, menentukan urutannya, menyusunnya menjadi blok utuh, lalu menyerahkannya ke jaringan untuk dikonfirmasi.
Masalah pun muncul pada tahap ini.
Setelah Ethereum beralih ke mekanisme PoS (Proof-of-Stake), untuk mencegah pool staking besar membentuk monopoli ekonomi dengan memanfaatkan MEV (Maximal Extractable Value), Ethereum memperkenalkan sistem PBS (Proposer-Builder Separation, Pemisahan Proposer dan Builder). Dalam arsitektur ini, alur pemrosesan setiap transaksi Ethereum sebenarnya dibagi menjadi dua peran:
- Builder: Bertanggung jawab mengumpulkan transaksi, mengatur urutan transaksi, mencari peluang arbitrase dan likuidasi, serta membangun blok dengan pendapatan setinggi mungkin;
- Proposer: Bertanggung jawab memilih satu dari blok kandidat yang diajukan Builder, dan mengajukannya ke jaringan;
Pembagian kerja ini memiliki keuntungan yang sangat realistis.
Seperti diketahui, strategi MEV dalam beberapa tahun terakhir semakin kompleks. Jika setiap validator biasa diminta untuk menyelesaikan sendiri pengurutan transaksi dan optimasi blok, maka itu jelas akan memberikan keuntungan kepada node besar yang memiliki lebih banyak modal, data, dan kemampuan teknis.
Jadi, dengan menyerahkan pekerjaan pembangunan blok yang kompleks kepada Builder profesional, node validator biasa meski tidak memiliki kemampuan arbitrase tingkat lanjut, masih dapat berpartisipasi dalam pengajuan blok dan mendapatkan keuntungan yang sesuai, sehingga mengurangi dampak MEV terhadap desentralisasi staking.
Namun, tanpa disengaja hal ini juga membawa efek samping lain, yaitu konsentrasi berlebihan dari hak pembangunan blok. Misalnya, saat ini lebih dari 90% blok Ethereum di seluruh jaringan diproduksi hanya oleh beberapa Builder profesional. Dan karena Builder ini biasanya memiliki latar belakang operasional entitas yang jelas, mereka sangat mudah terkena tekanan eksternal dari kepatuhan hukum di negara atau wilayah tertentu (misalnya daftar sanksi OFAC), sehingga sebenarnya telah menimbulkan risiko sentralisasi.
Oleh karena itu, begitu beberapa Builder utama ini secara selektif menyaring transaksi tertentu dari kontrak sensitif (seperti Tornado Cash) atau alamat tertentu, transaksi-transaksi tersebut akan terjebak dalam kesulitan tidak bisa dikemas dalam waktu lama, bahkan menghadapi risiko "diblokir secara terselubung".
Kesimpulannya, bagi pengguna biasa, Ethereum adalah jaringan terbuka yang dapat dihubungi, digunakan untuk transfer, dan memanggil kontrak pintar oleh siapa saja. Tapi dari sudut pandang operasi protokol, mengirim transaksi hanyalah langkah pertama. Apakah transaksi benar-benar berlaku, masih bergantung pada apakah transaksi itu dipilih, diurutkan, dan ditulis ke dalam blok oleh seorang pembangun blok.
Oleh karena itu, "anti-sensor" yang dibahas Ethereum, bukan hanya konsep besar yang terkait dengan politik, regulasi, atau sanksi. Pertama-tama, ini adalah masalah teknis yang sangat konkret:
Ketika sebuah transaksi memenuhi aturan protokol, dapatkah jaringan menjamin bahwa transaksi itu mendapat kesempatan masuk ke dalam blok dalam waktu yang wajar?
II. Dari FOCIL ke FairFIL: Bagaimana Ethereum Membatasi Builder Blok
Sebenarnya setelah membahas sampai di sini, masalahnya sudah cukup jelas. Builder dapat meningkatkan efisiensi pembangunan blok, tetapi jika hak pemasukan transaksi juga terkonsentrasi di tangan sedikit Builder dalam jangka panjang, Ethereum akan membentuk risiko monopoli sentralisasi baru.
Untuk itu, peneliti Ethereum mengusulkan Inclusion Lists, yang biasa disebut "daftar inklusi".
Nama ini terdengar agak abstrak, tetapi logika intinya tidak rumit — Builder masih bertanggung jawab membuat blok, tetapi tidak bisa memutuskan sendiri kelangsungan semua transaksi. Node validator yang berpartisipasi normal dalam staking Ethereum juga perlu mempertahankan sebagian kekuasaan, memungkinkan mereka untuk membuat daftar transaksi yang harus diproses.
Ambil stasiun bus sebagai contoh. Sebuah blok dapat dipahami sebagai satu kali perjalanan bus dengan kursi terbatas.
Builder memutuskan bagaimana sebagian besar penumpang mengantri, duduk di posisi mana, untuk meningkatkan pendapatan seluruh bus dengan pengaturan yang lebih efisien; namun node validator juga dapat menyerahkan daftar "penumpang yang harus naik". Selama transaksi dalam daftar tersebut masih valid, bersedia membayar biaya yang wajar, dan blok masih memiliki ruang yang cukup, Builder tidak bisa terus menolaknya hanya berdasarkan preferensi pribadi.
Namun, siapa yang membuat daftar inklusi, dan apa yang harus dilakukan jika ada yang sengaja menghilangkan transaksi, masih menjadi dua masalah yang perlu diselesaikan.
FOCIL dan FairFIL, adalah pengembangan ke dua arah ini.
1. FOCIL: Tidak Lagi Membiarkan Satu Proposer Sendiri Membuat Daftar Inklusi
FOCIL (Fork-Choice Enforced Inclusion Lists) memindahkan kekuasaan untuk memutuskan apakah suatu transaksi harus dimasukkan, dari satu proposer tunggal ke "komite node validator" yang terdiri dari banyak pihak.
Dalam setiap siklus pembuatan blok, jaringan akan secara acak memilih sekelompok node validator untuk membentuk komite sementara. Setiap anggota dalam komite akan mengamati mempool jaringan secara independen, dan masing-masing mengirimkan daftar inklusi lokal mereka.
Ini berarti meskipun 99% Builder dan proposer di seluruh jaringan berusaha mensensor transaksi tertentu, selama ada 1 node jujur dalam komite yang memasukkan transaksi itu ke dalam daftar, transaksi tersebut berkesempatan masuk ke dalam batasan protokol. Jika sensor ingin terus mengesampingkannya, mereka tidak lagi hanya perlu melewati satu orang, tetapi harus melewati beberapa partisipan independen sekaligus.
Jadi keunggulannya adalah, tidak perlu percaya bahwa setiap orang dalam komite akan tetap netral.
Tapi hanya daftar saja tidak cukup. Jika Builder menerima daftar namun tetap memilih untuk tidak mengeksekusi, daftar inklusi akan menjadi saran tanpa daya ikat.
Oleh karena itu, FOCIL menambahkan desain lapisan kedua, memperkenalkan aturan pemilihan percabangan (Fork-Choice Rule) sebagai batasan keras, sehingga node di seluruh jaringan yang bertugas memverifikasi suara akan memeriksa blok yang diajukan Builder secara ketat. Begitu ditemukan Builder berani melanggar daftar inklusi terintegrasi komite, seluruh jaringan akan langsung menolak memberikan suara untuk blok tersebut.
Ini berarti blok yang melanggar akan langsung dinyatakan sebagai blok tidak valid oleh protokol, dan Builder akan membayar harga mahal karena kegagalan pembuatan blok.
2. FairFIL: Tidak Hanya Menambal Kebocoran, Tetapi Juga Membuat Kelalaian Dapat Diperiksa
Jika FOCIL adalah larangan sensor yang keras dari aturan konsensus, maka FairFIL (Fair Forward Inclusion Lists) dan mekanisme akuntabilitas adalah dari sudut pandang ekonomi, membuat perilaku sensor menjadi sangat mahal dan tidak berkelanjutan.
Intinya, FairFIL mengajukan persyaratan yang lebih jauh, misalnya mengapa sebuah transaksi tidak masuk ke dalam blok, harus sebisa mungkin meninggalkan catatan yang dapat diperiksa secara publik.
Dalam operasi jaringan aktual, Builder mungkin memerlukan buffer yang sangat singkat untuk mengoptimalkan pengurutan transaksi dan arbitrase MEV. FairFIL mengizinkan Builder melakukan penyesuaian fleksibilitas di bawah batasan tertentu. Namun jika Builder mencoba melanjutkan perilaku sensor tertentu ke blok berikutnya, protokol akan segera memulai prosedur akuntabilitas.
Logika dasarnya dapat dipahami dalam tiga langkah.
- Pertama, protokol akan menetapkan serangkaian aturan referensi yang publik dan dapat diverifikasi, untuk menilai transaksi mana di mempool publik yang dalam kondisi normal memenuhi syarat untuk masuk ke blok saat ini. Jika beberapa transaksi yang seharusnya memenuhi syarat masuk blok menurut aturan referensi akhirnya tidak diproses, Builder perlu mencantumkannya secara terbuka di FairFIL;
- Kemudian, validator akan memeriksa apakah daftar ini lengkap. Jika Builder jelas-jelas menghilangkan transaksi yang memenuhi syarat, tetapi tidak menuliskannya ke dalam daftar, maka perilaku ini mungkin terdeteksi, dan memengaruhi apakah node validator mendukung blok tersebut;
- Terakhir, transaksi valid yang masuk ke FairFIL, akan menjadi tugas yang harus diprioritaskan untuk diproses oleh blok berikutnya. Builder berikutnya masih dapat mengatur posisi spesifiknya dalam blok, tetapi tidak dapat terus bersikap tidak melihatnya;
Jika sebuah transaksi terus-menerus dihilangkan, blok terkait mungkin kehilangan dukungan validator, dan Builder juga mungkin kehilangan seluruh keuntungan blok karenanya.
Dengan kata lain, "akuntabilitas" yang ditekankan FairFIL, sebenarnya adalah dengan memperkenalkan hukuman ekonomi bertahap, Builder yang terus-menerus mensensor transaksi akan menghadapi risiko kehilangan seluruh hadiah blok, bahkan menghadapi risiko pemotongan deposit staking mereka.
Ini juga merupakan arah mekanisme anti-sensor Ethereum yang semakin mendalam, bertujuan membangun serangkaian batasan yang lebih realistis. Meskipun ada beberapa partisipan dengan niat sensor, sulit bagi mereka untuk mengontrol pintu masuk transaksi dalam jangka panjang; meskipun ada yang sengaja menghilangkan transaksi, mereka perlu meninggalkan jejak, dan membayar harga yang semakin tinggi untuk sensor yang berkelanjutan.
III. Apa Artinya Ini bagi Pengguna Biasa?
Bagi pengguna biasa yang setiap hari melakukan transfer, pertukaran, atau menggunakan DeFi melalui dompet, mekanisme dasar ini bahkan jika diimplementasikan di masa depan, tidak perlu mengubah kebiasaan operasional yang ada.
Pengguna tetap mengisi jumlah, mengonfirmasi Gas, menyelesaikan tanda tangan di dompet, lalu menunggu transaksi masuk chain. Namun di lapisan dasar protokol yang tidak terlihat, logika apakah transaksi dapat masuk blok mungkin mengalami perubahan penting.
Yang benar-benar diperbaiki adalah kepastian proses inklusi transaksi.
- Pertama, sebuah transaksi yang mematuhi aturan, tidak lagi sepenuhnya bergantung pada pilihan Builder tertentu: Meskipun Builder saat ini tidak ingin memprosesnya, validator lain dapat melalui daftar inklusi, membangun persyaratan inklusi tingkat protokol untuknya;
- Kedua, hak inklusi transaksi dan hak pengurutan transaksi mungkin perlahan-lahan terpisah: Builder masih dapat menggunakan algoritma profesional untuk mengatur urutan transaksi, meningkatkan pendapatan blok, dan masih dapat bersaing di sekitar arbitrase dan likuidasi, tetapi kekuasaannya untuk memutuskan "siapa yang berhak masuk ke pasar" akan dibatasi;
Lebih jauh lagi, netralitas terpercaya Ethereum, mungkin perlahan berubah dari proposisi nilai yang bergantung pada komitmen partisipan, menjadi aturan protokol yang dieksekusi secara otomatis oleh klien.
Pengguna tidak perlu tahu blok saat ini dibangun oleh Builder mana, juga tidak perlu mempercayai satu per satu bahwa Builder ini akan tetap netral secara aktif. Node validator akan memeriksa blok sesuai aturan yang sama, membuat blok yang melanggar kewajiban inklusi sulit mendapat pengakuan jaringan.
Di masa depan, dompet dan penjelajah blok bahkan mungkin menyediakan status transaksi yang lebih detail berdasarkan hal ini.
Sebuah transaksi tidak lagi hanya ditampilkan secara umum sebagai "sedang diproses", tetapi mungkin lebih lanjut memberi tahu pengguna, apakah transaksi itu sudah masuk daftar inklusi, apakah sudah mendapat kewajiban inklusi dari blok berikutnya, serta apakah menunggu terus karena Gas tidak cukup, transaksi sudah tidak berlaku, atau ada anomali di tahap pembangunan blok.
Namun, mekanisme anti-sensor tidak berarti setiap transaksi bisa langsung berhasil.
Transaksi dengan saldo tidak cukup, konflik Nonce, Gas terlalu rendah, atau kondisi eksekusi kontrak sudah tidak berlaku, masih mungkin tidak bisa masuk ke blok. Ketika jaringan padat, ruang blok tidak cukup, pengguna masih perlu menunggu konfirmasi dengan bersaing melalui biaya.
Tapi mekanisme ini terutama memperbaiki bahwa transaksi yang awalnya valid, biayanya wajar, dan sudah menyebar ke mempool publik, seharusnya tidak ditunda tanpa batas waktu hanya karena pilihan subjektif dari sedikit pembangun blok.
Dari sisi kemajuan, hingga Agustus 2026, EIP-7805 yang sesuai dengan FOCIL masih dalam status Draft. Namun, EIP tersebut telah dipilih oleh pengembang inti Ethereum sebagai Headliner lapisan konsensus untuk peningkatan Hegotá, dan masuk tahap Scheduled for Inclusion, yang berarti tim klien telah setuju untuk melanjutkan implementasi dan pengembangan pengujian jaringan di sekitarnya, tetapi waktu peluncuran mainnet spesifik masih belum ditentukan secara final.
FairFIL bahkan lebih awal, saat ini terutama merupakan skema penelitian yang dirilis pada Juli 2026. Apakah di masa depan akan masuk ke peta jalan Ethereum, masih perlu melalui diskusi, implementasi, dan verifikasi keamanan yang lebih luas.
Ditulis di Akhir
Secara objektif, Ethereum tidak mungkin menjamin setiap Builder, validator, dan operator infrastruktur akan tetap netral selamanya.
Partisipan mungkin terkena tekanan regulasi, mungkin mengejar kepentingan sendiri, mungkin juga menerima insentif eksternal. Sebuah jaringan terdesentralisasi yang benar-benar tangguh, tidak dapat dibangun di atas asumsi ideal "semua orang akan melakukan hal yang benar".
Anti-sensor yang sesungguhnya adalah, meskipun sebagian partisipan berusaha mengintervensi transaksi, partisipan lain masih memiliki kemampuan untuk memecah kendali ini; meskipun ada yang memilih menyimpang dari prinsip netral, protokol dapat membuat perilaku ini terlihat, mahal, dan sulit berkelanjutan.
Dari daftar inklusi awal, ke FOCIL yang membatasi Builder secara bersama oleh komite terdistribusi, hingga FairFIL yang menuntut perilaku kelalaian dapat diperiksa secara publik. Dari mengizinkan siapa pun mengirim transaksi, hingga menjamin transaksi siapa pun memiliki kesempatan untuk dilihat.
Dari sudut pandang ini, Ethereum memang sedang mencoba menulis janji ini, dari sebuah deklarasi nilai, langkah demi langkah, ke dalam protokol itu sendiri.
Layak dinantikan.
