Key Mitigations

We classify the mitigations into three main categories. In the first category, the blockchain removes the miner’s ability to arbitrarily order transactions and tries to enforce some ordering, or queue, for the transactions. In the second category, cryptographic techniques are used to limit the visibility of transactions, giving the potential front-running less information to base their strategy on. In the final category, DApps are designed from the bottom-up to remove the importance of transaction ordering or time in their operations. We also note that for DApps that are legally well-formed (e.g., with identified parties and a clear jurisdiction), front-running attacks can violate laws, which is its own deterrent.

Transaction Sequencing

First-in-first-out (FIFO) is generally not possible on a distributed network because transactions can reach different nodes in a different order.

The vanilla Go-Ethereum (geth) implementation prioritizes transactions based on their gas price and nonce. Because no rule is enforced, miners can sequence transactions in advantageous ways. Nonetheless, some exchanges do centralize time-sensitive functionalities (e.g., EtherDelta and 0xProject) in off-chain order books.

One alternative is to sequence transactions pseudorandomly. This can be seen in proposals like Canonical Transaction Ordering Rule (CTOR) by Bitcoin Cash ABC which adds transactions in lexicographical order according to their hash. Note that Bitcoin does not have a front-running problem for standard transactions. While this could be used by Ethereum to make front-running statistically difficult, the protection is marginal at best and might even exacerbate attacks.

Confidentiality

A DApp interaction includes the following components:

(1) the code of the DApp

the code of the DApp (2) the current state of the DApp

the current state of the DApp (3) the name of the function being invoked

the name of the function being invoked (4) the parameters supplied to the function

the parameters supplied to the function (5) the invoked contract’s address

the invoked contract’s address (6) the identity of the sender.

Confidentiality applied to a DApp could mean different levels of protection for each of these. For front-running, function calls (3,4) are the most important, however, function calls could be inferred from state changes (2). Hawk and Ekiden are examples of (2,3,4)-confidentiality (with limitations we are glossing over).

The applicability of privacy-preserving blockchains needs to be evaluated on a case-by-case basis. For example, one method used by traditional financial ex- changes in dealing with front-running from high frequency traders is a dark pool: essentially a (2,3,4)-confidential order book maintained by a trusted party. A DApp could disintermediate this trusted party. Users whose balances are affected by changes in the contract’s state would need to be able to learn this information (e.g. Aztec Protocol exchange).

Commit/Reveal. While confidentiality appears insufficient for solving domain name front-running alone, a hybrid approach of sequencing and confidentiality can be effective and is, in fact, an example of an older cryptographic trick known as commit/reveal. The essence of the approach is to protect the function call (e.g., (3,4)- or (4)-confidentiality) until the function is enqueued in a sequence of functions to be executed. Once the sequence is established, the confidentiality is lifted and the function can only be executed in the order it was enqueued (or, generally speaking, not at all).

Recall that a commitment scheme enables one to commit to a digital value while keeping it a secret (hiding), and then open it (and only it: binding) at a later time of the committer’s choosing. A common approach (conjectured to be hiding) is to submit the cryptographic hash of the value with a random nonce (for low entropy data) to a smart contract, and later reveal the original value and nonce which can be verified by the contract to correctly hash to the commitment, as used in Namecoin and Ethereum Naming Service auctions.

Enhanced Commit/Reveal. Submarine Commitments extend the confidentiality of the commit and reveal, so that the commitment transaction is identical to a transaction to a newly generated Ethereum address. They initially hide the contract address being invoked, providing (3,4,5)-confidentiality during the commit phase; and they ensure that if a revealed transaction sent funds, the funds were fully collateralized at commit time.

Design Practices

The final main category of mitigation is to assume front-running is unpreventable and to thus responsively redesign the functionality of the DApp to remove any benefit from it. For example, when designing a decentralized exchange, one can use a call market design instead of a time-sensitive order book to sidestep and disincentivize front-running. In a call market design, the arrival time of orders does not matter as they are executed in batches.

Another example in the design of ERC20 standard is the allowance functionality. approve() function in the specification allows a second entity to be able to spend N tokens from the sender’s balance. In order to change the allowance, sender must send a transaction to set the new allowance value. Using the insertion attack, attacker could front-run the new allowance transaction and spend the old value before the new value is set, and then additionally spend the new amount at a later time. Solutions such as decreaseApproval()/increaseApproval() were added in updated implementations.