docs(fast-inbox): sweep remaining inboxLag and inHash references (A-1388)

spalladino · spalladino · commit 01b921a7a9be · 2026-07-19T12:35:02.000-03:00
Removes the dead AZTEC_INBOX_LAG entries from the spartan environment
profiles and the governance-upgrade tutorial, rewrites the validator and
sequencer README sections that still described the legacy inHash flow, and
drops e2e comments that still explained fixture settings in terms of the
deleted inboxLag / L1ToL2MessagesNotReadyError behavior. Versioned docs
snapshots are left untouched.
diff --git a/docs/docs-developers/docs/tutorials/testing_governance_rollup_upgrade.md b/docs/docs-developers/docs/tutorials/testing_governance_rollup_upgrade.md
@@ -107,7 +107,6 @@ export AZTEC_EPOCH_DURATION=16
 export AZTEC_TARGET_COMMITTEE_SIZE=48
 export AZTEC_LAG_IN_EPOCHS_FOR_VALIDATOR_SET=2
 export AZTEC_LAG_IN_EPOCHS_FOR_RANDAO=2
-export AZTEC_INBOX_LAG=2
 export AZTEC_PROOF_SUBMISSION_EPOCHS=2
 export AZTEC_LOCAL_EJECTION_THRESHOLD=0
 export AZTEC_SLASHING_ROUND_SIZE_IN_EPOCHS=1
diff --git a/spartan/environments/bench-10tps.env b/spartan/environments/bench-10tps.env
@@ -18,7 +18,6 @@ AZTEC_SLOT_DURATION=72
 AZTEC_PROOF_SUBMISSION_EPOCHS=2
 AZTEC_LAG_IN_EPOCHS_FOR_VALIDATOR_SET=1
 AZTEC_LAG_IN_EPOCHS_FOR_RANDAO=1
-AZTEC_INBOX_LAG=2
 
 # 2B mana target - good for about ~800 txs at 2.5M mana each
 AZTEC_MANA_TARGET=2000000000
diff --git a/spartan/environments/bench-inclusion-sweep.env b/spartan/environments/bench-inclusion-sweep.env
@@ -19,7 +19,6 @@ AZTEC_SLOT_DURATION=72
 AZTEC_PROOF_SUBMISSION_EPOCHS=100
 AZTEC_LAG_IN_EPOCHS_FOR_VALIDATOR_SET=1
 AZTEC_LAG_IN_EPOCHS_FOR_RANDAO=1
-AZTEC_INBOX_LAG=2
 
 AZTEC_MANA_TARGET=2000000000
 
diff --git a/spartan/environments/next-net.env b/spartan/environments/next-net.env
@@ -39,7 +39,6 @@ SEQ_MAX_TX_PER_CHECKPOINT=12
 SEQ_BUILD_CHECKPOINT_IF_EMPTY=true
 SEQ_BLOCK_DURATION_MS=5500
 
-AZTEC_INBOX_LAG=2
 
 VALIDATOR_REPLICAS=2
 VALIDATORS_PER_NODE=24
diff --git a/spartan/environments/next-scenario.env b/spartan/environments/next-scenario.env
@@ -7,7 +7,6 @@ DESTROY_ETH_DEVNET=true
 CREATE_ETH_DEVNET=true
 AZTEC_EPOCH_DURATION=32
 AZTEC_SLOT_DURATION=36
-AZTEC_INBOX_LAG=2
 ETHEREUM_CHAIN_ID=1337
 LABS_INFRA_MNEMONIC="test test test test test test test test test test test junk"
 FUNDING_PRIVATE_KEY="0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80"
diff --git a/spartan/environments/staging-internal.env b/spartan/environments/staging-internal.env
@@ -36,7 +36,6 @@ SPONSORED_FPC=false
 # Rollup
 AZTEC_LAG_IN_EPOCHS_FOR_VALIDATOR_SET=2
 AZTEC_LAG_IN_EPOCHS_FOR_RANDAO=2
-AZTEC_INBOX_LAG=2
 AZTEC_MANA_TARGET=75000000
 AZTEC_PROVING_COST_PER_MANA=12500000
 
diff --git a/spartan/environments/staging-public.env b/spartan/environments/staging-public.env
@@ -36,7 +36,6 @@ SPONSORED_FPC=false
 # Rollup
 AZTEC_LAG_IN_EPOCHS_FOR_VALIDATOR_SET=2
 AZTEC_LAG_IN_EPOCHS_FOR_RANDAO=2
-AZTEC_INBOX_LAG=2
 AZTEC_MANA_TARGET=75000000
 AZTEC_PROVING_COST_PER_MANA=12500000
 
diff --git a/yarn-project/end-to-end/src/fixtures/fixtures.ts b/yarn-project/end-to-end/src/fixtures/fixtures.ts
@@ -28,8 +28,6 @@ export const PIPELINED_FEE_PADDING = 30;
  *
  * The preset runs the production Sequencer with the always-enforced timetable at real (wall-clock)
  * timing, yielding exactly 2 blocks per slot. It sets:
