Make the WHIR path's hash a parameter, and add an RPX256 instantiation

[MauroToscano]

What this is

PR #988's WHIR path hard-codes keccak-256 in three places — the Merkle backend, the Fiat-Shamir sponge and
the proof-of-work grind. This makes the hash a parameter with keccak as the default and byte-identical,
and adds RPX256 (XHash12) as the second instantiation, host and device.

⚠ All three are reached as of a783f2de. They were not for most of this branch's life: the Fiat-Shamir
sponge stayed keccak-256 under both arms through four measured A/Bs — see Four things a reviewer should know
went wrong below. Every timing number on this page predates the wiring, so each is a number for
RPX-Merkle + RPX-grind + keccak-transcript. They stand as measurements; this is their description.

It is not a performance change and does not claim to be. RPX is slower than keccak everywhere a host or
a GPU is doing the hashing, and the numbers below say by how much. The reason to carry it is a proof that
will be verified inside another proof: a keccak-f[1600] costs ≈73,700 trace cells in a field-native
verifier against RPX's 325, so a WHIR epoch proof verified recursively pays ≈227× less for its hashing. On
the recursion side that is the difference between ≈1.59 G cells per chain and ≈10.6 M — between a wrap about
twice today's cost and one about a third of it.

Nothing here is a soundness analysis, and one assumption is explicitly unproven: that swapping the hash
leaves the protocol sound. The security accounting is unchanged and remains what with_security's own doc
calls it — a conservative mirror of the univariate parameters, not an analysis of this protocol.

---

The measurement

Block 25368371, epoch 2^21, --features cuda, one backend per process, ABBA (keccak, rpx, rpx, keccak), all
four arms at 0cbc9623, same ELF and fixture, 10 Hz VRAM histograms.

	keccak (rr1 / rr4)	rpx (rr2 / rr3)
prove	39.86 / 39.48 s	78.13 / 78.83 s
verify	2.12 / 2.32 s	9.61 / 9.63 s
proof	156.32 MiB	156.32 MiB — equal to the byte
epochs	15	15
host peak	9.23 / 9.23 GiB	9.31 / 9.19 GiB
VRAM max	25,774 / 25,806 MiB	25,838 / 26,062 MiB
GPU-busy	19.5 / 20.7 s	60.4 / 61.3 s
device grinds	keccak 2996 · rpx 0	keccak 0 · rpx 2996

Paired Δ = +38.3 / +39.4 s, mean +38.8 s (+98%). Controls reproduce to 0.38 s, RPX arms to 0.70 s.

The one VRAM figure that looks like an outlier is not one: rr3's 26,062 MiB is a single 100 ms sample,
and the four arms' distributions agree through p90 (13,038–13,262 MiB median, 17,326–18,286 MiB p90, in the
sampler's own units as in the VRAM row above, with the keccak arms marginally higher). Every arm spends
the same 8–9 samples above 24,000 MiB, at the same 19–23% point of its run. See handoffs/W1.md for the
full reading; the short version is that a sampled maximum is not a level, and the RPX arms take twice as
many samples, so they catch the top of the same transient more often.

All of the cost is on the device, and it decomposes exactly:

Δprove 38.3 s  =  ΔGPU-busy 40.9 s  +  Δhost (−2.7 s)        closes to 0.1 s

The host term is negative: the RPX arm no longer grinds on the CPU while the keccak arm still does. Split
of the device term — every term measured, none derived, each from a subtraction of two integrals:

device hash term    R_h − K_h  =  25.0 – 25.9 s     65–68% of Δ
device grind term   R_g − K_g  =  14.7 – 15.9 s
                                  ─────────────
                                   40.6 – 40.9 s  =  ΔGPU-busy

A fifth arm — keccak with LAMBDA_VM_NO_GPU_GRIND=1, which moves that grind to the host — pins the last
unknown: K_g = 1.5 – 2.7 s of device keccak grinding, the spread being the two keccak arms' own 1.2 s.
R_g = 17.4 s from both pairs independently. So ≈25 s hashing and ≈15 s grinding.

