Ethereum's Path to Censorship Resistance: BRAID vs FOCIL, Which Is Superior?
TechFlow Selected TechFlow Selected
Ethereum's Path to Censorship Resistance: BRAID vs FOCIL, Which Is Superior?
BRAID is an improved multi-concurrent proposer (MCP) scheme. FOCIL is an improved inclusion list (IL) scheme.
Navigating Web3 tides with focused insightsAuthor: 0XNATALIE
In the process of Ethereum block production and validation, builders are responsible for transaction ordering and submit blocks to proposers via an auction mechanism. Proposers then select one of these blocks, sign it, and propose it onto the blockchain. Since proposers act as single entities with final selection authority, this introduces the risk of collusion between proposers and builders to censor transactions.
One of the core values of blockchain is censorship resistance—the ability for anyone to transact without interference from centralized authorities. When proposers can control which transactions are included in a block, this property is threatened, undermining fairness and transparency. Furthermore, they may exploit this power to manipulate transaction ordering within blocks, capturing additional economic value and exacerbating MEV issues.
Existing Censorship Resistance Solutions
To address this challenge, the community has proposed several censorship-resistance solutions, such as the Forced Order Inclusion List (FOCIL). In FOCIL, a random set of validators is selected each slot to form an inclusion list committee. These committee members generate local inclusion lists based on their subjective views of the mempool and broadcast them. The proposer then collects and aggregates these local lists into a single aggregated list that must be included in the proposed block. This mechanism ensures block fairness, as validators verify the correctness of the aggregated list against previously broadcast local lists. Only blocks compliant with consensus rules are accepted and added to the chain.
Besides FOCIL, the community has also discussed Multiple Concurrent Proposers (MCP). This concept was first introduced by Max Resnick in the Multiplicity mechanism, aiming to decentralize power by enabling multiple parallel block proposers, thereby reducing any single node’s ability to censor transactions. In Multiplicity, each validator selects a subset of transactions from their own mempool to form a "special transaction bundle." They sign their chosen bundles and send them to the current round's proposer. Upon receipt, the proposer must include at least 2/3 of these bundles in their proposed block; otherwise, the block is considered invalid. This design prevents proposers from unilaterally deciding block contents, thus reducing censorship risks. To further incentivize fair transaction inclusion, the mechanism implements a "conditional tip" rule: only proposers who include a given transaction receive a share of its tip. Instead of automatically assigning the full tip to the first proposer including the transaction, the tip is conditionally distributed among all proposers who actually include it. This increases censorship costs—any attempt to censor would require bribing all proposers who included the transaction.
BRAID: An Enhanced MCP Implementation
Building upon Multiplicity, Max Resnick further proposed BRAID—a more sophisticated and refined MCP implementation. At a Paradigm-hosted workshop titled "DeFi in the MEV Era," Max presented BRAID. BRAID realizes MCP by allowing multiple proposers to propose blocks on different parallel chains while maintaining inter-chain consistency through a synchronized consensus mechanism. Each chain has its own proposer, and all proposers simultaneously publish their blocks within the same slot. The Ethereum execution layer aggregates all transactions from subchains generated during that slot into a single execution block, applying deduplication, ordering, and execution according to predefined rules—thereby reducing any single entity's ability to manipulate transaction records.
BRAID does not introduce additional roles, avoiding complexities associated with incentive or penalty mechanisms. However, its implementation is relatively complex, requiring coordination across multiple subchains for synchronization and data processing.
Problems with the BRAID Mechanism
Jonahb from Blockchain Capital identified an issue with BRAID’s “conditional tip” model: it imposes liquidity requirements that negatively impact user experience. This model uses a dynamic pricing strategy requiring users to pre-commit a certain amount of liquidity to ensure censorship resistance. Users must specify two tip values (T and t) when submitting a transaction. The actual fee paid depends on the number of proposers who include the transaction.
-
Higher tip T: Represents the maximum fee a user is willing to pay to guarantee their transaction won’t be censored. It incentivizes proposers to include the transaction even if no other proposer does. If only one proposer includes the transaction, they receive the full T.
-
Lower tip t: A lower base amount set by the user. If multiple proposers include the transaction, the user pays only t, which is then split among those proposers. Users unconcerned about censorship can set T = t and send their transaction to just one proposer.
However, this additional liquidity requirement increases the complexity and cost of participating in blockchain transactions. Users must lock up extra funds upfront solely to ensure censorship resistance. These reserved funds remain frozen until potentially used.
In response, Jonahb proposed two solutions:
-
Proof of Post-State Liquidity: Users provide proof at submission that they will have sufficient liquidity post-execution to cover T (e.g., they will have $1M in liquidity after the transaction). This allows users to proceed even without enough funds upfront, as long as they can prove post-state solvency. The challenge lies in proposers needing to know the final state before execution. However, most financial transactions involve shared states (like shared account balances), making it impossible for proposers to accurately assess post-transaction states before ordering is finalized. This would require custom proofs for every transaction type, limiting practicality.
-
Censorship Insurance: Introduce third-party censorship insurance providers (CI providers) who guarantee the user’s T payment. Users pay a premium rT, where r is calculated based on the likelihood of censorship. This reduces the need for users to immediately hold large liquidity reserves and allows CI providers to alert users when T is too low and censorship risk is high. However, establishing a market between users and CI providers will take time.
Community Perspectives on FOCIL vs. BRAID
Terenche, a developer of the Ethereum client Prysm, noted a key advantage of BRAID: it requires no additional participants. Most Inclusion List (IL) designs—including FOCIL—require an extra participant role, increasing time constraints within Ethereum slots (e.g., time needed to submit ILs, update bids, and allow validators to check ILs). However, FOCIL is simpler and more flexible to implement compared to BRAID.
Dan Robinson, a researcher at Paradigm, praised BRAID’s approach to transaction priority ordering—not left to a single leader—which effectively mitigates MEV. He also highlighted BRAID’s conditional tipping mechanism that incentivizes non-censorship behavior, features not present in FOCIL.
Developer Dev expressed a preference for FOCIL over MCP, arguing that FOCIL offers stronger censorship resistance and simpler implementation. He also suggested improvements to make FOCIL easier to deploy.
Ethereum researcher barnabe.eth viewed FOCIL as a highly generalizable and scalable mechanism. While acknowledging that BRAID might improve upon some guarantees provided by FOCIL, he remained cautious about fully abandoning leader-based models, noting that doing so is not yet a community consensus and requires more work to demonstrate feasibility.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@ChainFeedsxyz
