chore(bb): pin Chonk IVC inputs to e2dbfa3f to fix nightly debug build

[AztecBot]

What

Bumps barretenberg/cpp/scripts/chonk-inputs.hash from 209dde8e69a27c9f (pinned 2026-05-21) to e2dbfa3f4092e24f, so the Nightly Debug Build goes green again.

This is a plain pin bump — deliberately without the ci-refresh-chonk label or a --ci-skip marker — so it runs normal merge-queue CI and can merge through the queue like any other PR. See "Why a plain bump" below.

Root cause

Nightly Debug Build run 27399112032 (next @ fa063393) failed in:

FAILED: barretenberg/cpp/scripts/run_test.sh bbapi_tests ChonkPinnedIvcInputsTest.AllPinnedFlows (code: 1)

On circuit 10/10 (hiding_kernel) of the deploy_ecdsar1+sponsored_fpc pinned flow:

Pub inputs offset mismatch: 669 vs 673
Commitment mismatch: Q_M, Q_C, Q_L, Q_R, Q_O, Q_4, Q_5, Q_ARITH, Q_SORT, ...
Does the precomputed vk match with the one generated during accumulation? false
C++ exception: Assertion failed: (kernel_return_data_match)
  Reason: kernel_return_data mismatch: proof contains { 0x183227397098d014..., 0x0 }
          but kernel_calldata commitment is { 0x..01, 0x..02 }

The hiding_kernel circuit's public-input layout changed (offset 669 → 673, plus selector-commitment changes), so the precomputed VKs / proof baked into the pinned ivc-inputs.msgpack are stale. The reconstructed kernel_return_data reads the sentinel BN254 generator {1, 2} (an empty databus column) instead of the real return-data commitment, tripping the consistency check.

That check is BB_ASSERT_DEBUG(kernel_return_data_match, ...) at barretenberg/cpp/src/barretenberg/chonk/chonk.cpp:169 — a debug-only assertion compiled out of release/PR CI. Only the nightly debug build exercises it, which is why a stale pin slips past merge-queue CI and only the nightly catches it.

The circuit change came from #23484 (fix: harden batch chonk verifier, Jun 5) — it adds an independent batched-SRS MSM check binding the prover-supplied IPA G_0 in IPA::batch_reduce_verify; the IPA verifier lives inside the hiding kernel, accounting for the +4 public inputs and changed selectors. It landed without ci-refresh-chonk.

Why e2dbfa3f

The existing refresh PR #23924 already regenerated the pin to e2dbfa3f4092e24f on 2026-06-08 (its CI uploaded the matching bb-chonk-inputs-e2dbfa3f4092e24f.tar.gz to S3). That regen happened after #23484, so it reflects the 673-public-input hiding kernel. The only barretenberg change to land since is #23902 (pippenger/MSM prover rewrite) — MSM results are mathematically identical, so circuit shapes/VKs are unchanged. This PR's hash blob is byte-identical to #23924's.

Normal CI here re-validates the pin end-to-end (chonk_inputs.sh check recomputes the circuit VKs against the pinned tarball, and ChonkPinnedIvcInputsTest.AllPinnedFlows proves every flow). If e2dbfa3f were stale, CI fails and this won't merge.

Why a plain bump (not ci-refresh-chonk)

The ci-refresh-chonk flow ends by committing the new hash with a --ci-skip head-commit marker. On those PRs the required merge-queue checks therefore never run, so auto-merge can never be satisfied and the PR rots. That is why #23924 (auto-merge enabled since Jun 7) and several other cb/refresh-chonk-* branches have sat open and unmerged while next stayed on the May-21 pin. Landing the already-validated hash as an ordinary PR sidesteps that trap.

Supersedes/unblocks #23924.

Follow-up (separate, not in this PR)

Two systemic gaps worth a tracked fix so this stops recurring:

1. The debug-only assert means circuit changes can stale the pin with no PR-CI signal — consider running chonk_inputs.sh check (or a debug-asserts pinned-flow) at PR time, or having circuit-affecting PRs require ci-refresh-chonk.
2. ci-refresh-chonk refresh PRs are unmergeable by construction (--ci-skip head commit vs. required checks); the refresh automation should produce a landable PR.

---

Created by claudebox · group: slackbot

[AztecBot]

Automatically closing this stale claudebox draft PR (no updates for 5+ days). Re-open if still needed.