Vitalik Buterin’s latest thoughts: Two ways to solve the MEV problem under the PoS consensus mechanism

Special thanks to Justin Drake and the Flashbots team for feedback and discussions.

A major risk that threatens the continued decentralization of consensus networks is around the economics of Miner Extractable Value (MEV), which is the complex art of extracting profit from the ability to choose what goes into the next block. A simple MEV example is arbitrage across all on-chain decentralized exchanges for price changes that have occurred since the last block. While general PoS rewards are fairly egalitarian, as a single validator receives the same return as a strong validator pool, there are significant economies of scale in finding complex MEV extraction opportunities. Simply put, a pool that is 10 times larger has 10 times the opportunity to extract MEV, and it can spend more energy optimizing to extract more from each profit opportunity. In addition to this issue, MEV complicates decentralized pools, where there is still an entity responsible for packaging and proposing blocks, and they can easily extract MEV in secret without splitting revenue with the pool itself.

The most well-known solution is the proposer/block-builder separation. Instead of block proposers trying to produce revenue-maximizing blocks themselves, they rely on a market where external participants, whom we call block builders, produce bundles containing the full block content and proposer fees, and proposers choose the bundle with the highest fee. The proposer's choice is simplified to picking the bundle with the highest fee, an algorithm so simple that in a decentralized pool it can even be done within an MPC to prevent fraud.

This article proposes some designs on how to achieve this.

See also these ideas from 2018 which are closely related to the ideas here: Optimised proposal commitment scheme

Desired properties of proposer/builder separation block proposal design

We will focus on five main desired attributes:

1. Trustless proposer friendliness: There is little or no risk for proposers to defraud block builders, so block builders have no incentive to choose proposers with a certain off-chain reputation or personal relationship with builders (as this will favor large pools).

2. Trustless builder friendliness: There is little or no risk of block builders defrauding proposers, so proposers have no incentive to choose builders with a certain off-chain reputation or personal relationship with the proposer (as this makes it harder for new builders to enter the market). If a deposit is required to achieve this, the threshold should be minimized.

3. Weak proposer friendliness: The mechanism should not require proposers to have (i) high bandwidth or other computing resources or (ii) high technical complexity.

4. Bundles cannot be stolen: Proposers should not be able to accept a bundle proposed by a block builder and extract transactions from it to make their own bundle, thereby preventing block builders from profiting (and potentially further harming them).

5. Simplicity and security of the consensus layer: From a consensus layer perspective, the mechanism should continue to be secure and preferably subject to the same analysis as the existing block proposal mechanism.

Idea 1

1. Block builders generate bundles and publish the headers of the bundles they created. A bundle header contains a commitment to the bundle body (expected block content), a payment to the proposer, and the builder's signature.

2. The proposer chooses the bundle header that offers the highest payment (only bundles that the builder has enough balance to actually pay for are considered). They sign and publish the proposal containing that bundle header.

3. After seeing the signed proposal, the block builder who provided the bundle header will publish the complete bundle.

At this point, the fork choice rule is able to make one of three decisions (instead of the usual two):

1. The block proposal does not exist

2. The block proposal exists, but the bundle body does not exist

3. The block proposal exists and the bundle body exists

Note that in the second case, the proposal still becomes part of the chain, and crucially, the block builder’s payment to the proposer is still processed (but the block builder itself does not receive any fees or earn MEV itself).

analyze

Three of the five properties are easily met:

1. The proposer unconditionally accepts the promised payment, so the bundle cannot cheat the proposer;

2. All three steps are very automated and low-bandwidth, so this satisfies weak proposer friendliness;

3. The proposer cannot see the contents of the bundle they are signing, so this satisfies the bundle's unstealability property;

The consensus layer properties, and untrusted proposer friendliness are trickier. This design does change how fork choice works, increasing it from 2 options to 3 options, and it also means that the proposer is no longer the last player in the game. In theory, one could infer that if fork choice can make a decision, then this should be good, but it is still a major change with potential unknowns.

Proposers cannot see bundle contents and cannot cheat block builders through bundle stealing, but they can use more subtle attacks on block builders. They can publish their proposal at the end of a slot, ensuring that the prover (probably) sees the proposal on time, but not giving the block builder enough time to publish the body, so there is a high probability that the prover will not see the body on time. This creates risk for block builders and incentivizes them to favor trustworthy proposers. In addition, it creates an opportunity through which a malicious majority can heavily penalize a block builder they don't like.

I think there are two ways to mitigate this problem:

1. There is a 2 second delay between the maximum time a prover can accept a proposal and the maximum time a body can be accepted. This mostly solves the problem if you trust the prover, though the fundamental problem of block builders risking losing funds still remains. Also, it is unclear whether it is incentive-aligned for provers to vote this way (although they could be forced to wait by requiring them to prove a 2 second long VDF solution to a proposal).

2. If a body is not included, the proposer only gets half the payment (and the block builder only pays half). This makes it costly for the proposer to be malicious, but it also ensures that it is still costly for the block builder to be malicious (in both cases, the cost is high enough to make you believe that even anonymous actors would not want to do it). For example, if a bundle has a proposer fee of 1 and a block builder profit of 1.05:

(1) Honest behavior will result in a (builder, proposer) reward of (0.05, 1);

(2) If the proposer or prover publishes too late, resulting in a block with only a header being accepted, the reward is (-0.5, 0.5);

Idea 2

1. Block builders make bundles and publish the bundle headers they created. A bundle header contains a commitment to the content, a payment to the proposer, and a signature from the builder.

2. The proposer chooses and signs a statement consisting of a list of the bundle headers they have seen.

3. After seeing the announcement, the selected block builder will publish its corresponding bundle body.

4. The proposer selects a bundle header from their pre-submitted list and publishes a proposal with it.

There is a new slashing condition that evicts and penalizes any proposer who posts a proposal that is not on the list (within the same slot time period).

Note also that the list of bundle headers submitted by the proposer in step (2) can also be a list of cryptographic hashes of the headers, where each hash is encrypted to the public key of the bundle builder, so that only the builder knows whether they were accepted. This reduces the risk of DoS attacks.

analyze

Again, three of the five properties are easily satisfied:

1. Proposers cannot steal bundles, because they can only see any bundle body if they have restricted themselves to a limited set of existing bundle headers.

2. Without including the full body, payment from the builder to the proposer cannot occur, and thus the proposer cannot financially defraud the builder.

3. The consensus properties are the same as before, as the system is still a proposer-last-mover game, and there is no change in what the consensus rules determine.

Two of the harder properties to ensure in this case are weak proposer friendliness and untrusted block builder friendliness. The concern is that a malicious block builder could attack a proposer by making a large number of proposals that all offer very high fees, but never publishing the bodies of any of them. If the proposer has an upper limit on how many bundles they will accept, then this attack could price out all legitimate bundles and leave the proposer with no bundles that can be legitimately included in their block. If there is no upper limit on the number of bundles a proposer can accept, then this could result in an unlimited number of full bundle bodies (think 500kb each) being sent to the proposer, which is a huge bandwidth requirement.

One solution to this dilemma is to rate limit bundle header submissions in some way that is not a hard limit.

1. The cost of submitting bundles, which is adjusted to a certain rate (e.g. 8 bundles per slot) through some mechanism similar to EIP-1559.

2. Deposit requirements as a block builder, and a rule that if a bundle with a lower price is included and your published bundle is not included, then you cannot submit bundles for the next N slots.

The fee itself may also only be charged if your bundle does not include it, but a lower priced bundle does, because this is a specific case where you might be acting maliciously (either the proposer is malicious or the network is broken at the time).

There is precedent for this, such as the ENS auction which charges a 0.5% loser fee to discourage people from bidding when they clearly won't win (only to increase the amount the winner has to pay).

However, these techniques run the risk of introducing trust requirements on the proposer, so this needs to be done carefully, and the penalty for failing to include a bundle should not be too high.

Another solution is to allow free and unlimited distribution of bundles, but restrict the distribution of bundles at the network layer. A simple algorithm is:

1. Add a slight delay to the minimum time that the bundle body can be propagated: the highest paying bundle has a delay of 0 seconds, the second highest paying bundle has a delay of 0.2 seconds, the third highest paying bundle has a delay of 0.38 seconds, and the Kth highest paying bundle has a delay of 0.

Second.

1. Add a rule that a node will not broadcast a bundle body if it has already broadcast a higher-order bundle body.

These two techniques can be combined: you could charge a small fee to reduce the expected number of bundles to (say) 50 per slot, and then use network layer mechanisms like this to further reduce bandwidth requirements.

in conclusion

As of now, I am not sure whether the above two approaches are the only way to solve the problem, and there may be other approaches. Of the two approaches, idea (1) is conceptually simpler, but it brings risks to block builders and more complex fork choice rule requirements.

While idea (2) is simpler from a fork choice and consensus perspective, it has challenges in dealing with DoS attacks from malicious block builders, and any solution to that problem is likely to create other problems as well (although this can conceivably be minimized). So far, I’m still not sure which approach is better.