Front-Running as a Service
There’s been some back-and-forth recently about the problem of front-running in Ethereum dapps, and what can be done about it. As I wrote before (MEV auctions considered harmful), front-running is harmful to users and distorts application markets, so we should try to reduce it as much as we can — and attempts to harness front-running for good will probably make things worse.
Vitalik Buterin responded to my post, offering a common argument which in my view isn’t correct for reasons I’ll explain in a minute. This led to a long exchange with Vitalik on Telegram that helped me understand his views. Long story short, I still think his post was wrong on this point.
Here’s a quick refresher, for those not always in the weeds on this issue. Ethereum miners get to choose which transactions to include in the blocks they make, and in which order those transactions execute. This gives miners the ability to insert their own transactions into advantageous positions in the ordering or sell good positions to others. That’s front-running. The point of debate is how front-running opportunities will affect miners’ behavior, and how that in turn will impact the overall health of Ethereum.
The conventional wisdom, which Vitalik voiced, is that inevitably one miner will be more skilled at front-running than the others, and that miner will have an economic advantage that will lead them to increase their share of mining power, driving out the other miners who are less skilled at front-running. The result will be centralization of mining power, which has long been recognized as destabilizing.
A skilled front-runner will sell their services
I think the conventional argument is wrong. To see why, let’s suppose that Fred is the most skilled at front-running in the world. Fred knows how to craft Ethereum blocks that extract more front-running value than anyone else can manage. And suppose Alice is a miner who controls, say, 2% of the mining power. The natural outcome is that Fred will sell his block-making to Alice — front-running as a service. If Fred can increase the value of each of Alice’s blocks by V, then both parties benefit if Alice buys Fred’s block-making service, in exchange for a payment between 0 and V for each block Alice makes. Both Alice and Fred are better off making this deal than not making it — so it will happen. And there’s nothing special about Alice. Fred will sell his services to every miner.
Notice that this deal is mutually profitable for Fred and Alice whether or not Fred is a miner. A miner-Fred will presumably mine blocks that he himself has designed, and he’ll profit from doing so. But he will profit more if he also sells block-making services to Alice, because he’ll be able to make some money in the 2% of cases where Alice makes a block, which beats the alternative of making no money in those cases. So Fred’s decision about whether to invest in mining will be independent of whether he is selling to Alice.
(Also notice that if Fred owns a mining business, that business has no inherent cost advantage over other miners. Fred can have his front-running business sell service to his mining business at a sweetheart price or even at zero price, but that doesn’t benefit Fred: a discount of $X makes Fred’s mining business $X richer and his front-running business exactly $X poorer. Fred’s incentives are the same as they would be if his mining operation had to buy from his front-running service in an “arms-length deal” like Alice does.)
The upshot of all of this is that Fred will want to sell his front-running services to every miner who is willing to buy. And miners will buy.
So the natural outcome is Front-Running as a Service (FRaaS): an active market where front-running optimizer Freds compete to sell block-making services to miner Alices. None of this needs to drive centralization in mining. Indeed, by allowing Alices to offload the hard work of optimizing front-running to Freds, FRaaS will lower barriers to entry in mining. If anything, that will foster decentralization of mining, compared to today.
FRaaS and mining pools
This market will probably end up structured as a set of mining pools. Fred will run a mining pool, which can pay higher rewards than any competing pool, because Fred’s blocks are more lucrative than anyone else’s. Fred’s competitors in the FRaaS sector will do the same. Most miners will choose the honest pool that is paying the highest rewards at the moment.
Importantly, miners will be free to make independent choices of who to work with, to shun badly behaved pool operators, and to change who they’re working with on a block-by-block basis. So to the extent that a pool operator has power to choose the ordering, that power exists for only one block at a time. And of course, Ethereum mining already gives the miner who makes a block the power to choose ordering within that block. So a “one-block monopoly on ordering” that has to be earned in an open market is already what we’re living with.
Designing for a FRaaS world
So if Front-Running as a Service is the future, how should we design systems for robustness in that future? I would offer two principles.
- Maintain FRaaS competition
The first principle is that if there is going to be a FRaaS sector, we want it to be competitive, so that there is not a single party who is the only one that can establish transaction ordering in blocks. In general, monopolists have more power than market leaders in competitive markets do, and monopolists are typically incented to use that power to extract value that makes markets less efficient and drives end users away. It follows that we shouldn’t artificially grant a monopoly on block formation to one party. Doing so would violate the general community principle against artificial centralization, and would give the FRaaS monopolist power to engage in abusive behavior that would otherwise be constrained by competition. Even if the monopoly is time-limited, it is still an unnecessary concentration of power.
2. Reduce front-running
The second principle is simply to remember that front-running is harmful and we should be trying to reduce it. We should make resistance to front-running one of the criteria we use in evaluating systems and protocols.
For example, in evaluating any new protocol, we should ask: Will this protocol increase or reduce the front-running power of miners or other participants?
I’ll be saying more in the future about how this principle has informed the design of our Arbitrum protocol — and why we think a Layer 2 can do better than Ethereum by actively decentralizing control over transaction ordering.
MEV auctions still considered harmful
Those deep into these issues will be asking: in a world with FRaaS pools, does it make sense to have an MEV auction? Should we create a centralized sequencer that orders transactions, and auction off the right to be that sequencer for a period of time? The answer, I think, is no. In the next post I’ll explain why.
