Jalan Ethereum Menuju Perlawanan terhadap Sensor: BRAID vs FOCIL

Dalam lanskap Ethereum yang terus berkembang, pertempuran untuk melawan sensor telah memperkenalkan beberapa mekanisme inovatif. Di antaranya, BRAID dan FOCIL menonjol sebagai dua pendekatan yang menjanjikan yang dirancang untuk melindungi integritas jaringan dengan meminimalkan risiko penyensoran transaksi.

Kedua solusi ini membahas masalah-masalah penting dalam proses pengusulan blok, tetapi mengambil pendekatan yang berbeda secara fundamental untuk mencapai tujuan mereka. Artikel ini membahas perbedaan dari kedua mekanisme tersebut dan mengeksplorasi mana yang pada akhirnya terbukti lebih efektif.

Memahami Ancaman Penyensoran di Ethereum

Inti dari proses pembuatan dan validasi blok Ethereum adalah dua aktor utama: pembuat dan pengusul. Pembangun bertanggung jawab untuk menyortir transaksi dan mengirimkan blok ke pengusul, yang kemudian memilih satu blok untuk ditandatangani dan diajukan ke blockchain.

Akan tetapi, proses ini menciptakan sebuah kerentanan yang potensial. Karena pengusul memiliki keputusan akhir dalam menentukan blok mana yang akan diusulkan, ada risiko kolusi antara pengusul dan pembangun untuk menyensor transaksi tertentu, sehingga mengancam prinsip resistensi sensor Ethereum.

Resistensi terhadap sensor sangat penting untuk menjaga keadilan dan transparansi blockchain. Jika pengusul dapat secara selektif memasukkan atau mengeluarkan transaksi, hal ini akan merusak sifat terdesentralisasi dari jaringan dan dapat menyebabkan eksploitasi pemesanan transaksi, yang mengakibatkan masalah seperti Miner Extractable Value (MEV).

Solusi yang ada: MCP dan FOCIL

Untuk mengatasi tantangan ini, beberapa solusi tahan sensor telah diusulkan, dengan dua di antaranya yang paling banyak dibahas adalah mekanisme Daftar Penyertaan Paksa (FOCIL) dan Multi-Pengusul Bersamaan (MCP).

Daftar Penyertaan Paksa (FOCIL)

FOCIL dirancang untuk memastikan keadilan dengan melibatkan komite validator yang dipilih secara acak pada setiap slot waktu.

Para validator ini membuat daftar inklusi lokal berdasarkan pandangan mereka tentang mempool dan menyiarkan daftar ini.

Pengusul kemudian menggabungkan daftar lokal ini ke dalam daftar inklusi akhir yang ditambahkan ke dalam blok.

Mekanisme ini memastikan bahwa tidak ada satu pengusul pun yang memiliki kontrol penuh atas transaksi yang termasuk dalam blok, sehingga mengurangi risiko penyensoran.

Validator memverifikasi bahwa blok tersebut mematuhi aturan konsensus sebelum menerimanya ke dalam blockchain.

Pengusul Rangkap Jabatan (MCP)

MCP memperkenalkan konsep beberapa pengusul bersamaan, seperti yang pertama kali disarankan oleh Max Resnick dalam mekanisme Multiplicity.

Dalam sistem ini, beberapa pengusul bekerja secara paralel, masing-masing memilih sebagian transaksi dari mempool.

Transaksi-transaksi ini dikemas ke dalam “paket transaksi khusus” dan ditandatangani oleh para pengusul. Pengusul utama harus menyertakan setidaknya dua pertiga dari bundel ini dalam blok yang diusulkan agar dapat dianggap sah.

Metode ini mendesentralisasi kekuatan satu pengusul dan secara signifikan menurunkan kemungkinan sensor transaksi.

KEPANG: Implementasi MCP yang Disempurnakan

Berdasarkan konsep MCP, Max Resnick mengembangkan lebih lanjut BRAID, implementasi MCP yang lebih canggih dan lengkap.

Diperkenalkan selama seminar “DeFi di Era MEV” yang diselenggarakan oleh Paradigm, BRAID memungkinkan beberapa pengusul untuk mengajukan blok pada rantai paralel yang berbeda secara bersamaan.

Blok-blok ini kemudian disinkronkan melalui mekanisme konsensus untuk memastikan konsistensi di seluruh rantai.

Lapisan eksekusi Ethereum mengkonsolidasikan semua blok yang dihasilkan dalam slot ke dalam blok eksekusi tunggal, di mana transaksi diduplikasi, dipesan, dan dieksekusi sesuai dengan aturan yang telah ditentukan.

Pendekatan ini secara signifikan mengurangi kekuatan entitas tunggal untuk memanipulasi catatan transaksi.

Keuntungan utama dari BRAID adalah penghindaran peran tambahan atau struktur insentif yang rumit, yang dapat menambah kerumitan.

