Ethereum 2.0, MEV/VEV, Staking, and the Looming Specter of EV Farming Pools

# Ethereum 2.0, MEV/VEV, Staking, and the Looming Specter of EV Farming Pools To get the most out of this post you will need an understanding of MEV (Miner Extractable Value) / VEV (Validator Extractable Value), EIP-1559, and how PoS works. For the remainder of the piece I'll just refer to EV in general and within the context of PoS. The below resources should help: * [@Superphiz'](https://twitter.com/superphiz) [A Layman's look at staking on Ethereum](https://youtu.be/Yk39hNavhyM?t=10717) * [The Flash Boys 2.0 paper](https://pdaian.com/flashboys2.pdf) * [Alex Obadia and Tomasz Stanzak Discuss The Merge and MEV](https://youtu.be/Yk39hNavhyM?t=16322) * ETH2's revised value proposition in light of EIP 1559, EV capture, and PoS: * [Justin Drake\'s ETH2 Staking + EVM Fee rewards calcs](https://twitter.com/drakefjustin/status/1384124998084792324?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1384124998084792324%7Ctwgr%5E%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fwww.redditmedia.com%2Fmediaembed%2Fmu097f%3Fresponsive%3Dtrueis_nightmode%3Dfalse) * [@SquishChaos'](https://twitter.com/SquishChaos) [The Triple Halving](https://drive.google.com/file/d/1bECqgijhgjdS782AB620gFjK5qx-vA99/view) By now many of us are aware of the potentially lucrative rewards that validators will be likely able to accrue post-merge, when validators will be earning the "priority fee" (AKA inclusion fee / tip / miner bribe) currently given to miners. For the purposes of this analysis, let's set aside the question of whether EV should be solved at the protocol level or let protocol participants solve/optimize atop the protocol (current approach)[^1]. I highly doubt that the status quo will materially change within the next year, but until then we can certainly enjoy all the [lively](https://twitter.com/phildaian/status/1382775729700675588) [debate](https://twitter.com/GuilleAngeris/status/1379925899475230726). If you want to read more, here are some bits to chew on: Philip Daian's [MEV wat do](https://pdaian.com/blog/mev-wat-do/), and the response [MEV do this](https://pmcgoohan.medium.com/mev-do-this-beb2754bca63) by pmcgoohan (also [MEV Auctions will Kill Ethereum](https://ethresear.ch/t/mev-auctions-will-kill-ethereum/9060)). Given these out-sized gains from EV (compared to "pure" staking gains), we should consider what impact EV "farming" will have on the staking landscape and, by extension, how this will affect the decentralization and distribution of Eth 2.0 validators. If we want to avoid a scenario where the Eth 2.0 staking landscape ends up looking similar to the Eth 1.0 mining landscape (or worse, because staked money (especially retail) tends to move slower than hashpower), Ethereum needs to find a way to either incentivize solo staking, or ensure that decentralized and distributed staking pools play a dominant role in the resulting ecosystem. Based on the current design, I predict that it will be economically detrimental to run a solo validator vs participating in a validator pool, and decentralized pools are economically disadvantaged compared to centralized ones. Worse yet, the current system will likely lead to a "race to the top" for staking pools, where it will make very little economic sense for most staking participants, and especially "retail stakers" (i.e. purchasers of staking derivatives), to participate in any pool apart from the largest few, which will be able to leverage economies of scale to offer substantial returns while keeping costs low. ### EV capture, economies of scale, and the eventual death of solo staking At first glance, we may think that it shouldn't matter if a user is participating as a solo validator vs as a part of a pool, because the probability over time of proposing a block (and thus receiving the associated EV) is proportional to one's stake. In the case of solo validation, if a user's validator gets to propose a block, then they would get 100% of the VEV (assuming they are running the requisite software). In the case of pooled staking, they would receive a proportional reward depending on how the specific staking service reward distribution model (less fees/commission) but in general I argue that the optimal EV reward model is `[(total staked by user in pool)/(total staked by pool) - fees]` because this is what will bring the most capital into the staking pool. However, in actuality solo validators *will not* be equally likely to propose *EV-bearing blocks* and thus reap the associated inclusion fee, because of the following factors: * EV Searchers are risking a lot of money if a validator screws them, thus they are incentivized to only interact with validators who are trustworthy (i.e. will execute as expected, vs doing something like "front-running the front-run")[^2]. Since the only real way to penalize "malicious" (not in the staking sense, but in the EV sense) validators is to not give them blocks in the future, it's probably cheaper overall to just not send EV-bearing batches to unknown validators, and only interact with known/trusted validators. The best way to maximize the potential for ensuring your EV gets in is to interact with a known and trusted entity, and that's basically what large validator pools are. * Even if a solo validator ends up being a "trusted participant" of the EV system, they are still limited by the luck factor. Even though in theory validators will propose X blocks over time, the real number could obviously be far above or below the mean, so one may end up with a solo validator with 1 block proposed in the span of a few years, and there is no way to know what the potential value of the EV included in that block would be (it may also fall below the mean, even if the validator is running up to date and correct software, because it happens during a lull period). * In general, and especially for something long-term like staking, most actors will prefer to allocate their capital towards things that can pay consistent rewards over time, and even more-so if the value of the reward itself is also relatively consistent. The best way to do this would thus be to participate in a pool that socializes EV rewards across the pool: when any one validator gets to propose a block, the EV is then redistributed across the entirety of the pool. This ensures not only more consistent rewards but also a smoother reward value curve. It also means that pools are able to redistribute the EV volatility that occurs during network peaks and troughs into a more consistent reward curve. * The optimal reward distribution model is `[(total staked by user in pool)/(total staked by pool) - fees]`, because this generally maximizes the amount of "slow" capital that will want to allocate itself under a pool. Pools will then compete in terms of who offers the least fees. Centralized services have an advantage here, because they can rely on the trust that users already put in them (just by virtue of staking their money on a centralized platform) to perform the calculation and redistribution of rewards off chain (i.e. centrally), whereas decentralized alternatives will need to expend more time and resources to develop cost-efficient ways to do so on-chain Faster moving capital (i.e. actors who are willing to incur the gas costs associated with staking/re-staking across services) may look for smaller staking pools that offer potentially higher EV extraction at a potentially lower probability, hoping to capture value based on timing their stake being in the right pool at the right time, but this will not be the majority of staked capital. We should also consider that operating validators on Eth 2.0 is subject to economies of scale. In the very simple example of someone running a solo validator, a machine that can run 1 validator can probably run 10, where the only substantial incremental cost is the 32ETH stake needed. The next "bump" in marginal costs comes at the point where current hardware can support `n` validators but not `n+1`, and then either a hardware upgrade is needed or new hardware. For larger staking operations, and especially ones where these costs are spread across multitudes of participants and the capital can be drawn from retail stakers via staking derivatives, the marginal cost of increasing validators and thus potential staking rewards (including EV) is drastically reduced. Depending on how sharding ends up being implemented, this problem may even be further exacerbated (as solo stakers may be priced out of the ability to validate multiple shards). Given these economies of scale and the outsized rewards a staking pool would have by capturing incrementally more of the "EV market", users (and especially retail stakers) will tend to flock to the most economically efficient choice. This will lead to validator pool centralization, and potentially detrimental network effects in the Ethereum ecosystem. One really extreme example would be if a CEX-operated pool became the leading staking pool, and for some reason (perhaps cost minimization) they operated all of their validators on AWS and using only 1 Eth2 node+client. Given such a staking pool with 30-50% validator share even a simple client bug (like the recent [prysm proposal bug](https://medium.com/prysmatic-labs/eth2-mainnet-incident-retrospective-f0338814340c)), or an AWS outage, could be potentially catastrophic for the network. Even the searching and bundling protocol/technologies themselves increase centralization risk. MEV-geth is a solution for one client (geth). This means that unless EV "enhancements" can be made for all clients, and unless they work more or less equally effectively for all clients, the EV rewards market will resulting in a skewing of validator client distribution towards the client(s) that offer(s) the best rewards. This creates additional operational risk for the network in case of single-client (or modified/extended client) failure. In addition, these protocols may be centrally permissioned (i.e. whitelists and blacklists controlled off-chain, by off-chain actors), which will make it easier to sideline small actors but difficult to punish inefficient or even malicious large actors who are "too big to fail (exclude)". ### For the interim, a possible decentralized solution A decentralized and trustless staking pool could design a priority fee reward mechanism to at least prevent this EV capture from happening in a (semi)-centralized manner. It will still be more expensive to implement than a centralized approach, and it will probably be more economically beneficial for capital to flow to the centralized solutions, but if the difference is small then there is at least a realistic option for stakers who want to support a healthy network without sacrificing an inordinate amount of returns. The market could then decide to reward these decentralized validation networks through better returns on DeFi opportunities which use their associated staking derivatives. * Enforce socialized reward distribution by requiring that validators specify, as the priority fee coinbase address, a smart-contract address that would appropriately redistribute EV rewards across the pool. Failure to do so by a node operator would result in penalizing of their collateral and/or stake (e.g. at withdrawal). * Provide "guarantees/insurance" (to a certain extent) that all validators who are a part of the pool are running EV-compatible nodes. This would be done by a) punishing bad actors and b) utilizing collateral and/or insurance that is put up by pool participants in the case of bad behavior to compensate EV partners. [Izzy / @IsdrsP](https://twitter.com/IsdrsP) May 3, 2021 [^1]: There are a variety of on-protocol solutions being worked on; the below is a rough WIP list: * Gnosis Protocol V2 and Cowswap https://blog.gnosis.pm/introducing-gnosis-protocol-v2-and-balancer-gnosis-protocol-f693b2938ae4 (clever solution, but bad UX since basically users have to authorize transactions via opaque signed messages... at least gas fees aren't incurred for failed transactions) * Targeting Zero https://ethresear.ch/t/targeting-zero-mev-a-content-layer-solution/9224 * Encrypting Mempools https://github.com/pmcgoohan/dark-alex/blob/7925e8e74bd91e9df7fe876d4257dfcd09a3c38e/encrypted-content-layer.md#dark-alex * Threshold encryption https://github.com/skalenetwork/libBLS * Project Shutter https://shutter.ghost.io/ * HashFlow https://hashflow.com/ [^2]: There are also technical solutions being investigated that may solve the problem of bundle executioners taking advantage of the proposed bundle (e.g. MEV-SGX). These solutions propose to reduce/eliminate searcher risk by encrypting the bundle, but these solutions aren't currently being used (they may potentially be sub-optimal due to cost anyway). Even if they were in place, they would further disadvantage solo stakers, as the ability to "accept" such bundles is usually dependent upon either specialized hardware or additional time/resources in order to "rent" processing on such hardware from others, both of which increase cost for solo stakers and again promote centralization via economies of scale.