Vitalik: how to improve the transaction anti censorship of the block proposer's scheme

source | notes.ethereum.org

author | Vitalik Buterin

Special thanks Francesco Propose solutions 2 The core idea in , And thank Francesco、Justin Drake、Alex Obadia and Phil Daian Feedback and comments .

Block proposer / How the builder separation scheme works ？

In the current trading market , Block proposer  ( Currently miners , After the merger is the verifier ) Select which transactions are packaged into the next block by directly looking at which transactions in the trading pool pay the highest tip . This allows block traders to use complex strategies to choose which transactions to package , Or even package their own deal , To take advantage of the image DEX Opportunities for arbitrage and liquidation ( For the sake of simplicity , Hereinafter referred to only as MEV) To maximize their benefits . The complexity of these strategies causes a high fixed cost to run an effective miner or verifier node , And give an advantage to a centralized pool that uses these strategies on behalf of its participants .

Block proposer / Builder separation (PBS)  The solution solves this problem by separating the role of block construction from the block proponent . A separate class of actors is called Builder (buiders), They build Execute block body (exec block bodies) ( It's basically an orderly list of transactions , These transactions will become the main load in the block ) Submit and bid . The proposer's job is to receive the highest bid execution block . It is worth noting that , Proposal is ( And everyone else ) Until they choose the winning block in the bidding ( That is, the block body is also selected ) I don't know any content in the main body of the execution block . such Privacy before confirmation (pre-confirmation privacy)  Yes, to prevent “MEV steal ” There is a need , Because knowledgeable proponents will find the builder's MEV Extract policies and copy them without giving them to the builder .

PBS Compared with the current situation , What are the anti censorship challenges ？

The first is the status quo , Suppose there is a sum 150k gas Transactions , And the current gas The upper limit is 30m ( The goal is 15m). Economically powerful actors tried to censor the deal . In the current trading market , If the transaction is willing to pay a basic fee and more than 1~2 gas Tips for , Block proponents will be willing to package them ; On average, each block has about 15m Of gas Relax and let them do this . To review a sender's willingness to pay for packaging x Transactions , The attacker needs to raise the base fee above every gas X / 150k, And keep it there . If they do , Other users will withdraw from bidding because the cost is too high —— After all , If the base fee is high enough to pull out a deal that is important enough to attract targeted scrutiny , The attacker may have to pay the transaction with the most expensive transaction fee in the block . Say conservatively , It is likely that the attacker will have to pay up to every slot (X / 150k ) * 10m = X * 66.7 ( So it's about every hour  x*20000 )

Now? , Let's explore PBS The situation of . Suppose one block builder always performs better than other builders , Or because they convince inexperienced users to run wallets that only send them transactions (" Proprietary order flow "), Or because they have better algorithms and data access to find MEV The opportunity to . Suppose there are some specific Victimized transactions It's the builder (“ Review the builder ”) Trying to censor . set up ：

• M  Bid for non censorship builders without victimized transactions
• P = X - basefee * 150k  The tip part of the total transaction fee of the injured transaction
• M + P  In case the victim transaction can be packaged, the bid of the non review builder
• A  To review the advantages gained by the builder (advantage) ( Equal to the cost they earn +MEV With non censorship builders can earn the most money + MEV The difference between the )
• M + A  Is to review the builder's bid , Whether there is a victimized transaction or not ( Because the review builder doesn't want to package the victim transaction )

If  P>A, Non censorship builders will be able to give better results than censorship builders 0 Revenue bid (M + A) Higher than  P - A  The price of . To maintain censorship , Review builders will have to raise their bids to  M + P, And every slot Loss  P - A  To keep bids higher than non censored builders ( And sacrifice every slot Reap profit A The opportunity of , So the total loss is per slot P ). The cost is still high . But please note that this is better than every slot X * 66.7  It's much cheaper .

If  P < A, Even if you don't package the victim transaction , Review builders can also win bids , Although they did have to raise their offer slightly higher than  M + P , At the expense of everyone slot Of  P  earnings ( The benefits of reviewing the builder become  A - P  instead of  A).

Please note that , In two cases , Attackers will lose every... Because of censorship slot Of  P  earnings  —— For just excluding a transaction from the chain , This is still a huge and ongoing cost , But it's not as high as the cost of each transaction in the fee market .

* PBS Review economics and block time

