Unboxing front-running attack
In today’s post we’re going to unbox another popular type of attack, front-running transactions. This type of attack takes different forms and can be used in various ways. One of the examples of front-running I explained recently during ERC20 approval unboxing. But first thing first.
What is a front-running attack?
A blockchain creates a permanent ledger of transactions. Once something is added to the blockchain, it cannot be removed. So blockchains need a mechanism to figure out the sequence of how transactions are written to the block. The mempool is a waiting area for the transactions that haven’t been added to a block and are still unconfirmed. Mempool enables transaction ordering, transaction fee prioritization, and general block construction.
All transactions are visible in the mempool for a short period before being executed. Miners or other network observers can see and react to a transaction before it is included in a block. Most time, transactions with the highest gas prices are included first as the miners get the gas price for including them into the block.
Some have found a way to exploit this. Front-running, works like this: Transaction B is broadcasted with a higher gas price than an already pending transaction A so that B gets minedbefore A.
Simple? Yes. Devastating? Yes.
What can a malicious observer do with such knowledge and insight into a mempool?
One typical example which comes to mind is a decentralized exchange. When there is a buy order for asset X traded for asset Y, this can be front-run to buy the asset Y. An attacker knows that the victim trade will increase the price of the asset Y so by front-running the first transaction, he lets the victim buy at asset Y for a higher price. An attacker can then sell the asset again at a higher price afterward.
This is also known as a sandwich attack.
The attacker plans to buy this asset cheap, let the victim buy at an increased price, and then sell the received amount again at a higher price afterward.
If you want to learn more about the Sandwich attack, there is a great article by cmichel.
This is only one example of a front-run attack. Consensys created a great entry about this type of attack and potential variants.
ConsenSys
Are there any ways to protect against this type of attack?
Unfortunately, there isn’t one simple answer to this. Project developers can take proactive measures to remove the benefit of front-running in their application simply by removing the importance of transaction ordering or time. But that isn’t always possible. Take as an example Uniswap or other AMM products.
A potential solution to that would be to create batch transactions or private transactions. Private transactions could be done using the “commit and reveal” scheme. The issue with this is it requires two transactions to complete one simple trade.
As a user you could guard yourself against front-running by sending private transaction through https://taichi.network/.
Another solution would be to use flashbots bundle transaction feature which can help you mitigate potential for being front-run.
There is some potential protection against it, but it is a complex subject to cover in this article. I can recommend reading cmichel article and this hackernoon article, apart from diving into flashbots.
Can we protect ourselves from this attack ever? I don’t know, probably not. It’s all comes down to the mempool and the information which are portrait there by pending transactions. As long there is easy access to mempool, MEV (Most Extractable Value) will always be possible.
Thanks for reading, and if you like my writing, you can subscribe to my blog to receive the daily newsletter as I’m currently in the middle of 100 days of blogging challenge. Subscription box below 👇
If the newsletter is not your thing, check out my Twitter @adrianhetman, where I post and share exciting news from the Blockchain world and security.
See you tomorrow!