Namun, mengoordinasikan sinkronisasi di beberapa sub-rantai dan menangani pemrosesan data menimbulkan tantangan tersendiri.

Tantangan dan Pertimbangan dalam BRAID

Terlepas dari kekuatannya, BRAID bukannya tanpa masalah. Salah satu tantangan penting adalah model “tip bersyarat”, yang mengharuskan pengguna memiliki likuiditas yang tersedia untuk memastikan transaksi mereka tahan terhadap sensor. Pengguna harus menetapkan dua nilai tip saat mengirimkan transaksi:

1. Ujung Lebih Tinggi (T): Jumlah maksimum yang bersedia dibayarkan oleh pengguna untuk memastikan transaksi mereka disertakan meskipun ada upaya penyensoran. Jika hanya satu pengusul yang menyertakan transaksi, mereka akan menerima jumlah penuh T.
2. Ujung Bawah (t): Tip yang lebih kecil yang dibayarkan jika beberapa pengusul menyertakan transaksi. Dalam hal ini, tip didistribusikan di antara para pengusul yang menyertakan transaksi.

Model ini, meskipun efektif dalam mencegah penyensoran, namun menimbulkan kerumitan dan biaya tambahan bagi pengguna. Mereka perlu mencadangkan likuiditas ekstra pada saat transaksi, yang dapat dibekukan sampai ditentukan apakah likuiditas tersebut akan dibutuhkan.

Untuk mengatasi masalah ini, Jonahb dari Blockchain Capital menyarankan dua solusi potensial:

• Bukti Likuiditas Pasca-Pemerintah: Pendekatan ini memungkinkan pengguna untuk memberikan bukti bahwa mereka akan memiliki likuiditas yang cukup untuk membayar tip yang lebih tinggi setelah transaksi dieksekusi. Namun, hal ini mengharuskan pengusul untuk memahami kondisi pasca-transaksi, yang menjadi tantangan dalam transaksi yang melibatkan negara bagian atau operasi keuangan yang kompleks.
• Asuransi Penyensoran: Konsep ini memperkenalkan penyedia Asuransi Penyensoran (CI) pihak ketiga yang menjamin tip pengguna dengan imbalan biaya. Hal ini mengurangi beban likuiditas langsung pada pengguna, tetapi membutuhkan pengembangan pasar antara pengguna dan penyedia CI.

Perspektif Masyarakat: FOCIL vs BRAID

Komunitas Ethereum terbagi atas manfaat relatif FOCIL dan BRAID. Terence, seorang pengembang untuk klien Ethereum Prysm, menghargai bahwa BRAID tidak membutuhkan peserta tambahan, menyederhanakan prosesnya dibandingkan dengan FOCIL, yang memperkenalkan batasan waktu tambahan untuk mengirimkan dan memverifikasi daftar inklusi. Namun, FOCIL secara umum dianggap lebih mudah diterapkan dan lebih fleksibel.

Dan Robinson, seorang peneliti di Paradigm, memuji BRAID atas pendekatannya untuk memprioritaskan transaksi, yang secara efektif mengurangi risiko MEV. Dia juga menyoroti mekanisme tip bersyarat sebagai insentif yang kuat untuk melawan penyensoran – aspek yang tidak dimiliki oleh FOCIL.

Sebaliknya, pengembang Dev menyukai FOCIL karena kesederhanaan dan ketahanan sensor yang kuat, menunjukkan bahwa FOCIL menawarkan implementasi yang lebih mudah dengan lebih sedikit komplikasi.

Peneliti Ethereum barnabe.eth mengakui bahwa meskipun BRAID dapat menawarkan peningkatan di bidang-bidang tertentu, ia berhati-hati untuk sepenuhnya meninggalkan model berbasis pemimpin yang menjadi dasar dari FOCIL dan desain IL lainnya, dengan alasan perlunya penelitian lebih lanjut dan bukti untuk memvalidasi kelayakan BRAID.

Kesimpulan: Mekanisme Mana yang Lebih Unggul?

Perdebatan antara BRAID dan FOCIL menggarisbawahi kompleksitas untuk mencapai resistensi sensor di Ethereum. Pendekatan inovatif BRAID untuk mendesentralisasi kekuatan pengusul dan mengurangi risiko MEV sangat menarik, namun memiliki tantangan implementasi yang signifikan dan membutuhkan pengembangan lebih lanjut.

FOCIL, meskipun lebih sederhana dan lebih fleksibel, mungkin tidak menawarkan tingkat ketahanan yang sama terhadap upaya penyensoran yang canggih.

Pada akhirnya, pilihan antara BRAID dan FOCIL dapat bergantung pada prioritas spesifik jaringan Ethereum pada waktu tertentu. Seiring dengan ekosistem yang terus berkembang, kedua mekanisme tersebut dapat berperan dalam memperkuat ketahanan Ethereum terhadap sensor, memastikan bahwa jaringan tetap setia pada prinsip-prinsip desentralisasi.