The device grind's per-permutation ratio is ≈6–12× (RPX : keccak) — quoted as a range on purpose:
K_g is 1.5–2.7 s and its own noise floor dominates the quotient, so a point estimate here would be
precision the measurement does not have.

★ A finding for the keccak path, not the RPX one. That fifth arm also prices the existing device grind:
keccak WHIR prove is 82.32 s with the grind on the host against 39.5–39.9 s with it on the device, so
the device grind is worth 52% of the keccak WHIR prove on this block. Against it, run 1's host RPX grind
(≈510 s) puts the host grind ratio near 12× — a different code path from the merkle pass's 5.4× per
permutation (platform keccak with its assembly backend, against scalar RPX), so the two numbers are not in
tension and neither supersedes the other.

Why hashing costs what it does, measured independently (commit_phases, ethrex_10_transfers, two
rounds per arm): the merkle pass — leaf and tree hashing, isolated from stack, lift and encode, which are
identical between arms to two decimals — is 3.61 s keccak against 29.43 s RPX, a ratio of 8.15×. A tree
of L leaves does L leaf hashes and L−1 parents, so the permutation-count ratio is 1.5×; the
per-permutation cost is therefore ≈5.4×.

Proof size and host memory do not move. A 32-byte digest either way and no proof struct gains a field,
so the serialized length is equal to the byte across all four arms — a hash swap here is not a
proof-format change.

---

What is in it

The seam. One trait, multilinear::whir_hash::WhirHash, naming the Merkle backend, the Fiat-Shamir
configuration, the device kernel family and a name. One trait rather than four parameters, because separate
ones make the half-flip spellable — one hash's trees under another hash's sponge. That configuration is
self-consistent between prover and verifier, so it verifies, so nothing fails; it is silent by construction,
and the only thing wrong with it is that no single name describes the proof. With one name to write there is
nothing to assert against.

Commitment stays [u8; 32], so MultiProof, TableProof, StackedProof, ChainProof, CosetOpening
and Proof<Commitment> keep their layout, their rkyv derives and their serialized length. The parameter
flows through six modules and three types, each defaulting to KeccakWhir so existing call sites read
unchanged. Grinding became generic over its digest with no default — a defaulted proof-of-work hash
would silently keep grinding on keccak for a configuration that had moved everything else.

RPX256, ported not invented. The permutation, the leaf construction, the parent and all 168 round
constants come from prover::lfm::{rpo, rpx, algebraic_commit} on the per-table branch, byte for byte,
because the CUDA kernel and its known-answer tables are pinned to exactly those. A cherry-pick was not
available — none of the source commits is an ancestor of this base, and they are written against APIs it
does not have — so it is a port whose commit body names every source. The LFM machine is not carried
over: no chip, no AIR, no eDSL.

Two anchors of different strength, and the module says which is which:

• RPO's half is EXTERNAL. RPX is a schedule swap on RPO's geometry with the same constants, so seven
  fb_rounds composed are RPO256, and the tests replay miden-crypto's nineteen published hash_elements
  vectors through them — seventy-six numbers this repository did not produce, pinning ARK1, ARK2, the MDS row
  and its orientation, both S-box chains and the lane convention at once.
• RPX's own half is NOT. ⚠ miden publishes no RPX known-answer table (verified: its rpx/tests.rs has
  only structural tests). The RPX vectors here are the per-table branch's host implementation, transcribed
  from the CUDA KAT header — worth having because the kernel is pinned to those same tables, so a port
  reproducing them is byte-compatible with that branch's host and its device. It reproduced all of them on
  the first run: 11 permutation states including the canonicalisation witness, 7 leaf lengths, 2 parents.
• The E round and the schedule have no oracle at all and rest on independent algorithms.

The device. On the host a Merkle backend both names a hash and computes it; on the device it only names
it, so a key must travel with the request or a tree labelled RPX can be built by keccak's kernels with
nothing to notice. math_cuda::DeviceHash is that key, matched exhaustively at every launch site.
rpx_leaves_base_coset and rpx_leaves_ext3_coset are new — the per-table branch's seven RPX leaf
kernels all hash a row group, and WHIR's leaf is a fold coset.

