Serial HotStuff vs Chained HotStuff
HotStuff is a BFT consensus family that improves on PBFT by reducing view-change complexity and enabling pipelining. Two common variants are Serial HotStuff and Chained HotStuff. They share the same safety assumptions (up to f Byzantine nodes, n >= 3f + 1) but differ in how phases are structured and how quickly the system can pipeline blocks.
Below is a clear, side-by-side comparison and a table that highlights where data availability, ordering, finality, and execution happen in each variant.
Serial HotStuff (3-phase)
Serial HotStuff follows a three-phase pipeline similar to PBFT, but the quorum certificate (QC) chain is the core safety object — it links certified blocks and preserves a single, safe history.
- Prepare: leader proposes a block, replicas vote on it.
- Pre-commit: a second round of votes confirms the proposal.
- Commit: a third round of votes finalizes the block.
This means finality requires three phases after the proposal. It is clear and robust, but it limits throughput because each block is finalized before the next one is fully confirmed.
Chained HotStuff (pipelined)
Chained HotStuff connects proposals into a chain. Each new proposal implicitly carries votes that advance the previous blocks through phases. This makes finality pipeline-friendly, and the QC chain is fundamental to both ordering and safety:
- A block becomes committed when its grandchild is formed and certified.
- The system can propose continuously, improving throughput and latency under good network conditions.
The key tradeoff is complexity in reasoning about when a block is actually final, but the performance gains are significant.
Quick comparison table
| Aspect | Serial HotStuff | Chained HotStuff |
|---|---|---|
| Data availability | At proposal + Prepare QC | At proposal + QC on each block in the chain |
| Ordering | Defined per round with a single block proposal | Defined by the chain structure (parent -> child) |
| Finality | After 3 phases (Prepare, Pre-commit, Commit) | When a block has a certified grandchild |
| Execution | After commit, deterministic and immediate | After commit, deterministic and immediate |
| What is "consensus" here? | The 3-phase vote on a single block | The chain of QCs advancing blocks through phases |
| Throughput | Lower due to phase separation | Higher due to pipelining |
| Latency (good network) | Higher (more rounds) | Lower (continuous proposals) |
Summary
- Serial HotStuff is simpler to explain and reason about, but it pays a latency and throughput cost.
- Chained HotStuff is more efficient and is the form used in modern BFT systems, but it requires careful understanding of when blocks become final.
If you are building a permissioned system that needs fast finality and higher throughput, chained HotStuff is usually the better choice. If you prioritize simplicity and auditability, serial HotStuff can be easier to reason about.