igneum-network/igneum
1
0
Fork 0
Code Issues Pull requests Releases Activity

fud ledger N15: the 0.3.20 restart cleared three offsets and kept four (the ring's depth against the self-check's); the clean self-check line on 96161037

Browse source 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
igneum-labs 2026-10-07 16:14:07 +00:00
parent 296906f52f
commit f99a092ef8
1 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
docs/fud-ledger.md
View file

@ -2473,7 +2473,7 @@ Why: on every build, 5899f603 and this line alike, `ChainBlockRecord.number` is
Per tier: a home prover whose node drifted is never paid, whatever the card and whatever the claim rule (the settled floor of N11 cures reorged blocks, not numbering), and nothing tells it; a prover on an undrifted node is paid when its proof lands first; the chain itself is right, the carrier's check is right on its own numbering, and the two nodes disagree on what a block is called.
Fix on branch numbering-fix from 52e96c94 (for 0.3.21, after f95178a1): (1) `chain_path` checks the first added block's selected parent against the tip record before anything is appended and hands the orphan records above the fork point to the reorg unwind (`continuity_removed`; the p1-5090 class can no longer happen); (2) a start-time self-check once per process, `first_discontinuity` from the restart pin upward against the DAG's selected parents, names the first break, unwinds the records above it and lets the follower re-walk (the inherited class); (3) `recordsContinuous` and `continuityBreak` on igneum_getProvingStatus and igneum_getExecStatus, null before the check, so a prover claims only on true. Gates: two unit tests known-failed first (the short removed list leaving an orphan; the break at 5 named, a continuous chain None), the exec suite, and the fleet's restart of p1-5090 and p2-3090-3 on the binary (the self-check line, the unwind, offset 0 against the hub after). The carrier cannot resolve a record by hash instead: the segment statement binds the chain block number through the EVM block number and prevrandao, so a drifted node's proof is a proof over the wrong number and the refusal is right; canonical numbering is the only cure. Until the restart on the fix, a drifted node's prover must not claim (the fleet's hub read flags the seven).
Fix on branch numbering-fix from 52e96c94 (for 0.3.21, after f95178a1): (1) `chain_path` checks the first added block's selected parent against the tip record before anything is appended and hands the orphan records above the fork point to the reorg unwind (`continuity_removed`; the p1-5090 class can no longer happen); (2) a start-time self-check once per process, `first_discontinuity` from the restart pin upward against the DAG's selected parents, names the first break, unwinds the records above it and lets the follower re-walk (the inherited class); (3) `recordsContinuous` and `continuityBreak` on igneum_getProvingStatus and igneum_getExecStatus, null before the check, so a prover claims only on true. Gates: two unit tests known-failed first (the short removed list leaving an orphan; the break at 5 named, a continuous chain None), the exec suite, and the fleet's restart of p1-5090 and p2-3090-3 on the binary (the self-check line, the unwind, offset 0 against the hub after). The carrier cannot resolve a record by hash instead: the segment statement binds the chain block number through the EVM block number and prevrandao, so a drifted node's proof is a proof over the wrong number and the refusal is right; canonical numbering is the only cure. Until the restart on the fix, a drifted node's prover must not claim (the fleet's hub read flags the seven). One more fact from the fleet's 16:04Z hub-anchored pass: the 0.3.20 sweep's supervised restart on c4459193 (about 15:2xZ) cleared the offset on p2-3090-3 (46 → 0), p2-3090-1 (5 → 0) and p2-3090-2 (3 → 0) and kept it on p1-5090 (5), p2-4090-1b (6), p1-a5000 (2) and p2-3090-4 (4), with pool-1 newly at 2: a restart re-walks only what the ring or the resumed snapshot rebuilds, so a break inside that depth goes and a break below it stays, which is the depth the start-time self-check covers and the ring does not. On 96161037 the two kept copies without a break read "the 138388 records above the restart pin are continuous with the DAG (0.0 s)" at start (w-target, p12-vast); the live line on a drifted box (p1-5090, break #155958) is the fleet's n15-live run.
## Status updates, 5 October 2026 (ledger sweep, night of 4 to 5 October)