Merge remote-tracking branch 'origin/merge-train/barretenberg' into lde/circuit-to-polys

Author: ledwards2225

.github/workflows/docs-typesense.yml

@@ -34,23 +34,43 @@ jobs:
           # regression (which happened with #22861 dropping the index from
           # ~12k to 48 records) into a loud CI failure.
           MIN_HITS: "5000"
+          TYPESENSE_API_KEY: ${{ secrets.TYPESENSE_API_KEY }}
+          TYPESENSE_HOST: ${{ secrets.TYPESENSE_HOST }}
         run: |
-          set -o pipefail
+          set -euo pipefail
+
           docker run \
-            -e "TYPESENSE_API_KEY=${{ secrets.TYPESENSE_API_KEY }}" \
-            -e "TYPESENSE_HOST=${{ secrets.TYPESENSE_HOST }}" \
+            -e "TYPESENSE_API_KEY=$TYPESENSE_API_KEY" \
+            -e "TYPESENSE_HOST=$TYPESENSE_HOST" \
             -e "TYPESENSE_PORT=443" \
             -e "TYPESENSE_PROTOCOL=https" \
-            -e "CONFIG=$(cat docs/typesense.config.json | jq -r tostring)" \
+            -e "CONFIG=$(cat docs/typesense.config.json)" \
             typesense/docsearch-scraper:0.11.0 2>&1 | tee scraper.log
 
           nb_hits=$(grep -oE 'Nb hits: *[0-9]+' scraper.log | tail -1 | grep -oE '[0-9]+' || true)
           if [ -z "$nb_hits" ]; then
-            echo "::error::Could not parse 'Nb hits' from scraper output — assuming index is broken."
+            echo "::error::Could not parse 'Nb hits' from scraper output, assuming index is broken."
             exit 1
           fi
           echo "Indexed $nb_hits records (threshold: $MIN_HITS)"
           if [ "$nb_hits" -lt "$MIN_HITS" ]; then
             echo "::error::Indexed only $nb_hits records (expected at least $MIN_HITS). Search index is likely broken."
             exit 1
           fi
+
+          # Log how many api-nr records are visible in the live index. The
+          # docusaurus theme always prepends `default` to its contextual
+          # docusaurus_tag filter, and no docusaurus page is stamped with
+          # `default` (each carries its plugin-context tag instead), so this
+          # facet count is effectively the count of indexed api-nr records.
+          # Informational only: the count varies with aztec-nr content size.
+          api_hits=$(curl -fsS \
+            "https://$TYPESENSE_HOST/collections/aztec-docs/documents/search" \
+            -H "X-TYPESENSE-API-KEY: $TYPESENSE_API_KEY" \
+            -G \
+            --data-urlencode "q=*" \
+            --data-urlencode "query_by=hierarchy.lvl0" \
+            --data-urlencode "filter_by=docusaurus_tag:=[default]&&language:=en" \
+            --data-urlencode "per_page=1" \
+            | jq -r '.found')
+          echo "api-nr records visible under docusaurus_tag:=[default]: $api_hits"

.test_patterns.yml

@@ -60,9 +60,6 @@ tests:
     error_regex: "Aborted.*core dumped"
     owners:
       - *adam
-  - regex: "barretenberg/cpp/scripts/run_bench.sh wasm bb-micro-bench/wasm/chonk build-wasm-threads/bin/chonk_bench"
-    owners:
-      - *luke
 
   # noir
   # Something to do with how I run the tests now. Think these are fine in nextest.
@@ -297,11 +294,6 @@ tests:
     owners:
       - *palla
 
-  - regex: "bb-micro-bench/wasm/chonk build-wasm-threads/bin/chonk_bench"
-    error_regex: "core dumped"
-    owners:
-      - *adam
-
   - regex: "src/e2e_token_bridge_tutorial.test.ts"
     error_regex: "Error: Unable to find low leaf for block"
     owners:

CLAUDE.md

@@ -107,6 +107,16 @@ Do not explain *what* the code does — well-named identifiers cover that. Comme
 Do not reference the current task, PR, caller, or author (`// used by X`, `// fix for issue #123`, `// AI-generated`), and do not add banner-style section comments (`// ===== HELPERS =====`). Both rot the moment the surrounding code is moved.
 </writing_comments>
 
