Table of Content:
1. How are transactions added to the blockchain?
2. Front Running Attacks
3. Example of Front Running Attack
4. Sandwich Attack
How are transactions added to the blockchain?
Before understanding the vulnerability, let’s first understand some terms and how transactions are submitted to the blockchain.
So, when the user submits transactions to the node, it is not instantly added to a block. Before verifying the transaction, these unmined transactions are kept in a sort of waiting room called Mempool.
The term “mempool” is a contraction of “memory” and “pool” and is used to describe the storage area of a node where validated transactions hang out, waiting to be mined and added to the blockchain.
Miners include valid transactions to the block but there is no guarantee that they will be ordered in the same way as they were sent. These miners execute transactions on the basis of fees. Miners can choose transactions from mempool to be included in the block and ones with a higher fee are more likely to be picked sooner. The higher the fees, the more quickly transactions are processed.
Front-running attacks take advantage of the process by which transactions are added to the blockchain’s distributed ledger.
A front-running attack occurs when a malicious user observes a transaction after a user broadcasts it and it is waiting in the mempool. The attacker then sends their own transaction for the motive of gaining some profit with higher gas fees. This will lead to the attacker’s transaction being executed before the users. Commonly, a miner or bot will place their own transaction immediately in front of the pending transaction.
Let’s understand Front Running using a practical example:
Suppose there is a quiz game, where 2 users can participate in the game paying $50 each. Whoever submits the correct answer first gets $100 as a reward.
Now, Alice and Bob participated in the game.
- Alice knows the answer to the given question but Bob doesn’t know it.
- Alice submitted the correct answer paying 15 gwei as fees.
- Meanwhile, Bob monitors the mempool for Alice’s answer. After finding Alice’s transaction with the answer, Bob submits the same but with higher gas fees (50 gwei).
- Now, what will happen is Miner will order Bob’s transaction before Alice as Bob paid higher fees. As a result, Alice loses the game and Bob wins the game gaining $100 despite not knowing the answer.
A sandwich attack is a form of front-running, which primarily targets decentralized finance protocols and services.
A sandwich attack involves “sandwiching” a user’s transactions in between two transactions. These two transactions are before and after the user's transaction (hence the name sandwich), generating a loss for the user and a gain for the attacker.
In a sandwich attack, an attacker will first monitor for pending transactions in the mempool. Then He will find the user's transaction and place two trades, one before the victim’s pending transaction (front-running) and another trading order just after it (back-running). The victim’s pending transaction will be sandwiched between the two new trade orders created by the attacker. The purpose of placing these two orders and surrounding pending transactions is to manipulate asset prices.
Let’s understand Sandwich Attack using a practical example:
Let us assume that Bob is swapping ETH for MATIC from a Uniswap pool. Now, an attacker monitors his transaction by scanning the mempool, and when he finds his transaction and he immediately places two orders.
Attacker’s 1st Txn: Swapping ETH for MATIC paying higher gas fees
Attacker’s 2nd Txn: Swapping back MATIC for ETH paying lower gas fees
- First, the attacker will front-run Alice’s transaction with the same swap (swapping ETH for MATIC) and thus increasing the price of MATIC.
- Now, after the price is increased Alice’s transaction is executed and she ends up paying more ETH for MATIC with higher price slippage.
- Once the victim’s transaction is executed, the attacker will swap his MATIC back to ETH and make a profit.
How to prevent these Attacks?
There are a few ways in which front-running attacks can be prevented. Some of them are mentioned below:
1. Keep maximum slippage low: Keep maximum slippage low, around 0.5%-2%, to fend off front runners. When placing a large order, keep your slippage at the lower keel. Front runners want you to keep slippage high, so better to do just the opposite of it.
2. Transaction Counter: In many, if not most cases, the attacker’s aim is to inconspicuously send a transaction before the victim’s transaction is executed. So, to prevent this, you can utilize a transaction counter within your smart contract. Whenever a state-modifying transaction occurs in your smart contract, increment a universal transaction counter by one.
3. Off-Chain Ordering: Off-chain ordering implies two steps: ordering (done, of course, not on the blockchain) and settlement (done on the blockchain). Whoever is implementing the ordering solution has the liberty of choosing from a huge list of potential platforms to build on. They can leverage features of those systems that blockchains may not have, such as time-stamped messages, free messages, and higher throughput.
4. Limit the gas price: This method to mitigate front-running also requires very little overhead (which saves your users on gas costs). In Solidity, one could make a
gasThrottle, which checks that the gas cost for the transaction making the function call (via
tx.gasPrice) is less than or equal to some amount which we’ll call
Check out this article for detailed Prevention measures against front-running attacks.
Web3 security- Need of the hour
Why QuillAudits for Web3 Security?
QuillAudits is well-equipped with tools and expertise to provide cybersecurity solutions saving the loss of millions in funds.
Want more Such Security Blogs & Reports?
Partner with QuillAudits :
- QuillAudits Partnership Programme ( Venture funds, launchpads, development companies, marketing firms, web2 cybersecurity firms, web3 products )