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.
Experiment 1. Background proof pipeline
The experiment divided blocks into four fixed proof-capacity classes: B8, B32, B64 and B255. The number in each name was the maximum number of user transactions that the class could prove. Each class had one authenticated constraint matrix for the block transition and another for linking that block proof into the recursive history; a ninth matrix anchored the chain at genesis.
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:
The three smaller classes—covering blocks with at most 64 user transactions—allowed up to three block heights to be processed concurrently. The maximum-capacity B255 class, which covered up to 255 user transactions, ran one height at a time because of its larger memory footprint. This overlap improved throughput, but consensus now exposed two 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:
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
| Property | Background pipeline | Atomic HistoryStep |
|---|---|---|
| Consensus progress | Block tip plus recursively proved tip | One accepted height |
| Durable intermediate jobs | Block, link and promotion state | None |
| Restart cases | Recover and drain partial pipeline | Complete bundle or absent height |
| Proof latency | Can lag behind block production | Paid before acceptance |
| Network object | Block plus later coverage state | One 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 proof-class measurements are recorded separately in Why HistoryStep uses two proof classes.
The benefit is not raw speed. It is removal of an entire consensus-visible backlog state machine.
Result
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.