What Is the HotStuff Consensus Protocol, and How Does It Work?

What Is the HotStuff Consensus Protocol?

HotStuff is a BFT consensus protocol that lets a fixed group of validators agree on one final order of transactions or other commands, even if part of that group makes mistakes or intentionally sends misleading messages.

BFT stands for Byzantine Fault Tolerance. This means the protocol can handle validators that crash, don’t respond, lie, or send different messages to different participants. HotStuff makes sure the correctly working validators still follow the same version of the blockchain or shared ledger.

HotStuff works with a known validator set. So the protocol itself doesn’t decide who can become a validator, how staking is set up, or how an open crypto network selects participants. Those rules live outside HotStuff. HotStuff focuses on the question: how does this validator set safely reach agreement?

The original model assumes a validator set with n = 3f + 1 participants. Here, n is the total number of validators, and f is the maximum number of validators that are allowed to behave incorrectly or maliciously. Put simply: as long as less than a third of the validators are unreliable, the system keeps working correctly. With 4 validators, at most 1 can be unreliable. The other 3 validators can still make a safe decision together. With 7 validators, at most 2 validators can be unreliable. For a valid decision, at least 5 validators have to agree. HotStuff uses something called a quorum certificate, often shortened to QC. A QC is a compact cryptographic proof that enough validators voted for the same proposal. A quorum is the minimum amount of support needed to make a decision. In the original model, that quorum is n − f, or 2f + 1, votes.

With 4 validators, that’s 3 votes. With 7 validators, that’s 5 votes. This high bar prevents a small group of unreliable validators from approving a conflicting block on their own.

HotStuff is designed for a partially synchronous network. That means messages are allowed to be heavily delayed for a while, but the network eventually has to become stable enough again to deliver messages on time. Safety is preserved even during big delays. Progress, like finalizing new blocks, is only guaranteed once the network is stable enough.

Key Takeaways

• HotStuff is a BFT consensus protocol for a fixed group of validators.
• Validators together lock in one ordering of transactions or commands.
• A quorum certificate cryptographically proves that enough validators support the same proposal.
• The original model tolerates fewer than a third Byzantine validators.
• HotStuff stays safe during network delays, but needs a stable network for progress.

How Does the HotStuff Consensus Protocol Work?

HotStuff runs in consecutive rounds where one temporary leader coordinates a proposal and the validators vote on it. A round like this is called a view. The leader isn’t a permanent block producer, but only has a coordinating role during that specific view.

In the original Basic HotStuff variant, three voting phases are needed before a decision becomes final: prepare, pre-commit, and commit. Each phase gives validators more confidence that no conflicting proposal can be finalized.

A later practical form, Chained HotStuff, lets these phases overlap across consecutive blocks. That way, a new block can also provide proof of progress for earlier blocks at the same time. The core rules around voting, quorums, and safety stay the same.

What role do validators and the leader play?

Validators check whether the leader’s proposal is safe before they vote. They look at things like whether the proposal builds on the right earlier blocks and fits within the protocol’s safety rules. If it does, they send a digitally signed vote to the leader.

The leader collects the votes. Once the leader has enough votes, they bundle them into one QC. So instead of forwarding all individual votes every time, the leader can broadcast one compact proof showing that a quorum agreed.

Validators also use a lock. A lock is a rule that prevents a validator from later casually supporting a conflicting branch. A validator normally only votes for a proposal that extends its locked branch. An exception is possible when a QC from a higher view shows, under the safety rules, that moving forward is safe.

When a view doesn’t make progress, for example because the leader is offline, validators switch to a new view. They then send a new-view message to the next leader. This message includes their highest known prepareQC, meaning the strongest proof they know at that moment.

The new leader picks the highest received QC as the highQC. This is the starting point for a safe new proposal. A pre-known rotation can determine who the next leader is. A pacemaker, a mechanism with timeouts, makes sure validators don’t wait forever on a non-working leader.

How does the consensus process play out?

In Basic HotStuff, decision-making happens step by step through three voting phases. The description below shows how one proposal goes from start to a final decision.

1. The new leader gathers information. During a view change, the new leader receives new-view messages from a quorum of validators. The leader picks the highest QC included in those messages. This prevents the leader from proposing something that conflicts with a block that was already safely continued.

2. The leader makes a proposal. The leader builds a new block on top of the branch justified by the highQC and sends it to all validators. The proposal also includes proof of why this is the safe path forward.

