Asynchronous Blockchains: Designing Networks That Never Wait

Posted on by uplatzblog

Executive Summary

The history of distributed ledger technology is fundamentally a history of grappling with the constraints of time. In the quest to create decentralized networks that are secure, scalable, and decentralized, protocol designers have traditionally relied on the crutch of synchrony—the assumption that messages sent between nodes will arrive within a predictable timeframe. This reliance on “waiting” for timeouts, for block propagation, or for leader stability has been the primary bottleneck preventing blockchains from achieving the throughput and latency required for global-scale financial infrastructure. This report provides an exhaustive analysis of the paradigm shift toward Asynchronous Byzantine Fault Tolerance (ABFT), a class of protocols designed to operate correctly without global clocks or bounded message delays.

By decoupling data dissemination from consensus ordering and leveraging novel data structures like Directed Acyclic Graphs (DAGs), asynchronous blockchains such as Sui, Aleph Zero, Fantom, and Hedera have demonstrated the ability to process hundreds of thousands of transactions per second with sub-second finality. We explore the theoretical underpinnings of this shift, tracing the evolution from the FLP Impossibility Theorem to the breakthrough of HoneyBadgerBFT, and finally to the modern modular architectures of Narwhal, Tusk, and Mysticeti. The analysis reveals that true scalability lies in networks that “never wait,” replacing latency constraints with bandwidth constraints and utilizing advanced cryptographic primitives like threshold signatures and random beacons to achieve coordination in chaos.

1. Introduction: The Synchronization Bottleneck

In the domain of distributed systems, time is the enemy. The fundamental challenge of achieving consensus among a distributed set of potentially malicious (Byzantine) nodes is coordination. How do distinct computers, separated by oceans and unreliable networks, agree on the order of events? The classical solution, employed by Bitcoin and early Proof-of-Stake systems, is to impose a temporal structure on the network. These systems operate in lockstep, governed by a “synchronous” or “partially synchronous” model where progress depends on the assumption that messages will be delivered within a specific bound, denoted as $\Delta$.1

1.1 The Cost of Waiting

In a synchronous protocol, if a node does not receive a message within $\Delta$, it assumes the sender is faulty. This creates a dangerous dependency. To ensure safety, $\Delta$ must be set conservatively (e.g., 10 seconds), which artificially limits the speed of the network to the worst-case latency of the slowest link. If the network is faster than $\Delta$, the protocol sits idle, wasting potential throughput. Conversely, if the network experiences a partition or a Distributed Denial of Service (DDoS) attack and delays exceed $\Delta$, the protocol’s security guarantees can collapse, leading to forks or double-spending.2

This “waiting” paradigm introduces a fundamental vulnerability. Leader-based protocols like PBFT (Practical Byzantine Fault Tolerance) or HotStuff (used in Aptos) rely on a specific leader node to drive consensus. If an adversary attacks the leader, the network effectively halts until a timeout triggers a complex “view-change” to elect a new leader. This fragility makes synchronous networks inherently susceptible to performance degradation in adversarial environments.3

1.2 The Asynchronous Alternative

Asynchronous blockchains reject these timing assumptions entirely. In an asynchronous model, the adversary can delay messages indefinitely (though they must eventually be delivered). There is no global clock, and nodes cannot rely on timeouts to determine failure. A protocol designed for this environment must be “ready for anything,” capable of making progress regardless of network conditions. These networks “never wait” for a specific time bound; they proceed at the speed of the actual network, processing transactions as fast as bandwidth allows.1

Designing for asynchrony is notoriously difficult due to the FLP Impossibility Theorem, which states that deterministic consensus is impossible in a purely asynchronous system with even a single crash fault.5 However, modern cryptographic breakthroughs have allowed researchers to circumvent this barrier using randomization and DAG-based structures, leading to a new generation of high-performance protocols.

2. Theoretical Foundations and the FLP Impossibility

To fully appreciate the architecture of modern asynchronous blockchains, one must first navigate the theoretical constraints that governed their development.

2.1 The FLP Impossibility Theorem (1985)

The most significant hurdle in distributed computing theory is the result published by Fischer, Lynch, and Paterson (FLP). They proved that in an asynchronous system where nodes can fail (even without malicious intent), there exists no deterministic protocol that can guarantee consensus in finite time.1

The core of the proof lies in the inability to distinguish between a crashed node and a slow node. In an asynchronous network, if a node is silent, the other nodes cannot know if it has failed or if its messages are merely delayed. A deterministic protocol, forced to wait for input to make a decision, could potentially be stalled indefinitely by an adversary who manipulates message scheduling to keep the system in an indecisive state.

This theorem implies that any practical asynchronous protocol must relax one of the core requirements of consensus:

  1. Safety: All honest nodes agree on the same value.
  2. Liveness: The system eventually reaches a decision.
  3. Determinism: The protocol always produces the same output for a given input.

