MEV burn—a simple design

[CometShock]

@JustinDrake

Builders do not directly benefit from a low payload base fee floor Naively (i.e. assuming no kickback from the proposer) builder profit margins are invariant to the payload base fee.

My assumption is that kickbacks from proposer to selected builder are inevitable. The proposer wants all the builders to privately submit so that some of what would’ve been the payload base fee floor is instead captured as proposer revenue. It’s very natural that proposers would provide kickbacks to selected builders to incentivize this structure.

@JustinDrake

Notice that a public-good builder (e.g. a hypothetical “ultra sound builder” ) that wants to set a baseline payload base fee floor wouldn’t necessarily need to be good at capturing MEV spikes. They only need to be good at predicting what the payload base fee floor could be, and then bidding just under that value.

Establishing a word for following response.
Base Fee Overbid: payload_base_fee - builders_extracted_value_from_block when payload_base_fee > builders_extracted_value_from_block

My point is that an “ultrasound builder” who wants to set a baseline payload base fee floor through overbidding would be risking a lot of their balance should they instead be selected. In fact, they could be selected in either two scenarios:

• They predicted wrong and are the most valuable bid, now they lose their base fee overbid to a burn
• A proposer attempting to create a private bid structure selects the public ultrasound builder to call their bluff, now the ultrasound builder lost their base fee overbid to a burn. Rational move in an infinite game with enough relevant information.

My intuition is that the base fee overbidding phenomenon wouldn’t last very long given a few aggressive private-favoring proposers. If the ultrasound builders wanted to remain resilient in the long term, they’d have to become relatively good at capturing MEV spikes. But again, the financial incentive for them to improve their operation is just incomparable to a selfish builder, so the scales are tipped in the selfish favor.

[JustinDrake]

@CometShock

My assumption is that kickbacks from proposer to selected builder are inevitable.

Ok perfect, let’s try to analyse that scenario

• setup: There are precisely k builders (e.g. k = 2) that are capable of extracting a piece of non-commoditised MEV (e.g. 0.69 ETH from an exotic CEX-DEX arbitrage). The proposer has setup a coordination device (e.g. some fancy SGX, MPC, smart contract—you name it) to partially kickback some of the non-burned MEV to the builders.
• claim: The builders are better off bypassing the proposer altogether, with or without MEV burn.
• intuition: Indeed, one of the k builders can replicate the coordination device to fully kickback all of the non-burned MEV to the builders. For example, this coordination device could be an SGX enclave to which builders privately submit bids, and which only publicly outputs one bid which maximises value for the builders.

If you still believe the proposer can provide special coordination services with kickbacks for the builders, it would be helpful to describe such coordination services in more detail.

[ballsyalchemist]

@JustinDrake

Builders do not directly benefit from a low payload base fee floor Naively (i.e. assuming no kickback from the proposer) builder profit margins are invariant to the payload base fee.

The proposer and builder will indirectly benefit from colluding privately to lower the base fee floor (base fee takes away the MEV that could have benefitted proposer & MAYBE builder with kickback). Even with a public-good builder who attempts to set the base fee, which imo wouldn’t be as reliable as an assumption, builders with more orderflow (possibly private orderflow) can circumvent the base fee. Furthermore, this could incentivize the creation of a private bidding marketplace on the side for builders attempting to bribe proposers. In that case, as @CometShock suggested, floor can still be suppressed while proposers continue to capture the lion’s share of MEV as usual.

[CalabashSquash]

@JustinDrake

If all the builders capable of extracting a given piece of MEV are colluding then the optimal strategy is to not bid at all for that piece of MEV, even within the D seconds tipping window. Instead, the cabal of builders is better off coordinating to distribute the MEV among themselves, a strategy possible with or without MEV burn.

Is somebody able to explain this a bit more? Mostly: How would they distribute the MEV among themselves without bidding at all?

Thank you.

[Pintail]

Is this proposal compatible with a proposer suffix scheme whereby censorship resistance is enhanced by permitting the proposer to include transactions after the builder releases the payload? In your view would this be desirable?

Given then number of steps involved in the builder auction, do you think this proposal would require an increase in block interval?

[JustinDrake]

@CalabashSquash

Is somebody able to explain this a bit more? Mostly: How would they distribute the MEV among themselves without bidding at all?

Colluding builders would need some sort of coordination technology—could be legal, smart contract, SGX, blind trust, etc. The way builders collude is an implementation detail.

