Skip to content
Blockchain LabTHE VENTURE STUDIO

LibraryConsensus2022Design paperCorpus record

Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus

Narwhal and Tusk. George Danezis, Lefteris Kokoris-Kogias, Alberto Sonnino and Alexander Spiegelman.

Split the mempool from the consensus. Narwhal is a DAG of certified batches. Tusk picks a leader inside that DAG. Later Sui consensus descends from this split. The paper is not a Sui status report.

Narwhal certifies batches of transactions in a DAG before anyone orders them. Tusk then picks an anchor in that DAG. Consensus messages stay small because the bytes were already witnessed.

The five-minute read

The mempool is the DAG

Validators keep publishing batches that point at earlier batches. A quorum signs a certificate that the batch is stored. The certificate, not the batch, is what consensus has to talk about.

Fetch from any signer

If the author goes quiet, a node that holds the certificate can ask another signer for the bytes. Availability is a quorum property, not a favour from the leader.

Tusk commits an anchor

A random coin selects which certified block is the anchor of a round. The commit walks the causal history of that anchor. The coin is there so a bad leader cannot freeze the choice.

Later systems split again

Bullshark replaces the coin with a different commit. Sui's production consensus moved further. The paper is the separation of data and order, not those clients.

One action, walked through

  1. A validator packs transactions into a batch, includes hashes of earlier certificates, and asks peers to sign.
  2. A certificate forms when a quorum has signed. The batch is now referenced by a small object.
  3. Validators stream certificates to each other and keep the DAG.
  4. Tusk uses shared randomness to pick an anchor among certified blocks of a round.
  5. The ordered log is the causal past of successive anchors, with duplicates removed.

The argument, unpacked

Throughput was stuck behind the leader's bandwidth

HotStuff-style leaders were re-shipping the block. Narwhal's claim is that once a quorum has stored the batch, ordering it is a metadata problem. A system that still puts the full block inside the consensus vote has not taken the split.

Certificates are not execution

A certified batch can still contain a transaction the application will reject. The DAG proves the bytes were available to the quorum. Interpretation is later.

What has to be true

  • A quorum of validators stores what they sign and will serve it later.
  • Fewer than one third are Byzantine, so certificates cannot be forged and unavailable batches cannot both be certified and withheld from all honest nodes.
  • The random coin is unpredictable to the adversary before the round is fixed. A grindable coin restores leader control.
  • Nodes actually fetch missing batches. A certificate without a fetch path is a pointer into a void.

What happened after the paper

The Narwhal mempool and the Tusk commit rule were implemented in research prototypes and then revised. Sui in particular moved through Bullshark and later Mysticeti. When a team says Narwhal, ask whether they mean the certified DAG, the random-coin commit, or a descendant that kept only the DAG.

What to check before you use the idea

  • Are consensus messages certificates or full blocks?
  • Who will serve the bytes if the author is offline?
  • How is the anchor chosen, and can a leader grind it?
  • Which later commit rule does the live system actually run?

Terms

Certificate
A quorum signature on a batch, used as a name for bytes that are supposed to be stored.
Anchor
The certified block a round commits. Its causal history is what gets ordered.

The problem the paper names

Classic BFT leaders re-send the bulk data. Narwhal's claim is that availability of batches can be certified by quorum before anyone orders them, so consensus messages stay small.

What the design proposes

  • Each validator publishes batches that reference earlier batches, and collects a certificate.
  • A missing batch can be fetched from any replica that signed, not only the author.
  • Consensus then orders certificates, not raw transactions.

How the mechanism is specified

  • The DAG already contains the causal history. A commit walks that history.
  • Throughput scales with how fast certificates can be stored and fetched.
  • Tusk uses a random coin so the commit does not wait on a leader timeout in the same way HotStuff does.

What this page does not treat as proven

  • A certificate proves availability to the quorum that signed. It does not prove every full node has the bytes yet.
  • Bullshark, Mysticeti, and production Sui changed the commit rule. Do not describe them as this PDF.
  • The mempool can still be censored by a quorum that refuses to sign a validator's batches.

Why a venture studio still reads it

When someone shows a DAG consensus diagram, ask whether the data plane and the ordering plane are actually separate, and who you call when a certificate points at bytes you cannot fetch.

This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.

Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.