+<jargon>
+Avoid recurring AI-isms in chat replies, PR descriptions, commit messages, code comments, and docs. Substitutes:
+
+- **"load bearing"** → *important*, *critical*, *required*, or describe the actual dependency (e.g. "the scheduler relies on this invariant").
+- **"seam"** (for an interaction point or boundary) → *interface*, *boundary*, *call site*, *integration point*.
+- **"north star"** → *goal*, *main goal*, *objective*.
+- **"sharpening"** (for adding detail or refining wording) → *clarifying*, *adding detail*, *tightening*, *refining*.
+- **"You're absolutely right"** and effusive agreement openers (*"Great catch!"*, *"Excellent point!"*) → never lead a reply with these. A short acknowledgement (*"Right — …"*, *"Agreed."*) is fine, and a closing *"you're right"* at the end of a long reply is acceptable when warranted. Lead with substance, not validation.
+</jargon>
+
 <attribution>
 Attribute work to the git author, not to Claude. Do not add `Co-Authored-By: Claude` trailers or `Generated with Claude Code` in PR descriptions. The git author (from `git config user.name`) is the author of record.
 </attribution>

barretenberg/.claude/skills/benchmark-chonk/SKILL.md

@@ -6,16 +6,9 @@ argument-hint: <action> e.g. "run", "compare", "wasm", "instrument <area>", "per
 
 # Benchmark Chonk
 
-Run realistic Chonk IVC benchmarks using **pinned protocol inputs** (real transaction flows captured from end-to-end tests), not the synthetic `chonk_bench` target. The synthetic benchmark (`chonk_bench`) uses trivially small mock circuits — it is useful for quick regression checks but does NOT reflect production proving performance. Users invoking `/benchmark-chonk` want the real thing.
+Run realistic Chonk IVC benchmarks using **pinned protocol inputs** (real transaction flows captured from end-to-end tests).
 
-## What makes this different from `chonk_bench`
-
-| | `chonk_bench` (synthetic) | This skill (realistic) |
-|---|---|---|
-| Input data | Mock circuits via `test_bench_shared.hpp` | Pinned msgpack from real Aztec transactions |
-| Circuit count | 2 or 5 tiny circuits | Full transaction flows (10+ circuits) |
-| Circuit variety | All identical | Mixed: app, kernel, tail, public |
-| BB command | `./chonk_bench --benchmark_filter=...` | `bb prove --scheme chonk --ivc_inputs_path ...` |
+**Chonk has no synthetic micro-benchmark.** Past attempts (`chonk_bench`) used trivially small mock circuits and produced misleading numbers — the target was deleted to prevent regression of that mistake. Always benchmark Chonk via `bb prove --scheme chonk` against pinned `ivc-inputs.msgpack` for real transaction flows. If a Chonk proving question seems to call for a micro-benchmark, the answer is still `bb prove` on a real flow.
 
 ## Step 1: Get pinned IVC inputs
 
@@ -158,7 +151,7 @@ The macros create `BenchReporter` RAII objects that:
 
 ### Google Benchmark integration
 
