In the Ethereum block production and validation process, builders are responsible for ordering transactions and submit blocks to proposers through an auction mechanism. Proposers then select a block to sign and propose it to the blockchain. Since proposers have the final say as a single entity, there is a risk of collusion between proposers and builders to censor transactions.

One of the core values of blockchain is its censorship resistance, meaning that transactions can be conducted without interference from central authorities. When proposers control which transactions are included in a block, this feature is threatened, compromising fairness and transparency. Additionally, this power can be exploited to manipulate the order of transactions in a block, leading to additional economic gains and raising issues related to Miner Extractable Value (MEV).

Existing censorship-resistant solutions

To address this challenge, the community has proposed several anti-censorship solutions, such as Forced Inclusion Lists (FOCIL). In the FOCIL mechanism, a set of validators is randomly selected for each slot to form an inclusion list committee. These committee members generate local inclusion lists based on their subjective view of the mempool and broadcast them. Proposers are then responsible for collecting and aggregating these local lists into a single aggregated list to be included in the block. This mechanism ensures fairness in block inclusion since validators verify the aggregated list against the previously broadcasted local lists, and only blocks that meet consensus rules are accepted and added to the blockchain.

In addition to FOCIL, the community has also discussed Multiple Concurrent Proposers (MCP) schemes. This concept was initially proposed by Max Resnick in the Multiplicity mechanism, which aims to disperse power by introducing multiple parallel block proposers, reducing the ability of any single node to censor transactions. In the Multiplicity mechanism, each validator selects a portion of transactions from their own mempool to form a “special transaction package.” These validators sign their chosen transaction packages and send them to the current round’s proposer. The proposer must include at least 2/3 of these transaction packages in the block they propose for it to be considered valid. This mechanism ensures that proposers cannot unilaterally decide the block’s content, thereby reducing the possibility of censorship. To further incentivize proposers to include transactions fairly, this mechanism implements a “conditional tip” rule, where only proposers that include the transaction receive the transaction fees. The transaction fees are not automatically given to the first proposer to include the transaction but are distributed to all proposers who actually include the transaction based on specific conditions. This increases the cost of censorship, as bribing all proposers who include the transaction would be necessary.

BRAID: An improved MCP implementation

Building on the Multiplicity concept, Max Resnick introduced BRAID, a more complex and refined implementation of MCP. Max presented BRAID at the “DeFi in the MEV Era” seminar held by Paradigm. BRAID achieves MCP by allowing multiple proposers to propose blocks on different parallel chains and using a synchronization consensus mechanism to maintain consistency between these chains. Each chain has its own proposer, and all proposers release their blocks simultaneously within the same slot. The Ethereum execution layer aggregates the blocks generated by all sub-chains within that slot, forming an execution block. It then deduplicates, sorts, and executes these transactions according to predefined rules, reducing the ability of any single entity to manipulate transaction records.

BRAID’s design avoids introducing additional roles, thereby avoiding the complexities associated with incentive/punishment mechanisms. However, its implementation is relatively complex, requiring coordination of multiple sub-chains’ synchronization and data processing.

Problems with the BRAID mechanism

Jonahb from the Blockchain Capital team pointed out an issue with the BRAID mechanism: the “conditional tip” model imposes liquidity requirements, affecting user experience. This model is a dynamic pricing strategy that requires users to provide a certain amount of liquidity to ensure transaction censorship resistance. When submitting a transaction, users must set two tip values (T and t). The actual tip paid depends on the number of proposers who include the transaction.

1. A higher tip value, T, represents the maximum fee a user is willing to pay to ensure that their transaction is not censored. The goal is to incentivize proposers to include the transaction even if no other proposers are willing to do so. If only one proposer includes the transaction, they receive the full amount, T.
2. A lower tip value, t, is the minimum amount set by the user. If the transaction is included by multiple proposers simultaneously, the user only needs to pay t, which will be shared among the proposers. If the user is less concerned about censorship resistance, they can set T equal to t and send their transaction to only one proposer.

However, this additional liquidity requirement increases the complexity and cost of participating in blockchain transactions. Users need to reserve extra funds at the time of the transaction solely to ensure its censorship resistance. These reserved funds remain frozen until they are actually used.

To address this issue, Jonahb proposed two solutions:

• Proof of Post-State Liquidity: Users provide a proof at the time of transaction submission, indicating that they will have sufficient liquidity to pay T after the transaction is executed (e.g., the user will have $1M in liquidity post-transaction). This method allows users to proceed even if they do not have enough funds to pay T before the transaction. The challenge with this approach is that proposers need to know the final state of the transaction before execution. However, many financial transactions involve shared states (such as multiple transactions affecting the same account balance), making it difficult for proposers to accurately determine the post-transaction state before transaction ordering is finalized. This approach requires customized proofs for each transaction type, making it less practical.
• Censorship Insurance: Introduces third-party censorship insurance providers (CI providers) to guarantee the user’s T. Users pay an insurance premium, rT, where r is based on the likelihood of the transaction being censored. This approach reduces the need for users to immediately prepare a large amount of liquidity and can alert users if their T is too low and at high risk of censorship. However, establishing a market between users and CI providers takes time.

Community Thoughts on FOCIL vs. BRAID

Ethereum client Prysm developer Terence notes that a significant advantage of BRAID is that it does not require additional participants. Most Inclusion List (IL) designs, including FOCIL, require an extra participant, which adds time constraints within Ethereum slots, such as the time for submitting the IL, updating bids, and validators checking the IL. However, FOCIL is simpler and more flexible to implement compared to BRAID.

Paradigm researcher Dan Robinson appreciates BRAID’s design for transaction prioritization, which is not determined by a single leader (proposer), thus effectively mitigating MEV. Additionally, BRAID’s conditional tip mechanism incentivizes non-censoring behavior, which is not present in FOCIL.

Developer Dev prefers FOCIL over MCP, believing that FOCIL offers a stronger resistance to censorship and is simpler to implement. He also suggests some improvements to make FOCIL easier to deploy.

Ethereum researcher barnabe.eth views FOCIL as a fairly general and scalable mechanism. He acknowledges that BRAID might improve some of the guarantees provided by FOCIL but is cautious about completely abandoning the leader-based model. He believes more work is needed to prove BRAID’s feasibility.

statement:

1. This article is reproduced from [ChainFeeds Research], the original title is “Ethereum’s road to censorship resistance: Who is better, BRAID or FOCIL?”, the copyright belongs to the original author [0XNATALIE], if you have any objection to the reprint, please contact Gate Learn Team , the team will handle it as soon as possible according to relevant procedures.

2. Disclaimer: The views and opinions expressed in this article represent only the author’s personal views and do not constitute any investment advice.

3. Other language versions of the article are translated by the Gate Learn team, not mentioned in Gate.io, the translated article may not be reproduced, distributed or plagiarized.