Abstract

This study compares two fully implemented architectures. In the first, a block entered the canonical chain before recursive proving finished, and a three-stage background pipeline later built the block proof, linked it into the recursive history and advanced a separate proven tip. In the second, the block, matching HistoryStep terminal, State and indexes commit as one atomic result. This moves proof preparation onto the mining critical path, but removes the durable queue, partial promotion and ambiguous restart state: at every accepted height, the block and its recursive proof exist together.

When is a block complete?

State is the authenticated set of current unspent outputs and consensus counters. HistoryStep is the recursive terminal that proves one block's exact transition from its parent State to its child State and verifies the preceding terminal. The experiment asks when it must exist: may a block enter the canonical chain before its HistoryStep is ready, or must both become accepted together? Both designs were implemented to compare their consensus state machines, restart behavior and mining critical path.

Production geometry

The accepted implementation has two authenticated HistoryStep classes. B25 uses m = 22 for up to 25 effective page positions. B255 uses m = 24 from 26 through 255 positions. Both follow the same atomic state machine described below.

Experiment 1. Background proof pipeline

The background-pipeline prototype divided blocks into four fixed proof-capacity classes. Each class had one authenticated constraint matrix for the block transition and another for linking that block proof into the recursive history. A separate matrix anchored the initial chain state.

A recursive-link relation is the constraint system that verifies one block proof together with the preceding HistoryStep and produces the next link in the proved history. All four such relations used m = 22. Here m is the base-two logarithm of the padded witness and constraint domain, so each relation occupied 2^22 field positions. Work then moved through three stages whose intermediate state was saved to disk:

Stage 1Block proofProve one accepted height
Stage 2Recursive linkConsume previous terminal
Stage 3Verify and promoteAdvance the tip covered by recursive proofs

The smaller relations allowed up to three block heights to be processed concurrently. The maximum-capacity relation ran one height at a time because of its larger memory footprint. This overlap improved throughput, but the prototype exposed two consensus progress variables: the canonical block tip and the tip already covered by recursive proofs. Durable proof jobs, in-order promotion, recovery logic and partial pipeline state existed solely to keep those two positions consistent.

Experiment 2. Atomic PoW and HistoryStep

The alternative defines one accepted unit:

accepted block = canonical block bytes + matching HistoryStep terminal

A candidate cannot mutate State, create a reward or be announced until the terminal binds its exact semantic header and State transition. Block bytes, terminal, State and receipt indexes commit atomically. A restart therefore recovers either the complete unit or no block at that height.

State-machine comparison

PropertyBackground pipelineAtomic HistoryStep
Consensus progressBlock tip plus recursively proved tipOne accepted height
Durable intermediate jobsBlock, link and promotion stateNone
Restart casesRecover and drain partial pipelineComplete bundle or absent height
Proof latencyCan lag behind block productionPaid before acceptance
Network objectBlock plus later coverage stateOne complete bundle

The trade-off

Atomicity does not make proving free. Deterministic HistoryStep preparation moves onto the mining path and must be budgeted so supported hardware can keep producing candidates at the network cadence. Proof-of-work nonce search remains probabilistic and difficulty-dependent; it is not a fixed fifteen-second local task.

The benefit is not raw speed. It is removal of an entire consensus-visible backlog state machine.

Result

Accepted rule

If a recursive proof determines whether a block is fully valid, make that proof part of the accepted block object. Background proving is appropriate for optional indexes and caches, not for a second consensus-visible notion of progress.