SOLANA PROTOCOL ARCHITECTURE
What Changed in Solana?
Solana is transitioning from TowerBFT to Alpenglow (SIMD-0326). Explore what changed, what remained unchanged, and why next-generation applications require deeper validator state.
OLD SOLANA CONSENSUSTOWERBFT
Votes On-Chain as Transactions
Validators submitted vote transactions directly into blocks. Over 75% of total cluster transaction throughput was consumed by consensus votes.
32 Progressive Lockout Confirmations
Fork choice required accumulating progressive doubling lockout timers across 32 consecutive slot votes.
~12.8s Finality Duration
Slot was treated as a single monolithic block. Finality was only certified after 32 slot depths.
Legacy Invariant: 32 slot confirmations required for irreversible commitment
NEW SOLANA CONSENSUS (ALPENGLOW)SIMD-0326 • VOTOR
Validators Vote Directly Off-Chain
Consensus votes no longer compete with user transactions for blockspace. Zero transaction fee overhead for voting.
Aggregate BLS Notarization Certificates
Votes are aggregated off-chain into 192-byte BLS certificates. Fast path notarization triggers at 80% stake; fallback at 60%.
~150ms Target Finality (~231ms Observed)
Multiple candidate banks compete per slot. Fast leader handover redirects state dynamically via UpdateParent markers.
Alpenglow Invariant: Cryptographic certificate finalizes blocks in a single slot window
Architectural Boundary
Consensus changed. Execution did not.
Solana official documentation explicitly highlights that the Solana Virtual Machine (SVM), transaction execution rules, smart contracts, and fees remain 100% identical.
UNCHANGED (Execution Engine)
SVM (Solana Virtual Machine)BPF bytecode execution, compute units, memory limits, and instruction dispatch remain identical.
Smart Programs (dApps)Existing Anchor and native Rust programs execute with zero code changes or re-deployments.
Transactions & FeesSignature verification, account locking, priority fees, and gas mechanics remain unchanged.
CHANGED (Consensus & Ingestion Layer)
Consensus Protocol (Votor)TowerBFT 32-lockout confirmation replaced by single-slot cryptographic BLS certificates.
Bank Graph & Multiple CandidatesOne slot no longer equals one block. Multiple candidate banks exist per slot until notarized.
Fast Leader Handover (UpdateParent)Leaders optimistically switch parent blocks via SIMD-0337; infrastructure must track bank invalidations.
Infrastructure Scope
Why Normal RPC is Not Enough
Normal RPC is designed for application-level access (submitting transactions, reading balances, fetching confirmed blocks). CELOR is built to expose deeper protocol-level state required by low-latency infrastructure.
| Protocol Dimension | Standard Public RPC | CELOR Consensus Engine |
|---|---|---|
| Slot & Block Lineage | Linear confirmed slots upon cluster finality | Continuous sub-slot progression with real-time drift tracking |
| Candidate Bank Graph | UNSUPPORTED (Single block assumption) | Tracks all competing candidate banks per slot before sealing |
| Fast Handover (UpdateParent) | UNSUPPORTED (Omitted by public RPC) | Real-time invalidation detection and parent rollback tracking |
| Consensus Certificates | Commitment levels (“confirmed” / “finalized”) | Cryptographically verified BLS signatures & stake participation |
| Leader Handoff Window | getLeaderSchedule (heavy RPC roundtrip) | Cached lookahead with sub-millisecond remaining budget |
| Data Provenance | UNAVAILABLE (Blind JSON responses) | Explicit tags: DIRECT, DERIVED, INFERRED, ESTIMATED |
System Architecture
The CELOR Pipeline
UPSTREAMSOLANA VALIDATORSDevnet • Testnet • Mainnet
INGESTIONADAPTER LAYERRPC • WS • Yellowstone • Geyser
CORE CELORNORMALIZED STATERaw → Normal → Reconciled → State
PIPELINE LATENCY: 0.67µs in-memory processingDOWNSTREAM: REST • WebSocket Stream • Rust Crate • TypeScript SDK
Dynamic Cluster Detection
Active Protocol State
CURRENT SLOT—
CONSENSUS MODEALPENGLOW
OBSERVED FINALITY231ms
ALPENGLOW GENESISNONE (TOWER)
ACTIVE RPC ENDPOINT: http://127.0.0.1:8900
Execution Infrastructure
TPU QUIC Routing Engine
Real-time evaluation of cluster freshness, leader window budget, and TPU QUIC transport routing.
SAFETY GUARD: ACTIVE (DRY-RUN PROTECTED)
Routing Decision
SUBMITFRESH
Optimal window detected for direct TPU submission.
TPU QUIC Route Status
Connection State:CONNECTED
TPU QUIC Port:8003
Pre-warmed Socket:STANDBY
JSON-RPC Fallback:DISABLED
Leader Window Budget
Remaining Window:400ms
Blockhash Freshness:FRESH
Leader Freshness:FRESH
Bank State:CANONICAL