Asynchronous blockchains typically sacrifice determinism in favor of randomization. By introducing a source of randomness (like a coin flip), the system can break symmetry and force a decision with probability 1, thus circumventing the FLP result while maintaining both safety and liveness.1

2.2 Synchrony vs. Asynchrony: A Taxonomy of Time

The distinction between timing models is the defining characteristic of blockchain architecture.

  • Synchronous Model: Assumes a known, finite upper bound ($\Delta$) on message transmission. If a message is sent at time $t$, it must arrive by $t+\Delta$. This is the easiest model to design for but the most brittle in practice. If the assumption is violated (e.g., due to a network outage), safety is compromised.2
  • Partially Synchronous Model: A “sweet spot” used by most modern chains (Cosmos, Aptos, Solana). It assumes the network may be asynchronous for an unknown period, but eventually, there will be a Global Stabilization Time (GST) after which the network behaves synchronously with a bound $\Delta$. These protocols guarantee safety always (even during asynchrony) but only guarantee liveness (progress) after GST. The downside is that during the asynchronous period, the chain stops finalizing blocks.3
  • Asynchronous Model: Makes no assumptions about time. Messages can be delayed arbitrarily. Protocols in this model guarantee both safety and liveness regardless of network timing. This makes them incredibly robust against DDoS attacks and network partitions, as they do not rely on leaders or timeouts.1

2.3 The CAP Theorem Context

While often conflated, the FLP result is distinct from the CAP Theorem (Consistency, Availability, Partition Tolerance). In the context of blockchains, “Consistency” maps to Safety, and “Availability” maps to Liveness. The CAP theorem states that during a network partition, a system must choose between being safe (consistent) or live (available). Asynchronous BFT protocols generally prioritize Consistency (Safety) — they will never confirm conflicting transactions — but they achieve Availability (Liveness) through randomization techniques that allow them to recover from partitions without manual intervention.3

3. The Pioneer: HoneyBadgerBFT and the Era of Randomization

The transition from theoretical possibility to practical implementation began with HoneyBadgerBFT (HBBFT), the first asynchronous BFT protocol designed to be practical for cryptocurrency applications.

3.1 Breaking the Leader Paradigm

Traditional BFT protocols like PBFT rely on a leader to propose a block and drive consensus. This leader is a bottleneck; if the leader is slow, the whole network is slow. If the leader is malicious, they can censor transactions. HoneyBadgerBFT introduced a leaderless architecture where nodes push transactions concurrently.8

3.2 The Asynchronous Common Subset (ACS)

The core primitive of HBBFT is the Asynchronous Common Subset (ACS). The goal is for all nodes to agree on a set of transactions to include in the next block, without caring about the order initially.

  1. Reliable Broadcast (RBC): Each node proposes a batch of transactions. It uses an erasure-coding scheme (like AVID) to break the batch into fragments and scatter them across the network. This ensures that the data is available without requiring every node to download the full batch from the sender, optimizing bandwidth.10
  2. Binary Agreement (BA): For each proposed batch, nodes run a binary agreement protocol to decide “Yes” or “No” on whether to include it in the final set.
  3. The Common Coin: To resolve split votes in the Binary Agreement phase (where half say Yes, half say No), HBBFT uses a Common Coin. This is a cryptographic primitive where nodes collectively generate a random bit. If the vote is deadlocked, the Common Coin flips, and everyone adopts the random value. This breaks the FLP stall.10

3.3 Threshold Encryption for Censorship Resistance

A critical innovation in HBBFT is the use of Threshold Encryption. In a standard blockchain, a leader can see the contents of a transaction before ordering it, allowing them to extract Maximal Extractable Value (MEV) or censor specific users. In HBBFT, transactions are encrypted by the user. The nodes agree on the encrypted batches first. Only after the order is finalized do the nodes decrypt the batch using their threshold keys. This makes it impossible to censor transactions based on their content, as the content is unknown until it is too late to change the order.8

While HBBFT proved that asynchronous BFT was possible, it was computationally expensive and had high latency due to the multiple rounds of Binary Agreement required for every batch. This led researchers to look for more efficient structures, eventually converging on the Directed Acyclic Graph (DAG).12

4. The DAG Revolution: From Chains to Graphs

To overcome the throughput limitations of linear blockchains and the latency of early asynchronous protocols, the industry shifted toward Directed Acyclic Graphs (DAGs). In a linear blockchain, blocks form a single line, meaning blocks must be produced sequentially. In a DAG, blocks (or events) can be produced in parallel and reference multiple previous blocks, forming a braided web of history.13

This structure is naturally suited for asynchrony. Since nodes don’t need to agree on a single “tip” of the chain before creating the next block, they can work concurrently. The challenge then becomes post-hoc ordering: how to take this tangled graph and flatten it into a linear sequence of transactions that every node agrees on.