-For `chonk_bench` and other `.bench.cpp` targets:
+For `.bench.cpp` targets that integrate BB_BENCH into Google Benchmark counters:
 ```cpp
 #include "barretenberg/common/google_bb_bench.hpp"
 
@@ -275,15 +268,15 @@ python3 barretenberg/cpp/scripts/extract_component_benchmarks.py <output_dir> <n
 
 This reads `benchmark_breakdown.json`, finds operations matching key components (sumcheck, pcs, pippenger, commitment, circuit, oink, compute), and appends them to `benchmarks.bench.json` with stacked chart markers for the dashboard.
 
-## A/B comparison scripts
+## A/B comparison
+
+For Chonk A/B between branches, run `bb prove --scheme chonk` against the same pinned `ivc-inputs.msgpack` on each branch and compare the resulting `--bench_out_hierarchical` JSON manually. Use the **remote machine** (`/remote-bench`) for stable, single-run numbers.
 
-These use Google Benchmark's `compare.py` for statistical analysis. Note: these use the **remote machine** — see `/remote-bench`.
+The generic Google-Benchmark A/B scripts still exist for non-Chonk targets:
 
 | Script | What it compares |
 |--------|-----------------|
-| `scripts/compare_chonk_bench.sh` | Native ChonkBench/Full/6, branch vs baseline |
-| `scripts/compare_chonk_bench_wasm.sh` | WASM ChonkBench/Full/6, branch vs baseline |
-| `scripts/compare_branch_vs_baseline_remote.sh` | Generic native A/B |
+| `scripts/compare_branch_vs_baseline_remote.sh` | Generic native A/B (any `*_bench` target) |
 | `scripts/compare_branch_vs_baseline_remote_wasm.sh` | Generic WASM A/B |
 
 ## Key scripts reference
@@ -293,7 +286,6 @@ These use Google Benchmark's `compare.py` for statistical analysis. Note: these
 | `scripts/test_chonk_standalone_vks_havent_changed.sh` | Download/update/verify pinned inputs |
 | `scripts/ci_benchmark_ivc_flows.sh` | CI: proves a flow, extracts components, uploads to dashboard |
 | `scripts/benchmark_example_ivc_flow_remote.sh` | Proves a pinned flow on the remote machine (uses `/remote-bench`) |
-| `scripts/benchmark_chonk.sh` | Synthetic `chonk_bench` on remote |
 | `scripts/wasmtime.sh` | wasmtime wrapper with standard flags |
 | `scripts/extract_component_benchmarks.py` | Extract component timings from hierarchical breakdown |
 
@@ -307,7 +299,7 @@ These use Google Benchmark's `compare.py` for statistical analysis. Note: these
 - **WASM preset:** `wasm-threads`. Build dir is `build-wasm-threads/`. The preset enables `ENABLE_WASM_BENCH=ON` automatically.
 - **WASM is ~2.8x slower than native** — this ratio is consistent across all circuit types.
 - **CRS:** Ensure `~/.bb-crs` exists. For WASM, wasmtime needs `--dir=$HOME/.bb-crs`.
-- **`BB_BENCH=1` vs `--print_bench`:** Either activates profiling. `--print_bench` also triggers the hierarchical tree output to stderr. In `chonk_bench`, the `GOOGLE_BB_BENCH_REPORTER` macro enables it automatically when `BB_BENCH=1` is set.
+- **`BB_BENCH=1` vs `--print_bench`:** Either activates profiling. `--print_bench` also triggers the hierarchical tree output to stderr. In Google-Benchmark targets that wrap their loops with `GOOGLE_BB_BENCH_REPORTER`, the same activation happens automatically when `BB_BENCH=1` is set.
 - **Dashboard:** CI uploads breakdown data to `bench/bb-breakdown/` on S3. The dashboard at `ci3/dashboard/chonk-breakdowns/` visualizes it.
 - **Rebuilding after instrumentation changes:** Only `ninja bb` is needed — no need to reconfigure.
 

barretenberg/.claude/skills/remote-bench/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: remote-bench
 description: Run benchmarks on the dedicated remote EC2 benchmarking machine for noise-free, single-run results. Handles env var validation, lock management, binary transfer, and result collection. Use with /benchmark-chonk or any BB benchmark target.
-argument-hint: <target> e.g. "bb", "chonk_bench", "ultra_honk_bench", "wasm bb"
+argument-hint: <target> e.g. "bb", "ultra_honk_bench", "wasm bb"
 ---
 
 # Remote Bench
@@ -95,7 +95,7 @@ The standard flow used by `scripts/benchmark_remote.sh`:
 ```bash
 cd barretenberg/cpp
 
-BENCHMARK="bb"                    # or chonk_bench, ultra_honk_bench, etc.
+BENCHMARK="bb"                    # or ultra_honk_bench, etc. (Chonk: use bb with --scheme chonk on real example flows — there is no synthetic chonk benchmark)
 PRESET="clang20-no-avm"          # or clang20
 BUILD_DIR="build-no-avm"         # matches preset
 
@@ -204,14 +204,14 @@ Compare current branch vs baseline (builds and runs both on remote):
 
 ```bash
 # Native
-./scripts/compare_chonk_bench.sh                # ChonkBench/Full/6
 ./scripts/compare_branch_vs_baseline_remote.sh <target> '<filter>'
 
 # WASM
-./scripts/compare_chonk_bench_wasm.sh           # ChonkBench/Full/6
 ./scripts/compare_branch_vs_baseline_remote_wasm.sh <target> '<filter>'
 ```
 
+For Chonk A/B, do not use a synthetic benchmark — measure `bb prove --scheme chonk` against pinned `ivc-inputs.msgpack` for both branches and compare manually.
+
 These use Google Benchmark's `compare.py` for statistical analysis. Note: comparison scripts check out the baseline branch locally, so your working tree must be clean.
 
 ## Scripts reference
@@ -220,10 +220,7 @@ These use Google Benchmark's `compare.py` for statistical analysis. Note: compar
 |--------|---------|
 | `scripts/benchmark_remote.sh` | Generic: build locally, scp, run remotely |
 | `scripts/benchmark_wasm_remote.sh` | Same for WASM (wasmtime on remote) |
