pi-fold 4.2.0

pi-fold 4.2.0

A session load no longer costs more the longer the session runs.

A load replayed every delta since the session's only checkpoint and rebuilt the whole state at each one, so the cost was the delta count times the state size: quadratic in session length. One real 2,207-delta session spent 129.6s inside the restore, against 0.6s for pi to parse the same 93MB of entries; another spent 56.1s on 1,147 deltas. Doubling a session's entries quadrupled the time. The load is not paid once either: session_start, session_tree, session_compact and a branch switch each pay it, so with doubleEscapeAction: "tree" it sat behind a keypress.

Two changes bound it. The reader restarts the replay at the NEWEST checkpoint rather than refusing a second one, and persist closes the run with a fresh checkpoint every 50 deltas, so a load walks at most 50 deltas however long the session runs. And each fold is proven once per replay instead of once per delta: recomputing 375 content addresses and rehashing 375 fold subtrees at every one of 2,207 deltas could not reach a verdict the durable record had not already settled. A fold arriving for the first time still meets the full check.

Steady-state loads on those two sessions: 4.62s and 2.75s, reaching a state identical by digest, revision and forest to what the full replay produced. Right after a checkpoint, 0.34s and 0.20s. A session already past the bound heals itself on its next durable write. A checkpoint costs bytes where a delta does not, about 11% of a session file at this cadence.

A failed restore no longer writes the checkpoint that used to latch a session dead. persistedWireVersion read 0 both for a session that never had durable state and for one this build could not read, so a restore that threw appended a second checkpoint to a branch that already had one, the reader refused exactly that, and every reload made it worse: one session reached five checkpoints and grew from 859 entries to 4,393. The write is now refused where the restore error is known.

Compatibility: reading is backward compatible and every existing session still loads. A 4.1.6 reader refuses a ledger this version writes, so downgrading suspends folding on any session that has taken a second checkpoint.

Gates 174 and 175 cover the bound and the proof; gate 173 covers the refusal. Runtime suite 70 gates.