4.1 Comparison: Blockchain vs. DAG

Feature Linear Blockchain DAG (BlockDAG)
Structure Single chain of blocks. Graph of interconnected blocks/events.
Block Production Sequential (one leader at a time). Parallel (multiple leaders/nodes at once).
Consensus Agreement required before block is added. Agreement often derived after via graph structure.
Throughput Limited by block size and interval. Limited primarily by network bandwidth.
Orphans Stale blocks are discarded (wasteful). “Orphans” are referenced and included (efficient).

5. Case Study: Hedera Hashgraph

Hedera Hashgraph serves as a prime example of a “pure” DAG-based consensus that leverages the graph structure itself to achieve ABFT without the heavy message overhead of HBBFT.

5.1 Gossip about Gossip

The foundation of Hashgraph is a communication protocol called Gossip about Gossip. In a standard gossip protocol, Node A tells Node B “Here is a transaction.” In Hashgraph, Node A tells Node B “Here is a transaction, and here is the time I received it, and here are the two events (one from me, one from someone else) that preceded it.”

When this information propagates, it builds a cryptographically secure data structure (the Hashgraph) on every node. This graph depicts not just the transactions, but the history of communication itself. Each node knows exactly who talked to whom and when.15

5.2 Virtual Voting: The Zero-Bandwidth Consensus

The brilliance of Hashgraph lies in Virtual Voting. Because every node possesses a copy of the Hashgraph, Node A can inspect the graph and calculate what Node B knows. Node A can determine, “If I were to send a vote to Node B right now, what would they see?”

Since Node A can mathematically deduce Node B’s perspective, there is no need to actually send a vote over the network. Every node runs the voting algorithm locally on their own machine, feeding it the data from the Hashgraph. They reach the exact same conclusion without exchanging a single byte of voting data. This effectively reduces the bandwidth cost of consensus to zero (overhead is only the transactions and gossip structure).17

5.3 Famous Witnesses and Fairness

To establish a total order, Hashgraph uses Famous Witnesses:

  1. The Hashgraph is divided into “rounds.” The first event a node creates in a round is a Witness.
  2. Nodes determine if a Witness is “Famous” by checking if it is “seen” by the majority of Witnesses in the next round. This “seeing” is calculated using the graph’s connectivity (strongly seeing).
  3. Once the Famous Witnesses are identified, they act as anchors. The system calculates the “consensus timestamp” of every transaction based on when the Famous Witnesses received it.
  4. The result is a Fair Timestamp: the median time that the network received a transaction. This prevents a leader from arbitrarily manipulating timestamps or ordering.17

Hashgraph achieves ABFT, is resistant to DDoS (no leader), and offers extremely high throughput (10,000+ TPS) with low latency (3-5 seconds). However, it operates in a permissioned (governing council) mode for public networks, which distinguishes it from permissionless implementations like Fantom.11

6. Case Study: Fantom and Lachesis

Fantom utilizes a consensus mechanism called Lachesis, which, like Hashgraph, is a leaderless, DAG-based aBFT protocol, but it employs different algorithms to achieve finality.20

6.1 The OPERA Chain

In Fantom, nodes construct a local DAG called the OPERA Chain. Each node creates “event blocks” containing transactions and references to previous event blocks (one self-parent and one other-parent). This structure captures the causal relationship of events.22

6.2 Clotho and Atropos: The Election Mechanism

Lachesis distills the complex DAG into a simpler structure for ordering:

  1. Roots: Events that are known by a supermajority ($2/3$) of nodes are flagged as “Roots.”
  2. Clotho: As the DAG grows, specific Roots are promoted to Clotho status. A Clotho is a Root that is acknowledged by a supermajority of other Roots. These act as checkpoints in the DAG.
  3. Atropos: The final stage is the selection of an Atropos from the Clotho candidates. The Atropos blocks form the “Main Chain” of the network. Once an Atropos is finalized, all transactions in its past cone are finalized.20

6.3 Finality and Performance

Lachesis enables Fantom to achieve absolute finality in 1-2 seconds. Unlike probabilistic finality (where a transaction becomes “more” secure over time, like in Bitcoin), once an Atropos is selected, the history is immutable. This speed, combined with the ability to process thousands of TPS, makes it suitable for high-frequency DeFi applications. The leaderless nature ensures that there is no single point of failure for DDoS attacks.24

7. Case Study: Aleph Zero and AlephBFT

Aleph Zero represents a hybrid approach, combining the speed of DAGs with the structured security of a rotating committee, integrated with privacy-preserving technologies.26

7.1 AlephBFT Mechanics

