Proposer/block builder separation-friendly fee market designs

Agreed. We should go with the simplest protocol that satisfies the five properties. I hope the market/fee based mitigation can achieve it.

I don’t know if it would come to that, since each proposer would probably run its own local builder to handle cases where it gets selected and no one else submits a block. Whether it creates a sub-optimal block or just proposes an empty (but valid) block doesn’t matter. Either way it breaks the stall chain and resets the conditional_fee. Long stall-chains will be too rare to justify developing a layer-2-super-protocol when it’s easy to just break the chain with a local builder.

But you’re right - keep it as simple as possible as long as it satisfies the requirements.

BTW another mental shortcut for thinking about Idea 1, with the attester-enforced body acceptance delay:

Think of it as a blockchain where there are “full-slot” and “half-slot” blocks; a block with slot n+0.5 can follow a block of slot n. Full-slot blocks are “regular” block-proposer-proposed blocks, and contain consensus data and the hash of a body. Half-slot blocks contain the body, and can only legally contain the body whose hash was in the preceding full-slot block. The significance of calling the body a separate block is that this makes it clear that the time limit for accepting the body should be half a slot later.

2 Likes

Could you apply a delay to block building instead of the block attestation?

  1. Block builders make bundles, evaluate a VDF with a hash of the bundle as the input. A bundle header contains a commitment to the bundle body, the payment to the proposer, a signature from the builder and the VDF proof. The builder publishes both the bundle and the header.
  2. The proposer chooses the bundle+header that offers the highest payment, and is valid (including verifying the VDF proof). They sign and publishing the bundle+header.

If the VDF takes greater than half the slot time to evaluate then the proposer won’t have time to re-arrange the block and create a new valid header. This will also mean that the proposer wont see any blocks until they’re half way through the slot.

This sounds like it would mean that a bundle cannot be created until half a slot after the previous proposal, but I don’t see how it prevents the proposer-griefs-block-builder attack. The proposer’s attack is just not publishing the header until too late. The attack where the proposer makes two conflicting headers is already penalized by slashing conditions.

The bundle is available at the time the proposer makes their choice, the builder provides both the bundle and the header at the same time. They can do this because they can be sure that the proposer won’t have time to rearrange the block. The proposer then has no excuse for not publishing the bundle. So it’s not valid for the proposer to propose a header without the corresponding block.

This fork choice rule is no longer valid:

Maybe I am missing something, but I do not really understand the idea.

I understand that if the proposer and the builder are independent different entities, it would improve manipulation resistance. But how do you prevent the same entity from registering as both a proposer and a builder?

Even if there is an auction, and the proposer is required to select the winner, the proposer will arguably be able to make the highest bid and win. In general, the most effective MEV extractor will always win, because she will be able to offer the highest bid.

But how do you prevent the same entity from registering as both a proposer and a builder?

The goal is not to prevent this. The goal is to make it possible to be a proposer without being a builder.

I see.

So the problem is that the block proposer is not sharing money with the pool.

One unfortunate weakness is that if I am MEV extractor, then using a scheme like described above will force me to leak information about MEV value extracted. If I found a new way to extract MEV I may not want other people to even know extraction is possible. So I may just bid a little higher than others and pay the rest to the proposer privately.

A much better scheme as I mentioned before is to use threshold encryption by a committee. There is simply no MEV under threshold encryption. A Uniswap running under threshold encryption scheme will be way more attractive for users since there will be no hidden fees due to MEV.

On the turing-complete chain both ideas, while doing good for the network itself, still causes MEV losses to transactors. While sometime these losses are in form of just hidden costs (for example trade sandwiching), but in case of pure gain transactions (transactions resulting in value increase as the result of their execution) MEV will destroy the gain opportunity for the original transactor, which is clearly a griefing bechavior. With the proposer/block-builder separation as it is proposed, a non-proposer effectively can not have their pure gain transaction executed successfully.

At the same time, on an application-specific layer2 protocols may introduce additional rules to make the MEV itself provably impossible. To achieve it, block builders should not have information required to perform the MEV, or have no control to execute actions required (like altering transaction order or insetring new transaction into the proposed block). Proposal propagation may be a part of the layer2 protocol itself.

