Impact of frontrunning & randomness on UX

The exotic queue (0:00)

When people send transactions on Ethereum, they get added to a queue before being included in the blockchain.

This queue acts differently from normal queues : transactions can be reordered or held back rather than always being processed in a strict "first-in-first-out" or "first-come-first-served" (FIFO/FCFS) way.

The person controlling the queue and deciding what order to include transactions is called the "scheduler." Schedulers have a lot of flexibility to manipulate the order for their own interests.

Some exotic scheduling activity (1:30)

Frontrunning is when the scheduler adds their own transaction ahead of someone else's transaction in the queue. Frontrunning is generally considered "bad" because it directly interferes with and exploits other people's pending transactions.

Backrunning is adding a transaction behind someone else's. Backrunning may be useful or bad depending on who you ask, as it doesn't directly interfere with the target transaction. It may be used for arbitrage or liquidations which can be useful for market functioning, or used to exploit other people's failed transactions.

So there are open questions around how to create queueing rules and incentives that balance different needs

New queuing disciplines (2:50)

Andrew (the speaker) introduces a specific type of queue design called a "backrun auction" :

• Users place orders (like transactions) into a pool. These orders get labeled and put in some order by the system.
• Separately, there are "searchers" who can insert their own special orders immediately after any user's order.
• So if the user orders are labeled tx1, tx2, tx3 etc, a searcher can put their own tx in right after any tx they want.

This creates a priority queue where the user orders execute first in some order, but searchers get the very next slot after any user order.

It prevents abusive manipulation by enforcing the rule that searchers can only insert orders AFTER a user's, not jump ahead or mess with the base order.

Searcher's perspective (5:00)

The searchers may have imperfect information about :

• The details of the user transactions they can backrun
• How the users' transactions are ultimately ordered
• Which user transaction the searcher's own transaction will be matched with

Example :  on some systems like Flashbots' MEV-Share, users can hide some or all details about their trades from the searchers.

The searchers may know which user trades they'll be able to backrun, but not know the final order those trades will be included in the blockchain. Even if a searcher knows the one user trade they'll be matched to backrun, they don't know which user trade will come after theirs in the final order.

In the end, This lack of information makes it difficult for the searchers to create manipulative "frontunning" transactions

There is still room for manipulative behavior (6:30)

Suppose all transactions are trades on "Constant Function Market Makers" (i.e. Uniswap).

A common attack here would be to manipulate the price in order to "sandwich" a user's trade between your own trades to profit. To do this, you need your transactions scheduled right before and after the user's transaction.

In an ideal case, there's too much competition between searchers to realistically get two slots in a row. However, if there's any chance of getting two consecutive slots, it can be profitable to attempt a sandwich attack, even if you have very little specific information about user trades and order.

This is especially true when :

• One searcher monopolizes all the backrun spots
• Expected Value is positive

Expected Value of frontrunning strategies must be negative. So there must be enough competition among searchers to keep the probability of winning two consecutive backrun spots low enough.

Quantifying how bad manipulation can be (7:50)

Andrew has done some mathematical analysis to try to quantify exactly how much price manipulation can happen within this backrun auction model : Price manipulation converges to zero as either :

• The user trades are small
• There is a lot of competition between searchers

The optimal strategy for searchers is to do little or no price manipulation, and instead just set prices similar to the wider market.

Next steps (9:20)

This allows designers of decentralized exchanges to potentially make claims about how resistant to manipulation their systems are under this queue model.

However, the current analysis assumes just one batch of transactions. Andrew says the next step is to expand the model to multiple blockchain blocks.

When searchers can coordinate across multiple blocks, that likely enables more manipulation strategies like "Stackelberg Commitments"

Stackelberg Commitments : strategically restricting a rival's options by moving aggressively first and committing resources, rather than waiting to react later.