An important result of the above analysis is , stay PBS in , The cost of the review is per slot Calculated ( Strictly speaking, every block , But for simplicity , We ignore the difference between the two , Because in fact, almost all on Ethereum slot There is a block ). If the out of block frequency decreases 10 times , Review costs will be reduced 10 times . If the out of block frequency increases 10 times , The cost of censorship will increase 10 times . It's counterintuitive , But it is consistent with the logic in the previous part . Please pay special attention , The current toll market is a bit like PBS, Yes 100 Multiple bids grab the packaging position of one transaction at the same time ; however , This is a problematic PBS market , Because it lacks privacy protection before confirmation .

therefore , It's natural to ask such a question ： Can we try to expand PBS, To achieve fast block out , But make those blocks appear in parallel rather than in order ？

What are the design objectives of the anti audit scheme ？

• DOS Protection and no free data availability ： Proposal is ( Or builder ) You shouldn't be able to package data that no one pays , Because it could be exploited by attackers , Expand the chain data , Or to rollup Opportunities to defraud transaction costs . for example , This means that if a block contains a transaction that proves invalid due to insufficient balance or other transactions in the same block , The agreement must still charge the proposer the basic fee for the transaction .

• Minimum additional bandwidth consumption ： This mechanism should not only be effective for data on the chain , Yes p2p The data on the network should also be effective . for instance , It is unrealistic to float hundreds of redundant complete block subjects from different builders on the network .

• No longer reintroduce proponentization ：PBS The whole point of is that it doesn't need the proposer to be sophisticated . We don't want to create a mechanism that will reintroduce benefits to sophisticated proponents , So as to encourage the proposer to enter into further out of agreement bidding relationship or join the pool .

• Ideally , Allow the proposer to be stateless ： The verifier can become completely stateless ( once Verkle trees Deployed to the main network ) It will be a great gospel for further decentralization and scalability .

• If we rely on altruism , Don't let altruism become expensive ： We can generally rely on such an assumption —— At least a few percent of the proponents are altruistic , And will ignore bribe offers and accept reviewed transactions . however , If this is costly within the agreement , This assumption will become very unrealistic . Proponents should not have to sacrifice large profits to help ensure that the transactions under review can be packaged .

Solution 1： We can run a lot of pre confirmation privacy at the same time PBS Bidding ？

