Every BFT protocol this phase has covered — PBFT, HotStuff, Tendermint — shares one structural bottleneck this article names explicitly for the first time: the leader (or round proposer) must personally handle the full bandwidth of every transaction, because data dissemination and consensus ordering are bundled into the same role and the same protocol. Danezis, Kokoris-Kogias, Sonnino, and Spiegelman's 2021 Narwhal paper makes a structural separation that turns out to unlock dramatically higher throughput: split data dissemination (getting transaction data to everyone) from consensus (deciding the order) into two independent components. Bullshark, the companion consensus protocol built on top of Narwhal's output, then achieves near-zero marginal ordering overhead. This closes Phase 6 with the throughput-focused frontier of BFT research — and sets up a direct thematic bridge to Phase 7's leaderless and flexible-quorum modern Paxos variants.
The shared bottleneck every prior protocol has
Look back across PBFT (6.2), HotStuff (6.3), and Tendermint (6.4): in every one of them, the leader/proposer role does double duty — it's both the party responsible for disseminating the actual transaction data to the rest of the network and the party whose proposal drives the ordering/agreement protocol. This bundling means the leader's available bandwidth becomes a hard ceiling on the whole system's throughput — no matter how efficient the voting/signature-aggregation machinery is (HotStuff's whole contribution, article 6.3), the leader still has to personally push every transaction's raw data out to the network before the protocol can even begin ordering it.
Narwhal: separating dissemination from ordering
Narwhal's structural fix: transaction data flows through a DAG (directed acyclic graph) based mempool that is entirely separate from, and doesn't wait for, the consensus ordering protocol. Every validator continuously proposes its own batch of transactions into the DAG structure, referencing prior batches from other validators; validators certify (with signatures, echoing article 6.2's cryptographic-authentication theme) that they've received and stored each batch, and once a batch has certificates from a quorum, it's durably, redundantly available across the network — completely independent of whatever the current consensus leader happens to be doing. Every validator participates in disseminating data continuously and in parallel, rather than funneling everything through one leader's bandwidth, directly removing the shared bottleneck named above.
Fig 1 — Separating "get the data everywhere" from "agree on the order" removes the single-leader bandwidth ceiling.
Bullshark: ordering the DAG with near-zero overhead
With Narwhal handling data availability, Bullshark solves the remaining, now much lighter-weight problem: deciding a total order over the certified batches already sitting in the DAG. Because every batch is already certified and durably available (Narwhal's job, already done), Bullshark's ordering protocol doesn't need to move any transaction data at all — it only needs to agree on a traversal order over the DAG structure, using the DAG's own structure (which batch references which) as an implicit source of ordering information, requiring only a small amount of additional metadata exchange (not full transaction data) on top of Narwhal's continuous operation. This is why Bullshark's marginal overhead is characterized as near-zero: the expensive part (data dissemination, which every protocol in this phase needed to do somehow) is already amortized across Narwhal's continuous, parallel operation, leaving Bullshark to do comparatively cheap, metadata-only ordering work.
Phase 6 closing comparison
| Protocol | Core innovation | Communication pattern | Best fit |
|---|---|---|---|
| PBFT (6.2) | First practical BFT — 3-phase protocol at the 3f+1 minimum | All-to-all, O(n²) | Small permissioned clusters |
| HotStuff (6.3) | Linear communication via threshold-signature aggregation | Leader-routed, O(n) | Large validator sets, blockchain-scale |
| Tendermint (6.4) | Immediate deterministic finality + economic slashing | Round-based, gossip | Proof-of-stake chains needing instant finality |
| Narwhal/Bullshark (6.5) | Separating data dissemination from ordering | DAG mempool + lightweight ordering | Maximum throughput, high transaction volume |
Closing Phase 6
Phase 6 introduced a genuinely harder failure model — Byzantine, not just crash — and showed that the majority-overlap mechanism this series built across Phases 3-5 needed real reinforcement (the 3f+1 bound, cryptographic signatures) rather than a simple bigger-cluster fix, to survive actively adversarial participants. From that foundation, four protocols showed four different, defensible engineering priorities: PBFT's foundational practicality, HotStuff's communication-complexity focus, Tendermint's finality-and-accountability focus, and Narwhal/Bullshark's throughput-through-architectural-separation focus — a real spread of design trade-offs, unlike Phase 5's closing comparison (article 5.7) which showed largely convergent presentations of the same underlying mechanism.
Phase 7 now returns to the crash-fault-tolerant world (Paxos's own extended family, not Byzantine), covering the modern Paxos family — EPaxos's leaderless design, Flexible Paxos's quorum relaxation, and the research lineage (Atlas, Caesar, OmniPaxos, Matchmaker Paxos, PigPaxos, BPaxos, Rabia) that leads directly to this series' eventual destination: QuePaxa and Meerkat in Phase 10.
FAQ
Does Narwhal/Bullshark still need 3f+1 nodes?
Yes — the fundamental Byzantine-agreement bound from article 6.1 is unaffected by this architectural separation; Narwhal/Bullshark operates within the same 3f+1 constraint as every other protocol in this phase, since the separation addresses throughput and communication patterns, not the underlying fault-tolerance mathematics.
Is the DAG mempool itself vulnerable to a Byzantine validator withholding data?
The certification requirement (a quorum of validators must sign off that they've received a batch before it's usable) prevents a single Byzantine validator from making data unavailable — this directly mirrors article 3.3's overlap-based safety logic, just applied to data availability rather than value agreement.
Which production systems use Narwhal/Bullshark?
The Sui and Aptos blockchain ecosystems (both emerging from the former Diem/Meta blockchain engineering lineage mentioned in article 6.3) have adopted Narwhal/Bullshark-family architectures specifically for their high-throughput design goals, a direct, concrete continuation of the HotStuff-adjacent research lineage this phase has traced.
Is separating dissemination from ordering an idea that could apply to Phase 5's crash-fault algorithms too?
In principle yes, and it's an active area of systems research — the core insight (don't bottleneck data movement on whichever single node is currently "the leader") isn't inherently Byzantine-specific. Some of Phase 7's modern Paxos family variants (particularly the throughput-focused ones like PigPaxos and BPaxos, covered in article 7.8) explore related decoupling ideas within the crash-fault-tolerant setting.
Takeaways
- Every prior Phase 6 protocol shares a structural bottleneck: the leader/proposer's bandwidth caps system throughput because data dissemination and ordering are bundled into one role.
- Narwhal fixes this by moving transaction data through a DAG-based mempool where every validator disseminates continuously and in parallel, independent of whatever consensus is currently doing.
- Bullshark then orders the already-certified DAG with near-zero marginal overhead, since the expensive data-movement work is already amortized by Narwhal.
- This is an architectural innovation — splitting one bundled role into two specialized components — genuinely different in kind from the communication-complexity and finality-philosophy trade-offs of PBFT/HotStuff/Tendermint.
- Phase 6 closes having shown Byzantine fault tolerance demands real mechanism reinforcement (3f+1, signatures) over crash-fault tolerance, with four protocols spanning a real spread of design priorities — setting up Phase 7's return to crash-fault-tolerant modern Paxos variants, building toward QuePaxa and Meerkat in Phase 10.
References & further reading
- Danezis, Kokoris-Kogias, Sonnino & Spiegelman — Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus (2021) — the primary Narwhal reference.
- Spiegelman, Giridharan, Sonnino & Kokoris-Kogias — Bullshark: DAG BFT Protocols Made Practical (2022) — the Bullshark ordering protocol.
- cvam.sight — Consensus 6.3: HotStuff — the leader-centric communication pattern this article's separation directly addresses.
- cvam.sight — Consensus Algorithms series hub — Phase 7 (the Modern Paxos Family) picks up next.