Such protocols may compete with the apps on the layer1 by providing better conditions to transactors who will not suffer the hidden costs and will be able to profit from the pure gain transactions.

I’m afraid that penalizing proposers for missing bodies may allow a bad equilibrium in which the following happens:

  1. A single pool of block builders is responsible for a very large proportion of all blocks.
  2. The pool subsidizes malicious block builders to generate griefing attacks outside the pool.
  3. Rational proposers notice a large proportion of blocks coming from outside the pool are malicious, and therefore give fee discounts to blocks from inside the pool.

Because of (3), the pool is able to maintain its high proportion of all blocks of (1) and make outsized profits that are more than enough to pay for (2).

It may be relatively easy for a malicious pool to acquire a large proportion of all blocks if it is willing to have some losses to do it, for instance paying 1.03 for a block that generates 0.99 in profits. If this allows the pool to build 75% of all blocks, this will cost 0.03 per block on average. If it then tries to attack 40% of the remaining blocks (~10% of all blocks attacked), this will cost about 0.50 per block or 0.05 on average. So the total cost of running this strategy will be 0.08 per block.

At the same time, rational proposers will now see 40% of griefing attacks for blocks outside the pool, meaning they will become willing to give a 20% fee discout to blocks from inside the pool, meaning they will accept blocks for 0.83 instead of 1.03 (and continue making 0.99 in profits out of it). If all proposers are rational, the pool will now make 0.12 on average in block profits, more than enough to cover the 0.05 on average for the griefing attacks.

The attack may be theoretical, however, because:

  1. Proposers are unlikely to be rational in the short-term, so the attacking pool may have to maintain the large block proportion and the griefing attacks for a long time before a significant proportion of proposers start accepting blocks from the pool at a discount.
  2. Other pools will appear and stablish their own reputation for not griefing, but without sponsoring malicious attacks. These may “free-ride” on the fee discounts generated by the fear of griefing without paying their “fair-share” of the griefing costs.

This is analogous to the attack described above in which (if I understood correctly) a large pool of proposers may sponsor griefing attacks in order to discourage competitors. That attack too is theoretical in that competing proposers will just start looking at trusted block builders instead.

If I understand you correctly, what you call “pure gain transactions” are already almost impossible. If you send one publicly, you will be frontrun by generalised frontrunners (which could even be run by the miner/proposer, giving you 0 chance of succeeding), if you send it through Flashbots you’ll need to give most of the profit away as a bribe. The problem is not the proposer/builder separation, because even without it proposers are free to extract all the value they can, and eventually they would do it

1 Like

I am a bit worried about the possible consequences of changing PoS into “Proof of MEV extraction” (which I’ll just call PoM from here on). By this I mean that the actual builder of a block would be chosen in that way, regardless of the fact that the proposer is chosen in the normal PoS lottery.

The main issue I see is that PoS (as PoW) distributes outcomes uniformly over the global pool of resources, but PoM does not. If someone has 1% of the stake, in PoS they’ll get to build 1% of the blocks, but in PoM there is no clear way to have (probabilistically) guaranteed access to a small percentage of the blocks by committing an equivalently small percentage of the globally committed resources, because it’s not a brute force search but one where algorithmic sophistication makes a huge difference. The problem with a game dominated by the latter is that “a little bit of algorithmic sophistication” does not get a little bit of the blocks, it doesn’t get almost any of them, and that access to “sufficient algorithmic sophistication” is a much higher barrier of entry than some capital and a little bit of technical knowledge (as in PoW or PoS).
How many entities even are there that could truly compete in such a game? Assuming there’s not many, PoM could end up hugely centralising block production, which is obviously very problematic

1 Like

100%. MEV is the reason doing business on Ethereum is so expensive, it’s not all about scaling. Users must literally bid against their attackers.

Because MEVA maximizes rather than reducing MEV it increases overall user tx costs (auction bid + MEV extracted).

Worse, it complicates UX. Users now don’t know whether they should put a high gas price in or bid to win a MEV auction directly with Flashbots or through an aggregator. Without a cutting edge MEV mining rig, they can’t possibly know. Because of this, they will often be paying twice, eg: they might raise their gas price to get included and then get frontrun anyway.

Good points about PoM too @frankdfr.

I’m putting together an alternative proposal which I will post here shortly.