From a6dae2afb87f9a65e4f7beb817a54dad500f9435 Mon Sep 17 00:00:00 2001 From: igneum-labs <337424239+igneum-labs@users.noreply.github.com> Date: Tue, 6 Oct 2026 22:38:20 +0000 Subject: [PATCH] latency ladder design doc: the test lines and the first two harness results (the known-failed case fails, the step case stepped at epoch 8; the two harness faults named) Co-Authored-By: Claude Fable 5.1 --- docs/design/latency-ladder.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/docs/design/latency-ladder.md b/docs/design/latency-ladder.md index 2ca8adc72..0dab59270 100644 --- a/docs/design/latency-ladder.md +++ b/docs/design/latency-ladder.md @@ -106,6 +106,9 @@ A chip's shadow core grows with N at k x 11 pJ per op; at rung 1 the f = 1 GDDR7 Public text: section 10. +Test and build lines (igneum-build-1 through `tools/build-remote.sh`, `IGNEUM_AGENT=ladder`, 6 October 2026, 22:00 to 22:20Z): igneum-pow `test --release`: 61 passed (the first run failed on the rung-1 label 130,000 against the arithmetic's 132,105, corrected to the arithmetic); the fork at 1591ee1d: kaspa-consensus-core 114 passed, 2 ignored (`latency_ladder_rule`, `override_params_carry_the_latency_ladder_and_the_digest_moves_only_when_set`, the 60x file test after the file gained the two 0.3.16-lane fields and `exec_restart_state_root` it lacked); kaspa-pow with the feature 16 passed (`latency_ladder_rungs_are_programs_of_their_own_over_one_day_cache`: one cache build for three rungs, rung 1 another pow, 27 passes equal to rung 0); kaspa-consensus lib 131 passed (the template carries bit 15 only while the ladder is active); igneum-miner, kaspa-rpc-core, kaspa-grpc-core green; `igneumd` and `igneum-miner` built, the commit string carried. Harness results: section 11. + + Implemented: the ladder, activation, window and signal in `Params`, `OverrideParams`, the digest and the 60x file; the pure rule and the bits in `igneum.rs`; `processes::latency_ladder` (the walk, the memo, the step); `EpochSeeds.shadow_reps` through the engine, the header path, the miner and the pack; `PowEpochInfo` and the gRPC fields; the daemon lines; `igneum-pow`: `v4_class_at`, the shadow program path, the id rule, the consumed draws, `--shadow-reps` on the CLI. Tests, the known-failed case first: a changed N today is a hard fork (the same seeds at reps 35 hash another program with the same class and, before the ladder, the same id); the step moves only by signal; 8,999 bps does not move it; a two-step jump is impossible; down never below 0; an inadmissible rung is never entered; rung 0 is `V4_CLASS` byte for byte. Fast-time harness `infra/fast-time/latency-ladder.mjs` (three cases and the failed case, the class harness's shape). Owed: the ladder witness in the pruning proof; the app's signal toggle and its consequences line; a rung check in the three hosts (today a host compiles whatever `IGNEUM_SHADOW_REPS` the pack carries and the Rust pack check binds the pack to its seeds, so a stale pack of another rung fails the miner's own check, not the host's); the O-1.14 laptop run. ## 10. Public text (the litepaper's hash-class paragraph, `site/litepaper.html`, Mining section) and the ledger row @@ -113,3 +116,12 @@ Implemented: the ladder, activation, window and signal in `Params`, `OverridePar The paragraph as placed in the litepaper: "**The work that waits can grow.** Class v4 adds a block of latency-shadow arithmetic to every hash, about 100,000 integer operations that run while the memory reads are in flight, so a chip that stores the whole dataset still has to pay for a core. That size sits on a ladder fixed at genesis, six rungs from about 100,000 to about 1,000,000 operations, and it moves one rung at a time only when 90 percent of blue blocks in each of seven consecutive days ask for it; it can never move two rungs inside a week and never past a rung the reference verifier cannot check under 10 ms with its sibling thread busy (measured on the build server: every rung's cold verify stays under that gate on the quiet core, 5.1 to 8.9 ms). What it buys, on the measured cards: against a dataset-storing chip whose core costs what an RTX 5090's does per operation, the chip's per-joule edge falls from 2.1x at the first rung to 1.3x at the third; against a core as good as the shipping RandomX chip's (Bitmain's Antminer X9, about 3x per joule over a desktop CPU after seven years, approximate), from 3.9x to 2.8x. What it costs, per rung, is measured too: the Apple tier gives up 3 points of rate at the first step and 6 more at the second, the RTX 5090 nothing until the second; so the miners who pay for a step are the ones who take it." The sentence "Monero has run on RandomX since 2019 with no chip publicly shipped" is replaced by the X9 fact. The ledger row is M34 in `docs/fud-ledger.md`. + +## 11. The fast-time gate (igneum-build-1, 6 October 2026, 22:2x to 23:xxZ; `infra/fast-time/latency-ladder.mjs`, the ladder fork's Linux binaries built on the box, three nodes and three CPU miners on `override-60x.json` with class v4 from genesis, class signalling off, the ladder active from DAA 0, windows of 60 DAA) + +| Case | Run | SUMMARY | Summary file | +|---|---|---|---| +| The known-failed case first (`--signal up,up,none --expect step`) | 22:15 to 22:26Z | FAIL as it must: no step over epochs 0 to 10, the weakest-of-seven up share 6,166 to 6,333 bps at the sink from epoch 7 (two CPU miners of three), on the chain 406 blocks up and 198 none (6,722 bps up), no step line on any node, 0 rejected, one sink at 603/603/603; `FAILED CHECK` on eight step checks plus `chain_carries_the_bits`, which was the harness's own fault (genesis carries header version 0 and the low-byte check read it; fixed in the file and recorded there), exit 1 | `/srv/builds/_log/ladder-harness/failed-case.json` | +| All three signal up (`--signal up,up,up --expect step`) | 22:26 to 22:37Z | the chain did what the rule says: `Latency ladder step by miner signal: epoch 8 moves to rung 1 (35 shadow passes, from rung 0): up in each of 7 consecutive windows of 60 DAA ending at seed block beb8b40f..., threshold 9000 bps, weakest up 10000 bps, ... 420 of 420 blue blocks up` on 3 of 3 nodes with the same epoch; the template at rung 1 from epoch 8 (DAA 480, the first epoch whose seed block has seven full windows below it) at 500 s wall; epochs 9 and 10 stayed at rung 1 (no second step inside seven windows); 481 / 132 blocks across the boundary; 0 rejected; one sink at 612/612/612; 612 blocks up and genesis none (9,984 bps up), every object byte 0; the three miners' rung-1 ids equal each other and differ from the same seed's rung-0 id on epochs 8, 9 and 10 (e8 `d4cfc28a1c525077` against `ea49bc6e870eb34c`). The harness reported FAIL on two checks of its own: the genesis low-byte fault above and `rung1_ids_equal_the_cli_rung1_id`, because `igneum-pow show` built its program without `--shadow-reps` (fixed at 6b30e85; the miners' ids were the chain's). Re-run as step2 below with both fixes | `step.json` | +| Two of three signal up (`--signal up,up,none --expect no-step --epochs 10`) | from 22:37Z | RUNNING | `no-step.json` | +| All three signal up, the fixed harness and CLI (step2) | after no-step | QUEUED | `step2.json` |