Mev is centralizing. No amount of trying to ‘manage’ it will change that. Any proposal (like this one) that makes it easier for a single actor to dominate block content worsens the situation. Read the links I gave to see why.
Mev is a reality because the protocol permits it.
If you actually want to decentralize you must include transaction order in the consensus.
Allright, I gave your linked thread a good 20min read. This will be my last comment on this, as I feel it starts to derail the discussion of @thegostep’s proposal.
If you think the best course of action is to ignore MEV, do nothing about it and let the chips fall where they may, don’t beat around the bush and come with an actual proposal on that, including why it’s better to do that than this alternative.
And if you think there’s a third option, by all means articulate it.
But all your criticism of @thegostep’s proposal is also true for letting MEV grow unregulated. With this proposal we will at least know if we are suffering the consequences, as it will not happen in the dark.
In any regard, I do appreciate you thinking deeply about MEV, as it has large potential consequences for us all. So thank you for that!
Thank you for taking the time to read it. I am deliberately avoiding mitigations because I am attempting to do the prerequisite work of defining the true extent of the problem.
The risks of full block MEVA have not only been underestimated, they have barely been explored at all. The result will be catastrophic.
Here’s a fix. If centralized relayers are now acceptable in the eth2 base layer, then why aren’t they fair ordering transactions and solving MEV?
Had a fruitful conversation with @thegostep where we explored another scheme where consensus(validator) is the final actor that submits block to the network.
In this design:
1.) consensus requests ExecutionPayloadHeader from mev_boost
2.) mev_boost returns the most profitable to consensus
3.) consensus signs SignedBeaconBlock which contains ExecutionPayloadHeader and submits it to mev_boost
4.) mev_boost validates block signature and saves the block to escrow to enforce slashing in the event of frontrunning
5.) mev_boost returns SignedBeaconBlock with ExecutionPayload to consensus
6.) consensus validates SignedBeaconBlock again, saves it in the DB, and submits it to the network
Pros
1.) mev_boost and relay network no longer have to touch the consensus layer’s network stack. Easier to reason and simpler to implement
2.) beacon node / validator guaranteed to have full version of SignedBeaconBlock (ie Payload not PayloadHeader) to be saved in storage and not depend on network to gossip back previous signed block.
Note: same could be achieved in current scheme by just having mev_boost return the full block as it submits to the network
3.) consensus get to submits backup block in the event mev_boost fails to respond back signed block with full payload.
Note: this is dangerous and requires more consideration in the event mev_boost fails to respond back but still kept the good SignedBeaconBlock with ExecutionPayloadHeader, validator could be subjected to slashing with two versions of valid blocks
Cons
1.) consensus validator identity will become known to the mev_boost, the more validators connects to the same mev_boost software, the risk amplifies
This captures most of the notes. I will do more thinking around this scheme and evaluate further trade offs
This solves many of the issues with the initial design. Ensuring the validator receives the block is, in my opinion, critical to keeping the network decentralized from an operational point of view.
Regarding the con of the relay being able to map the validator index to a given IP address (which I assume is what you mean by “identity”), the ideal solution would be to put the request and response on the p2p network. However, given that this would require additions to the protocol and would be a relatively large amount of traffic for what is in reality a client-server interaction that seems unlikely.
One option could be for many participants in the ecosystem to provide open mev-boost services that connect to the same relay. At the point the consensus client needs to fetch a payload it can pick one of the mev-boost providers at random and ask them to forward the request for a block. This is, ultimately, just an obfuscation layer (and brings with it potential additional overheads) but with the low incidence of individual proposer selection it may be enough to ensure that no single mev-boost instance obtains details of the index-to-IP address mapping of a significant portion of the network.
Sorry, a couple more things. A note on point 3) in the pros: once the consensus node sends its signed header it absolutely cannot do anything but broadcast the block containing the payload for which it has signed, or it can be slashed. This does mean that the relay can carry out blocking attacks (where the consensus node submits a signature but never receives the related payload) but that’s about as bad as it gets.
And although direct front-running is not possible in this model, it would still be possible for the consensus node to not broadcast the block for the given slot, and broadcast a new bundle to the relays to be included in the subsequent block. This relies on the consensus node sacrificing its rewards for the current block in the expectation of higher rewards in the next, but should be preventable if the relay also broadcasts the block after it has returned it to the consensus node (so between steps 5 and 6 in your process).
This does mean that the relay can carry out blocking attacks (where the consensus node submits a signature but never receives the related payload) but that’s about as bad as it gets.
I agree. There’s certainly trust assumption between mev_boost and validator. Similar to beacon_node and validator as standalone software in some client implementations today
This relies on the consensus node sacrificing its rewards for the current block in the expectation of higher rewards in the next
I think having proposer score boosting does mitigate some the concern, but certainly worth further exploration
There is little detail in here on how the escrow works. It seems to have been dropped in to the design in an attempt to hand-wave away the issue of relays being dishonest (most obviously about the value of the execution payload they want the validator to sign) but it’s another trusted component.
Given the complexity and potential holes here, I believe that relays trusting validators is a far simpler approach. Yes the validator can cheat, but then the relay can block the validator from receiving further blocks. Detecting a cheating validator should be no harder than detecting a cheating escrow or relay in the existing proposal. This would also turn the relay in to a simple block builder, which fits more cleanly with the proposed builder/proposer separation and so would require less work to move to the fully decentralized model.
The main objective of this proposal (as I see it) is precisely that it avoids any trust assumption about validators. As soon as the design allows validators to steal MEV (i.e. we take away the blind signing), small stakers are imho unlikely to be able to receive the very best MEV opportunities, because they can’t be trusted with them. The fact that cheating is detectable (and still, this is not easy at all, so you’d rather trust and police few reputable entities like the escrows) helps very little, because for a small staker stealing once can be worth more than a year of expected rewards (or even several years). Also, small stakers can hardly build a reputation worth anything, because they propose so few blocks (20-40 a year I think?), most of which might not have very high MEV.
For example, would a searcher who has found a 100 ETH extraction opportunity (assuming it’s not very time-sensitive) trust an unknown proposer with it, or just wait one block and give it to a staking pool?
Even if it’s just a small percentage of MEV opportunities, it matters because the distribution of MEV is very much long-tailed, so this small percentage amounts to a disproportionate fraction of the total MEV. Making the long-tail much less accessible for small stakers can result in them earning significantly less, and is therefore a centralizing force
Validators trusting relays is a completely different game than the opposite, because the relay “plays” all the time, so it has a much higher incentive not to do anything bad. Moreover, from the perspective of a validator, I don’t think the relay can do any bad thing which isn’t easily detectable (from the perspective of a searcher it can, i.e. stealing MEV, but that’s irrelevant to validators):
Not only all these faults are detectable and contribute to a relay’s performance/reputation score, they are also greatly mitigated by the presence of multiple reputable escrows. Before signing a payload header, a proposer can simply ask a variety of escrows which it trusts to certify the availability and validity of the full payload, and only sign if it gets at least one positive response (or however many the proposer wants). The trust model for validators becomes then 1/N, and think most small validators would be quite ok with this tradeoff (no trust required versus this trust model) considering it gives them full access to MEV.
MEV is already a fact. You cannot deny it, by naming it “centralized”. Ethereum and Bitcoin are also “centralized” by mining pools. In crypto, everything, allowing free market is good. MEV is not “bad”, you cannot dictate network how to order transactions and how to propagate them in p2p network. It’s allowed by protocol, and that’s enough to make it “legitimate” for traders - there is no need to do somethng with it with words, only with algorithms.
MEV, flashbots and other projects, moving in the same direction is only a develoment of “ordering market”, it’s normal. We need to build things like flashbots, better auctions, more concurrency on this market, it will stimulate new strategies of mitigating it. MEV make markets more effective, allowing almost instant reactions on asset prices changes - so, it’s not so bad for whole market, only for part of it. Also, there are strategies to attack MEV searchers, it’s also makes this topic not so simple as “MEV is bad”.
It’s a serious problem, but there are many ways to work with MEV, flashbots are not the only solution. DeFi protocols will mitigate MEV problem with offchain swaps, commit-reveal orderbooks, deterministic randomization of orders. These solutions, born in fight, will make crypto market stronger - so, it’s not so bad as you suggest, IMHO
At the expense of creating a trust assumption about relays, and there will objectively be far fewer relays than validators. The most likely outcome is one major relay, with a handful of minor and/or special-case relays. Network effects will cause one relay to become dominant, because MEV is all about maximizing rewards and any relay with an advantage over the others will pick up the lion’s share of MEV (and hence the lion’s share of validators chasing said MEV).
That is up to the searcher to decide. They can put their bundle through sooner with higher risk (but less chance of losing their MEV to a competing bundle), or later with a validator they prefer. If a validator has little history, however, then it seems a fair assumption that the validator is unlikely to have built their own internal infrastructure to take the proposed block, decompose it, find the MEV, extract it, build a new block, and validate and broadcast said block on the off-chance that a long tail MEV opportunity comes along just at the right time.
Alternatively, given that a relay will be in play all of the time it would be easy for that relay to be 99% trustworthy and subvert the occasional bundle: it has both the financial incentives and the power structure to be able to do so, and it is easy for parties to believe that a small amount of MEV going missing doesn’t point to a corrupt system.
A general point I would like to make, though: the trusted relays design helps to maximize MEV returns at the expense of decentralization (in operational terms), stability and diversity of the network. Trusted relay creates a chokepoint through which all (or many) block proposals will flow, both for selection of the payload and broadcast of the block. Consider: in the trusted relay model a corrupt relay can stop block creation (for one slot at least, and highly likely for many more) acting against the validator’s interests, whereas in the trusted validator model the worst a corrupt validator can do is steal MEV. As far as the chain is concerned, the former is far more problematic than the latter. The chain is also able to punish the validator (both within the protocol and socially), but has no similar capability over the relay. Fundamentally, relays are external entities and so should not have any significant level of control over what happens in the network.
Decentralization is not simple when there are conflicting views of which bit of it matters, and the course seems to be heading for a builder/proposer split enshrined in the protocol. Until then, though, I would prefer to see an architecture that favors putting the burden on in-protocol entities and utilizes the built-in rewards and punishments system to encourage the right behavior for the good of the network.
But the majority of MEV opportunities currently are arbs, sandwiches, and liquidations. All of them are extremely time sensitive. And in cases when multiple searchers compete for an arb opportunity the large chunk of profit goes to miner anyway as a result of bets race. Searchers also have highly optimized smart contracts so an average validator is unlikely to have good enough infrastructure to steal the opportunity and get significantly more than he got via bribe.
Overall I think trying to build infrastructure that likely ends up in a single relay controlling the majority of blocks produced on the network is dangerous.
As for the relay lying about the value of the block, it can be solved by attaching a Merkle proof of the fee_recipient account balance.
Any misbehaviour of the relay is detectable within a single slot or immediately.
I uncovered another howler concerning Flashbots auctions over the weekend…
Myth: Flashbots auctions mitigate the centralization risk of extractors investing profits into owning validators because they no longer need to own validators to extract.
This is not the case. If a searcher makes 5% running a strategy on someone else’s validator and 100% running it on their own validator, they are still incentivized to put their profits into buying validators.
Auctions ensure that the majority of extracted profits go to validators, therefore extractors will make more from running strategies on their own validators and centralization risk has not been mitigated.
This is in addition to the existing risks I highlighted of block builder centralization, censorship-as-a-service and unstaked hijack attacks.
MEV is fundamentally centralizing. You can’t build stuff ontop of a centralized component (lone miners choosing block content) and expect it to decentralize. It’s magical thinking. The only workable option is to decentralize content. I would not expect this idea to be controversial in this community.
From what I’ve heard, just two actors now dominate MEV extraction (Wintermute and Alameda) so it seems like the centralizing effects of unchecked MEV are already building. They will be busy buying up validators with their profits. Whichever of them is the first to establish a censorship market will dominate the other when full-block MEVA arrives.
All this proposal would achieve is to build a collusion network acting against the interests of the network into the network itself.
A few thoughts based on the discussion so far:
Let’s say I am the best builder and I win every single block by paying 95% of the MEV I extract. My incentive to run validators is exactly the same incentive as everyone else’s: the 95% of the MEV which I am paying out to proposers, because the remaining 5% is mine anyway. Basically I can go from 5 to 100, but anyone else can go from 0 to 95, and thus has the same exact incentive to stake as I do.
This property does not hold without auctions: a builder would then only be able to access MEV for all the blocks they directly propose, and so they’d be much more incentivized to stake than anyone else.
Yes you’re quite right about this- good spot. I missed that the relative incentive for all stakers is raised by the same amount and I retract this post. My previous objections still apply.
I’ve had a thought on the same subject. Dominant extractors owning validators may be preferable to them not. It sucks big time, but it still may be better.
As I understand it, the outcome PBS/MEVA is trying to mitigate is dominant extractors being incentivized to buy up validators as this is centralizing and so a security risk. But in this case at least the extractors have a stake in the network, so they are going to behave better than unstaked dominant extractors (ie: not do CaaS, Unstaked Hijacks, etc, for the same reason they’re less likely to double spend).
It seems to me that PBS/MEVA actually removes the security assurance that dominant extractors must also be stake holders, so making the network less secure. Isn’t it a security flaw not a security assurance that they can dominate block content without needing to have any skin in the game? It allows them to be maximally explotative even if it harms the network because they won’t be harming themselves.
I’ll rephrase this as a question (not rhetorical, I am interested). Why do you think that allowing dominant extractors to be unstaked improves the security of the network?
While a builder monopoly/oligopoly is obviously not ideal, it doesn’t break security assumptions other than censorship-resistance. The key point here is that controlling the executable part of a block does not give any control over consensus, as this is determined by attestations.
What this means practically is that even a monopolistic builder cannot do anything to break liveness or safety, nor they can do anything to force reorgs and double spend etc…
What would be really dangerous is for the validator set to centralize, because that opens the door to all of these attacks. It is therefore much much more important for us to preserve the decentralization of the validator set rather than that of the set of builders
Even for censorship-resistance, we wouldn’t have any guarantees if the validator set comes to be dominated by an oligopoly of extractors: even if a non-censoring minority existed, 51% of the stake can completely control the fork-choice and censor it. On the other hand, a decentralized validator set allows us to create mechanisms which give us strong censorship-resistance guarantees even with PBS (see here for the current state of research on this).
Yes understood, but this focus on the formal measures of liveness and safety has been exactly the problem because they are time-insensitive whereas most smart contracts are not. Academia has lagged necessity here, although thankfully that is changing.
My point is that Flashbots auctions mitigate structural centralization at the expense of centralizing content. This allows for attacks nearly as severe as reorgs and double spends but with the added issue that the attackers are unstaked.
Yes- this! A PBS proposal which appreciates the centralizing effects of auctions on content and uses consensus to mitigate it will beat the status quo.
I like @vbuterin’s idea of parallel PBS you linked to here. I’ll continue a discussion of that on the PBS thread as it seems more appropriate.
