Dalam proses produksi dan validasi blok Ethereum, pembangun bertanggung jawab untuk memesan transaksi dan mengirimkan blok ke para penyaji melalui mekanisme lelang. Para penyaji kemudian memilih blok untuk ditandatangani dan mengusulkannya ke blockchain. Karena para penyaji memiliki keputusan akhir sebagai entitas tunggal, ada risiko kolusi antara penyaji dan pembangun untuk menyensor transaksi.

Salah satu nilai inti dari blockchain adalah ketahanan sensor, yang berarti transaksi dapat dilakukan tanpa gangguan dari otoritas pusat. Ketika penentu mengendalikan transaksi yang disertakan dalam blok, fitur ini terancam, mengorbankan keadilan dan transparansi. Selain itu, kekuatan ini dapat dieksploitasi untuk memanipulasi urutan transaksi dalam blok, menyebabkan keuntungan ekonomi tambahan dan menimbulkan masalah terkait Nilai Ekstraksi Penambang (MEV).

Solusi yang sudah ada untuk resistensi terhadap sensor

Untuk mengatasi tantangan ini, komunitas telah mengusulkan beberapa solusi anti-sensorship, seperti Daftar Inklusi Paksa ( FOCIL). Dalam mekanisme FOCIL, seperangkat validator secara acak dipilih untuk setiap slot untuk membentuk komite daftar inklusi. Anggota komite ini menghasilkan daftar inklusi lokal berdasarkan pandangan subjektif mereka terhadap mempool dan menyiarkannya. Para penawar kemudian bertanggung jawab untuk mengumpulkan dan menggabungkan daftar lokal ini menjadi daftar gabungan tunggal yang akan disertakan dalam blok. Mekanisme ini memastikan keadilan dalam inklusi blok karena validator memverifikasi daftar gabungan terhadap daftar lokal yang disiarkan sebelumnya, dan hanya blok yang memenuhi aturan konsensus diterima dan ditambahkan ke blockchain.

Selain FOCIL, komunitas juga telah membahas skema Multiple Concurrent Proposers (MCP). Konsep ini awalnya diusulkan oleh Max ResnickdalamKelipatan mekanisme, yang bertujuan untuk membubarkan kekuasaan dengan memperkenalkan beberapa pengusul blok paralel, mengurangi kemampuan setiap node tunggal untuk menyensor transaksi. Dalam mekanisme Multiplisitas, setiap validator memilih sebagian transaksi dari mempool mereka sendiri untuk membentuk "paket transaksi khusus." Validator ini menandatangani paket transaksi pilihan mereka dan mengirimkannya ke pengusul putaran saat ini. Pengusul harus menyertakan setidaknya 2/3 dari paket transaksi ini di blok yang mereka usulkan agar dianggap valid. Mekanisme ini memastikan bahwa pengusul tidak dapat secara sepihak memutuskan konten blok, sehingga mengurangi kemungkinan penyensoran. Untuk lebih memberi insentif kepada pengusul untuk memasukkan transaksi secara adil, mekanisme ini menerapkan aturan "tip bersyarat", di mana hanya pengusul yang menyertakan transaksi yang menerima biaya transaksi. Biaya transaksi tidak secara otomatis diberikan kepada pengusul pertama yang menyertakan transaksi tetapi didistribusikan kepada semua pengusul yang benar-benar menyertakan transaksi berdasarkan kondisi tertentu. Ini meningkatkan biaya penyensoran, karena menyuap semua pengusul yang menyertakan transaksi akan diperlukan.

BRAID: Implementasi MCP yang ditingkatkan

Mengembangkan konsep Multiplicity, Max Resnick memperkenalkan BRAID, implementasi MCP yang lebih kompleks dan rafinasi. Max mempersembahkan BRAIDpada seminar “DeFi di Era MEV” yang diselenggarakan oleh Paradigm. BRAID mencapai MCP dengan memungkinkan beberapa pengusul untuk mengusulkan blok pada rantai paralel yang berbeda dan menggunakan mekanisme konsensus sinkronisasi untuk mempertahankan konsistensi antara rantai-rantai ini. Setiap rantai memiliki pengusulnya sendiri, dan semua pengusul melepaskan blok mereka secara bersamaan dalam slot yang sama. Lapisan eksekusi Ethereum mengumpulkan blok yang dihasilkan oleh semua sub-rantai dalam slot tersebut, membentuk blok eksekusi. Kemudian menghilangkan duplikat, mengurutkan, dan menjalankan transaksi-transaksi ini sesuai dengan aturan yang telah ditentukan, mengurangi kemampuan entitas tunggal untuk memanipulasi catatan transaksi.

Desain BRAID menghindari memperkenalkan peran tambahan, sehingga menghindari kompleksitas yang terkait dengan mekanisme insentif/hukuman. Namun, implementasinya relatif kompleks, memerlukan koordinasi sinkronisasi dan pemrosesan data dari beberapa sub-chain.

Masalah dengan mekanisme BRAID

Jonahbtim Blockchain Capital menunjukkan bahwa masalahdengan mekanisme BRAID: model “tombol kondisional” menetapkan persyaratan likuiditas, yang memengaruhi pengalaman pengguna. Model ini adalah strategi penetapan harga dinamis yang memerlukan pengguna untuk menyediakan sejumlah likuiditas tertentu untuk memastikan ketahanan sensor transaksi. Ketika mengirimkan transaksi, pengguna harus menetapkan dua nilai tip (T dan t). Tip aktual yang dibayarkan bergantung pada jumlah pemberi proposal yang menyertakan transaksi.

