Plasma Docs
  • Introduction
    • Overview
    • Use Cases
    • Why Bitcoin
    • Roadmap
  • Architecture
    • System Overview
    • Core Features
    • Consensus
      • HotStuff
      • PlasmaBFT
      • Committee Formation
      • References
    • Execution
    • Bitcoin Bridge
    • Hardware Requirements
    • RPC-API
      • Reth Reference
    • EVM Details
  • Community
    • Official Links
Powered by GitBook
On this page
  1. Architecture
  2. Consensus

HotStuff

Before diving into PlasmaBFT, it's useful to contextualize the consensus landscape. HotStuff is a modern BFT consensus protocol that improves upon earlier designs—such as Tendermint—both theoretically and practically, and it serves as an ancestor to PlasmaBFT.

A key advantage of HotStuff is its responsiveness; by eliminating fixed timeout delays, a correct leader can drive consensus at the limit of communication latency in synchronous networks, while maintaining linear message complexity relative to the number of replicas. In contrast, other methods often rely on gossip broadcasts of votes during view changes, leading to quadratic communication complexity or worse.

HotStuff streamlines consensus by collecting votes from the committee and distributing an aggregated proof, thereby reducing overhead and maintaining both liveness and safety. These proofs, known as Quorum Certificates (QCs), are formed from signatures collected from a quorum of validators.

This cryptographic proof serves as evidence that a supermajority of validators supported a given round's proposal. Thanks to the intersection property of quorums, no two nodes can observe an equivalent quorum for two conflicting blocks unless the number of faulty replicas exceeds the consistency bound.

While these techniques significantly reduce communication complexity, there are still further improvements possible—such as pipelining and view-change adjustments—that can enhance consensus times even more.

PreviousConsensusNextPlasmaBFT

Last updated 1 month ago