- * - `inboxLag: 2` so the sequencer sources L1->L2 messages from checkpoint N-1 (already sealed),
- *   avoiding `L1ToL2MessagesNotReadyError` when building for slot N during slot N-1.
  * - `minTxsPerBlock: 0` so empty checkpoints land even when a tx arrives late in the build window
  *   (otherwise the chain stalls on alternating slots).
  * - `aztecSlotDuration: 12` / `ethereumSlotDuration: 4` so the pipelined cycle fits inside the
diff --git a/yarn-project/end-to-end/src/multi-node/governance/add_rollup.test.ts b/yarn-project/end-to-end/src/multi-node/governance/add_rollup.test.ts
@@ -88,10 +88,8 @@ describe('multi-node/governance/add_rollup', () => {
       aztecTargetCommitteeSize: NUM_VALIDATORS,
       governanceProposerRoundSize: 10,
       // Allow validators to build empty checkpoints so the chain keeps advancing while we wait for
-      // L1->L2 messages to land in the next checkpoint's inbox tree.
+      // L1->L2 messages to be consumed from the streaming Inbox.
       minTxsPerBlock: 0,
-      // inboxLag: 2 sources L1->L2 messages from an already-sealed checkpoint under pipelining, avoiding
-      // L1ToL2MessagesNotReadyError.
       // Fund the bridging accounts (and the sponsored FPC) at genesis. Skip the hardcoded-account
       // fast-path so our additionallyFundedAccounts are not clobbered.
       skipHardcodedAccount: true,
diff --git a/yarn-project/end-to-end/src/p2p/fee_asset_price_oracle_gossip.test.ts b/yarn-project/end-to-end/src/p2p/fee_asset_price_oracle_gossip.test.ts
@@ -46,8 +46,6 @@ describe('e2e_p2p_network', () => {
         slashingRoundSizeInEpochs: 2,
         slashingQuorum: 5,
         listenAddress: '127.0.0.1',
-        // Pipelining: target-slot is one ahead of build-slot; inboxLag sources L1->L2
-        // messages from the previous checkpoint to avoid L1ToL2MessagesNotReadyError.
       },
     });
 
diff --git a/yarn-project/end-to-end/src/p2p/reqresp/utils.ts b/yarn-project/end-to-end/src/p2p/reqresp/utils.ts
@@ -43,8 +43,6 @@ export async function createReqrespTest(options: ReqrespOptions = {}): Promise<P
       ...(disableStatusHandshake ? { p2pDisableStatusHandshake: true } : {}),
       listenAddress: '127.0.0.1',
       aztecEpochDuration: 64, // stable committee
-      // Pipelining: target-slot is one ahead of build-slot; inboxLag sources L1->L2
-      // messages from the previous checkpoint to avoid L1ToL2MessagesNotReadyError.
     },
   });
   await t.setup();
diff --git a/yarn-project/sequencer-client/README.md b/yarn-project/sequencer-client/README.md
@@ -142,7 +142,7 @@ Inside `execute()`:
    - Transitions to `INITIALIZING_CHECKPOINT`. If there is a pending invalidation, enqueue it.
    - Builds **pipelined-parent simulation overrides**: when building on top of a parent that hasn't landed on L1 yet, the fee-asset price modifier must be computed against the parent fee header we predicted (not the L1 one), so all in-flight checkpoints in the pipeline agree on the same modifier.
    - Asks the global variables builder for the slot's `CheckpointGlobalVariables` (`coinbase`, `feeRecipient`, `timestamp`, `gasFees`, `chainId`, `version`, `slotNumber`). These are shared across every block within the checkpoint — only `blockNumber` increments.
-   - Computes `inHash` from the L1→L2 messages for the checkpoint, and collects `previousCheckpointOutHashes` for prior checkpoints in the same epoch.
+   - Resolves the streaming Inbox consumption cursor (the parent checkpoint's last-consumed bucket, from the fork's L1→L2 leaf count), and collects `previousCheckpointOutHashes` for prior checkpoints in the same epoch. Each block then selects its own message bundle against the cursor (AZIP-22 Fast Inbox).
    - Forks world state at the parent (`closeDelayMs: 12 s`) and asks `FullNodeCheckpointsBuilder` for a `CheckpointBuilder` bound to that fork.
    - Runs `buildBlocksForCheckpoint()` — the per-block loop, described below.
    - Transitions to `ASSEMBLING_CHECKPOINT`, asks the builder to `completeCheckpoint()`, validates it against the configured caps, and asks the validator client to sign the `CheckpointProposal` (which bundles the final block proposal so the two travel together).
@@ -206,7 +206,7 @@ See the [Block Building Timetable Spec](../stdlib/src/timetable/README.md) for t
 Key entry points:
 
 - `canProposeAt(archive, msgSender, simulationOverridesPlan?)` — eth_call simulation of `Rollup.canProposeAt`. The sequencer runs this before deciding to build.
