Written by: 0XNATALIE

In the Ethereum block generation and verification process, the builder is responsible for sorting transactions and submitting blocks to the proposer through an auction mechanism. The proposer selects a block to sign and propose to the blockchain. Since the proposer, as a single entity, has the final choice, this brings the risk of collusion between the proposer and the builder to censor transactions.

One of the core values ​​of blockchain is its censorship resistance, which means that anyone can conduct transactions without interference from a central authority. This feature is threatened when the proposer can control which transactions are included in the block, compromising 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 censorship-resistant 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 validators 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 idea of ​​multiple concurrent proposers (MCP). 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, as censorship requires bribing all proposers of 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 entitled "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 inter-chain consistency. 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.

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

Problems with the BRAID mechanism

Jonahb from the Blockchain Capital team pointed out a problem in the BRAID 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 transactions. 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.

• 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 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.

• Lower tip t: This is a lower amount set by the user, and as long as the transaction is included by multiple proposers, the user only needs to pay t. t is 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, and users need to set aside additional 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 this regard, 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 they 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 censorship 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 can remind 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 views 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 adds timing constraints in Ethereum time slots, such as when IL is submitted, when bids are updated, and validator checks IL time. However, the FOCIL solution is simpler and more flexible to implement than BRAID.

Paradigm researcher Dan Robinson appreciated BRAID's design in transaction prioritization, 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. He also 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 acknowledges that BRAID has the potential to improve the guarantees provided by FOCIL in some ways, 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.