AlephBFT is a peer-reviewed consensus protocol presented at the AFT 2019 conference. It builds a DAG where units (blocks) are created by committee members.

  • The Committee: Unlike pure gossip protocols where every node talks to every node (which scales poorly to thousands of nodes), Aleph Zero selects a rotating committee of validators to construct the DAG.
  • Asynchronous Operation: The creation of the DAG is asynchronous. Validators emit units as fast as possible.
  • Ordering: Once the DAG is formed, the protocol applies a deterministic algorithm to extract a linear ordering. This allows AlephBFT to tolerate asynchronous conditions (safety) while optimizing for speed.27

7.2 Privacy: The “Liminal” Layer

A key differentiator for Aleph Zero is its focus on privacy. It integrates Secure Multi-Party Computation (sMPC) and Zero-Knowledge Proofs (ZK-SNARKs) into the platform. This allows for “private smart contracts” where the global state is updated without revealing the input data of individual users. This is particularly relevant for institutional use cases requiring compliance (ZK-ID) and confidentiality.28

8. The Modern Modular Stack: Narwhal, Tusk, and Mysticeti

The most significant recent evolution in asynchronous blockchains is the architectural decoupling of transaction dissemination (making data available) from transaction ordering (consensus). This modular approach, pioneered by the Narwhal and Tusk papers and adopted by the Sui blockchain, represents the state-of-the-art.30

8.1 Narwhal: The High-Performance Mempool

In traditional blockchains, the “mempool” (memory pool of unconfirmed transactions) is a chaotic waiting room. Narwhal transforms the mempool into a structured, reliable data store.

  • Workers: Each validator runs multiple “worker” processes. These workers ingest transactions, batch them, and broadcast them to workers on other nodes.
  • Proofs of Availability: When a worker receives a batch, it signs it and sends the signature back. Once a batch has $2f+1$ signatures (a quorum), a Certificate is created. This certificate is a cryptographic proof that the data is available on the network.32
  • The DAG of Certificates: The consensus engine never sees the raw transactions. It only sees the Certificates. Narwhal builds a DAG of these certificates. This means the heavy lifting (bandwidth) is done by the workers, while the consensus engine (CPU) only processes tiny metadata headers. This allows the network to scale linearly with bandwidth.34

8.2 Tusk: Zero-Message Overhead Consensus

Tusk is the consensus component designed to sit on top of Narwhal. It is a “Zero-Message Overhead” protocol.

  • Mechanism: Tusk looks at the DAG of certificates built by Narwhal. Because the DAG is causally linked, Tusk can run a randomized algorithm (using a shared coin) to agree on a total ordering of the batches without sending any extra consensus messages. The communication for consensus is effectively piggybacked on the data dissemination.31
  • Resilience: Tusk is fully asynchronous and leaderless. It maintains high throughput (160,000+ TPS) even when the network is under attack or failing, making it one of the most robust protocols in existence.4

8.3 Bullshark: Optimizing for Partial Synchrony

While Tusk is robust, researchers noted that real-world networks are synchronous 99% of the time. Bullshark was developed to optimize Narwhal for the “happy path” (partial synchrony).

  • Fast Path: Bullshark introduces a “Fast Path” that allows the network to commit blocks quickly when the network is stable, using a simplified voting mechanism.
  • Fallback: If the network becomes asynchronous (bad conditions), it falls back to a slower but safe mechanism. This trade-off allowed Bullshark to achieve lower latency than Tusk in good conditions, though it introduced some complexity regarding garbage collection of old blocks.35

8.4 Mysticeti: The Lower Bound of Latency (Sui)

In 2024, Sui upgraded from Bullshark to Mysticeti, pushing the boundaries of DAG-based consensus further.

  • The Latency Problem: Previous DAG protocols (Narwhal) required “Certified” blocks. To create a block, you had to broadcast it, wait for signatures, and creating a Certificate. This added round-trip times (RTTs).
  • Uncertified DAGs: Mysticeti allows the DAG to be built from “Uncertified” blocks. Validators can propose blocks without waiting for a full quorum of signatures first. The consensus logic (safety checks) is applied post-hoc on the graph structure.
  • 3-Round Commit: Mysticeti achieves consensus in just 3 message rounds, which is the theoretical lower bound for BFT. This reduced Sui’s consensus latency to ~390ms on testnets, an 80% improvement over Bullshark.37

9. Comparative Analysis: Asynchronous vs. Synchronous Leaders

To contextualize the performance of asynchronous chains, we must compare them to the leading synchronous/partially synchronous competitors: Aptos, Solana, and Avalanche.

9.1 Aptos (Block-STM & HotStuff)

