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

fud ledger N11: young claims lose their block to one-block reorgs (records refused "is not chain block"); the settled claim floor for 0.3.20

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

10
docs/fud-ledger.md
View file

@ -2109,6 +2109,16 @@ Per tier: a prover cutting a fixture at a block below the thin boundary on a res
Fix, owed to the exec lane rather than built here: a resumed node re-executes from its exec restart through the bodies it holds (its retention root is 27276) and replaces every thin record above the restart with a full one, once, at start; and the exporter refuses a thin segment ("record {n} is thin: no transactions to replay; resume from a full snapshot or re-execute") instead of replaying it as empty. Until then the fleet's exports below about 129,000 are not replayable and no port root below that line is evidence of anything.
### N11. A prover claims a segment 10 to 38 DAA behind the tip and the devnet's one-block reorgs take its block before the record is carried, so carried records are refused "is not chain block" and the proof lands late or never (hub-1's records, 7 October 2026, 11:3x UK)
The claim rule as it stands (box-prover.py `candidates`, app `segments::candidates`): a segment is claimable when every block of it is `open` (past the 10-DAA exclusive window), unpaid and absent from the pool, and its deadline (`last_daa + unproven_daa`, 600 on the devnet) leaves at least `need` DAA (240 or 1.5 x the last prove); candidates are ranked by a hash of (first, key). The "margin" the prover logs is the DAA left before the deadline, not the segment's age: 2,684 claims on hub-1 read margins 562 to 589, so the claimed segment's last block sat 10 to 38 DAA behind the tip, and with one candidate per pass it was the newest whole open segment. There is no settled-depth floor at all. The records show the cost: of the segments carried around 161910 to 162046, 161926 was refused twice (carriers 161998, 161999), 161958 three times at 162001 before another key's record paid it at 162029, 161982 once at 162040, 161910 once at 161951, every refusal "block ... is not chain block ... on this chain": the segment's block had been reorged out between the claim and the carry (hub-1: 14,453 selected-chain reorgs, deepest 58). A proof over a block that is no longer a chain block is unpaid work and a reopened segment, and the lag the observer sees is the sum of the refused attempts.
Found while reading the same log: hub-1's own prover has failed every cut since segment 141054 (2,410 "port state root differs ... 0x8e1bef4b" lines to 162054 at 10:28Z): it exports from the exec restart and parts at 72142 (N10), so the hub has claimed 2,685 segments and proved none in that span; the fleet lane holds it.
Per tier: a prover on a young claim loses the prove (30 to 60 s of GPU) whenever a reorg touches the segment and sees the proof lag as minutes; a home prover with one GPU loses the whole pass; the chain pays nothing twice and loses nothing, but segments go unproven past the 600-DAA deadline when every claimant is refused. The observer reads "planned then paid" with minutes between because the first carried record was refused.
Fix on release-0.3.20-node: the worklist (`igneum_getAssignedShards`) carries `settled` per row and `igneum_getProvingStatus` carries `settledNumber`, `settledDaa`, `settledBy`: the floor is the latest LOCKED finality checkpoint when there is one (a block below a lock moves only under a certificate-driven reorg, rule C4), else the tip less 64 chain blocks (`SETTLED_FALLBACK_BLOCKS`, above the devnet's deepest observed reorg). The provers claim only segments whose last block is settled (box-prover.py and app `segments.rs`: `settled` in place of `open`, their lanes). What the floor becomes on the devnet: the latest lock trails the tip by about 20 to 50 blocks (checkpoint interval 30, depth 20, the certificate within seconds), so a segment is claimable 20 to 50 s after its last block instead of 10 to 38, and the refusal class goes to zero for settled claims; block to paid is then the floor plus the prove plus one template, about 60 to 120 s on the devnet, from today's shape of refused carries and a second claimant. A reorg deeper than the margin: below a lock only a certificate-driven reorg moves the chain; the carried record is refused as today ("is not chain block"), nothing is paid for it, and the segment reopens for a claim on the new blocks; above a lock (the depth fallback) the same as today. The before row is hub-1's refusal count per 100 carried records over the hour before the provers switch; the after row the hour after; a fast-time harness only if the live rows disagree.
## Status updates, 5 October 2026 (ledger sweep, night of 4 to 5 October)
`docs/review/ledger-sweep-2026-10-05.md` holds the runs, the commands and the running table. Every Open, Proposed, Unmeasured or pending entry was read against its experiment line; the status lines above carry the evidence inline, marked "Sweep (5 October 2026)" where a note was added and "Was:" where the status changed. Items owned by the other two night branches (F23, F24, G12, X18, the flood memory growth; the base-fee floor, testnet parameters, G13, G14, public text) were left to them.