Votor’s “Pool” Explained
When Alpenglow replaces Tower BFT, the spotlight will be on Votor’s single-round voting, but the real hero is a tiny in-memory ledger every node keeps: the Pool. Think of it as Solana’s high-speed clipboard for signatures and certificates. Below we break down why the Pool exists, what problem it solves and how it keeps finality fast without drowning the network in vote spam.
The Problem: Vote Overhead in Tower BFT
Tower requires each validator to post two on-chain vote transactions every slot.
A 400 ms slot cadence means ~4,320,000 vote TXs per validator, per day.
Those votes crowd blocks, consume bandwidth, and cost small nodes ~25 % of their gross rewards in fees.
Worse, a vote isn’t useful until enough others arrive, so the chain waits—adding seconds of latency before a block is final.
The Pool: A Local Ledger for Signatures
What it is A hash-map keyed by slot and validator pubkey. For every slot, a node stores the first valid signature it gets from each peer.
What it does
Memoize votes. When the Pool sees the quorum threshold (≥ 80 % stake), the node instantly builds a certificate—a BLS aggregate of those signatures.
Broadcast once. The certificate is sent to the network only a single time; any honest node can create it, and because the aggregated signature set is identical, every honest node produces the same byte-for-byte output.
Handle fallback rounds. If the fast path misses a few slow validators, up to three additional “fallback” certs may circulate—but never more than four unique certs per slot in total.
Net effect: votes stay off-chain, certificates move once, and bandwidth use collapses.
Why It Matters for Validators & Stakers
Benefit
How It Shows Up
Economic Outcome
Fewer packets
Vote traffic drops from millions of TX/day to a handful of certs
Lower bandwidth and disk I/O bills
Faster finality
Nodes can commit as soon as their Pool reaches quorum
More priority-tip bidding → higher validator & staker yield
Deterministic data
Certs are byte-identical, so no replay storms
Zero risk of “vote-spam” griefing
Resilience
Any honest node can forge the cert; leader failures are non-events
Lower orphan rate, steadier staking APY
Operational Checklist
Memory footprint: The Pool stores at most one signature per validator per slot : kilobytes, not megabytes.
Gossip logic: Broadcast each new cert exactly once, ignore duplicates.
Fallback handling: Track up to three slower-quorum certs, then prune.
Upgrade path: Pool logic ships with the Alpenglow binary; no external DB required.
Toby’s View
The Pool collapses the vote fire-hose into a trickle, freeing up bandwidth for MEV bundles and real user traffic, exactly the scenarios Toby’s validator optimiser is built for. Less noise, faster commitment and richer fee flow translate into stronger yields for stakers who delegate to well-tuned nodes.
Last updated