Front running of transactions is a phenomenon that negatively affects the user experience and operation of the Ethereum blockchain. This behaviour is not something new in recent times. It has always existed on Ethereum and actually originates in traditional markets, particularly the stock market.
However, the problem of front running transactions has been exacerbated with the rise of the DeFi movement.
What is front running?
DeFi has fostered the creation of a variety of financial applications. One of the things that DeFi protocols allow is speculative activities aimed at making profits. This is where the activity of the front-runner comes in. It consists of identifying potentially profitable actions by users on the blockchain, and anticipating them in order to gain an advantage.
In general, the front-runner analyzes the blockchain to identify transactions that they will overlap with in order to make money. The term originated in the stock market, back in the days when trading was still done by hand and on paper through trading desks. Here is an example.
A broker receives an order from a client to buy a certain security. The broker estimates that the size of that order will drive up the price of the security, so he will place a buy order for himself before the client’s order.
In this way, the broker is able to benefit from the price increase following the execution of the client’s order. Or, in another case, he damages the client for raising the price of the security (by his purchase) before the execution of the order placed with him. Of course, the practice is unfair and has been declared illegal.
Front running on the blockchain
Front running is nothing more than a practice through which an entity benefits from prior access to privileged market information regarding upcoming transactions and exchanges. On the blockchain, the problem becomes much more serious.
First, all transactions are transmitted publicly. More importantly, participants in the blockchain are not bound by the same relationship that exists between a broker and his client. Attackers can exploit this knowledge of a transaction with impunity.
The typical example is that of DeFi’s decentralized exchanges.
A user places a large buy order that will cause the price of a token to move upwards. The front-runner sees this unconfirmed transaction and anticipates it with his own transaction to buy the same token. A profit will be made from the subsequent price increase due to the execution of the user’s order.
Alternatively, the front-runner may pass slippage onto the user. This occurs if the user enters a non-restricted order and the front-runner moves the (possibly illiquid) market with their own transaction ahead of that of the user.
Why is this the case?
The blockchain enables the execution of decentralized applications, or more generally smart contracts. Function calls (or transactions) are finalized in stages:
- first, they are propagated to the network, ending up in a “waiting room” called a mempool;
- then they are selected by a miner and put into a valid block;
- finally, the block becomes deeper as the chain lengthens, so that the immutability of the transaction becomes more and more likely.
So front running is an attack where a malicious node observes a transaction that has been transmitted to the network, but not yet finalized. The attacker attempts to get their transaction confirmed before – or instead of – the observed transaction.
Miners are in the best position to conduct these attacks. They have detailed control over the exact set of transactions that will be executed and their order. In general, however, any user monitoring transactions on the network (e.g. by running a full node) can see unconfirmed transactions. On the Ethereum blockchain, users have to pay for the gas used by the network to process their transactions. The price (gas price) that users offer for the gas consumed can increase or decrease the rate at which miners will include the transaction in a blockchain.
A miner (normally profit-oriented) who sees identical transactions but different fees will give priority to the transaction paying a higher gas price (due to limited space in the blocks). This is nothing more than a gas auction. Therefore, any user running a full node can front-run outstanding transactions by sending their transactions with a higher gas price.
Finally, well-placed transaction forwarding nodes on the network may also try to influence the way transactions are propagated. This may affect the order in which miners receive transactions or if they receive them at all.
Types of attacks
A variety of attacks can be carried out with front running, going far beyond trading activity and financial applications more generally. The scenarios are innumerable. It would be easier to draw up general categories of front running actions than to identify each specific case.
For instance, a front-running hypothesis could also arise in the case of a vulnerability in a smart contract. A user might try to exploit a bug to make a profit, but the front runner might copy the same transaction and anticipate it to use the vulnerability to his advantage.
Or a user may try to send a bug to receive a bounty but is tricked by the front runner who copies the transaction and anticipates him. Again in the case of domain registration, where the attacker manages to register a domain before the user’s transaction is confirmed.