Ethereum's road to anti-censorship: BRAID and FOCIL, who is better?

Author: 0xNatalie

During the Ethereum block generation and verification process, the builder is responsible for selecting and sorting transactions from the transaction pool and submitting the blocks to the proposer through an auction mechanism. The proposer selects a block from these submitted blocks to sign and propose to the blockchain. Since the proposer, as a single entity, has the final right of selection, this brings the risk of collusion between the proposer and the builder to censor the transaction.

One ​​of the core values ​​of the blockchain is its anti-censorship property, that is, anyone can trade without interference from a central authority. This feature is threatened when the proposer can control which transactions are included in the block. It undermines fairness and transparency. And this power can be used to manipulate the order of transactions in the block to obtain additional economic benefits, causing the MEV problem.

Existing anti-censorship solutions

To address this challenge, the community has proposed a variety of anti-censorship solutions, such as the Forced Inclusion List (FOCIL). In the FOCIL mechanism, a group of validators are randomly selected for each slot to form an inclusion list committee. These committee members generate local inclusion lists based on their subjective views of the transaction pool (mempool) and broadcast them. The proposer is responsible for collecting and aggregating these local lists to form an aggregate list and include it in the block. This mechanism ensures the fairness of the block, because the validator will verify the correctness of the aggregate list based on the previously broadcast local list, and only blocks that meet the consensus rules will be accepted and added to the blockchain.

In addition to FOCIL, the community has also discussed the multiple concurrent proposers (MCP) scheme. This concept was first proposed by Max Resnick in the Multiplicity mechanism, which aims to decentralize power by introducing multiple parallel block proposers and reduce the ability of a single node to censor transactions. In the Multiplicity mechanism, each validator selects a portion of transactions from its own transaction pool to form a "special transaction package". These validators sign their selected transaction packages and send them to the proposer of the current round. After receiving them, the proposer needs to include at least 2/3 of the transaction packages in the block it proposes. Only in this way will the block be considered valid. This mechanism ensures that the proposer cannot decide the content of the block alone, thereby reducing the possibility of censorship. In order to further incentivize proposers to include transactions fairly, this mechanism implements the "conditional tip" rule, that is, only those proposers who include the transaction can share the transaction tip. The transaction tip is not automatically given to the first proposer who includes the transaction, but is distributed to all proposers who actually include the transaction according to certain conditions. This increases the cost of censorship, and if you want to censor, you need to bribe all proposers who include the transaction.

BRAID: An Improved MCP Implementation

Based on Multiplicity, Max Resnick further proposed BRAID, a more complex and complete MCP implementation. At a seminar held by Paradigm on the theme of "DeFi in MEV Era", Max introduced BRAID. BRAID implements MCP by allowing multiple proposers to propose blocks on different parallel chains and using a synchronous consensus mechanism to maintain consistency between chains. Each chain has its own proposer, and all proposers publish their blocks simultaneously in the same slot. The Ethereum execution layer aggregates the block transactions generated by all subchains in the slot to form an execution block, and deduplicates, sorts and executes these transactions according to predetermined rules, thereby reducing the ability of any single entity to manipulate transaction records.

BRAID’s design does not introduce additional roles, thus avoiding the complexity brought by the incentive/penalty mechanism, but its implementation is relatively complex and requires coordination of the synchronization and data processing of multiple sub-chains.

BRAID mechanism problems

Blockchain Capital team Jonahb pointed out BRAID One problem with the mechanism: The "conditional tip" model has liquidity requirements, which affects the user experience. This model is a dynamic pricing strategy that requires users to prepare a certain amount of liquidity to ensure the censorship resistance of the transaction. Users need to set two tip values ​​(T and t) when submitting a transaction. The actual tip paid in the end depends on the number of proposers who include the transaction.

1. Higher tip T: represents the maximum fee that the user is willing to pay to ensure that the transaction is not censored. The purpose is to incentivize the proposer to choose to include the transaction when no other proposer is willing to include it. In the end, if only one proposer is willing to include it, he will get T.

2. Lower tip t: This is a lower amount set by the user. As long as the transaction is included by multiple proposers at the same time, the user only needs to pay t. t will be shared among multiple proposers. If the user does not care about censorship resistance, they can set T=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 set aside an additional amount of funds at the time of the transaction, just to ensure the censorship resistance of the transaction. These reserved funds are frozen until they are actually used.

In response to this, Jonahb proposed two solutions:

• Proof of Post-State Liquidity: When submitting a transaction, the user provides a proof that there will be enough liquidity to pay T after the transaction is executed (for example, the user will have $1M liquidity after the transaction). In this way, even if there is not enough funds to pay T before the transaction, the user can prove that he can pay after the transaction. The challenge of this method is that the proposer must know the final state of the transaction before the transaction is executed, but most financial transactions involve shared state (such as multiple transactions sharing the same account balance), so the proposer cannot accurately judge the state after the transaction before the transaction order is determined. This requires customized proofs for each transaction type, which is less practical.

• Censorship Insurance: Introduce a third-party review insurance provider (CI provider) to guarantee the user's T. The user pays an insurance premium rT for this, where r is calculated based on the probability of the transaction being censored. This scheme not only reduces the need for users to prepare a large amount of liquidity immediately, but also reminds users through CI that T is too low and there is a high risk of censorship. But it takes time to establish a market between users and CI providers.

Community's View on FOCIL and BRAID

Ethereum client Prysm developer Terence believes that a significant advantage of BRAID is that it does not require additional participants. In most Inclusion List (IL) designs, including FOCIL, an additional participant is required, which increases the time constraints in the Ethereum time slot, such as the time to submit IL, the time to update the bid, and the time for the validator to check IL. However, the FOCIL scheme is simpler and more flexible to implement than BRAID.

Paradigm researcher Dan Robinson appreciates BRAID's design on transaction priority sorting, which is not determined by the leader (single proposer) at his own discretion, effectively alleviating MEV. In addition, the conditional tipping mechanism in BRAID incentivizes non-censorship behavior, which is not reflected in FOCIL.

Developer Dev prefers FOCIL to MCP. He believes that FOCIL has advantages in providing strong resistance and simplified implementation. And provides some improvement plans to make FOCIL easier to implement.

Ethereum researcher barnabe.eth believes that FOCIL is a fairly general and scalable mechanism. He admits that BRAID has the potential to improve the guarantees provided by FOCIL in some aspects, but is cautious about completely abandoning the leader-based model, believing that this is not a consensus yet and more work is needed to prove its feasibility.