Sui has replaced its consensus core twice. The network has never needed a hard\u00a0fork.<\/p>\n
This article is part of a series on\u00a0Sui:<\/em><\/p>\n Discovering Sui: A Blockchain With Multiple Innovations<\/em><\/a>Under the Hood of Sui: Validators, Consensus and\u00a0Staking<\/em><\/a>Sui: The Object Model, or Rethinking Blockchains Through\u00a0Data<\/em><\/a>Sui Governance: Upgrading Without\u00a0Breaking<\/em><\/a>Sui\u2019s Consensus Explained: How Narwhal and Mysticeti Finalize in 0.5\u00a0Seconds<\/em><\/a><\/p>\n 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\u00a0layer.<\/p>\n 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\u200a\u2014\u200aa simple transfer, for instance\u200a\u2014\u200abypass consensus entirely via Byzantine Consistent Broadcast, which is faster. Only shared objects require consensus for ordering. This mechanism has been in place since Sui\u2019s 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\u00a0article.<\/p>\n Tusk was designed for a network where nothing can be assumed about message delivery times. No timing bounds, no synchrony assumptions. That\u2019s the most adversarial scenario\u200a\u2014\u200aand also the most realistic for a global network where conditions vary widely from one validator to the\u00a0next.<\/p>\n Its core idea: once Narwhal\u2019s 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\u00a0markers.<\/p>\n The original paper\u2019s 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\u00a0achieve.<\/p>\n 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\u200a\u2014\u200aa structural imbalance that favored the fastest\u00a0nodes.<\/p>\n Tusk lived mostly in research and on testnet. By the time Sui\u2019s mainnet launched in 2023, Bullshark was already in\u00a0charge.<\/p>\n Bullshark\u2019s 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.<\/p>\n From that assumption follows Bullshark\u2019s genuine fast path\u200a\u2014\u200anot 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\u2019s a latency shortcut conditioned on network\u00a0health.<\/p>\n Bullshark also addressed the fairness problem Tusk left unsolved, through weak links<\/em>. These links allow a temporarily slow validator to be included in the final consensus even if faster validators haven\u2019t 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\u00a0periods.<\/p>\n 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\u200a\u2014\u200alower 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\u2019t directly comparable. Latency, meanwhile, stayed in the range of a second\u200a\u2014\u200astill too slow for the most demanding applications.<\/p>\n 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\u00a0it.<\/p>\n Mysticeti doesn\u2019t extend Bullshark\u200a\u2014\u200ait changes the underlying logic. Both Tusk and Bullshark rely on a certified<\/em> DAG: each block must be signed by a quorum of validators before it\u2019s considered available. That certification is expensive\u200a\u2014\u200ain signatures to produce and verify, and in network round trips. It was the bottleneck shared by both previous generations.<\/p>\n Mysticeti removes that step entirely. It operates on an uncertified DAG: validators sign and broadcast their blocks, and that\u2019s it. Agreement is no longer voted on; it\u2019s inferred. When a validator references another\u2019s block in its own output, that act of referencing constitutes implicit approval. Consensus is derived from referencing behavior, with no dedicated voting messages at\u00a0all.<\/p>\n The results show on two dimensions. On latency, Mysticeti commits in three rounds of messages\u200a\u2014\u200athe 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.<\/p>\n 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\u200a\u2014\u200anot in Bullshark.<\/p>\n 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\u00a0seconds.<\/p>\n Then there\u2019s the widely cited \u201c80% latency reduction versus Bullshark\u201d (from ~1.9s to ~400ms). The figure is accurate, but it\u2019s 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\u2013400,000 TPS numbers come from controlled benchmarks. On mainnet, under real conditions, observed throughput is far\u00a0lower.<\/p>\n Lining up the three generations, the progression is clear\u200a\u2014\u200aas long as the numbers are read in\u00a0context.<\/p>\n Throughput goes from ~160,000 TPS (Tusk, 20 validators) to 125,000 TPS (Bullshark, 50 parties) and then to 300,000\u2013400,000 TPS depending on configuration (Mysticeti). The node counts differ, so these values don\u2019t 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\u00a0traffic.<\/p>\n The real inflection point is not between Tusk and Bullshark\u200a\u2014\u200aboth 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.<\/p>\n One thing worth emphasizing: across all three protocols, Narwhal barely changed. All the innovation concentrated on the ordering layer, without destabilizing data dissemination. It\u2019s that separation of responsibilities that made these replacements possible without service interruption\u200a\u2014\u200athe kind of architectural choice that doesn\u2019t pay off immediately, but ends up changing everything.<\/p>\n Mysticeti probably isn\u2019t the final word. Sui\u2019s 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\u00a0Narwhal.<\/p>\n Tusk<\/strong>\u200a\u2014\u200aDanezis, Kokoris-Kogias, Sonnino, Spiegelman. Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus<\/em> (2021). arXiv<\/a> \u00b7\u00a0PDF<\/a>Bullshark<\/strong>\u200a\u2014\u200aSpiegelman, Giridharan, Sonnino, Kokoris-Kogias. Bullshark: DAG BFT Protocols Made Practical<\/em> (2022). arXiv<\/a> \u00b7\u00a0PDF<\/a>Mysticeti<\/strong>\u200a\u2014\u200aBabel, Chursin, Danezis, Kichidis, Kokoris-Kogias, Koshy, Sonnino, Tian. Mysticeti: Reaching the Limits of Latency with Uncertified DAGs<\/em> (2023, NDSS 2025). arXiv<\/a> \u00b7\u00a0PDF<\/a><\/p>\n Sui\u2019s Consensus Evolution: From Tusk to Mysticeti<\/a> was originally published in Coinmonks<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>","protected":false},"excerpt":{"rendered":" Sui has replaced its consensus core twice. The network has never needed a hard\u00a0fork. This article is part of a series on\u00a0Sui: Discovering Sui: A Blockchain With Multiple InnovationsUnder the Hood of Sui: Validators, Consensus and\u00a0StakingSui: The Object Model, or Rethinking Blockchains Through\u00a0DataSui Governance: Upgrading Without\u00a0BreakingSui\u2019s Consensus Explained: How Narwhal and Mysticeti Finalize in 0.5\u00a0Seconds […]<\/p>\n","protected":false},"author":0,"featured_media":189106,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-189105","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-interesting"],"_links":{"self":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/189105"}],"collection":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=189105"}],"version-history":[{"count":0,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/189105\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/media\/189106"}],"wp:attachment":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=189105"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=189105"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=189105"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Tusk: The Asynchronous Starting\u00a0Point<\/h3>\n
Bullshark: Partial Synchrony<\/h3>\n
Mysticeti: Dropping Explicit Certification<\/h3>\n
What the Trajectory Shows<\/h3>\n
Sources<\/h3>\n