1. Nilai tip yang lebih tinggi, T, mewakili biaya maksimum yang ingin dibayar pengguna untuk memastikan transaksi mereka tidak disensor. Tujuannya adalah untuk memberikan insentif kepada proposer agar memasukkan transaksi bahkan jika tidak ada proposer lain yang bersedia melakukannya. Jika hanya satu proposer yang memasukkan transaksi, mereka akan menerima jumlah penuh, T.
2. Nilai tip yang lebih rendah, t, adalah jumlah minimum yang ditetapkan oleh pengguna. Jika transaksi dimasukkan oleh beberapa penawar secara bersamaan, pengguna hanya perlu membayar t, yang akan dibagi di antara penawar. Jika pengguna kurang peduli tentang resistensi sensor, mereka dapat mengatur T sama dengan t dan mengirim transaksi mereka hanya kepada satu penawar.

Namun, persyaratan likuiditas tambahan ini meningkatkan kompleksitas dan biaya berpartisipasi dalam transaksi blockchain. Pengguna perlu menyisihkan dana ekstra pada saat transaksi semata-mata untuk memastikan ketahanannya terhadap sensor. Dana yang disisihkan ini tetap beku hingga benar-benar digunakan.

Untuk mengatasi masalah ini, Jonahb mengusulkan dua solusi:

• Bukti Likuiditas Setelah Posting-Status: Pengguna memberikan bukti pada saat pengajuan transaksi, menunjukkan bahwa mereka akan memiliki likuiditas yang cukup untuk membayar T setelah transaksi dieksekusi (misalnya, pengguna akan memiliki $1M likuiditas setelah transaksi). Metode ini memungkinkan pengguna untuk melanjutkan meskipun mereka tidak memiliki dana yang cukup untuk membayar T sebelum transaksi. Tantangannya dengan pendekatan ini adalah bahwa pengusul perlu mengetahui status akhir transaksi sebelum dieksekusi. Namun, banyak transaksi keuangan melibatkan status bersama (seperti beberapa transaksi yang memengaruhi saldo akun yang sama), sehingga sulit bagi pengusul untuk menentukan dengan akurat status setelah transaksi sebelum urutan transaksi ditetapkan. Pendekatan ini memerlukan bukti yang disesuaikan untuk setiap jenis transaksi, sehingga menjadi kurang praktis.
• Asuransi Sensorship: Memperkenalkan penyedia asuransi sensorship pihak ketiga (penyedia CI) untuk menjamin T pengguna. Pengguna membayar premi asuransi, rT, di mana r didasarkan pada kemungkinan transaksi disensor. Pendekatan ini mengurangi kebutuhan pengguna untuk segera menyiapkan sejumlah besar likuiditas dan dapat memberi peringatan kepada pengguna jika T mereka terlalu rendah dan berisiko tinggi disensor. Namun, menetapkan pasar antara pengguna dan penyedia CI membutuhkan waktu.

Pemikiran Komunitas tentang FOCIL vs. BRAID

pengembang klien Ethereum PrysmTerence catatanKeuntungan signifikan dari BRAID adalah bahwa tidak memerlukan peserta tambahan. Sebagian besar desain Daftar Inklusi (IL), termasuk FOCIL, memerlukan peserta tambahan, yang menambahkan batasan waktu dalam slot Ethereum, seperti waktu untuk mengirimkan IL, memperbarui penawaran, dan validator memeriksa IL. Namun, FOCIL lebih sederhana dan lebih fleksibel untuk diimplementasikan dibandingkan dengan BRAID.

Peneliti paradigmaDan Robinson menghargaiDesain BRAID untuk prioritas transaksi, yang tidak ditentukan oleh satu pemimpin tunggal (penyaji), sehingga secara efektif mengurangi MEV. Selain itu, mekanisme tip kondisional BRAID mendorong perilaku non-sensor, yang tidak ada di FOCIL.

PengembangDev lebih memilihFOCIL lebih disukai daripada MCP, karena FOCIL menawarkan ketahanan yang lebih kuat terhadap sensor dan lebih mudah diimplementasikan. Dia juga menyarankan beberapa perbaikan untuk membuat FOCIL lebih mudah didistribusikan.

peneliti Ethereumbarnabe.ethpandanganFOCIL sebagai mekanisme yang cukup umum dan dapat diskalakan. Ia menyadari bahwa BRAID mungkin dapat meningkatkan beberapa jaminan yang diberikan oleh FOCIL tetapi ia berhati-hati dalam meninggalkan model berbasis pemimpin sepenuhnya. Ia percaya bahwa lebih banyak pekerjaan yang diperlukan untuk membuktikan kelayakan BRAID.

pernyataan:

1. Artikel ini adalah reproduksi dari [Riset ChainFeeds], judul aslinya adalah "Jalan Ethereum menuju resistensi sensor: Siapa yang lebih baik, BRAID atau FOCIL?", Hak cipta milik penulis asli [0XNATALIE], jika Anda memiliki keberatan terhadap pencetakan ulang, silakan hubungi Tim Pembelajaran Gate , tim akan menanganinya secepat mungkin sesuai dengan prosedur yang relevan.

2. Disclaimer: Pandangan dan opini yang diungkapkan dalam artikel ini hanya mewakili pandangan pribadi penulis dan tidak merupakan saran investasi apa pun.

3. Versi bahasa lain dari artikel ini diterjemahkan oleh tim Gate Learn, tidak disebutkan di dalamnya.Gate.io, artikel yang diterjemahkan tidak boleh direproduksi, didistribusikan, atau diplagiat.