Front-running Attack in Sharded Blockchains and Fair Cross-shard Consensus

Front-running Attack in Sharded Blockchains and Fair Cross-shard Consensus

Speakers: Jianting Zhang

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=7CrIt6NqohE

Overview

This talk by Jianting Zhang from the NDSS Symposium unveils a critical, previously unaddressed security vulnerability in sharded blockchains: a novel form of front-running attack that exploits a property termed finalization unfairness. Sharding, a widely adopted technique to boost blockchain scalability by processing transactions in parallel across smaller network partitions (shards), paradoxically introduces a new attack surface. The core issue lies in the inherent processing-execution difference between intra-shard and cross-shard transactions, creating a window for adversaries to manipulate transaction ordering.

The research highlights how an attacker can force their transaction to execute and commit before a victim's cross-shard transaction, even if the victim's transaction was processed earlier by fair intra-shard consensus. This violation of finalization fairness—the principle that transactions should be finalized in their processed order—has severe implications, particularly for order-sensitive contracts (OSCs) prevalent in Decentralized Finance (DeFi), Initial Coin Offerings (ICOs), and gambling platforms. Such manipulations have already led to millions of USD in losses in existing systems. Beyond financial exploitation, this attack can disrupt the very scalability benefits of sharding by creating unbalanced workloads. To counter this, the talk introduces Haechi, a novel cross-shard protocol built on a Process-Order-Execute-Commit (POEC) model, designed to ensure finalization fairness and robust consistency across sharded systems.

Background

▶ Watch: Introduction to sharding, front-running attack, and finalization fairness (0:00)

Sharded blockchains fundamentally divide the network into shards, each responsible for a subset of the network's state and transactions. To manage transactions within a single shard, an intra-shard consensus protocol (often a standard Byzantine Fault Tolerant, or BFT, State Machine Replication protocol) is employed. However, for transactions spanning multiple shards—known as cross-shard transactions—a more complex cross-shard consensus protocol is required. The primary goals of these cross-shard protocols are to ensure data isolation and atomicity, meaning all involved shards either commit or abort the transaction together, maintaining consistency.

