Front-Running Attacks on Blockchain
The main focus of this article is front running attacks on Decentralized Applications (DApp) and smart contracts. In a blockchain system, transactions are broadcasted to the network, then a party in the system called ‘miners’ selects transactions, validates them, and puts them into a valid block that is eventually added to an immutable chain of blocks. The transaction is visible to the nodes when it is propagated to the network and before a miner processes the transaction, a malicious node can observe the transaction and find its purpose and construct his own malicious request (transaction) based on the observed transaction. This article explains what front running attackers are, different front-running attack scenarios, possible ways to mitigate and protect the system against these attacks, and existing proposals that intend to solve front running attacks as examples.
Possible Front-running Attackers
Eliminating central parties and substituting them with new decentralized untrusted parties with the same functionality add some parties who can conduct front running attacks.
- Miners are in the best position to conduct these attacks. Miners can control the order of transaction execution and mix transactions with their late transactions without broadcasting them.
- Full nodes (users monitoring network transactions) have the ability to see unconfirmed transactions. In the case of Ethereum, gasPrice is a good factor for a profit-motivated miner to prioritize orders. The higher your gasPrice is, the higher the chance of your transaction being selected. As a result, any Ethereum full node client can front-run pending transactions by sending its own adjusted transactions with a higher gas price.
- Well-positioned relaying nodes on the network or in some rare cases, a part of the internet backbone, can have an influence on the transaction propagation through the network. They can also affect the order in which the miners receive the transactions or if they receive them at all.
Different Attack Scenarios
- Displacement Scenario:
When Alice sends a transaction, an attacker can steal her transaction and push his transaction with the same call and the same value. For instance, once Alice sends a domain registration request, the adversary can steal her request, issue the same domain name and finalize it before Alice’s request. Therefore, Alice’s request would be meaningless.
- Insertion Scenario:
A transaction changes the state of the contract. If Alice sends a transaction after the attacker changes the state of the contract, her request will be processed in a new state modified by the attacker. For instance, if Alice places a purchase order at a higher price than the best offer, the attacker will insert two transactions: the adversary will purchase at the best-offer price and then offer the same asset for sale at a price slightly higher than Alice’s. If Alice’s transaction is then run after, the attacker will profit from the price difference without having to hold the asset.
- Suppression Scenario:
The adversary tries to delay Alice from running her function after he runs his function. After the delay period, it does not matter for the adversary whether Alice’s transaction runs or not.
Here we mainly talk about the insertion scenario.
Mitigation
The key problems of a system that make it vulnerable to front-running attacks are first, a lack of transaction confidentiality, and second, the miner’s ability to arbitrarily order transactions that can be the result of an asynchronous system. In order to prevent the front-running attack, a suitable solution must address these two problems or change the whole structure to prevent race conditions. A list of possible measurements in three different categories are described as follows:
1. Transaction Ordering
Transaction-ordering is a way to tackle asynchronicity. Ethereum picks transactions that are stored in pending transaction pools when creating blocks. There is no predefined order to how transactions are picked and miners can freely put them in an arbitrary sequence. Because there are no rules, profits could be the main motivation for miners to choose transactions from pools. Ways to enforce rules to diminish this attack are listed below:
- First-in-First-out (FIFO):
(FIFO) is generally not feasible on a distributed system because transactions can reach different nodes in different orders. Although we can add a complex consensus-based solution to use locally observed FIFO, it would lead to an increase in the rate of orphaned blocks.
- Trusted Third Party:
A trusted third party can be a source to assign sequential numbers to transactions (and sign them), but this is contrary to blockchain’s core innovation of distributed trust. Also, it might add a single point of failure and an additional delay in the process of transaction validation to the system.
- Randomized Order:
Bitcoin Cash ABC orders transactions in lexicographical order according to their hash. This idea is proposed as Canonical Transaction Ordering Rule (CTOR).
Bitcoin does not have a front-running problem for standard transactions due to being protected against the race condition.
Note: Although this could be used by Ethereum to make front-running statistically difficult, it would not add additional security and the system would not be immune to front running attacks. The adversary can conduct multiple equivalent transactions, with subtle different values, until they find the best position in the transaction order. The adversary propagates only that transaction and now miners that include the adversary’s transaction will position it in front of transactions that they heard about much earlier.
- Transaction Chaining
The transaction itself can enforce the order of transactions. For example, in a blockchain like Ethereum, states are changed based on transactions; therefore, transactions could specify the current state of the contract as the only state to execute. This transaction chaining only prevents insertion attacks while the system is still vulnerable to displacement attacks.
Mitigation example: Injective Protocol
The injective protocol is designed for decentralized exchanges that are highly vulnerable to front running attacks. The main idea behind the protocol is that a user must provide publicly verifiable proof-of-elapsed-time construction using a verifiable delay function (VDF). Proof-of-elapsed-time is a measurement to choose the Taker (which is part of the blockchain that inject orders into a smart contract for settlement). A user who wants to take the order begins to solve the VDF. The longer it takes, the higher the chance that the user has to become the Taker. If a person starts to solve the VDF first, he’s had more time. The idea seems promising to solve the transaction ordering issue, but it adds overhead to transaction size and computation resources while adding additional complexity to the consensus algorithm.
2. Confidentiality Strategies
In order to get a good understanding of confidentiality, we have to look at different components of a DApp and their potential confidentiality problem. Reference: SoK: Transparent Dishonesty.
Components of a DApp:
- The code of the DApp.
- The current state of the DApp.
- The name of the function being invoked.
- The parameters supplied to the function.
- The address of the contract on which the function is being invoked.
- The identity of the sender.
Components 3 and 4 are the two main parts that should be protected and kept hidden from the public. If an adversary finds access to one of them, he can construct his own request based on them. Components 2 and 5 are optional parts that should be hidden based on applications and their functionality.
- Commit/Reveal strategy
The concept is driven from a cryptography concept called commitment scheme. A commitment scheme allows a user to commit to a digital value; the owner can include as much information as he wants. He can reveal the actual transaction later at the desired time.
We can utilize the commit/reveal strategy that is a confidentiality trick. We can protect the function call (e.g., (3,4)- or (4)-confidentiality) until the function is en-queued in the order of functions to be executed. This approach can be applied until the sequence is established, the confidentiality is lifted and the function can only be executed in the place it was given.
The figure below exhibits a common method in which the cryptographic hash of the value is sent with a random nonce to a smart contract as a commitment. After a period of time, the original value and nonce are revealed. The smart contract can then verify the correctness of the commitment.
Commit/reveal drawbacks
- An adversary can send multiple committed transactions and reveal only the one that will lead to an advantageous trade.
- Usability challenges are a common problem of multiple round protocols. Users must be aware to commit to the subsequent rounds.
- Commit/reveal scheme adds some additional overhead to the transaction size.
Mitigation example: CodeChain DEX Protocol
The CodeChain platform supports an on-chain order for its DEX (Decentralized Exchange). CodeChain uses the principle behind the commit/reveal scheme to immune the system against front running attacks. In the CodeChain DEX protocol, the trader encrypts the order with a publicly known encryption key. There is an entity called reveal agent (to be discussed in detail in the next chapter) that reveals the decryption key after a period of time. CodeChain makes sure that reveal agents reveal their decryption keys on time with the reward system and using Shamir’s Secret Sharing Scheme to recover the secret key that is required to reveal the committed order with a predefined `minimum` number of reveal agents. This idea decentralizes the classical commit/reveal scheme, which is not bound to traders’ decisions. Traders are not entities that can decide whether to reveal their commitments or not. Instead, reveal agents take responsibility and reveal with regards to the Shamir’s Secret Sharing Scheme. Besides, to have less transaction size, traders can choose not to encrypt the transaction if they believe it is safe to trade.
Reveal Agent
In the CodeChain DEX protocol, reveal agents are the only agents designed to publish the decryption key for every block. An account can be a valid reveal agent if it deposits more CCC (CodeChain Coin) than the minimum defined deposit called MIN_DEPOSIT. Once the account is recognized as a valid reveal agent, its public key will be recorded in the state.
Committing Phase
This phase encrypts some part of the order with a random secret key. Using Shamir’s Secret Sharing Scheme, the secret key is separated into different parts and encrypted with the public key of the reveal agents. The figure below shows the step by step algorithm of the commitment phase. Z is the sufficient number of reveal agents defined as a threshold in the Shamir’s secret sharing scheme.
Revealing Phase
When z numbers of reveal agents publish their secret keys, the actual secret key of the commitment phase can be recovered. If the number of reveal agents is not as large as z or the order is invalid, the order will not proceed and the trading fee is charged. When the decryption is released, the execution of the order begins and reveal agents will be rewarded with the incentive procedure of CodeChain.
Summary
This article mainly discussed front running attacks and some possible solutions to mitigate and harden the system against such attacks. In addition, the CodeChain DEX protocol was presented as a novel approach where a node will not reveal its commitment, and instead, decentralized third parties will take the responsibility of revealing the commitment. By adding third decentralized parties, CodeChian is enabled to overcome front running attacks.