Gated without a card. make test-rpx-host-kat compiles rpx.cu as host C++ through a shim and pins its
arithmetic, its schedule, its sponge, its parent and every leaf kernel's read pattern in seconds. The two
new kernels have their own case, built from the definition rather than from a second kernel call, with a
control asserting the strided read differs from the contiguous one. ⚠ Necessary, never sufficient: it cannot
say whether nvcc accepts the file or anything about execution rather than arithmetic. Both were then
confirmed on a real 5090 under nvcc 13.1.

LAMBDA_VM_WHIR_HASH={keccak|rpx}, read once per process. An unknown value aborts rather than
defaulting — rpx-256 silently proving keccak is a measurement worse than none. The banner prints on every
setting including the default, because a banner only for RPX cannot be told from a banner absent because the
code never ran.

The f64 leaves the multilinear query-count derivation (query_count.rs), replaced by Q62 fixed point
and enumerated against the f64 reference over all 4,259,840 points of the realistic parameter grid.
The shipped posture's 110 / 112 / 113 are unchanged, and the univariate derivation is untouched.

---

Also in the diff, and why

Three repairs the branch needed to be gateable at all, each its own commit so they can be taken or dropped
separately:

• f57a71a5 — four disk-spill call sites passed the wrong arity, so make lint's third pass could
  not build. Verified red at this PR's own head before this branch touched anything.
• 140e2694 — four clippy findings in crypto/multilinear/src/gpu.rs, likewise red at that head, in a
  file this branch's feature commits do not touch. make lint is now five passes and all five are green,
  the cuda pass for the first time on this stack.
• c9c452c6 — hash-metrics was in no lint pass and no test target, which is how its Merkle counters
  stayed keccak-only after a second hash arrived and would have reported ZERO for the RPX arm.

---

Four things a reviewer should know went wrong

The first measured RPX arm was 571 s, not 78. A guard added in this branch's own first commit dispatched
the grind to the device only for keccak, so every RPX grind fell to the host — ~2^20 RPX permutations each,
2,996 per block proof — while a correct, KAT-pinned grind kernel sat in the cubin, loaded and called by
nothing. Nothing failed and every proof was valid; only the clock said so. It was diagnosed from a GPU
utilisation histogram plus the host-only verify ratio, and the bench now prints device commit and grind
counts after every arm so the next one is named from inside the run rather than from outside the process.

The RPX arm was never running an RPX transcript, and four measured A/Bs did not notice. The transcript
is built and absorbed into before the with_whir_hash! block opens, so H does not exist yet where its
type would be named — and DefaultTranscript's second parameter defaults to keccak. All eight WHIR call
sites take that default. Nothing failed: every proof was valid, both arms differed from each other (the
Merkle backend and the grind are genuinely RPX), the banner printed the right name, and the counters showed
RPX kernels running. The arm was simply one third narrower than its label.

It was found by a change that had to move the bytes and did not. faadcc8f alters how every RPX squeeze is
handed out; the byte gate's RPX line was therefore required to move, and it printed
5226e4cf…031adb — the same value as before. A passing test would have said nothing here; it was the
pinned line's refusal to move that carried the information, which is the argument for pinning it rather
than asserting != against the other arm.

Also recorded because it is the same lesson twice: a test named the_transcript_follows_the_configuration
has existed on this branch since the seam landed. It constructs both transcript types itself and shows they
draw different challenges — true, and it never mentions the prover. It is renamed to what its body asserts,
and the system test it claimed to be arrives with the wiring.

A performance change was designed against a doc comment nobody read. H4 kept each commitment's Merkle
tree to remove a second leaf-hash pass; the retention is O(chains) rather than O(1), it filled the card, and
the function being changed already said so. Measured, reverted, and written up under What this does not do
below — including the counter that makes the failure mode self-reporting next time.