Aptos uses a derivative of HotStuff (AptosBFT), a partially synchronous, leader-based protocol.

  • Mechanism: Leaders rotate. The current leader proposes a block, and validators vote. If the leader fails, a new one is elected (wait for timeout).
  • Parallel Execution: Aptos shines in execution. Its Block-STM engine allows transactions to be executed in parallel optimistically. If there is a conflict, the transaction is re-executed. This yields massive throughput (160k TPS).40
  • Comparison: While Aptos matches Sui in throughput due to parallel execution, its consensus layer is more brittle. A DDoS attack on the Aptos leader can degrade performance, whereas Sui/Mysticeti has no single leader to attack.42

9.2 Solana (Proof of History)

Solana uses Proof of History (PoH), a unique clock-based mechanism.

  • Mechanism: Validators hash a sequence of events to prove time passage. The schedule of leaders is known in advance.
  • Vulnerability: Because the leader schedule is deterministic and known, attackers can target the next leader with DDoS traffic just as they are about to propose. This has contributed to Solana’s historical instability/outages compared to the theoretically unstoppable asynchronous networks.43

9.3 Avalanche (Snowman)

Avalanche uses a Metastable consensus mechanism based on repeated random sampling.

  • Mechanism: Nodes ask a small random set of peers for their preference. This creates a feedback loop where the network rapidly tips toward one color (decision).
  • Asynchrony: While not BFT in the traditional sense (it is probabilistic), Avalanche is highly resilient and fast. It builds a DAG (X-Chain) but linearizes it (C-Chain) for smart contracts. It shares the “leaderless” benefit of ABFT protocols.45

9.4 Performance Matrix (2025 Data)

 

Feature Sui (Mysticeti) Hedera (Hashgraph) Fantom (Lachesis) Aleph Zero Aptos Solana
Consensus DAG (Uncertified) DAG (Virtual Voting) DAG (Clotho/Atropos) DAG (Rotating Committee) HotStuff (Leader) PoH (Leader)
Model Partial/Async Asynchronous Asynchronous Asynchronous Partial Sync Partial Sync
Latency ~390ms 39 2-5s 16 1-2s 24 ~0.9s 28 <1s 47 ~0.4s (Block)
Max TPS 297,000 48 3,300+ 49 ~181 (Real) 50 100,000 (Theor.) 51 160,000 40 65,000 43
DDoS Resilience Very High Very High Very High High Medium Low

10. Cryptographic Engines of Asynchrony

The magic of “never waiting” is powered by specific cryptographic primitives that replace the coordination role of time.

10.1 Threshold Signatures (BLS)

Boneh-Lynn-Shacham (BLS) signatures are the workhorse of modern BFT. They allow signature aggregation.

  • Why it matters: In a network with 1,000 validators, sending 1,000 signatures for every block would crush the bandwidth. BLS allows all 1,000 signatures to be compressed into a single, constant-sized signature. This is essential for the Certificates in Narwhal and Mysticeti, allowing quorums to be proven efficiently.52
  • Mechanism: Based on bilinear pairings over elliptic curves ($e: G_1 \times G_2 \rightarrow G_T$). The “uniqueness” property of BLS is also crucial—for a given message and key, there is only one valid signature, which prevents malleability attacks.53

10.2 Random Beacons and Common Coins

To solve the FLP “deadlock” (where the network can’t decide between A and B), asynchronous protocols use Random Beacons.

  • Drand: A distributed service that pulses random numbers.
  • Common Coin: A protocol where nodes contribute “shares” of a secret. Once enough shares (threshold) are revealed, the random number is reconstructed.
  • Function: This random number acts as a tie-breaker. “If we haven’t decided by round X, we flip a coin: Heads = Block A, Tails = Block B.” Since the coin is shared and unbiasable, the whole network jumps to the same decision instantly, ensuring liveness.10

10.3 Distributed Key Generation (DKG)

For threshold cryptography to work, nodes must share a secret key without any single person knowing the full key. DKG protocols allow nodes to mathematically generate these key shares distributedly. This setup phase is critical for the security of the random beacons and threshold encryption used in HBBFT and Aleph Zero.55

11. Security Analysis: Robustness in Chaos

The primary selling point of asynchronous blockchains is not just speed, but survival.

11.1 DDoS Resistance

In leader-based systems (Solana, Aptos, PBFT), an attacker can watch the network, identify the leader, and flood them with traffic. The network stalls until a new leader is elected. The attacker then targets the new leader.

In asynchronous, leaderless DAGs (Sui, Fantom, Hedera), there is no single target. An attacker would have to DDoS $1/3$ of the entire network simultaneously to stop consensus. This raises the cost of attack exponentially.4

11.2 Censorship Resistance

Threshold encryption (as used in HBBFT and potential upgrades to others) provides strong censorship resistance. Since validators cannot see the transaction content until it is ordered, they cannot discriminately drop transactions from blacklisted addresses. This is a significant improvement over leader-based chains where the leader has absolute discretion over block inclusion.8

11.3 MEV Protection

