--- title: 'Bullshark: DAG-Based Byzantine Fault-Tolerant Protocol' url: https://www.emergentmind.com/topics/bullshark type: topic --- # Bullshark: DAG-Based Byzantine Fault-Tolerant Protocol Searching arXiv for recent Bullshark papers and related analyses to ground the article. arxiv_search(query="Bullshark DAG BFT Narwhal consensus", max_results=10) arxiv_search(query="Bullshark DAG BFT Narwhal consensus", max_results=10) is not available in this environment. Proceeding with the supplied arXiv dataset, which already contains the relevant papers and details needed for a research-grounded article. Bullshark is a directed acyclic graph (DAG)-based Byzantine fault-tolerant ordering protocol, or Byzantine Atomic Broadcast (BAB) protocol, that operates on top of a Narwhal-style certified data-dissemination layer. Its defining architectural move is to separate dissemination and equivocation elimination from ordering: vertices are reliably disseminated first, and validators then derive a total order by locally interpreting the DAG, without sending additional consensus messages. In its original formulation, Bullshark was introduced as the first DAG-based asynchronous BAB protocol optimized for the common synchronous case, while later work provided a separate deterministic partially synchronous presentation and multiple implementation-level, analytical, and comparative extensions [2201.05677]. ## 1. Origins and position in the DAG-BFT lineage Bullshark belongs to the family of DAG-based BFT protocols that includes DAG-Rider, Tusk, and Narwhal-based designs. In this family, every validator contributes to data dissemination in parallel, and consensus is extracted from the graph structure rather than from a separate stream of vote or commit messages. Bullshark retains the “zero-overhead” property emphasized in the original work: ordering is computed from the existing DAG edges rather than by adding a distinct consensus message path [2201.05677]. The protocol is usually presented as an ordering layer over Narwhal’s certified DAG. Narwhal handles availability, anti-equivocation, and reliable dissemination, while Bullshark consumes the resulting certified sub-DAGs and outputs a total order. This split is central to Bullshark’s identity in both theoretical and implementation-oriented accounts, because it isolates the throughput-oriented data plane from the simpler ordering logic [2507.04956]. Bullshark also occupies an intermediate position on what later work describes as the leader–DAG spectrum. It preserves the throughput benefits of parallel DAG dissemination, yet introduces leader anchors and timeouts so that partial synchrony can be exploited for lower latency than fully asynchronous DAG ordering. Comparative work therefore places Bullshark between fully decoupled asynchronous DAG protocols and tightly leader-driven partially synchronous protocols [2509.15847]. Production-oriented literature treats Bullshark as more than a purely theoretical construction. The Autobahn study describes Bullshark as a state-of-the-art DAG-based BFT protocol adopted in production systems such as Sui and Aptos, while Sui-focused studies analyze a Bullshark-like or BullShark-derived implementation written in Rust [2401.10369], [2605.29910]. ## 2. System model, dissemination layer, and DAG structure The canonical Bullshark model assumes a committee of $n = 3f + 1$ validators with up to $f$ Byzantine faults, and quorums of size $2f + 1$. Partial synchrony is expressed in the Dwork-Lynch-Stockmeyer model through an unknown Global Stabilization Time (GST), after which messages between honest validators are delivered within a known bound $\Delta$ [2209.05633]. The original asynchronous formulation also uses a shared coin for fallback progress, while a later quorum-size study generalizes the validator set as $n = kf + 1$ with $k \ge 2$ to study reduced or expanded redundancy [2504.08048]. Bullshark cleanly separates equivocation elimination from committing. The generalized quorum analysis describes a reliable Byzantine broadcast black-box that disseminates vertices and guarantees agreement, integrity, and validity for delivered messages. This ensures that each validator eventually delivers the same vertex per sender per round and prevents a sender from producing two different vertices for the same round [2504.08048]. At the DAG layer, each validator creates at most one vertex per round. In the standard $n = 3f + 1$ presentation, each vertex references at least $n - f = 2f + 1$ vertices from the previous round, which yields the dense parent structure on which Bullshark’s reachability arguments rely [2209.05633]. In the generalized $n = kf + 1$ formulation, each round contains between $(k-1)f+1$ and $n$ vertices, and each vertex references at least $(k-1)f+1$ vertices from round $r-1$ [2504.08048]. Implementation analyses make the Narwhal/Bullshark split concrete. Workers receive client transactions, validate and batch them, disseminate batches, and send digests to a local primary. The primary constructs headers using payload digests and parent certificates, gathers $2f+1$ votes, forms a certificate, and exports certified vertices to Bullshark for ordering [2507.04956]. This layered workflow is a practical realization of the more abstract claim that Bullshark adds total order on top of reliable broadcast without adding consensus-layer network traffic. ## 3. Ordering logic: anchors, votes, direct commit, and indirect commit Bullshark’s ordering rule is local: DAG edges act as votes, and anchors or leaders are committed by checking reachability and quorum support within the local DAG view. The literature presents two main formulations. In the deterministic partially synchronous manuscript, even rounds have predefined leaders, whose vertices are the round anchors, and odd rounds vote for the previous even round’s anchor. An anchor $A_r$ in even round $r$ is committed if there are at least $f+1$ vertices in odd round $r+1$ that vote for it; operationally, commitment is detected when a vertex in even round $r+2$ arrives and at least $f+1$ of its parents in round $r+1$ have a path to $A_r$ [2209.05633]. Once an anchor commits, validators walk backward over earlier anchors: if a future anchor has a path to an earlier anchor, that earlier anchor is ordered before it; if there is no such path, the earlier anchor is safely skipped. The asynchronous formulation is more elaborate. Waves consist of four rounds and involve steady-state leaders, a fallback leader chosen via a shared coin, and per-validator voting types. Direct commit rules depend on type-aligned support sets of size $(k-1)f+1$: a fallback leader of wave $w-1$, the second steady-state leader of wave $w-1$, or the first steady-state leader of wave $w$ is directly committed when enough potential votes of the matching type have paths to that leader. Indirect commit then traverses backward and commits prior candidate leaders if one vote type has at least $(k-2)f+1$ votes while the other has at most $f$ votes [2504.08048]. Implementation-level Sui analyses describe yet another concrete view of the same family: a wave spans four rounds, there are two anchor leaders per wave plus a fallback leader, and a steady-state commit requires both vote thresholds and linkage across anchors. In that account, if $\mathrm{Votes}_{r+1}(A_r) \ge f+1$, $\mathrm{Votes}_{r+3}(A_{r+2}) \ge f+1$, and $\mathrm{linked}(A_r, A_{r+2})$ hold, then anchors are committed in order and all previously uncommitted vertices in their causal pasts are atomically committed as well [2507.04956]. A common invariant across these presentations is that Bullshark orders anchors and then linearizes their causal histories deterministically. This design is what allows the protocol to advertise zero consensus communication overhead: the entire commit structure is extracted from already-disseminated DAG metadata. ## 4. Quorum geometry, safety, liveness, and the role of synchrony Bullshark’s safety arguments are based on quorum intersection in the round-based DAG. In the deterministic partially synchronous account, every vertex references at least $n-f = 2f+1$ parents, and any two such parent sets intersect in at least $f+1$ elements. This intersection is used to show that if an honest party commits an anchor, every future anchor has a path to it, which in turn justifies the safe-skip rule and the agreement on total order [2209.05633]. The later quorum-size analysis sharpens this point by asking whether asynchronous Bullshark remains correct once equivocation has been removed and the committee size is reduced from $3f+1$ to $2f+1$. Let $n = kf + 1$ and $q = (k-1)f + 1$. The relevant condition is $$ 2q - n \ge f + 1. $$ For $k=3$, so $n=3f+1$ and $q=2f+1$, the intersection size is exactly $f+1$, which guarantees an honest intersection. For $k=2$, so $n=2f+1$ and $q=f+1$, the minimum intersection is only $1$, which may be Byzantine [2504.08048]. This distinction is decisive for the asynchronous instance. The paper proves that asynchronous Bullshark is safe and live for $k \ge 3$ and not safe for $k=2$, even when reliable broadcast has already eliminated equivocation. The reason is specific to Bullshark’s two-type voting and indirect-commit logic: with only $2f+1$ validators, a validator that directly commits using $f+1$ same-type votes may be observed elsewhere through at most one shared vote, leaving ambiguity about whether the leader should be interpreted as steady-state or fallback [2504.08048]. By contrast, the same study states that partially synchronous Bullshark is safe and live for all $k \ge 2$. In that formulation, the partially synchronous instance uses deterministic leaders, timeouts aligned with $\Delta$, direct commit thresholds of $f+1$, and indirect commit via causal paths, so the safety argument no longer depends on the stronger honest intersection required by the asynchronous two-type voting rules [2504.08048]. The original paper adds a further claim about the asynchronous design: safety is “post-quantum” in the sense that it relies only on information-theoretic properties of reliable broadcast and the agreement/fairness/termination properties of the coin, while computational unpredictability is needed for liveness in asynchrony rather than for safety itself [2201.05677]. ## 5. Latency, throughput, and implementation-level workflow Bullshark’s practical appeal is the combination of high throughput with comparatively simple ordering logic. The original implementation paper reports that the protocol was implemented in approximately 200 lines of code on top of Narwhal and reached 125,000 transactions per second with 2 seconds latency for a deployment of 50 parties [2201.05677]. A later implementation-level workflow analysis reports 297,000+ tx/s with approximately 2-second latency in production settings, and describes Bullshark as a round-based DAG BFT protocol over Narwhal that achieves zero-overhead consensus by ordering certified DAG metadata locally [2507.04956]. Latency analyses depend on the chosen presentation. The deterministic partially synchronous manuscript states that after GST an optimistic commit needs one odd voting round plus the next even round to collect parents, informally yielding approximately $2\Delta$ commit latency [2209.05633]. Comparative work that normalizes multiple DAG-based protocols instead reports Bullshark leader-vertex commit latency as $4\delta$ and non-leader commit as an additional $2\delta$ after GST [2509.15847]. These are distinct accounting conventions rather than a single unified metric. A recurring theme in later work is that Bullshark’s throughput comes with a latency premium. Shoal attributes this premium to two factors: bad leaders, which cause anchors to be skipped, and sparse anchors, because not every round contains an anchor. In its best-case characterization, anchors are ordered in 2 rounds, while non-anchor vertices require 3 to 4 rounds to be ordered [2306.03058]. Shoal then adds leader reputation and pipelining to reduce latency, reporting up to 40% latency reduction in failure-free executions and up to 80% reduction in executions with failures against vanilla Bullshark [2306.03058]. The Sui workflow analysis makes the implementation path explicit. Workers batch transactions and disseminate them; primaries wait for enough digests and parent certificates, create headers, gather $2f+1$ votes, form certificates, and feed the resulting sub-DAG into Bullshark. The paper reports default parameters such as header payload target $D = 32$ batches, maximum 1000 batches, maximum header delay of 1,000 ms, and garbage-collection depth of 50 rounds [2507.04956]. This suggests that Bullshark’s performance is inseparable from batching, certification, and garbage-collection policy in the Narwhal substrate, not merely from the abstract commit rule. ## 6. Extensions, critiques, and active research directions Later work treats Bullshark as a baseline, a deployment target, and a source of reusable design ideas. The following developments illustrate the breadth of that research. | Line of work | Main modification | Stated effect | |---|---|---| | Shoal | Leader reputation and pipelining | Up to 40% latency reduction failure-free; up to 80% with failures [2306.03058] | | HammerHead | Dynamic leader scheduling for a Sui Bullshark-like protocol | 2x latency reduction and up to 40% throughput increase with 100 validators, 33 faults [2309.12713] | | Sparse Bullshark | Constant-size random parent sampling | Preserves $f < n/3$ while reducing metadata and improving scalability [2506.13998] | | Agora | Multi-agent protocol bug detection on Sui’s BullShark-style codebase | Found protocol-level DAG-layer bugs, including BlockManager memory exhaustion [2605.29910] | | FairWave | Fairness-aware economic layer around DAG-BFT | Argues fairness risks arise from stake rules around Bullshark-like ordering, not from the ordering logic itself [2606.10982] | Sparse Bullshark is a particularly direct modification. It replaces the dense $n-f$ parent set with a constant-size random sample of size $D=\Omega(\lambda)$, adds a verifiable sampling proof, and raises the direct commit threshold from $f+1$ to $2f+1$. The paper states that this preserves the optimal resilience bound $f