Vitalik: How can we restrain builders and minimize the responsibilities of the proposer?

A natural reaction to the risks of centralization in builders (mainly censorship, but also various forms of economic exploitation) is to try to limit the power that builders have. Instead of builders having full authority to build an entire block after winning the auction, builders would have more limited power. This power should still be sufficient to capture almost all MEV that can be captured, and ideally still sufficient to capture the other benefits of PBS, but it should be weakened to limit the opportunity for abuse.

This idea is sometimes called a partial block auction: instead of auctioning the right to decide everything in the block, you auction the right to decide certain things, and these “certain things” can be more subtle than “the builder chooses the first half of the block instead of the second half”: you can give the builder the right to reorder, pre-order, append, and you can even constrain the proposer. This article introduces some possible methods and the resulting trade-offs.

In the inclusion list model, the proposer provides an inclusion list, that is, a list of transactions they require to be included in the block unless the builder can completely fill the block with other transactions.

For a builder who is not influenced by unusual external incentives to maximize profits, the inclusion list is not a constraint at all: adding an additional transaction at the end of the block always brings the builder the priority fee of that transaction as additional profit.

In the case of the block being filled (twice the target), so the builder will have to choose between this transaction and other transactions, this constraint is disabled. In the long run, this does not affect inclusion because the operation of full blocks can only be sustained briefly as it causes the base fee to rise exponentially (every 6 blocks ~2.02 times).

However, if a builder does have some desire to refuse to include specific transactions that they disapprove of or are incentivized to exclude, that builder will be forced to not participate in the auction.

This design is quite simple, but it is important to describe some of its weaknesses:

1. Incentive compatibility issues: The builder sees the inclusion list in advance, and the builder can refuse to build a block with an inclusion list that they do not want to build. This directly incentivizes the proposer to have an empty inclusion list to maximize the builder’s chances of building a block for them.

2. Additional burden on the proposer: The proposer needs to be able to identify paid transactions. This requires (i) access to the mempool and (ii) the ability to read the state to determine the payment fees, or be connected to a witness of the transaction. The witness is the best because they will retain the attributes of PBS, that is, the verifiers can be stateless clients.

3. Builders can still engage in some abusive behavior: particularly sandwich attacks. However, it is not clear how this problem can be eliminated without taking extreme measures, such as using advanced cryptography to encrypt the mempool, because otherwise taking this power away from the builder means giving it to the proposer, which would incentivize the proposer to join the equity pool.

4. Partial compliance is required for account abstraction to work: see The Road to Account Abstraction – HackMD 11.

Another construction is to allow the proposer to create a suffix for the block. The builder does not see any information about the proposer’s intentions when building the block, and the proposer can add any transactions that the builder has omitted to the end.

1. Reduced incentive compatibility issues: The builder can still retrospectively punish the proposer for including transactions that the builder disapproves of (for example, by refusing to build for them in the future) and send the root to the builder. This is inevitable, but it is much more proposer-friendly than the builder being able to refuse to build a block in real-time (especially since each individual proposer only proposes occasionally, now once every two months).

2. Even more additional burden on the proposer – the proposer now has to calculate the post-state root, which means the proposer must hold the entire state. Therefore, there is no statelessness unless the proposer outsources this task to a separate intermediary.

3. Between getting a response from the builder and having to publish the block, the proposer gets some MEV opportunities. This may only be worth half a second, but it still increases the verifier’s motivation to join the equity pool to be able to optimize internally.

4. Builders can still engage in some abusive behavior as before.

5. As before, partial compliance with account abstraction work is required.

A fix for the proposer’s suffix: pre-commitment

The proposer pre-commits to a Merkle tree or KZG commitment or other accumulator of the set of txs they want to include. The builder creates their block. Then, the proposer must add a suffix that exactly consists of a subset of the Merkle tree that the builder has not yet included, and the gas limit allows them