Struct BankingSimulator 

pub struct BankingSimulator { /* private fields */ }

This creates a simulated environment around BankingStage to produce leader’s blocks based on recorded banking trace events (TimedTracedEvent).

At a high level, the task of BankingStage is to pack transactions into assigned, fixed-duration, leader blocks. So, there are 3 abstract inputs to simulate: blocks, time, and transactions.

In the context of simulation, the first two are simple; both are well defined.

For ancestor blocks, we first replay a certain number of blocks immediately up to target simulation leader’s slot with halt_at_slot mechanism. Ultimately freezing the ancestor block with expected and deterministic hashes. This has the added possible benefit of warming caches that may be used during simulation.

After replay, a minor tweak is applied during simulation: we forcibly override leader’s hashes as the simulated BankingStage creates them, using recorded BlockAndBankHash events. This is to provide indistinguishable sysvars to TX execution and identical TX age resolution as the simulation goes on. Otherwise, the vast majority of TX processing would differ because the simulated block’s hashes would differ than the recorded ones as block composition difference is inevitable.

As in the real environment, for PoH time we use the PohRecorder. This is simply a slot timer, external to BankingStage and thus mostly irrelevant to BankingStage performance. For wall time, we use the first BankStatus::BlockAndBankHash and SystemTime::now() to define T=0 for simulation. Then, simulation progress is timed accordingly. For context, this syncing is necessary because all trace events are recorded in UTC, not relative to poh nor to leader schedule for simplicity at recording.

Lastly, the last and most complicated input to simulate: transactions.

A closer look of the transaction load profile is below, regardless of internal banking implementation and simulation:

Due to solana’s general tx broadcast strategy of client’s submission and optional node forwarding, many transactions often arrive before the first leader slot begins. Thus, the initial leader block creation typically starts with rather large number of schedule-able transactions. Also, note that additional transactions arrive during the 4 leader slot window (roughly ~1.6 seconds).

Simulation must mimic this load pattern while being agnostic to internal banking impl as much as possible. For that agnostic objective, TracedSenders were introduced into the SigVerify stage and gossip subsystem by BankingTracer to trace all BankingPacketBatchs’ exact payload and sender’s timing with SystemTime::now() for all ChannelLabels. This deliberate tracing placement is not to be affected by any BankingStage’s internal capacity (if any) nor by its channel consumption pattern.

BankingSimulator consists of 2 phases chronologically: warm-up and on-the-fly. The 2 phases are segregated by the aforementioned T=0.

Both phases just send BankingPacketBatch in the same fashion, pretending to be SigVerifyStage/gossip from a single thread to busy loop for precise T=N at ~1us granularity.

Warm-up starts at T=-WARMUP_DURATION (~ 13 secs). As soon as warm up is initiated, we invoke BankingStage::new_num_threads() as well to simulate the pre-leader slot’s tx-buffering time.

Implementations

impl BankingSimulator

pub fn new( banking_trace_events: BankingTraceEvents, first_simulated_slot: Slot, ) -> Self

pub fn parent_slot(&self) -> Option<Slot>

pub fn start( self, genesis_config: GenesisConfig, bank_forks: Arc<RwLock<BankForks>>, blockstore: Arc<Blockstore>, block_production_method: BlockProductionMethod, ) -> Result<(), SimulateError>

pub fn event_file_name(index: usize) -> String