@Pintail

Is this proposal compatible with a proposer suffix scheme whereby censorship resistance is enhanced by permitting the proposer to include transactions after the builder releases the payload?

Yes, this proposal is compatible with inclusion lists (see also section titled “inclusion lists” under “part 3: technical remarks”). My favourite design is called forward inclusion lists:

• list means it’s an unordered list of transactions
• forward inclusion means the next builder must include the transactions (up to the gas limit)

@Pintail

a proposer suffix scheme

An important detail with inclusion lists is whether the list is ordered or unordered. The word “suffix” suggests that the list is ordered and must be included as-is in the block. The problem with ordered lists is that they allow the proposer to extract MEV, which incentivises the proposer to be a builder and defeats the purpose of PBS. My favourite inclusion list design so far allows for both reordering and insertions by the builder (but no deletions!).

@Pintail

In your view would this be desirable?

Inclusion lists for censorship resistance is important to derisk the potential outcome where top block builders are censoring. (Thankfully the top two builders—builder0x69 and beaverbuilder—are not currently censoring.) Inclusion lists are even more important with MEV burn because of the reduced discretionary power of proposers to choose the winning bid.

@Pintail

Given then number of steps involved in the builder auction, do you think this proposal would require an increase in block interval?

MEV burn does not require any increase in the slot duration beyond what is required for ePBS. Having said that, ePBS itself will almost certainly require an increase in the slot duration. This is because, as you note, there are two rounds of attestations instead of just one.

In practice ePBS likely requires single slot finality (SSF) which would add yet another round of attestations (for a total of three rounds of attestations per slot). My best guess is that the slot duration will have to increase for SSF and ePBS, possibly to something like 32 seconds.

As a side note, the effectiveness of MEV burn increases with larger slot durations (see section “partial burn” under “technical similarities with EIP-1559”). The reason is that the ratio of the parameter D to the slot duration reduces. So if D = 2 seconds and the slot duration is 32 seconds, roughly 93.75% of the MEV would be burned.

[voidp]

Very interesting idea!

@JustinDrake

Rational proposers will want to maximise the payload tip by guessing the payload base fee floor and accepting bids with non-zero tips after the payload base fee floor has been established.

I think I’m missing something basic: why do they need to guess since bids (including base fee) & tips are broadcast publicly?

@JustinDrake

claim: The builders are better off bypassing the proposer altogether, with or without MEV burn.

If by bypassing the proposer you mean the builders can wait to be elected as a proposer by themselves, that may be risky if the MEV opportunity is time sensitive.

[JustinDrake]

@voidp

why do they need to guess since bids (including base fee) & tips are broadcast publicly?

Because rational proposers need to guess the minimal base fee that attesters will accept. Every attester, depending on their connectivity to the bid pool and their clock skew, may enforce a different payload base fee floor.

@voidp

If by bypassing the proposer you mean the builders can wait to be elected as a proposer

I mean the builders can collude among themselves so that the MEV does not go to proposer.

[wanify]

Thanks for the great write-up!
Will attesters only accept the highest payload base fee they watched as the payload base fee floor? Or do they have some flexibility? (For instance, could they consider accepting a fee that is 90% of the highest observed fee, or perhaps even the second highest base fee.)

[bertmiller]

Thanks for a very interesting design @JustinDrake

Right now MEV-Boost and MEV burn have a first price account with public bids. I’d like to see more analysis of the trade-offs of other auction designs - for example making the auction sealed bid could be desirable because it prevents strategic bidding (builders watching the p2p layer for bids and incrementally bidding higher) and incentivizes builders to bid their true bid value instead. Moreover, we should explore the second-price auctions as well as an alternative to first price. The tradeoff, of course, is that these introduce more implementation complexity.

[JustinDrake]

@bertmiller

Right now MEV-Boost and MEV burn have a first price account with public bids

MEV burn is largely orthogonal to the auction design. With cryptography (e.g. FHE) one can do sealed bids as well as second-price auctions.

For sealed bidding, bidders encrypt their bids. Whenever nodes in the p2p network or attesters receive two encrypted bids, they locally apply (using FHE) the comparison function which returns an encryption of the largest of the two bids. This allows attesters to produce an encryption of their subjective base fee floor, which can then be force-decrypted (e.g. using threshold decryption or time-based decryption).