Maximal Extractable Value (MEV) is the profit a miner makes by reordering transactions (front-running). Asynchronous protocols with threshold encryption eliminate “toxic” MEV because the ordering is fixed before the content is revealed. However, protocols like Narwhal (without encryption) simply separate ordering from dissemination; while they make reordering harder due to the speed of the DAG, they do not strictly prevent it unless coupled with a simplified ordering mechanism like Tusk.28

12. Future Directions and Challenges

12.1 The Bandwidth Constraint

As protocols like Mysticeti remove latency bottlenecks, the limiting factor becomes bandwidth. To process 300,000 TPS, validators need massive internet pipes. This creates a centralization pressure: only data centers can run nodes. Future research is focused on state compression and sharding to allow consumer hardware to participate despite the high throughput.37

12.2 Post-Quantum Security

Most current ABFT protocols rely on BLS signatures, which are vulnerable to quantum computers (Shor’s algorithm). The structure of DAG-based consensus is compatible with post-quantum signatures (like Lattice-based crypto), but these signatures are much larger. The “Zero-Message Overhead” of Tusk makes it a prime candidate for adopting these heavy keys, as it minimizes the number of times they need to be sent.57

12.3 Convergence with Databases

We are witnessing the convergence of blockchains and distributed databases. Techniques like Block-STM (Aptos) and Mysticeti (Sui) draw heavily from optimistic concurrency control in databases. The future blockchain will likely look less like a “chain of blocks” and more like a globally replicated, asynchronous, ACID-compliant database state machine.41

13. Conclusion

The evolution of asynchronous blockchains marks a critical maturity point for distributed ledger technology. By abandoning the safety net of synchrony, protocols have evolved from the linear, fragile chains of the past into robust, high-speed directed acyclic graphs.

From the theoretical breakthrough of HoneyBadgerBFT to the commercial speed of Hedera Hashgraph and Fantom, and finally to the modular, bandwidth-optimized architecture of Sui’s Mysticeti, the industry has solved the “waiting” problem. These networks do not rely on global clocks or arbitrary timeouts; they operate at the limit of physics and bandwidth. While complexity remains a barrier—requiring advanced threshold cryptography and intricate DAG traversal algorithms—the result is a class of infrastructure capable of supporting the global financial system: networks that are secure, decentralized, and, crucially, never wait.

Note: Citations follow the format “ referring to the provided research snippets. No separate reference list is included.

