MEV Driven Centralization in Ethereum: Part 1
With the merge looking likely to happen within the next couple of months, I thought it would be interesting to write a post that speculates how MEV will affect Ethereum’s landscape after the merge. Being this close to the merge gives me the opportunity to publish a two part “before-and-after” series of posts that compare my idea about what might happen to what does actually happen in real life, which for me, is an interesting experiment.
Overall, the objective of this post is to imagine certain scenarios that may or may not emerge, and to compare those scenarios to the ones that do actually emerge post-merge.
This post assumes you have at least a basic understanding of Ethereum’s roadmap and specifically the move to proof-of-stake, as well as a grasp of the fundamentals of MEV.
Obligatory disclaimer: the opinions in this post are entirely my own, not representative of the views of my employer, colleagues or any other organization I’m associated with.
PoW to PoS
Back in 2017, when PoS was still being thought about in one of the many iterations towards “eth 2.0”, Vitalik ostensibly had doubts about the degree that PoS would affect decentralization:
“all in all, the centralization balance is an empirical question for which the answer is unclear until the system is actually running for a substantial period of time”.
To be fair, Vitalik has subsequently stated in other posts that he sees PoS as being more decentralized than PoW. From my perspective though, to what extent it may improve decentralization is still uncertain.
But decentralization was never the only motivating factor toward the move to PoS, there were other benefits that made it a logical choice, including being able to reduce the ETH issuance that is required to incentivize participation, because the network uses less power than PoW, meaning a lower cost to participants. It also means the network uses less energy overall, which is good for the planet.
But if the move to PoS never had a clear improvement over the level of centralisation in PoW Ethereum, well at least it couldn’t make it any worse. Or could it?
Enter MEV . . .
The Flashboys 2.0 paper by Daian et al. was published in 2019, and I was lucky enough to attend a talk by Phil Daian in which he presented this paper. He warned that there was a possibility that explicit re-ordering and targeted insertion of transactions in blocks could create game theoretic incentives that could “leak down” to affect the security at the base consensus layer.
Just to put things in context, MEV does not account for a huge amount of revenue, it’s a relatively small amount (according to the Flashbots’ MEV Explorer anyway). Currently the amount of MEV captured from blocks is a relatively low percentage of the overall profit from the amount in transaction fees and block reward, (I put it at an average of 1.63% for the past 18 months, please correct if added up wrong).
However, with the block reward being reduced substantially with PoS, the amount of MEV becomes much bigger relative to the block reward, and this is what makes a difference.
That means that validators will want to get MEV. If they don’t, well then that’s money left on the table. Furthermore, it’s reasonable to assume that staking pools will want to ensure that their customers know that they are receiving the best possible return on their staked ETH. That means, block rewards, transaction fees, and MEV.
Economies of scale
MEV skews the economic design of PoS Ethereum, because large staking pools will enjoy economies of scale that smaller staking pools will find difficult to compete with. Intuitively, this makes sense, because the higher the percentage of the network’s validator set a staking pool has, then the more often that staking pool will have one of it’s validators nominated as proposer, and thus the more MEV that staking pool will capture, earning more capital that it can convert into more validators, and so on. For more of a deep dive into the economies of scale of MEV in PoS Ethereum, see Alex Obadia’s excellent research on the subject.
But what if block building was totally separated? What if constructing the block was undertaken by another entity, separate and independent to the proposer / validator? What if these separate block builders could bid against each other to have their block proposed? Under this scenario, the validator that was nominated as proposer for a given slot needs to only accept the block from the builder that was offering the highest amount of value to the proposer. This would mean that every proposer that was nominated by the network would be able to capture the most amount of MEV possible, irrespective of how sophisticated an MEV searcher they were, leveling the playing field between validators. Also, competition between block builders bidding against each other would mean that more MEV would go to validators, smoothing out the variance in revenue that MEV caused.
Enter PBS . . .
This is exactly what Proposer-Builder-Separation aims for, to separate the construction of a block and the validation of a block into separate concerns.
Quickly it was discovered that PBS has other benefits in terms of scalability, and is one of the core requirements for danksharding, but originally it was intended to deal with the centralizing effect that MEV could have on the validator set, as described in the earlier paragraph.
PBS works by outsourcing the block building concerns to a dedicated block builder, while allowing the validators to concentrate on proposing the blocks to the network and providing attestations. This helps scalability because it means that validators have less of a heavy lift (they no longer need to expend computational effort on building blocks — or extracting MEV).
With PBS, block builders provide block headers, with a fee that will be paid to the proposer. The proposer doesn’t see the block body until they commit to selecting one of the blocks being provided. Naturally they will select the block that pays them the highest fee.
In-protocol PBS is going to take some time, and the exact mechanism by which in-protocol PBS will be implemented is still under discussion, (see here, here, and here). For the time being, PBS will be implemented via mev-boost, which allows for ‘relayers’ to act as escrow, facilitating an open sealed-bid auction between block builders and proposer / validators.
See this ethresear.ch post for original specifications.
Validator Centralisation
What PBS / mev-boost does is smooth out the variance of validator revenue to a degree, by giving solo stakers the same chance getting as much MEV for the blocks they propose as a large staking pool, but it doesn’t really fix MEV driven validator centralisation. At the end of the day, If you have 10x more validating power than the next staking pool, then you will have 10x more opportunities to earn MEV. That’s more profit that you can re-invest into more validators, to have yet more opportunities for capturing MEV, and so on…
Block Builder Centralization
In order to be competitive and out-bid other block builders in the mev-boost auction, and hence have their blocks chosen by proposers, block builders will need to be able to extract more value from the transactions in the block, than the value derived from simply selecting the transactions with the highest gas fees. This means that block builders will need to rely on MEV searchers to provide the highest value transaction bundles, so that the blocks they produce will be chosen by the proposer.
From the searcher’s point of view, they must choose which block builder to send their bundles to. It is reasonable to expect that a searcher will make this decision by determining which block builder is the most likely to have their blocks chosen by the proposer.
The block builder that will most likely have their blocks chosen by the proposer:
- is the block builder that consistently presents the highest value blocks to the proposer,
- which is the block builder that consistently has the highest number of transaction bundles to choose from,
- which is the block builder that most searchers submit their bundles to.
It is relatively trivial for searchers to ascertain which block builders are winning bids, even in real-time.
This simple network effect creates a virtuous cycle that can plausibly lead to the emergence of a single block builder. While a single monopolistic block builder does not present any obvious threat to the network, (as they can’t adversely affect the liveness or safety of the system), it does raise a number of concerns.
If we assume that there will be only a handful of dominant block builders in the space, (or even just one), then what potential implications does this have?
Let’s assume there are only a handful of dominant block builders. They must extract as much MEV as possible in order to remain competitive. That means they need to explore all avenues to to extract MEV, including:
- Censorship-as-a-Service — accept payments to censor specific transactions for x number of blocks.
- Preferential treatment — slow down withdrawals from competitor exchanges / rollups / bridges, for a fee.
- Bundling all transactions to a particular AMM trading pair into one block, in order to amplify the price impact — causing transactions with tight slippage tolerance to fail on-chain.
- Potentially offering reorgs-as-a-service in order to maximize MEV.
Even without the above mentioned tactics, there are still inter-block MEV strategies that I have no doubt will emerge.
Is this all just FUD?
I want to point out that this is all speculation at this point, and block builders may never resort to such strategies to remain competitive. Personally I don’t think that these strategies will be employed by block builders. I think block builders will take a long term view and put the health of the ecosystem above short term competitive advantage and will find a way to make it work. Nobody knows for sure, but I’m taking as guidance the fact that currently only 3 or 4 mining pools share over half the hashrate on the network (and so I presume they generate half the blocks on average). Currently the operators of these mining pools don’t engage in the sort of practices I’ve outlined above.
That being said, the other difference between block construction pre and post merge, is that currently the “other” 50% of the hashrate is very diverse, whereas if we end up 5 or 6 block builders, it may well be the case that those are the only block builders we have. If that scenario arises, it would make it much easier for regulators to target them, which is worth thinking about as we figure out how to enshrine PBS at the protocol level over the next couple of years.
MEV Hiding
Something that I think staking pools are starting to worry about is out-of-band payments to node operators, or “mev hiding”, see this post as exhibit A.
If a block builder decides to pay a node operator out-of-band, it means that the node operator doesn’t have to share the MEV with the validators, (in other words, they keep it all themselves). Instead they just share what is publicly auditable, i.e. the transaction fees and the block reward.
See the documentation for more information on how Lido fees are paid as an example:
“The protocol includes Oracles that periodically report the combined Beacon balance of all validators launched by the protocol. When the balance increases as a result of Beacon chain rewards, a fee is taken from the amount of rewards …. and distributed between active Node Operators.”
If you’re a node operator, and your nodes are continuously running, somewhere on the internet, year after year, you’re probably thinking: “hmm, those small amounts of MEV could really add up over time if I keep them for myself”, and you wouldn’t be wrong. The risk is that if you get caught, you will be ejected from the staking pool and you will lose a revenue stream (if you get caught).
Ok, but why would a block builder want to pay a node operator out-of-band anyway?
Well maybe because they know that the node operator will be more willing to accept a block that bids lower than a competitor’s block, because it means the node operator can keep the MEV for themselves, which in the long run, is worth more. Basically, not having to share the MEV with the validators, means they make more money than if they accept the highest bid block and share the MEV. When block builders are under huge competitive pressure, if there’s a chance they can get a node operator to accept a block for less fees than their competitor, this becomes a very attractive proposition.
Ok, so great theory, but how would it actually work?
One way I think it could be done is with a simple direct API that a builder exposes that any node operator can submit a payment address to. The builder can return the proposed execution payload header, with a valid payment transaction and proof that the payment transaction is included under the block header’s state root. This way the node operator knows which exec payload to sign when selecting one from the relayer, and that if they sign this exec payload, the block will contain a transaction that pays them the MEV, separately from the transaction that pays the priority fees to the `feeRecipient` address.
Staking pools are afraid of MEV hiding because it affects their customers, and may potentially drive them to competitors who can offer a solution. But what solutions exist?
Trusted Relayers
This is what’s going to happen initially. Certain parties will run relayers that will accept block bids from builders, and will relay those bids to validators / proposers. The builders need to trust the relayers that they will not steal MEV from the blocks that they submit to them. The proposers need to trust that the relayer is relaying all the bids, that the relayer will release the full block to the network on time so that the validator that’s proposing a block for the current slot doesn’t get slashed, and from the staking pools perspective, they would like it very much if they can require their node operators to all connect to the same trusted relayer. That way, the staking pool sees all the bids that their node operators see, and can identify when any node operator selects a bid that is not the highest bid for that slot (as this would suggest some form of MEV hiding).
Ultimately I think builders would prefer to run their own relayers, but I’m fairly sure that staking pools would be more comfortable using a neutral, independent, third-party relayer. I don’t think staking pools will run their own relayers for the same reason I don’t think they will become involved in block building: regulatory concerns. Running a block builder or relayer would give them too much visibility into the transactions in the block before they are proposed to the network, which would just raise too many questions.
One crucial piece of infrastructure that is planned for collaborative development between a number community members is the Relay Monitor, which will go a long way toward increasing transparency into which builders and relayers and node operators are active, and the relationships and activity between them, as well as performance metrics, which will also be absolutely crucial.
Overall it boils down to trust. With so much money involved, and with such a small number of actors participating in certain components of the overall network’s infrastructure, I believe that they will find a way to make it work for everyone’s benefit. And that means implicit trusted and mutually beneficial relationships between various actors. Ultimately I believe we will need a less centralized and more robust solution, but I think we will get there together, eventually.
So what other solutions could there be for the MEV hiding problem?
Single Secret Leader Election
SSLE theoretically mitigates the problem of MEV-hiding, because the block builder doesn’t know who the proposer is going to be until the block is propagated, and so they don’t know “where to send the money”. By the time the block lands on-chain, it’s too late to bribe the proposer with an out-of-band payment. The problem is that SSLE is still being discussed, there are a number of proposals that have yet to be decided on, and it’s not yet clear how SSLE will work with PBS, especially if crLists are implemented.
Distributed Validator Technology
Distributed Validator Technology is a technology that aims to help validators against inadvertently getting slashed when their node goes offline. Normally node operators run two instances of the validator clients, so that if one goes down, they can fail over to the backup. In some cases, the primary node does not go down, but fails to communicate its health to the back-up, which can result in both validator clients running simultaneously. If this happens, then they release a different block at the same time, signed with the same key. Big no no, this gets you slashed, resulting in loss of funds. It’s a tricky problem. DVT solves this, because it means you can have multiple nodes, they all sign a single block / attestation with one key, because they rely on threshold cryptography, i.e. an m-of-n threshold signature. If one of the nodes goes offline because of a cloud vendor outage or something, that’s ok, because there should still be enough nodes to meet the threshold signature, and so they can continue to keep signing blocks and attestations.
Ok, what does this have to do with MEV hiding?
I’ve described the short term use-case for DVT, but longer term, the goal of DVT is to allow solo stakers to coordinate amongst themselves, so that they can pool their ETH into one 32 ETH bonded validator, they can run their own nodes, and not have to worry about getting slashed if one of the participants goes offline. This will all be coordinated by a smart contract, totally permission-less. Obol Technologies have this in the long term roadmap, and SSV Network have implemented something similar.
According to SSV’s docs: “Stakers will distribute their validator KeyShares to 4 or more operator nodes on the network . . . . note that operators within a cluster act in unison to generate ETH rewards for stakers”
With this sort of implementation of DVT, it becomes much more difficult for a block builder to deliver out of band payments to node operators, as they will be dealing with a number of node operators working as a single validator.
Distributed Block Building
As it stands there are no concrete proposals that I’m aware of for a Distributed Block Building protocol on L1. There are some proposals for threshold encryption, see Dark Alex, or the proposal for Shutterizing the beacon chain, however, these are very early stage ideas, and implementation is a very long way off, and may never actually come to pass.
Summary
The ultimate solution may very well be to not fix the MEV problem on the base layer, but simply to mitigate it as much as possible, while working to reduce the opportunities for MEV extraction in the public mempool. This means that MEV sensitive transactions should move to Layer 2, where the possibility for distributed block building, or other MEV mitigation techniques, is far more feasible. At the end of the day, MEV is not a solvable problem, it’s a phenomenon that is inherent to open economic systems, and there is good MEV and MEV that undermines user’s intentions and expectations, which is widely regarded as bad MEV. Ultimately MEV acts as a force to shape the landscape of Ethereum, and the extent to which this happens is what is still being understood.
As I mentioned at the start of this post, I plan to follow up with a second part to this post at some point after the merge, to compare some of the scenarios I’ve speculated about in this post, to what actually unfolds, and to see how far off I was. Stay tuned.
Works and wesbites referenced in this post:
Obol — Building Distributed Validators for Ethereum, http://obol.tech.
Asgaonkar, Aditya, et al. “ethereum/distributed-validator-specs: Ethereum Distributed Validator Specifications.” GitHub, 23 November 2021, https://github.com/ethereum/distributed-validator-specs. Accessed 28 July 2022.
Beiko, Tim, and Liam Horne. “EIP-4844: Proto-Danksharding.” EIP-4844: Proto-Danksharding, https://www.eip4844.com.
Buterin, Vitalik. “Proof of Stake FAQ.” Vitalik Buterin’s website, 31 December 2017, https://vitalik.ca/general/2017/12/31/pos_faq.html#will-exchanges-in-proof-of-stake-pose-a-similar-centralization-risk-to-pools-in-proof-of-work.
Buterin, Vitalik. “Simplified SSLE — Consensus.” Ethereum Research, 4 April 2022, https://ethresear.ch/t/simplified-ssle/12315.
Buterin, Vitalik. “Why Proof of Stake (Nov 2020).” Vitalik Buterin’s website, 6 November 2020, https://vitalik.ca/general/2020/11/06/pos2020.html.
cducrest. “Shutterized Beacon Chain — Execution Layer Research.” Ethereum Research, 24 March 2022, https://ethresear.ch/t/shutterized-beacon-chain/12249.
Daian, Phil, et al. “[1904.05234] Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges.” arXiv, 10 April 2019, https://arxiv.org/abs/1904.05234.
“flashbots/mev-boost: mev-boost allows proof-of-stake Ethereum consensus clients to outsource block construction.” GitHub, https://github.com/flashbots/mev-boost.
“GitHub.” The Merge — The Beacon Chain, https://github.com/ethereum/consensus-specs/blob/a45ee9bf5b1fde766d69e551a6b1a21fe2531734/specs/merge/beacon-chain.md#executionpayloadheader.
Gosselin, Stephane. “MEV-Boost: Merge ready Flashbots Architecture — The Merge.” Ethereum Research, 4 November 2021, https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177.
Mcgoohan, P. “pmcgoohan/targeting-zero-mev: Targeting Zero MEV — A Content Layer Solution.” GitHub, https://github.com/pmcgoohan/targeting-zero-mev.
Monnot, Barnabé, and Sacha Yves Saint-Léger. “Economic incentives of Eth 2.0 — hackingresearch.” hackingresear.ch, 16 April 2019, https://hackingresear.ch/economic-incentives/.
Monnot, Barnabé, and Sacha Yves Saint-Léger. “Economic incentives of Eth 2.0 — hackingresearch.” hackingresear.ch, 26 April 2019, https://hackingresear.ch/economic-incentives/.
“Node Operator Manual.” Lido Docs, https://docs.lido.fi/guides/node-operator-manual/#general-overview.
Obadia, Alex. “MEV in eth2 — an early exploration.” HackMD, https://hackmd.io/@flashbots/mev-in-eth2.
Ryan, Danny. “The Risks of LSD.” HackMD, https://notes.ethereum.org/@djrtwo/risks-of-lsd.
“SSV Tokenomics | ssv.network.” The SSV Network, https://ssv.network/tokenomics/.
Worsely, Nathan. “MEV as an inner experience.” MEV Day, 19 April 2022, https://docs.google.com/presentation/d/1qiN7zEGMv704XUj0UtZTVUlofgY09NewvF8FcxaPvnk/edit#slide=id.p.
Worsely, Nathan. “MEV as an inner experience.” https://docs.google.com/presentation/d/1qiN7zEGMv704XUj0UtZTVUlofgY09NewvF8FcxaPvnk/edit#slide=id.p.