Two instruments printed the wrong arm's label. Both shape benches and then the byte gate itself pinned
keccak at their prove sites, so under LAMBDA_VM_WHIR_HASH=rpx they reported keccak's numbers. All three
now go through the dispatch, phases refuses to run under a hash it cannot honour, and the byte gate
asserts rather than prints: same length under both arms, the keccak line equal to its constant, the RPX line
required to differ.

---

The squeeze reversal, and a soundness term it was carrying (3e8c6fac)

DefaultTranscript::sample reversed all 32 bytes of every squeeze before handing them out. Under keccak that
is a harmless byte convention. Under RPX the squeeze is already four canonical big-endian felts, so reversing
them hands the sampler the last felt's bytes backwards — and a field-native verifier then spends rows undoing
it: V1 sizes the replay cost at +9.7 M instructions and +456 M cells per epoch verify.

TranscriptHash::REVERSES_SQUEEZE makes it a per-configuration constant — true keccak, false RPX — and
CANDIDATES_PER_COORDINATE arrives with it (None, Some(1)). The two are one change: the schedule is a
consequence of the byte order, which is why an earlier revision of that file argued at length that Some(1)
could not be claimed here. The argument was right; its conclusion is now inverted, and both paragraphs are
rewritten rather than deleted.

⚠ The reversal was also biasing the RPX sampler, which is a better reason to remove it than the cost. A
candidate was byteswap(canonical(felt)), which is >= p exactly when the felt's low four bytes are all
0xFF — witness 0x00000001ffffffff, canonical, whose byteswap is 0xffffffff01000000 and is rejected. The
rejection sampler therefore drew uniformly from a subset of [0, p) missing ~2^32 elements: ~2^-32
statistical distance per coordinate, ~2^-17 of added soundness error over an epoch verify's ~3e4 draws on a
loose hybrid bound. Not a demonstrated attack — the excluded set is fixed and public — and never exercised
in production, because the RPX transcript was never wired to a prover. It was inherited from the keccak
transcript, where it is harmless because keccak's 8-byte groups are uniform on 64 bits. Found by V1;
exhibited in the_reversal_would_have_biased_the_rpx_sampler, which carries the witness, generates the whole
excluded set rather than sampling it, and checks a million felts of the complement to show the bias is
exactly that one and no larger.

Soundness of the result: with the permutation ideal, each 8-byte group IS canonical(felt) and
FieldElement::from maps it back, so the round trip is the identity on F and each coordinate is exactly
uniform, with no rejection step left to bias anything. The reversal was a fixed public bijection, and
composing a random oracle with one leaves a random oracle. Absorb order, domain separation, padding, the
grind preimage, the Merkle construction and every keccak byte are unchanged.

This commit moves no proof bytes on either arm — both gate lines read exactly as before, which is this
change's control and, as above, how the missing wiring was found.

---

The transcript reaches the configuration (3f75574b, a783f2de)

DefaultTranscript's hash parameter has a default, so DefaultTranscript::<E> is a keccak transcript
while looking like it names no hash — and the transcript is built and absorbed into before the
with_whir_hash! block opens, so H does not exist where the type would have to be named. All eight WHIR
call sites wrote the default. The RPX configuration therefore ran an RPX Merkle backend, an RPX grind and a
keccak sponge, and no instrument disagreed: valid proofs, genuinely different arms, the right banner, RPX
kernels in the counters.

The fix is an equality the compiler checks, not a convention. HasTranscriptHash names the hash a
transcript runs on, and multi_prove/multi_verify require
T: HasTranscriptHash<Hash = <H as WhirHash>::Transcript>. Requiring each site to name a hash would not have
caught this — a site can name the wrong one as easily as take a default. The compiler then found the defect
itself: six type-mismatch errors, one per production site, before any test ran. And the guard test's mutation
can no longer be written — restoring the old spelling gives
error[E0271] … expected associated type, found KeccakTranscriptHash.

⚠ The default hash parameter is NOT removed, deliberately. Doing so would touch 344 turbofish sites
across ~60 files, all STARK code, for which keccak is not an unchosen default but the answer. The bound
already makes the WHIR bad state unspellable, which is the part that matters; the rest is verbosity. Parked
as a possible mechanical follow-up, not scheduled.

