BFT Consensus Implementation Deep Dive

Learning Objectives

• Understand block proposal flow in hyperscale-rs
• Learn vote collection and QC formation
• Understand commit rules
• Trace through actual code in the BFT crate

Where BFT Lives in the Flow

In the Transaction Flow, BFT consensus corresponds to the steps where the node proposes blocks, collects votes, and forms quorum certificates (QCs). The main implementation is in the BFT crate and related types in crates/types.

Block Proposal Flow

The proposer (leader for the current round) builds a block containing transactions from the mempool, then broadcasts it. In hyperscale-rs:

• Proposal event – The BFT state machine receives a proposal (from self or network). It validates the block (structure, parent, round) and, if valid, emits actions to broadcast the block and start vote collection.
• Round and view – Proposals are tied to a round; the protocol advances rounds on timeouts or when a QC is formed. See crates/bft (or the consensus crate name in the repo) for the proposal handler.

Key files to open: look for Proposal, Propose, or similar event types and their handlers in the BFT/consensus crate.

Vote Collection and QC Formation

Validators send votes on the proposed block. When a node has collected a quorum of votes (e.g. 2f+1 of 3f+1), it can form a Quorum Certificate (QC) and use it to justify a commit or to advance the round.

• Vote message – Typically includes block hash (or block id), round, and signature. Votes are aggregated or collected in a structure that allows quorum check.
• QC – A QC is a certificate that “enough” validators voted for this block; it is stored with the block and used as the parent QC for the next proposal. Formation logic lives in the BFT crate (e.g. when vote count reaches threshold).

Cryptography: votes are usually signed (e.g. BLS); the crate may use an aggregation step to produce a single QC signature. See crates/types for Vote, QuorumCertificate, and the crypto crate for aggregation.

Commit Rules

Commit rules define when a block is considered committed (safe to execute and to build on). In HotStuff-style protocols:

• A block is committed when it has a QC, and often when there is a “linked” QC for a child block (two direct QCs in a row), or according to the specific rule in the codebase.
• Once committed, the block is applied to the execution state and the chain is extended. The BFT state machine emits actions that trigger execution or persistence.

Trace the code path from “QC formed” to “block committed” and “execution triggered” to see how hyperscale-rs ties consensus to execution.

Practical Trace

To trace through the code:

1. Start from crates/node or the top-level state machine that composes BFT.
2. Find where BFT Events are fed (e.g. Proposal, Vote, ProposalTimer).
3. Follow the handler for one round: proposal → votes → QC → commit (or timeout → next round).
4. Check crates/types for block, vote, and QC types so you can read the structures used in the flow.