gpu-benchmark.sh phase 3 cannot find its own receipts, and the fallback path holds cross-guest ones

[defenwycke]

Found while measuring block 962,000 on an L40S for v0.21.0. Phases 1 and 2 are fine — the failure
is phase 3, and the reason it is worth an issue is the second half rather than the first.

The bug

Phase 2 writes each receipt into the run directory, and does so correctly — all 16 land:

prove_0.log:  chunk 0 (435 inputs) proved in 242s -> /root/gpu-bench-core-.../receipts/chunk_0.bin
$ ls gpu-bench-core-20260907-2316/receipts | wc -l
16

Phase 3 (scripts/gpu-benchmark.sh:144) then does:

( cd "$P" && export HAZYNC_CHUNKS=16 HAZYNC_RECEIPTS="$OUT/receipts"; "$BIN" agg-chunks )

and dies immediately:

thread `main` panicked at host/src/main.rs:2609:72:
chunk receipt chunk_0.bin: No such file or directory (os error 2)
agg REAL_EXIT=101

agg-chunks does not honour HAZYNC_RECEIPTS. It resolves chunk_0.bin relative to the working
directory, which phase 3 has just set to $P (prover/). HAZYNC_RECEIPTS is referenced exactly
once in the whole script — on that line — so nothing else was ever going to make it take effect.

Workaround, which is how I got the number: cd "$OUT/receipts" and run agg-chunks there.
Result: BLOCK 962000 AGGREGATED in 1238.9s — succinct receipt VERIFIED.

⛔ The part that actually matters

Because the path is resolved from the working directory, an aggregate run from the wrong place does
not necessarily fail — it can silently pick up whatever chunk_*.bin happens to be there.

On the box I ran this on, /root/bench-default/receipts/ contains a full set of 16 chunk receipts
dated 2026-09-05, i.e. from a different guest, two re-baselines of context ago:

-rw-r--r-- 1 root root  511490 09-05 21:13 chunk_0.bin
...
count: 16

A complete set, plausible sizes, correct names. An aggregate that resolved to that directory would
fold cross-guest receipts and return a number that looks entirely reasonable. That is the failure
mode this repo keeps writing down: a harness result that is indistinguishable from a real one.

Suggested fix

1. Make agg-chunks honour HAZYNC_RECEIPTS (or take the directory as an argument) so the script
   and the host agree on one contract — they currently disagree silently.
2. Have agg-chunks refuse to aggregate receipts whose guest id is not the current one, rather
   than trusting the filename. The receipts carry their guest; the check is cheap and it is the only
   thing that makes a wrong-directory run loud instead of plausible.
3. Failing both, phase 3 should assert the receipt count and their mtimes against the proves it just
   ran, and stop if they do not correspond.

Item 2 is the one worth doing. 1 and 3 fix this script; 2 fixes the class.

Evidence: ~/hazync-v0.21.0-release-evidence/gpu-benchmark-962000-{l40s,aggregate}.log.

[defenwycke]

Correction to the "dangerous part" above — I overstated it, and the code already handles it.

I claimed an aggregate resolving to the wrong directory "would fold cross-guest receipts and return
a number that looks entirely reasonable". That is wrong. read_chunk_receipts verifies every
receipt against the compiled-in id before it is used, and has since hazync#153:

r.verify(METHOD_ID).unwrap_or_else(|e| panic!("chunk receipt {f} does not verify: {e}"));

The call is unconditional — no feature gate, no cfg. So the stale set in
/root/bench-default/receipts/ cannot be silently folded: it would panic with
chunk receipt chunk_0.bin does not verify. The "fix the class" item I listed as (2) was already
done before I filed this.

That leaves the actual defect, which is narrower and fails loudly either way: the host never reads
HAZYNC_RECEIPTS. grep -rn HAZYNC_RECEIPTS prover/host/src/ returns nothing, while
scripts/gpu-benchmark.sh:144 has been exporting it all along — so phase 3 resolved chunk_0.bin
against its own CWD (prover/) and died on a run whose sixteen proves had every one succeeded.

Fix in flight on fix/229-agg-chunks-receipts-dir: read_chunk_receipts honours HAZYNC_RECEIPTS
as the directory, defaulting to . so behaviour is unchanged when nothing sets it. That makes the
script correct as already written, rather than working around it with a cd.

Leaving the stale-receipts observation in the issue, but demoted: a directory of 16 correctly-named
receipts from an older guest is still a trap for anything that does not check the id — it just is
not a trap for agg-chunks.