Whole Stwo proofs: what a season of agents found

What it does: builds the Merkle leaf layer tile by tile, streaming each column once and hashing the first five inner layers in a pass that stays in the L1 cache ¹.

At the gate: the frontier carrying it, with the kernel changes below, measured 0.8210 vs unmodified ^{2 3}.

In the browser: not ported; the browser port left out the fork's fused Merkle and FFT changes ⁴.

Generalises: Partial Prover-side and bit-exact; on a 13th-gen Intel laptop it was the change whose local gain carried over best to the evaluator, although the evaluator showed only part of each local gain ¹. The tile pass is sized to stay in L1, so the gain may vary with cache geometry, and it is untested outside x86: the browser port left out the fused Merkle changes ⁴.

What it does: keeps only level 5 and above of each Merkle tree; decommitment recomputes the 32-leaf block around each query. That is 16 MB per tree instead of 512 MB ⁵. The same idea was reached independently in a separate submission ⁶.

At the gate: 0.7511 vs unmodified ⁷.

In the browser: ported into the memory build, without its fused tiling ⁸.

Generalises: Broad A prover-side storage change: roots, openings and proof bytes are unchanged and omitted hashes are recomputed at decommitment ⁸. Adapted without the fused tiling in the single-threaded wasm port, it lowered the memory profile's requested peak from 4.91 to 2.31 GB at the same proving time ⁸, and locally it cut peak RSS and page faults on an Apple M3 Max ⁵.

What it does: splits BLAKE2s compression into two halves, inlines the field operators and adds a dedicated proof-of-work grind kernel ¹. A tiled transpose shipped with them locally but was left out: it was neutral at the gate ³.

At the gate: two-half BLAKE2s alone measured 0.9563 vs unmodified ¹; the combined effect is in the tiled-leaf-hashing frontier above.

In the browser: adapted in a separate kernels build, not in the standard or memory build ⁴.

Generalises: Host-specific The two-half BLAKE2s split answers register pressure on AVX2, where the 16-lane state spills to the stack ⁹; the browser port's kernels build adapted it with the grind prefix but notes the AVX register argument does not establish a WASM benefit, and its smoke runs established no isolated gain ¹⁰. The grind-prefix precomputation is ISA-independent and was checked bit-exact on both Blake2s channel variants ¹¹, so it is the part most likely to transfer.

What it does: fuses the forward FFT's first pass with the transposition, saving one pass over memory.

At the gate: the frontier carrying it measured 0.7373 vs unmodified, about 0.5 point better than without it ^{12 13}.

In the browser: the port's kernels build draws on this frontier but excludes the fork's fused Merkle and FFT changes ⁴.

Generalises: Partial Prover-side and bit-exact, but its local gain on an Intel laptop depended strongly on the page regime and thread count, shrinking to a small effect with 4 KB pages or 6 pinned cores ¹⁴. Most of the saving comes from reading each source group once for all cosets ¹⁴, which may transfer to other hosts at a smaller size; the browser port did not take the fused FFT changes ⁴.

What it does: interpolates into reused, pooled buffers instead of in place, with the first pass again fused with the transposition.

At the gate: the frontier measured 30.7% faster than unmodified ¹⁵.

In the browser: not ported.

Generalises: Untested No evidence outside the gate. Reusing pooled buffers instead of fresh pages is protocol-neutral and may transfer, but pool policy matters elsewhere: the frontier's pool buffers grow in place ¹⁵, and the browser port found that a pool reserving growth capacity on fresh buffers held 1.55 GB of requested memory for 0.93 GB of values in wasm, so it made fresh buffers exact ¹⁶.

What it does: computes the witness lookup tables (range checks, XOR, Blake sigma and others) by formula instead of through hash maps.

At the gate: 2.2% faster than its parent ¹⁷.

In the browser: not ported.

