Anchor warp: spend the tip cluster's idle time proving backwards from the anchor

[defenwycke]

The tip cluster proves each new block as it is mined, then waits. A block arrives every ~10 minutes and proving one takes well under that (966,256 proved in 544 s on rented 4090s), so the cluster is idle most of the time. Anchor warp spends that idle time proving the block below the anchor and folding it in, so the anchor walks backwards toward genesis one block at a time.

This is the plan already published on hazync.org ("Proving the whole chain"): the proof party climbs from genesis, the tip cluster works down from an anchor, and the gap closes from both ends. Until they meet, a proof starting at the anchor rests on that checkpoint, much as Core's assumeutxo rests on a snapshot hash. When they meet, the checkpoint stops being something anyone has to trust.

What already exists

• The fold is the same operation, in the other direction. fold-range takes two adjacent ranges and checks the seam in the guest: [N..N] + [N+1..M] -> [N..M]. Prepending a block below a range needs no new proving mode. extend-spine is just the genesis-pinned specialisation of it.
• Submissions already accept arbitrary widths. parse_any_range takes any lo-hi, and the board labels a range anchored only if it starts at block 1 — a warped range is honestly labelled unanchored until it meets the spine.
• The pre-state format is right. Each bundle carries height, in_tip, in_roots, in_leaves, in_nbits, in_time, in_epoch_start, in_recent plus the witness — exactly what proving that block needs.

What is missing

1. A work source that goes downward. claim() scans upward from block 1 and hands out the earliest unproven block; there is no way to ask for "anchor − 1". Needs an endpoint (or claim mode) that serves the block below a named anchor, and coordinator state tracking each anchor's current low-water mark.
2. Idle detection in the worker. The cluster should warp only while waiting for the next block, and drop it the moment a new tip block arrives — tip blocks always win.
3. Fold-in and bookkeeping. After proving anchor−1, fold it into the anchored range and publish the new, lower anchor. Same shape as the spine's absorb step, so the same failure modes apply: a lost race should self-heal, not abort.

⛔ The blocker is pre-state, not proving

To prove block N you need the accumulator as of N−1. The bridge keeps one forward-walking checkpoint (bridge_load_state → a single st.height) and the accumulator only advances by applying blocks; the snapshot format notes that leaf order depends on deletion history, so it is not trivially invertible.

Measured on the coordinator today:

• 230,000 bundles on disk, heights 1..230,000, 95 GB. Nothing prunes them — there is no bundle deletion path anywhere in the coordinator.
• Disk: 1.5 TB used, 495 GB free.
• Earlier measurement (2026-09-08): the bridge walks at 15.6 blocks/s and costs ~2.05 MB/block at the 220k era, projecting ~1.5 TB to reach the tip — and that is an under-estimate, since bundles grow with block size.

So:

• Below 230,000, anchor warp would work today — every block's pre-state is already on disk.
• An anchor near the tip has no bundles beneath it, and producing them means walking the bridge from 230k upward through ~736k blocks, which is the retention/disk problem, not a proving problem.

⇒ Either the anchor starts where bundles exist, or this needs a second bridge cursor (walk forward from a lower snapshot, retaining a window below the anchor), or a way to reconstruct pre-state downward. That choice should be made before any code is written.

Open questions

• Where does the anchor start, and who publishes the checkpoint it rests on?
• One anchor or several (each cluster warping its own region, folding when they touch)?
• How is warp work shared without two cards proving the same block? The existing foldable pattern (advisory, duplicates discarded) probably transfers.
• What does the board show for a range that is verified but not genesis-anchored, so nobody reads it as "proven from genesis"?

How to know it works

An anchor at height A, left idle for an hour, should sit at A − (number of idle slots), with one verified range [A−k..tip] and no gaps. Cheapest first test: pick an anchor inside the bundled region (say 200,000), warp it down 20 blocks, and check the folded range verifies and the seam holds at every step.

[defenwycke]

Proposal: drop the downward mechanism — give the idle tip cluster the existing claim queue

Working through bundle supply for the whole chain (2026-09-17) inverted the case for warp. Putting it
here because the reasoning only becomes visible once #40's bridge speedup is taken into account, and
this issue predates that.

The blocker was pre-state, and the fix for it is forward-only

This issue's blocker section is right: proving block N needs the accumulator as of N−1, the bridge walks
forward from a single checkpoint, and leaf order depends on deletion history so it is not invertible.

The fix is not to invert it. It is to keep the checkpoints the bridge already makes
(HAZYNC_BRIDGE_CKPT=2000, currently overwritten into one state.bin) and walk forward from the rung
below any target. That is roadmap item 6.6, already scoped as "cheap insurance".

But once generation is forward-only, warp loses its reason to exist as a separate mechanism.

Warp is strictly more expensive than party work, for the same blocks/hour

	needs	cost
idle cluster proves lowest unproven block	the rolling forward window the bridge already does ahead of the frontier	nothing new
idle cluster proves anchor − 1	a checkpoint ladder, because it jumps to arbitrary high heights, then walks forward anyway	~174 GB at 25,000-block rungs

Both prove one block per unit of idle time. The chain is covered at the same rate. One of them additionally
needs a downward claim endpoint, per-anchor low-water-mark state in the coordinator, and reverse fold
bookkeeping — this issue's own "what is missing" items 1 and 3.

And the work source already exists. This issue says:

claim() scans upward from block 1 and hands out the earliest unproven block; there is no way to ask
for "anchor − 1".

Read the other way, the coordinator already serves the lowest unproven block to anyone who asks. An
idle tip cluster calling claim() needs no coordinator change at all.

Bundles near the frontier are also far cheaper to produce than bundles near the tip — inputs per block,
measured on the archive node 2026-09-17:

height	inputs	height	inputs
79,427	42	500,000	4,370
182,000	210	800,000	4,911
230,000	253	960,000	1,684

Bridge cost is two Forest::prove calls per input, so frontier-region work is roughly 20x cheaper to
supply than mid-chain work. Warp consumes the expensive end by construction.

What survives

Item 2, idle detection, is still needed and is unaffected: the cluster should take backlog work only
while waiting, and drop it the moment a new tip block arrives — tip blocks always win. That holds whichever
direction the backlog work comes from.

What is lost, and it is a product argument not a throughput one

Warp's real product was contiguous coverage adjacent to the tip, so a recent proof could rest on the
anchor much as Core's assumeutxo rests on a snapshot hash, long before the party climbs 880,000 blocks.
Dropping warp gives that up. If that property matters for G4, it deserves its own issue stated as a
coverage goal — but it does not justify the ladder on throughput grounds, because there are none.

Suggested disposition

Close this in favour of: idle tip cluster calls the existing claim(), keeping item 2 (idle detection)
as the only implementation work. Reopen the tip-adjacent-coverage question separately if G4 needs it.

⚠ Numbers above are measured except the mid-chain walk projection, which infers bridge cost scaling from
input counts rather than timing the bridge at those heights. That timing has not been run.

[defenwycke]

Closing: not doing this — the pre-state cost is the whole objection, and we chose regeneration instead

Decision taken 2026-09-21. Nothing here was wrong; the blocker this issue named itself is the reason.

The blocker, measured again today on hazync-proof (not quoted from the issue):

/srv/bulk/hazync/bridge_bundles entries	418,269
highest bundled height	418,268
on disk	1.2 TB

The tip bridge runs HAZYNC_BRIDGE_EMIT_FROM=967500, so heights 418,269 … 967,499 have no bundles at all — roughly 549,000 blocks. Those 418,268 low blocks already cost 1.2 TB (~2.9 MB/block averaged over the small early chain); tip-era blocks are far larger, which is how the >9 TB figure for the gap was arrived at. An anchor anywhere near the tip therefore has no pre-state beneath it, and manufacturing it is a storage project, not a proving one.

What we did instead. #378 (merged 2026-09-18) regenerates a gap bundle on demand from an archived rung. That is the same need — pre-state for an arbitrary height — answered by recomputation rather than retention, and it costs no standing disk. Anchor warp as specified here is the retention-shaped answer to a question we have since answered the other way.

What stays true and is worth keeping in mind if this ever comes back:

• The fold really is direction-agnostic; fold-range checking the seam in the guest would have served a downward walk unchanged.
• Below 418,268 the pre-state is on disk today, so the cheap test this issue proposed (anchor at 200,000, warp down 20) is still runnable if anyone wants the shape demonstrated.
• The idle time is real — the tip cluster does sit idle between blocks. If we want to spend it, the cheaper candidates are blocks in the bundled region, claimed through the existing upward claim(), with no new anchor bookkeeping and no second bridge cursor.

Closing as decided against. Not stale, not blocked — declined.