Moved inside the dispatch with the transcript: two owed computations that fork it to draw z and
alpha. Those challenges are a function of the configuration's sponge, so computing them against another
hash is the same defect one level down, and just as quiet.

The counters that would have named it (3f75574b): transcript_absorbs{,_keccak,_rpx} and
transcript_squeezes{,_keccak,_rpx}, bumped from DefaultTranscript's own append and sample methods rather
than from a hash — a counter living inside keccak cannot see an algebraic sponge, and a counter in a digest's
update mixes Merkle leaf bytes with Fiat-Shamir bytes and answers neither question. Rpx256Digest also
bumps the pre-existing count_absorb/count_total, which had exactly one call site (the keccak wrapper) and
so read zero for every RPX proof ever measured, while total's own documentation claimed to count
transcript squeezes.

Both arms are instrumented and both are asserted, because one side is not evidence: "rpx > 0, keccak 0" is
equally true when the keccak transcript ran and nobody counted it. transcript_unattributed() reports what
neither bucket claimed, so a third configuration arriving without a counter shows up instead of looking like
silence. The per-arm bench line prints absorbs K/R · squeezes K/R · unattributed K/R beside gpu commits.

The RPX gate line moved, which is the proof the wiring reached the prove path — nothing else in these
commits changes proof bytes:

arm	line	bytes
keccak	7b8afea2618350600e99bb67200bb4447d962f753b6e858ee0982336436e6dd3	6880 (unchanged)
rpx	dcc0e8d52a80a6c9ee4ed9911d54b41e7df132d209fbf91e43018b0ac01c4985	6880 (was 5226e4cf…031adb)

Both arms are now pinned to constants. The RPX arm previously only had to differ from keccak's, and that is
precisely why the defect survived: an arm that can only report a category cannot report a surprise.

The statement is padded to a field element boundary (8c933bd6)

⚠ THE THIRD PROTOCOL-TOUCHING CHANGE ON THIS BRANCH, after the squeeze reversal drop and the DECODE
preprocessed commitment, and like them it is on the list Mauro holds the veto over. It moves the bytes of
every WHIR statement, so every continuation proof this branch produces differs from one produced before it.

The transcript hashes BYTES. The algebraic configuration's sponge re-slices everything absorbed since its
last squeeze into field elements every eight bytes (rpx::sponge_leaf_bytes), so a value absorbed at an
offset that is not a multiple of eight straddles two of them — and the field machine that replays this
transcript can only reproduce such an absorb by decomposing bits.

Every window after the first is aligned already: a squeeze leaves the sponge holding its own 32-byte output,
and roots (32), extension elements (24), grind nonces (8) and final values (24) are all multiples of eight.
The first window is the exception, because it opens with the statement and the roots land wherever the
statement ended.

The pad is COMPUTED, and that is the whole point. The roots do not follow the statement's fixed prefix;
two variable-length fields sit in between. The epoch statement's fixed prefix is 237 bytes, and padding that
to 240 leaves the roots at (|public_output| + |table_num_vars|) mod 8 = 2 mod 8 at the shape this system
runs — it would move every pinned constant and align nothing. So each statement function accumulates its own
length beside its append_bytes calls, with absorb_table_counts reporting its own width, and
pad = (8 - len % 8) % 8. No literal, and no constant a caller has to keep in step.

The padding absorb is made even when the pad is empty, so "one padding absorb per statement" holds for
every shape and an absorb count stays a function of the statement's fields rather than of its lengths.

Padded: the continuation epoch, the cross-epoch and the monolithic multilinear statements. Not padded: the
univariate statement, whose sponge is keccak (it never re-slices a byte stream into field elements) and whose
bytes the block identity lines pin.

What moves, and what does not

