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

Ledger: F22 placed after F20

Browse source 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
igneum-labs 2026-10-04 14:41:42 +00:00
parent 4951a46218
commit 8345bc2f7a
1 changed files with 9 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
docs/fud-ledger.md
View file

@ -26,15 +26,6 @@ Evidence locations referenced below: `docs/bench-log.md`, `proto-metal/TESTS.md`
## 1. Mining and ASIC claims
### F22. Certificates carry 8 to 10 of 12 votes on a healthy network, so locks sit a hair above the floor
"Two of your cloud checkpoints locked at 66.8% against a 66.7% floor with every node connected. One slow aggregator and finality pauses."
Status: Open, found by the team (4 October 2026, 12-node cloud devnet, second partition run).
Answer: True as measured. With all 12 miners connected the certificates carried 8 to 10 of 12 votes (66.7 to 89% of total weight at 14:00 UTC); checkpoints 437 and 439 locked at 66.8%. The missing votes are late votes that miss the aggregation window, not absent voters. Experiment: measure vote arrival against the aggregator's cut-off on the cloud network (inter-region RTT up to 289 ms) and on the devnet; candidates are a longer aggregation window, a second aggregation round that folds late votes into the certificate before it is carried, or counting a vote that arrives after the certificate toward the next checkpoint's presence. Owner: finality.
Evidence: `infra/cloud-devnet/results/2026-10-04/partition-sin-20261004-140305/partition.md`; bench-log "Hetzner partition and hash-step".
### M1. The program space is tiny
"Eleven integer ops, 64 instructions, 8 iterations, a splitmix register init. That is not RandomX. RandomX leans on a superscalar out-of-order CPU with floating point and branches. Yours is a sea of 32-bit ALUs and a memory bus. A chip for that is a weekend."
@ -1339,6 +1330,15 @@ Answer: Correct on the gap. Spec 4.3 proposes that the seed checkpoint may be th
Evidence: spec 4.3 (O-4.3), 3.3.1, 3.5, 3.7 item 2, 3.9. Experiment: O-3.16. Review: external, point 2.
### F22. Certificates carry 8 to 10 of 12 votes on a healthy network, so locks sit a hair above the floor
"Two of your cloud checkpoints locked at 66.8% against a 66.7% floor with every node connected. One slow aggregator and finality pauses."
Status: Open, found by the team (4 October 2026, 12-node cloud devnet, second partition run).
Answer: True as measured. With all 12 miners connected the certificates carried 8 to 10 of 12 votes (66.7 to 89% of total weight at 14:00 UTC); checkpoints 437 and 439 locked at 66.8%. The missing votes are late votes that miss the aggregation window, not absent voters. Experiment: measure vote arrival against the aggregator's cut-off on the cloud network (inter-region RTT up to 289 ms) and on the devnet; candidates are a longer aggregation window, a second aggregation round that folds late votes into the certificate before it is carried, or counting a vote that arrives after the certificate toward the next checkpoint's presence. Owner: finality.
Evidence: `infra/cloud-devnet/results/2026-10-04/partition-sin-20261004-140305/partition.md`; bench-log "Hetzner partition and hash-step".
### P16. The proving gate can be passed by shrinking the shard
"'A mid-range GPU proves a shard in under 20 s.' Your own R2 says: if missed, halve the shard and re-measure. That is the trap. Fix the workload first, measure the whole journey, and have strangers reproduce it."