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

Counter ASIC 3.0 status: the blocker closed (G4 re-run with the id assertion green), every gate green, the line for the project lead confirmed

Browse source
This commit is contained in:
igneum-labs 2026-10-06 16:45:52 +00:00
parent 365e927200
commit 4e6c6fc87c
1 changed files with 6 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
docs/plans/counter-asic-3-status.md
View file

@ -187,16 +187,18 @@ No publish, no manifest, nothing on the live devnet; PC 2 one job at a time with
| G2 | the CPU verifier exact on 1,024 random hashes per card | GREEN on NVIDIA and Apple; AMD OWED (job run-ca3-pc1-amd-g2-20261006 ready on the chain-seed packs v4-devnet-epoch0 and mx8-devnet-epoch0 with the verifier's digests 435b976a... and 2a1824a2..., its own 198 KB kit; the first kit's sh256x27 is a string-seed pack the worker's job protocol refuses, so it cannot be served; queued after the Ember run) | 24 runs of 1,024 of 1,024 (eight packs on the 5090, Metal, Apple OpenCL), re-hashed on the Mac with `igneum-pow hash-bound --count 1024` on the same packs; tooling item: the found lines go to a file with a count and digest (in hand) |
| G3 | the soundness suite green on the class | GREEN | the crate suite 96 of 96 (97 on the merged tree at 17:17Z, cargo 1.99); the Metal fuzz 200 of 200 and 50 of 50; Apple OpenCL 20 of 20 and 5 of 5; 4 of 4 CPU tests on the class and on the era-composed class |
| Verifier benchmark | ms per warp on one M5 Max core, v2 / x8 / v4 in one session, gate 10 ms | GREEN | 2.33 ms on the candidate (x8 2.06), about 5.8 ms on a 2019-class core by the 2.5x rule (approximate); the 2019-class core itself still unmeasured (O-1.14) |
| G4 | the fast-time 3-node network across a v4 activation, plus the known-failed case | GREEN | run 1 (15:54 to 15:59Z, class-v4.mjs, activation 150 rounded to epoch 3 at DAA 180, the v3 switch at 60): 3 of 3 switch lines, templates class 2 / 3 / 4 by epoch, 181 blocks before and 128 after DAA 180, program ids agree on all three miners and no v2 or v3 id reappears under v4, rejected 0/0/0, one sink at 308/308/308, one digest; the first v4 epoch's cache ready in 2 ms (the v3 day cache reused across the boundary); run 2 the known-failed case (the switch at never: no v4 epoch reported) |
| G4 | the fast-time 3-node network across a v4 activation, plus the known-failed case | GREEN (and GREEN again on the id fix with the id assertion and its failed case, 491131a) | run 1 (15:54 to 15:59Z, class-v4.mjs, activation 150 rounded to epoch 3 at DAA 180, the v3 switch at 60): 3 of 3 switch lines, templates class 2 / 3 / 4 by epoch, 181 blocks before and 128 after DAA 180, program ids agree on all three miners and no v2 or v3 id reappears under v4, rejected 0/0/0, one sink at 308/308/308, one digest; the first v4 epoch's cache ready in 2 ms (the v3 day cache reused across the boundary); run 2 the known-failed case (the switch at never: no v4 epoch reported) |
| G4b | a real Metal miner across a v4 boundary through --prepare-packs | GREEN | run 3 (16:02 to 16:07Z, igneum-bench from the committed tree): 5 PREPARE lines 5 to 6 DAA before each boundary, three `class=v4 era=<hex>`, the worker's `prepared` lines (430 ms the first with the v4 day built on the GPU, 139 and 175 ms with the day resident; a v3 prepare 62 ms), every swap with no pause, 301 blocks accepted on the Metal miner (123 after the switch) all re-checked on the CPU mismatched 0, `need` 0, no mismatch or out-of-date line, no exit 42 or 44 |
| G5 | the PC-built Windows workers and the Mac workers from the same commit | GREEN, one gap named | the Windows workers cross-built on the Mac from a522d04 as 0.3.11's G5 did (the build job has no worker unit: a tooling gap): igneum-worker-cuda.exe e563126e... (1,536,512 bytes), igneum-worker-opencl.exe 7fce1249... (478,208), both with the resource block, mingw not bit-reproducible (a link-time stamp); the Mac igneum-bench 30c70754... from the same tree, the binary G4b mined with; the node and app from PC 2 job build-20261006-155958, every sha256 verified |
| G5 | the PC-built Windows workers and the Mac workers from the same commit | GREEN, one gap named (re-done from the fix 7c22d0d: cuda.exe 3bc8ad8f..., opencl.exe 16ef0154..., igneum-bench f9ca4b07...) | the Windows workers cross-built on the Mac from a522d04 as 0.3.11's G5 did (the build job has no worker unit: a tooling gap): igneum-worker-cuda.exe e563126e... (1,536,512 bytes), igneum-worker-opencl.exe 7fce1249... (478,208), both with the resource block, mingw not bit-reproducible (a link-time stamp); the Mac igneum-bench 30c70754... from the same tree, the binary G4b mined with; the node and app from PC 2 job build-20261006-155958, every sha256 verified |
| G6 | the node suites on PC 2 with --features igneum-pow, from a fork branch off the current release tip | GREEN | fork ca3-v4-node 5f7e0543 on release-0.3.13-node; PC 2 job build-20261006-155958 (15:59 to 16:08Z under the lock, the app untouched, the prover on): every stage ok in 392 s; kaspa-consensus 98 (2.0's flake did not recur), consensus-core 109 + 7 (`override_params_carry_the_program_class_v4_activation`), kaspa-pow 15 with the v4 engine test under the feature, p2p-flows 33, igneum-app 112 + 26 + 8 |
BLOCKER before any cut (found by the hash lane, 17:0x UTC): `program_id(3, seed, attempt)` is class-independent, so all seven v4 packs carry the same program id as the v3 control of their seed (73bcbfe8ccf988f1), and a stale worker across the activation would see no id mismatch (2.0's G4 id check cannot fire on it; G4's per-epoch ids differ only because each epoch has its own seed). The fix is on the v4 seam, assigned to the node lane: a generator-4 stamp in the id so a v3 and a v4 program of one seed differ, v2 and v3 ids byte-identical, the packs re-exported (fingerprints unchanged, ids moved), G4's id assertion and the fuzz re-run. FIX MERGED (ca3-v4-node 7c22d0d, 17:3x UTC): the trap was the CLI's --era path (stamp_era stamped generator 3 on any class), not the chain seam (the fork already stamped generator 4 and its kaspa-pow test asserts the same-seed v3 and v4 ids differ); now generate_era and the CLI stamp the generator from the class, the shadow block marks class v4 in packcheck.rs, packfile.h and main.swift (a generator-3 pack with a shadow block is refused as "a v4 program stamped v3", a generator-4 pack without one refused; the ladder packs stay loadable); v2 and v3 ids byte-identical; the crate suite 97 of 97 on the merged tree; the seven gate packs re-exported with generator 4, class "v4" and program id c120d7963abdcd96 (the v3 control keeps 73bcbfe8ccf988f1), only the generator, id, class and comment lines changed, the kernels and vectors byte-identical. The hash lane's re-run on the fix is GREEN (ca3-v4-hash ca61dec, merged; `hash-gates.md` "Follow-up 1"): the crate suite 97 of 97; the seven packs re-exported here equal the tree's (0 differing files); the fingerprints unchanged on the rebuilt Metal and Apple OpenCL harnesses (all eight); Mac G2 through the `class=v4` token 1,024 of 1,024 on all eight packs, both harnesses; the fuzz 200 programs and 800 units, stats, edge and determinism 4 of 4 on the class and 4 of 4 era-composed, the same-seed v3 and v4 ids now differ (`assert_ne`). Still open before the cut is green: the G4 re-run with the id assertion and its own failed case (node lane, running) and the Metal fingerprints from the node lane's packbench (running). Two conditions ride with the fix: every kit sent to a PC carries the re-exported packs (the AMD G2 kit is being rebuilt from the merged tree), and the mixer.rs harness change rides with any merge of 7c22d0d (it does, on ca3-coord). The PC 1 AMD rows taken on the old-id packs stand: the id is not an input to the hash.
BLOCKER before any cut (found by the hash lane, 17:0x UTC): `program_id(3, seed, attempt)` is class-independent, so all seven v4 packs carry the same program id as the v3 control of their seed (73bcbfe8ccf988f1), and a stale worker across the activation would see no id mismatch (2.0's G4 id check cannot fire on it; G4's per-epoch ids differ only because each epoch has its own seed). The fix is on the v4 seam, assigned to the node lane: a generator-4 stamp in the id so a v3 and a v4 program of one seed differ, v2 and v3 ids byte-identical, the packs re-exported (fingerprints unchanged, ids moved), G4's id assertion and the fuzz re-run. FIX MERGED (ca3-v4-node 7c22d0d, 17:3x UTC): the trap was the CLI's --era path (stamp_era stamped generator 3 on any class), not the chain seam (the fork already stamped generator 4 and its kaspa-pow test asserts the same-seed v3 and v4 ids differ); now generate_era and the CLI stamp the generator from the class, the shadow block marks class v4 in packcheck.rs, packfile.h and main.swift (a generator-3 pack with a shadow block is refused as "a v4 program stamped v3", a generator-4 pack without one refused; the ladder packs stay loadable); v2 and v3 ids byte-identical; the crate suite 97 of 97 on the merged tree; the seven gate packs re-exported with generator 4, class "v4" and program id c120d7963abdcd96 (the v3 control keeps 73bcbfe8ccf988f1), only the generator, id, class and comment lines changed, the kernels and vectors byte-identical. The hash lane's re-run on the fix is GREEN (ca3-v4-hash ca61dec, merged; `hash-gates.md` "Follow-up 1"): the crate suite 97 of 97; the seven packs re-exported here equal the tree's (0 differing files); the fingerprints unchanged on the rebuilt Metal and Apple OpenCL harnesses (all eight); Mac G2 through the `class=v4` token 1,024 of 1,024 on all eight packs, both harnesses; the fuzz 200 programs and 800 units, stats, edge and determinism 4 of 4 on the class and 4 of 4 era-composed, the same-seed v3 and v4 ids now differ (`assert_ne`). The node lane's re-run on the fix is GREEN (ca3-v4-node 491131a, merged): G4 re-run 16:32 to 16:38Z on igneumd and igneum-miner rebuilt on the fixed crate, SUMMARY PASS, 181 / 125 blocks across DAA 180, rejected 0/0/0 and 0/0/0, one sink at 305/305/305, and the id assertion: every v4 epoch's id on all three miners equals the CLI's class v4 id for that seed and era and differs from the same-seed v3 id (e3 30544487d1289d6e against 1ae1c9f0eda0cef5, e4 53e36801cc6fafcf against af81f6e844959460, e5 876e155e3fb59983 against b4f25c4678496a78); the assertion's own failed case (`--id-check-against v4`) reports exactly `FAILED CHECK v4_ids_differ_from_the_same_seed_v3_id`, exit 1. The seven re-exported packs' Metal fingerprints by packbench equal the table (only the ids moved). G5 re-done from 7c22d0d because packfile.h and main.swift moved: igneum-worker-cuda.exe 3bc8ad8f..., igneum-worker-opencl.exe 16ef0154... (resource block verified), igneum-bench f9ca4b07...; kaspa-pow with the feature 15 of 15 on the rebuilt fork. THE BLOCKER IS CLOSED: the gate table is green on the hash and on the cut, with AMD G2 and the AMD watts the owed rows (queued on PC 1). Two conditions ride with the fix: every kit sent to a PC carries the re-exported packs (the AMD G2 kit is being rebuilt from the merged tree), and the mixer.rs harness change rides with any merge of 7c22d0d (it does, on ca3-coord). The PC 1 AMD rows taken on the old-id packs stand: the id is not an input to the hash.
The per-tier cost line of the candidate (item 8, measured): the 5090 -0.2 percent of rate at 350 to 431 W (a rig about 23 percent more electricity), the M5 Max -1.5 percent at 21 to 37 W, pool users nothing, the verifier +0.17 ms per warp; the 9070 XT and the 4070 rows land with the PC 1 jobs. Owed before the cut, besides the blocker: AMD G2 (1,024 nonces on the 9070 XT, queued on PC 1 after the Ember run), the AMD watts (the sampler fix is in; the re-run queued), the 2019-class core (O-1.14; the US laptop's CPU could answer it with a Windows igneum-pow build, a proposal), the G2 found-lines file and digest and the 200 KB report cap (tooling, in hand on ca3-v4-hash).
THE ONE LINE FOR [user]: class v4 (`mx8+sh256x27`, 100,000 ops per hash in the latency shadow) is ready for a whole-fleet one-sweep cut (the digest moves, so every node takes it in one publish) once the program-id fix passes G4's id assertion and the fuzz re-run; its cost is the 5090 at 431 W instead of 350 for 0.2 percent less rate (a rig pays about 23 percent more electricity), the M5 Max at 37 W instead of 21 for 1.5 percent, the 9070 XT no rate at all (its watts pending), the verifier +0.27 ms per warp; what it buys is the stored-dataset chip's per-joule edge over the 5090 falling from 5.6x to 2.1x at a chip core equal to the GPU's; proposed for a day when no other cut is in flight, not tonight (0.3.14 and the fleet night come first).
Facts for the cut from the node lane (docs/plans/counter-asic-3-node.md): the devnet digest moves (c562d70e... to 3c505021...), so the cut is a one-sweep binary rollout and a 0.3.13 node is refused at the handshake afterwards (intended, fleet-wide); a 0.3.13 miner reads the v4 height as never (an optional proto field), so miners and nodes move together; `infra/fast-time/override-60x.json` as committed carried the proving-v1 block twice and lacked four 0.3.12 and 0.3.13 fields (the node refused the file; fixed, with a new CI check `override-json-check.sh`); the 48 GiB target clone `vendor/igneum-node-ca3v4/target-ca3v4` can go after the cut.
THE ONE LINE FOR [user]: class v4 (`mx8+sh256x27`, 100,000 ops per hash in the latency shadow) is READY for a whole-fleet one-sweep cut (the digest moves, so every node takes it in one publish): every gate is green on the fixed tree, the program-id blocker closed with its own failed case; its cost is the 5090 at 431 W instead of 350 for 0.2 percent less rate (a rig pays about 23 percent more electricity), the M5 Max at 37 W instead of 21 for 1.5 percent, the 9070 XT no rate at all (its watts pending), the verifier +0.27 ms per warp; what it buys is the stored-dataset chip's per-joule edge over the 5090 falling from 5.6x to 2.1x at a chip core equal to the GPU's; proposed for a day when no other cut is in flight, not tonight (0.3.14 and the fleet night come first).
## 6. Decisions for the project lead