Generalises: Partial Bit-exact and self-checking: each table is tested at construction for a bit-field layout of the row index and falls back to a hash map otherwise, and on an Apple M-series host it cut circuit proving time locally, mostly in two XOR-heavy circuit components ¹⁸. The browser port did not take it, though its compact preprocessing builds preprocessed lookup tables by formula, a related but separate change ¹⁹.

What it does: simplifies the LogUp constraints algebraically and writes LogUp columns in one pass ²⁰. Three of its simplifications entered the frontier ²¹.

At the gate: the rest measured 0.9677 ²² and 0.9793 ²³ of the frontier's time but had no route to promotion. It fitted the patch-size cap only after its comment lines were stripped ²⁰; the memory-weighted rule then needed about 11.5% faster at flat memory ²⁴, and the smaller-first rule that replaced it admits no time-only gain ²⁵.

In the browser: not tracked separately; the frontier that took part of it is among the sources of the port's lifetime changes ⁴.

Generalises: Partial All changes are exact arithmetic and stayed byte-identical across the 16-workload corpus on arm64, but the gain is concentrated in a few components (xor_12, blake_g_gate) and the Cairo xor_12 factoring dispatches on the evaluator type inside Cairo AIR code ²⁶. The time gain reproduced closely in a Linux VM while an Apple M5 overstated it about twofold ^{21 26}; the browser port did not track it separately ⁴, and its upstream forbids hand edits to AIR-generated Cairo files, so the Cairo part may need to go through the generator ²⁷.

What it does: uses one large-block cache, shared by all threads, as the global allocator, so freed temporaries are not stranded in per-thread glibc arenas.

At the gate: peak 8.22 → 6.88 GiB at time ratio 1.0039 ²⁸.

In the browser: not ported; the port uses no native allocator or page mechanisms ⁴.

Generalises: Host-specific Its gain comes from glibc keeping freed temporaries in per-thread arenas ²⁸, so it depends on that allocator and on many worker threads. The browser port uses no native allocator mechanisms ⁴; there wasm linear memory sits about 0.65 GB above the requested peak because it never shrinks, which the fork's unmapping cache does not address ²⁷.

What it does: backs the allocator's 2 MiB blocks with transparent huge pages; in the same step, preprocessed address columns became u32 and unpacked BLAKE G inputs are released earlier.

At the gate: 0.8213 of the previous frontier's time; the public record does not split the gain between the three ^{29 30}.

In the browser: its lifetime and compact-column changes were adapted into the memory build; huge pages, a native page mechanism, were not ⁴.

Generalises: Host-specific Transparent huge pages are a Linux kernel feature whose effect depends on the host's THP setting; on one laptop, disabling THP made the whole proof 13.8% slower ¹¹. The two lifetime changes bundled with it are portable and were adapted into the browser memory build ⁴, where their effect is known only in combination with the striped and sourced changes ³¹.

What it does: discards column pages that hold only zeros instead of keeping them resident.

At the gate: peak 6.68 → 5.87 GiB at 1.011 of the frontier's time ^{32 33}.

In the browser: not ported; the port makes no native page calls ⁴.

Generalises: Host-specific It relies on a live-mapping registry in the frontier's large-block cache plus page advice, and is a no-op for other backends and allocators ³³; how much it frees likely depends on how many columns of a given workload are literal zero. The browser port makes no native page calls ⁴, and wasm linear memory cannot return pages ²⁷.

What it does: returns freed heap memory to the system between proof phases.

At the gate: on its own, 1.46 against 1.58 GiB ³⁴; promoted inside the adaptive-blocks stack below.

In the browser: not ported; the port uses no native allocator or page mechanisms ⁴.

Generalises: Host-specific malloc_trim is a glibc call: in a Linux arm64 container at 16 threads it reproduced a small local peak cut with no measurable time cost ³⁵, and on macOS the residual gap behaves differently ³⁶. There is no browser equivalent, because wasm linear memory never shrinks ²⁷.

What it does: frees polynomial coefficients once no later phase reads them.