3. Validators verify and vote in the prepare phase. Each validator checks whether the block meets the safety rules. If it does, the validator sends a prepare vote back to the leader.

4. The leader forms proofs for prepare and pre-commit. After 2f + 1 prepare votes, the leader creates a prepareQC and broadcasts it for the pre-commit phase. Then validators collect votes again. With another 2f + 1 votes, the leader creates a precommitQC.

5. Validators lock and commit the proposal. Validators set a lock based on the precommitQC and vote in the commit phase. The leader then bundles 2f + 1 commit votes into a commitQC. A following decide message makes the proposal executable and final.

Example: Say a group has 4 validators. A leader proposes a block. At least 3 validators must vote in every required phase before the leader can form a QC. So one faulty validator can’t force the process to finalize a different block.

Chained HotStuff makes this workflow more efficient by combining phases of different blocks. Under the three-chain commit rule, the oldest block in a sequence becomes final when three consecutive blocks are connected to each other through valid QCs according to the protocol rules. That chain provides the commit proof for the oldest relevant block.

How Does HotStuff Handle Byzantine Faults?

HotStuff limits the damage from Byzantine faults by combining a high voting threshold, signed votes, locks, and clear rules for view changes. A Byzantine validator is a validator that behaves unpredictably or maliciously, for example by lying, not responding, or sending different proposals to different validators.

The fault limit is less than a third of validators in an unweighted group. With n = 3f + 1 participants, at most f validators can be Byzantine. A QC requires 2f + 1 votes, which equals n − f.

The key result is that two quorums always overlap. With 7 validators, for example, 5 votes are needed for a QC. Two groups of 5 votes must share at least 3 validators. Since at most 2 validators can be Byzantine, there’s always at least one correct validator in that overlap.

A correct validator doesn’t vote twice for conflicting proposals in the same phase and view. Because of that, two conflicting QCs for the same phase and view can’t exist. The locks and the safeNode rule, the check that a new proposal safely builds on known proofs, also make sure validators can’t later just switch to a conflicting branch.

This protects safety. Safety here means two conflicting blocks can’t both be made final by correctly working validators. When there’s uncertainty, the network would rather wait than finalize two different histories.

Liveness is about progress: the ability to finalize new blocks. HotStuff doesn’t promise that progress during a long network partition or ongoing major delays. Once the network is stable enough again and a correct leader stays in the same view long enough, validators can form quorums again and continue.

In proof-of-stake variants, this limit is often expressed in voting weight instead of just the number of validators. Then not every validator counts the same. The safety and progress guarantees only hold as long as less than a third of the relevant voting weight is Byzantine.

What Is the HotStuff Consensus Protocol Used For?

HotStuff is used to make a group of servers or validators lock in one final ordering of commands. This is called state machine replication: multiple computers execute the same commands in the same order, so they keep the same outcome and the same shared ledger.

In a blockchain, that task can be ordering and finalizing blocks with transactions. After validators lock in the order, other parts of the network can execute the transactions and update the ledger. So HotStuff mainly determines the ordering and finality of decisions.

DiemBFT was a HotStuff-based consensus family for the historical Diem blockchain. This protocol family ordered and finalized transactions within a configurable validator group.

Aptos uses AptosBFT, a BFT consensus protocol based on Jolteon. The protocol works with stake-weighted voting power and can apply reputation-based leader selection, where validator behavior and performance influence leader choice. In that setup, validators’ voting weight can differ based on stake.

Flow uses the HotStuff consensus family and migrated in January 2023 to Jolteon. Jolteon is an optimized variant of HotStuff. So these systems don’t necessarily use the original HotStuff spec exactly as it was designed; details like leader selection and processing can differ.

What Are the Benefits of HotStuff?

A big benefit of HotStuff is that it organizes communication between validators more efficiently than protocols where everyone constantly has to communicate with everyone else.

• Compact proofs: The leader bundles validator votes using threshold signatures into one QC. Threshold signatures are combined digital signatures that prove enough validators voted. That way, a validator doesn’t need to receive every individual vote each time to verify the quorum.

• Linear communication with a correct leader: In the original model, the communication and authentication work per correct leader grows roughly with the number of validators, instead of growing much faster. This doesn’t automatically say how many transactions a full blockchain can process, because execution, storage, hardware, and transaction gossip can also be limiting.