instrument	before	after
transcript pair pin, absorbs	prove 583,924 · verify 584,061	prove 583,940 · verify 584,077 (+16, one per statement)
pin, squeezes · states	183,226 · 183,256 · 2,996	unchanged
owed	137 · 30 · 0	unchanged
absorb_bytes	—	+Σ pad, one pad per statement, 0..=7 each
WHIR byte gate, both arms	7b8afea2…6dd3 · dcc0e8d5…4985 · 6880	unchanged, and it cannot move

⛔ The byte gate is not a witness here. Its fixture builds its own transcript from b"whir-identity" and
calls multi_prove directly, so it absorbs no statement at all — multi_prove begins at the roots. "The gate
is unmoved" is the assertion this change owes, not evidence that it did nothing; both arms were run and both
printed their pinned lines. The same fact means the gate's own first window (13 seed bytes, then roots) is not
aligned, and it must never be quoted as a witness that a real proof's is. That is now written beside the
constants.

The tests, and what each of them can fail on

tests::statement_alignment_tests, five tests, card-free:

• Three sweep the statements against a recording transcript that stores the window offset of every absorb.
  Each asserts the property first (the statement ends on a multiple of eight), then two corroborating
  derivations: the total equals a closed form written from the field list — a second derivation from the
  production accumulator, and the only place the two can disagree — and the absorb-call count equals its own
  closed form, which is what a padding absorb skipped at pad == 0 fails. The epoch sweep also asserts its
  shapes do not all share one residue, so it cannot be satisfied by a constant pad.
• padding_only_the_fixed_prefix_would_not_align_the_roots writes the arithmetic that killed the constant-pad
  design as an assertion, so it cannot be forgotten: fixed prefix 237, rounded 240, roots at 2 mod 8.
• ★ every_absorb_of_a_real_prove_is_field_element_aligned drives a real multi_prove through the
  recorder, under both KeccakWhir and RpxWhir, and requires every absorb after the statement to be
  aligned — 119 absorbs, 0 misaligned, at a pad of 2 and a pad of 0. The recorder is not trusted: it
  mirrors DefaultTranscript's duplex output buffer (the only part that says where a window ends) and the
  test first requires the recorded prove to serialise to the same bytes as the same fixture proved through the
  production transcript. A mirror that drifted would draw different challenges and fail there.

Mutations, each run and each failing on the assertion named:

the padding absorb removed          -> epoch ends at 271 = 7 mod 8 at (po 0, tnv 34); global at 149 = 5;
                                       monolithic at 270 = 6; the real prove fails too
the absorb skipped when pad == 0    -> the CALL COUNT at (po 2, tnv 1): 25 against 26, bytes and
                                       alignment both still correct — only this assertion sees it
a field absorbed, not accumulated   -> epoch ends at 274 = 2 mod 8, and the real prove names the
   (`len += table_num_vars.len()`)     absorb it broke: "1 of 119 values ... [(241, 32)]" — a root

The pair pin is now a base plus a per-branch term (d4f983f8)

The absorb columns carry EPOCHS * NUM_TABLE_KINDS — one u64 per per-table count, per epoch statement —
and that kind count is not a constant of the protocol: this lineage binds fourteen and the merged one
fifteen, because per-table adds TableCounts::blake3 (legitimately: the BLAKE3 table is conditional and its
count is the one entry a verifier cannot derive, which is why per-table bumped both domain tags for it). The
box found that as a pin FAILURE at the merged base, +15 on both sides.

So the pin now stores branch-independent bases and derives the totals, with the kind count read from the
struct rather than written down. NUM_TABLE_KINDS is guarded by two compile errors that need each other: the
exhaustive destructure fails when a field is added to TableCounts, and the array's return type fails when
the field is pushed in without bumping the constant. A new test checks the split is the protocol's, and a
mutation confirms both halves (a bumped constant without the field does not compile; a base off by one fails
the_pinned_pair_is_the_measurement and the_pinned_constants_differ_by_owed).

⚠ Half the provenance is a PREDICTION and the comment says so: the bases come from the box's measured
583,924 / 584,061 at c73568f4 plus this branch's +16, which has not been measured yet. These constants
are what will say so if it is wrong.

---

What this does not do, and what is next

