update-prover-toml

name

update-prover-toml

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

All paths are from the repository root (one level above barretenberg/).

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).

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(...)) (yarn-project/foundation/src/testing/files/index.ts), which writes noir-projects/fnd/noir-protocol-circuits/crates/<circuitName>/Prover.toml.

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

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/prover-client test regenerate_rollup_sample_inputs

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.

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 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

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.