Why HistoryStep uses two proof classes

What B64 and B255 mean

State is the authenticated set of current unspent outputs and consensus counters. HistoryStep is the recursive proof that binds a block's exact State transition to the preceding HistoryStep, forming a chain of proved States. B64 and B255 are two fixed capacities for that same proof relation. A physical user page is one fixed-size part of the PagedSpend transaction format; one logical spend may occupy several pages. B64 covers blocks with up to 64 such pages, while B255 covers 65 through the consensus maximum of 255. The classes enforce the same validity rules: the larger one only provides more proof capacity.

The study asks whether a third geometry between them would make block production materially faster or more efficient without adding unjustified protocol surface.

Why class count is a consensus decision

Every HistoryStep class adds a new authenticated constraint matrix to the matrix pack—the release bundle whose matrix digests are pinned by the verifier—plus a selection rule and a verifier branch. A middle class is useful only if it covers an operating range that the existing classes cannot.

The study tested B64 and B255 with the production assembler, prover, terminal codec and verifier, the frozen matrix pack and the complete local wallet path. HistoryStep preparation was measured against a fifteen-second reference gate instead of inferred from row counts. This is a deterministic proof-production budget, not a claim that one miner must discover proof of work within fifteen seconds.

The measured reference host

In the table below, m is the base-two logarithm of the padded witness and constraint domain: m23 contains 2^23 field positions and m24 contains 2^24. The p50 value is the median of the twenty retained runs; p95 is their nearest-rank 95th percentile.

The run used an Intel Core i7-1365U, 10 cores and 12 threads, AVX2 with VPCLMULQDQ, no AVX-512, thin link-time optimization (Thin LTO), one codegen unit and target-cpu=native. The desktop was active and already thermally hot. Parent-proof construction, wallet authorization, proof-of-work search and durable block commit were outside the timed interval.

B64 passed the nearest-rank p95 preparation gate by 613 ms. One of its twenty retained samples reached 15.333 seconds. B255 remained outside that gate on the same host: it required 1.984× more p95 preparation throughput to reach fifteen seconds.

The network's fifteen-second block target is an expected proof-of-work interval. Nonce search is probabilistic and depends on difficulty and a miner's share of network hash rate; it was deliberately excluded from this proof-class benchmark. The result applies to one measured laptop and one release profile: the host meets the B64 preparation gate and not the B255 gate.

What the two classes cover

A logical PagedSpend may contain 128 pages, 1,020 inputs and 256 outputs. A block may contain 255 physical user pages, 1,020 inputs and 510 outputs. The fixed parent representation covers both m23 and m24; those transaction limits do not require a third recursive geometry.

One authorization capsule across 1,020 inputs

The wallet run measured page construction, logical hashing, one randomized authorization capsule—the proof object showing that one owner secret controls all selected inputs—encoding and decoding of the atomic intent—the single logical transaction envelope shared by all of its pages—and local admission. Network latency and HistoryStep proving were excluded.

Intent bytes grow with fan-in. Capsule size and proving time remain nearly flat because authorization is grouped by owner rather than by physical page.

The release-profile comparison

A baseline twenty-sample run used default release code generation with the same relation, witness, pack and benchmark procedure. Thin LTO and one codegen unit changed only machine code:

Profiling placed nearly all proof time in the polynomial commitment scheme (PCS) and the post-commit recursive phase. The profile change improved those cross-crate paths without changing consensus data or matrix geometry.

Reproducing the authenticated pack

The complete two-leaf pack was regenerated from an empty output root and compared byte for byte with the release pins:

• generation time: 5,596.2 seconds;
• B64 compressed leaf: 4,584,391 bytes;
• B255 compressed leaf: 11,912,603 bytes;
• runtime metadata: 1,732,922 bytes;
• complete pinned pack: 18,229,916 bytes.

The regenerated metadata and both leaves matched their recorded digests.

Recorded decision

B64 and B255 covered the two demonstrated operating regions. The study also implemented an intermediate 128-page class, an alternative authorization-capsule layout and a design that split authentication across multiple Merkle trees. Measurements did not establish a workload that required any of those additional authenticated geometries, so they were removed before the class bank was frozen.