Partnered With:

Vitalik: How to solve the MEV problem under PoS

Read this article in 17 Minutes

One major risk threatening the continued decentralization of consensus networks is the economics surrounding miner extractable value (MEV), the complex art of extracting profit from the ability to choose what goes into the next block.

Original title: "V God's Latest Thinking: Two Ways to Solve the MEV Problem under the PoS Consensus Mechanism"

Original Author: Vitalik Buterin

Original Translation: Overnight Porridge, Babbitt

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

A major risk that threatens the continued decentralization of consensus networks is the economics around miner extractable value (MEV), which is a complex trick to profit from the ability to choose the content of the next block. Here is a simple MEV example: arbitrage all chain decentralized exchanges for price changes that have occurred since the last block. While general PoS rewards are fairly equal, as a single validator has the same rate of return as a strong validation pool, there are significant economies of scale in finding complex MEV extraction opportunities. In simple terms, a pool that is 10 times larger has 10 times more opportunities to extract MEV, and it can spend more energy optimizing to extract more from each profit opportunity. In addition to this problem, 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 reduced to picking the bundle with the highest fee, an algorithm that is so simple that in a decentralized pool it can even be done within the MPC to prevent fraud.

This post proposes some designs on how to achieve this.

See also 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 properties:

1.Untrusted Proposer-Friendliness :There is little or no risk that a proposer could cheat a block builder, so there is no incentive for a block builder to choose a proposer with a certain off-chain reputation or a personal relationship with a builder (as this would favor large pools).

2.Untrusted Builder-Friendliness :There is little or no risk that a block builder could cheat a proposer, so there is no incentive for a proposer to choose a builder with a certain off-chain reputation or a personal relationship with a proposer (as this would make 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.Bundle packages cannot be stolen:Proposers should not be able to accept bundle packages proposed by block builders and extract transactions from them to make their own bundle packages, thereby preventing block builders from profiting (and potentially further harming them).

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

Idea 1

1. Block builders generate bundles and publish 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 selects 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 a proposal containing that bundle header.

3. After seeing the signed proposal, the block builder that provided the included bundle header will publish the full bundle.

At this point, the fork choice rule has the ability 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 builders themselves do not receive any fees or earn MEV themselves).

Analysis

Three of the five properties are easy to satisfy:

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 bundle unstealability;

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

Proposers can't see bundle contents, and can't cheat block builders via bundle stealing, but they can use more subtle attacks against block builders. They can publish their proposal at the end of a slot, ensuring that the prover (likely) sees the proposal on time, but not giving the block builder enough time to publish the body, so there's a high chance that the prover doesn't see the body on time. This creates risk for block builders and an incentive for them to favor trustworthy proposers. Additionally, it creates an opportunity by which a malicious majority can heavily penalize block builders they don't like.

There are two mitigations I see for this problem:

1. 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, although the basic problem of block builders being at risk of losing funds still remains. Furthermore, it is unclear whether it is incentivized for attesters to vote in this way (although they could be forced to wait by requiring them to prove a 2-second-long VDF solution to the 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) payoff of (0.05, 1);

(2) The proposer or attestor publishes too late, causing a block with only a header to be accepted, in which case the payoff is (-0.5, 0.5);

Idea 2

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

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

3. Upon seeing the statement, the selected block builder publishes their 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 publishes a proposal that is not on the list (within the same slot time period).

Also note 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 builder of that bundle, so that only the builder knows whether they were accepted. This reduces the risk of DoS attacks.

Analysis

Again, three of the five properties are easily satisfied:

The proposer cannot steal bundles, because they can only see any bundle body if they have restricted themselves to a limited set of existing bundle headers.
No payment from the builder to the proposer can occur without including the full body, so the proposer cannot financially cheat the builder either.
The consensus properties are the same as before, because the system is still a game where the proposer is the last mover, and there is no change in what the consensus rules dictate.

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 body of any of them. If proposers have an upper limit on how many bundles they 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 difficulty is to rate limit bundle header submissions in some way that is not a hard limit.

1. The fee for submitting bundles, adjusted to a certain rate (e.g. 8 bundles per slot) via some mechanism like EIP-1559.

2. A deposit requirement as a block builder, and a rule that if a lower priced bundle is included and yours is not, then you cannot submit a bundle for the next N slots.

The fee itself may also only be charged if your bundle is not included but the lower priced unblock bundle is, as this is a specific case where you may 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 charging a 0.5% loser fee to discourage people from bidding when they clearly won't win (just to increase the amount the winner has to pay).

However, these techniques run the risk of introducing trust requirements on proposers, so this needs to be done carefully and the penalty for failing to get a bundle included cannot be too high.

Another solution is to allow free and unlimited bundle corpus publishing, but limit corpus propagation at the network layer. A simple algorithm is:

Add a slight delay to the minimum time that the body of a bundle 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

seconds.

Add a rule that a node does not broadcast a bundle body if it has already broadcast a higher-income bundle body.

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

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 others. 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 by 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 one is better.