Why votes on-chain cost block space
TowerBFT validators vote by sending transactions to the leader. See how much block space that consumes, and why Alpenglow blocks carry zero votes.
On mainnet today roughly three quarters of all transactions are votes. This lesson shows why.
Under TowerBFT a validator votes by building a *vote transaction* (about 300 bytes) and sending it to the current leader, exactly like a user transaction. The leader packs it into the next block; only once the block is replayed does everyone count the vote.
Under Alpenglow a vote is a small packet (about 150 bytes) sent directly to every validator. It is never placed in a block.
Press Start.
Where it stops
-
A TowerBFT block packs vote transactions
-
How many votes per run?
The Metrics tab has a row "vote txs in blocks" for TowerBFT. We will run to the 8 s mark, half of this 16 s scenario. Predict first.
With 25 validators voting once per 400 ms slot, about how many vote transactions land in blocks over the full 16 s run?
- About 25
- About 100
- About 400
- About 4000
25 validators × one vote per slot × 40 slots ≈ 1000 votes cast, but each block only carries the votes that reached the leader in time, and votes for skipped or late blocks are dropped, so roughly 400 land. On mainnet with ~1300 validators this is the majority of all transactions.
-
An Alpenglow block carries no votes
What you saw
- TowerBFT votes are transactions: they wait for the leader, cost block space and fees, and are counted only after replay.
- Alpenglow votes are messages: broadcast directly, aggregated into certificates, never in a block.
- The Metrics row *vote txs in blocks* quantifies the cost for any scenario you load.
Try next
- Switch the scenario to offline-25pct and compare the vote counts.
- Lesson Skip certificates shows what Alpenglow does when the leader is missing.