The Present Must Prove the Past · Parano1d Lab

Skip to content

On this page Carrying validity forwardWhat is history still for?State only needs to represent what exists nowValidity does not choose a winnerThe hard part is provingWhat cryptography should the present rest on?The new architecture became Parano1dHow I got recursive proving down to 10.7 seconds on a laptopWhat does end-to-end post-quantum soundness from genesis mean?Parano1d's main result<br>Can a blockchain validate its current state without replaying the entire execution history from genesis?

A new node can be handed a perfectly well-formed snapshot of a blockchain. Every record may decode correctly. Every commitment may match. The data can be internally consistent in every obvious way.

None of that answers the question that matters:

Why should this state be accepted as the result of the chain?

Bitcoin answers by reconstructing it. Start at genesis, verify the chain, execute every transaction, and derive the current UTXO set yourself.

The evidence for the present lives in the past.

Snapshots can make that process faster. Checkpoints can move the starting point. Specialized infrastructure can perform the historical work elsewhere and distribute the result.

But none of those changes the underlying relationship. The state you have in front of you still does not prove that it was reached through a valid sequence of transitions from genesis.

That was the relationship I wanted to invert.

The interesting question was not simply whether blockchain history could be compressed into a recursive proof. It was this:

What if the validity of the current state were itself something consensus carried forward?

Then a new node could receive the current state together with proof of the valid path that produced it. It would not need to replay the network's lifetime execution just to establish why the present is valid.

The expensive part of state validation would no longer grow simply because the chain had grown older. The work required to authenticate the present would be tied to what exists now, rather than to every transaction the network has ever processed.

Carrying validity forward

Let ShS_hSh​ denote the state after block hhh, and let πh\pi_hπh​ denote the proof associated with that state.

For each new block, the proof must establish two facts:

πh−1 is valid<br>applying block Bh to state Sh−1 produces exactly state Sh

The result is a new proof, πh\pi_hπh​:

(Sh−1, πh−1) + Bh<br>prove transition<br>(Sh, πh)

Each proof verifies the previous proof and incorporates one more transition. At block height ten million, the proof does not contain ten million separate proofs. Its shape remains fixed as the chain grows. Transition validity moves forward recursively.

That leads to an important consensus question:

When does the proof become authoritative?

If πh\pi_hπh​ is the reason ShS_hSh​ is accepted as valid, then the proof cannot be an auxiliary certificate produced sometime after the block. The justification for accepting a state must exist at the moment the state enters consensus.

Otherwise the protocol ends up with two independent tips:

proven state tip ---------->">accepted block tip<br>proven state tip

The gap between them now needs its own semantics. What does an unproven tip mean? Which tip is authoritative? What survives a crash? How does proving resume?

The cleaner rule is atomic acceptance:

accepted block<br>=block<br>+recursive proof

A new state enters consensus together with the proof of the transition that created it. State and proof advance together, so consensus has a single notion of progress.

The recursive proof is no longer a separate certificate about history.

It carries the reason the state is valid from one block into the next.

Once historical execution no longer serves that purpose, the role of history itself begins to change.

What is history still for?

If the current state already carries a recursive proof of valid ancestry, a new node no longer needs historical block bodies to establish the validity of the present.

That does not make the past irrelevant. Sometimes what matters is one particular event that happened earlier .

Suppose I make a payment and later need to prove that the network accepted it. I can keep the transaction and its Merkle path. Together, they let me reconstruct the block's transaction root and prove that the transaction was included in that block.

One fact is still missing.

A block can be valid, propagate across the network, and still lose to a competing branch. Inclusion in a block is not the same as inclusion in the canonical chain.

A payment proof therefore needs to answer two questions:

01Was this transaction included in this block?<br>02Was this block part of the canonical chain?

The transaction and its Merkle path answer the first question.

We could make the recursive proof commit to an authenticated block history that supports openings at arbitrary heights, but there is no reason to give it that...