HotStuff Data Availability and How Narwhal + Tusk Solve It
HotStuff provides fast, deterministic finality, but it still faces a data availability (DA) challenge: a leader can propose a block that other validators cannot fully retrieve. Without DA, the network can finalize a block that only the leader saw — which breaks execution and undermines safety in practice.
Narwhal + Tusk solve this by splitting the system into two layers:
- Narwhal (mempool / DA layer): reliably disseminates transaction data and produces a DAG of available batches.
- Tusk (consensus / ordering layer): orders references to that DAG rather than raw data.
This separation makes data availability explicit and avoids stalling consensus on missing data.
The HotStuff DA problem (intuitive)
In classical HotStuff, a leader proposes a block. If some validators cannot download the block data in time, they may still vote based on hashes or partial knowledge. This creates a risk: finality can be achieved without full data availability.
In practice, teams add checks (fetch proofs, gossip, size limits), but the core issue remains: ordering and data availability are tightly coupled.
Narwhal + Tusk in a nutshell
Narwhal ensures data availability by having validators broadcast transaction batches to everyone, forming a DAG of verified, available data. Tusk then runs consensus only over references to that DAG, which is much smaller and easier to order.
So the protocol does:
- Narwhal: disseminate and confirm data availability.
- Tusk: order the available data references.
- Execution: apply ordered transactions.
Example flow
- Step 1 (DA): Validator A gossips batch
B1. Others store it and include it in the DAG. - Step 2 (DA): Multiple batches from different validators form a DAG with causal links.
- Step 3 (Ordering): Tusk orders a sequence of batch references (not the full data).
- Step 4 (Execution): The execution layer fetches batches by reference and applies them in order.
If a batch is not widely available, it never becomes part of the DAG, so it never gets ordered.
Comparison table
| Responsibility | HotStuff (monolithic) | Narwhal + Tusk (separated) |
|---|---|---|
| Data availability | Implicit inside block proposal | Explicit via Narwhal DAG |
| Ordering | Block ordering inside consensus | Reference ordering by Tusk |
| Finality | HotStuff QC chain | Tusk BFT finality on references |
| Execution | After commit, uses block data | After ordering, fetch by reference |
| What this means | Risk of missing data if leader is faulty | No ordering without availability |
Takeaways
- HotStuff alone couples ordering and availability — fast but fragile under adversarial leaders.
- Narwhal + Tusk make availability explicit and order only what is available.
- This yields higher throughput, better resilience, and cleaner separation of concerns.
If you are building a high‑performance BFT chain, this separation is one of the clearest improvements over monolithic consensus designs.