chonk-inputs
Skill458 starsChanged 2 months agoApache-2.0View on GitHub
Manage pinned Chonk IVC inputs and the Chonk/rollup UltraHonk proving checks. Use when updating, testing, benchmarking, or reviewing the CI flow for Chonk input refreshes.
We split this skill into the rules it gives an agent
11 rules. About 0 are common, 3 are distinctive, and 8 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
8
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 15
Use the scripts instead of open-coding URLs, hashes, temp paths, or bucket listings.
- Distinctive: line 27
If a bb/proof-system change can affect VKs, refresh in this order:
- Very specific: line 35
Keep the tracked noir-projects/fnd/mock-protocol-circuits/pinned-build.tar.gz diff.
- Very specific: line 36
Remove the generated untracked noir-projects/fnd/noir-protocol-circuits/pinned-build.tar.gz unless intentionally reintroducing that large …
- Very specific: line 51
After pin-build, sanity-check that the tracked tarball is a full pin, not the empty/incomplete shell a silent failure leaves behind: tar …
- Distinctive: line 76
Check pinned VK compatibility without updating:
- Very specific: line 105
Keep Chonk benchmark command enumeration in barretenberg.
- Very specific: line 109
Do not use aws s3 ls or depend on bucket listing.
- Very specific: line 110
Use .cache/ for scratch state and clean job-specific subdirectories.
- Very specific: line 111
Keep refresh commits scoped to barretenberg/cpp/scripts/chonk-inputs.hash.
- Very specific: line 112
Run bash -n on edited shell scripts and yq e .
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Chonk Inputs
Pinned Chonk IVC inputs live in an S3 tarball keyed by barretenberg/cpp/scripts/chonk-inputs.hash. The owner scripts are:
barretenberg/cpp/scripts/pinned_chonk_inputs.shfor shared shell helpers.barretenberg/cpp/scripts/chonk_inputs.shfor download, check, and update.barretenberg/cpp/scripts/ci_update_chonk_inputs.shfor the PR push-back step.
Use the scripts instead of open-coding URLs, hashes, temp paths, or bucket listings.
Pins to keep in sync
A bb/proof-system change that rotates VKs touches THREE tracked pins, and all of them feed the captured Chonk flows:
- The mock artifact pin
noir-projects/fnd/mock-protocol-circuits/pinned-build.tar.gzfreezes mock protocol circuit bytecode and VKs used by Chonk fixture capture. - The standard-contracts pin
labs/noir-projects/noir-contracts/pinned-standard-contracts.tar.gzfreezes thecontracts/standard/artifacts with their precomputed VKs and deterministic addresses.noir-contracts/bootstrap.sh buildextracts it and excludesstandard/from recompilation, so these VKs only refresh viapin-standard-build(step 5). - The Chonk flow pin
barretenberg/cpp/scripts/chonk-inputs.hashpoints to the S3 tarball of capturedivc-inputs.msgpackflows. Those msgpacks embed bytecode, witnesses, circuit kinds, and precomputed VKs — including the standard-contract VKs above, so the standard-contracts pin must be correct before recapturing flows.
noir-projects/fnd/noir-protocol-circuits/pinned-build.tar.gz is not a current tracked pin on the next line. noir-projects/fnd/bootstrap.sh pin-build may generate it as untracked local build output; do not commit it unless intentionally reintroducing that large artifact pin.
If a bb/proof-system change can affect VKs, refresh in this order:
- Rebuild the AVM-enabled bb binary so the regenerated VKs reflect the change.
cmake --build build --target bbis not enough:noir-projects/fnd/noir-protocol-circuits/bootstrap.shresolves the bb binary viabarretenberg/cpp/scripts/find-bb, which returnsbb-avm(notbb) unlessAVM=0. Frombarretenberg/cpp/:cmake --preset default -DAVM=ON cmake --build build --target bb-avm - Repin Noir artifacts with the AVM-enabled binary:
./bootstrap.sh pin-buildfromnoir-projects/fnd/. Do not setAVM=0— the*-tx-base-publiccircuits verify an AVM proof, so non-AVMbbfails their VK generation with "AVM recursion is not supported in this build". Because pin-build runs underset +e, that failure does not abort the run; it silently archives an incompletepinned-build.tar.gzwith stale/missing VKs. - Keep the tracked
noir-projects/fnd/mock-protocol-circuits/pinned-build.tar.gzdiff. - Remove the generated untracked
noir-projects/fnd/noir-protocol-circuits/pinned-build.tar.gzunless intentionally reintroducing that large pin. Repin the standard contracts iteratively, and regenerate their address stamps. A stale standard-contracts pin surfaces as a "Computed VK differs from precomputed VK" mismatch on a
standard/contract function during chonk capture verification. Repinning is not a single command:pin-standard-buildcompiles the standard contracts against the currentstandard_addresses.nrand tarballs them — it does NOT regenerate the stamps, and standard contracts can reference each other's deterministic addresses. Because a contract's address depends on its bytecode, which depends on the addresses it embeds, you must repeat the re-pin + stamp-regeneration until a round changes nothing (the addresses stop moving):cd labs/noir-projects/noir-contracts # repeat this pair until `generate` makes no change (exits 0, no "Changed values"): BB=$(realpath ../../barretenberg/cpp/build/bin/bb-avm) ./bootstrap.sh pin-standard-build (cd ../../yarn-project && yarn workspace @aztec/standard-contracts generate) # rewrites stamps; exits non-zero on driftBBdefaults to non-AVMbb; set it tobb-avmexplicitly. Once converged, runmake noir-projectsfrom the repo root once to recompile dependents against the final addresses, then commit the pin together with the two regenerated stamp files:yarn-project/standard-contracts/src/standard_contract_data.tslabs/noir-projects/aztec-nr/aztec/src/standard_addresses.nr
Two failure modes if you cut corners: skipping the stamp regen rotates the contract addresses out from under the committed stamps → a cascade of contract-class / "address not updated" failures; stopping before the addresses stabilize leaves a pinned contract calling another standard contract's previous address → e2e capture aborts with
Function artifact not found for contract 0x…during flow execution.- Recapture and upload Chonk flows with
barretenberg/cpp/scripts/chonk_inputs.sh update(only after step 5 is committed, since the capture embeds the standard-contract VKs).
After pin-build, sanity-check that the tracked tarball is a full pin, not the empty/incomplete shell a silent failure leaves behind: tar tzf noir-projects/fnd/mock-protocol-circuits/pinned-build.tar.gz | grep -c '\.json$' should list every circuit (a 400-byte tarball containing only ./ and ./keys/ means the build produced nothing).
A refreshed Chonk flow pin alone can still contain stale VKs if the capture used stale Noir artifacts. ChonkPinnedIvcInputsTest.AllPinnedFlows uses the embedded VKs with the default policy, so stale VKs may surface later as generated-proof verification failure rather than the explicit chonk_inputs.sh check VK-mismatch message.
Diagnosing an AllPinnedFlows failure
Decide whether you have a pin problem or something upstream before repinning or re-uploading:
- Download / hash failure (
failed to download … may be stale,InvalidAccessKeyId) → a pin/upload problem. Refresh the flow pin; forInvalidAccessKeyId, the build+capture is fine but your AWS creds are expired — the canonical fix is theci-refresh-chonklabel so CI uploads with its own creds. - Prove / verify failure (e.g.
ChonkVerifier: verification failed at PI pairing points check,Failed to verify the generated proof) → does NOT by itself mean the flow pin is stale, and re-capturing the flow pin will not fix it. Factor out the pin by re-running the test against a freshly-captured local flow set (the test honorsCHONK_PINNED_IVC_INPUTS_DIR, with no hash/marker check):
(CHONK_PINNED_IVC_INPUTS_DIR=$(pwd)/yarn-project/end-to-end/chonk-pinned-flows \ CHONK_PINNED_IVC_FLOW=<flow> AZTEC_REPO_ROOT=$(pwd) \ ./barretenberg/cpp/build/bin/bbapi_tests --gtest_filter='ChonkPinnedIvcInputsTest.AllPinnedFlows'CHONK_PINNED_IVC_FLOWfilters to one flow dir for a fast loop; omit it to run all.) If a freshly-captured flow fails identically, the flow pin is not the cause — an embedded precomputed VK is stale. Runbb check --scheme chonkover the flows to name the function (VK mismatch detected for function <contract>:<fn>); if it's astandard/contract, the cause is the standard-contracts pin (step 5), not the flow pin.
Common Commands
Download or repair the local fixture directory:
barretenberg/cpp/scripts/chonk_inputs.sh downloadCheck pinned VK compatibility without updating:
barretenberg/cpp/scripts/chonk_inputs.sh checkRefresh the pin locally:
barretenberg/cpp/scripts/chonk_inputs.sh updateIn PR CI, refresh via the ci-refresh-chonk label or a --ci-refresh-chonk head-commit marker. The follow-up refresh commit includes --ci-skip.
Proving is handled by the pinned-input tests; the CI push-back step runs one small pinned flow before committing a refreshed hash.
Benchmark and Proving Checks
Barretenberg owns the Chonk and rollup UltraHonk benchmark commands. Use barretenberg/cpp/bootstrap.sh bench_cmds to inspect the CI command list, or bench_ivc for a focused Chonk run.
The benchmark scripts restore or regenerate their inputs when missing:
barretenberg/cpp/scripts/chonk_inputs.sh download
barretenberg/cpp/scripts/ci_benchmark_ivc_flows.sh native
barretenberg/cpp/scripts/ci_benchmark_ultrahonk_circuits.sh parity_base \
../../yarn-project/end-to-end/ultrahonk-bench-inputs 8Keep Chonk benchmark command enumeration in barretenberg; yarn-project/end-to-end/bootstrap.sh build_bench_capture is only for live input capture during pin refresh.
Review Checklist
- Do not use
aws s3 lsor depend on bucket listing. Verify exact object URLs. - Use
.cache/for scratch state and clean job-specific subdirectories. - Keep refresh commits scoped to
barretenberg/cpp/scripts/chonk-inputs.hash. - Run
bash -non edited shell scripts andyq e . .github/workflows/ci3.ymlafter workflow edits. - For update-step changes, run
.cache/chonk-ux-harness/run.shwhen available.
In this repository22 other files it gives its agents.
- avm-transpiler/CLAUDE.mdCLAUDE.md
- barretenberg/CLAUDE.mdCLAUDE.md
- CLAUDE.mdCLAUDE.md
- docs/CLAUDE.mdCLAUDE.md
- docs/llms.txtllms.txt
- acir-formal-proofsSkill
- adding-benchmarksSkill
- bench-regressionSkill
- capture-app-flowSkill
- ci-logsSkill
- create-issueSkill
- cycleSkill
- fixSkill
- genesis-constantsSkill
- merge-train-infraSkill
- merge-trainsSkill
- noir-sync-updateSkill
- prep-cycleSkill
- release-docsSkill
- release-network-docsSkill
- update-doc-referencesSkill
- updating-changelogSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

