Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

Fast-HotStuff: A Fast and Resilient HotStuff Protocol

Mohammad M. Jalalzai, Jianyu Niu, Chen Feng, Fangyu Gai

TL;DR

Fast-HotStuff addresses the primary bottlenecks of HotStuff by introducing a two-round, rotating-primary BFT that requires a block to prove extension of the latest highQC, enabling two-round optimistic commits and improved responsiveness. The protocol combines basic and pipelined variants with AggQC/ highQC mechanisms to reduce view-change cost and fork-related inefficiencies, while maintaining safety and liveness through formal proofs. Empirical evaluation on AWS across up to $n=160$ replicas shows that Fast-HotStuff achieves lower latency than HotStuff in typical operation and remains robust under forking attacks, with only modest overhead when a primary fails. Overall, the work demonstrates a practical, fork-resilient two-chain consensus that sustains high performance in both LAN and WAN environments, offering a significant improvement for rotating-primary BFT in blockchain-like systems.

Abstract

The HotStuff protocol is a breakthrough in Byzantine Fault Tolerant (BFT) consensus that enjoys both responsiveness and linear view change. It creatively adds an additional round to classic BFT protocols (like PBFT) using two rounds. This brings us to an interesting question: Is this additional round really necessary in practice? In this paper, we answer this question by designing a new two-round BFT protocol called Fast-HotStuff, which enjoys responsiveness and efficient view change that is comparable to linear view change in terms of performance. Compared to (three-round) HotStuff, Fast-HotStuff has lower latency and is more robust against performance attacks that HotStuff is susceptible to.

Fast-HotStuff: A Fast and Resilient HotStuff Protocol

TL;DR

Fast-HotStuff addresses the primary bottlenecks of HotStuff by introducing a two-round, rotating-primary BFT that requires a block to prove extension of the latest highQC, enabling two-round optimistic commits and improved responsiveness. The protocol combines basic and pipelined variants with AggQC/ highQC mechanisms to reduce view-change cost and fork-related inefficiencies, while maintaining safety and liveness through formal proofs. Empirical evaluation on AWS across up to replicas shows that Fast-HotStuff achieves lower latency than HotStuff in typical operation and remains robust under forking attacks, with only modest overhead when a primary fails. Overall, the work demonstrates a practical, fork-resilient two-chain consensus that sustains high performance in both LAN and WAN environments, offering a significant improvement for rotating-primary BFT in blockchain-like systems.

Abstract

The HotStuff protocol is a breakthrough in Byzantine Fault Tolerant (BFT) consensus that enjoys both responsiveness and linear view change. It creatively adds an additional round to classic BFT protocols (like PBFT) using two rounds. This brings us to an interesting question: Is this additional round really necessary in practice? In this paper, we answer this question by designing a new two-round BFT protocol called Fast-HotStuff, which enjoys responsiveness and efficient view change that is comparable to linear view change in terms of performance. Compared to (three-round) HotStuff, Fast-HotStuff has lower latency and is more robust against performance attacks that HotStuff is susceptible to.

Paper Structure

This paper contains 19 sections, 7 theorems, 15 figures, 1 table, 3 algorithms.

Table of Contents

  1. Introduction
  2. System Model and Preliminaries
  3. System Model
  4. Preliminaries
  5. HotStuff in a nutshell
  6. Limitations of HotStuff
  7. Higher Latency During Happy Path
  8. Forking Attack
  9. Fast-HotStuff
  10. Basic Fast-HotStuff
  11. Pipelined Fast-HotStuff
  12. Proof of Correctness for HotStuff
  13. Correctness Proof for Basic Fast-HotStuff
  14. Correctness Proof for Pipelined Fast-HotStuff
  15. Evaluation
  16. ...and 4 more sections

Key Result

Lemma 1

If any two valid $QC$s, $qc_1$ and $qc_2$ with same type $qc_1.type=qc_2.type$ and conflicting blocks i.e., $qc_1.block=B$ conflicts with $qc_2.block=B'$, then we have $qc_1.viewNumber \neq qc_2.viewNumber$.

Figures (15)

  • Figure 1: The primary of the round $r+3$ performs the forking attack.
  • Figure 1: Comparison of BFT Protocols
  • Figure 2: A simple case of conflicting blocks. Block $B_v$ is a fork vertex, and blocks $B_{v+1}$ and $B_{v+2}$ are two conflicting blocks.
  • Figure 3: The chain structure of pipelined HotStuff. Curved arrows denote the Quorum certificate references.
  • Figure 4: Forking attack by the primary of the view v+3.
  • ...and 10 more figures

Theorems & Definitions (16)

  • Definition 1: Safety
  • Definition 2: Liveness
  • Lemma 1
  • proof
  • Lemma 2
  • proof
  • Lemma 3
  • proof
  • Lemma 4
  • proof
  • ...and 6 more