Front-running attack in DeFi applications – how to deal with it?

Front-running has a great impact on the whole decentralized finance ecosystem. It is a well-known phenomenon since the first stock exchange began to rise in popularity. It can be defined as a course of actions where (not necessarily malicious) actors benefit from prior access to information about incoming trade. 

DeFi has much in common with the traditional finance system. In DEXes roles such as miners, traders and arbitrageurs take advantage of mechanisms behind front-running, in both foundational and malicious ways. On the one hand, these same mechanisms are currently necessary for balancing the market through, for example, liquidity pools arbitrage or under-collateralized loans liquidations (you can read more about those mechanisms HERE). But on the other hand, user experience is constantly falling due to higher price slippage caused by being a victim of flashbots.

How are the transactions ordered in blockchain?

In the blockchain network, immutable data is secured by decentralized nodes known as miners. They store and propagate unconfirmed, pending transactions within the so-called mempool (commonly referred to as a Dark Forest :)). Actually, access to the mempool data is indeed access to the list of incoming trades. Miners are also responsible for including valid transactions to the block but without a guarantee that they will be ordered in the same way as they were sent. However, the main factor influencing the order of transactions is money.

Like the traditional finance system, DeFi has to provide some incentives for all members. Mining subsidies and transaction fees are the ways that allow miners to gain rewards for the work performed. They arbitrarily choose transactions from mempool to be included in the block and ones with a higher fee are more likely to be picked sooner. However, they can reorder, include, exclude or censor transactions within certain blocks to increase their income. The value extracted in this manner is called Maximal Extractable Value (MEV).

New order with ETH 2.0 update?

Launching the beacon chain in December 2020 was the first stage for transitioning Ethereum to a Proof of Stake consensus model. MEV was previously known as ‘Miner Extractable Value’ and in order to adapt to the ETH 2.0 dimension the ‘miner’ word was changed to ‘maximal’. Since validators will do the same transactions ordering it is reasonable to assume that nothing is going to change in this matter.

But in our case miners are not the only one threat actor.

Let’s imagine that Alice is going to swap TokenA for TokenB from the liquidity pool. Meanwhile, attacker using Evil bot (threat actor) is scanning mempool, finds their transaction and place two other ones:

• TX2 transaction – the same TokenA for TokenB swap, with fewer amount of assets (to avoid causing a big price slippage) and with slightly more gas fee,

• TX3 transaction – TokenB for TokenA swap, with slightly lower gas fee.

First malicious transaction TX2 will be validated and executed before Alice’s TX1 transaction. To the best of the attacker’s knowledge, Alice’s transaction increases the price of TokenB. So the second Evil bot’s TX3 transaction is profitable for an attacker.

This kind of derivation of the front-running is called ‘sandwiching’, and is an example of malicious manner of taking advantage from MEV. 

All kinds of front-running attacks come down to one thing – the victim is trying to invoke a function from a contract with a particular state, when the threat actor is trying to invoke a function with the same state, but before the victim. 

We may distinguish two major threat actors:

1. Miners – Because of their ability to control and influence the order of transactions. They are not required to offer a higher gas price, so as to manipulate the transaction sequence. And furthermore, miners can only front-run in the blocks that they themselves mine.
2. Nodes – They shall be considered as users monitoring transactions in the mempool where they can choose unconfirmed transactions to front-run. The higher gas price they set, the higher chance the transaction is selected first. And if the user can front-run any transaction in the protocol, bad things happen.

Among the most profitable (and because of that potentially dangerous) areas where front-running matters, some platforms are worth highlighting. DEXes and NFT marketplaces could be great examples of places where securing against this attack MUST be taken into consideration not to let the user experience be destroyed.

Mitigations for front-running attack.

There are few opportunities to prevent protocol’s users from being front-runned. However, the proposed mitigations have to address two issues:

• Lack of transactions confidentiality – all information about transactions are   transparent to each actor,
• Miners’ ability of transaction ordering – usually based on the given gas fee.

Possible solutions have to take it into account. Nevertheless, they cannot decrease incentives for the system’s participants as well as to be efficient for everyone. 

Transaction sequencing

The main idea for this mitigation is to assign a sequence number to transactions in the protocol, so as to keep order of the execution process. The counter should be incremented every time the transaction modifies the smart contract’s state. This mechanism has to require a contract to compare the counter value given by the user as function argument and the counter value from the storage variable. If they are different, the transaction should revert. In other words, a transaction should specify the arbitrary contract’s state as the only state to execute itself.

Commit & reveal strategy

This solution basically relies on limiting the transaction’s visibility. Transaction is divided into two consecutive stages. Firstly, a hash of the desired value and nonce are sent into the smart contract as a commitment. Secondly, after an arbitrary period of time, the clear value of transaction and nonce are revealed. Logic implemented in the smart contract verifies if associated commitment is correct. Some enhanced improvements of this solution are added by a technique called Submarine Sends. However, the obvious drawback of this approach is that it adds additional overhead which increases the time of the transaction process. 

Off-Chain Ordering

This solution relies on trust for the third party. There are many ways to handle this kind of remediation. The transaction is simply split into two phases: ordering (out off blockchain) and settlement (on blockchain). Application providers are able to choose the most appropriate off-chain platform, according to their needs. The disadvantage of this approach is that the flow is less transparent for users.

Limit the gas price

The idea of this mitigation is to only accept transactions with a gas price below the appointed threshold. However, because of the gas price fluctuations, this solution requires permanent supervision in some cases. What is more, malicious miners can choose to not order the transactions by the gas price and still perform front-running. 

Determine minimal expected value

Decentralized applications should always force users to specify transaction minimal expected value or an acceptable price slippage. Because front-running is connected with high slippage, it seems reasonable to indicate the tolerable value derivation. Also, inform users that in order to protect themselves, it makes sense to split large transactions into few smaller ones to avoid flashbots-encouraging price impact. 

Prepare for front-running with threat modeling

Front-running attacks strongly depend on Dapp implementation. The best and most versatile recommendation is to remove the malicious actor’s benefit of the front-running in the application itself. 

However, you should model each protocol’s threats individually, during the design phase. Putting security issues at the beginning of the development process will save you a lot of time (and money) in the future. Why not build your solution secure from the very beginning? You can see how to approach the topic of threat modeling in this article.

If you have any question about this article, or need assistance in securing your decentralized application, feel free to contact us via contact form!

Jakub Zmysłowski IT Security Consultant