Sui’s Consensus Evolution: From Tusk to Mysticeti

Sui has replaced its consensus core twice. The network has never needed a hard fork.

This article is part of a series on Sui:

• Discovering Sui: A Blockchain With Multiple Innovations
• Under the Hood of Sui: Validators, Consensus and Staking
• Sui: The Object Model, or Rethinking Blockchains Through Data
• Sui Governance: Upgrading Without Breaking
• Sui’s Consensus Explained: How Narwhal and Mysticeti Finalize in 0.5 Seconds

The reason comes down to an architectural choice. Narwhal, the layer responsible for disseminating transactions between validators and organizing them into a DAG, stayed stable across all three protocols. Above it, the mechanism responsible for ordering transactions could be swapped out. Tusk, then Bullshark, then Mysticeti each plugged into the same foundation. Where other blockchains would have needed to rebuild from scratch, Sui only replaced one layer.

One terminological point worth clarifying upfront. Sui handles two types of transactions differently, and that distinction has nothing to do with which consensus protocol is running. Objects owned by a single party — a simple transfer, for instance — bypass consensus entirely via Byzantine Consistent Broadcast, which is faster. Only shared objects require consensus for ordering. This mechanism has been in place since Sui’s launch and operates regardless of which consensus protocol is active. It should not be confused with the evolution of the consensus protocol itself, which is the subject of this article.

Tusk: The Asynchronous Starting Point

Tusk was designed for a network where nothing can be assumed about message delivery times. No timing bounds, no synchrony assumptions. That’s the most adversarial scenario — and also the most realistic for a global network where conditions vary widely from one validator to the next.

Its core idea: once Narwhal’s DAG is built, consensus is reached without any additional communication. Each validator applies the same deterministic algorithm to its local view of the DAG and arrives at the same ordering as every other validator. No voting rounds, no explicit coordination. The order is read from the reference structure itself, by identifying anchor points that act as commit markers.

The original paper’s benchmarks, measured across 20 validators, put throughput at around 160,000 transactions per second with a latency of approximately 3 seconds. At the time, that was ahead of what classical systems could achieve.

Two problems remained. First, latency: 3 seconds is workable for many use cases, but a dealbreaker for trading or real-time gaming. Second, fairness. In a purely asynchronous setting, better-connected validators saw their transactions included more often than others — a structural imbalance that favored the fastest nodes.

Tusk lived mostly in research and on testnet. By the time Sui’s mainnet launched in 2023, Bullshark was already in charge.

Bullshark: Partial Synchrony

Bullshark’s conceptual leap rests on a single assumption: most of the time, the network behaves normally. Rather than always preparing for the worst, the protocol exploits periods when messages arrive within reasonable delays. This is the partially synchronous model: timing bounds are assumed under normal conditions; asynchronous robustness kicks in when the network degrades.

From that assumption follows Bullshark’s genuine fast path — not to be confused with the owned/shared object distinction mentioned above. During synchronous periods, the protocol can commit faster, without waiting through as many rounds as in degraded mode. It’s a latency shortcut conditioned on network health.

Bullshark also addressed the fairness problem Tusk left unsolved, through weak links. These links allow a temporarily slow validator to be included in the final consensus even if faster validators haven’t referenced it yet. No honest validator gets shut out due to a poor connection. The protocol also refined anchor selection and memory cleanup, which allowed it to sustain load over extended periods.

The cost: greater complexity. Weak links and network adaptation introduce edge cases and computational overhead. The paper reports 125,000 TPS at 2 seconds of latency across 50 parties — lower than Tusk on paper, but the comparison is misleading: Tusk was measured across 20 validators, and throughput drops mechanically as the network grows. The two figures aren’t directly comparable. Latency, meanwhile, stayed in the range of a second — still too slow for the most demanding applications.

For Sui, the transition had one main value: proving the network could change its consensus without disruption. A meaningful confidence signal for developers building on it.

Mysticeti: Dropping Explicit Certification

