Update Prover Toml

Updating protocol-circuit Prover.toml files

All paths are from the repository root (one level above barretenberg/). The circuit crates and their tomls live in this repository; the TypeScript that regenerates them lives in the labs/ git submodule, so its paths start with labs/yarn-project/ and its workspaces are named @aztec-labs/*. Run the yarn commands below from labs/yarn-project.

What these files are

Each noir-projects/fnd/noir-protocol-circuits/crates/<circuit>/Prover.toml is a checked-in sample input (witness) for that circuit. Its job is a CI smoke test: noir-projects/fnd/noir-protocol-circuits/bootstrap.sh (test_cmds → circuits_to_execute) runs, for each listed circuit,

nargo execute --program-dir noir-projects/fnd/noir-protocol-circuits/crates/<circuit> --silence-warnings --skip-brillig-constraints-check

nargo execute reads the Prover.toml, generates the witness, and asserts all constraints hold. So each toml must be valid (or the execute test fails) and representative (so the test exercises the circuit on real-shaped inputs).

The tomls are captured from a real end-to-end run, not written by hand (except the reset one — see below).

Each toml is self-contained on the verification-key side: it carries its own vk_tree_root, plus a vk_data membership witness (leaf_index + sibling_path) under that root for every child proof the circuit verifies. So a change that only moves the real VK tree root — adding or removing a circuit, say — does not by itself need a regeneration pass: the committed samples still execute against the root they were captured with.

How regeneration works

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(...)) (labs/yarn-project/foundation/src/testing/files/index.ts), which writes noir-projects/fnd/noir-protocol-circuits/crates/<circuitName>/Prover.toml under whichever repository root it resolves from — which is no longer this one, see the warning next.

⚠️ The tests that write the tomls no longer live in the repository that holds them. getPathToFile derives the repository root from the calling module's own location, so a run inside the submodule targets labs/noir-projects/fnd/noir-protocol-circuits/crates/<circuitName>/Prover.toml. The submodule has no noir-projects/fnd — it consumes the compiled circuits as the @aztec-foundation/protocol-circuits-artifacts package rather than as a source tree — so the write fails there instead of updating the tomls committed here. As a local stopgap, point the missing directory at this repository before running either command, and remove it afterwards so it does not sit untracked in the submodule:

ln -s ../../noir-projects/fnd labs/noir-projects/fnd   # ... regenerate ... then: rm labs/noir-projects/fnd

Block-root and above rollup circuits — prover-client suite

labs/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.skipped unless AZTEC_GENERATE_TEST_DATA=1, and it needs no L1 sandbox.

AZTEC_GENERATE_TEST_DATA=1 yarn workspace @aztec-labs/prover-client test regenerate_rollup_sample_inputs

Regenerates every block-root variant plus the block-merge, checkpoint-root, checkpoint-merge, tx-merge and root tomls. Take the exact inventory from the scenarios array in that test rather than from a list here: each scenario's dump field names the tomls it owns, and the set changes whenever a block-root variant is added or removed.

Private-kernel and transaction-base circuits — e2e prover full test

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.

From the repo root:

AZTEC_GENERATE_TEST_DATA=1 FAKE_PROOFS=1 labs/yarn-project/end-to-end/scripts/run_test.sh simple single-node/prover/server/full

(Equivalently, from labs/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

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.

After either run, review and stage the changed tomls with git diff noir-projects/fnd/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

The inner reset is not regenerated by full.test.ts at all: 'private-kernel-reset' is commented out of the circuit list and no flow produces it. So the bulk regeneration command above leaves this one toml untouched — when a change affects it, you edit crates/private-kernel-reset/Prover.toml by hand.

Figuring out the change. Whatever change triggered the regeneration of the other tomls almost always applies to the reset toml too, in the same shape. So:

1. Run the regeneration command and look at the diffs to the generated tomls (git diff noir-projects/fnd/noir-protocol-circuits/crates/*/Prover.toml) — especially the closely-related private-kernel-reset-tail / private-kernel-reset-tail-to-public.
2. Apply the analogous edit by hand to private-kernel-reset/Prover.toml (e.g. mirror a renamed/added/removed field, an adjusted array length, or a changed constant).
3. Verify it executes (see below) before committing.

When the edit isn't obvious from the other diffs, a known-good earlier version of this same toml (e.g. git show origin/next:noir-projects/fnd/noir-protocol-circuits/crates/private-kernel-reset/Prover.toml) is the reference for the surrounding structure; splice in only the section that needs to change.

Fallback: regenerate a fresh reset toml with the test

If the change is too large to hand-apply (e.g. a reset ABI/layout change), or if there is no Prover.toml to modify, capture a fresh sample by temporarily re-enabling the inner-reset flow:

1. In full.test.ts, re-add a flow that forces an inner reset — a PendingNoteHashesContract.test_recursively_create_notes tx that emits more notes than a reset dimension can hold — and uncomment 'private-kernel-reset' in the circuit list.
2. Run the regeneration command above; this now writes private-kernel-reset/Prover.toml.
3. Revert the full.test.ts edits — do not commit the re-enabled flow.

⚠️ Disclaimer: zero out the key-validation requests in the captured toml. The captured inner reset does not verify the key-validation requests it carries (it has no master secret keys for them), but the full max-dimension private-kernel-reset circuit verifies all of them — so the raw captured toml fails nargo execute. After capturing, empty the key-validation requests (set their claimed length to zero and clear their array entries) so the verify loop runs over nothing. Confirm with the verify step below.

Verify

For the reset toml (and any other you touched), confirm it solves before committing. $NARGO defaults to noir/noir-repo/target/release/nargo:

noir/noir-repo/target/release/nargo execute \
  --program-dir noir-projects/fnd/noir-protocol-circuits/crates/private-kernel-reset \
  --silence-warnings --skip-brillig-constraints-check

Success prints Circuit witness successfully solved. This is the same check CI runs, so a clean local execute means the execute test will pass.