Ethereum’s Path to Censorship Resistance: BRAID vs. FOCIL
In the evolving landscape of Ethereum, the battle for censorship resistance has introduced several innovative mechanisms. Among these, BRAID and FOCIL stand out as two promising approaches designed to protect the network’s integrity by minimizing the risk of transaction censorship.
Both of these solutions address critical issues in the block proposal process but take fundamentally different approaches to achieve their goals. This article delves into the nuances of these two mechanisms and explores which might ultimately prove more effective.
Understanding the Threat of Censorship in Ethereum
At the core of Ethereum’s block generation and validation process are two primary actors: builders and proposers. Builders are responsible for sorting transactions and submitting a block to proposers, who then select one block to sign and propose to the blockchain.
This process, however, creates a potential vulnerability. Since proposers have the final say in which block gets proposed, there is a risk of collusion between proposers and builders to censor certain transactions, thereby threatening Ethereum’s principle of censorship resistance.
Censorship resistance is crucial to maintaining the fairness and transparency of the blockchain. If proposers can selectively include or exclude transactions, it undermines the decentralized nature of the network and can lead to the exploitation of transaction ordering, resulting in issues like Miner Extractable Value (MEV).
Existing Solutions: MCP and FOCIL
To address this challenge, several censorship-resistant solutions have been proposed, with two of the most discussed being the Force Inclusion List (FOCIL) and the Multi-Concurrent Proposer (MCP) mechanisms.
Force Inclusion List (FOCIL)
FOCIL is designed to ensure fairness by involving a randomly selected committee of validators during each time slot.
These validators create local inclusion lists based on their views of the mempool and broadcast these lists.
The proposer then aggregates these local lists into a final inclusion list that is added to the block.
This mechanism ensures that no single proposer has full control over the transactions included in a block, thus reducing the risk of censorship.
Validators verify that the block adheres to the consensus rules before accepting it into the blockchain.
Multi-Concurrent Proposer (MCP)
MCP introduces the concept of multiple concurrent proposers, as first suggested by Max Resnick in the Multiplicity mechanism.
In this system, several proposers work in parallel, each selecting a portion of transactions from the mempool.
These transactions are packaged into “special transaction bundles” and signed by the proposers. The lead proposer must include at least two-thirds of these bundles in the proposed block for it to be considered valid.
This method decentralizes the power of a single proposer and significantly lowers the likelihood of transaction censorship.
BRAID: An Enhanced MCP Implementation
Building on the MCP concept, Max Resnick further developed BRAID, a more sophisticated and complete MCP implementation.
Introduced during the “DeFi in MEV Era” seminar hosted by Paradigm, BRAID allows multiple proposers to propose blocks on different parallel chains simultaneously.
These blocks are then synchronized through a consensus mechanism to ensure consistency across chains.
Ethereum’s execution layer consolidates all the blocks generated within the slot into a single execution block, where transactions are deduplicated, ordered, and executed according to predefined rules.
This approach significantly reduces the power of any single entity to manipulate transaction records.
A key advantage of BRAID is its avoidance of additional roles or complex incentive structures, which can add complexity.
However, coordinating synchronization across multiple sub-chains and handling data processing poses its own challenges.
Challenges and Considerations in BRAID
Despite its strengths, BRAID is not without its issues. One notable challenge is the “conditional tipping” model, which requires users to have liquidity available to ensure their transactions are censorship-resistant. Users must set two tip values when submitting transactions:
- Higher Tip (T): The maximum amount a user is willing to pay to ensure their transaction is included even if censorship is attempted. If only one proposer includes the transaction, they receive the full amount of T.
- Lower Tip (t): A smaller tip that is paid if multiple proposers include the transaction. In this case, the tip is distributed among the proposers who include the transaction.
This model, while effective in discouraging censorship, introduces additional complexity and costs for users. They need to reserve extra liquidity at the time of the transaction, which can be frozen until it is determined whether it will be needed.
To address these issues, Jonahb from Blockchain Capital suggests two potential solutions:
- Proof of Post-State Liquidity: This approach allows users to provide proof that they will have sufficient liquidity to pay the higher tip after the transaction is executed. However, this requires proposers to understand the post-transaction state, which is challenging in transactions involving shared state or complex financial operations.
- Censorship Insurance: This concept introduces third-party Censorship Insurance (CI) providers who guarantee the user’s tip in exchange for a fee. This reduces the immediate liquidity burden on users but requires the development of a market between users and CI providers.
Community Perspectives: FOCIL vs. BRAID
The Ethereum community is divided on the relative merits of FOCIL and BRAID. Terence, a developer for the Ethereum client Prysm, appreciates that BRAID does not require additional participants, simplifying the process compared to FOCIL, which introduces extra time constraints for submitting and verifying inclusion lists. However, FOCIL is generally considered easier to implement and more flexible.
Dan Robinson, a researcher at Paradigm, praises BRAID for its approach to prioritizing transactions, effectively reducing MEV risks. He also highlights the conditional tipping mechanism as a strong incentive against censorship—an aspect that FOCIL lacks.
Conversely, developer Dev favors FOCIL for its simplicity and robust censorship resistance, suggesting that FOCIL offers a more straightforward implementation with fewer complications.
Ethereum researcher barnabe.eth acknowledges that while BRAID may offer improvements in certain areas, he is cautious about fully abandoning the leader-based model that FOCIL and other IL designs are built on, citing the need for further research and evidence to validate BRAID’s feasibility.
Conclusion: Which Mechanism is Superior?
The debate between BRAID and FOCIL underscores the complexity of achieving censorship resistance in Ethereum. BRAID’s innovative approach to decentralizing proposer power and reducing MEV risk is compelling, yet it comes with significant implementation challenges and requires further development.
FOCIL, while simpler and more flexible, may not offer the same level of robustness against sophisticated censorship attempts.
Ultimately, the choice between BRAID and FOCIL may depend on the specific priorities of the Ethereum network at any given time. As the ecosystem continues to evolve, both mechanisms could play a role in strengthening Ethereum’s resistance to censorship, ensuring that the network remains true to its decentralized principles.