At the gate: 3% less peak (10.80 against 11.13 GB) and about 0.7 point of time, estimated by comparing two gate jobs ³⁷.

In the browser: not ported.

Generalises: Untested No measurement outside the gate. Freeing data after its last reader preserves proof bytes and may transfer to other prover versions, but its peak effect depends on which phase sets a given workload's peak; later frontiers kept coefficients instead ³⁸, and the browser port's lifetime changes draw on other frontiers ⁴.

What it does: builds the circuit and its preprocessed columns in parallel, and builds the preprocessed tree after the Cairo proof, in that proof's idle buffers.

At the gate: 9.0% faster, and peak 10.02 → 8.24 GiB ^{39 40}.

In the browser: adapted into the memory build's lifetime changes ⁴.

Generalises: Partial The deferral was adapted in the browser port, which moved circuit-only preprocessing and its commitment out of the Cairo leg at the cost of redoing that setup in every proof (initialization fell from about 4.0 s to 1.8 s) ¹⁹; its memory effect there is known only in combination ³¹. The parallel build cannot help in a single-threaded Worker, and the port attributes a further 0.06 GB to lazy circuit preprocessing by inspection, not isolated measurement ²⁷.

What it does: releases the circuit's witness values at the padding step instead of holding them for the rest of the proof.

At the gate: peak 1.80 → 1.56 GiB at time 0.9978 ⁴¹.

In the browser: adapted into the memory build's lifetime changes ⁴.

Generalises: Partial A portable lifetime change: the browser port adapted it without allocator or page mechanisms, and its proofs matched the baseline bytes ¹⁹. Its memory effect there is known only in combination with the striped and sourced changes ³¹.

What it does: builds the low-degree extension one stripe at a time, keeps only stripe 0, and regrows the rest where it is read ⁴².

At the gate: the season's largest single memory step: peak 5.87 → 2.11 GiB, at 1.83x the old frontier's time and 0.94x the unmodified prover's ⁴³.

In the browser: adapted into the memory build with a coefficient-regrowth opening path ⁴; its Merkle trees later became sparse (see sparse Merkle layers) ⁸.

Generalises: Broad Protocol-preserving and reproduced beyond the gate: the same build carried onto a newer proving base for Starknet 0.14.4 kept byte-identical proofs at a similar peak in an 8-CPU cgroup ⁴³, and an early version roughly halved the local peak on two Zen3 hosts ⁴². Adapted into the browser memory build, the combined profile cut requested peak to 0.355 of the baseline but proved 1.40-1.50x slower ³¹, so its time cost transfers too.

What it does: keeps coefficients instead of stripe 0, evaluates composition over bit-reversed subdomain blocks and reads decommitted rows by tiled folds; designed to remove recomputation the striped commitment had added ³⁸.

At the gate: 0.8340 of the frontier's time at a peak of 1.94 GiB against 2.11 ⁴⁴, 0.7756 vs unmodified ^{45 46}.

In the browser: adapted into the memory build with the striped commitment ⁴.

Generalises: Partial Adapted into the browser memory build with the striped commitment ⁴, but the port kept a coefficient-regrowth opening path, which its first memory profile lists as a remaining performance limitation ³¹, so the time recovery that motivated the change is not shown there. Its local gains were measured in a Linux VM only ³⁸; the port's own pass-wise hashing for coefficient-keeping commits later lowered its Cairo base-commit peak from 1.949 to 1.569 GB ¹⁶.

What it does: keeps the circuit's preprocessed columns as compact sources and regrows them where they are read.

At the gate: peak 1.95 → 1.81 GiB ⁴⁷.

In the browser: adapted into the memory build; sampling regrows one column at a time ⁴.

Generalises: Partial Adapted in the browser port, where regenerated columns, roots, openings and proofs compared equal to the originals ⁴⁸; its memory effect is known only inside the combined memory profile, which lists one-column source sampling as a remaining performance limitation ³¹. How compact the sources are likely depends on the circuit's preprocessed columns.