-- `enqueueProposeCheckpoint(checkpoint, attestations, attestationsSignature, opts)` — adds the propose call, with a `preCheck` that re-validates the proposal against real L1 state when it is finally sent (catches drift between build time and submit time).
+- `enqueueProposeCheckpoint(checkpoint, attestations, attestationsSignature, bucketHint, opts)` — adds the propose call, with a `preCheck` that re-validates the proposal against real L1 state when it is finally sent (catches drift between build time and submit time).
 - `enqueueInvalidateCheckpoint`, `enqueueGovernanceCastSignal`, `enqueueSlashingActions` — the rest of the actions a proposer may bundle.
 - `sendRequests(targetSlot?)` — immediately flushes the queue as one Multicall3 transaction. Used by the `AutomineSequencer` for synchronous in-slot publishing.
 - `sendRequestsAt(targetSlot)` — the production (pipelined) path: sleeps (cancellable) until the ideal L1 send time, runs each request's `preCheck` (dropping those that fail), and then calls `sendRequests(targetSlot)`, which filters expired requests, sorts the remainder, and submits one Multicall3 that mines inside the target slot.
diff --git a/yarn-project/validator-client/README.md b/yarn-project/validator-client/README.md
@@ -21,7 +21,7 @@ A `BlockProposal` is broadcast by the proposer for each block **except the last
 BlockProposal {
   blockHeader          // Per-block header with global variables
   indexWithinCheckpoint // 0, 1, 2, ... position within checkpoint
-  inHash               // L1-to-L2 messages hash (constant across checkpoint)
+  bucketRef?           // Inbox bucket reference for the block's L1-to-L2 message bundle
   archive              // Archive root after this block
   txHashes             // Transaction hashes in order
   signature            // Proposer's signature
@@ -50,7 +50,7 @@ CheckpointProposal {
 }
 ```
 
-The `checkpointHeader` contains aggregated data: `blockHeadersHash` (hash of all block headers), `contentCommitment` (blobsHash, inHash, outHash), and shared global variables.
+The `checkpointHeader` contains aggregated data: `blockHeadersHash` (hash of all block headers), `contentCommitment` (blobsHash, inboxRollingHash, outHash), and shared global variables.
 
 ### Checkpoint Attestations
 
@@ -75,7 +75,7 @@ These rules must always hold:
 
 1. **Attestations are checkpoint-only**: Validators never attest to individual `BlockProposal`s
 2. **Global variables match within checkpoint**: All blocks within the same checkpoint must have identical global variables (except `blockNumber`), which includes the slot number
-3. **inHash is constant**: All blocks in a checkpoint share the same L1-to-L2 messages hash
+3. **Inbox consumption moves forward**: Each block's bucket reference consumes at or past its parent block's Inbox position (AZIP-22 Fast Inbox)
 4. **Sequential indexWithinCheckpoint**: Block N must have `indexWithinCheckpoint = parent.indexWithinCheckpoint + 1`
 5. **One proposer per slot**: Each slot has exactly one designated proposer. Sending multiple proposals for the same position (slot, indexWithinCheckpoint) with different content is equivocation and slashable
 6. **One attestation per slot**: Validators should only attest to one checkpoint per slot. Attesting to different proposals (different archives) for the same slot is equivocation and slashable
@@ -93,7 +93,7 @@ When a `BlockProposal` is received via P2P, the `BlockProposalHandler` performs:
 4. Find parent block by archive root (wait/retry if not synced)
 5. Compute checkpoint number from parent
 6. If indexWithinCheckpoint > 0, then validate global variables match parent (chainId, version, slotNumber, timestamp, coinbase, feeRecipient, gasFees)
-7. Verify inHash matches computed from L1-to-L2 messages
+7. Run the streaming Inbox acceptance checks on the proposal's bucket reference and derive the block's L1-to-L2 message bundle (AZIP-22 Fast Inbox)
 8. Collect transactions from pool/network/proposal
 9. Re-execute transactions (if enabled)
 10. Compare re-execution result with proposal

Original file line number	Diff line number	Diff line change
`@@ -28,8 +28,6 @@ export const PIPELINED_FEE_PADDING = 30;`
`28`	`28`	`*`
`29`	`29`	`* The preset runs the production Sequencer with the always-enforced timetable at real (wall-clock)`
`30`	`30`	`* timing, yielding exactly 2 blocks per slot. It sets:`
`31`		- * - `inboxLag: 2` so the sequencer sources L1->L2 messages from checkpoint N-1 (already sealed),
`32`		- * avoiding `L1ToL2MessagesNotReadyError` when building for slot N during slot N-1.
`33`	`31`	* - `minTxsPerBlock: 0` so empty checkpoints land even when a tx arrives late in the build window
`34`	`32`	`* (otherwise the chain stalls on alternating slots).`
`35`	`33`	* - `aztecSlotDuration: 12` / `ethereumSlotDuration: 4` so the pipelined cycle fits inside the