Visualize expected user-perceived latency from transaction send to effects visible in the proposed chain
This tool models the user-perceived latency from sending a transaction to seeing its effects in the proposed chain. The lifecycle proceeds through the following stages:
1. TX submission. The user submits a transaction to their local Aztec node.
2. P2P propagation to proposer. The node broadcasts the TX to the P2P network. It takes one P2P propagation delay for the TX to reach the current slot's proposer.
3. Waiting for the next block. The proposer builds blocks in fixed-duration sub-slots within the L2 slot. The TX must wait until the next block building window starts, since the proposer snapshots the TX pool at the beginning of each block.
4. Block execution. The proposer executes the transactions in the block. The actual execution time depends on block fill (how many and how complex the transactions are). Once done, the block proposal is broadcast to the network without waiting for the full block window to elapse.
5. P2P propagation back. The block proposal propagates back through the P2P network to the user's node (another one-way propagation delay).
6. Node re-execution. The user's node re-executes the block to update its local world state (merkle trees, nullifiers, public data). Only after this step are the transaction's effects visible in the proposed chain.
7. Slot wrap. If the TX arrives too late in the slot and misses all block building windows, it must wait for the next slot's proposer to pick it up, adding up to one full slot duration of extra latency.
Note that this models "proposed chain" visibility -- the TX effects are visible locally before checkpoint confirmation on L1 or epoch proving.