The Alpenglow Consensus Architecture
Technical analysis of Solana's fundamental consensus transition: replacement of TowerBFT with Votor, aggregate BLS12-381 certificate notarization, multi-candidate bank execution, and fast leader handovers.
Consensus Changed. Execution Did Not.
Alpenglow is exclusively a consensus replacement. It replaces TowerBFT's on-chain vote transactions and progressive 32-slot lockouts with direct off-chain validator voting and cryptographic certificates. The Solana Virtual Machine (SVM), transaction execution, program bytecode, account schemas, and priority fees remain 100% unchanged.
- ✓Consensus Engine: TowerBFT replaced by Votor
- ✓Finality Time: ~12.8s lockouts reduced to ~150ms target (231ms observed)
- ✓Validator Voting: On-chain tx voting replaced by off-chain aggregate BLS signatures
- ✓Slot Reality: Multiple candidate banks can compete per slot (SIMD-0326)
- ✓Leader Handover: Fast parent switches with state rollback (SIMD-0337)
- —Solana Virtual Machine (SVM): Bytecode execution, eBPF JIT unchanged
- —On-Chain Programs: Rust, Anchor, and C smart contracts run identically
- —Transactions & Signatures: Ed25519 user signatures, fee structures identical
- —Account Data Model: Account state storage, rent, and owner checks identical
- —Priority Fees: Compute budget program and priority pricing unchanged
Solana Improvement Documents (SIMDs)
Canonical SpecificationsAlpenglow: Fast Finality Consensus & Votor
Defines the Votor consensus algorithm replacing TowerBFT. Validators directly sign candidate banks using BLS12-381 keypairs. Aggregated signatures form cryptographically verifiable certificates:
Fast Leader Handover & UpdateParent State Invalidation
Under Alpenglow, incoming leaders do not stall waiting for the preceding leader to seal their block. A leader begins producing on speculative state and issues an UpdateParent marker if the parent fork switches:
UpdateParent marker is emitted, CELOR immediately marks candidate banks rooted in the abandoned parent as ABANDONED, rolling back all uncommitted speculative transactions without deleting historical lineage.Dynamic Slot Duration Reduction
Progressively compresses slot durations from the historic 400ms target down through 350ms, 300ms, 250ms, and targeting 200ms as validator telemetry and Turbine propagation pipelines optimize under Alpenglow.
The New Reality: Why Slot ≠ Block
In legacy Solana, developers assumed a strict 1-to-1 mapping between a slot and a block. Under Alpenglow (SIMD-0326), a slot can contain multiple competing candidate banks generated during leader handovers or fork resolution. The Agave validator assigns an internal bank_id which is strictly validator-local. Cross-cluster reconciliation requires block identity (blockhash), which CELOR indexes automatically.