Lesson 4 — HotStuff and HyperBFT — the single-leader BFT family

Question

HotStuff is the production single-leader BFT protocol; HyperBFT (Hyperliquid) is a HotStuff-inspired variant. The single-leader design enables sub-second finality but assumes a smaller validator set. Read both.

Principle (minimum model)

• HotStuff = leader-driven BFT with pipelined voting. A single leader proposes; validators vote in three phases (prepare + pre-commit + commit). Pipelined → one block per slot.
• Three-phase voting. Prepare = "I would commit this if more vote" → Pre-commit = "I have evidence > 2/3 would commit" → Commit = "block is final".
• Pipelining. Phase n+1's votes carry phase n's outcome → one phase per slot → one block per slot. Without pipelining, three slots per block.
• Leader rotation. Round-robin or stake-weighted. Bad leader → next leader steps in after a timeout. The round-change protocol is the complex part.
• HyperBFT (Hyperliquid). A HotStuff-inspired BFT customised for perp UX. Single leader + 21 validators + sub-100ms finality. Trade-off: smaller validator set, less decentralised.
• Why single-leader at all? Throughput. A single leader can order ~1000+ tx/s; multi-leader requires coordination overhead. For high-frequency apps (perps, payments), single-leader is the right answer.
• Trade-offs. Single-leader = fast + simple, but the leader is a censorship vector + DDoS target. Round-change protocol mitigates but adds complexity.

Worked example + steps

HotStuff and HyperBFT — the single-leader BFT family

Hyperliquid does ~200,000 perp trades per second with sub-second finality. The consensus under that is HyperBFT — and HyperBFT isn't an exotic new design. It's a HotStuff variant. HotStuff (2018) is itself a descendant of PBFT (1999), and the whole family is what nearly every modern non-Ethereum L1 picks when it needs instant finality.

Hyperliquid hasn't open-sourced HyperBFT. But HotStuff is published, and reading it is the closest reference you have to what's actually running under HYPE.

1. PBFT — the parent

Castro & Liskov (1999). The protocol everyone learned from. Three rounds:

Round 1 (Pre-prepare): Leader → all validators: "Block B"
Round 2 (Prepare):     All → all: "I voted for B"
Round 3 (Commit):      All → all: "I'm ready to commit B"

After round 3, validators commit. Three round-trips × n² messages (because round 2 and 3 are all-to-all) = n² total.

For n = 100, that's 10,000 messages per block. For n = 1,000, that's 1 million messages per block. It doesn't scale.

2. HotStuff — the breakthrough

Yin, Malkhi, Reiter, Gueta, Abraham (VMware, 2018). Two innovations:

2.1 Threshold signatures

Instead of every validator sending their signature to everyone, use threshold cryptography (a signature scheme — typically BLS — where partial signatures from k different signers can be mathematically combined into one short signature that verifies as "k of them signed"):

• 2f+1 validators each produce a partial signature
• The partials combine into one aggregated signature of size O(1) — same byte count whether it represents 4 signers or 400
• The leader broadcasts just the aggregate, not n individual signatures

This collapses n²→n communication. The leader fans out a single aggregated signature; validators don't need to talk to each other.

2.2 Pipelined commits

Combine "Prepare" and "Commit" into a single pipeline. A new block goes through phases, but multiple blocks are in different phases simultaneously:

Block N:   Propose → Vote → Commit
Block N+1:           Propose → Vote → Commit
Block N+2:                     Propose → Vote → Commit

Throughput becomes 1 commit per block-time, not 1 commit per 3-block-times.

After the propose phase, if 2f+1 validators don't vote yes, the next leader takes over with a view change. The bad proposal is dropped. Liveness recovers in one extra round.

3. The HotStuff variants

The family has evolved:

The pattern: each variant optimizes for a specific deployment. HyperBFT appears to optimize for: low-latency single-region validator cluster, hot-path optimized for orderbook trades.

🔍 Find in research. Search arXiv for "HotStuff" and look at the 2020+ variants. Each adds a specific optimization. What does each optimize for? This is your map of the design space.

4. HyperBFT — what's public

Hyperliquid's whitepaper and tech blog give some details:

• HotStuff-derived: explicitly mentioned
• ~20-25 validators: bounded committee
• Sub-second finality: 1 round-trip in practice
• EVM integration: HyperEVM runs in parallel with orderbook, both committed by the same consensus

What's not public (and you need to infer):

• Exact pipelining depth
• Leader rotation policy (round-robin, stake-weighted, randomized?)
• View change details
• Network optimization (custom transport? batching?)

For Tempo (Paradigm) we don't have a whitepaper yet, but the family is almost certainly the same (HotStuff or Tendermint family — they're cousins).

5. The HotStuff invariants you must understand

Three properties make HotStuff work:

5.1 Quorum certificates (QCs)

A QC is "proof that 2f+1 validators voted for block B". It's a single aggregated signature. Cheap to verify.

Every commit is backed by a QC. If you see a block with a valid QC, you know 2f+1 validators agreed.

5.2 View numbers

The protocol runs in views. View k has a designated leader. If the leader is Byzantine or unreachable, view changes to k+1 (new leader). Each view has its own QC chain.

5.3 Locks

Once 2f+1 validators "lock" on a block (vote in phase 2), the next leader must include that block — or prove it can't (via a higher QC). This prevents safety violations during view changes.

6. The Hyperliquid context — why HotStuff specifically

Hyperliquid is a perp DEX. Their consensus design serves:

• High orderbook update rate: validators must agree on the orderbook state, which changes every block
• Low latency: traders want <1s confirmation
• Bounded validator set: high throughput requires few, fast validators
• EVM coexistence: HyperEVM runs alongside, same finality guarantees

HotStuff fits because:

• Bounded committee enables low-latency
• QCs are cheap to verify (orderbook code can validate inclusion fast)
• Pipelining = high throughput

Compare with Tendermint: Tendermint is simpler but doesn't pipeline as aggressively. HotStuff wins on throughput.

7. Practice

For each chain, identify the consensus family and one design choice:

1. Hyperliquid (HotStuff-derived) — bounded validator set for latency
2. Aptos (Aptos-BFT, HotStuff-derived) — DAG-based mempool for throughput
3. Sui (Bullshark + Narwhal, DAG-based) — separates ordering from execution
4. Cosmos Hub (Tendermint) — simpler, lower throughput than HotStuff
5. Solana (PoH + Tower BFT) — clock-based, sequence-driven (different family)

8. Reading list

• HotStuff paper — the original 2018
• Hyperliquid whitepaper — what's public
• DiemBFT spec — the production HotStuff variant (defunct project but public docs)

Final check: in one sentence, what makes HotStuff superior to PBFT for chains like Hyperliquid? If your answer is just "faster," go deeper — name the specific structural change. Reference §2 if needed.

Summary (3 lines)

• HotStuff = leader-driven BFT with three-phase pipelined voting (prepare / pre-commit / commit). One block per slot.
• HyperBFT (Hyperliquid) = HotStuff-inspired, 21 validators, sub-100ms finality. Single-leader trades decentralisation for speed.
• Single-leader is right for high-throughput apps (perps, payments). Round-change protocol handles bad leaders. Next: read Reth's Consensus trait.