A new node still validates proof of work and still downloads current State. What it no longer does is download every historical transaction body and execute the chain from genesis. This study records the authenticated snapshot boundary, disk-staged installation, retained suffix and the distinction between constant proof verification and costs that necessarily scale with headers or live State.
Remove replay, not verification
Historical replay combines several different tasks and calls all of them “synchronization.” A node reads headers to compare proof of work. It downloads transaction bodies to reconstruct State—the authenticated set of current unspent outputs and consensus counters. It executes every historical rule to decide whether the reconstructed State is valid. As the chain ages, the third task grows even when the present State stays the same size.
ParanO(1)d replaces historical execution replay with a recursive HistoryStep. Each accepted block proves the exact transition from its authenticated parent State to its child State. The current boundary therefore carries a proof of the transition chain that produced it.
A finalized boundary is a block old enough to lie outside the protocol's permitted reorganization window. The recent suffix is the sequence of no more than eighteen complete blocks between that boundary and the current tip.
A joining node does not download and execute every historical transaction body. It verifies one recursive terminal at a finalized boundary, reconstructs the exact committed live State, then applies a bounded recent suffix.
Costs that remain
Only boundary proof verification is constant in chain age. Header validation and live State transfer still scale with the data a full node must possess.
| Phase | Scales with | Why it remains |
|---|---|---|
| Header validation | Chain height | Proof of work and chainwork must be compared |
| HistoryStep terminal | Constant proof verification | Recursive validity at the selected boundary |
| State transfer | Live State | A node must obtain the data it will serve |
| Recent suffix | At most 18 complete blocks | Connect the finalized boundary to the live tip |
The architecture removes an age-dependent execution log. It does not claim that proof of work can be compared without reading headers or that a multi-gigabyte current State can be installed without moving multi-gigabyte data.
Two synchronization paths
A short gap
Every full node retains the latest eighteen complete accepted blocks. A peer within that window requests atomic bundles containing the semantic block and matching HistoryStep terminal. It checks header continuity, exact difficulty and timestamp rules, the Poseidon2b-based proof-of-work hash, transaction and State commitments, recursive validity, fork choice and finality before materializing writes.
A deep gap
A peer farther behind selects a finalized snapshot boundary:
- download and validate permanent headers;
- select the canonical finalized boundary;
- obtain and verify the matching HistoryStep terminal;
- download the State manifest and referenced segments;
- reconstruct the exact global State root and counters;
- install the staged State transactionally;
- verify and apply the retained complete suffix.
Bind every object to one boundary
A valid proof for height h must not authenticate a manifest from h − 1 or a segment set from another branch. The snapshot manifest therefore binds the boundary height, State root, slot geometry, active count, allocation counter, segment identifiers, segment roots and lengths. The recursive terminal, canonical header and manifest must name the same boundary.
The implementation uses distinct types for header staging, the selected proof session, durable proof work and exact boundary binding. These are not network cosmetics. They prevent a peer from combining individually valid objects into an invalid snapshot package.
Disk staging as a consensus boundary
Segments arrive into an isolated scratch environment. The active database is not updated page by page. Only after every segment, counter, root, boundary header and terminal agrees does the node atomically replace the installed State.
If the process exits, startup removes the incomplete staging environment and resumes from the last canonical database. This avoids a recovery mode where consensus code has to decide which fraction of a peer-provided snapshot became authoritative.
Header staging and State installation are disk-backed and allocation-bounded. The peer controls payload bytes but does not control an unbounded decoder allocation or force the complete candidate State into RAM.
The peer is a data source
A seed or snapshot peer does not sign the State and does not become a checkpoint authority. It supplies headers, terminals, manifests and segment bytes. The joining node derives canonicality from proof of work and validates the recursive and State commitments itself.
This is the central difference between a convenient snapshot and a trustless snapshot. In the latter, changing the distributor does not change what State the verifier accepts.
Recent reorganization and finality
The finalized boundary cannot be reorganized. Fork choice considers only candidates that preserve it, and the accepted rollback depth is less than eighteen blocks. Recent complete blocks and undo data cover the suffix. A deeper competing branch is rejected rather than “repaired” by installing a different snapshot.
This rule keeps the snapshot authority aligned with recursive validity. Without a hard boundary, a node could authenticate one present and then be asked to reconstruct a deep alternative history whose bodies it intentionally did not retain.
Four checks, no snapshot authority
Bootstrap separates four kinds of evidence:
- headers establish the greatest-work eligible chain;
- HistoryStep establishes validity at the boundary;
- the manifest and segment roots establish the exact current State;
- the retained suffix establishes freshness to the live tip.
A peer supplies bytes for all four stages but controls none of their acceptance rules. Transfer and staging can change without turning a cache, seed or snapshot mirror into a checkpoint authority.