Mysticeti doesn’t extend Bullshark — it changes the underlying logic. Both Tusk and Bullshark rely on a certified DAG: each block must be signed by a quorum of validators before it’s considered available. That certification is expensive — in signatures to produce and verify, and in network round trips. It was the bottleneck shared by both previous generations.

Mysticeti removes that step entirely. It operates on an uncertified DAG: validators sign and broadcast their blocks, and that’s it. Agreement is no longer voted on; it’s inferred. When a validator references another’s block in its own output, that act of referencing constitutes implicit approval. Consensus is derived from referencing behavior, with no dedicated voting messages at all.

The results show on two dimensions. On latency, Mysticeti commits in three rounds of messages — the theoretical minimum, on par with practical BFT. On resources, eliminating thousands of signatures per round significantly reduces CPU load: roughly 40% less in production (from ~48% to ~29% across deployed validators). The protocol also runs multiple leaders in parallel each round, which lowers median and tail latencies, and it absorbs leader unavailability without stalling.

A variant, Mysticeti-FPC, adds a fast commit path for asset transfers. Its distinguishing feature is weaving those transactions directly into the DAG rather than handling them separately, which saves signatures and messages. This is where the genuine fast commit path embedded in the structure lives — not in Bullshark.

The numbers, measured in a controlled environment: 300,000 TPS with 10 nodes and 400,000 TPS with 50 nodes before latency crosses one second. Under sustained load, commits land around 0.5 seconds at 200,000 TPS. In the same tests, other leading protocols peak below 150,000 TPS with latencies starting around 2 seconds.

Then there’s the widely cited “80% latency reduction versus Bullshark” (from ~1.9s to ~400ms). The figure is accurate, but it’s a best-case comparison: it pits Bullshark under degraded conditions against Mysticeti under optimal ones. Under typical shared-object load, the gain is more modest, though no public measurement pins down an exact figure. Worth keeping in mind too: the 200,000–400,000 TPS numbers come from controlled benchmarks. On mainnet, under real conditions, observed throughput is far lower.

What the Trajectory Shows

Lining up the three generations, the progression is clear — as long as the numbers are read in context.

Throughput goes from ~160,000 TPS (Tusk, 20 validators) to 125,000 TPS (Bullshark, 50 parties) and then to 300,000–400,000 TPS depending on configuration (Mysticeti). The node counts differ, so these values don’t compare point for point: they give an order of magnitude, not a strict ranking. Latency, on the other hand, drops unambiguously: from 3 seconds to roughly 0.5 seconds, passing through ~2 seconds for Bullshark. On the communication side, the progression moves from zero overhead once the DAG is built (but with expensive certification upstream) to implicit certification that eliminates most voting traffic.

The real inflection point is not between Tusk and Bullshark — both belong to the same family: certified DAG, explicit certification, incremental optimizations. The break is between Bullshark and Mysticeti, with the abandonment of certification. Tusk and Bullshark optimized a step; Mysticeti eliminated it.

One thing worth emphasizing: across all three protocols, Narwhal barely changed. All the innovation concentrated on the ordering layer, without destabilizing data dissemination. It’s that separation of responsibilities that made these replacements possible without service interruption — the kind of architectural choice that doesn’t pay off immediately, but ends up changing everything.

Mysticeti probably isn’t the final word. Sui’s approach is precisely to replace a component when a better one emerges, without touching the rest. If a fourth generation arrives, it will most likely plug into the same Narwhal.

Sources

• Tusk — Danezis, Kokoris-Kogias, Sonnino, Spiegelman. Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus (2021). arXiv · PDF
• Bullshark — Spiegelman, Giridharan, Sonnino, Kokoris-Kogias. Bullshark: DAG BFT Protocols Made Practical (2022). arXiv · PDF
• Mysticeti — Babel, Chursin, Danezis, Kichidis, Kokoris-Kogias, Koshy, Sonnino, Tian. Mysticeti: Reaching the Limits of Latency with Uncertified DAGs (2023, NDSS 2025). arXiv · PDF

Sui’s Consensus Evolution: From Tusk to Mysticeti was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.