Suppose in every slot There is a auction in the for The main execution block  (primary exec block)  And have  N-1  A bid is for Auxiliary execution block (auxilary exec block) ( So there's a total of  N  A bid ), And they run in parallel . These blocks are executed sequentially ( The order is from primary to secondary ), But their consensus is reached in parallel .

Suppose a transaction sender is willing to pay  P  Gratuity . To exclude the transaction from the chain , The reviewer will need to be willing to give each controller who assists in the execution of the block auction slot P+1, So they will have to pay for every slot(P+1) * N.

The attacker must every slot All bid , And it's not just when someone is trying to do assisted packaging , Because if the attacker only automatically bid higher than the auxiliary packaging , Proponents will start submitting false self bids to force attackers to bid higher than them .

But there's a problem ： How the auxiliary execution block will be constructed ？ The builder who builds the main execution block (" Main builders ") It will be relatively simple , Because they see the pre state of the foundation of the block they are building ： This is the post state of the previous block . On the other hand , The builder who builds the auxiliary execution block ( Auxiliary builder ) Not so lucky ： They are in the same slot Any block built in the needs to be based on the main execution block ( And the auxiliary execution block of the lower index ). therefore , When auxiliary builders choose which transactions to package, they don't know what state they want to build on .

If an auxiliary builder packages a transaction that has been packaged into the previous block , They must pay for data and execution until signature and random number verification gas, But they won't get a fee from the deal . therefore , They will lose money  ( In this case, design an exemption data + verification gas Fee agreement is not safe , Because it could be rollup And other use cases for storing data to the blockchain ).

This raises a question ： Does the auxiliary builder have a security policy to package transactions into the auxiliary execution block ？ This strategy should be profitable under normal circumstances ( Expected ), And can provide protection if a major builder who will review is clearly trying to attack them . A possible example of an attack is , A major builder who will review can suddenly package those transactions until they foresee that a secondary builder will start packaging those transactions , So as to realize the review . If they keep doing this , They can cause the helper builder to lose money ; Once the auxiliary builder loses too much , They will withdraw from the market , Allow the builder who will review to review the transaction freely .

* The lowest possible auxiliary builder strategy

please remember , stay “ Good situation ” Next , The auxiliary block will be empty , Because any transaction that wants to be packaged will be packaged into the main block . therefore , This strategy only needs to be activated when the review really happens .

set up ：

• N = Every slot The total number of auctions that took place on ( Including primary and secondary )
• P = Trade tips
• B = Current base fee

First , For the sake of simplicity , hypothesis  N = 2 ( therefore , Every slot There is only one auxiliary execution block ). Also assume  P = B ( Victims of censorship always pay twice the cost , To attract auxiliary builders and avoid censorship ). Here is a suggested helper strategy ：

If an auxiliary builder sees a transaction in  k  individual slot First received before , But it hasn't been packaged yet , And has been effective since then , Then the probability that the builder should package the transaction in their proposed block is .

It is assumed that the main builders who will be reviewed are k individual slot Then he accepted the victim's deal . or  k = 0, In this case, they only have  0.00000001  The opportunity to “ Frame up ” Auxiliary builder ( intend , The review builder and the auxiliary builder are in the same slot Released in , Cause them to lose money ), or  k > 0, In this case, the probability of the attacker framing the auxiliary builder is equal to the probability that the auxiliary builder packages the injured transaction before the attacker ( namely   , because k≥1 ).

In the latter case , On average, auxiliary builders make no money . This is because when the attackers framed them , They lost money  B, And when they packaged a deal , They make a profit  P, And we assume above  P = B. Reduce the index base to  2  following , Make mathematical operations simpler , And ensure that the auxiliary builder is profitable . We can set the cardinality to    Extend to any tip .

and  N > 2  The situation is tricky , Because there may be interference ： What if a transaction is packaged into two auxiliary execution blocks at the same time ？ however , If we assume that the helper builder uses an independent random strategy , The chances of conflict are manageable ( A simulation script shows that , If the cardinality is 2, No matter how many builders there are , P Are close to 1/4).

In practice , The above figures are almost certainly too pessimistic . The transactions under review may be in several slot Then it is packaged by the auxiliary builder , The auxiliary builder will respond dynamically to the attack . Besides , The cost of a failed transaction is lower than that of a successful one , So in practice , P  Only a few percentage points of a large number of transactions  B. contrary , The above content is more as a proof of existence , That is, the helper builder can use a fixed specific strategy , Even under attack .

After the content of the main execution block is known , Why not let the auxiliary builder choose which transactions to exclude from the chain through a bit field

A bit field still carries enough information , An attacker can encode instructions into a smart contract , To learn how to use MEV The opportunity to . Besides , If there are multiple auxiliary builders , They will have to provide their bit fields in order . therefore , This will simply convert the secondary auction into a series of primary auctions .

Solution 2： Can we still use the proposer (“ Hybrid PBS"), But only for ” The last resort of packaging ”

Another natural way to prevent censorship is to integrate the current transaction costs into the market PBS Merge . This approach will rely on proponents to resist censorship . Only a few proponents need to actually use this scheme ; Even if 95% The proponent of the proposal somehow succeeded in being bribed , Pretend not to see the deal and only accept PBS Blocks generated under the mechanism , The rest 5% signify , On average , Any victimized transaction will still be 20 individual slot Then packed .

The working principle of this scheme is as follows . At every slot ：

1. Proposer broadcast  crList, This is the list of transactions that the proposer sees that should be packaged ( That is, they have the correct random number and sufficient balance packed in their state 、 Tips and maximum basic fee ). This  crList  Can only contain one  sender ( Give a person ) A deal for . Proponents also have to respond to a  crListSummary  Signature and broadcast , It is contained in  crList  Every last stroke  tx  Of  tx.sender  and  tx.gaslimit.

2. The builder creates a proposal body , It must be included in  crListSummary  in

3. The proposer accepts the winning block

4. The builder publishes the subject . The validation of the principal needs to be checked in  crListSummary  On each  (sender, gaslimit), Or whether  block.gasused + gaslimit > block.gaslimit, or  sender  Whether the sender of a transaction in the block .

To further save space , There is a more complex alternative , It is demand.  crList  according to  tx.gaslimit  In descending order , Then ask the subject to include only (i) stay  crList  The first transaction that cannot be packaged on the Merkle prove , and (ii) Those in the block are  crList  Bit field of the transaction on . Anyone can rebuild Merkle Prove the previous part of the tree and check whether it is related to Merkle Verify by proving conformity .

Please note that , Either solution , If the proposer mistakenly constructs  crList, The builder may not be able to safely propose an execution block body . under these circumstances , The builder should simply not propose anything , Like the proposer never broadcast at all  crList  equally .

* The fusion PBS And stateless

PBS An important secondary goal of is to allow the verifier to be completely stateless ( once Verkle trees Deployed ).PBS This is achieved because only the builder needs to really build the subject ; The builder is also responsible for attaching witness data (witness) To their block , So that the verifier can verify the block in a stateless state .

To extend this property to this scheme , Each transaction needs to be accompanied by a simple witness data , Prove the balance and random number of the sender of the transaction . If the user is stateless , This witness data can be generated by intermediate nodes ( for example , Builders can do this voluntarily ) To add .

* Hybrid PBS How to interact with the second tier account abstraction ( for example ERC 4337)

ERC 4337 Fundamentally changed the game of anti censorship , Because it decouples the concept of transaction at Ethereum level from the economic concept of user intention object . in the final analysis , We try to make sure that the user's intention object is anti censorship . When the two are the same ( Just like today ), This can be said to be the anti censorship of the transaction . however , stay ERC 4337, The transaction becomes an object that contains many user intentions ( stay ERC 4337 This is called user operations) The wrapper .

stay " The conventional " PBS in , This distinction is not important , Because the protocol only interacts directly with the execution block . The builder can create one that contains many pens (" routine ") Execution block of the transaction , Or they can create one that contains a single package of multiple user operations Execution block of the transaction , Or a mixture of the two . The mechanism of the two cases is exactly the same ; There is little difference between the packer and the packer of the packer .

If the auxiliary execution block is used as anti censorship , Then the mechanism is still the same . If you use a hybrid PBS, So for the status quo and transactions ERC 4337 user operations There will be differences in the treatment of ： The anti censorship of current transactions is directly guaranteed , But yes ERC 4337 user operations The resistance to censorship is only indirectly provided .

Whether it's ERC 4337 Or hybrid PBS All need to be slightly modified , To make sure it's in the hybrid PBS Integrate censorship resistance in the world of . Understand why , First, let's take a look at why ERC 4337 The first problematic argument that will remain resistant to censorship ：

carry ERC 4337 user operations Of ” transaction “ Directly map to the above ” Auxiliary block “ The concept of . If a given ERC 4337 user operations Not packaged by major builders who will review , So anyone ( We call them ” Relay ”) You can create a package user operations Transactions ( A fake auxiliary execution block ), And expect to profit from it . Of course , The reviewer can pack at that exact time user operations , And take away the relay's income , But not always , So on average , The relay will be profitable , The reason is the same as explained in the auxiliary builder strategy section above .

The key flaw in this argument is ,“ Not always ” It's wrong. . This is because in the case of auxiliary execution blocks and ERC 4337 There are fundamental differences between transactions . In the case of auxiliary execution blocks , The main body of the main and auxiliary execution blocks are submitted at the same time . therefore , Neither side can see what the other side is doing , You can't do a rush . But in ERC 4337 In the case of trading , The winning builder can see the deal , So they can make a run .

Solution 1： modify ERC 4337

We can ERC 4337 Make the following changes ：user operations Will need the ability to specify a single relay that allows them to be packaged . This can protect user operations Don't be “ steal ” ( But here's the thing , Censorship builders who collude with users may still be able to draw heavily on the benefits of assisting builders , Because the builder who will review can preempt the relay with the same random number but different user operations ).

Solution 2： Modify hybrid PBS

Need to be in crList Transactions on are executed before all other transactions . This prevents the builder from rushing . however , In fact, using this function may be more expensive for the proposer , Because it may reduce them from MEV The proceeds from the auction , Because in  crList  The transaction itself may be extracting MEV. therefore , Using this method may motivate proponents to  crList   Use a more complex approach to the construction of , This brings back centralized incentives .

summary

PBS It is an active and developing research field . reduce MEV The risk of verifier centralization is very important for any blockchain seeking to maintain its decentralized nature . however , It is also important to prevent builder centralization from becoming another type of censorship vulnerability .

At this point in time , I prefer hybrid in the short term PBS. Hybrid PBS At present and “ pure ” PBS Get the best of both worlds between models ：

• Even an altruistic proposer can package any other proposer and deal bundle that the packer is reviewing , therefore We have retained the existing anti censorship .
• MEV Extracting the required priority position is auctioned to another group of specialized actors , Therefore, the verifier does not need to touch MEV, such We'll reduce MEV The risk of driving verifier centralization .
• The proposer does not need to execute the block himself , So the verifier can be completely stateless . It means Greatly increasing the block capacity of one layer will become more secure .

In the longer term , Hybrid PBS The problem of and the desire for more abstraction will be the reason to explore the concept of assisted execution blocks , They will be built in parallel with the main execution blocks .

Besides , The arguments in this article offer some interesting reasons , May eventually consider recognizing at the protocol level ERC 4337 Of user operations. In the short term ,ERC 4337 Should be maintained as an additional agreement ERC, Because it will innovate much faster there . however , In the long term , Obviously, write it into the protocol layer , And the explicit recognition of users' intended objects at the protocol layer can provide more choices to ensure that they are free from censorship .