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

  1. Memoize votes. When the Pool sees the quorum threshold (≥ 80 % stake), the node instantly builds a certificate—a BLS aggregate of those signatures.

  2. 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.

  3. 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