chore(fast-inbox): single canonical path for rollup sample-input regeneration (A-1435)

barretenberg/.claude/skills/gate-counts/SKILL.md

@@ -209,41 +209,42 @@ Then retry `bb gates`.
 The committed `Prover.toml` files carry fake recursive proofs whose length is
 frozen at the value present when they were last generated. After a proof-length
 change they must be regenerated (or hacked — see below). Two commands cover all
-protocol circuits:
+protocol circuits, split by whether the sample needs a real client-proved
+transaction.
 
-**Kernel circuits + most rollup circuits** (spins up an L1/anvil sandbox):
+**Block-root and above rollup circuits — prover-client suite** (simulated
+orchestrator, no L1 sandbox):
 
 ```bash
-AZTEC_GENERATE_TEST_DATA=1 FAKE_PROOFS=1 \
-  yarn workspace @aztec/end-to-end test:e2e e2e_prover/full.test
+AZTEC_GENERATE_TEST_DATA=1 \
+  yarn workspace @aztec/prover-client test regenerate_rollup_sample_inputs
 ```
 
-Regenerates `Prover.toml` for: `private-kernel-init` and its `private-kernel-init-N`
-variants, `private-kernel-inner` and its `private-kernel-inner-N` variants,
-`private-kernel-reset`, `private-kernel-reset-tail`,
-`private-kernel-reset-tail-to-public`, `rollup-tx-base-private`,
-`rollup-tx-base-public`, `rollup-block-root-first`,
-`rollup-block-root-first-single-tx`, `rollup-checkpoint-root-single-block`,
-`rollup-checkpoint-merge`, `rollup-root`.
+Regenerates `Prover.toml` for `rollup-block-root-first-empty-tx`,
+`rollup-block-root-first`, `rollup-block-root-first-single-tx`,
+`rollup-block-root`, `rollup-block-root-single-tx`, `rollup-block-root-msgs-only`,
+`rollup-block-merge`, `rollup-checkpoint-root`, `rollup-checkpoint-root-single-block`,
+`rollup-checkpoint-merge`, `rollup-tx-merge`, `rollup-root`.
 
-**Rollup circuits NOT covered by `full.test`** (incl. `rollup-tx-merge`):
+**Private-kernel + transaction-base circuits — e2e prover full test** (spins up
+an L1/anvil sandbox):
 
 ```bash
 AZTEC_GENERATE_TEST_DATA=1 FAKE_PROOFS=1 \
-  yarn workspace @aztec/prover-client test src/orchestrator/orchestrator_single_checkpoint.test.ts
+  yarn workspace @aztec/end-to-end test:e2e single-node/prover/server/full.test
 ```
 
-Regenerates `Prover.toml` for `rollup-tx-merge`, `rollup-block-root-first-empty-tx`,
-`rollup-block-root` (single-tx checkpoint test) and `rollup-block-root-single-tx`,
-`rollup-block-merge`, `rollup-checkpoint-root` (multi-block checkpoint test).
-
-> **`rollup-tx-merge`'s `Prover.toml` is regenerated by the prover-client
-> command, NOT `full.test`** — it is commented out in `full.test`'s circuit
-> list. Use the prover-client command for the tx-merge circuit.
+Regenerates `Prover.toml` for: `private-kernel-init` and its `private-kernel-init-N`
+variants, `private-kernel-inner` and its `private-kernel-inner-N` variants,
+`private-kernel-reset-tail`, `private-kernel-reset-tail-to-public`,
+`rollup-tx-base-private`, `rollup-tx-base-public`. These need real client-proved
+transactions the simulated orchestrator cannot produce. (`private-kernel-reset`,
+the inner reset, is commented out and hand-maintained — not regenerated.)
 
 The circuit lists live in the `updateProtocolCircuitSampleInputs(...)` loops in
-`yarn-project/end-to-end/src/e2e_prover/full.test.ts` and
-`yarn-project/prover-client/src/orchestrator/orchestrator_single_checkpoint.test.ts`;
+`yarn-project/end-to-end/src/single-node/prover/server/full.test.ts` and the
+`scenarios` array in
+`yarn-project/prover-client/src/test/regenerate_rollup_sample_inputs.test.ts`;
 re-read them if a circuit seems missing (entries get commented in/out).
 
 ### Build prerequisites for regeneration

