Skip to content

LibraryConsensus2022Design paperCorpus record

Bullshark: DAG BFT Protocols Made Practical

Bullshark. Alexander Spiegelman, Neil Giridharan, Alberto Sonnino and Lefteris Kokoris-Kogias.

DAG-Rider is built for asynchrony and pays for it on the common path. Bullshark keeps a DAG and a local commit rule, but adds a fast path for when the network is timely. The paper also writes down a simpler partially synchronous version.

Bullshark keeps DAG-Rider's local ordering and adds a fast path for when the network is timely. A partially synchronous version in the same paper is the one the authors treat as small enough to implement. Safety remains a one-third quorum argument. A benchmark in the paper is not a service level.

The five-minute read

The common case was the complaint

DAG-Rider waits out asynchrony. Bullshark commits faster when messages arrive on time, and keeps an asynchronous fallback in the full protocol.

Two protocols, one paper

The asynchronous Bullshark and the partially synchronous Bullshark are both specified. Citing the name without saying which one is incomplete.

Still a DAG

The fast path does not go back to a single leader broadcasting a classical block. Vertices, rounds and quorum references stay.

The number is an experiment

The paper describes a deployment of about fifty parties and a throughput it measured. That is evidence about that implementation, on that day, in that setup.

One action, walked through

  1. Replicas build a round DAG by quoting a quorum of prior vertices.
  2. On the synchronous path, a commit rule fires after fewer rounds than the asynchronous fallback.
  3. The committed vertex drags its causal history into the total order.
  4. Garbage collection drops history the commit rule can no longer need.
  5. If the network stops being timely, the asynchronous rule is what the full protocol relies on for liveness.

The argument, unpacked

Practical means specified

The authors' claim is that the partially synchronous protocol is short relative to its predecessors. Short is not the same as production-ready. Clients, mempools and membership are still outside the PDF.

Fairness was traded

The paper is explicit that fairness under asynchrony is not DAG-Rider's fairness. A summary that keeps the fast path and the fairness sentence has misread it.

What has to be true

  • A known committee and the usual one-third bound.
  • For the fast path, periods when the network delivers on time.
  • The benchmark's hardware, batching and transaction size are not yours unless you reproduced them.
  • Garbage collection must match the commit rule. Deleting a vertex the rule might need is a safety bug the paper is warning you not to invent.

What happened after the paper

Bullshark is the citation when a system says its DAG consensus is practical. Ask which of the two protocols it implemented, and do not let a 2022 experiment become a current capacity claim.

What to check before you use the idea

  • Asynchronous Bullshark or the partially synchronous version?
  • How many rounds does the fast path need?
  • Is a throughput figure tied to the paper's experiment or to a live chain?
  • What is deleted by garbage collection, and why is that safe?

Terms

Fast path
The shorter commit rule Bullshark uses when the network is behaving synchronously.
Causal history
The vertices a committed vertex can reach, which become part of the ordered output.

The problem the paper names

An asynchronous protocol that is optimal in the worst case can still be slow on an ordinary day. The paper wants the worst-case properties without making the common case wait for them.

What the design proposes

  • Vertices still form a round DAG by quoting a quorum of the previous round.
  • Under synchrony, a commit can happen on a shorter path than the asynchronous fallback.
  • The partially synchronous variant drops the asynchronous machinery and is offered as the implementation-sized protocol.

How the mechanism is specified

  • Safety stays with the quorum intersection. The fast path does not shrink the one-third bound.
  • The paper reports an implementation figure for a 50-party deployment. That figure is an experiment in the paper, not a live network's capacity.
  • Garbage collection is part of making the DAG practical. An unbounded DAG is not a product.

What this page does not treat as proven

  • A reported transactions-per-second number in a paper is not a service level.
  • The committee is known. Later chains that cite Bullshark still have to say how validators are chosen.
  • Fairness during asynchrony is weaker than DAG-Rider's. The paper says so.

Why a venture studio still reads it

Separate the experiment from the rule. The rule is a DAG plus a commit path. The experiment is one deployment. A venture that quotes only the number has not named the rule.

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.