Skip to content

WHIR no-epoch (prove-and-retire) prover: block 25368371 — work in progress - #1014

Draft
MauroToscano wants to merge 1720 commits into
mainfrom
noepoch/whir
Draft

MauroToscano wants to merge 1720 commits into
mainfrom
noepoch/whir

Conversation

@MauroToscano

@MauroToscano MauroToscano commented Sep 30, 2026 •

Copy link
Copy Markdown
Contributor

One WHIR (multilinear) proof per block, with no epochs (the prove-and-retire / VADCOP shape). This is a second prover next to #1010's epoch-based one. #1010 stays the reference and this branch does not touch it. The branch starts from #1010's head f3d359998; compare against f3d359998 to see only this work.

Status: draft, work in progress. One binary (FAST 416, #1010's head 88b0d31 merged in, ABBA × 2): the block tree 23.20 s whole vs #1010's epoch tree 31.80 s, −8.60 s. Since then: 20.89 s whole at d9d0ac5 (FAST 424: base 16.76 + recursion 4.13), with the batched argue on by default, ops dropped after commit (M1), the lean walk and paged executor memory (E1/E4), and one prepared stack per group. e06dce5 added narrow trace storage (M4: same bytes, time-neutral, max RSS 1× 36.2 → 29.5 GiB, 4.13× now proves). 3cfffe2 added the KECCAK and ECSM split (§6: the same tables and proof bytes on every block measured so far, FAST 830). 01da99f uploads phase A's next group beside the current commit (prover-only, same bytes, base −0.60 s at 1×, FAST 832). 59e9890 lays out the streamed chunks on three threads by default (E3; prover-only, same bytes; whole block −0.48 s to 19.75 s and max RSS −1.51 GiB at 1×, FAST 838). 82f9046 re-hashes phase B's kept-top paths in parallel (prover-only, same bytes; phase B −0.96 s, whole block −0.82 s to 18.90 s at 1×, FAST 843 + 844 pooled). d169edd lets the tree's leaves execute while their artifacts are built (prover-only, same bytes; level 0 −0.24 s, whole block −0.24 s to 18.54 s at 1×, FAST 841 + 842 pooled). 70eee3e lays out the rest in waves and builds KECCAK_RND as its tables (W, lane i-m4b; same bytes; max RSS 88.9 → 79.5 GiB at 4.13×, base −0.14 s at 1×). fac261f lets the tree's first finished leaf execute during phase B (R2-ii; prover-only, same bytes; whole block −0.24 s to 18.39 s at 1×, measured before the merge with W, FAST 845 + 846 pooled). 365e3ab packs the finish's tables as they are built and commits them narrow (b2, lane i-m4b; same bytes; max RSS 78.8 → 52.1 GiB at 4.13×, 28.5 → 22.5 at 1×; base −0.36 s at 1×). 351a773 adds a device readout to the tree test (test-only), and the measurement posture moves to the card memory pool's code default, which retains freed memory: a baseline shift, not a prover change (whole block 17.91 → 17.27 s at 1×, FAST 848 + 849 pooled; every number above was taken under the old posture and stays as measured). 9a18ab5 makes the prover refuse a block over the group maximum as its groups close, with the verifier's own error (lane i-m4b; prover-only, same bytes, FAST 858). 54aae28 builds the recursion tree's node programs beside the tree, each level proving as its own nodes arrive (A; prover-only, same bytes; median whole block 242.69 → 233.80 s, −8.89 s, BIG 611; 2.66× recursion −1.22 s; 1× unchanged), and closes a latent card-permit re-entry that parked BIG 569. d107a91 proves each node of the tree as soon as its own children are proved (C; prover-only, same bytes; median recursion −1.73 s, BIG 612; 2.66× recursion −0.49 s, BIG 614 + 615; 1× unchanged). 0d61081 spills the held tables to disk when memory is short (lane i-m4b; prover-only, same bytes; #1013's store and auto policy, on by default; nothing spills at 1× or 4.13× by default, and the 1× time is unchanged within noise; BIG 616, ULTRA 006). acfd54a counts phase 4's BITWISE lookups in slices (#1013's c369843, ported by lane i-m4b; prover-only, same bytes; median whole-run VmRSS 108 → 89 GiB, phase A −9.5 s, BIG 619; 1× base −0.30 s, ULTRA 010). c55dec4 lets the tree's top execute each child's share as that child is proved, while a child is still unproved (B′; prover-only, same bytes; median recursion −0.47 s, BIG 613 / 620; 1× unchanged, where the top executes whole, ULTRA 009). 806c211 lets each node of the tree execute from its program as soon as it is emitted, with only its prove waiting for its artifacts (b′; prover-only, same bytes; 1× recursion −0.27 s, ULTRA 012; 2.66× −0.41 s, BIG 624; median unchanged). Head cbfa7d7 grinds the block's WHIR proofs at 18 bits instead of 20 and opens 114 queries instead of 112 (§7, a format change approved by Mauro 10-05; proven bits unchanged at 130.393; 1× whole block −0.27 s, ULTRA 019; median whole block −3.42 s, BIG 628). Every format change below but §6 (the port of #1013's S0a, gated FAST 830) is approved by Mauro (10-02; §7 on 10-05); the cryptography team reviews them at the end (CRYPTO-REVIEW.md rows W-0…W-6, W-8, W-9).

What it is

  • prover::block_whir::prove_block_whir / verify_block_whir. The whole block is one MultiProof:
    • every table is cut into instances of at most 2^21 rows, and KECCAK_RND into 2^16-row instances;
    • memory is the monolithic PAGE argument, with no local-to-global bookend and no cross-epoch proof.
  • The tables are packed into groups of at most 3 stacked polynomials (2^27 each).
    • Phase A commits each group and retires it: the codewords go, and only the top of each tree stays on the host (the bottom 4 levels are dropped).
    • The roots block: every root goes into the transcript, then (z, α, β) are drawn once.
    • Phase B proves each group on its own fork S_post ‖ g: upload again, argue (LogUp-GKR), re-encode with the NTT alone, open. The dropped tree levels are rebuilt from the queried cosets and checked against the kept nodes.
    • The bus is checked once, over every table of the block.
  • Streamed phase A. The executor runs in 2^20-cycle windows feeding the shared WindowedTraceBuilder (noepoch/windowed-builder, also used by STARK no-epoch (prove-and-retire) prover: block 25368371 — work in progress #1013). Every full chunk of CPU, MEMW_R, MEMW_A, MEMW, LOAD, LT, SHIFT and STORE is laid out and committed as soon as it exists.
  • The builder is deterministic: on block 25368371 the whole-run build and two windowed builds under host contention give identical per-table digests (FAST 411; 129 tables row for row, the six HashMap-ordered tables as row multisets).

⚠ Format changes (all approved by Mauro, 10-02 (§7 on 10-05), but §6, the port of #1013's S0a; for the cryptography team's end review; ledger rows W-0…W-6, W-8, W-9 in CRYPTO-REVIEW.md)

The block is one WHIR proof (BlockWhirProof, one MultiProof) over all of the block's tables.

  • Phase A commits the tables in groups as the trace is built. Each group is at most 3 stacked polynomials of 2^27, and each group is committed and retired as it closes.
  • The challenges. The transcript then absorbs the statement, the groups' roots and the derived prepared roots, and draws z, α, β.
  • Phase B proves each group on its own fork of the transcript (S_post ‖ g).

Every parameter below is a verifier-side constant. None is read from the proof.

constant value meaning
BLOCK_GROUP_POLYS 3 a group of two or more tables stacks into at most 3 polynomials of 2^27
BLOCK_MAX_GROUPS 64 at most 64 groups
BLOCK_MAX_TABLE_VARS 27 no table stated over 2^27 rows
BLOCK_MAX_KECCAK_RND 2^12 at most 4096 KECCAK_RND tables
BLOCK_KECCAK_RND_MAX_VARS 16 each at most 2^16 rows
BLOCK_MAX_ECDAS 2^12 at most 4096 ECDAS tables
BLOCK_ECDAS_MAX_VARS 17 each at most 2^17 rows
BLOCK_MAX_KECCAK 2^12 at most 4096 KECCAK tables
BLOCK_KECCAK_MAX_VARS 18 each at most 2^18 rows
BLOCK_MAX_ECSM 2^12 at most 4096 ECSM tables
BLOCK_ECSM_MAX_VARS 17 each at most 2^17 rows
ArgueFormat::BATCHED bins of 2^26 input cells change 5 below
PRODUCTION_WHIR_GRIND_BITS 18 (Q 114) each WHIR chain's query grind; change 7 below
LEAF_PERMS_CAP, BLOCK_FAN_IN 279,000 permutations; 3 the recursion tree's leaf cap and fan-in

1. The group partition is in the statement

What. The streamed prover packs tables into groups in the order their chunks complete. It writes the partition (per group, its tables' indices) into the statement. The transcript absorbs it before any root.

Verifier. The verifier checks:

  • that the partition is exact (every table once);
  • that each group of two or more tables fits within 3 stacked polynomials under the verifier's own stack cap;
  • that there are at most 64 groups.

It then rebuilds every group's stack layout itself.

Security. Proven bits are unchanged.

  • Each WHIR chain is 130.393 bits, and the proof minimum under the campaign's min-over-phases accounting is 128.946.
  • The chain heights are capped by BLOCK_MAX_TABLE_VARS (change 3), so no partition can make a chain taller than 2^27.

Proof bytes vary from run to run. Arrival order depends on thread timing, and the hash-ordered tables' row order (LT, EQ, BYTEWISE, BRANCH, MUL, DVRM) follows a hash state that is random per process. Mauro, 10-02: "the proof not having the same bytes it's fine, they never had the same bytes anyways".

  • Byte-identity tests run with LAMBDA_VM_FIXED_TRACE_HASH=1 (fixed hash keys) and LAMBDA_VM_DETERMINISTIC_GRIND=1. Under both, two processes prove the same bytes (FAST 423).
  • Fixed keys let a crafted program steer many operations into one bucket, so they are a test setting, not production's.

2. Prepared openings, one stack per group (approved by Mauro, 10-02: "it's a standard technique, go ahead")

In short. This is #1010's existing prepared DECODE opening, carried into the block format. It is extended to the dense genesis pages and stacked per group.

  • Costs: +0.14 s of base and −0.57 s of recursion (4.71 → 4.14 s).
  • The verifier recomputes every derived root from the ELF.

What. The recursion guest cannot evaluate DECODE's five 2^20 preprocessed columns, nor the dense genesis pages (millions of rows), on its own. So each group's prepared tables (DECODE and the dense genesis pages chosen by genesis_stack_plan) have their leading preprocessed columns stacked into one commitment.

  • Both sides derive this commitment from the ELF and the partition. The verifier recomputes every derived root from the ELF: verify_block_whir, and verify_block_tree's plan. The prover's own roots only shortcut the prover's side.
  • Its roots are absorbed after the groups' roots, before z.
  • It is opened on the group's fork after the group's own opening, each table's block at that table's point.

Negatives, on a guest with two dense genesis pages. Each is refused by the host verifier and by the recursion leaf, and admitted when the openings are skipped (the mutation):

  • two groups' openings swapped;
  • a block opened at another table's point.

Wrongly committed stacks are refused at the roots block: two pages swapped, a page holding another page's columns, another program's DECODE.

Cost. One stack per group costs +0.14 s of base (FAST 419; one commitment per table cost +0.49 s) and saves 0.57 s of recursion, by taking 90 k permutations out of the leaves. BlockFormat::prepared = false turns the openings off, for measurement only.

3. ECDAS split; table heights capped

What.

  • ECDAS is split into tables of at most 2^17 rows, as KECCAK_RND is at 2^16 (split_ecdas).
  • A scalar multiplication may straddle two tables. Its steps chain only through the Ecdas bus, keyed by the call's timestamp and the step's (round, op).
  • The frame (the host verifier and the tree plan) refuses:
    • a KECCAK_RND table over 2^16 rows;
    • an ECDAS table over 2^17 rows;
    • any table over 2^27 rows (REV-JUDGE G2). A 2^30 table would otherwise make a 2^30 chain at 127.39 bits.

Why. At a median block, one ECDAS table (2^19) argues on a 12 GiB tree. At p90 (2^20) it stacks into five polynomials on a 24 GiB tree.

Gates. FAST 534 and 535: the negatives, 3 mutations caught.

4. Recursion leaf: the leaf cap (G3) and the inverse share (W1)

  • G3. The tree plan refuses a group over LEAF_PERMS_CAP. With no fixed leaf count, it adds leaves while the heaviest leaf is over the cap. The block's own partition is unchanged.
  • W1, on by default. Each WHIR leaf publishes its bus share Σ p/q as p · ediv(1, q), which has no satisfying assignment for q = 0 whatever p is. The former ediv(p, q) left the share free at p = q = 0 (≈ 2^-160 under GKR soundness).
    • The leaf gains one XALU op per table, so every WHIR tree id changes. The base proof is untouched.
    • Gate: FAST 536. LFM_WHIR_SHARE_INVERSE=0 keeps the former form.

5. Batched argue, on by default since d9d0ac5 (BlockFormat::argue = ArgueFormat::BATCHED; Mauro, 10-02: "batch the constraints")

What. Each group's tables are argued together on the group's fork:

  • one lockstep LogUp-GKR ladder per bin, the tables packed first-fit-decreasing under 2^26 input cells;
  • one front-loaded constraint sumcheck per group;
  • no claim reduction for unshifted tables (every VM table).

Verifier side. The verifier derives the bins from the statement's shapes and its own cap; the variant is never read from the proof. The proof carries one BatchedArgue per group in BlockWhirProof.argues, and proof.tables is empty under this format. The recursion leaves verify the same format (lane i-batch2, N-4).

Security at the block's measured inputs (D-BATCH §3.2's formulas; re-checked at FAST 424's inputs: |T| ≤ 60 tables a group, ≤ 51 trees a bin, ≤ 2^28.87 input cells, bus messages ≤ 204 elements, N_C ≤ 413, D_max 4, n ≤ 21; L = 300):

term bits
LogUp fractional 147.22
GKR step batching 185.34
GKR sumcheck round 190.42
GKR line 186.33
zerocheck point 187.61
constraint β (N_C − 1 = 412) 183.31
claim batching 184.52
constraint rounds 190.00

Every term is above the WHIR phase, so the proof minimum is unchanged: 128.946 under the campaign accounting (130.393 for the WHIR fold under the calculator of record).

Measured.

  • FAST 348: phase-B argue −0.685 s, whole block −0.385 s (≈ −0.65 s attributable).
  • FAST 424 at the flip (d9d0ac5, A B B A, one binary): base 17.56 → 16.76 s (−0.80), whole block 21.85 → 20.89 s (−0.96), recursion −0.16 s. Every proof verified; determinism within each format 2/2.
  • Peaks: BIG 402/403 found none raised at 1.0 / 1.31 / 1.80×. BIG 395 at 1.80× with ops dropped: per-table 62.39 against batched 63.12 GiB (+0.72).

The knob. ArgueFormat::PerTable (one argument per table, the format before) stays measurable, with BLOCK_WHIR_ARGUE=per-table in the real-block tests. At the per-table format, the MultiProof, the prepared openings and the partition are digest-equal to the head before the batched merge (BIG 393).

6. KECCAK and ECSM split; their heights capped (the port of #1013's S0a; landed at 3cfffe2; approved by the lead under Mauro's any-block target, Mauro to confirm)

What.

  • KECCAK is split into tables of at most 2^18 rows and ECSM into tables of at most 2^17 (split_keccak, split_ecsm), as ECDAS is at 2^17.
  • A row of either is one whole call (a permutation, a scalar multiplication), so a cut falls between calls. A call reaches its rounds (KECCAK_RND), its steps and scalar bits (ECDAS) and its memory only through buses keyed by its timestamp.
  • The frame takes up to 2^12 tables of each and refuses a KECCAK table over 2^18 rows or an ECSM table over 2^17. Every other verifier keeps both to one table.

Why. A keccak-heavy block at the gas limit makes about 2^21 permutation calls. One KECCAK table that tall stacks into eight polynomials of 2^27, against a group budget of three. At its cap each table fits one polynomial.

Bytes. Every block measured so far has KECCAK ≤ 2^17 rows and ECSM ≤ 2^11, so it builds the same tables and the same proof (FAST 830: digest 07d1bd43… unchanged on block 25368371).

Gates. FAST 830: KECCAK and ECSM forced into 4 tables each on block 25368371 prove and verify, base and tree; the count and height negatives; mutation C caught.

7. WHIR grinding 20 → 18 bits, queries 112 → 114 (landed at cbfa7d7; approved by Mauro, 10-05)

What.

  • Each WHIR chain grinds 18 bits instead of 20 before each round's queries, and opens 114 queries instead of 112 to buy the two bits back. At every block height (15 to 27 variables) Q = num_queries(2, rounds, 128, 18).

  • One site, multilinear_prove::chain_config_under. Every side of the block reaches it through BlockFormat::chain_config:

    • the prover's group chains and prepared openings;
    • verify_block_whir;
    • the plan the recursion leaves' in-guest verifier is emitted from.

    The statement absorbs Q and the grind bits.

  • Scope: the block's WHIR proofs only. The recursion tree's own leaf, node and top proofs are STARK proofs (FRI) and keep their own grind.

  • It ports WHIR recursion on GPU (RPX) with ZisK-style proof formats: block 25368371 in 32.62 s #1010's grind 18 (landed there at 2687e48). Opt-out: LAMBDA_VM_ZF_WHIR_GRIND_BITS=20, which reproduces the previous proofs byte for byte.

Security. The calculator of record: Johnson bound, η = 1/300, the fold proof of work unground.

  • The binding WHIR phase is the unground fold at 27 variables, 130.393 bits at both settings. Neither Q nor the query grind reaches it.
  • The query phases move from 130.926 to 130.907 bits (15 to 27 variables).
  • The argue terms and the tree's FRI phases do not move. The proof minimum stays 128.946 under the campaign accounting.
  • The grind bits are a verifier constant:
    • a block ground at 18 bits is refused by a verifier at 20, and the reverse;
    • a leaf emitted at 20 refuses an 18-bit block;
    • at chain level, the host and the machine refuse fewer grind bits at the same Q.

Measured behind the knob, on c55dec4, one binary per box:

  • 1× (ULTRA 019, 8 + 8 runs after one warm-up):
    • phase B −0.344 s (t −12.9), from the grind falling 0.577 → 0.214 s;
    • whole block −0.27 s (18.71 → 18.44 s);
    • recursion −0.01 s, i.e. unchanged.
  • Median 25475471 at i-m4b's cap-128 exploration head (BIG 628, A B B A):
    • phase B −3.48 s;
    • whole block −3.42 s (226.51 → 223.09 s);
    • recursion −0.12 s;
    • both arms verified.
  • The leaves' cost. The leaves verify two more queries per chain: +1,041 permutations per three-polynomial group. On these two blocks no leaf table crossed a power of two, and the leaf counts did not change (3 at 1×, 23 at the median).

Bytes. The proof bytes change. Under the fixed trace hash and deterministic grind, the 1× top proof's digest is b9b4826d… at the default and 0da6fea9… under =20. Both trees are accepted (ULTRA 015, at this head).

Known limit. The leaf cap (279,000 permutations) sits above 2^18 LFM_HASH rows, and 18 bits moves every leaf about 1.7 % closer to that doubling.

  • On the median, the heaviest leaf's LFM_HASH is 256,549 of 262,144 rows: 2.1 % headroom.
  • A heavier block can cross it. That doubles the table, which costs that leaf's prove; it does not affect correctness.

Gates.

  • Laptop: zf_format::; the chain refusals and the legacy-bytes KAT; the pins the flip moved; the host block refusal.
  • ULTRA 019: the leaf refusal (box tier); the opt-out byte-identical to c55dec4.
  • ULTRA 015: the landing sha's identity, above.

One-binary A/B: the block tree vs #1010's epoch tree (FAST 416, noepoch/whir @ 454dad6)

Eight arms E B B E E B B E on the same binary (md5 checked after every arm):

whole block base last stage (E: root; B: top) whole − last stage harness verifies
E, #1010's epoch tree (n = 4) 31.80 s 22.48 s 1.05 s 30.75 s 0.92 s, in its timed path
B, the block tree (n = 4) 23.20 s 18.50 s 1.35 s 21.86 s 2.97 s, off the clock
B − E −8.60 s −3.98 s −8.89 s

Base, block 25368371 on FAST (each run against #1010's epoch base on the same binary)

run change block base
FAST 360 W1: non-streamed block proof 29.9 s
FAST 364 first streamed version 25.96 s
FAST 365 chunk generation off the walk thread 24.45 s
FAST 366 windowed executor 23.55 s
FAST 367 walker/accumulator split 22.68 s
FAST 368 walked windows kept whole, concatenated at finish 21.98 s
FAST 369 BITWISE counted per window, KECCAK_RND split by rows 20.73 s (epoch base 25.71 s, −4.98 s)
  • Phase B: 9.96 s. Host peak: 43 GiB.
  • Every block proof the windowed builder produced verified: 14 of 14 (FAST 363–369). Non-windowed: 6 of 6 (FAST 360–362).

Recursion (W3): proved and verified on block 25368371 (FAST 413)

  • Leaves are cut along groups: a group's opening covers all of its tables, so a group is the smallest unit a leaf can verify alone. The tree plan (lfm::whir_block::WhirBlockPlan) runs the host verifier's own statement checks, derives every shape from the AIR and every prepared root from the program, and never reads a proof. It prices each group in permutations and partitions the groups over the leaves (heaviest first, onto the least-loaded leaf).
  • A leaf:
  • Nodes are the STARK block's (block_node, shared byte for byte with STARK no-epoch (prove-and-retire) prover: block 25368371 — work in progress #1013). They check the id, the state and the output equal across children, add the shares, and the top asserts zero.
  • Final check: verify_block_tree(elf, statement, top) derives the top program and checks the top proof against it. Every preset is pinned inside: the base's options, the block format, the tree's options, the leaf rule and the fan-in.
  • Tests:
    • every new check has a negative, and each negative a mutation showing that check is the one refusing;
    • the leaf's challenges equal the host's;
    • a tree over another partition is refused at the final check.
block 25368371 FAST 413: first build, serial FAST 414: pipelined (mean of 2 arms)
base (streamed, 9 groups, 27 chains, 12 prepared tables) 21.00 s 20.98 s
plan + leaf emission 0.23 s + 2.38 s, after the base inside the base (done at 12.2 s of 21.0)
leaves (3) 7.04 s, one at a time 3.36 s, three at a time
nodes 2 levels: 3.41 + 1.91 s one top over 3 children: 1.36 s
recursion 12.36 s 4.75 s
whole block 33.37 s 25.72 s
tree verify (derives every program from the ELF and the statement) accepted, 4.97 s accepted, 2.95 s

Every proof was verified by the harness off the clock. The base is unchanged by the emission running beside phase B (20.98 s vs 21.18 s in the arms without the change).

Next:

  • one prepared stack per group (group 8 carries 12 prepared chains);
  • the base levers: build_traces over segmented lists, and KECCAK_RND streamed.

Base levers after the A/B (FAST 417–422, each S/P on one binary)

lever base status
builder: windows concatenated in parallel −0.52 s (417), −0.21 s (419, replication in band) on by default
KECCAK_RND chunks streamed −0.14 s, no effect (this block's keccak work is at its end) off by default
LT's MEMW-derived ops streamed per window (FAST 420) +1.27 s, regression: the layout thread binds (9 more LT chunks, layout busy +2.47 s); LT heights deterministic across runs off by default
streamed chunks laid out on 3 threads, prepared columns after the groups (FAST 421, 422; BIG 390) −0.54 s (421), −0.22 s (422 replication); but the extra host memory scales with the block: +2.2 / +4.2 / +8.7 GiB max RSS at 1.0 / 1.3 / 1.8× (BIG 390) reverted at 11e2de5; on again since 59e9890, bounded (E3)
the rest of the run packed as it is laid out, AIR order (FAST 422) +0.21 s, regression: groups 6–8 still close together off

Memory (D-MEMORY, with i-mem / i-mem2)

stage effect status
M1: the builder drops each streamed chunk's ops as it leaves (drop_streamed_ops) FAST 501: 1× base −0.74 s, peak 47.4 → 36.6 GiB; the 1.20× block 25490321 now proves (49.2 GiB, OOM before). BIG 391 lean gate on the exact head: same statement shape kept vs dropped, both verify, 1.20× at 49.05 GiB on (f4aafea)
E1 lean walk + E4 paged executor memory (D-EXEC, lane i-exec) base −0.45 s (FAST 602); median windows phase 42.4 → 25.2 s (harness, FAST 599) on (5b4e6b4)
E1 v2: smaller per-step records (CPU op 96 B, MEMW_A ops as 48 B rows; D-EXEC, lane i-exec) byte-identical: proof digest equal to d9d0ac5's under the fixed trace hash + deterministic grind (FAST 426) on (773f134)
E3: layout workers bounded to K + 1 chunks unpacked (layout_ahead, D-EXEC) BIG 392: max RSS vs workers 0 +0.23 / −0.06 / +0.16 GiB at 1.0 / 1.3 / 1.8× (flat). FAST 425: no effect on time (whole 20.91 s both), since phase A no longer waits on layout on (3 workers since 59e9890)
one prepared stack per group prepared cost +0.49 → +0.14 s; recursion −0.57 s in
W: the rest laid out in ≤ 2 GiB waves; KECCAK_RND built as its 2^16-row tables at the finish (lane i-m4b) BIG 562: max RSS 88.88 → 79.54 GiB at 4.13×, 29.84 → 27.10 at 1×; FAST 852 + 853: base −0.14 s on (70eee3e)
b2: the finish packs each table as it builds it; phase A commits those tables narrow, never transposing them (lane i-m4b) BIG 563: max RSS 78.84 → 52.10 GiB at 4.13× (89.15 with W and b2 off), 28.53 → 22.45 at 1×; FAST 855 + 856: base −0.36 s on (365e3ab)

Narrow trace storage (M4, lane i-m4)

Prover-only; the proof bytes are the same. The proof digest equals the head's before M4 (07d1bd43…) under the fixed trace hash + deterministic grind (FAST 820).

  • What changes: between phase A's commit and phase B, each table of at least 2^16 cells is kept on the host packed at the width its values need, 1, 2, 4 or 8 bytes a column (BlockOptions::narrow, production Narrowing::CARD).
    • The pack runs on the card from the group's resident store, on a thread of its own, after the group's commit.
    • Phase B uploads the packed table and widens it on the card. A host reader widens on the host.
    • A wrong width map is refused by the kept-tree check (test plus mutation).
  • Time-neutral: whole block −0.04 s at 1×.

Max RSS, wide → narrow (BIG 560; the traces themselves shrink about 4×, e.g. 24.89 → 6.20 GiB at 1×):

block wide narrow
25368371 (1.0×) 36.23 GiB 29.47 GiB
25453112 (1.8×) 63.52 GiB 46.10 GiB
25482821 (2.66×) 80.80 GiB 52.83 GiB
25410821 (4.13×) — 86.93 GiB, proves and verifies

Before M4, #1014 ran out of memory at 3.03× (i-m4); the narrow line puts the 120.7 GiB edge near 5.5–6×.

Phase A uploads the next group beside the commit (3′, lane i-noepoch-w2)

Prover-only; the proof bytes are the same (digest 07d1bd43… at the default, FAST 832; the commits, their order and their bytes are unchanged).

  • What changes: phase A used to upload, commit and retire each group in turn, so the card waited on every group's upload. Now the current group's commit runs on a thread of its own while phase A's thread takes the next group and uploads its columns (BlockOptions::upload_ahead, on by default; BLOCK_WHIR_UPLOAD_AHEAD=0 is the control).
    • The upload starts only after the commit has asked the card for its room, so it takes what the ledger has left; a store the ledger refuses goes up after the commit, as before (no store or commit room was refused in any run).
  • Time (FAST 832, A B B A on one binary): base −0.60 s, phase A −0.66 s, whole block −0.61 s; 46 % of the upload seconds hidden. Groups 4–5 cannot hide theirs: the inline layout thread closes them after the previous commit ends, which is the next term (E3, next section: on since 59e9890).
  • Memory: one more group's columns held at the peak — the previous group's wide columns and its packed bytes wait for its pack's install while the current group commits (FAST 834, BLOCK MEM terms). At most one group (≤ ≈ 3.8 GiB), constant per group, not growing with the block; max RSS +1.8 to +2.3 GiB at 1× (FAST 832, 833, 834).

Streamed chunks laid out on three threads (E3 on by default, lane i-noepoch-w2)

Prover-only; the proof bytes are the same (digest 07d1bd43… at the default, FAST 838 and 835; the groups, their order and the packing are unchanged).

  • What changes: layout_workers 0 → 3 in BlockOptions::production (59e9890). The streamed chunks are laid out on three threads, with at most K + 1 = 3 of them unpacked at a time (layout_ahead, E3), instead of on the builder's one layout thread. BLOCK_WHIR_LAYOUT_WORKERS=0 (the inline layout, 01da99f's) is the control.
  • Why it pays now: with phase A uploading ahead (3′), the inline layout closed groups 4–5 only after the previous commit had ended, so the card waited on them; three workers close them in time.
  • Time (FAST 838, A B B A on two binaries, A = 01da99f, B = 59e9890): base −0.54 s (t −14.7), phase A −0.58 s, whole block −0.48 s (t −12.4; 20.23 → 19.75 s); phase B +0.06 s (one job, below what a single job resolves). FAST 835 (one binary, workers 0 vs 3) read whole −1.00 s.
  • Memory: max RSS −1.51 GiB at 1× (31.99 → 30.48 GiB, FAST 838; 835 read −0.68 GiB). The bound is what the earlier revert lacked: unbounded, the workers' host memory grew with the block (BIG 390); bounded, it stayed flat at 1.0 / 1.3 / 1.8× (BIG 392, measured before M4 and 3′, not re-run on this head).
  • 59e9890 also caps a readout stamp (an upload's "paid" seconds at the upload's own length); no proving change.

Phase B's kept-top paths re-hashed in parallel (lever 1, lane i-noepoch-w2)

Prover-only; the proof bytes are the same (digest 07d1bd43… at the default, FAST 840 at 733557a — 82f9046 adds only the knob; the paths, their order and the refusal are unchanged).

  • What changes: phase B serves each revived commitment's first-round paths from the kept tree top. The leaves under each queried block are gathered from the card, re-hashed on the host, and the block's subtree root is checked against the kept node. That re-hash ran one block at a time on the prover's thread while the card waited: 27 gaps of ≈ 37 ms, 1.01 s at 1× (nsys timeline, FAST 839). The blocks are now re-hashed in parallel and kept in block order; the root check still refuses before any path is returned. BLOCK_WHIR_REHASH_SERIAL=1 restores the serial re-hash (a measurement knob).
  • Time (FAST 843 + 844 pooled, 6 + 6 + 6 runs: one binary with the knob, serial S vs parallel P, plus 59e9890's binary as the reference R): re-hash 1.01 → 0.07 s; phase B −0.96 s (P − R; P − S −0.93 s, t −30.5); whole block −0.82 s (P − R, t −5.5; 19.72 → 18.90 s); phase A unchanged (this build vs R +0.09 s, t +1.0); max RSS unchanged.
  • FAST 840 (two binaries, 2 + 2 runs) read phase A +0.71 s, from one run that stalled in the layout; the code runs only in phase B, and the one-binary check shows no phase-A effect.
  • Also in: BLOCK OPEN SPLIT (with LAMBDA_VM_BASE_SPLIT=1), phase B's openings by host stage and the kept-top gather and re-hash seconds.

The tree's leaves execute while their artifacts are built (R2-i, lane i-noepoch-w2)

Prover-only; the proofs are the same (the top proof's digest equal with and without it, 0da6fea9…, under the fixed trace hash + deterministic grind, FAST 841).

  • What changes: WHIR no-epoch (prove-and-retire) prover: block 25368371 — work in progress #1014's tree is proved by the W3 harness (prove_tree_pipelined, the way a prover would run it; there is no production tree driver yet). Its level 0 built all three leaves' artifacts first (three serial card holds, 0.24 s at 1×) and only then let the leaves execute and fill their traces (0.46 s until the first was ready) while the card sat idle (nsys timeline, FAST 839). Execution and fill do not read the artifacts; only the prove does. lfm_prove is now cut into its host half (lfm_execute_and_fill) and its card half (LfmFilled::prove, which asserts the artifacts' hasher is the one the traces were filled for), in the same order; the harness builds the artifacts on a thread of their own and each leaf executes and fills beside them, waiting for its artifacts only to prove. W3_EXEC_BESIDE_ARTIFACTS=0 is the control (the order before).
  • Time (FAST 841 + 842 pooled, 8 + 8 runs on one binary): level 0 −0.24 s (t −17.8), recursion −0.23 s, whole block −0.24 s (t −5.2; 18.78 → 18.54 s; per job −0.29 / −0.20); base and max RSS unchanged.
  • The first leaf now takes the card 0.48 s after the tree starts, not 0.76 s (one run of each arm, FAST 841's card-hold trace).

A second whole-block field. The W3 readout prints, on the clock between the base and the tree, the block report, a second block frame for the LT heights and the group tables: 0.13–0.14 s at 1× that a prover would not spend. "Whole block" keeps its meaning (every number above includes them); from d169edd on, W3 RECURSION also prints "whole excl. harness readouts" beside it (at d169edd, FAST 841 + 842 pooled: whole 18.54 s, whole excl. harness readouts 18.40 s).

The rest laid out in waves; KECCAK_RND built as its tables (W, lane i-m4b)

Prover-only; the proof bytes are the same (digest 07d1bd43… under the fixed trace hash + deterministic grind: FAST 854 at 0bcc1fc, and FAST 855's W arm on this head's code).

  • What changes:
    • The tables the finish builds (the "rest") were turned into columns all at once, and a table's column copy exists before its rows are freed. So for a few seconds most of the rest was held twice, and WHIR no-epoch (prove-and-retire) prover: block 25368371 — work in progress #1014's memory log put the 1× and 4.13× peaks there (BIG 561). The rest is now laid out in AIR order, in waves of at most 2 GiB of rows, each wave in parallel (BlockOptions::rest_layout_bytes). The tables, their order and the groups are the same (test).
    • The finish built KECCAK_RND as one table of 1,480 columns, which split_keccak_rnd then copied into its 2^16-row tables. At 4.13× that copy was a second peak of the same height. The finish now builds the 2^16-row tables directly (BlockOptions::finish_keccak_rnd_chunks), the same tables as the split's (test), and hands none out during the windows, which would change the groups.
    • BLOCK_WHIR_REST_LAYOUT=all and BLOCK_WHIR_KR_FINISH_CHUNKS=0 restore the old behaviour.
  • Memory (BIG 562, one binary at 0bcc1fc, which 70eee3e merges with WHIR no-epoch (prove-and-retire) prover: block 25368371 — work in progress #1014's later commits; A = both off, W = this; three layout workers; jemalloc never purges, the record posture):
block A W
25368371 (1.0×) 29.84 GiB 27.10 GiB
25482821 (2.66×) — 49.02 GiB
25410821 (4.13×) 88.88 GiB 79.54 GiB
  • The live peak (jemalloc active) at 4.13× fell 72.9 → 63.7 GiB and now sits at the finish's end.
  • Not as pre-registered, on magnitude: the bands were ≤ 76 GiB and a ≥ 10 GiB drop at 4.13×, and ≤ 27 GiB at 1×. The resident-set gain came from the KECCAK_RND copy alone. The waves bound the live column copies, but the resident set still grows ≈ 16 GiB during the layout, because the freed row buffers stay with the allocator while the column copies take new pages. That growth and the finish's 8-byte tables are the next cut's target (finish packing, being measured).
  • On the max-RSS line, the 120.7 GiB edge moves from ≈ 5.9× to ≈ 6.4–6.7× (a linear estimate).
  • Time (FAST 852 + 853 pooled, one binary per job, three layout workers): base −0.14 s against both off, phase A −0.12 s.
    • The time comes from the finish ending without the KECCAK_RND copy.
    • The waves add ≈ 0.3 s to the rest's layout, which phase A does not wait on.
    • Packing the rest as it is laid out (pack_rest_as_laid_out) was re-measured with the waves: no gain (+0.01 s), so it stays off.
  • Also in:
    • the block memory log, LAMBDA_VM_BLOCK_MEMLOG=1 (off by default). It prints the host memory term by term every half second and at each phase mark, with the line at jemalloc's active peak and each arena's bytes (those two in the lib tests, which install jemalloc).
    • the readouts BLOCK REST TABLES (each rest table's layout end and group) and each group's commit start (from@).

The tree's first finished leaf executes during phase B (R2-ii, lane i-noepoch-w2)

Prover-only; the proofs are the same (base digest 07d1bd43… and the top proof's digest equal with and without it, 0da6fea9… — FAST 841's — under the fixed trace hash + deterministic grind: FAST 845, and FAST 847 again on fac261f, the merge with W).

  • What changes: phase B now hands each group's share of the proof (its argue, its opening, its prepared opening) to an observer as that group's opening ends (block_prove_on_forks_observed; the old entry point passes a no-op, and the proof is the same with any observer). A leaf's arena is built from its groups' words alone (group_arena_words + leaf_arena; block_leaf_arena is built from them). The W3 harness turns the groups into words as they arrive; the first leaf whose groups are all opened while another group is still to come (leaf 0 = groups 1, 5, 6 at 1×, done after group 6) executes and fills its traces on a thread of its own, about 1.5 s before the base ends, and the tree picks it up. Off the clock its arena is checked against the finished proof's. W3_LEAF_DURING_PHASE_B=0 is the control.
  • Time (FAST 845 + 846 pooled, 8 + 8 runs on one binary, at c5d9cec before the merge with W): whole block −0.24 s (18.63 → 18.39 s; per job −0.21 / −0.28); phase B +0.02 s; max RSS unchanged. The card's wait before the first leaf's prove fell from 0.23 s to 0.003 s; level 0 gained 0.15 s of it, since the first prove now runs beside the other two leaves' execution and fill.
  • Memory: the host's high-water is set in phase A at every size (1×: 25.5 GiB active at its peak, 7.2 GiB active by group 6's end with 31.0 GiB resident; 4.13×: 63.7 GiB at the finish's end, i-m4b), so one leaf's traces during phase B's tail fit in what phase A already holds.

The finish's tables packed as they are built (b2, lane i-m4b)

Prover-only; the proof bytes are the same (digest 07d1bd43… under the fixed trace hash + deterministic grind at both arms: FAST 855 at 0cebe16, and FAST 857 again on 365e3ab, the merge with R2-ii).

  • What changes:
    • After W, the finish still built its tables 8 bytes per cell, and phase A transposed each one into columns before packing it on the card. At 4.13× that layout took 24.6 GiB of wide tables and grew the resident set by ≈ 16 GiB (BIG 562).
    • The finish now packs each table into the narrow layout as soon as it is built (BlockOptions::pack_finished). KECCAK_RND is packed in waves of four 2^16-row tables. Phase A takes those tables as narrow columns and uploads them as they are, so the card packs only the groups' other tables. Nothing packed is transposed.
    • KECCAK, ECSM and ECDAS stay wide (BLOCK REST PACKED counts the rest: 187 of 191 tables at 4.13×).
    • A packed table's preprocessed columns are checked word for word against the AIR's before it is committed; a wrong one is refused (test, with a mutation).
    • BLOCK_WHIR_PACK_FINISHED=0 restores W.
  • Memory (BIG 563, one binary at 0cebe16; O = W and b2 off, A = W, B = W + b2; the memory log on; jemalloc never purges):
block O A (W) B (W + b2)
25368371 (1.0×) — 28.53 GiB 22.45 GiB
25482821 (2.66×) — — 37.64 GiB
25410821 (4.13×) 89.15 GiB 78.84 GiB 52.10 GiB
  • At 4.13× the live peak (jemalloc active) fell 63.7 → 49.7 GiB. The resident set now sits within 2 GiB of it (retention +2.0 GiB, from +14.7), and the rest's layout adds +1.15 GiB to it instead of +16.1. Every pre-registered row is in but one: the 1× live peak, at 21.0 GiB against a band of ≤ 19, because at 1× it falls in the middle of the finish, where the commit pipeline's in-flight copies bind.
  • On the max-RSS line (52.10 GiB at 4.13×, 12.82 + 9.47 GiB per 1×), the 120.7 GiB edge moves from ≈ 6.4–6.7× to ≈ 11.1–11.4× (a linear estimate for the base alone; the median block is 9.78×).
  • Next in line at the 4.13× peak: the committed groups held narrow for phase B (18.5 GiB, ≈ 5.9 GiB per 1×), then the finish's tables still being built (16.5 GiB).
  • Time (FAST 855 + 856 pooled, 8 + 8 runs on one binary): base −0.36 s (t −6.2; per job −0.40 / −0.32), all of it in phase A: the rest is laid out in 0.13 s instead of 0.57.

Measurement posture: the card's pool now retains freed memory (baseline shift)

Not a prover change; the proofs are the same (the top proof's digest 0da6fea9… under both postures, fixed trace hash + deterministic grind, FAST 848; 351a773 adds only a test readout).

  • What the env set, and why: every WHIR no-epoch (prove-and-retire) prover: block 25368371 — work in progress #1014 box run (the canonical env since FAST 416) set LAMBDA_VM_MEMPOOL_RELEASE_MB=0. The card's stream-ordered memory pool then hands its freed blocks back to the driver at each synchronize, so a VRAM sampler's total − free reads the live working set. The code default is to retain every freed block (DEFAULT_MEMPOOL_RELEASE_THRESHOLD_BYTES = u64::MAX in math-cuda), and that is what a prover runs.
  • What release-0 cost: each synchronize paid for the release, and the next large allocation mapped the memory again. In FAST 839's trace, the time spent inside cuStreamSynchronize and cuMemAllocAsync while the card was idle was ≈ 0.25 s in phase A, 0.42 s in phase B (0.26 s of it in the encode: one 18–33 ms gap per group) and 0.34 s in the tree.
  • Measured (FAST 848 + 849, one binary at 351a773, release-0 vs the default, 8 + 8 runs): whole block 17.91 → 17.27 s, −0.64 s (t −6.0). Phase B −0.44 s (t −28, against the 0.42 s above); phase A −0.07 s (t −0.7; phase A's runs scatter); recursion −0.12 s (level 0 −0.09 s); base −0.51 s; max RSS −0.16 GiB.
  • Gates, every run: the tree verified; the log's posture line matched its arm; no host fallback, device commit error, decline or ledger refusal; the card's peaks 24.15 GiB (the ledger's reservation) and 22.8 GiB (the pool's live high-water), read from the ledger and the pool, not from total − free (the new W3 DEVICE line).
  • From 351a773 on, WHIR no-epoch (prove-and-retire) prover: block 25368371 — work in progress #1014's numbers are taken at the code default. Every earlier number in this description was taken under release-0 and stays as measured. VRAM figures come from the ledger or the pool's high-water, never from total − free.

The prover refuses a partition over the group maximum (lane i-m4b)

Prover-only; the proof bytes are the same (digest 07d1bd43…, FAST 858). The prover now refuses a block over BlockFormat::max_groups as its groups close, with the verifier's own InvalidTableCounts error, instead of proving a block the verifier refuses. The median block (90 groups against the cap of 64) spent its whole ≈ 190 s base on such a proof (BIG 564). A test covers both prover paths, with a mutation for each check.

The tree's nodes built beside it, each level proving as its nodes arrive (A, lane i-noepoch-w2)

Prover-only (the W3 harness); the proofs are the same (the top proof's digest 0da6fea9… — FAST 841's — with and without it, under the fixed trace hash + deterministic grind: FAST 889, and FAST 891 again after the permit fix below).

  • What changes:
    • The W3 tree (prove_tree_pipelined) built every node program and its artifacts on one thread, level after level, and level 0 joined that thread before any node proved, so level 1 waited for the whole tree's builds. At the median block, 32 s of serial node builds after the leaves' artifacts held level 0 open 10.7 s past its last leaf proof, and the card sat idle 11.4 s before level 1 (BIG 565 / 568's card trace). At 2.66× the wait was 1.5–2.1 s (FAST 888).
    • Now a builder runs beside the whole tree and puts each node's program and artifacts in a slot of its own as soon as they exist. A level's programs are emitted together on a pool of W3_EMIT_THREADS threads (default 4, the builder's own: on the global pool a prover's join can steal an emission and leave the card idle, STARK no-epoch (prove-and-retire) prover: block 25368371 — work in progress #1013's FAST 454), and the builder's thread builds each one's artifacts as it arrives. Each node proves once its children are proved and its slot is filled. A builder that stops fails every empty slot. W3_NODE_PIPE=0 is the control.
    • This is STARK no-epoch (prove-and-retire) prover: block 25368371 — work in progress #1013's slot pipeline (i-tree's per-node emission, −7.32 s at the median there) in the W3 harness, with three differences: W3's Published<T> serves as the slot; there is no per-group early emission (W3 builds every leaf's artifacts up front, so a level's programs are emitted together); and there is no host-only thread marking (WHIR no-epoch (prove-and-retire) prover: block 25368371 — work in progress #1014 has none).
    • The level builder is generic (build_levels, an emit on the pool and a finish on the builder's thread). A toy tree at the median's shape puts the serial builder's programs in their slots whatever order a pool finishes them in, and finishes every node off the rayon workers (test; finishing on a worker, or publishing in arrival order, fails it). A failed build fails every slot above it without a hang (test).
  • Time:
    • Median (BIG 611, block 25475471 at i-m4b's cap-128 exploration head with these commits, P O O P on one binary): whole block 242.69 → 233.80 s, −8.89 s, every pipeline run below every control run (the estimate from BIG 565 / 568 was −10.6 s). Recursion 52.85 → 43.89 s; level 1's start gap 12.52 → 1.73 s (card idle 11.4 → 1.5 s). Peak VRAM 24274 → 24242 MiB and VmRSS 112.44 → 111.95 GiB: no growth (the gates).
    • 2.66× (FAST 889 + 890 pooled, one binary, 4 + 4 runs): recursion −1.22 s (t −5.2; whole block −1.21 s). Level 1's start gap (the last leaf proof's end to level 1's first prove on the card) fell from 1.97 to 0.69 s. After the permit fix: −1.19 s (t −6.5, FAST 891).
    • 1× (8 + 8 runs): recursion +0.007 s (t +0.3). At 1× the tree has one node, built in the same 1.8 s either way, so there is nothing to take.
  • What is left: a level still starts only after its children's proofs and its node's own execute + fill (0.45 s at 1×, 0.63 s at 2.66×; at the median the card sits idle 0.9–1.1 s at each later level's start). That start term is the next one; it is not addressed here.
  • Part of this landing: the card permit's latent re-entry, closed (lane i-m4b's diagnosis and repro). W3 built its leaves' artifacts as rayon jobs that each held the card around a build that uses rayon. A holder that waits inside rayon runs queued jobs on its own thread, so a sibling build could take the card a second time on that thread: the permit's assert fired and BIG 569's run parked. Which run trips it was the scheduler's choice (568 ran clean on the same code). Now:
    • the armed permit refuses a hold on a rayon worker before it takes the card, so any hold inside a rayon job fails at once instead of by luck (i-m4b's repro test now asserts the refusal; a plain thread holding the card while rayon builds under it is tested too);
    • W3 builds the leaves' artifacts one after another on their own thread (each held the card throughout anyway);
    • the node pipeline builds artifacts only on the builder's plain thread;
    • the harness disarms the permit before its off-the-clock verify, whose WhirBlockPlan::programs builds as rayon jobs.
  • Also in: W3_NODE_TIMES=1 (off by default). It prints, per program, when it was built, taken and proved; its prove's split (execute, fill, the prove net of the card wait, the wait); and each node level's start against the level below. The stamps are taken either way and cost a handful of Instant reads.
  • Toward a production tree driver: WHIR no-epoch (prove-and-retire) prover: block 25368371 — work in progress #1014 has none, and prove_tree_pipelined is its de-facto driver. With the slots it now has a driver's shape: leaves from phase B, nodes from slots, levels as their nodes and children arrive. Moving it out of the test harness is a landing item for STARK no-epoch (prove-and-retire) prover: block 25368371 — work in progress #1013 and WHIR no-epoch (prove-and-retire) prover: block 25368371 — work in progress #1014 both.

Each node proved as soon as its own children are (C, lane i-noepoch-w2)

Prover-only (the W3 harness); the proofs are the same (the 1× top proof's digest with and without it, under the fixed trace hash + deterministic grind, both trees accepted: 0da6fea9…, BIG 614 — the digest FAST 841 / 889 / 891 printed).

  • What changes:
    • After (A), a level still started only once its whole level below was proved, and then ran its first node's execute + fill with the card idle. At the median the card sat idle 1.4–1.6 s before level 1 and 0.9–1.1 s before each later level (BIG 611).
    • Now one pool of siblings workers proves every program of the tree, leaves and nodes, taking them in topological order (the leaves, then each node level) and publishing each proof into a slot of its own. A node waits only for its own children's slots, so it executes, fills and proves while the rest of the level below still proves. W3_DATAFLOW=0 is the control: each node waits for its whole level below (tested never to start early).
    • Workers that take programs in this order reach a node only after every program before it has been taken, so the earliest unfinished program never waits on one not yet taken: no deadlock at any number of workers (test; taking the nodes first deadlocks it). The siblings bound, and so the memory in flight, is unchanged. A failed or panicking prove fails every program above it without a hang (test).
    • A level's W3 LEVEL wall now runs from the level below's last proof to its own.
  • Time (one binary, arms alternated on one box):
    • Median (BIG 612, block 25475471, F O O F): recursion 43.78 → 42.05 s, −1.73 s, every dataflow run below every control run. The card's idle at level 1's start fell 1.4 → 0.0 s, and at level 2's 0.93 → 0.0 s, in both runs. Whole block −2.60 s (234.15 → 231.55 s), but −0.87 s of that is the base, which the knob cannot reach (it is read after the base): recursion is the number. VRAM flat (24306 → 24274 MiB); the tree phase's VmRSS max 120.05 GiB (one control run) / 112.07 GiB.
    • 2.66× (BIG 614 + 615 pooled, 6 + 6 runs): recursion 12.51 → 12.02 s, −0.49 s (t −4.5). Whole block −0.13 s (t −0.8): the base read +0.37 s (t +2.1), all of it in phase A's host front (executor and trace build), before the knob is read. Phase B was equal within 0.02 s, so nothing moved out of it. At 1× the base moved +0.04 s.
    • 1× (8 + 8 runs): recursion −0.02 s (t −0.5; per-run sd 0.08 s). At 1× the tree has one node, so there is nothing to take.
  • Mechanism, as registered (2.66× level-1 start, card idle with no hold active, ≤ 0.30 s): 0.31 s, OUT by 0.007 s (control 1.11 s).
    • Four of the six dataflow runs read 0.00. In the other two (0.88 / 0.96 s), the first level-1 node ready to prove had its program by 4.0 s, but its artifacts (a 0.14 s build on the card) waited 2.0 s behind level 0's proves and were ready only after level 0 ended. A node's slot holds its program and its artifacts together, so its execute + fill waited too, and ran with the card idle. In the four other runs the same build got the card between two leaf proves.
    • So the residual is the slot waiting for the artifacts before the execute, not the dataflow. At the median, level 1's idle read 0.00 in both runs. (Corrected: the first version of this section blamed the builder's emission; the build stamps include the card wait.)
  • A readout note: under dataflow the levels overlap, so a level's start gap (from the level below's last proof to the first prove hold starting after it) can count the next level's own proves. At the median, level 2's gap read 0.65 s with the card idle 0.00 s (BIG 612). The level starts are therefore read as card idle with no hold active.
  • What is left: the top node's execute + fill after its last child (1.0–1.1 s of card idle at the median, BIG 612). That is (B)'s target, next.
  • Toward a production tree driver: with (C), the driver's prove loop is one topological pool over the slots, with the levels taken from the plan's shape.

The held tables spill to disk, by default only when memory is short (lane i-m4b)

Prover-only; the proof bytes are the same: one shape and one proof digest (07d1bd43…) across the base and all four policies, under the fixed trace hash + deterministic grind (BIG 616). The 1× top proof's digest (0da6fea9…) and the tree verify at the landed merge (ULTRA 006).

  • What changes:
    • In phase A, after each group is installed, the narrow (packed) tables of every committed group past the first two can move to STARK no-epoch (prove-and-retire) prover: block 25368371 — work in progress #1013's spill store. The store (crypto/stark/src/spill.rs) is imported byte-identical; it digests each slot and writes it with O_DIRECT on a writer thread, off the committer's path. A table moves only when the writer's queue has room at that moment, so the committer never waits.
    • Phase B reads the tables back ahead of their upload, within a window of two groups' bytes, and checks every slot's digest. A table whose columns are still out when its group is read is refused (SpillFailed). After a group's opening its packed columns are let go.
    • The policy is STARK no-epoch (prove-and-retire) prover: block 25368371 — work in progress #1013's knob and rule: LAMBDA_VM_BLOCK_SPILL = auto (the default) | off | always | <GiB> (a resident budget). auto spills a table when the host's bytes plus a reserve plus the table would pass the target.
    • BLOCK SPILL prints the policy, the slots and bytes, the writer's split, the read-back, and the largest host reading auto decided on.
    • Tests:
      • the same bytes spilled and held;
      • a byte flipped in a spilled slot is refused, and so is a slot that does not come back;
      • a budget the block fits in spills nothing, and a zero budget spills every table past the first two;
      • unit tests of the knob, the rule, the cgroup v2/v1 readers and the working-set measure, each with a mutation that fails it.
  • Measured:
    • 4.13×, always (BIG 566, single runs): 22.74 GiB spilled, max RSS 52.53 → 40.12 GiB, whole block +1.15 s, drivers waited 0 s.
    • 4.13×, auto (BIG 567): by default nothing spills (target 110.7 GiB). Under a 35 GiB target it spills 21.21 GiB, max RSS 41.04 GiB, +2.91 s.
    • The median, on the cap-128 exploration head (BIG 568; the cap is not part of this landing):
      • auto spilled 26.98 GiB from group 44 of 90, and the tree verified.
      • VmRSS fell only 110.55 → 105.32 GiB. Under the never-purge allocator posture, freed pages stay resident, and the whole-run peak forms in phase A's finish, which the spill does not reach.
    • The landing gate (BIG 616 at 3d99c64, base WHIR no-epoch (prove-and-retire) prover: block 25368371 — work in progress #1014 54aae28, two jobs pooled, arms B, D = auto, O = off, S = always, T = auto at a 47.5 GiB target):
      • the card tests;
      • one shape and one proof digest across all five arms;
      • every auto run spilled 0 in both jobs, at 110.7 GiB and under the 47.5 GiB target (FAST's limit, kept as a real test on BIG's 128 GiB; the host read 25.3–26.8 GiB across those runs);
      • every run's environment the same size;
      • D − B −0.063 s (t −0.6), O − B −0.048 s (t −0.4), both inside the box's ±0.23 s band.
    • Earlier 1× gates on FAST (880 + 881, 882): always and auto at 0 spilled within noise.
    • ULTRA 006 at the landed merge 0d61081: 1× top digest 0da6fea9…, tree accepted, auto spilled 0 (host at most 27.65 GiB).
  • What is left: the median's peak is phase A's own (the finish's transient over the tables still held when it starts), not phase B's. That is the next memory term.

Phase 4 counts the BITWISE lookups in slices (#1013's c369843, lane i-m4b)

Prover-only; the bytes are the same:

  • the 187 whole-run trace digests (four programs at the small and default caps) are identical with the slices on and off;
  • the 1× proof digest is 07d1bd43… at both, under the fixed trace hash + deterministic grind (ULTRA 010).

What changes:

Measured: the median, BIG 619. One binary on the cap-128 exploration head, N P P N, auto spill on. N runs the whole-source path, P the slices.

N P (slices)
phase 4's transient (unnamed peak) 31.9 / 30.9 GiB 11.0 / 11.0
phase 4's length 13.3 / 15.4 s 6.6 / 6.5
active peak 93.1 / 89.2 GiB 83.5 / 83.1
VmRSS − active peak (retention) +13.2 / +18.1 GiB +5.1 / +4.3
base VmRSS, phase A / B 104.1 / 106.3 GiB (N1) 86.1 / 88.6, 85.0 / 87.4
whole-run VmRSS 107.6 / 108.9 GiB 89.1 / 89.9
the tree phase's cgroup peak 115.8 / 117.1 GiB 97.3 / 98.1
phase A 135.4 / 132.3 s 124.1 / 124.6
whole block 238.3 / 235.0 s 227.2 / 227.4
spilled (auto) 25.9 / 25.6 GiB 25.9 / 25.0
  • Phase A −9.5 s (whole block −9.3 s) comes from the finish, not the spill: every run spilled ≈ 25–26 GiB.
    • Phase 4 lost its two long poles (LT, KECCAK), so the finish builds the run 8.5–11 s sooner.
    • Phase A's wait for the rest's groups falls 33.8 / 32.0 → 20.8 / 22.6 s.
  • 1× (ULTRA 010, 8 + 8, one warm-up discarded): base −0.30 s (t −2.0), recursion −0.01 s.
  • The pre-registered bands for phase 4's transient (≤ 9 GiB), the active peak (≤ 83) and phase A (±3 s) were missed, all on the good side. Landed on the lead's judgment; there is a row in FAILED-LEVERS.
  • Proves 25416971 (12.4×) at cap 128, exploration (BIG 621, acfd54a + the cap, defaults): 40.7 G cells, 109 groups, base and tree verified; whole-run VmRSS 98.0 GiB, cgroup 106.2; 40.3 GiB spilled; whole block 278.1 s. On the line through the median and this block (≈ 1.18 GiB per G cells), cap 128 binds first, at ≈ 14.4× (≈ 47.8 G cells); memory binds at ≈ 15.5–16×.
  • What is left: the median's active peak is now the finish's phase 5. It holds the rest's tables until the finish ends (unnamed +24.0 GiB), beside the held narrow tables (33.8 GiB), which auto spills only once memory is short.

The top executes each child's share as that child is proved, while a child is still unproved (B and B′, lane i-noepoch-w2)

Prover-only (the W3 harness and the LFM executor); the proofs are the same. The 1× top digest is 0da6fea9… with the streamed top on and off, under the fixed trace hash + deterministic grind, and both trees are accepted (BIG 617; ULTRA 008 and 009; ULTRA 011 at c55dec4 itself).

  • What changes:
    • The top node executed its whole program after its last child was proved, although most of that program verifies one child at a time.
    • executor::StreamedExecution runs an execution as its arena groups land: each instruction runs in the wave in which the last group it reads lands (each instruction's group set comes from one forward pass), in the level schedule's order, into the slot the schedule gives it. So the witness is execute's, word for word.
    • Tests: the streamed execution is byte-identical in every landing order; a missing group, a group landed twice, or a wrong arena count or length is refused; finish checks that every instruction ran once. Dropping the group propagation (ReadBeforeWrite) or re-running instructions across waves (DoubleWrite) fails them.
    • The W3 top lands each child's arenas as that child is proved (W3_STREAM_TOP, on by default), so only the last child's share and the fill remain after the last child.
    • The readiness gate (B′): the top streams only if a child is still unproved when its program and artifacts arrive; otherwise it executes whole, on the control's path. W3 TOP EXECUTE prints which. A test covers a program ready before the last child (streamed), after it (whole), and a failed child (whole, which then reports the failure). Inverting the predicate fails the test.
  • Why the gate: the first version (B) always streamed. At 1× and 2.66× the top's slot arrives after its last child: its artifacts are a short card hold that queues behind the children's proves. So there was nothing to stream behind, and the streamed path costs more than one whole execution. 1× recursion rose by 0.22 s (t +5.8, BIG 617 + 618), and the top's start idle rose too (1.01 → 1.20 s). (B) was not landed. With the gate, the top executes whole at those sizes.
  • Time:
    • Median (block 25475471, BIG 613, S O O S O S on one binary): recursion −0.47 s (t −3.2); the card idle at the top's start fell 1.07 → 0.69 s. There the top's program is built 6–8 s before its first child, so it streams. BIG 620 (one gated run at the median) streamed, with recursion 41.91 s, inside 613's streamed range.
    • 1× (ULTRA 009, 8 + 8 after a warm-up): recursion +0.019 s (t +0.8), within the registered ±0.05 s; every gated run executed whole. At 2.66× the top's slot also arrives after its last child, so it executes whole there too.
  • What is left: the top's fill and the streamed path's own overhead (≈ 0.7 s of card idle before the median's top). Splitting a node's slot into its program and its artifacts, so that a node executes before its artifacts are built, is the next lever.

A node executes from its program; only its prove waits for its artifacts (b′, lane i-noepoch-w2)

Prover-only (the W3 harness); the proofs are the same: the 1× top digest is 0da6fea9… with W3_EXEC_EARLY on and off, under the fixed trace hash + deterministic grind, and both trees are accepted (ULTRA 012; ULTRA 013 at 806c211 itself).

  • What changes:
    • A node's slot held its program and its artifacts together, and its artifacts are a card hold that queues behind the proves below it. So a node could not execute until its artifacts were built, although executing needs only its program. At 1× and 2.66× the top's slot arrived 0.12–0.15 s after its last child, though its program had been emitted 0.03–2.1 s before it. At 2.66× a level-1 node's artifacts waited up to 2.1 s for the card while its children were already proved (BIG 614 / 617 / 618's card holds).
    • Now the builder publishes each node's program as soon as it is emitted: on the pool thread that emitted it, before the builder's thread builds its artifacts. The node executes and fills from the program once its children are proved, and only its prove waits for its own artifacts (node_flow). The traces are filled under the block hasher, which the node artifacts are built for. The top's streaming choice (B′) is taken when the top can execute. W3_EXEC_EARLY=0 is the control.
    • Tests:
      • A toy at the median's shape runs the real builder, scheduler and node flow at 1 to 6 workers, without a hang. It checks that every node gets its program within 40 ms of its emission or its take, executes before its artifacts where it can, and proves only with its own artifacts, after they are built.
      • Mutations fail it: waiting on another node's artifact slot; waiting for the artifacts before the execute; publishing a program after a sibling's finish.
      • The readiness predicate's test, the deadlock test (1–6 workers) and the failure-propagation test were re-run.
    • Part of this landing: proving filled traces against artifacts built for another hasher is refused (LfmProveError::HasherMismatch, naming both) instead of failing a release assert, and the streamed execution's finish returns an error instead of asserting its public words' capacity. Each has a test and a mutation.
  • The first build published each program from the builder's thread, between finishes that wait for the card. In one of BIG 622's six runs, a level-1 node got its program 2.3 s after it was emitted, so level 1's idle read 0.183 s against the registered ≤ 0.15. Publishing on the pool fixed it (BIG 624).
  • Time (one binary per box, arms alternated):
    • 1× (ULTRA 012, 8 + 8 after a warm-up): recursion −0.274 s (t −15.1; 4.125 → 3.851 s). The card idle at the top's start fell 0.536 → 0.239 s: the top's program now arrives before its last child, so B′ streams it.
    • 2.66× (BIG 624, 6 + 6 after a warm-up): recursion −0.410 s (t −2.8; 12.008 → 11.598 s). Level 1's start idle fell 0.197 → 0.007 s and the top's 0.795 → 0.525 s.
    • Median (BIG 625, N O O N): unchanged. In every run, every node is taken at least 1.27 s after its artifacts exist: the three workers are busy with the 23 leaves. So the split has nothing to act on there. 625 read −0.55 s, but the control arm itself moved +0.52 s from BIG 623 with no change on its path; over both jobs, −0.31 s at t ≈ −1.3. It passed its registered row by chance.
  • What is left: the top's fill and the streamed path's overhead (≈ 0.5–0.7 s of card idle at the top's start), and at the median the worker-bound leaf level.

@github-actions

github-actions Bot commented Sep 30, 2026 •

Copy link
Copy Markdown

Benchmark Results for modified programs 🚀

Command Mean [ms] Min [ms] Max [ms] Relative
head ecsm 2.1 ± 0.0 2.1 2.2 1.00
Command Mean [ms] Min [ms] Max [ms] Relative
head hashmap 86.9 ± 2.5 84.1 93.0 1.00
Command Mean [ms] Min [ms] Max [ms] Relative
head keccak 118.8 ± 2.1 116.6 122.2 1.00
Command Mean [ms] Min [ms] Max [ms] Relative
head syscall_commit 80.8 ± 1.2 79.6 83.5 1.00

@github-actions

github-actions Bot commented Oct 1, 2026 •

Copy link
Copy Markdown

Benchmark Results for unmodified programs 🚀

Command Mean [ms] Min [ms] Max [ms] Relative
base binary_search 51.2 ± 1.1 49.2 53.1 1.00
head binary_search 52.2 ± 2.1 50.0 57.4 1.02 ± 0.05
Command Mean [ms] Min [ms] Max [ms] Relative
base bitwise_ops 50.2 ± 1.0 48.8 51.4 1.01 ± 0.03
head bitwise_ops 49.9 ± 0.9 48.4 50.9 1.00
Command Mean [ms] Min [ms] Max [ms] Relative
base fibonacci_26 55.0 ± 0.7 54.1 56.5 1.00
head fibonacci_26 62.2 ± 1.5 59.9 64.5 1.13 ± 0.03
Command Mean [ms] Min [ms] Max [ms] Relative
base matrix_multiply 59.6 ± 1.7 58.0 64.1 1.09 ± 0.04
head matrix_multiply 54.7 ± 1.4 53.2 57.5 1.00
Command Mean [ms] Min [ms] Max [ms] Relative
base modular_exp 50.4 ± 0.9 49.5 52.0 1.00
head modular_exp 51.1 ± 1.2 49.5 52.7 1.01 ± 0.03
Command Mean [ms] Min [ms] Max [ms] Relative
base quicksort 54.4 ± 1.2 53.2 56.6 1.00
head quicksort 59.1 ± 1.3 57.8 62.0 1.09 ± 0.03
Command Mean [ms] Min [ms] Max [ms] Relative
base sieve 56.4 ± 1.0 55.2 57.8 1.00
head sieve 62.0 ± 2.4 59.5 67.8 1.10 ± 0.05
Command Mean [ms] Min [ms] Max [ms] Relative
base sum_array 67.9 ± 1.2 66.3 70.0 1.11 ± 0.03
head sum_array 61.4 ± 0.9 60.4 62.9 1.00

MauroToscano added a commit that referenced this pull request Oct 2, 2026
… leaves

The builder kept every walked window until finish, so at the run's end
all of its op lists were resident, about 300 B per cycle (0.28 GiB per M
cycles: 8.6 GiB on block 25368371 and about 100 GiB on a median mainnet
block). WindowedTraceBuilder::drop_streamed_ops keeps only the ops not yet
in a handed-out chunk for each of the 8 streamed tables (Tail: the windows'
lists moved in whole and freed once used up). As a chunk leaves, the
builder takes what the table phase would have read from its ops. It
counts BITWISE's lookups from LT, SHIFT, STORE, MEMW_A and MEMW_R, plus
DECODE's lookups and the last ECALL from CPU. It derives and keeps the
phase-3 LT ops of MEMW and MEMW_A, unless stream_memw_lt already put them
in the windows' LT lists. The other walk lists are appended window by
window instead of being concatenated at finish. The in-walk BITWISE
lookups are counted and dropped. finish runs the table phase over the
tails (StreamSkip::tails), padding the dropped CPU chunks and placing the
kept LT ops where phase 3 would have derived them.

The tables are the same. The new tests compare every table with the
whole-run build, and with stream_memw_lt every table with the builder
that keeps its windows, plus LT's multiplicities. Both go through push and
the split, at window lengths 1 to the whole run, and with chunks small
enough that all 8 tables drop. The same comparison runs with KECCAK_RND
streamed. Another test checks that after each window each table holds
less than a chunk of ops. Removing any one accounting step (LT, MEMW_R or
DECODE counts, the CPU padding, either LT prefix) fails the first test.
Off by default.

Cherry-picked from mem/m1 74e1df1 onto #1014, with the streamed finish's build marks kept.
MauroToscano added a commit that referenced this pull request Oct 3, 2026
MauroToscano added a commit that referenced this pull request Oct 3, 2026
…es are laid out

#1014 now lays the streamed chunks out on three workers (0498480), and phase
A waits on the groups the rest closes, which close only once the whole rest
is laid out. With b1's waves the AIR order's prefix is laid out first, so
pack_rest_as_laid_out (the rest's sink, groups identical by test) is now on in
production: each wave's tables go to the packer as the wave ends, and a group
closes once its own tables are laid out. Laid out all at once, the first table
in AIR order was ready only with the last, which is why packing as laid out
read +0.21 s before (FAST 422).

The real-block tests' BLOCK_WHIR_PACK_REST=0|1 now overrides the production
choice instead of replacing it with off.

Readouts for the finish's place in phase A: each group's commit start
(from@, beside done@), and every rest table's layout end and group in AIR order
(BLOCK REST TABLES).
MauroToscano added a commit that referenced this pull request Oct 3, 2026
MauroToscano added a commit that referenced this pull request Oct 3, 2026
MauroToscano added a commit that referenced this pull request Oct 3, 2026
MauroToscano added a commit that referenced this pull request Oct 3, 2026
MauroToscano added a commit that referenced this pull request Oct 3, 2026
…s its tables, the block memory log) into nw2/r2ii

No conflicts. multilinear_block.rs: the memory log's phase-B marks and the
group observer sit side by side at the end of each group (the observer first,
then the group's columns are released and the mark taken). block_whir.rs and
the W3 harness: the new BlockOptions fields and the memory log's plumbing
next to the group observer's.
MauroToscano added a commit that referenced this pull request Oct 3, 2026
… proof to an observer; the block tree's first leaf executes during phase B) into m4b/b2

No conflict. R2-ii's two full BlockOptions literals in lfm/whir_block_tests.rs
already carry b2's pack_finished: true, so its hand-over tests run with the
finish's tables packed, as production does.
MauroToscano added a commit that referenced this pull request Oct 3, 2026
…14fea1

crypto/stark/src/narrow.rs and crypto/stark/src/spill.rs are #1013's files,
byte-identical to mem/stark-f1 @ e5214fea1 (i-mem3's F1: the page-backed
Bytes, the streaming Digester, the fused writer, over the S1/S2 store). #1013
is their one source of truth: #1014 never edits them, re-imports any change
from there, and they merge as one when both PRs reach main.

Wiring only: the two modules in lib.rs (dead code allowed there, since some
parts serve #1013's prover alone), math's page-bytes feature, and libc
unconditional as the store needs it (it was behind disk-spill). #1013's prover
glue (TraceTable::spill_main) and its spill tests are not imported; #1014's
adapter and tests follow.
MauroToscano added a commit that referenced this pull request Oct 3, 2026
#1013 landed 4cb0a07 (the writer's digest / copy / pwrite step timings on
SpillStats, SpilledMain::is_resident). crypto/stark/src/spill.rs is again
byte-identical to noepoch/stark @ edddc68; narrow.rs was already. Readouts
only: nothing #1014 calls changed.
MauroToscano added a commit that referenced this pull request Oct 3, 2026
… reserve

LAMBDA_VM_BLOCK_SPILL now reads as #1013's (prover/src/block.rs SpillPolicy …
spill_decision @ edddc68): auto (and unset) | off | always | <GiB> resident
budget. auto spills a committed table once the host's bytes (the larger of
VmHWM and the cgroup's memory.current), the reserve and the table would pass
the target (LAMBDA_VM_BLOCK_SPILL_TARGET_GIB, else the cgroup's memory.max
less 10 GiB, else MemTotal less 10 GiB). Phase A decides per table and never
past the writers' queue; groups 0 and 1 count but never spill.

The reserve is #1014's own, inferred from the median block (BIG 565): the
finish's p5 transient (25.5 GiB) and the tree's leaf programs alive through
phase B (16.3 GiB), about 1.25 GiB per total G cells or 1.65 per G cells
committed so far, plus 6 GiB for phase B's bump and the read-back window.

BlockSpill carries the policy's choice (SpillWanted) and the kept bytes and
committed cells it reads. A block that fits spills nothing; the store opens
for every policy but off. Tests: the knob and the decision (unit), a budget
the block fits in spills nothing and one of zero spills (block).
MauroToscano added a commit that referenced this pull request Oct 3, 2026
…@ 278e6a8

The rule #1014 copies from #1013 read only cgroup v2's memory.max and
memory.current. On a v1 host (FAST) the target fell through to MemTotal
less 10 GiB, and the host's charge was not read at all. #1013 fixed both
in 278e6a8; this re-copies spill_target_bytes, spill_target_from,
cgroup_memory and host_bytes_now from that sha, with its two tests (the
cgroup files from fake trees, and the target rule), cited as before.

The only changes from #1013's text are the citations and the tests'
temporary directory, which gets a name of its own so the two copies of
the test never share one if they ever run in one process.
MauroToscano added a commit that referenced this pull request Oct 3, 2026
…cf253d2)

The host measure #1014 copies from #1013 took max(VmHWM, the cgroup's
charge), and the charge counts page cache. FAST charged 40.58 GB at 17:28Z
with 15.18 GB of it inactive file pages, which would have made auto spill
the last groups of a 1x block that fits.

This re-copies #1013's measure from its landed head 035aef5 (commit
cf253d2): HostReading reads VmHWM, the charge and memory.stat's inactive
file pages (v2 inactive_file, v1 total_inactive_file, by their exact key),
and the host's bytes are max(VmHWM, charge - inactive_file). CgroupValue
lets cgroup_memory read a whole-file number or one memory.stat key. The
BLOCK SPILL line ends with the largest reading auto decided on, as #1013's
does. With #1013's two tests; the text differs only in citations and the
test's temporary directory. The rest of #1013's train (lazy queue budgets,
the allocator purge) is not copied: #1014 has no queue budgets.
MauroToscano added a commit that referenced this pull request Oct 3, 2026
#1013 added one test-hook field (ProveOverrides::tight_claims, behind
cfg(test)/test-utils) with its tight resident claims (1cc3a70, 00871b9).
#1014 keeps the store byte-identical to #1013's: git diff 035aef5 --
crypto/stark/src/{narrow,spill}.rs is empty. Nothing in #1014 reads the
field.
MauroToscano added a commit that referenced this pull request Oct 4, 2026
MauroToscano added a commit that referenced this pull request Oct 4, 2026
The spill code (stark, multilinear, block_whir) and the streamed top (executor, proof, the W3 tree) touch disjoint code; the one shared file, whir_block_tests.rs, merges without conflict (the spill side adds BlockSpillPolicy::Off to two test fixtures).
MauroToscano added a commit that referenced this pull request Oct 5, 2026
…2/stream

The p4 port touches only prover/src/tables/trace_builder.rs; the streamed top and its readiness gate touch the executor, proof.rs and the W3 harness. No file in common, no conflict.
MauroToscano added a commit that referenced this pull request Oct 5, 2026
MauroToscano added a commit that referenced this pull request Oct 5, 2026
…114; min proven bits unchanged at 130.393)

The default flip of LAMBDA_VM_ZF_WHIR_GRIND_BITS: the port of #1010's
5364aa2 and its pin follow-up 2687e48. PRODUCTION_WHIR_GRIND_BITS is 18;
LEGACY_WHIR_GRIND_BITS = 20 keeps the legacy format and is the opt-out
(LAMBDA_VM_ZF_WHIR_GRIND_BITS=20). It reaches #1014's WHIR proofs: the
block's group chains and prepared openings, verify_block_whir, and the W3
leaves' in-guest verifier. The W3 tree's own STARK LFM proofs do not read it.
The binding WHIR phase is unchanged (the unground fold at 27 variables,
130.393 bits); the query phases move 130.926 -> 130.907.

Measured behind the knob on c55dec4: ULTRA 019 1x phase B -0.344 s
(t -12.9), whole -0.270 s, recursion -0.010 s; BIG 628 median whole
-3.42 s, both arms verified. The opt-out reproduces the previous 1x proof
byte for byte (top digest 0da6fea9 under fixed hash keys and deterministic
grind); the new default's is b9b4826d.

The W-leg sizing pins follow the process's grind bits, as 2687e48 did on
#1010.
MauroToscano added a commit that referenced this pull request Oct 6, 2026
…all, commit pairs off the pool)

ULTRA 096 (median 25475471, #1014 + cap 256, one binary, 3 + 3 runs plus
2 + 2 single-lever arms) read LEVER EFFECTIVE on every pre-registered row:
phase-A end -6.66 s with every run of the pair below every run without it,
whole block -6.86 s (154.67 -> 147.81 s), finish 15.8 -> 9.3 s at most,
KECCAK_RND's span 12.0 -> 5.4 s at most, the largest phase-A commit
2.93 -> 0.68 s, the card's wait for the rest 6.65 -> 1.77 s, max RSS
-0.97 GiB. The wave alone gave -5.92 s whole, the commit pairs alone
-0.47 s. At 1x (ULTRA 095) the pair is neutral (whole -0.016 s, t -0.4) and
the top digest is unchanged.

Both become the defaults; the knobs stay as opt-outs:
LAMBDA_VM_KR_PACKED_WAVE=4 builds the chunks four at a time again, and
LAMBDA_VM_BLOCK_COMMIT_OFF_POOL=0 puts the commit pairs back on the global
pool. The proof bytes are the same either way.
MauroToscano added a commit that referenced this pull request Oct 6, 2026
…W_WINDOW=1)

A #1014 block leaf's LFM_BALU is 70,692 rows a full group, so a 4-group
leaf holds 282,768 rows and pads to 2^19. 34,200 of a group's rows are
the lean fold's point x0^-1 = prod g^(-2^i b_i): one Select and one Mul a
bit through edsl::pow_bits.

pow_bits_windowed drops the identity multiply (the first factor read is
the accumulator) and reads each of the first two bit pairs through a
4-way Select mux over the constants {1, f0, f1, f0 f1}. A fold then pays
three fewer Muls and two more Selects at four or more index bits, two
and one below. A full group goes -6,498 LFM_BALU and +4,104 LFM_SELECT,
so a 4-group leaf's LFM_BALU drops to 256,776 (under 2^18) while its
LFM_SELECT stays under 2^19 at 480,168.

The value is the same and so is the Select semantics. The knob is read
at program emission like LAMBDA_VM_WHIR_FOLD_CLASSIC and defaults off,
so today's programs and ids are unchanged. pow_bits itself is untouched,
so the STARK paths keep their programs. The lean fold's row and constant
closed forms follow the setting.
MauroToscano added a commit that referenced this pull request Oct 10, 2026
…E_DOWNLOAD (default off)

The port to #1014 of #1013's 6d25865: the same changed lines in
device.rs, lde.rs, stark's gpu_lde.rs and the new device test, applied to
functions that were identical on both PRs.

On a precomputed-tree cache miss the preprocessed commit downloads the full
node buffer into a zeroed pageable Vec<u8> and stark copies it once more
into Vec<[u8; 32]>. #1014's median recursion pulls about 14.7 GB this way
at 2.75 GB/s (I-PROF4 B.5.1). LAMBDA_VM_TREE_DOWNLOAD=staged sends it
through a staging pair straight into the node vector and queues the
multiplicity tree behind the last chunk; the device peak stays one tree
and the nodes are the same bytes.
MauroToscano added a commit that referenced this pull request Oct 10, 2026
The port to #1014 of #1013's 814a4b6. LAMBDA_VM_TREE_DOWNLOAD unset
(or any unknown value) now selects the staged download; `legacy` or
`pageable` keeps the old pageable copy as an opt-out. The nodes are the
same bytes on both paths. A unit test pins the default.

On #1013, legacy vs staged on the median 25475471, one binary per job:
recursion -2.94 s (t -15.9, ULTRA 094) and -6.26 s (t -27.6, RYZEN 002),
with the base digest and the top program id unchanged (ULTRA 093, 100).
#1014's own gate is I-COPIES §10.
A chunk held as records points into window-sized lists that neighbouring
chunks can share. When its records are let go, each list this chunk is the
last holder of (Arc::get_mut) has the whole pages inside its allocation
handed back with madvise(MADV_DONTNEED) right before the free; a list
another chunk still holds is left alone. Linux only, and only for values
with nothing to drop. A refusal is counted and logged once, never a panic.
CPU, MEMW_R and the row families' records use it.
release_group no longer drops a records table's records on the driver
thread. Under a spill they go to one background thread that hands their
pages back to the OS and frees them, so phase B waits on neither. The
thread is joined before phase B returns (and on drop), and what each
group's records came to lands in its stamps (records_pages,
records_return_secs). The release unit test covers the thread, its join
and the per-group stamps.
…rop test

The release line adds the pages handed back to the OS: bytes, buffers,
shared, refused, and the seconds on their thread. The records drop test
checks that, with nothing dropped before phase B, some list is handed back
by its last holder and none is refused.
…fault

In a build with the card's kernels, an unset LAMBDA_VM_BLOCK_CARD_FILL now
has the card fill the streamed CPU and MEMW_R chunks from their records,
beside KECCAK_RND, as the measured configuration did (keccak_rnd,cpu,memw_r:
large block about 2.7 s faster and about 7.6 GiB lower at its peak, the same
proof bytes). The row families stay behind their own words. The word
keccak_rnd alone rolls back to KECCAK_RND's fill only. A build without the
card is unchanged: nothing is filled from records there.

The knob test pins the unset default to exactly those three words with a
card and to nothing without, and the rollback word to KECCAK_RND alone.
With a card build's default now filling CPU and MEMW_R chunks from their
records, the live-regeneration block tests that do not ask for records
would hold those chunks as records and drop them as such. The helper they
share keeps both families on the host unless a test asks otherwise, as it
already does for KECCAK_RND, so each test proves the configuration it was
written for in either build. The records tests set theirs explicitly.
The pool count of the deduplicating tables' per-row lookups (LT, BRANCH,
BYTEWISE) counts each chunk's distinct operations in one hash map reserved
for them. A block's LT chunk holds about a million distinct operations, so
its map is some 60 MiB, far beyond any cache, and each insert waits on
memory: on a large block the count is the finish's longest step.

LAMBDA_VM_BLOCK_P4_ROWS=parts counts each chunk by parts instead. A first
pass notes each operation's part, read from bits of its hash that a map
neither indexes its buckets by nor keeps in its control bytes; a second
copies each operation into its part; each part is then counted with one
small map, cleared between parts, which stays in a core's cache. Every
operation of one value lands in one part, so the counts are the one map's.
pool (the default) keeps one map a chunk.

The BLOCK P4 ROWS line says how the chunks were counted, the count's wall
seconds and, beside it, how long phase 4's other collectors took. The
multiplicities and the tables are the same.
The card's backend (its context, its modules and its staging pools) is set
up at the card's first use, which in a block's prove is the first group's
upload: the group waits for it after it is laid out. With
LAMBDA_VM_BLOCK_CARD_EARLY=1 the streamed prove starts the setup on a thread
of its own as it starts, beside the executor and the first windows. Unset,
empty or 0 (the default) keeps the setup at the first use.

math_cuda::device::set_up_backend sets the backend up without counting as a
device entry, and the backend now initialises one caller at a time, so the
first group waits for a setup already under way instead of building a
second context beside it. The proof is the same.
The finish's phase 4 counts the BITWISE lookups of about twenty sources
(LT's per-op lookups, MUL, DVRM, BRANCH, SHIFT, BYTEWISE, EQ, STORE, MEMW_A,
KECCAK, ECDAS, COPY, the small lists, the padding, IS_WH, PAGE, and the
walk's tails) into at most eight buckets, each with its own 80 MiB
histogram, beside the pool count of the per-row lookups. The phase ends
when the slower of the two does.

The BLOCK P4 ROWS line now also says how many buckets ran, the longest and
shortest bucket's wall, and each source's seconds summed over the buckets,
so a block's log shows which source the phase waits on. The
multiplicities and the tables are the same.
…its histograms

Phase 4's two largest BITWISE sources build each slice's list of lookups
before folding it into a bucket's histogram: LT's eight a op (a 32 MiB list
for each slice of 2^20 ops, some 3.6 G lookups on a large block) and
KECCAK's five thousand a permutation (a list grown by doubling for each
slice of 2^11). On a block the collectors are bound by memory traffic, not
threads: more buckets made them slower.

The lookups of each source now come from one generator,
for_each_lt_lookup and for_each_keccak_lookup, on COPY's pattern: the
lists the finish built (collect_bitwise_from_lt_ops,
collect_bitwise_from_keccak) push what it emits, and the new
count_bitwise_from_lt_ops and count_bitwise_from_keccak bump the histogram
they are handed with no list in between.
LAMBDA_VM_BLOCK_P4_LOOKUPS=direct counts that way; unset, empty or lists
keeps the lists. Tests hold the generators against the earlier lists, kept
word for word as the reference, at the finish's slice sizes. The
multiplicities and the tables are the same.
… histograms by default

LAMBDA_VM_BLOCK_P4_LOOKUPS unset or empty now counts LT's per-op lookups
and KECCAK's straight into phase 4's histograms, with no list of each
slice's lookups in between. lists, the earlier way, is the rollback. The
multiplicities, the tables and the proof are the same.
A test holds the finish's phase-4 defaults: the per-row lookups counted on
the pool with one map a chunk, LT's and KECCAK's lookups counted straight
into the histograms, and the card set up at its first use.
…each

`auto` arms once the host's bytes (the larger of the process's peak and
its cgroup's working set) pass its target, MemTotal less 10 GiB, and the
walk's end hands off, which arms live regeneration, once the process's
peak passes 85 % of that target. Two cases meant to never arm read the
real host: the records drop test's `auto` run with no disk, and the
live regeneration test's `auto` run under a budget the block fits in.
On a GitHub runner the records case armed at 0.0 s, dropped its 10
records chunks as records, and phase B let go of none, so the release
check read 0 against 11008 bytes.

Both cases now take a target of u64::MAX, so neither the per-table
decision nor the walk's-end hand-off can arm on any host, and the
records case first checks its own premise: nothing dropped, and the
dropped line says it never armed.
…each

Both read the host at the walk's end: a store's parked tables are
handed off once the process's peak passes 85 % of the host's target
(MemTotal less 10 GiB). The budget test's "a budget it fits in spills
nothing" and the hand-off test's "parked and never handed off" hold only
on a host whose target is above the test's peak; on a small one (a
runner with 7 GiB has a target of 0) every parked table is handed off
and both read slots > 0.

Both now take a target of u64::MAX, so the budget alone decides what
goes, and the hand-off runs only where the test asks for it.
The ethrex guest now builds its eight ethrex crates from yetanotherco/ethrex,
branch lambda-vm/jumpmap: the pinned commit 797df554 plus two commits. The first
keeps the JUMPDEST analysis as a bitmap, so a JUMP or JUMPI tests one bit
instead of binary-searching the list of offsets; the second moves the tracer's
branch of the jump out of line. A jump destination is valid exactly when it was
before; the fork's commits carry tests that compare the new check with the old
one on edge cases, random code and every bytecode of 25 mainnet blocks. On
mainnet block 25475471 the guest executes 9.79 M fewer instructions (-4.1 %).

The pins stay on lambdaclass/ethrex at 797df554: the commits leave ProgramInput
as it is, so the fixture writer and the native reference keep reading the same
layout, and the native reference now also checks the forked guest against
unpatched ethrex. All eight crates are patched together, because patching only
the two that changed leaves two copies of ethrex-crypto in the graph.

scripts/set_ethrex_rev.sh learns about the patch: --show counts only the
lambdaclass pins and fails unless the fork's recorded base is the pin, and a
re-pin to another commit refuses until the fork is rebased onto it. Ethrex main
has kept jump destinations as a bitmap since 3ca8bc23 (#7095), so the patch can
go when the pin moves past that commit.
The default benchmark block (mainnet 25368371) executes 20,399,452 instructions
with the jump-destination bitmap (laptop count), against 21,217,647 with the
ethrex crates unpatched at this head; the table and the history line said
23,935,913, the count before main's guest-side changes were merged.
The ethrex guest's [patch] now points at yetanotherco/ethrex branch
lambda-vm/jumpmap-plus (4a6d9270): the jump-destination bitmap's two commits
plus ethrex main's #7119, picked without its changelog entry. #7119 lets
MLOAD and MSTORE round the memory size once and write the stack top without a
second bounds check, and lets the memory accessors skip RefCell's runtime
borrow flag; each check it drops is one an earlier check already made, and the
memory and stack code it changes is the same at the pinned 797df554 as at its
upstream parent.

On mainnet block 25475471 the guest now executes 10.82 M fewer instructions
than with unpatched ethrex (-5.06 %), 1.03 M of them from #7119; on 25368371,
the benchmark block, 20,296,269 (the converter README's count). The public
output and every accelerated call except the copy accelerator's count are the
same on all 22 executing blocks, and #7119 itself moves no call.
A block format field, leaf_query, chooses how the recursion leaf checks
each WHIR chain's queries. V1 (the default) is today's leaf, unchanged.
Under Lean, a chain's tail rounds -- round 1 on, a suffix whose current
trees lie wholly in their 4-ary caps and have fewer leaves than the
queries (rounds 5 and 6 at blowup 2) -- are checked at every leaf once
instead of at each query: each leaf's block is hashed against its cap
node, folded at its constant position and compared with the successor
tail round's block at that slot, or the final value. Every sampled
position is one of these, so the leaf accepts only what the host's
checks at the sampled positions accept, and an honest proof passes at
every position. The query draws stay in the transcript, their bits
unused.

The arena writes a tail tree's blocks once in leaf order. The host keeps
no query position, so each opened block is placed by its leaf hash among
the cap's nodes; a leaf no opening hits makes the writer return an
error. The arena stays a function of the proof.

On the median mix at blowup 2 every group spends 1,356 socket rows,
4,512 hinted words and 1,374 selects fewer, and its base and extension
ALU and lanes fewer too; the leaf's front is unchanged. The opening
permutation model counts the tail rounds, and the query-row model has
a tail branch.

The knob is LAMBDA_VM_WHIR_LEAF_QUERY (v1 or lean), read by the
production format on both sides; the harness prints W3 LEAF QUERY.
Tests: the tail rule picks a capped suffix and only under Lean; lean
chains execute on host-accepted proofs and spend their closed form of
socket rows, fewer than V1's; a tail block one lane off and the final
value one off are refused; a compare at the neighbouring slot refuses
an honest proof; a proof missing a tail leaf makes the writer err; equal
tail blocks are each placed; the knob's words.
The arena takes every block of a tail tree from the proof's own openings
of it: the round before's successor openings and the round's own, 2Q
uniform positions. "Fewer leaves than queries" left that coverage to
chance: at 6 queries over 4 leaves an honest proof misses a leaf about
one time in eight, and its arena cannot be laid out.

A tail round now needs Q >= 24 L, which bounds the miss by L * e^-48
(below 2^-63 for every tree of at most 64 leaves). The production chains
keep their tails at blowup 2 (229 queries: trees of 2, 4 and 8 leaves).
The test chains move to 96..192 queries so their tails stay; a chain one
query short of a tree's bound drops that round.
Under the lean query a round-0 base block arrives four values a word,
the last word zero-filled, instead of one (v, 0, 0, 0) word a value. The
leaf hash takes the words as its rate words (leaf_hash_words: the same
width tag and twelve-felt schedule, so the same digest), and the fold
reads the felts each word's Unpack writes. The base-lift pin moves from
Pack to Unpack, which sends each lane as a base token from the hashed
word's own columns. Lanes past the last value are hashed as given, so
anything but the zero fill misses the root.

Per group on the median mix at blowup 2, on top of the tail rounds:
hinted words -32,976 more (-37,488 in all), no permutation and no lane
row added. The default (V1) arena and programs are unchanged.

Tests: the word leaf hash equals the host's linear hash at lengths on
and off a word and a block, and a nonzero lane past the last value gives
another digest; the lean arena lays each block out as the proof's
values; a value one off in any lane of a block's first or last word, at
the first or last query, has no execution, on single chains and on
grouped round-0 trees.
Instr::HintOn reads arena word `index` when its bit cell holds 0 and
`alt` when it holds 1. It compiles to the same LFM_HINT row as a Hint:
the row carries the output address and multiplicity only, and a hinted
value is free witness, so which word the executor reads changes no
constraint.

The bit is a schedule dependency and never a read: schedule_reads_into
adds it for the level schedule, the streamed executor's group needs and
the validator's order check, while reads_into (whose recount sets every
multiplicity) leaves it out. The validator also holds both indices to
the arena. Existing programs are unchanged: no emitter makes a HintOn
yet.

Tests: a HintOn reads its alternative on a set bit under both schedules
and its bit's multiplicity counts no read; a non-boolean bit, a bit
written after the hint and an alternative past the arena are refused;
a bit drawn from a permutation schedules the hint after it, and a
streamed execution landing the hint's arena first waits for the bit's
group (dropping the bit from the schedule reds both).
Under the lean query the openings' paths stay in the arena, in the
proof's child order, until their walk. The walk hints each 4-ary level's
three siblings with HintOn on the level's b1 bit, so the executor reads
them in hint order ((s0, s1, s2) on a clear bit, (s2, s0, s1) on a set
one), and places them with walk4's three Selects instead of the
child-order walk's five. The arena is byte for byte the same; only the
leaf program changes. Every placement is still a Select on an index
bit, so the node hashed is the one the index names whatever the hints.

Per group on the median mix at blowup 2: selects -27,022 more (-28,396
in all with the tail rounds), as modelled; no permutation added. The
default (V1) programs are unchanged.

Tests: rotated hints walk a child-order path to Merkle4's root at every
leaf of trees of depth 0..5 with three Selects a level, and the
rotation swapped misses it; a lean chain spends two Selects fewer a
walked level and its closed-form socket rows; a path word one off in a
lean arena has no execution.
verify_block_tree_at and verify_whir_block_tree_proof_at take the
leaves' query check (LeafQuery) as a typed choice beside the group
opening, blowup, leaf order and leaf scale, and the scan of the public
verifiers requires it. The block commands take --leaf-query v1|lean
(default v1) on prove-block and verify-block alike and refuse the
harness's LAMBDA_VM_WHIR_LEAF_QUERY, as they refuse the leaf scale's
knob. The proof file carries none of it.

Box-tier tests: every lean leaf of a small block executes, per
polynomial and with grouped round-0 trees, with fewer Selects than V1's,
and a round-0 sibling or value tampered is refused; a tree proved under
one query check is refused by a verifier under the other, both ways,
and each verifies under its own; phase B's streamed arenas equal the
proof's under the lean check too.
…s by iterator

Clippy's cloned_ref_to_slice_refs and needless_range_loop, under make lint.
Every tail round's blocks replaced by blocks of the final value fold to
the final value at every position, so each tail fold compare holds; the
cap compare is what refuses them. A test-only fault turns that compare
off, and the forgery then executes, so the check is load-bearing: the
tampered-lane test alone could not show it (a lane off also breaks the
fold).
The lean leaf draws every query position V1 draws (as many BitDec rows:
the tail rounds' draws stay in the transcript, their bits unused), and
the round before the first tail round still opens the tail tree at each
sampled position: its successor opening one off at the first or the last
query, which the host refuses, has no execution.
With the tail cap compare off by a test fault, the hinted tail blocks are
bound to nothing but their folds: one value of the last tail round's first
block one off folds away from the final value and has no execution,
while the honest arena under the same fault executes. A mutant dropping
the fold compare turns it red: the compare is what makes the leaf's
acceptance imply the host's sampled fold checks.

Also formats the named-format test's tuple, widened for the query check
when this stack took the leaf options.
The verifiers' cross-check over the lean and V1 query checks builds its
small block at blowup 4 (at_blowup_4): at blowup 2 the test format's V1
groups pass a single leaf's room and the rule's partition refuses. The
phase-B arena test's lean arm stays at blowup 2, the shipped rate; its
doc records the lean leaf's margin on the format's widest groups.
The leaves' query check is a format choice, so its leaf programs should
not drift unnoticed. On the median mix at blowup 2, pin the leaf count
and the digest of the first and the last leaf program (every
instruction and the arena schema, as Debug prints them) under the
per-query check and under the lean check, each named explicitly.

A later change of which check is the default must leave both pins as
they are.
A block's recursion leaves now take the lean query check unless told
otherwise: round 0's values arrive four to a hinted word, paths are
walked on hints the executor rotates, and a chain's tail rounds that lie
wholly in their caps are checked at every leaf once instead of at each
query. Measured on whole blocks against the per-query check at the same
head, one binary, three mirrored runs a size: recursion -0.74 s on the
median block and -0.97 s on the large one, whole block -0.96 s and
-1.31 s, the large block's peak resident memory -1.33 GiB, both
verifiers accepting every run. The block statement is unchanged; the
tree's top moves, since the leaf programs change.

The per-query check stays selectable by name everywhere the lean one
is: LAMBDA_VM_WHIR_LEAF_QUERY=v1 for the process format, and
--leaf-query v1 on prove-block and verify-block. As before, the choice
is the verifier's constant and the proof does not carry it. Chains
outside a block leaf keep the per-query check.

Tests: the knob and the CLI flag read lean when unset; a new test holds
the type's default, the unset knob and the production format to lean,
and the median mix's pinned leaf programs (the previous commit) are
unchanged under each named check, with the default's first leaf equal
to the lean pin.
Every block leaf absorbs the ELF's digest and its pages, and the built
poc_rodata_commit.elf differs by the assembler that made it (the Linux
build is not the macOS one), so the leaf program pins only held on the
machine that recorded them. The test now reads a checked-in copy of the
ELF, so the pins are the same bytes on every machine; the pinned values
do not change.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant