Source-linked AI summary
SoK: Transparent Dishonesty: front-running attacks on Blockchain
Shayan Eskandari, Seyedehmahsa Moosavi, Jeremy Clark
TL;DR
Front-running reappears in blockchain through transparent transaction processing and privileged control over pending transactions. This paper systematizes attacks across Ethereum DApps, analyzes the Status.im ICO, and categorizes mitigation approaches, finding evidence of abnormal mining behavior.
Problem
Front-running is a recurring issue in transparent, decentralized blockchain systems, but knowledge about attacks and proposed solutions is scattered across DApp contexts.
Method
The paper conducts case studies across Ethereum DApp categories, analyzes the Status.im ICO, and extracts principles underlying front-running mitigations.
Results
F2Pool sent 100 Ether to 30 new addresses before the Status.im ICO, then constructed 31 unbroadcast ICO transactions and mined its own transactions using its mining power.
Takeaways & Limitations
Front-running appears across Ethereum DApp categories, and the paper highlights blockchain-level mitigation as an important research area.
Takeaways & Limitations
Commit/reveal protocols can suffer early aborts, including committed transactions that are never revealed, unless additional mitigations such as fidelity bonds are used.
Abstract
from arXiv · showhide
We consider front-running to be a course of action where an entity benefits from prior access to privileged market information about upcoming transactions and trades. Front-running has been an issue in financial instrument markets since the 1970s. With the advent of the blockchain technology, front-running has resurfaced in new forms we explore here, instigated by blockchains decentralized and transparent nature. In this paper, we draw from a scattered body of knowledge and instances of front-running across the top 25 most active decentral applications (DApps) deployed on Ethereum blockchain. Additionally, we carry out a detailed analysis of Status.im initial coin offering (ICO) and show evidence of abnormal miners behavior indicative of front-running token purchases. Finally, we map the proposed solutions to front-running into useful categories.
1 Introduction
The paper examines front-running across Ethereum DApps, where malicious nodes exploit broadcast-but-unfinalized transactions to confirm their own transactions first. It systematizes scattered knowledge through DApp case studies and categorizes mitigation techniques.
- 1 Introduction: Front-running occurs when a malicious node observes a broadcast transaction before finalization and seeks to confirm its own transaction before or instead of it.Ethereum transactions are relayed, selected into blocks by miners, and finalized as blocks become unlikely to reorganize.
- 1 Introduction: The study covers front-running across Ethereum DApp categories including exchanges, crypto-collectibles, gambling services, name services, and ICOs.The authors emphasize that profitability depends on each DApp’s internal logic and mitigations, requiring individual or category-level study.
- 1 Introduction: The paper categorizes mitigation techniques as transaction sequencing, cryptographic commit/reveal methods, and DApp redesign that removes time dependencies.These approaches aim to eliminate or mitigate front-running while preserving utility.
2 Preliminaries & Related Work
Front-running extends a longstanding financial-market practice into blockchain systems, where public pending transactions and miner or relay control create new attack opportunities. The paper positions its systemization as distinct from prior work.
- 2 Preliminaries & Related Work: Front-running exploits privileged access to information about concrete upcoming transactions, distinguishing it from insider trading and post-trade arbitrage.The distinction depends on whether the actor reacts to an actual pending trade, general predictive information, or a completed/public trade.
- 2 Preliminaries & Related Work: The SEC defined traditional front-running in 1977 as trading on non-public information about an impending block transaction to profit from price adjustment.A stock-market block is defined in the supplied footnote as 10,000 or more shares whose sale heavily changes price.
- 2 Preliminaries & Related Work: Blockchain miners can front-run because they control which transactions execute, their order, and whether their own transactions are broadcast.Users and relaying nodes can also influence ordering through gas prices or transaction propagation.
- 2 Preliminaries & Related Work: The paper states that it is unaware of another systematic study of blockchain front-running while relating the issue to double-spending and rushing adversaries.Double-spending can involve broadcasting a competing transaction with higher fees or miner arrangements to replace an earlier transaction.
3 A Taxonomy of Front-running Attacks
The paper reduces front-running examples to displacement, insertion, and suppression templates based on how the adversary manipulates another user’s function call. Each template also has asymmetric and bulk variants.
- Displacement: Displacement attacks make the victim’s call ineffective or unnecessary, such as registering a domain or submitting a bid first.The victim’s transaction may execute later, be orphaned, or have no meaningful effect.
- Insertion: Insertion attacks place the adversary’s transactions before and after the victim’s call so the victim executes on a state favorable to the adversary.A purchase-order example lets the adversary buy at the best offer and resell at the victim’s slightly higher price.
- Suppression: Suppression attacks delay the victim’s function, after which the adversary is indifferent to whether it executes.The paper observes this pattern in only one DApp and defers its detailed discussion.
- Variants: Each attack template has asymmetric and bulk variants, covering different operations by the adversary or many adversarial function calls.Examples include fulfilling an offer before its cancellation and displacing many buyers competing for limited shares.
4 Cases of Front-running in DApps
The paper examines front-running across four DApp categories, showing how application logic and transaction visibility create distinct attack opportunities. It also identifies concrete mechanisms in exchanges, gambling, collectibles, and name services.
- Scope and categories: The study selects the top 25 DApps by recent user activity, groups them into four principal use cases, and notes that activity is an imperfect significance measure.The authors separately study lower-volume or time-limited applications such as ICOs.
- 4.1 Markets and Exchanges: In exchanges, attackers can exploit pending cancellation transactions by submitting higher-gas fill orders that execute before cancellation, an asymmetric displacement attack.A miner can also insert a buy order before the cancellation transaction in a block it mines and collect the cancellation gas.
- 4.1 Markets and Exchanges: Truly decentralized on-chain order books remain vulnerable because miners or full nodes can observe pending orders and displace or insert transactions.Bancor provides continuous token liquidity through Smart Tokens and a market scoring rule, making its exchange logic distinct from order-book designs.
- 4.2 Crypto-collectibles: CryptoKitties uses ERC-721 tokens and auction contracts, while its breeding callback rewards whoever calls giveBirth() after the designated birthing block.Front-running these calls does not alter protocol workflow but can still produce financial profit.
- 4.3 Gambling: Fomo3D’s first round ended with a winner collecting 10,469 Ether, after network congestion and high-gas transactions displaced new ticket purchases near timer expiration.The strategy used unrelated high-gas-consumption DApps and transactions to congest the network and induce miners to prioritize them.
- 4.3 Gambling / 4.4 Name Services: The paper classifies the Fomo3D strategy as suppression because transaction displacement was only a means to prevent new purchases from resetting the timer.ENS instead uses sealed-bid auctions with a reveal phase, though leaked domain hashes and bid amounts enable domain squatting; the authors do not classify this action as front-running.
5 Cases of Front-running in ICOs
The Status.im ICO reached its cap amid severe transaction congestion, while analysis identified F2Pool behavior consistent with miners prioritizing their own token purchases and interfering with competing transactions.
- More than 3,000 Ethereum ICOs had been held, while Status.im’s June 2017 ICO reached its cap within 16 hours and collected close to 300,000 Ether.
- Transactions frequently failed during the ICO, including higher-gas-price attempts rejected by the contract’s 50 GWei ceiling.The ceiling was intended as a front-running mitigation.
- F2Pool controlled around 23% of mining hash rate and sent 100 Ether to 30 new addresses before constructing 31 unbroadcast ICO transactions.The pool used its mining power to mine its own transactions and potentially failing high-gas-price transactions.
- Most leading miners mined roughly similar numbers of failed and successful transactions, but F2Pool’s successful transactions equaled only 10% of its failed transactions.The analysis interprets this pattern as maximizing gas rewards while censoring other token-sale transactions.
- Tracing the 30 addresses found that F2Pool’s deposited funds were sent to the ICO, mined by F2Pool, partially refunded by Dynamic Ceiling, and later returned to the pool.The study used a purpose-built database assembled from a full node, ethereum-etl, BigQuery, and Tableau.
- The incident did not reorder transactions within blocks, but showed that miners could modify mining software to bulk-displace other transactions for monetary profit.
6 Key Mitigations
The paper groups front-running mitigations into transaction sequencing, confidentiality techniques, and DApp redesign, while examining their mechanisms and limitations. Commit/reveal hides transaction details until ordering is established, but multi-round protocols and application-specific leakage create constraints.
- Mitigation taxonomy: Mitigations fall into three categories: enforced transaction ordering, cryptographic limits on transaction visibility, and DApp designs that remove dependence on ordering or time.Systems may combine multiple primitives in layered mitigation approaches.
- Transaction sequencing: Ethereum miners can arbitrarily sequence pending transactions, with geth prioritizing gas price and nonce, enabling advantageous ordering.Pending transactions reside in pools without intrinsic ordering, and miners choose transactions when forming blocks.
- Transaction sequencing: FIFO ordering is generally infeasible in distributed networks because transactions arrive at nodes in different orders and consensus-based FIFO could increase orphaned blocks.Centralized sequencing can support time-sensitive functionality but conflicts with distributed trust.
- Transaction sequencing: Transaction chaining prevents insertion attacks but not displacement attacks, and permits at most one state-changing transaction per state.This restriction can disadvantage active DApps with concurrent transactions.
- Confidentiality: Privacy protections must be evaluated per DApp because public state changes, known contract addresses, or traffic patterns can still reveal exploitable information.For decentralized domain registration, hiding state changes defeats the DApp’s purpose, while hiding function calls is ineffective against public state changes.
- Confidentiality: Commit/reveal hides function calls until they are enqueued, then reveals the committed data for verification using a cryptographic hash and nonce.Namecoin applies this pattern by confirming a hidden domain commitment, waiting through a delay, and then revealing the domain details.
- Confidentiality: Early aborts create a commit/reveal vulnerability because adversaries can submit multiple commitments and reveal only advantageous ones.Fidelity bonds can automatically penalize users who fail to complete committed transactions, though multi-round protocols also create usability challenges.
- DApp redesign: ERC20 allowance updates can be front-run so an attacker spends the old allowance before the new value is set and may later spend the new amount.The example illustrates how application functionality can expose insertion-attack opportunities.
7 Concluding Remarks
The paper presents front-running as pervasive across Ethereum DApps and argues that awareness, application-level defenses, and blockchain-level mitigations all deserve attention. Its broad prevalence motivates blockchain-level research as a potentially more effective direction.
- Scope and significance: Front-running is pervasive across Ethereum DApps, while developers do not necessarily design applications with these attacks in mind.The paper frames the discussion as an effort to increase awareness.
- Scope and significance: Some DApp-level application logic can mitigate front-running attacks, but the issue appears across different DApp categories.The conclusion connects this ubiquity with the need to consider broader mitigations.
- Future research: The paper identifies blockchain-level mitigations as an important research area because they may be more effective than isolated application-level defenses.This is presented as a research direction rather than a demonstrated result.