-| `scripts/benchmark_example_ivc_flow_remote.sh` | Chonk with pinned inputs on remote |
-| `scripts/benchmark_chonk.sh` | Synthetic chonk_bench on remote |
-| `scripts/compare_chonk_bench.sh` | A/B native comparison |
-| `scripts/compare_chonk_bench_wasm.sh` | A/B WASM comparison |
+| `scripts/benchmark_example_ivc_flow_remote.sh` | Chonk with pinned inputs on remote (the only realistic Chonk bench) |
 | `scripts/compare_branch_vs_baseline_remote.sh` | Generic A/B native |
 | `scripts/compare_branch_vs_baseline_remote_wasm.sh` | Generic A/B WASM |
 | `scripts/_benchmark_remote_lock.sh` | Lock mechanism (source it, don't run it) |

barretenberg/bbup/bb-versions.json

@@ -1,4 +1,5 @@
 {
+  "1.0.0-beta.21": "5.0.0-nightly.20260324",
   "1.0.0-beta.20": "5.0.0-nightly.20260324",
   "1.0.0-beta.19": "4.0.0-nightly.20260120",
   "1.0.0-beta.18": "3.0.0-nightly.20260102",

barretenberg/cpp/CMakePresets.json

@@ -788,7 +788,6 @@
         "barretenberg-debug.wasm",
         "ecc_tests",
         "ultra_honk_bench",
-        "chonk_bench",
         "bb"
       ]
     },

barretenberg/cpp/bootstrap.sh

@@ -324,12 +324,8 @@ function bench_cmds {
   prefix="$hash:CPUS=8"
   echo "$prefix barretenberg/cpp/scripts/run_bench.sh native bb-micro-bench/native/ultra_honk $native_build_dir/bin/ultra_honk_bench construct_proof_ultrahonk_power_of_2/20$"
   echo "$prefix barretenberg/cpp/scripts/run_bench.sh native bb-micro-bench/native/ultra_honk_zk $native_build_dir/bin/ultra_honk_bench construct_proof_ultrahonk_zk_power_of_2/20$"
-  echo "$prefix barretenberg/cpp/scripts/run_bench.sh native bb-micro-bench/native/chonk $native_build_dir/bin/chonk_bench ChonkBench/Full/5$"
   echo "$prefix barretenberg/cpp/scripts/run_bench.sh wasm bb-micro-bench/wasm/ultra_honk build-wasm-threads/bin/ultra_honk_bench construct_proof_ultrahonk_power_of_2/20$"
   echo "$prefix barretenberg/cpp/scripts/run_bench.sh wasm bb-micro-bench/wasm/ultra_honk_zk build-wasm-threads/bin/ultra_honk_bench construct_proof_ultrahonk_zk_power_of_2/20$"
-  echo "$prefix barretenberg/cpp/scripts/run_bench.sh wasm bb-micro-bench/wasm/chonk build-wasm-threads/bin/chonk_bench ChonkBench/Full/5$"
-  prefix="$hash:CPUS=1"
-  echo "$prefix barretenberg/cpp/scripts/run_bench.sh native bb-micro-bench/native/chonk_verify $native_build_dir/bin/chonk_bench VerificationOnly$"
 }
 
 # Runs benchmarks sharded over machine cores.

barretenberg/cpp/scripts/README.md

@@ -28,7 +28,8 @@ There are scripts that:
 4. If `ssh` worked, the setup is complete.
 
 ## How
-- `./scripts/benchmark_chonk.sh` lets you run `chonk_bench` remotely and analyze the results.
 - `./scripts/benchmark_example_ivc_flow_remote.sh` copies the example flow input you'd like to run to the remote machine, runs `bb prove`, and analyze the results.
     - For the script to work you need to have the example flows downloaded locally, by `AZTEC_CACHE_COMMIT=origin/next~3 FORCE_CACHE_DOWNLOAD=1 yarn-project/end-to-end/bootstrap.sh build_bench`
 - If you have other special needs, look inside the above scripts and see what parameters you can give, or use `./scripts/benchmark_remote.sh`.
+
+Chonk proving must always be measured on real example app flows via `benchmark_example_ivc_flow_remote.sh` — there is no synthetic chonk benchmark, and there should not be one. Running synthetic Chonk benchmarks gives misleading numbers because the mock circuits do not reflect production proving costs.