MEV burn—a simple design

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.

1 Like

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 :frowning:

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.

2 Likes

Exactly, there are two auctions :slight_smile:

This is a common fear that I would argue is a common misconception :slight_smile: 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.

2 Likes

This is a common fear that I would argue is a common misconception :slight_smile: 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.

1 Like

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

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.

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

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.

1 Like