• More efficient leader changes: HotStuff is designed to need less communication than PBFT even when a leader fails. That matters when a leader crashes or doesn’t broadcast a usable proposal.

• Pipelining in Chained HotStuff: New proposals can help finalize earlier blocks. This means the network doesn’t have to fully finish every phase in isolation before starting the next proposal.

• Deterministic finality: A committed block is final under the safety assumptions. Deterministic finality means correctly working validators can’t later accept a conflicting block as final too.

HotStuff also has optimistic responsiveness. After the network becomes stable, a correct leader doesn’t have to keep waiting for a pre-set maximum network delay if the needed messages already arrived earlier. That can improve progress under good network conditions.

What Are the Limitations of HotStuff?

HotStuff doesn’t offer unlimited protection or guaranteed progress in every situation. How it behaves depends on clear assumptions about validators, network communication, and the chosen implementation.

• Limits to fault tolerance: The formal safety analysis holds when less than a third of validators or voting weight is Byzantine. With a larger unreliable fraction, the safety and progress guarantees fall outside the model.

• No progress during a permanent partition: Safety is preserved under unlimited network delays, but HotStuff won’t necessarily finalize new blocks as long as the network stays split or unstable for a long time.

• Leader dependency: A bad, crashed, or unreachable leader can cause a view to fail. The pacemaker and leader rotation help the network recover once the synchrony assumption holds again, but they first add extra delay.

• Fixed validator set as a starting point: The original protocol assumes a known, authenticated validator set and threshold signatures. HotStuff doesn’t decide how an open network chooses validators, distributes stake, or punishes economic misbehavior.

• Multiple phases for finality: Basic HotStuff needs three voting phases before a proposal is final. Chained HotStuff boosts throughput through pipelining, but the time to finality for the first blocks and behavior during leader changes still depend on network delays, timeouts, and the implementation.

So the leader reduces how much validators have to communicate with each other, but also becomes an important temporary coordination point. That leader has to collect quorum votes in time and broadcast new proofs.

How Does HotStuff Compare to Other Consensus Protocols?

HotStuff belongs to the family of leader-based BFT protocols, but it differs in how it organizes voting, quorums, and leader changes. There’s no single ranking: protocols make different choices around validator sets, network conditions, and finality.

Compared to PBFT, HotStuff is designed to reduce communication during normal progress and during a view change. In the original comparison, HotStuff’s authenticator complexity with a correct leader and during a leader failure grows linearly with the number of validators. In the same comparison, PBFT’s load grows faster. Authenticator complexity is specifically about how much authentication info the protocol has to process, not directly about transactions per second or user latency.

Tendermint and Casper share HotStuff’s BFT approach with temporary leaders, quorums, and finality. In the original comparison, the Tendermint and Casper variants at the time had higher communication overhead. Technical optimizations, like threshold signatures, can change those costs in specific implementations.

HotStuff is clearly different from Nakamoto consensus, like Bitcoin. HotStuff works with a known validator set and can deterministically finalize committed decisions under the fault limit. Bitcoin uses a permissionless proof-of-work model where participants can freely join and finality is probabilistic. That means the chance of a rollback gets smaller as more blocks follow, instead of one moment giving absolute finality under the protocol rules.

Compared to fully asynchronous BFT protocols, HotStuff chooses partial synchrony. Because of that, the protocol can make responsive progress after the network stabilizes, but it doesn’t promise liveness during a permanent network partition.

Later variants build on HotStuff’s ideas. DiemBFTv4 adapts the approach with a two-step steady-state commit, while Flow uses Jolteon as an optimized HotStuff variant. Those derivatives can have different properties than the original protocol.

Final thoughts

HotStuff is a BFT consensus protocol that helps a fixed validator set safely lock in one ordering of transactions or commands. The temporary leader collects votes, while quorum certificates show that enough validators checked and supported the same proposal.

The combo of high voting thresholds, digital signatures, locks, and view changes prevents a small group of Byzantine validators from finalizing two conflicting blocks. HotStuff stays safe during big network delays, but it can only guarantee progress once the network is stable enough again and a correct leader stays active.

Efficient vote bundling and the option to pipeline make HotStuff an important foundation for modern BFT variants. At the same time, it’s still essential to understand that HotStuff isn’t a fully open consensus model or an economic system: validator selection, stake, and incentives are handled by the blockchain or the implementation around it.