• No recursion. This is the hash seam the WHIR recursion needs, and nothing above it.
• No claim that the swap is sound; the query count and posture are unchanged.
• ⚠ The 275 tests in crypto/multilinear/src still do not run in CI (-p multilinear is absent from
  pr_main.yaml), which is orthogonal to this PR but worth knowing while reviewing it.

The largest remaining term is not the hash — and the attempt to remove it was measured and reverted.
The WHIR device path hashes each commitment's leaf layer twice: commit builds the tree, takes the root
and drops it, and paths rebuilds the whole thing per opening. Every commitment here is opened, so every one
pays twice — by construction about half of the ≈25 s of RPX device hashing above, and the keccak arm pays the
same structure at its own ≈3.8 s.

3e38c9d9 kept the tree so the second pass would go away. It was measured on the card and it lost:

arm	prove	vs control	host peak	VRAM max	util
keccak, cache	55.50 / 56.04 s	+15.6 / +16.6 (band −1.5/−2.5)	28.9 GiB	31,438 MiB	33%
rpx, cache	80.50 / 80.86 s	+2.4 / +2.0 (band −10/−13)	28.9 GiB	31,438 MiB	51%
keccak, control	39.86 s	—	9.23 GiB	25,774 MiB	46%
rpx, control	78.13 s	—	9.31 GiB	25,838 MiB	69%

Not a cache miss: it returned the hashing it promised, and the ~+15 s penalty is the same in both arms.
The retention is one tree per commitment in the group, not one tree. StackedCommitment::commit builds
every chain's commitment before it returns — all the roots enter the transcript before any query index is
drawn — and the openings follow one chain at a time, so the last chain's tree lives from its commit to the
end of multi_prove. Ten chains at 512 MiB is 5,120 MiB; the measured VRAM delta is 5,664 MiB, eleven trees
exactly (ten round-0, one fold pair). No placement of an eviction call bounds that peak, because all N trees
exist before the first opening.

Past the ceiling the cost stops being memory: a failed device allocation becomes None, commit_stacked
takes its host arm, and from_codeword then retains a 1 GiB host codeword and a 512 MiB host node array
for the rest of the proof — the +19.7 GiB, the utilisation fall, and the seconds.

⚠ This PR's own code said so before any of it was built. whir_commit.rs's paths carries, unchanged
from aa38739d: "keeping it would cost half a gigabyte of device memory per commitment for the whole
proof". An earlier draft of this paragraph quoted that sentence, called the figure "derived rather than
quoted", re-derived the 512 MiB correctly — and read the window as two live commitments, 544 MiB, because it
reasoned about the local variables in prove_with_factors and never asked who owned them. The reservation in
StackedCommitment::commit says it a second way: "nine codewords of room instead of sixteen" budgets a
retained codeword per commitment and no tree.

So 2997b97a removes the cache and with_tree is the one place that builds and frees, carrying the finding.
What the run earned is kept: the per-codeword and process-wide leaf-pass counters, Backend::free_vram_bytes
(the driver's own accounting — reserved_bytes() counts what callers promised, which is how the retention
stayed invisible to a unit test that passed), and a group-scale guard, a_group_holds_only_its_codewords_before_any_open: four live, unopened commitments must take under
256 MiB from the driver, where four codewords are 128 MiB and four codewords with their trees are
384 MiB — the blocking is chosen so a tree is two codewords, which is what makes the margin survive the
allocator rather than only the arithmetic. The shipped unit test dropped one bare codeword and
passed on the leaking prover, because an O(chains) peak is not a state one codeword can be in.

107bde98 adds the counter that would have named it from inside the run: host fallbacks prints beside
gpu commits, so a device commit that silently degrades to the host is never invisible again.

Removing the second pass still looks worth having, and one shape remains: bring the tree home over pinned
memory instead of keeping it on the card — host RAM has the room the card does not. The same comment prices
that too ("a pageable copy of half a gigabyte is the slowest thing in the commit"), and the pinned bandwidth
that would decide it has not been measured. Flagged, not built.