Proposer/block builder separation-friendly fee market designs

Economics
#22

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.

#23

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
#24

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.

#25

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.

#26

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:

#27

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.

1 Like
#28

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.

#29

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.

#30

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.

#31

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.

#32

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

2 Likes
#33

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

5 Likes
Two-slot proposer/builder separation
#34

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 @fradamt.

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

#35

Idea 3 is a simplified version of my content layer proposal:

Design:

  • schedule nodes to continuously chunk up the mempool in approx 1-3 sec chunks, many chunks per block
  • they may be honest or accept bribes/MEVA etc as usual
  • mempool txs are chunked up quickly because only simple tx/account balance validation is required with no need to update state and propogate blocks
  • if a node takes too long chunking because they’ve gone offline or to gain advantage, they get skipped and the next chunk proposer takes over
  • validators must write contiguous content chunks or their blocks fail attestation

You get proposer/block builder separation but with these benefits…

Advantages:

  • Reduced MEV (over 3 secs attackers only have around 70 txs to reorder/censor/exploit vs hundreds of thousands in the mempool currently)
  • Therefore also lower user costs (MEV is a big reason gas fees/bid prices are so high. Users currently have to compete against their attackers)
  • We can still run GPAs if it feels like too big a change not to for now, but there is far less to auction off because you are only bribing order within a 3 sec window not over many hours worth of txs
  • Users hate having to set gas prices and you could then drop GPAs entirely for an improved UX. Now that content is enforced by attestation you may just be able to use the eip1559 basefee and drop the tip
  • UX is also improved with tx order becoming visible while txs are still in the mempool as well as less or no gas price variance
  • Transactional data integrity is improved, which benefits all Ethereum use cases
  • The centralizing effect of algorithmic sophistication @fradamt raised is eased as you only need to mine opportunities from 70 txs not combinations of 100000+ and so don’t need a MEV farm

This first version of the content layer can then be updated over time to encrypt txs and then later to fair order them.

There’s our roadmap for solving MEV for our users, and for showing the SEC that we are taking frontrunning seriously. But this first version is much simpler and I think represents a big improvement straight away. I’m planning to quantify this.

(the embedded links are for an earlier random order version not this simplified version, and are just to explain the concepts)

5 Likes
#36

Yes you are right in your understanding. This is exactly what I’m pointing at- the proposer/builder separation is not sufficient to solve the issue with the pure gain transactions.
Thus the more prospective way to solve the MEV issue can be to restrict the proposer’s ability to extract the value, instead of making everyone potentially able to perform an extraction.

There is more to this. Because the proposition with the most profitable block require significant amount of computations with algorithms which could be proprietary and kept secret, we may end up with a “winner takes all” situation. One proposer with the most advanced knowledge can be authoring overwhelming majority or even all blocks on the network and use this advantage for their own intents.

1 Like
#37

I used to be worried about this, but I’m actually less worried now! The reason is that censorship is very uneconomical for the censor: if you censor some set of transactions, then someone else will outbid you by including them, and if you want to keep censoring them you would have to outbid them, which would require you to keep burning money every single slot.

But if this doesn’t satisfy people, there is always the option of allowing the proposer themselves to add a small number of transactions if they wish.

1 Like
#38

In a scenario where there are very few searchers who create all the blocks and there’s collision between those searchers, I believe censorship means that a transaction would need to offer a fee higher than all the MEV in an entire block to win the block auction and get included, right?

I think a proposal where the proposer is always filling up the block with transactions is important… I don’t think it should even be optional. Say something like only 50% of a block is allowed to come from a searcher?

1 Like
#39

If blocks are small, and there are many different contracts allowing different types of MEV extraction, there will be block-builders specializing in extracting profits from very specific and rare contract transactions. They will only compete seriously for the blocks in which such transactions appear, which is only a small part of all blocks. When such transactions appear, they dominate the MEV for the block.

However, if blocks are larger, such that many types of MEV transactions happen in every block, then block builders need to excel at extracting revenue from all of them to become competitive, and cannot specialize. This may lead to centralization. A high-level block builder may even run a secondary auction for slots (or partial ordering rights) at his own block, aggregating information from specialized MEV (that would not know how to extract enough MEV from the full block). A small number of such high-level block builders may come to have a significant market share in this scenario.

1 Like
#40

Profiting from censorship doesn’t require permanently blacklisting the transaction. There’s many scenarios where a censor can profit by delaying even for a single block. For example let’s say you’re an LP at Uniswap or a major DeX. A very large order comes in, which moves the price substantially but results in large LP fees.

The ability to punt for one or two blocks is enormously valuable. You can watch the price discovery process run faster at the short-block time L2s or continuously at the centralized exchanges. If the price move disperses and holds, a strategic LP can flash out liquidity, avoiding the impermanent loss/adverse selection. If the price move doesn’t hold, the LP can keep his position firm and collect the fees on the order. The value of this ability is enormous. In FX markets, it’s called “last look” and participants pay huge amounts of money for the privilege.

3 Likes
#41

Good points, as ever @Mister-Meeseeks.

I posted about this on another thread, but when you consider the value contained on an L2 rollup (many thousands of txs) censoring via MEVA is cheap.

Those L2 txs will necessarily interact with pools on L1 and to bridge other L2s and chains. The MEV opportunities from censoring an L2 for just one block and frontrunning all its txs on L1 are mind-boggling.

I used to think that L2 might ease MEV. I’m beginning to see that without protocol level mitigation it will raise it by orders of magnitude.

L2s will need to own a large number of validators to mitigate the negative impacts of MEVA.

3 Likes
High-frequency trading and the MEV auction debate