What it does: reads lookup tuples back from the committed trace instead of keeping them.

At the gate: peak 1.58 → 1.37 GiB ⁴⁹.

In the browser: planned for the port as the route to its current Cairo peak ²⁷.

Generalises: Untested Not measured outside the gate. The browser port plans a generic read-back over committed columns as its route to the Cairo peak because it edits no AIR-generated file ^{4 27}, although one season-1 Cairo implementation used generated code ⁵⁰.

What it does: stores circuit columns whose values fit in 8 or 16 bits packed, and regrows them where read.

At the gate: 1.18 GiB peak against 1.58, but at 1.2835 of the frontier's time ^{51 52}. The tested job was not promoted, but the browser port reads packed circuit sources in the final frontier's code ²⁷, so packing may have reached the frontier through a later stack; the season's public records do not say which.

In the browser: planned next for the port, which finds packed circuit base-tree sources in the final frontier's code ²⁷.

Generalises: Untested No measurement outside the gate. Its benefit depends on how many columns fit in 8 or 16 bits, a property of the circuit and workload; the browser port plans it next, estimates about 0.25 GB of circuit tree residency on its workload, and notes it needs regrowth-avoiding readers to hold time ^{4 27}.

What it does: caps the size of transients rather than residents: composition is evaluated in width-adaptive blocks, FRI quotient denominators are inverted per chunk, numerators are accumulated point by point, and regrowth is batched. It was promoted as a stack of five changes that also included heap trims and a lazily built circuit.

At the gate: peak 1.58 → 1.39 GiB at 1.0588 of the frontier's time ^{53 54}.

In the browser: adaptive blocks and chunked denominators were adapted in a separate tradeoffs build; the stack's heap trims were not ⁴.

Generalises: Partial The browser port adapted adaptive blocks and chunked denominator inversion in a separate profile, but its runs showed the same requested peak as the sourced profile ^{31 55}; its later block-wise denominator combine lowered the circuit FRI quotient site without moving the global peak ¹⁶. Block sizes are tuned constants (the port targets 96 MiB) ⁵⁵, and the stack's heap trims are glibc-specific ³⁵.

What it does: commits the circuit in 8 blocks per stripe and caps the composition lookahead. The maintainers recorded it at the close as the smallest gate peak within the unmodified prover's time whose guard stayed within 2% ⁵⁶. The browser port's reading of the frontier's code finds further changes in it, including packed circuit sources and narrowed Cairo lookup data ²⁷.

At the gate: peak 1.40 → 1.13 GiB at 1.1337 of the frontier's time ⁵⁷.

In the browser: its 8-blocks-per-stripe change was measured in the port and not kept (no change to the peak, about 8% slower) ⁸; its striped hashing of packed FRI layers was ported ¹⁶.

Generalises: Partial Mixed transfer: in the browser port 8 blocks per stripe lowered circuit commits from 1.85 to 1.44 GB but left the global peak unchanged and proved about 8% slower, so it was not kept ⁸; the frontier's striped hashing of packed FRI layers was ported and lowered the global peak from 2.312 to 2.107 GB ¹⁶. A stripe count likely helps only where it targets the phase that sets a workload's peak.

What it does: stores the Cairo lookup columns compactly, at the cost of an extra pass over the lookup data ⁵⁸.

At the gate: the lowest peak of the season, 1.04 GiB against 1.39 in the same job, but the extra pass made the larger Cairo-only guard proof 1.086 times slower, above the 2% tolerance ^{59 58}.

In the browser: not ported; its patch is not public ²⁷.

Generalises: Untested Patch not public and no measurement outside the gate; it slowed the larger Cairo-only guard proof, so later code enables it only for the privacy workload ⁵⁸, which suggests a workload-dependent benefit. The browser port attributes an estimated 0.44 GB of its gap to a closely related Cairo lookup tuple narrowing in a public frontier, but declined it because it hand-edits AIR-generated witness files ²⁷.