jakiro
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 for signature and proposes it to the blockchain.Since the proposer, as a single entity, has the ultimate option, this brings the risk of possible collusion between the proposer and the builder to review the transaction.
One of the core values of blockchain is its censorship resistance, that is, anyone can trade without interference from central authority.This feature is threatened when the proposer can control which transactions are included in the block.Injure fairness and transparency.And this power can be used to manipulate the order of transactions in the block, thereby obtaining additional economic benefits, causing MEV problems.
Existing anti-censorship solutions
To address this challenge, the community has proposed a variety of anti-censorship solutions, such as Forced Inclusion List (FOCIL).In the FOCIL mechanism, each slot (time slot) will randomly select a group of validators to form a committee containing lists.These committee members generate local inclusion lists based on their respective subjective views of the transaction pool (mempool).The proposer is responsible for collecting and aggregating these local lists to form an aggregate list and include them in the block.This mechanism ensures the fairness of the blocks, because the validator will verify the correctness of the aggregated list based on the local lists broadcasted previously, and only blocks that comply with the consensus rules will be accepted and added to the blockchain.
In addition to FOCIL, the community also discussed the schemes of multiple concurrency proposers (MCPs).This concept was first proposed by Max Resnick in the Multiplicative mechanism, aiming toReduce the ability of a single node to review transactions by introducing multiple parallel block proposers to diversify power.In the Multiplicability mechanism, each validator will select a portion of the transaction from his or her trading pool to form a “special transaction package”.These validators sign and send their selected transaction package to the proposer of the current round.After the proposer receives it, he needs to include at least 2/3 of the transaction packages in his proposed block.Only in this way can this block be considered valid.This mechanism ensures that the proposer cannot decide the block content separately, thereby reducing the possibility of censorship.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 receive transaction tips.The tip of the transaction is not automatically given to the first proposer containing the transaction, but is distributed to all proposers who actually contain the transaction according to certain conditions.This increases the cost of review, and if you want to review, you need to bribe all proposers who include the transaction.
BRAID: Improved MCP implementation solution
Based on Multiplicability, Max Resnick further proposed BRAID, which is a more complex and comprehensive MCP implementation.At a seminar on “DeFi in MEV Era” held by Paradigm, 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 within the same slot.The Ethereum execution layer collects all the block transactions generated by the subchains in this slot to form an execution block, and deduplicate, sort and execute these transactions according to predetermined rules, thereby reducing the transaction record manipulation by any single entity.ability.
The design of BRAID does not introduce additional roles, thus avoiding the complexity of the incentive/punishment mechanism, but its implementation is relatively complex and requires coordination of the synchronization and data processing of multiple sub-chains.
Issues with the BRAID mechanism
Blockchain Capital team Jonahb pointed out a problem in the BRAID mechanism: the “conditional tip” model has requirements for liquidity, which affects the impact of user experience.This model is a dynamic pricing strategy that requires users to prepare a certain amount of liquidity to ensure the transaction’s censorship resistance.Users need to set two tip values (T and t) when submitting a transaction.The actual tips paid in the end depend on the number of proposers containing the transaction.
-
Higher tip T: Represents the maximum fee the user is willing to pay to ensure that the transaction is not reviewed.The purpose is to incentivize the proposer to choose to include when no other proposer is willing to include a transaction.Eventually if only one proposer is willing to include it, he gets a T.
-
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 allocated among multiple proposers.If the user is not concerned about censorship resistance, they can set T=t and send their transactions to only one proposer.
However, this additional liquidity requirement increases the complexity and cost of participating in blockchain transactions. Users need to reserve more funds at the moment of transactions 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 sufficient liquidity after the transaction is executed to pay T (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 pay after the transaction by proof.The challenge of this approach is that the proposer must understand the final state of the transaction before the transaction is executed, but most financial transactions involve shared state (such as multiple transactions share the same account balance), so the proposer cannot accurately judge until the transaction sort is determined.Status after transaction.This requires customized proof for each transaction type, which is less practical.
-
Censorship Insurance: Introducing a third-party review insurance provider (CI provider) to provide guarantees for users’ T.The user pays an insurance premium rT for this, where r is calculated based on the possibility that the transaction is reviewed.This solution not only reduces the need for users to prepare for large amounts of liquidity immediately, but also reminds users that T is too low and there is a high risk of scrutiny through CI.But it takes time to build a market between users and CI providers.
Community views on FOCIL and BRAID
Ethereum Client Prysm Developerterence 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 time constraints in Ethereum time slots, such as the time to submit IL, the time to update bids, and validator checksIL’s time.However, the FOCIL solution is simpler and more flexible than BRAID.
Paradigm researcher Dan Robinson appreciates BRAID’s design in transaction prioritization, rather than being decided by the leader (single proposer) to effectively mitigate MEV.Furthermore, conditional tipping mechanisms in BRAID incentivize non-censored behaviors, which are not reflected in FOCIL.
Dev, a developer, prefers FOCIL to MCP, believes that FOCIL has more advantages in providing strong resistance and simplifying implementation.And some improvements are provided to make FOCIL easier to implement.
Ethereum researcher barnabe.eth believes that FOCIL is a rather general and scalable mechanism. He acknowledges that BRAID has the potential to improve the assurances provided by FOCIL in some ways, but is cautious about abandoning the leader-based model altogether.It is believed that this is not a consensus at the moment and more work is needed to prove its feasibility.