Second-price auctions only make sense with sealed bids, and those are also possible with FHE. This time, the comparison function takes three encrypted bids and returns an encryption of the largest two bids.

[bertmiller]

All of that makes sense to me From my perspective the discourse around PBS has mostly assuming first price, public auctions (as exist at the moment) and my intention was to highlight that this is an assumption and one that we should explore alternatives to.

[PatrickAlphaC]

Loved reading this, big question though - sorry if it sounds brash, but would this essentially remove MEV-boost, flashbots, and the likes from the ecosystem?

It seems they would have no place if this was at the protocol level.

[jessiepark]

Loved reading this, big question though - sorry if it sounds brash, but would this essentially remove MEV-boost, flashbots, and the likes from the ecosystem?

It seems they would have no place if this was at the protocol level.

Hello Patrick,

I am Jessie, a researcher at A41, an APAC based organization specializing in blockchain infrastructure services with particular strengths in ecosystem growth and technical understanding of protocols.

I wanted to discuss the concept of ePBS and MEV-burn, which were addressed in the Scourge roadmap shared by Vitalik. Currently, the PBS scheme is not available within the Ethereum network, so Flashbots’ MEV-boost is filling the gap outside the protocol and accounts for up to 95% of the blocks created in the network (This is addressed as the external markets in the roadmap). Therefore, embedding these kinds of schemes will essentially remove outside players like MEV-boost, flashbots, and the likes from the ecosystem, like what you said.

However, there are concerns about centralization within Relays in this external market, and that relying on a single external market could be a single point of failure. To address this, Ethereum is working on adopting PBS within the protocol, known as ePBS in the Scourge roadmap. This integration aims to make the system more robust and decentralized. Nonetheless, implementing ePBS within the network is expected to take more than two years, during which MEV-boost will continue to play a crucial role.

It’s important to note that the implementation of MEV-burn is dependent on the successful integration of ePBS. So, MEV-burn will have enough time to be developed thoroughly and address various aspects before it becomes a reality.

[ethDreamer]

Edit: I’ll keep this post up for anyone else that wants to read. But the questions I had below were largely due to two misunderstandings:

1. In the proposed design, the proposer is allowed to keep the MEV difference between the bid floor (what I called the attested bid) and the bid he selects for the block (what I call the proposed bid).
2. While the builders are not directly incentivized to gossip competitive bids (what I called participating in the attester auction), they’re not dis-incentivized from doing this either. The value of bids from builders are already public today, so builders are not giving up information by gossiping this.

Original post below:

Forgive me if I’m misunderstanding, but I feel like something needs to be clarified here.

• non-colluding builders: If one of the builders capable of extracting a given piece of MEV defects by bidding there is no benefit for any of the builders to bid late. If anything, late-bidding builders risk not having bids reach the proposer on time.

It’s worth being explicit about the fact that the builder who submits the bid with the highest base fee (as chosen by the attesters D seconds before the slot), does not necessarily win the right to build the block. In other words, another builder could still bid higher after the cutoff & win the auction. This must be the case, as awarding the proposal rights to the winner of the attester auction removes the whole purpose of having a proposer. It would also result in increased re-org probabilities. The whole purpose of having a gap D is to stop split views of the top bid from creating forks.

But having a delay means there are really two auctions:
the attester auction: where the winning bid (the attested bid) is selected by attesters
the proposer auction: where the winning bid (the proposed bid) is selected by the proposer

We would expect these to often be different bids as the proposer auction takes place several milliseconds after the attester auction which usually corresponds to more MEV. There is incentive for proposers to engage in off-chain agreements with builders here as proposers can extract the value difference between the proposed and attested bids.

Suppose we reflect this on chain by allowing the proposer to submit both bids. In a similar way, the attesters enforce that the attested bid matches at least what they see as the attested bid & the attested bid is burned. The proposer will want to wait a small delay past the cutoff before selecting the attested bid to ensure that gossip latency won’t cause them to under shoot the attested bid. But we also allow the proposer to submit the proposer bid & extract this difference. This could remove much of the incentive for the proposer and builder to collude. By including the attested bid, the chain can know who won the attester auction. It’s also worth noting that these bids could be the same.

This won’t work because the proposer could create their own bid and say they won the attester auction

With that out of the way, let’s revisit this statement:

If anything, late-bidding builders risk not having bids reach the proposer on time.

