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

Counter ASIC 3.0 node plan 7.7.7: the release join bench rows (0.3.17 220 ms a checkpoint, the 0.3.20 line with the lazy snapshot 92 ms, same bound)

Browse source 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
igneum-labs 2026-10-07 11:35:38 +00:00
parent b3c2dbe5a4
commit 392ebce68c
1 changed files with 13 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
docs/plans/counter-asic-3-node.md
View file

@ -385,6 +385,19 @@ The 0.3.20 tree's first fresh join of the live devnet (RTX 3070 pod, wiped datad
Fix on release-0.3.20-node: `WEIGHT_TABLE_CACHE` = 1,024 tables with oldest-first eviction, never a clear (`FinalityManager::weights_at`); gated by a unit test that fills the cache past the bound and reads the newest table back without a walk (the known-failed case is the old rule, which leaves one table after each clear). Expected on the next fresh join: the tables fall to about one per checkpoint (5,400 tables, about 15 s on the pod), the bodies thread time with them since the lock is held for the walk; the wall is then the bodies' own cost plus the signatures, about 60 to 70 minutes on the pod, approximate until the 0.3.20 canary's line.
### 7.7.7 The join bench, release rows (box, 7 October 2026, 11:03 to 12:35 UK)
`cargo test --release --config 'env.IGNEUM_JOIN_BENCH="2000"' -p kaspa-consensus --lib join_bench`: 2,000 checkpoints, 67,221 blocks, the joiner fed one block at a time. The measured part is the join; the bench's own chain building (about 10 to 20 minutes) and the compile (1 to 2 minutes) are not.
| Row | Tree | Conditions | Joined | Per checkpoint | Finality thread time |
|---|---|---|---|---|---|
| before | aa49613f (0.3.17) | nice 15, 16 cores, box load 175 to 190 | 425.3 s | 213 ms | bodies 266 s, virtual 62 s, tables 16 s, signatures 261 s |
| after | 420f9305 (0.3.20 feature, snapshot per change) | the same | 538.8 s | 269 ms | bodies 179 s, virtual 206 s, tables 18 s, signatures 29 s |
| before | aa49613f | nice 10, 32 cores, box load 20 to 30 (the d1285cef rule) | 439.6 s | 220 ms | bodies 269 s, virtual 64 s, tables 16 s, signatures 264 s |
| after, lazy snapshot | the 0.3.20 node line (this section's fixes) | the same | 183.1 s | 92 ms | bodies 37 s, virtual 51 s, tables 14 s, signatures 32 s |
Reading: the feature tree's parallel signature pre-verification cut the signatures 8x, but the template snapshot rebuilt on every virtual change (2.1 ms, serialized on the virtual processor) cost more wall than it saved, so the first after row joined 27 percent slower than before. With the snapshot refreshed only while templates are wanted (`template_wanted`, a minute after the last ask), the 0.3.20 line joins 2.4x faster than 0.3.17 under the same conditions (220 to 92 ms per checkpoint; the second before row and the lazy row ran back to back on the same bound). For a miner: a fresh 0.3.20 node replays a day of devnet checkpoints (2,400) in about 3.7 minutes of join on 32 box cores, against 8.8 on 0.3.17; the live join on a pod is set by the bodies and the IBD, see 7.7.6.
### 7.7.5 The proof oracle at never (ledger N9; the 0.3.19 canary's stall, 7 October 2026)
The e69e8a39 canary on c18-1 passed its headers proof and stalled in the block stage at block 2,728: the daemon installed the proof oracle whatever `proving_consensus_verify_daa` said, the IBD flow then demanded the proof bytes of every record-carrying block from the syncer, and the serve flow answers from a peer's in-memory pool (records drop at 600 chain blocks, proof bytes live as long as the process), so a block from months ago was served by nobody; 56 asks of pool-1 and the hub, 110 failed IBDs, every peer 0.3.17, which installs no oracle and so never asked. Fix dc141409 on release-0.3.19-node: `ProofOracle::active_from` carries the switch, and the body rule, the IBD fetch and the relay retry apply from it only (known-failed test on the pure gate). The retention store landed as aea0ca5c on release-0.3.19-node (10:04 UK): the proof archive under the exec db dir's proofs/, one file per proof by the carrying block's DAA, the index rebuilt at start, read after the pool by the oracle's held check and the serve flow, dropped below the pruning point in the chain-facts refresh; the rule applies above the pruning point only (the pipeline skips trusted bodies). Known failed first in its unit test (served by a second instance after the pool holds nothing; gone once the pruning point passes the carrier). The harness hook is e5f993d4 (`--prover`, `--join-after`, per-node exec ports on the join harness); the late-join case runs on the testnet lane's fast-time network with provers, the pre-archive binary its known-failed side.