Professional Documents
Culture Documents
Frontrunner Jones and The Raiders of The Dark Forest: An Empirical Study of Frontrunning On The Ethereum Blockchain
Frontrunner Jones and The Raiders of The Dark Forest: An Empirical Study of Frontrunning On The Ethereum Blockchain
SnT/University of Luxembourg
1
Ethereum is given. Transactions, submitted to the Ethereum 2 Background
network, send money and data to smart contract addresses
or account addresses. Transactions are confirmed by miners This section provides the necessary background to understand
who get paid via a fee that the sender of the transaction pays. our work setting, including smart contracts, transactions, gas
This payment is also responsible for the speed/priority min- economics, and transaction ordering.
ers include a transaction in a mined block. Miners have an
inherent incentive to include high paying transactions and
2.1 Smart Contracts
prioritize them. As such, nodes observing the unconfirmed
transactions can front-run by just sending transactions with The notion of smart contracts has already been introduced
higher payoffs for miners [9]. The common feature of all three in 1997 by Nick Szabo [25], but the concept only became a
attack types is that by frontrunning a transaction, the initial reality with the inception of Ethereum in 2015 [29]. Ethereum
transaction’s expected outcome is changed. In the case of the proposes two types of accounts: externally owned accounts
first attack (displacement), the outcome of a victim’s original (EOA) and contract accounts (smart contracts). EOAs are con-
transaction is irrelevant. The second attack type (insertion) trolled via private keys and have no associated code. Contract
manipulates the victim’s transaction environment, thereby accounts, i.e., smart contracts, have associated code but are
leading to an arbitrage opportunity for the attacker. Finally, not controlled via private keys. They operate as fully-fledged
the third attack (suppression) delays the execution of a vic- programs that are stored and executed across the blockchain.
tim’s original transaction. Although previous papers [9, 12] EOAs and smart contracts are identifiable via a unique 160-bit
have identified decentralized applications which are victims address. Smart contracts are immutable, and they cannot be
of frontrunning attacks, no scientific study has analyzed the removed or updated once they have been deployed unless they
occurrence of these three attacks in the wild on a large scale. have been explicitly designed to do so. Besides having a key-
The impact of this structural design failure of the Ethereum value store that enables them to preserve their state across
blockchain is far-reaching. Many decentralized exchanges, executions, smart contracts also have a balance that keeps
implementing token-based market places have passed the 1B track of the amount of ether (Ethereum’s cryptocurrency)
USD volume [26] and are prone to the same frontrunning that they own. Smart contracts are usually developed using a
attack vectors because the Ethereum blockchain is used as a high-level programming language, such as Solidity [30]. The
significant building block. Frontrunning is not going to dis- program code is then compiled into a low-level bytecode rep-
appear any time soon, and the future looks rather grim. We resentation, which is then interpreted by the Ethereum Virtual
do not expect to have mitigation against frontrunning in the Machine (EVM). The EVM is a stack-based virtual machine
short-term. Miners do profit from the fees and thus will al- that supports a set of Turing-complete instructions.
ways prioritize high yield transactions. Moreover, the trust
mechanism in Ethereum is built on the total observability of
the confirmed/unconfirmed transactions and is thus by design 2.2 Transactions
prone to frontrunning. Our paper sheds light into the long Smart contracts are deployed and executed via transactions.
term history of frontrunning on the Ethereum blockchain and Transactions contain an amount of ether, a sender, a receiver,
provides the first large scale data-driven investigation of this input data, a gas limit and a gas price. Transactions may only
type of attack vector. We investigate the real profits made by be initiated by EOAs. Smart contract functions are invoked
attackers, differentiated by the specific attack type and pro- by encoding the function signature and arguments in a trans-
pose the first methodology to detect them efficiently. action’s data field. A fallback function is executed whenever
Contributions. We summarize our contributions as follows: the provided function name is not implemented. Smart con-
• We propose a methodology that is efficient enough to tracts may call other smart contracts during execution. Thus,
detect displacement, insertion, and suppression attacks a single transaction may trigger further transactions, so-called
on Ethereum’s past transaction history. internal transactions.
2
𝑇! 𝑇! 𝑇! 𝑇! 𝑇! 𝑇!
Ordered by Gas Price
𝑇# 𝑇% 𝑇# 𝑇% 𝑇# 𝑇$"
𝑇# 𝑇$" 𝑇$#
𝑇# 𝑇%
𝑇#
defines the amount of ether that the sender is willing to pay deliberately creating a prioritization mechanism for transac-
per unit of gas used. The sender is required to have a balance tions [31].
greater than or equal to gas limit × gas price, but the final
transaction fee is computed as the gas used × gas price. The
price of gas is extremely volatile as it is directly linked to the 3 Frontrunning Attacks
price of ether. As a result, Breidenbach et al. [6] proposed
GasToken, a smart contract that allows users to tokenize gas. This section defines our attacker model and introduces the
The idea is to store gas when ether is cheap and spend it reader to three different types of frontrunning attacks.
when ether is expensive, thereby allowing users to save on
transaction fees. Two versions of GasToken exist, whereby 3.1 Attacker Model
the second version is more efficient than the first one. The
first version of GasToken (GST1) exploits the fact that gas is Miners, as well as non-miners, can mount frontrunning attacks.
refunded when storage is freed. Hence, gas is saved by writing Miners are not required to pay a higher gas price to manip-
to storage and liberated when deleting from storage. The ulate the order of transactions as they have full control over
second version of GasToken (GST2) exploits the refunding how transactions are included. Non-miners, on the other hand,
mechanism of removing contracts. Hence, gas is saved by are required to pay a higher gas price in order to front-run
creating contracts and liberated by deleting contracts. In 2020, transactions of other non-miners. Our attacker model assumes
1inch released their version of GST2 called ChiToken [1], an attacker A that is a financially rational non-miner with
which includes some optimizations. the capability to monitor the transaction pool for incoming
transactions. The attacker A needs to process the transactions
in the pool, find a victim V among those transactions and
2.4 Transaction Ordering create a given amount of attack transactions TAi before the
victim’s transaction TV is mined. Usually, A would not be
A blockchain is essentially a verifiable, append-only list of able to react fast enough to perform all these tasks manually.
records in which all transactions are recorded in so-called Hence, we assume that the attacker A has at least one com-
blocks. This list is maintained by a distributed peer-to-peer puter program BotA that automatically performs these tasks.
(P2P) network of distrusting nodes called miners. Miners However, BotA must be an off-chain program, because con-
follow a consensus protocol that dictates the appending of tracts cannot react on its own when transactions are added to
new blocks. They compete to create a block by solving a the pool. Nevertheless, BotA needs at least one or more EOAs
cryptographic puzzle. The winner is rewarded with a static to act as senders of any attack transaction TA . Using multiple
block reward and the execution fees from the included trans- EOAs helps attackers obscure their frontrunning activities,
actions [14]. While blockchains prescribe specific rules for similar to money laundering layering schemes. We refer to
consensus, there are only loose requirements for selecting these EOAs owned by A as attacker accounts EOAA j and to
and ordering transactions. Thus, miners get to choose which the EOA owned by V as victim account EOAV . We assume
transactions to include and how to order them inside a block. that attacker A owns a sufficiently large balance across all
Nevertheless, 95% of the miners choose and order their trans- its attacker accounts EOAA j from which it can send frontrun-
actions based on the gas price to increase their profit, thereby ning transactions. However, attacker A can also employ smart
3
Suppression. In a suppression attack, an attacker A observes
a transaction TV from a victim V and decides to broad-
Attacker Bot Attacker EOAs Bot Contracts
cast its transactions to the network, which have a higher
gas price than TV such that miners will include A’s trans-
action before TV (see Figure 1 c). The goal of A is to
suppress transaction TV , by filling up the block with its
transactions such that transaction TV cannot be included
anymore in the next block. This type of attack is also
Off-Chain On-Chain called block stuffing. Every block in Ethereum has a
so-called block gas limit. The consumed gas of all trans-
actions included in a block cannot exceed this limit. A’s
Figure 2: Attacker model with on-chain and off-chain parts. transactions try to consume as much gas as possible to
reach this limit such that no other transactions can be
included. This type of attack is often used against lotter-
contracts to hold part of the attack logic. We refer to these ies where the last purchaser of a ticket wins if no one
smart contracts as bot contracts BCAk , which are called by the else purchases a ticket during a specific time window.
attacker accounts EOAA j . Figure 2 provides an overview of Attackers can then purchase a ticket and mount a sup-
our final attacker model. pression attack for several blocks to prevent other users
from purchasing a ticket themselves. Keep in mind that
this type of frontrunning attack is expensive.
3.2 Frontrunning Taxonomy
We describe in the following the taxonomy of frontrunning
4 Measuring Frontrunning Attacks
attacks presented by Eskandari et al. [12].
This section provides an overview of our methodology’s de-
Displacement. In a displacement attack an attacker A ob- sign and implementation details to detect frontrunning attacks
serves a profitable transaction TV from a victim V and in the wild.
decides to broadcast its own transaction TA to the net-
work, where TA has a higher gas price than TV such that
miners will include TA before TV (see Figure 1 a). Note 4.1 Identifying Attackers
that the attacker does not require the victim’s transaction
to execute successfully within a displacement attack. For As defined in Section 3.1, an attacker A employs one or more
example, imagine a smart contract that awards a user off-chain programs to perform its attacks. However, because
with a prize if they can guess the preimage of a hash. An we have no means to distinguish between the different soft-
attacker can wait for a user to find the solution and to sub- ware agents an attacker A could have, for this study, we con-
mit it to the network. Once observed, the attacker then sider all of them as part of the same multi-agent system BotA .
copies the user’s solution and performs a displacement Additionally, we cannot recognize the true nature of A or how
attack. The attacker’s transaction will then be mined first, BotA is implemented. Instead, we would like to build a cluster
thereby winning the prize, and the user’s transaction will with the n different attacker accounts EOAA1 , . . ., EOAAn and
be mined last, possibly failing. the m different bot contracts BCA1 , . . ., BCAm to form an iden-
tity of A. Consequently, in each of the following experiments,
Insertion. In an insertion attack an attacker A observes a we use our detection system’s results to build a graph. Each
profitable transaction TV from a victim V and decides node is either an attacker account or a bot contract. We make
to broadcast its own two transactions TA1 and TA2 to the the following two assumptions:
network, where TA1 has a higher gas price than TV and
TA2 has a lower gas price than TV , such that miners will Assumption 1: Attackers only use their own bot contracts.
include TA1 before TV and TA2 after TV (see Figure 1 b). Hence, when an attacker account sends a transaction to
This type of attack is also sometimes called a sandwich a bot contract, we suspect that both entities belong to the
attack. In this type of attack, the transaction TV must same attacker. Note that one attacker account can send
execute successfully as TA2 depends on the execution of transactions to multiple bot contracts, and bot contracts
TV . A well-known example of insertion attacks is arbi- can receive transactions from multiple attacker accounts.
traging on decentralized exchanges, where an attacker
observes a large trade, also known as a whale, sends a Assumption 2: Attackers develop their own bot contracts,
buy transaction before the trade, and a sell transaction and they do not publish the source code of their bot con-
after the trade. tracts as they do not want to share their secrets with
4
Input Bytes 4 bytes with an offset of 1 byte and check whether at least
deadbeefcafebabe ... 95% of the n-grams match n-grams of previous transaction
deadbeef
inputs. Each window has its own Bloom filter that memorizes
previously observed n-grams. A Bloom filter is a probabilis-
adbeefca
tic data structure that can efficiently tell if a given element
beefcafe
may already have been seen before or if it definitely has not
...
been seen before, meaning that Bloom filters may yield false
positives, but no false negatives. The idea is first to use a
Bloom filter to perform a quick probabilistic search and only
0 1 1 1 1 0 1 0 1 0 0 0 0 0 1 0 perform an exhaustive linear search if the filter finds that at
Bloom Filter least 95% of a transaction’s n-grams are contained in the filter.
Our Bloom filters can hold up to n = 1M elements with a false
positive rate p = 1%, which according to Bloom [3], requires
Figure 3: An example on how transaction input bytes are having k = 6 different hash functions:
mapped into a bloom filter.
n ln p
m=− (1)
(ln 2)2
competitors. Hence, when the bytecode of two bot con-
tracts is exactly the same, we suspect that they belong to m
k= ln 2 (2)
the same attacker. n
We bootstrapped our 6 hash functions using the Murmur3
With these assumptions in mind, we create edges between hash function as a basis. The result of each hash function is
attacker accounts and bot contracts that share at least one an integer that acts as an index on the Bloom filter’s bit array.
attack transaction, and between bots that share the same byte- The bit array is initialized at the beginning with zeros, and a
code. Using the resulting graph, we compute all the connected value of one is set for each index returned by a hash function
components. Hence, we interpret each of these connected (see Figure 3). An n-gram is considered to be contained in
components as a single attacker cluster. the filter if all indices of the 6 hash functions are set to one.
We use interleaved n-grams because the input of a copied
transaction might be included at any position in the attacker’s
4.2 Detecting Displacement
input. Once our linear search finds two transactions TA and TV
We limit our detection to displacement attacks where attack- with matching inputs, we check whether the following three
ers observe profitable transactions via the transaction pool heuristics hold:
and copy these profitable transactions’ input to create their Heuristic 1: The sender of TA and TV as well as the receiver
own profitable transactions. While attackers are not required of TA and TV must be different.
to use a bot contract to mount displacement attacks, using a
smart contract allows them to save money as they can abort Heuristic 2: The gas price of TA must be larger than the gas
the execution in case of an unexpected event. Therefore, our price of TV .
detection focuses on finding attackers that use bot contracts
Heuristic 3: We split the input of TA and TV into sequences
to perform internal transactions of copied inputs. The general
of 4 bytes, and the ratio between the number of the se-
idea is to detect displacement by checking for every trans-
quences must be at least 25%.
action T if there exists a subsequent transaction T 0 with a
gas price lower than T and a transaction index higher than T , Finally, to validate that TA is a copy of TV , we run in a sim-
where the input of T 0 is contained inside the input of T . How- ulated environment first TA before TV and then TV before TA .
ever, detecting displacement in the wild can become quite We report a finding if the number of executed EVM instruc-
challenging due to a large number of possible combinations. tions is different across both runs for TA and TV , as this means
A naive approach would compare every transaction to ev- that TA and TV influence each other. During our experiments,
ery subsequent transaction in the blockchain, resulting in a we noted, that some bot contracts included code that checks if
combinatorial explosion. Our goal is to follow a more effi- the miner address of the block that is currently being executed
cient approach that might sacrifice completeness but preserve is not equal to zero. We think that the goal of this mechanism
soundness. We begin by splitting the range of blocks that are could be to prevent transactions from being run locally.
to be analyzed into windows of 100 blocks and slide them
with an offset of 20 blocks. This approach has the advantage
4.3 Detecting Insertion
that each window can be analyzed in parallel. Inside each
window, we iterate block by block, transaction by transaction, We limit our detection to insertion attacks on decentralized
and split the input bytes of each transaction into n-grams of exchanges (DEXes). At the time of writing, we are not aware
5
of any other use case where insertion attacks are applied in
the wild. DEXes are decentralized platforms where users can
trade their ERC-20 tokens for ether or other ERC-20 tokens
via a smart contract. Uniswap is currently the most popu-
lar DEX in terms of locked value with 3.15B USD locked1 .
There exist two genres of DEXes, order book-based DEXes
Token 𝑦 Reserve
and automated market maker-based (AMM) DEXes. While
order book-based DEXes match prices based on so-called
’bid’ and ’ask’ orders, AMM-based DEXes match and settle
trades automatically on-chain via a smart contract, without 𝑝!" (sell)
the need of third party service. AMMs are algorithmic agents 𝑝" (buy)
that follow a deterministic approach to calculate the price 𝑝!! (buy)
of a token. Uniswap, for example, is an AMM-based DEX,
which computes for every trade the price of a token using the
Token 𝑥 Reserve
equation of a constant product market maker (CPMM):
6
Heuristic 5: The transaction index of EA1 must be smaller If we happen to find a cluster that fulfils the heuristics men-
than the transaction index of EV , and the transaction tioned above, we check whether at least one of the neighbour-
index of EV must be smaller than the transaction index ing blocks (i.e., the previous block and the subsequent block)
of EA2 (i.e., iA1 < iV < iA2 ). also contains a cluster that satisfies the same heuristics. We
assume that an attacker tries to suppress transactions for a
Heuristic 6: The gas price of EA1 must be larger than the sequence of blocks. Finally, we try to detect if an attacker
gas price of EV , and the gas price of EA2 must be less of employs one of three suppression strategies by retrieving and
equal to the gas price of EV (i.e., gA1 > gV ≥ gA2 ). analyzing the execution trace of the first transaction in the
cluster. An execution trace consists of a sequence of executed
4.4 Detecting Suppression instructions. We detect the first strategy by checking if the
transaction did not raise an exception and if the instruction se-
In suppression, an attacker’s goal is to submit transactions to
quence [GAS, GT, ISZERO, JUMPI] is executed more than
the network that consume large amounts of gas and fill up the
ten times in a loop. We detect the second strategy by checking
block gas limit to withhold a victim’s transaction. There are
if the transaction raised an exception via a revert and if the
several ways to achieve this. The naive approach uses a smart
instruction sequence [SLOAD, TIMESTAMP, ADD, SSTORE]
contract that repeatedly executes a sequence of instructions in
is executed more than ten times in a loop. Finally, we de-
a loop to consume gas. This strategy can either be controlled
tect the third strategy by checking if the transaction raised an
or uncontrolled. In a controlled setting, the attacker repeat-
exception via an assert.
edly checks how much gas is still left and exits the loop right
before all gas is consumed such that no out-of-gas exception
is raised. In an uncontrolled setting, the attacker does not 4.5 Challenges and Limitations
repeatedly check how much gas is left and lets the loop run
until no more gas is left and an out-of-gas exception is raised. We were compelled to make trade-offs between efficiency
The former strategy does not consume all the gas and does not and completeness with more than 11M blocks and over 1B
raise an exception which makes it less obtrusive, while the transactions. For instance, to detect displacement attacks, we
latter strategy does consume all the gas but raises an excep- had to set a window size of 100 blocks, meaning that we could
tion which makes it more obtrusive. However, a third strategy not detect displacement attacks were an attacker’s transaction
achieves precisely the same result without running code in and a victim’s transaction are more than 100 blocks apart.
an infinite loop. If we think about it, the attacker’s goal is Another example is insertion detection, where we assume
not to execute useless instructions but rather to force miners that the attacks occur within the same block. However, this
to consume the attacker’s gas units to fill up the block. The assumption does not always hold, as transactions might be
EVM proposes two ways to raise an error during execution, scattered across different blocks during the mining process.
either through a revert or an assert. The difference between Theoretically, it would be possible to attack victims using
revert and assert is that the former returns the unused gas to attacker accounts directly for displacement and suppression
the transaction sender, while the latter consumes the entire attacks. However, our detection heuristics rely on the exis-
gas limit initially specified by the transaction sender. Hence, tence of the bot contracts to identify attackers as a single
an attacker can exploit this and call an assert to consume all entity. Considering these limitations, all the results presented
the provided gas with just one instruction. Our goal is to de- in this paper should be interpreted as lower bounds, and they
tect transactions that employ one of the three aforementioned might be solely the tip of the iceberg.
suppression strategies: controlled gas loop, uncontrolled gas
loop, and assert. We start by clustering for each block all
transactions with the same receiver, as we assume that attack- 5 Analyzing Frontrunning Attacks
ers send multiple suppression transactions to the same bot
contract. Afterwards, we check the following heuristics for In this section, we analyze the results of our large scale mea-
each cluster: surement study on detecting frontrunning in Ethereum.
7
10 Intel(R) Xeon(TM) L5640 CPUs with 12 cores each and of more than 4.1M USD while spending over 40K USD in
clocked at 2.26 GHz, running 64 bit Ubuntu 16.04.6 LTS. transaction fees. We can also see that the attacker used 16
different accounts and 3 different bots to mount its attacks.
The minimum amount of profit that an attacker made with
5.2 Analyzing Displacement displacement is 0.01 USD. Overall, the average number of
Overall Results. We identified a total of 2,983 displacement attacks per attacker cluster is 175.47 attacks, using 2.88 ac-
attacks from 49 unique attacker accounts and 25 unique bot counts and 1.47 bots. However, we also observe from the
contracts. Using the graph analysis defined in Section 4.1 we distribution that at least half of the attackers only use one
identified 17 unique attacker clusters. account and one bot contract.
8
Bancor Uniswap V1 Uniswap V2 SushiSwap
Bancor Uniswap V1 Uniswap V2 SushiSwap
Release Release Release Release
Insertion Attacks [log]
103
102
101
100
2018-01 2018-05 2018-09 2019-01 2019-05 2019-09 2020-01 2020-05 2020-09
Cost (USD) Profit (USD) Gas Price ∆1 (GWei) Gas Price ∆2 (GWei) Exchange Combination Attacker Clusters
mean 19.41 65.05 407.63 3.88
Uniswap V2 72
std 51.15 233.44 1,897.47 137.12
min 0.01 -10,620.61 0.00 0.00 Uniswap V1 16
25% 4.09 7.86 0.00 0.00 SushiSwap, Uniswap V2 4
50% 7.74 24.07 5.25 0.00 Bancor 3
75% 15.23 62.92 74.10 0.00 Uniswap V1, Uniswap V2 2
max 1,822.22 20,084.01 76,236.09 27,396.63 Bancor, SushiSwap, Uniswap V1, Uniswap V2 1
Table 3: Distributions for insertion attacks. Table 4: Exchange combination count by attacker cluster.
Gas Tokens. We analyzed how many attacks were mounted to the core functionality of Uniswap V1 and Uniswap V2 be-
using gas tokens. Gas tokens allow attackers to reduce their ing the same and that SushiSwap is a direct fork of Uniswap
gas costs. We found that 63,274 (32,17%) of the insertion V2. Thus, for attackers it was probably straightforward to
attacks we measured were performed using gas tokens. 48,281 take their existing code for Uniswap V1 and adapt it to attack
(76.3%) attacks were mounted using gas tokens only for the Uniswap V2 as well as SushiSwap. The peak of insertion
first transaction TA1 , 1,404 (2.22%) attacks were mounted by attacks was on October 5, 2020, with 2,749 daily attacks. We
employing gas tokens only for the second transaction TA2 , measured in total 3,004 attacks on Bancor, 13,051 attacks
and 13,589 (21.48%) attacks were mounted by employing gas on Uniswap V1, 180,185 attacks on Uniswap V2, and 451
tokens for both transactions TA1 and TA2 . We also found that attacks on SushiSwap. Table 4 shows the different combina-
24,042 (38%) of the attacks used GST2, 14,932 (23.6%) used tions of exchanges that attackers try to front-run. We see that
ChiToken, and 24,300 (38.4%) used their own implementation most of the attackers focus on attacking Uniswap V2, with
or copy of GST2 and ChiToken. 72 attacker clusters (73.47%). We also see that 92.86% of the
attackers only focus on attacking one exchange. Moreover,
Exchanges and Tokens. We identified insertion attacks we observed one attacker that attacked all the 4 exchanges,
across 3,200 different tokens on four exchanges: Bancor, 2 attackers that attacked Uniswap V1 and Uniswap V2, and
Uniswap V1, Uniswap V2, and SushiSwap. Figure 5 depicts 4 attackers that attacked Uniswap V2 and SushiSwap. The
the weekly average of daily insertion attacks per exchange. latter is expected since SushiSwap is a direct fork of Uniswap
The first AMM-based DEX to be released on Ethereum was V2. Hence, the attackers can reuse their code from Uniswap
Bancor in November 2017. We observe from Figure 5 that the V2 to attack SushiSwap. What is interesting though, is the
first insertion attacks started in February 2018, targeting the fact that no attacker is attacking only SushiSwap, we see that
Bancor exchange. We also see that the number of insertion attacker always attack SushiSwap in conjunction to another
attacks increased tremendously with the rise of other DEXes, exchange.
such as Uniswap V1 and Uniswap V2. While it took 3 months
for attackers to launch their first insertion attacks on Uniswap Attack Strategies. In 186,960 cases (95.05%) the attackers
V1, it only took 2 weeks to launch attacks on Uniswap V2 and sold the exact same amount of tokens that they purchased.
5 days to launch attacks on SushiSwap. This is probably due Thus, an easy way to spot insertion attacks on decentralized
9
[ $ H &