Another point, even the profit itself should be dynamic and not consistent
One quick clarification: the 0.05 is not a hardcoded number, it was simply an example. In reality, the profit rate for block builders would be set by the market; I expect it to be low in a competitive environment.
If MEV carries over to the next block and it’s controlled by a honest proposer then the protocol achieved its goal despite the delay. But if the colluders that performed the 0.5 fee attack are also a large pool of potential proposers (think coinbase-sized staking farms), they have a relatively high chance to control the next slot. Their strategy in this case would be to stall slots by spending 0.5 until one of their proposers is selected.
This attack wouldn’t have been possible with the pre-separation protocol because even a large staking farm can’t stall the chain effectively. With this change a stalling attack might become a viable strategy during high MEV circumstances.
It seems that any design that enables stalling attacks would violate Weak proposer friendliness by favoring large pools. Does it make sense or am I totally off the mark here?
The only way I see to mitigate this attack in the context of idea 1 is to increase stalling cost exponentially with each bad slot:
fee but sends conditional_fee = fee*2^num_of_consecutive_bad_slots
fee in any caseconditional_fee - fee if slot is badconditional_fee - fee to builder if not burnedI think the fee for a stalling attack might end up being quadratic naturally. The reason is that as more blocks come up, the attacker would need to keep outbidding legitimate block builders, and legitimate block builders would be making higher and higher bids as the number of unclaimed transactions piles up. So the per-block cost to the builder would be increasing in time (linear in time if demand is constant and either (i) there was no block size cap or (ii) elasticity = 1), and so the total cost would be something close to quadratic.
The protocol doesn’t control the profit and can’t even calculate it. This is MEV profit and may only become apparent in hindsight when the block builder’s MEV strategy is analyzed. For well known strategies the profit will be low due to a race to the bottom, with block builders competing by offering a high fee for their block to be included. Basically a MEV auction. For new strategies or ones that can’t be replicated easily (e.g. requiring large holdings of an illiquid governance token), profit can be very high for a short time.
Yes. I was just thinking about that too. Fees will keep increasing linearly but the attacker has to pay 0.5 * the sum of fees for the stalled slots. It’ll only make sense in rare opportunities of knowledge-asymmetry such as when implementing a new MEV strategy that others haven’t identified yet, to prevent frontrunning its first shot.
But any reason not to make it exponentially expensive based on the length of the stall? Under normal conditions a stall of more than 1-2 slots seems unlikely, so the exponential cost will only kick in during an attack.
I would say the main reasons to consider staying away from that are:
I think (correct me if I am wrong) that the incentive to move to a layer-2 super-protocol would be a strategy in any case, so it doesn’t need a special event (e.g., few rounds of stalling) to happen.
If we separated the rewards from penalties, it would be a very rare case to have few rounds of stalling because its cost would be very high (quadratic or exponential as you explained).
Thus, attacking the protocol is a loosing strategy (unless the malicious player does not care about incentives but it only cares about taking down the protocol).
I think that the attack on the protocol and making builders quit because of unprofitable auctions have the same overall effect. However, the latter has a more probability of happening. So, we need a tradeoff between the two.
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.
Could you apply a delay to block building instead of the block attestation?
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:
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:
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
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
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.