Standalone HotStuff: Key Events, Variables, and Guarantees

Standalone HotStuff is the core HotStuff consensus protocol without extra layers (like execution engines or blockchain-specific tooling). It is leader‑based, Byzantine fault tolerant (BFT), and designed to be safe under asynchrony and live under partial synchrony.

This writeup explains the key events, variables, and state transitions that make HotStuff work: QC, highQC, lockedQC, lockedRound, finality rules, data availability, and execution timing.

Mental model

HotStuff advances in rounds. Each round has a leader who proposes a block. Replicas vote; votes aggregate into a Quorum Certificate (QC). The protocol always builds on the highest known QC (highQC) to preserve safety. Finality happens when the protocol forms a certified chain that proves consistent history.

Core variables (what each node tracks)

• QC (Quorum Certificate): a signed proof that 2f + 1 replicas voted for a block in a specific round.
• highQC: the highest‑round QC the node knows. This is the preferred parent for new proposals.
• lockedQC: the highest QC the node is currently locked on. A node will not vote for proposals that conflict with this lock (unless it sees a higher safe QC).
• lockedRound: the round number associated with lockedQC. This makes the lock explicit.
• commitQC (implicit): when a block has a certified grandchild, the block is committed (final).

These variables define the safety and liveness logic.

Key events in a round

1. Leader proposal

   • Leader proposes a block B that extends highQC.
   • The proposal includes QC for the parent (this is the proof of safety).

2. Vote (Prepare / Pre‑commit / Commit phases)

   • Nodes validate the proposal (parent QC, round number, safety rules).
   • If safe, they vote for B.
   • Votes are aggregated into a QC for B.

3. QC formation

   • Once 2f + 1 votes are collected, a QC for B is created.
   • Each node updates highQC if this QC is higher.

4. Lock update

   • A node updates lockedQC when it sees a QC for a block that is safe to lock.
   • lockedRound becomes the round of that block.

5. Commit (finality)

   • If a block X has a certified grandchild, then X is committed.
   • This gives deterministic finality for X and its ancestors.

Safety rules (why forks do not finalize)

• Extend highQC: proposals must extend the highest known QC.
• Respect locks: a node only votes for a block that is either:
  • on the chain of lockedQC, or
  • carries a QC with a round higher than lockedRound.

This ensures a node cannot help two conflicting histories both reach finality.

Liveness rules (how the system makes progress)

• Partial synchrony: once the network stabilizes, leaders can gather votes in time.
• View change / round change: if the leader is faulty, timeouts trigger the next round, and the next leader proposes using the newest highQC.

Data availability

Data availability is enforced by proposal + QC:

• A block is considered available when it is proposed and enough replicas have seen it to form a QC.
• If data is missing, replicas withhold votes, so a QC cannot form.

This keeps the system from finalizing data that only the leader saw.

Finality and execution

• Finality: deterministic. A block is final once it has a certified grandchild.
• Execution: happens after commit. The execution layer consumes the committed chain in order.

This separation is important: HotStuff decides ordering, the execution engine applies state changes.

Serial vs chained (standalone perspective)

Standalone HotStuff is often presented in chained form:

• Serial: 3 explicit phases per block.
• Chained: phases are pipelined, and finality happens when a grandchild is certified.

In both, the QC chain is the fundamental safety object, and highQC is the anchor for safe proposals.

Summary

Standalone HotStuff is built around three ideas:

• QC chain safety: QCs link certified blocks and prevent conflicting finality.
• highQC leadership: leaders always build on the highest certified block.
• Locks: lockedQC and lockedRound prevent unsafe votes.

With these variables and events, HotStuff provides deterministic finality and strong Byzantine fault tolerance while enabling efficient pipelining under stable network conditions.