Aurora BFT Consensus

Aurora BFT is Rivellum's Byzantine Fault Tolerant consensus protocol, derived from HotStuff with a three-chain commit rule.

Protocol Overview

Aurora BFT operates per-committee. Each committee manages a set of lanes and runs consensus independently.

Three-Phase Protocol

Phase 1: PROPOSE
  Leader broadcasts (batch, state_root, parent_qc) to committee

Phase 2: VOTE
  Each validator verifies the proposal:
    - Validates batch contents (signatures, nonces, fees)
    - Executes batch through Photon engine
    - Checks state root matches execution result
  If valid, signs a vote and sends to leader

Phase 3: COMMIT
  Leader collects >2/3 votes → forms Quorum Certificate (QC)
  QC is broadcast to all committee members
  Members apply state changes and advance to next view

Safety Rules

A validator only votes for proposal P in view V if:

P extends from the highest QC the validator has seen
P's view number > any previously voted view
The parent QC is valid (>2/3 signatures verify)

These rules prevent equivocation and ensure no two conflicting proposals can both reach quorum.

Quorum Certificate (QC)

A QC contains:

Batch hash
View number
State root after execution
2/3 validator signatures (Dilithium3)

QCs serve as the immutable proof of consensus for a batch.

Two-Level Finality

Level 1: Per-Lane Commit

Each lane's state is committed to its own RocksDB with an updated SMT root. This happens immediately after the committee QC.

Level 2: MetaRoot Aggregation

The MetaRoot aggregator combines all lane SMT roots into a single global root. This provides a cross-lane consistency checkpoint.

Lane 0 SMT Root ─┐
Lane 1 SMT Root ─┤
Lane 2 SMT Root ─┼──→ MetaRoot Aggregator ──→ Global Root
Lane 3 SMT Root ─┤
Lane N SMT Root ─┘

BFT Guarantees

Property	Guarantee
Safety	No two conflicting batches committed at same height (with <1/3 Byzantine)
Liveness	Progress guaranteed with >2/3 honest validators online
Finality	Immediate — no reorgs once QC is formed
Fault tolerance	Up to f < n/3 Byzantine validators per committee

View Changes

When a leader fails to produce a proposal within the timeout:

Validators send a ViewChange message with their highest QC
New leader collects >2/3 ViewChange messages
New leader proposes from the highest QC in the ViewChange set
Normal three-phase protocol resumes

Committee Threading

Committees are in-process thread groups:

1 leader thread per committee
N executor worker threads
Shared memory communication (no network overhead for intra-committee messages)
Each committee processes its assigned lanes independently

For the overall architecture, see Architecture Overview.