barretenberg/.claude/skills/update-prover-toml/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: update-prover-toml
-description: Regenerate the protocol-circuit sample Prover.toml files (the witnesses CI feeds to `nargo execute`). Covers which e2e test/commands regenerate which tomls, and the one exception — private-kernel-reset/Prover.toml (the inner reset) — which is NOT generated by the test at all and is maintained entirely by hand. Use when a `nargo execute` CI check fails on a crates/*/Prover.toml, after changing protocol-circuit inputs/constants, or when asked to refresh/regenerate Prover.toml sample inputs.
+description: Regenerate the protocol-circuit sample Prover.toml files (the witnesses CI feeds to `nargo execute`). Covers which of the two commands regenerates which tomls — the prover-client `regenerate_rollup_sample_inputs` suite for the block-root and above rollup circuits, and the e2e prover full test for the private-kernel and transaction-base circuits — and the one exception, private-kernel-reset/Prover.toml (the inner reset), which is NOT generated by the test at all and is maintained entirely by hand. Use when a `nargo execute` CI check fails on a crates/*/Prover.toml, after changing protocol-circuit inputs/constants, or when asked to refresh/regenerate Prover.toml sample inputs.
 ---
 
 # Updating protocol-circuit Prover.toml files
@@ -21,39 +21,40 @@ The tomls are captured from a real end-to-end run, not written by hand (except t
 
 ## How regeneration works
 
-`yarn-project/end-to-end/src/e2e_prover/full.test.ts` has a test "generates sample Prover.toml files if generate test data is on". During proving, circuit inputs are captured via `pushTestData`/`getTestData`; the test then calls `updateProtocolCircuitSampleInputs(circuitName, TOML.stringify(...))` (`yarn-project/foundation/src/testing/files/index.ts`), which writes `noir-projects/noir-protocol-circuits/crates/<circuitName>/Prover.toml`.
+Two commands cover the protocol-circuit tomls, split by whether the sample needs a real client-proved transaction. Both capture circuit inputs during proving via `pushTestData`/`getTestData` and write them with `updateProtocolCircuitSampleInputs(circuitName, TOML.stringify(...))` (`yarn-project/foundation/src/testing/files/index.ts`), which writes `noir-projects/noir-protocol-circuits/crates/<circuitName>/Prover.toml`.
 
-The test early-returns unless **both** are true: `AZTEC_GENERATE_TEST_DATA=1` (enables `isGenerateTestDataEnabled()`) and fake proofs (`FAKE_PROOFS=1`, i.e. `REAL_PROOFS` is false).
+### Block-root and above rollup circuits — prover-client suite
 
-### Command
-
-From the repo root:
+`yarn-project/prover-client/src/test/regenerate_rollup_sample_inputs.test.ts` drives representative epochs through the simulated orchestrator and dumps each rollup circuit's captured input. The whole suite is `describe.skip`ped unless `AZTEC_GENERATE_TEST_DATA=1`, and it needs no L1 sandbox.
 
 ```bash
-AZTEC_GENERATE_TEST_DATA=1 FAKE_PROOFS=1 yarn-project/end-to-end/scripts/run_test.sh simple e2e_prover/full
+AZTEC_GENERATE_TEST_DATA=1 yarn workspace @aztec/prover-client test regenerate_rollup_sample_inputs
 ```
 
-(Equivalently, from `yarn-project/end-to-end`: `AZTEC_GENERATE_TEST_DATA=1 FAKE_PROOFS=1 yarn test:e2e e2e_prover/full.test`.) This is a full-stack run (L1 anvil + node + prover), ~15 min with fake proofs.
+Regenerates: `rollup-block-root-first-empty-tx`, `rollup-block-root-first`, `rollup-block-root-first-single-tx`, `rollup-block-root`, `rollup-block-root-single-tx`, `rollup-block-root-msgs-only`, `rollup-block-merge`, `rollup-checkpoint-root`, `rollup-checkpoint-root-single-block`, `rollup-checkpoint-merge`, `rollup-tx-merge`, `rollup-root`. The scenario list lives in the `scenarios` array in that test; each scenario's `dump` field names the tomls it owns.
 
-After it finishes, review and stage the changed tomls with `git diff noir-projects/noir-protocol-circuits/crates/*/Prover.toml`.
+### Private-kernel and transaction-base circuits — e2e prover full test
 
-### Which tomls this regenerates
+`full.test.ts` has a test "generates sample Prover.toml files if generate test data is on". It early-returns unless **both** `AZTEC_GENERATE_TEST_DATA=1` (enables `isGenerateTestDataEnabled()`) and fake proofs (`FAKE_PROOFS=1`, i.e. `REAL_PROOFS` is false) are set. These circuits need real client-proved transactions, which the simulated orchestrator suite above cannot produce.
 
-The circuit list lives in the `forEach(circuitName => ...)` loop in `full.test.ts`. Currently active (regenerated by the run above):
+From the repo root:
+
+```bash
+AZTEC_GENERATE_TEST_DATA=1 FAKE_PROOFS=1 yarn-project/end-to-end/scripts/run_test.sh simple single-node/prover/server/full
+```
+
+(Equivalently, from `yarn-project/end-to-end`: `AZTEC_GENERATE_TEST_DATA=1 FAKE_PROOFS=1 yarn test:e2e single-node/prover/server/full.test`.) This is a full-stack run (L1 anvil + node + prover), ~15 min with fake proofs.
+
+Regenerates:
 
 - `private-kernel-init`, `private-kernel-init-2` … `private-kernel-init-5`
 - `private-kernel-inner`, `private-kernel-inner-2` … `private-kernel-inner-5`
 - `private-kernel-reset-tail`, `private-kernel-reset-tail-to-public` (the terminal resets — these run as part of every tx's tail)
 - `rollup-tx-base-private`, `rollup-tx-base-public`
-- `rollup-block-root-first`, `rollup-block-root-first-single-tx`
-- `rollup-checkpoint-root-single-block`, `rollup-checkpoint-merge`
-- `rollup-root`
-
-`private-kernel-reset` (the **inner** reset) is deliberately **commented out** of this list and is **not** generated by the test — see the exception below.
 
-Other entries commented out (e.g. `rollup-tx-merge`, `rollup-block-root`, `rollup-block-merge`, `rollup-checkpoint-root`) are also not produced by this flow; the inline comment points to the orchestrator single-checkpoint test for those.
+The circuit list lives in the `forEach(circuitName => ...)` loop in `full.test.ts`. `private-kernel-reset` (the **inner** reset) is deliberately **commented out** of this list and is **not** generated by the test — see the exception below.
 
-If you add a new circuit crate, add its name to that list so its toml gets generated.
+After either run, review and stage the changed tomls with `git diff noir-projects/noir-protocol-circuits/crates/*/Prover.toml`. If you add a new circuit crate, add its name to the appropriate list so its toml gets generated.
 
 ## ⚠️ Exception: `private-kernel-reset/Prover.toml` (inner reset) is NOT generated — hand-maintain it
 

barretenberg/cpp/CLAUDE.md

@@ -139,21 +139,21 @@ run the generation commands above.
 
 Proof-length-affecting changes (e.g. `CHONK_PROOF_LENGTH` bumps from MegaFlavor entity additions) make the committed `Prover.toml` fixtures stale. `nargo execute --program-dir <crate>` then fails with `Type Array { length: N, typ: Field } is expected to have length N but value Vec(...)`.
 
-Regenerate via the e2e prover full test with fake proofs:
+Regeneration is split across two commands. The block-root, block-merge, checkpoint, tx-merge, and root rollup samples come from the prover-client suite, which drives the simulated orchestrator and needs no L1 sandbox:
 
 ```bash
-cd yarn-project
-AZTEC_GENERATE_TEST_DATA=1 FAKE_PROOFS=1 yarn workspace @aztec/end-to-end test e2e_prover/full.test
+AZTEC_GENERATE_TEST_DATA=1 yarn workspace @aztec/prover-client test regenerate_rollup_sample_inputs
 ```
 
-`FAKE_PROOFS=1` skips real proving — runs in ~2 min (orchestrator + witness generation only). Writes 12 `Prover.toml` files under `noir-projects/noir-protocol-circuits/crates/<circuit>/Prover.toml`.
-
-For circuits not exercised by `full.test.ts` (`rollup-tx-merge`, `rollup-block-root`, `rollup-block-root-single-tx`, `rollup-block-merge`, `rollup-checkpoint-root`, `rollup-block-root-first-empty-tx`), additionally run:
+The private-kernel samples and the transaction-base rollup samples (`rollup-tx-base-private`, `rollup-tx-base-public`) need real client-proved transactions, so they come from the e2e prover full test with fake proofs:
 
 ```bash
-AZTEC_GENERATE_TEST_DATA=1 yarn workspace @aztec/prover-client test orchestrator_single_checkpoint
+cd yarn-project
+AZTEC_GENERATE_TEST_DATA=1 FAKE_PROOFS=1 yarn workspace @aztec/end-to-end test single-node/prover/server/full.test
 ```
 
+`FAKE_PROOFS=1` skips real proving. Both write into `noir-projects/noir-protocol-circuits/crates/<circuit>/Prover.toml`.
+
 Verify with `nargo execute --program-dir noir-projects/noir-protocol-circuits/crates/<crate>` for any previously-failing crate; should print `Circuit witness successfully solved`.
 
 ## Verification Keys

docs/docs-developers/docs/tutorials/js_tutorials/aave_bridge.md

@@ -96,7 +96,7 @@ sequenceDiagram
     Portal->>Aave: withdraw(aTokenAmount)
     Aave-->>Portal: underlying + yield
     Portal->>Inbox: sendL2Message(content)
-    Note over Inbox: Wait for 2 L2 blocks (required for L1→L2 message availability)
+    Note over Inbox: Wait for an L2 block to include the message (12-30s)
     User->>Bridge: claim_public(amount_with_yield)
     Bridge->>Inbox: consume_l1_to_l2_message
     Bridge->>Token: mint_to_public(user, amount_with_yield)
@@ -441,7 +441,7 @@ Extract the message leaf index:
 
 #include_code get_claim_leaf_index /docs/examples/ts/aave_bridge/index.ts typescript
 
-On the local network, L2 blocks are only produced when transactions are submitted. L1-to-L2 messages require 2 L2 blocks before they can be consumed on L2. This utility deploys two dummy contracts (with random salts for unique addresses) to force block production. On devnet or testnet, blocks are produced continuously and this step is unnecessary:
+On the local network, L2 blocks are only produced when transactions are submitted. An L1-to-L2 message can only be consumed once an L2 block includes it, and the network waits until the message is at least 12 seconds old before including it. This utility deploys two dummy contracts (with random salts for unique addresses) to force block production. On devnet or testnet, blocks are produced continuously and this step is unnecessary:
 
 #include_code mine_blocks /docs/examples/ts/aave_bridge/index.ts typescript
 
@@ -501,7 +501,7 @@ If `claim_public` reverts, ensure you called `set_minter(l2Bridge.address, true)
 
 ### L1→L2 message not found — claim reverts after mining blocks
 
-L1-to-L2 messages need 2 L2 blocks after the L1 transaction before they become consumable. Make sure `mine2Blocks` runs before the claim. If the issue persists, verify the `messageLeafIndex` extracted from the `MessageSent` event is correct.
+An L1-to-L2 message becomes consumable once an L2 block includes it, which takes 12 to 30 seconds after the L1 transaction. Make sure `mine2Blocks` runs before the claim. If the issue persists, verify the `messageLeafIndex` extracted from the `MessageSent` event is correct.
 
 ## Next Steps
 

docs/docs-developers/docs/tutorials/js_tutorials/token_bridge.md

@@ -437,15 +437,15 @@ To bridge, first approve the portal address to transfer the NFT, then transfer i
 
 #include_code deposit_to_aztec /docs/examples/ts/token_bridge/index.ts typescript
 
-The `Inbox` contract will emit an important log: `MessageSent(inProgress, index, leaf, updatedRollingHash);`. This log provides the **leaf index** of the message in the [L1-L2 Message Tree](../../foundational-topics/ethereum-aztec-messaging/index.md)—the location of the message in the tree that will appear on L2. You need this index, plus the secret, to correctly claim and decrypt the message.
+The `Inbox` contract will emit an important log: `MessageSent(index, hash, inboxRollingHash, bucketSeq);`. Its first field is the **leaf index** of the message in the [L1-L2 Message Tree](../../foundational-topics/ethereum-aztec-messaging/index.md)—the location of the message in the tree that will appear on L2. You need this index, plus the secret, to correctly claim and decrypt the message.
 
 Use viem to extract this information:
 
 #include_code get_message_leaf_index /docs/examples/ts/token_bridge/index.ts typescript
 
-This extracts the logs from the deposit and retrieves the leaf index. You can now claim it on L2. However, for security reasons, at least 2 blocks must pass before a message can be claimed on L2. If you called `claim` on the L2 contract immediately, it would return "no message available".
+This extracts the logs from the deposit and retrieves the leaf index. You can now claim it on L2. However, a message can only be claimed once an L2 block includes it, and the network waits until the message is at least 12 seconds old before including it, so expect 12 to 30 seconds of latency. If you called `claim` on the L2 contract immediately, it would return "no message available".
 
-Add a utility function to mine two blocks (it deploys a contract with a random salt):
+On a local network blocks are only produced when transactions are submitted, so add a utility function that forces a couple of blocks (it deploys a contract with a random salt):
 
 #include_code mine_blocks /docs/examples/ts/token_bridge/index.ts typescript
 

docs/docs-developers/docs/tutorials/js_tutorials/uniswap_swap.md

@@ -309,7 +309,7 @@ Bridge WETH from L1 to L2:
 When depositing from L1 to L2, we use a secret/secret-hash pattern: generate a random secret on the client, send only the hash to L1 (in the deposit transaction), then later reveal the secret on L2 to claim the tokens. This prevents **front-running attacks**: a malicious sequencer (the node that orders and processes L2 transactions) cannot observe the L1 deposit and claim the tokens themselves because they don't know the secret. Only someone who knows the preimage can claim.
 :::
 
-Before claiming, we need to mine 2 L2 blocks. L1-to-L2 messages are not available in the same block they are sent -- the rollup must first include them in an L2 block, and then one more block must pass before the message can be consumed. We use a helper that deploys throwaway contracts to force these blocks:
+Before claiming, we need to mine a couple of L2 blocks. An L1-to-L2 message is not available the moment it is sent -- the rollup only includes it in an L2 block once it is at least 12 seconds old, and it becomes consumable as soon as that block lands. We use a helper that deploys throwaway contracts to force these blocks:
 
 #include_code mine_blocks /docs/examples/ts/example_swap/index.ts typescript
 

l1-contracts/gas_benchmark.md

@@ -12,24 +12,24 @@
 
 ## No Validators
 
-| Function             | Avg Gas | Max Gas | Calldata Size | Calldata Gas |
-|----------------------|---------|---------|---------------|--------------|
-| propose              | 195,988 | 222,201 |           932 |       14,912 |
-| submitEpochRootProof | 697,655 | 743,529 |         2,820 |       45,120 |
-| setupEpoch           |  31,998 | 113,793 |             - |            - |
+| Function             | Avg Gas |   Max Gas | Calldata Size | Calldata Gas |
+|----------------------|---------|-----------|---------------|--------------|
+| propose              | 199,557 |   225,741 |           996 |       15,936 |
+| submitEpochRootProof | 994,378 | 1,032,871 |        14,148 |      226,368 |
+| setupEpoch           |  32,042 |   113,837 |             - |            - |
 
-**Avg Gas Cost per Second**: 3,341.5 gas/second
+**Avg Gas Cost per Second**: 3,648.7 gas/second
 *Epoch duration*: 0h 38m 24s
 
 ## Validators
 
-| Function             | Avg Gas | Max Gas | Calldata Size | Calldata Gas |
-|----------------------|---------|---------|---------------|--------------|
-| propose              | 324,449 | 351,604 |         4,452 |       71,232 |
-| submitEpochRootProof | 896,101 | 941,944 |         5,316 |       85,056 |
-| aggregate3           | 373,118 | 386,457 |             - |            - |
-| setupEpoch           |  46,459 | 547,626 |             - |            - |
+| Function             |   Avg Gas |   Max Gas | Calldata Size | Calldata Gas |
+|----------------------|-----------|-----------|---------------|--------------|
+| propose              |   327,969 |   355,787 |         4,516 |       72,256 |
+| submitEpochRootProof | 1,575,427 | 1,673,267 |        16,644 |      266,304 |
+| aggregate3           |   376,569 |   389,943 |             - |            - |
+| setupEpoch           |    46,504 |   547,670 |             - |            - |
 
-**Avg Gas Cost per Second**: 5,304.3 gas/second
+**Avg Gas Cost per Second**: 5,942.9 gas/second
 *Epoch duration*: 0h 38m 24s