Works cited

  1. Foundations of Blockchains Lectures #4 & 5: The Asynchronous Model and the FLP Impossibility Theorem (ROUGH DRAFT) – GitHub Pages, accessed on December 21, 2025, https://timroughgarden.github.io/fob21/l/l4-5.pdf
  2. Synchrony and Timing Assumptions in Consensus Algorithms Used in Proof of Stake Blockchains | by zk – Zubin Koticha | Mechanism Labs | Medium, accessed on December 21, 2025, https://medium.com/mechanism-labs/synchrony-and-timing-assumptions-in-consensus-algorithms-used-in-proof-of-stake-blockchains-5356fb253459
  3. Foundations of Blockchains Lectures #6: The Partially Synchronous Model, 33%, and the CAP Principle (ROUGH DRAFT) – GitHub Pages, accessed on December 21, 2025, https://timroughgarden.github.io/fob21/l/l6.pdf
  4. An Empirical Study of Consensus Protocols’ DoS Resilience – Network Security Group, ETH Zurich, accessed on December 21, 2025, https://netsec.ethz.ch/publications/papers/Consensus_DDoS_AsiaCCS_24.pdf
  5. Impossibility of Distributed Consensus with One Faulty Process – cs.Princeton, accessed on December 21, 2025, https://www.cs.princeton.edu/courses/archive/spr22/cos418/papers/flp.pdf
  6. Asynchronous Byzantine Fault Tolerance (ABFT) – Emergent Mind, accessed on December 21, 2025, https://www.emergentmind.com/topics/asynchronous-byzantine-fault-tolerance-abft
  7. Synchrony, Asynchrony and Partial synchrony – Decentralized Thoughts, accessed on December 21, 2025, https://decentralizedthoughts.github.io/2019-06-01-2019-5-31-models/
  8. Honeybadger of BFT Protocols | PDF – Slideshare, accessed on December 21, 2025, https://www.slideshare.net/slideshow/honeybadger-of-bft-protocols/157560935
  9. poanetwork/hbbft: An implementation of the paper “Honey Badger of BFT Protocols” in Rust. This is a modular library of consensus. – GitHub, accessed on December 21, 2025, https://github.com/poanetwork/hbbft
  10. Understanding the Honey Badger Consensus Algorithm | by Bernd Strehl – Medium, accessed on December 21, 2025, https://medium.com/elbstack/understanding-the-honey-badger-consensus-algorithm-240be28d7dc
  11. What is asynchronous byzantine fault tolerance (ABFT)? – Hedera, accessed on December 21, 2025, https://hedera.com/learning/hedera-hashgraph/what-is-asynchronous-byzantine-fault-tolerance-abft
  12. Alea-BFT: Practical Asynchronous Byzantine Fault Tolerance – USENIX, accessed on December 21, 2025, https://www.usenix.org/system/files/nsdi24-antunes.pdf
  13. A Review of Asynchronous Byzantine Consensus Protocols – PMC – NIH, accessed on December 21, 2025, https://pmc.ncbi.nlm.nih.gov/articles/PMC11679012/
  14. A Survey on Consensus Algorithms of Blockchain Based on DAG – ResearchGate, accessed on December 21, 2025, https://www.researchgate.net/publication/384991759_A_Survey_on_Consensus_Algorithms_of_Blockchain_Based_on_DAG
  15. What is Hashgraph Consensus Mechanism?-Fincash, accessed on December 21, 2025, https://www.fincash.com/l/basics/hashgraph-consensus-mechanism
  16. Hashgraph Consensus: What It is, How It Works – Investopedia, accessed on December 21, 2025, https://www.investopedia.com/terms/h/hashgraph-consensus-mechanism.asp
  17. How does Hashgraph consensus work? – Accubits Blog, accessed on December 21, 2025, https://blog.accubits.com/how-does-hashgraph-consensus-work/
  18. Hashgraph Consensus Algorithm – Hedera Docs, accessed on December 21, 2025, https://docs.hedera.com/hedera/core-concepts/hashgraph-consensus-algorithms
  19. Hedera Hashgraph vs Fantom utility comparison – CoinExams, accessed on December 21, 2025, https://coinexams.com/compare/hedera-hashgraph-vs-fantom
  20. fantom-documentation/lachesis.md at master – GitHub, accessed on December 21, 2025, https://github.com/Fantom-foundation/fantom-documentation/blob/master/lachesis.md
  21. How Consensus Works on Fantom, accessed on December 21, 2025, https://blog.fantom.foundation/how-consensus-works-on-fantom/
  22. A Simple Guide to Understanding Fantom’s Lachesis Protocol and DAG Structure – Kishan, accessed on December 21, 2025, https://www.0xkishan.com/blogs/a-simple-guide-to-understanding-fantoms-lachesis-protocol-and-dag-structure
  23. Understand Fantom (FTM) in one article – Gate.com, accessed on December 21, 2025, https://www.gate.com/learn/articles/understand-fantom-ftm-in-one-article/4128
  24. How Fantom is Solving The Blockchain Trilema – EatTheBlocks, accessed on December 21, 2025, https://eattheblocks.com/getting-started-with-fantom-blockchain/
  25. Understanding Lachesis Consensus: The Backbone of Asset Chain’s Speed and Security | by Valentine Blaze | Medium, accessed on December 21, 2025, https://medium.com/@V-Blaze/understanding-lachesis-consensus-the-backbone-of-asset-chains-speed-and-security-02d7c166e132
  26. AlephBFT Consensus – Aleph Zero, accessed on December 21, 2025, https://docs.alephzero.org/aleph-zero/explore/alephbft-consensus
  27. What is Aleph? – AlephBFT, accessed on December 21, 2025, https://cardinal-cryptography.github.io/AlephBFT/how_alephbft_does_it.html
  28. Aleph Zero Overview – Reflexivity Research, accessed on December 21, 2025, https://www.reflexivityresearch.com/free-reports/aleph-zero-overview
  29. Aleph Zero Information – OnBloq, accessed on December 21, 2025, https://onbloq.com/azero/
  30. Narwhal Protocol: Scalable BFT for Ledgers – Emergent Mind, accessed on December 21, 2025, https://www.emergentmind.com/topics/narwhal-protocol
  31. Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus – Meta Research, accessed on December 21, 2025, https://research.facebook.com/publications/narwhal-and-tusk-a-dag-based-mempool-and-efficient-bft-consensus/
  32. Narwhal: Scalable Blockchain Data Propagation with DAG-Based Design | blog.wonjoon, accessed on December 21, 2025, https://wnjoon.github.io/2024/12/17/what-is-narwhal/
  33. Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus – Alberto Sonnino, accessed on December 21, 2025, https://sonnino.com/papers/narwhal-and-tusk.pdf
  34. [Infrastructure] Aptos Series #4: Block-STM, Narwhal&Tusk, and Bullshark — Technologies for Further Scalability – A41.io, accessed on December 21, 2025, https://medium.a41.io/aptos-series-4-block-stm-narwhal-tusk-and-bullshark-technologies-for-further-scalability-681f2ccc17cc
  35. Research on the Next-gen Consensus Mechanism — BFT Consensus Based on DAG – PlatON Network, accessed on December 21, 2025, https://platon.network/informationDetail?id=185&plat=1
  36. Bullshark: DAG BFT Protocols Made Practical – Aptos Labs, accessed on December 21, 2025, https://aptoslabs.com/pdf/2201.05677.pdf
  37. Consensus – Blockberry API, accessed on December 21, 2025, https://docs.blockberry.one/docs/consensus
  38. Mysticeti: Reaching the Latency Limits with Uncertified DAGs – Network and Distributed System Security (NDSS) Symposium, accessed on December 21, 2025, https://www.ndss-symposium.org/wp-content/uploads/2025-929-paper.pdf
  39. Zoom in on Mysticeti, the update that powers Sui (SUI) – OAK Research, accessed on December 21, 2025, https://oakresearch.io/en/analyses/fundamentals/zoom-in-mysticeti-update-sui
  40. Aptos vs Sui: A Fight of The New-generation Layer-1 Blockchain Platforms – Global IT Services and Consulting Company – SotaTek, accessed on December 21, 2025, https://www.sotatek.com/blogs/blockchain/aptos-vs-sui-a-fight-of-the-new-generation-layer-1-blockchain-platforms/
  41. Sui vs Aptos: A Technical Deep Dive into Move Language Implementations, accessed on December 21, 2025, https://aeorysanalytics.medium.com/sui-vs-aptos-a-technical-deep-dive-into-move-language-implementations-b2c2c8132dd6
  42. SUI vs. APTOS: Blockchain Protocols Using the Move Programming Language – Trust Wallet, accessed on December 21, 2025, https://trustwallet.com/blog/blockchain/sui-vs-aptos-blockchain-protocols-using-the-move-programming-language
  43. Fastest Cryptocurrencies With High Transaction Speeds (TPS) – HollaEx, accessed on December 21, 2025, https://www.hollaex.com/blog/fastest-cryptocurrencies-with-high-transaction-speeds
  44. ‍Fastest Blockchains in 2025: Which Networks Are Actually the Fastest?‍ – Bleap, accessed on December 21, 2025, https://www.bleap.finance/blog/fastest-blockchains
  45. When Is Spring Coming? A Security Analysis of Avalanche Consensus – DROPS, accessed on December 21, 2025, https://drops.dagstuhl.de/storage/00lipics/lipics-vol253-opodis2022/LIPIcs.OPODIS.2022.10/LIPIcs.OPODIS.2022.10.pdf
  46. An Analysis of Avalanche ConsensusIgnacio Amores-Sesar has been supported by the Swiss National Science Foundation (SNSF) under grant agreement Nr. 200021_188443 (Advanced Consensus Protocols). Philipp Schneider has been supported by a grant from Avalanche, Inc. to the University of Bern. – arXiv, accessed on December 21, 2025, https://arxiv.org/html/2401.02811v1
  47. Which blockchain is the fastest? – Pontem Network, accessed on December 21, 2025, https://pontem.network/posts/which-blockchain-is-the-fastest
  48. Consensus | Sui Documentation, accessed on December 21, 2025, https://docs.sui.io/concepts/sui-architecture/consensus
  49. Hedera [TPS, Max TPS, Block Time & TTF] – Chainspect, accessed on December 21, 2025, https://chainspect.app/chain/hedera
  50. Transactions Per Second (TPS) – DEV Community, accessed on December 21, 2025, https://dev.to/fromaline/transaction-per-second-tps-3f8b
  51. Understanding TPS: A Key Measure of Blockchain Speed – Aleph Zero Blog, accessed on December 21, 2025, https://alephzero.org/blog/understanding-tps-key-measure-of-blockchain-speed
  52. BLS digital signature – Wikipedia, accessed on December 21, 2025, https://en.wikipedia.org/wiki/BLS_digital_signature
  53. Randomness Generation · Cloudflare Randomness Beacon docs, accessed on December 21, 2025, https://developers.cloudflare.com/randomness-beacon/cryptographic-background/randomness-generation/
  54. STROBE: Streaming Threshold Random Beacons – DROPS, accessed on December 21, 2025, https://drops.dagstuhl.de/storage/00lipics/lipics-vol282-aft2023/LIPIcs.AFT.2023.7/LIPIcs.AFT.2023.7.pdf
  55. How do Randomness Beacons based on Threshold Signatures work? – NEAR, accessed on December 21, 2025, https://www.near.org/blog/randomness-threshold-signatures
  56. Liveness analysis, modeling, and simulation of blockchain consensus algorithms’ ability to tolerate malicious miners – UTC Scholar, accessed on December 21, 2025, https://scholar.utc.edu/cgi/viewcontent.cgi?article=1893&context=theses
  57. SoK: DAG-based Consensus Protocols – arXiv, accessed on December 21, 2025, https://arxiv.org/html/2411.10026v1