Here we are incentivizing the builder to participate competitively in the attester auction by assuming that they risk losing the proposer auction if they don’t submit a competitive bid by the cutoff. But that risk is a function of the gap between D and the gossip bid delay. The larger this gap, the lower the risk, and this gap can be artificially increased by using out of protocol relays that enable low-latency connections between the proposer & builder. It’s also just generally sub-optimal to rely on optimal tuning of timing parameters for security.

It would be better if there were economic incentives for winning the attester auction. One way to do this is to award the winner of the attester auction in this slot some fraction of the MEV burned in the next slot.

[JustinDrake]

@ethDreamer

So then there are really two auctions

Exactly, there are two auctions

@ethDreamer

There is incentive for proposers to engage in off-chain agreements with builders here as proposers can extract the value difference between the proposed and attested bids.

This is a common fear that I would argue is a common misconception If a proposer can collude with n builders (for a total of n+1 parties) then the n builders are better off colluding among themselves (without involving the proposer, for a total of only n parties). Now if n builders are capable of colluding then they are effectively one “virtual” builder and any excess MEV that is exclusive to that virtual builder can be extracted by that virtual builder, i.e. it doesn’t have to be reflected in the public bid values. As such, MEV burn doesn’t change the incentives for virtual builders: none of the excess goes to proposers, with or without MEV burn.

[ethDreamer]

This is a common fear that I would argue is a common misconception If a proposer can collude with n builders (for a total of n+1 parties) then the n builders are better off colluding among themselves (without involving the proposer, for a total of only n parties)

I should be more clear, I was thinking more that there’s incentive to use relays simply because of lower latency connections between the builder and proposer. The builders aren’t colluding with each other, they’re just competing more efficiently to win the proposer auction by using relays.

My point in this statement:

There is incentive for proposers to engage in off-chain agreements with builders here as proposers can extract the value difference between the proposed and attested bids

was that if we try to enforce burning of the full proposer bid, this could create an incentive to hide the MEV that the proposer can extract. For example:

The attested bid is 5 ETH
A builder releases a second bid to win the proposer auction for 7 ETH
Another builder has the ability to bid 6 ETH, but colludes with the proposer to bid 5 ETH and the proposer & builder split 0.5 ETH each

It is possible that situations like this could be too rare to justify the upkeep of relays however since most of the MEV should be burned. But either way there’s certainly an incentive to win the proposer auction. And that means submitting the highest bid you can. And because more time = more MEV this means releasing the bid as close to the start of the slot as possible while still getting to the proposer in time, whether that be through a relay or gossip.

[vuittont60]

Spike smoothing yields security benefits. Redistribution yields economic benefits like EIP-1559. It’s a good job.

[namayama]

@JustinDrake

If you still believe the proposer can provide special coordination services with kickbacks for the builders…

I believe the proposer can ‘bribe’ builders to delay their bids using a trustless L1 contract that pays winning builders a share of fees.

The proposer deposits collateral into a BribeContract. BribeContract allows winning block builders to withdraw X% * (base_fee - base_fee_floor) for any block produced by the proposer.
Builders, if they know this contract exists, will rationally wait until base_fee_floor has been set to submit their bids (or otherwise make their bid privately in advance).
More advanced versions using validator withdrawal contracts might be possible as well.

@JustinDrake

If a proposer can collude with n builders (for a total of n+1 parties) then the n builders are better off colluding among themselves

Proposer/builder collusion only requires builders delay their bid (easy). Builder/builder collusion requires builders withhold their bid entirely (hard).

[Nerolation]

@ethDreamer

The attested bid is 5 ETH
A builder releases a second bid to win the proposer auction for 7 ETH
Another builder has the ability to bid 6 ETH, but colludes with the proposer to bid 5 ETH and the proposer & builder split 0.5 ETH each

In this example the proposers wouldn’t care as long as they receive their selected bid minus the burn. If a majority of the attestors are fine with attesting to a block that burns at least 5 ETH, then it wouldn’t matter if another builder bids 6 ETH after the burn floor was set. Only if the proposer thinks that the 6 ETH came before the burn floor was set, he’d would need to also choose a bid that burns at least 6 ETH.
I think the main collusion problem is not setting the burn floow, which would be carried out by colluding builders. Though, this doesn’t get worse compared to the situation today where colluding builders could pressure down the mev boost payments and increase their own profit share as a group.