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). Hyperliquid's docs call it "a variant of HotStuff consensus". The code is closed source and the docs give no validator count or finality figure; they report end-to-end latency for a co-located client placing an order of median 0.2 s, p99 0.9 s.
• Why single-leader at all? Throughput. A single leader orders transactions without the coordination overhead multi-leader designs need. 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's docs say its mainnet "currently supports approximately 200k orders/sec", with a median end-to-end latency of 0.2 s for a co-located client. 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's design isn't published beyond "a variant of HotStuff"; the latency figures in Hyperliquid's docs suggest it is tuned for low-latency orderbook trading.

🔍 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 docs give some details:

• HotStuff-derived: "Hyperliquid is secured by HyperBFT, a variant of HotStuff consensus" (HyperCore overview)
• Stake-weighted validator set: a quorum is any set of validators with more than ⅔ of stake; a validator needs 10k HYPE self-delegation to become active; the set changes in epochs of 100k rounds (staking). No fixed validator count is given.
• Latency, not a finality number: for a co-located client placing an order, end-to-end latency has median 0.2 s and p99 0.9 s; mainnet supports ~200k orders/sec and "the current bottleneck is execution"
• No automatic slashing: "There is currently no automatic slashing implemented"; a quorum of jail votes can remove a validator from consensus instead (staking)
• EVM integration: "The HyperEVM is not a separate chain, but rather, secured by the same HyperBFT consensus as HyperCore" (HyperEVM)

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?)

Tempo's node is open source. Its README says it uses Simplex consensus via Commonware, with "sub‑second finality in normal conditions", and its consensus crate describes itself as "a Tempo node using commonware's threshold simplex as consensus" (crates/consensus/src/lib.rs). Simplex is neither HotStuff nor Tendermint, but it is in the same classical-BFT family: a leader per view and ≥ 2/3 quorums.

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 is secured by the same HyperBFT consensus as HyperCore

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 docs: HyperCore overview — 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) = a HotStuff variant per its docs; closed source, no published validator count; co-located order latency median 0.2 s. 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.