diff --git a/docs/bench-log.md b/docs/bench-log.md index 651a95a35..7dc7d960b 100644 --- a/docs/bench-log.md +++ b/docs/bench-log.md @@ -2646,5 +2646,18 @@ block. An unmodified A refused its own carrying block ("block is known to be inv Consequence per tier: the rule costs an honest node nothing on the hot path (a proof verified at relay time is a cache hit); a cold proof costs a 2019 core 0.4 to 0.5 s and a current one 0.2 s, in parallel per record; a forger -loses its block and its peer. Until 0.3.16.1's finality-horizon skip, a fresh joiner fetches every carried proof in +loses its block and its peer. Until 0.3.17.1's finality-horizon skip, a fresh joiner fetches every carried proof in its IBD window from its syncer (1.27 MB a record), so a syncer must still hold them. + +### 6 October 2026, 22:10Z to 22:28Z, Devnet 2: the zero program-id class and its close (the fleet's reads) + +Devnet 2 (igneum-devnet-2, five nodes on 4c6b129d, 1 block/s, every switch at DAA 0): the nodes ran without a verifier +host or IGNEUM_PROOF_PROGRAM_IDS, so their expected segment statements carried zero program ids at hex offset 472 and +every segment record from the shipped host was refused while 8 of 8 shards passed (seg 2868: chain proof 1.27 MB in +281 s on a 4090). Fix on 4c6b129d: IGNEUM_PROOF_PROGRAM_IDS=0x2b1a81cb...,0x474678f3... on each node process, restart +22:10Z to 22:16Z, same genesis. Result: paidSegments 2 on every node at 22:22:28Z and 4 at 22:28:10Z (two provers, +8-block segments), 0 PoW rejected, one exec state root on all five at height 3,792 (0xab19a0be...), one version +(2.1.0-1279a1d6, digest 4a0b8726). On the 0.3.17 node (fork a344fea3) the override object's proving_shard_program_id +and proving_aggregator_id are the statement's ids when set, so the env is not needed. Consequence per tier: a node +without a host (a pool hand, a seed, a home node that does not prove) must carry the ids in its object or its env, or +it refuses every segment record and pays no aggregator; the 0.3.17 object carries them. diff --git a/docs/fud-ledger.md b/docs/fud-ledger.md index 522cb6fe5..9da30c1bb 100644 --- a/docs/fud-ledger.md +++ b/docs/fud-ledger.md @@ -1781,7 +1781,7 @@ Answer: Correct for v0, and by design for now. The consensus check on a carried Round 2 (5 October 2026, night): the public text now carries the v0 fact, labelled Open: `site/litepaper.html`, Proving, "How a block gets proven": "Open: in proving v0 the SP1 proof itself is checked off the consensus path, by every block producer before it carries a record, and the native-execution check is what consensus enforces; whether the SP1 verifier moves inside consensus is a decision before the public testnet." Status unchanged: decision owner the project lead, decisions item 11. -Round 4 (6 October 2026, 21:0x UTC, the 0.3.16 exec work): Fixed on a branch, pending merge. Fork `exec-sync-0313` da2d17ec puts the proof check on the consensus path: from `proving_consensus_verify_daa` (never by default; with `proving_shard_program_id` and `proving_aggregator_id` in the digest once set) body validation in context verifies every carried record's proof in-process (sp1-sdk's LightProver, the keys embedded from `proving/igneum-prove/elf`) against the pinned program id and the record's statement; a failing proof invalidates the block (`RuleError::IgneumInvalidProofRecord`, the relaying peer disconnected); a proof not held is fetched from the relaying peer (`IgneumRequestProofRecords`, payload 78) and the block retried once, never marked. Measured: 0.204 to 0.232 s a proof on one M5 Max core, 0.400 s on igneum-build-1, release, in-process; the harness `tools/exec-sync/forged.mjs` 8/8 in 23.6 s (an attacker with the rule off carries a forged record; the honest peer asks for the proof, refuses the block in 0.000 s of verify, pays nothing). A node whose embedded keys are not the pinned ids refuses to start. Open for 0.3.16.1: the finality-horizon skip (a block a certified checkpoint covers needs no proof check), so a fresh joiner's syncer serves proofs only for the unfinalised window. +Round 4 (6 October 2026, 21:0x UTC, the 0.3.17 exec work): Fixed on a branch, pending merge. Fork `exec-sync-0313` da2d17ec puts the proof check on the consensus path: from `proving_consensus_verify_daa` (never by default; with `proving_shard_program_id` and `proving_aggregator_id` in the digest once set) body validation in context verifies every carried record's proof in-process (sp1-sdk's LightProver, the keys embedded from `proving/igneum-prove/elf`) against the pinned program id and the record's statement; a failing proof invalidates the block (`RuleError::IgneumInvalidProofRecord`, the relaying peer disconnected); a proof not held is fetched from the relaying peer (`IgneumRequestProofRecords`, payload 78) and the block retried once, never marked. Measured: 0.204 to 0.232 s a proof on one M5 Max core, 0.400 s on igneum-build-1, release, in-process; the harness `tools/exec-sync/forged.mjs` 8/8 in 23.6 s (an attacker with the rule off carries a forged record; the honest peer asks for the proof, refuses the block in 0.000 s of verify, pays nothing). A node whose embedded keys are not the pinned ids refuses to start. Open for 0.3.17.1: the finality-horizon skip (a block a certified checkpoint covers needs no proof check), so a fresh joiner's syncer serves proofs only for the unfinalised window. ### P22. The rewards and payouts are inputs to the shard proof, not outputs "The shard guest takes the segment's rewards and the prover payouts as data and commits the post-root after them. A host can feed any list and the proof still verifies." @@ -2327,9 +2327,9 @@ Same rule as the count above. 167 entries (P23 added by round 2). | Open, found tonight, fix in round 3 | 1 | P23 | | Another agent's tonight | 1 | C4 | -## Status updates, 6 October 2026 (21:0x UTC, the 0.3.16 exec work) +## Status updates, 6 October 2026 (21:0x UTC, the 0.3.17 exec work) -### X31. The prover's segment exports filled the disk under the node +### X34. The prover's segment exports filled the disk under the node The fleet's provers (the kit's box-prover.py) exported the chain with `igneum_exportSegments [0, last]` for every segment, 50 to 500 MB a file, and nothing pruned them: between about 13:00Z and 20:44Z on 6 October 2026 the exports reached 42 GB on the hub (586 segment dirs on a 60 GB disk, 100 percent) and 3 to 46 GB on every standing box (p1-4090 and p2-4070-1 at 100 percent with 45 and 46 GB; p1-4070 97 percent, p2-3090-4 94 percent, p1-3080 87 percent, p1-a5000 81 percent, p2-4090-3 79 percent, p2-3090-3 75 percent, p1-5090 74 percent, p2-3090-2 55 percent, p2-3090-1 38 percent, p2-4090-1b 30 percent, the 8x rig 28 GB), 4 to 6 GB an hour a box. The hub's node died three times: 19:58:08Z and 20:01:55Z on the sync KeyNotFound (a peer's gap sync below retention, another class), 20:42:31Z on "No space left on device"; the supervisor restarted it at 19:59:11Z, 20:02:36Z and 20:44:38Z. Status: Fixed (6 October 2026, 21:0x UTC). At the source: the 0.3.14 export is `[first-1, last]` with the account dump, a few hundred KB a segment, not 50 to 500 MB. In the kit: gpu-fleet f9ad70e (every standing box): a 20 GB and 168 h cap on the export dir enforced before every export, the export deleted the moment its record is accepted or paid, no export under 10 percent free disk (logged); the supervisor's 20-minute prune stays as the belt. In the app: exec-app-0314 4159818 and proving-v2 717148d (`app/igneum-app/src/provingdir.rs`): the same caps on `/proving` (IGNEUM_PROVING_DIR_MAX_GB 20, IGNEUM_PROVING_DIR_MAX_DAYS 7, which leave 80 GB of a 100 GB box to the node and the system), a segment's directory deleted on submission, the free-disk floor before each export with the skip on the Prove page; the cap is a pure function with a unit test. Consequence per tier: a home miner's app never grows its proving dir past 20 GB or a week, and stops exporting (not mining) when the disk is under 10 percent free; a box or a rig the same through the kit.