Five theses about transaction ordering, MEV, and front-running

The Ethereum community debate about miner-extractable value and transaction ordering has been heating up again, thanks to a recent post by Ari Juels and collaborators, and the resulting tweet storms. The debate often conflates some issues that I think should be separated. So, building on my past posts, let me offer five theses that that I hope will lend some clarity.

Thesis 1: Front-running harms users.

The first point, which is too easy to forget in the heat of debate, is that front-running makes markets less valuable and deters participation. A world with less front-running — less value extracted from users — is a better world.

Now you might argue that front-running can’t be prevented, or that we’re unfortunately locked into an equilibrium with more front-running. Those are plausible arguments that can be evaluated on the merits. But front-running is at best a necessary evil, and the community should try to find ways to reduce it.

Thesis 2: All else being equal, if front-running is going to exist, transaction ordering should be for sale in a transparent market.

Today’s Ethereum is subject to front-running: miners can control transaction ordering within the blocks they make. As long as this is true, miners will be able to front-run users, or sell positions in the transaction order.

If ordering is for sale, it might as well be for sale openly and transparently, so people can see what is happening and the opportunity to pay for ordering is available to ordinary users and not just insiders. Systems like Flashbots aren’t causing the front-running problem, they’re making it a bit less bad.

Thesis 3: Some designs and protocols are more resistant to front-running than others. This resistance is a good thing.

Not all protocols are equal. How much front-running can exist in a protocol will depend on how that protocol is designed. So when we’re evaluating a protocol, we should ask whether it will increase or decrease front-running opportunities. This isn’t the only thing to consider, but it should be a factor in evaluating new protocols or changes to existing ones.

Thesis 4: There’s a lot more research to be done about how to make systems more front-running resistant, and how to make types of resistant systems more practical.

There’s a lot that is still unknown about how to provide consensus with fair ordering. Current research is promising, and it looks like major improvements can be found. It’s important to keep pushing forward with this research, and to transition more mature research to practice. Over time, our systems can get better and better at resisting front-running.

Thesis 5: The worst thing we could do, right now, is to adopt an architecture that increases front-running, and lock ourselves into it.

First, do no harm. Adopting new protocols that increase front-running, such as use of “MEV Auctions” will make the front-running problem worse, and should be avoided.

Worst of all would be a change that locked us in to a world with more front-running. That would be immediately harmful, but its worst effect would be to prevent adoption of better, more resistant approaches as they are discovered.

The community is going to be dealing with front-running, and working to reduce it, for a long time.