Most existing sharded systems, inspired by traditional distributed databases' two-phase commit (2PC) protocol, adopt a two-phase (2P) approach for cross-shard transactions. In the vote phase, relevant shards modify and lock local states using intra-shard consensus. In the commit phase, another instance of intra-shard consensus finalizes the transaction. This multi-phase, multi-shard approach introduces a critical distinction: a cross-shard transaction is processed by one shard (e.g., deducting a sender's balance) and then executed by another (e.g., modifying a contract's state), with an inherent time delay between these steps. In contrast, an intra-shard transaction is processed and executed entirely within one shard by a single consensus instance.

This processing-execution difference is benign for order-agnostic contracts (like simple token transfers) but becomes a severe vulnerability for order-sensitive contracts (OSCs) where the sequence of operations is paramount. The talk formally defines finalization fairness as the property that transactions are executed and committed in the exact order they were processed. The presented front-running attack specifically targets sharded systems by leveraging this processing-execution separation. An attacker can strategically insert an intra-shard transaction (ITX) into the contract shard between the processing and execution phases of a victim's cross-shard transaction (CTX), causing the ITX to be executed first. This attack is insidious because it doesn't require transaction fee bidding wars, making it inexpensive and highly probable to succeed in sharded environments. The consequences are dire: compromised security for OSCs, potential financial losses, and unbalanced shard workloads that undermine the very scalability sharding aims to achieve. Prior to this work, no existing sharded system had adequately addressed this specific vulnerability.

Key Findings

▶ Watch: Explaining the critical processing-execution difference and vulnerability (2:40)

The research makes several foundational contributions to sharded blockchain security and design:

1. First Formalized Front-running Attack in Sharded Systems: The talk introduces and formally details the first front-running attack specifically targeting existing two-phase (2P) cross-shard consensus protocols. This attack exploits the temporal gap between the processing and execution of cross-shard transactions, demonstrating how an attacker can manipulate transaction order to their advantage, leading to significant financial losses and imbalanced shard loads.
2. Novel Definition of Finalization Fairness: A new security property, finalization fairness, is introduced and formally defined for sharded systems. This property mandates that any two transactions interacting with the same order-sensitive contract (OSC) must be executed in the exact order they were initially processed. This serves as a fundamental requirement for preventing front-running in fragmented blockchain environments.
3. Haechi: A Novel Cross-shard Protocol: The paper presents Haechi, a new cross-shard protocol built on a Process-Order-Execute-Commit (POEC) consensus model. Haechi's innovative design incorporates a globally fair ordering phase that effectively resolves the processing-execution discrepancy, thereby guaranteeing finalization fairness and immunity to the described front-running attack. This model also enhances efficiency for OSCs through asynchronous and non-blocking processing.
4. Comprehensive Experimental Validation: A full prototype of Haechi was implemented using Tendermint 39 and rigorously evaluated in a geo-distributed AWS environment. The experiments compared Haechi's performance and security against state-of-the-art 2P cross-shard protocols.
5. Demonstrated Effectiveness and Efficiency: The evaluation conclusively shows that Haechi successfully prevents all front-running attacks, achieving a 0% success rate for attackers. Crucially, it accomplishes this with minimal performance sacrifice, demonstrating high scalability with over 13,000 Transactions Per Second (TPS) with 32 shards, and acceptable latencies (less than 6s intra-shard and 17s cross-shard confirmation latency).

Technical Deep Dive

▶ Watch: Introducing Haechi: Process-Order-Execute-Commit (POEC) consensus model (4:00)

To counter the identified front-running vulnerability and ensure finalization fairness, the talk introduces Haechi, a novel cross-shard protocol founded on a Process-Order-Execute-Commit (POEC) consensus model. The core innovation of Haechi is to insert a globally fair ordering phase between the initial processing and final execution stages of a transaction. This phase ensures that the execution order of order-sensitive contract (OSC) transactions strictly aligns with their processing order across all shards, thereby guaranteeing finalization fairness and robust consistency.

Beyond fairness, this globally fair order offers benefits such as strong consistency across shards and enhanced parallelism for handling conflicting transactions, allowing non-blocking processing even when multiple transactions from different shards target the same contract. However, establishing such a global order in a sharded system is challenging due to varying consensus speeds among shards, which can lead to "in-flight transactions"—transactions processed by a slow shard but whose data hasn't reached the global coordinator when a fast shard's transactions are being ordered. A naive solution, like synchronizing all shards block-by-block (Haechi-sync), would severely bottleneck performance to that of the slowest shard, negating sharding's scalability advantages.

Haechi overcomes these challenges using two key mechanisms:

1. Block Timestamp as Ordering Indicator: Haechi leverages the block timestamp from each shard's block header. These timestamps are publicly verifiable, immutable once committed, and incrementally updated within each shard. This provides a deterministic and unforgeable basis for establishing a global order, preventing adversaries from manipulating it.
2. At-Least-One Ordering Rule: Instead of waiting for all in-flight transactions to arrive, Haechi's ordering phase can commence as soon as it receives at least one CrossLink from each shard. This rule allows the protocol to gather sufficient information to establish a fair order while significantly minimizing the performance degradation caused by waiting for slower shards to catch up.

System Design and Architecture: Haechi Details

Haechi is designed for state-sharded systems with smart contract capabilities. The ledger is partitioned among m+1 shards, where m shards (S1 to Sm) maintain their own shard chains, and a dedicated beacon shard (S0) maintains a beacon chain. Shards utilize a BFT-based protocol for intra-shard consensus. The beacon chain acts as a global coordinator for the critical ordering phase, communicating with shard chains via CrossLink (CL) messages. A CrossLink is a data structure comprising the blockTS (block timestamp), Ltx (a list of order-sensitive transactions), i (shard chain ID), and h (block height).

Haechi's POEC model comprises four distinct phases:

1. Processing Phase (Sender Shards):

• Transaction Handling: Order-sensitive transactions (OTXs) are initially processed and packed into blocks. Haechi introduces a novel block structure featuring two transaction lists: a pending list for processed but uncommitted OTXs, and a committing list for committable transactions (including non-OSC transactions and successfully executed OTXs).
• Benefits: This two-list structure enables asynchronous processing (sender shards don't need to execute contracts themselves) and non-blocking processing (shards can continuously process new OTXs without waiting for previous commitments). It also establishes a local order for conflicting transactions in the pending list, contributing to the global order.
• Algorithm 1 outlines this phase: a shard node verifies new OTXs, adds valid ones to Ltx, and commits ready transactions. The shard leader then generates a CrossLink (CLh) with blockTS, Ltx, shard ID, and block height, broadcasts it for signatures, and sends it to the beacon chain once a quorum certificate is obtained.

1. Ordering Phase (Beacon Chain):

• The beacon chain's primary function is to establish a globally fair order for OTXs.
• Algorithm 2 details the finalization fairness algorithm:
• CrossLinks Preparing: The beacon chain receives Si.CL from shards. It checks for consecutive block heights; consecutive CrossLinks are added to shardCLs (an m-sized 2D vector storing CLs for each shard), and shardLastTSi is updated. Non-consecutive CrossLinks are temporarily held in a CLPool to ensure no in-flight CLs are skipped.
• CrossLinks Filtering: Once at least one consecutive CrossLink from each shard is available in shardCLs, the beacon chain filters them. It selects all CrossLinks whose blockTS is less than or equal to min(shardLastTSi) across all shards. This crucial step guarantees that all transactions chosen for ordering have timestamps smaller than any potential in-flight transactions, ensuring fairness.
• Transactions Ordering: The chosen CrossLinks are then ordered based on two rules: (i) CrossLinks with smaller blockTS are ordered first, and (ii) within the same CrossLink, transactions with smaller indexes are ordered first. These ordered transactions are appended to relevant Cross-shard Call Lists (CCLsi), which form the content of a new beacon block. This design significantly reduces average waiting times and allows shards to process irrelevant transactions independently.

1. Execution Phase (Contract Shards):

• Contract shards receive the deterministic transaction orders via CCLs from the beacon chain and execute the related OSCs.
• One-shard execution: For simple contracts, the shard executes the OSC independently via intra-shard consensus, labeling the OTX as final-and-commit (success) or final-but-abort (failure).
• Multi-shard execution: For complex contracts involving multiple shards, a collaborative execution is performed, labeling the OTX as progress-and-commit or progress-but-abort.
• Execution results (commit/abort status, return values, contract dependencies) are packed into an execution message and forwarded to the sender shard.

1. Commitment Phase (Sender Shards):

• The sender shard coordinates the atomic commitment of the OTX.
• Based on the tags in received execution messages:
• final-and-commit: The sender commits the transaction, modifies its account, and notifies the contract shard to unlock and commit its state.
• progress-and-commit: For multi-shard transactions, the sender waits for all related messages before committing.
• final-but-abort or progress-but-abort: The sender aborts the transaction and notifies all related shards to discard modifications.
• Finally, all OTXs are recorded in the committing list of shard blocks.

Security Analysis

The talk formally proves Haechi's adherence to crucial security properties: finalization fairness, safety, and liveness.

• Finalization Fairness (Theorem 3): This theorem asserts that if two transactions call the same contract, their execution order will match their processing order. This is achieved by enforcing the processing order strictly during the ordering phase, which is then maintained through execution and commitment.
• Lemma 1: Proves that the block timestamp of any in-flight CrossLink is always larger than the block timestamps of CrossLinks currently being ordered. This is ensured by requiring consecutive block heights for CrossLinks and the filtering step in Algorithm 2 (selecting CLs with timestamps less than or equal to min(shardLastTSi)).
• Lemma 2: Demonstrates that Haechi's ordering rules (smaller blockTS first, then smaller index) are strictly followed, with Byzantine behavior (e.g., malicious leader attempting to violate rules or drop CLs) being detectable by honest nodes.
• Theorem 3 Proof: By combining Lemmas 1 and 2, it is guaranteed that all in-flight and received CrossLinks are ordered based on their processing order, ensuring finalization fairness.

• Sharded System Safety (Theorem 6): Defines safety as (i) any two honest nodes of the same shard maintaining the same prefix ledger, and (ii) any two honest nodes from different shards having the same commitment sequence and operation for all cross-shard transactions involving them.
• Lemma 4 (Intra-shard Safety): Guaranteed because each shard runs a BFT consensus with honest nodes.
• Lemma 5 (Cross-shard Atomicity): For OTXs modifying data across multiple shards, all relevant shards either commit or abort atomically. The honest sender shard coordinates this, reaching a consistent decision via BFT.
• Theorem 6 Proof: Lemmas 4 and 5, combined with finalization fairness (Theorem 3), collectively ensure both intra-shard and cross-shard consistency.

• Sharded System Liveness (Theorem 7): Ensures that any transaction received by an honest node will eventually be handled by relevant shards and receive a response.
• Proof: Non-OTX transactions rely on underlying intra-shard or 2P cross-shard protocols (which guarantee liveness). For OTXs, messages between honest parties are not dropped, the beacon chain eventually receives CrossLinks, Haechi's fairness guarantees no CLs are dropped, and honest shards are responsive, ensuring eventual handling and response.

Demo / Proof of Concept

▶ Watch: Challenges of establishing globally fair order in sharded systems (4:40)

The efficacy and performance of Haechi were validated through a full prototype implementation. The system was built upon Tendermint 39, a modular BFT consensus engine, allowing for seamless integration of Haechi's fair ordering algorithm and cross-shard communication mechanisms while leveraging Tendermint's underlying security. Transaction data for each shard was stored in LevelDB. Cross-shard communication was managed by designating a leader node within each shard as a cross-shard portal to avoid redundant message delivery. New blocks on shard chains were proposed randomly by shard proposers.

The beacon chain's block generation incorporated Algorithm 2 to achieve fair ordering for OSC transactions across all shards. The implementation also included multiple client types for securely sending transactions, which were verified by Tendermint before processing. The total implementation comprised approximately 4.7K lines of code written in Golang.

For comparison, three other cross-shard protocols were also implemented using Tendermint:

1. Haechi-sync: A "strawman" solution where shards are blocked, unable to process new transactions until the beacon chain completes the ordering phase for the previous round, enforcing full synchronization to the same block height.
2. AHL 17: A state-of-the-art 2P cross-shard protocol that delegates the coordination of all cross-shard transactions to a dedicated reference shard.
3. Byshard 18: Another state-of-the-art 2P cross-shard protocol where the sender shard acts as the cross-shard coordinator. Both AHL and Byshard support smart contract-type transactions and are inherently vulnerable to front-running attacks.

The evaluation was conducted in a geo-distributed AWS environment, utilizing 10 AWS regions globally (4 in America, 3 in Asia, 3 in Europe) with ten c5a.8xlarge EC2 instances (32 CPUs, 64 GB RAM, 10 Gbps network). The setup included 30 nodes per shard, totaling 33 shards (including one beacon shard). Transaction sender and receiver addresses were randomly generated to ensure balanced workloads. Each test ran for over 3 minutes, with the mempool capable of storing up to 50,000 transactions (max 1 GB).

Evaluation of Front-running Attack

The front-running attack, as described in Figure 4 of the original paper, was implemented and tested.

• Impact of Workload: For 2P protocols (AHL, Byshard), the attack success rate decreased with higher workloads on the contract shard. This is because under heavy load, front-running transactions might not be processed immediately, potentially being processed within the same intra-shard consensus instance as the victim's transaction, thus reducing the attacker's window.
• Impact of Byzantine Ratio: For 2P protocols, a higher ratio of Byzantine nodes (attackers) within a shard led to a higher attack success rate, as expected.
• Haechi and Haechi-sync: Crucially, both Haechi and the synchronized strawman Haechi-sync protocols effectively prevented all front-running attacks, demonstrating a 0% success rate in the realistic test environment. This validated Haechi's core security contribution.

Scalability Evaluation

• Throughput (TPS): Haechi exhibited near-linear scalability, achieving over 13,000+ TPS with 32 shards. Byshard showed the best raw performance, while AHL's performance degraded significantly with increasing shard numbers due to its bottlenecked reference shard. Haechi-sync, due to its global synchronization, did not scale well.
• Latency: Haechi demonstrated a slow increase in latency with more shards, achieving 6s intra-shard latency and 17s cross-shard latency with 32 shards. Byshard again performed best, while AHL's latency degraded significantly. Haechi-sync's latency was deemed unacceptable. Haechi's low overhead was attributed to its efficient finalization fairness algorithm and ordering operations.

Micro-benchmark & Further Performance

• CCLs Interval: Haechi achieved an average CCLs interval of 1.68s with 32 shards, considered acceptable under real-world network latencies. Haechi-sync, by contrast, introduced significantly higher overhead.
• Gas Consumption: Estimating gas consumption by converting the ordering phase into timestamp comparisons, one comparison operation cost 780 gas. Assuming an average of 100 transactions per CrossLink and up to 10,000 CrossLinks ordered in one cycle, and a historical maximum gas price of 150 Gwei, the maximum gas consumption for a Haechi transaction was estimated at **1.17 10-2 ETH. The average fee was a very cheap 1.55 10-5 ETH**, deemed negligible compared to potential asset loss from front-running.
• Workload and Client Ratios: Haechi maintained competitive performance, with less than 5s intra-shard and less than 10s cross-shard latency for TPS below 15,000, meeting most DApp requirements. The performance of all protocols decreased as the ratio of cross-shard transactions increased, highlighting the inherent overhead of cross-shard communication but underscoring Haechi's efficiency in asynchronous and non-blocking processing.

In summary, the extensive evaluations confirmed that Haechi successfully prevents front-running attacks with only a slight performance sacrifice compared to existing 2P cross-shard consensus protocols, while providing the crucial finalization fairness property.

Defensive Implications

▶ Watch: Haechi's two key mechanisms for fair cross-shard ordering (5:20)

The findings presented in this talk have profound implications for developers, operators, and users of sharded blockchain systems. The primary defensive implication is a stark warning: current two-phase (2P) cross-shard consensus protocols are inherently vulnerable to a novel, inexpensive, and potent front-running attack. This vulnerability is not a theoretical edge case but a critical design flaw stemming from the processing-execution difference of cross-shard transactions, which can be exploited for significant financial gain, particularly in order-sensitive contracts (OSCs) like those in DeFi.

For existing sharded blockchain projects relying on 2P cross-shard mechanisms, immediate attention is warranted. They should acknowledge this vulnerability and understand that their systems may be susceptible to transaction ordering manipulations. Defenders must recognize that traditional intra-shard fairness mechanisms are insufficient to protect against this cross-shard attack vector.

The proposed solution, Haechi, offers a clear defensive strategy: adopting protocols that incorporate a globally fair ordering phase. By ensuring that the execution order of transactions aligns strictly with their processing order, protocols like Haechi eliminate the attack window. This means that future sharded blockchain designs, especially those aiming to host robust DeFi ecosystems, must prioritize finalization fairness as a fundamental security property.

DApp developers building on sharded platforms should be acutely aware of the underlying cross-shard consensus mechanism. If the platform uses a vulnerable 2P protocol, developers of OSCs should assume their contracts are susceptible to front-running and consider architectural changes or external monitoring to mitigate risks, though a protocol-level solution like Haechi is ultimately more robust. The minimal performance overhead demonstrated by Haechi suggests that implementing such a secure protocol is a viable and necessary trade-off for critical applications.

Finally, the discussion on block timestamp security and intra-shard order fairness highlights that while Haechi addresses cross-shard fairness, a holistic security posture requires considering all potential ordering manipulation vectors. Future research and implementation efforts should explore integrating complementary intra-shard fairness protocols and potentially more robust timestamp mechanisms (e.g., using encryption to hide transaction information until consensus, despite added latency) to achieve end-to-end fairness.

Key Takeaways

• Sharded blockchains, while enhancing scalability, introduce a novel front-running attack vector that exploits the processing-execution difference in two-phase (2P) cross-shard consensus protocols.
• This attack leads to finalization unfairness, where transactions are not executed in the order they were processed, posing significant security risks and potential financial losses for order-sensitive contracts (OSCs) in DeFi and other applications.
• Finalization fairness is a newly defined, critical security property for sharded systems, demanding that transactions interacting with the same OSC are executed in the same order they were processed.
• Haechi, a novel cross-shard protocol based on the Process-Order-Execute-Commit (POEC) model, effectively prevents this front-running attack by introducing a globally fair ordering phase.
• Haechi achieves fairness and strong consistency without sacrificing scalability, demonstrating over 13,000+ TPS and acceptable latencies (6s intra-shard, 17s cross-shard) with 32 shards in geo-distributed AWS tests.
• Haechi's design leverages verifiable block timestamps as ordering indicators and an at-least-one ordering rule to efficiently establish global order while minimizing performance degradation from slow shards.
• Existing 2P cross-shard protocols (like AHL and Byshard) are vulnerable to these attacks, underscoring the urgent need for robust, fairness-preserving cross-shard consensus mechanisms like Haechi.

About the Speaker(s)

The talk was presented by Jianting Zhang. No further biographical details were provided in the transcript or metadata.