From 2dd074c189ac0f67d96bb79bbce8d64f988d0dd0 Mon Sep 17 00:00:00 2001 From: igneum-josh <337424239+igneum-josh@users.noreply.github.com> Date: Sun, 4 Oct 2026 21:07:01 +0100 Subject: [PATCH] Site: journey and bench rebuilt after the finality merge Co-Authored-By: Claude Fable 5.1 --- site/bench.html | 13 +++++++++++-- site/journey.json | 20 ++++++++++---------- 2 files changed, 21 insertions(+), 12 deletions(-) diff --git a/site/bench.html b/site/bench.html index b54d940b3..654f15904 100644 --- a/site/bench.html +++ b/site/bench.html @@ -69,7 +69,7 @@ footer{border-top:1px solid var(--line);padding-block:32px 48px;font-size:13px;c

Engineering log

Every measurement the project has made, newest at the bottom, written by the people and agents who ran it, with the commands and hardware. Prototype numbers are not mining numbers and say so.

- +

Igneum bench log

Append-only. Every number here was measured on the machine named, on the date given.

2026-10-03 proto-metal / igneum-bench, first run

@@ -307,7 +307,16 @@ footer{border-top:1px solid var(--line);padding-block:32px 48px;font-size:13px;c

Rollout: the cloud rehearsal in the morning (12 nodes, one chain through N + 600), then the devnet. Node 1, the observer node and the seed were restarted on the v2 binary with --override-params-file carrying {"difficulty_v2_activation_daa": 33000}; the three app machines received the same height through the signed update manifest (the engine writes it to the node's override file and restarts the node at a safe moment), the two PCs within two minutes of an update-now job, the Apple M5 Max on its next check; the height had first been set to 46,500 and was moved to 33,000 at 16:55 UTC by the same route. The height passed at 17:37 UTC: node 1 and the seed shared the sink (ab6bb0a7147b at block 33,291), the observer followed, both PCs' nodes processed blocks normally, difficulty kept moving (150.8M at the height, then stepping down as PC 2's card paused for a proving job). No node forked; no restart of the chain; a consensus rule changed under a running network with miners on three platforms. The first measurement of v2 on the devnet's own regime (two large miners, bursty parallel blocks) needs PC 2 back from its job; the cloud numbers stand meanwhile (settle 157 to 272 s, no swing).

Third run (job run-20261004-r3-shards, 18:59 to 19:02 UTC, 3 min 22 s wall for the shard and both blocks): the buffered save closed the gap, the core proof finished at 19:00:38 and the compressed stage started at 19:00:39 UTC; shard timings repeated within 0.3 s of the first run (core 9.1 s, compressed 10.5 s). The second run (run-20261004-1912-shards) failed in its first second with a guest that returned 0 bytes of public values; the same sources executed the shard on the Apple M5 Max, and a forced rebuild of every source on the RTX 5090 machine cleared it (ledger P20 closed; the package build now has a gate).

4 October 2026, first machine in the United States: a Windows laptop on an Intel integrated GPU, synced and voting

-

A colleague's Windows laptop in the United States installed Igneum Miner 0.3.3 from the downloads link at about 18:52 UTC. Its node took the 38,000 headers and blocks from one peer, the seed node, in about eight minutes across the Atlantic. The only card is an Intel UHD integrated GPU: the OpenCL worker runs at 1.46 MH/s and found one block in its first four minutes; the identity's votes on checkpoints 1202 and 1203 were accepted by the network, so a laptop with no discrete card takes part in finality. Machine id 37ba0461 in the console; app log run win-37ba0461-20261004-185342.

+

A colleague's Windows laptop in the United States installed Igneum Miner 0.3.3 from the downloads link at about 18:52 UTC. Its node took the 38,000 headers and blocks from one peer, the seed node, in about eight minutes across the Atlantic. The only card is an Intel UHD integrated GPU: the OpenCL worker runs at 1.46 MH/s and found one block in its first four minutes; the identity's votes on checkpoints 1202 and 1203 were accepted by the network, so a laptop with no discrete card takes part in finality. Machine id 37ba0461 in the console; app log run win-37ba0461-20261004-185342.

+ +

the maintainers, 4 October 2026 evening: "we need to fix these serious issues before making things public". Both fixes sit behind one height switch, finality_v3_activation_daa (default never on every network, set by the override file like difficulty_v2_activation_daa), on branch finality-fixes of the node (worktree vendor/igneum-node-finality, from the proving head 8c0cff15). Spec 03 Q4 (fold) and Q5 (frozen table), 3.3.1, 3.7 items 2 and 9, 3.10, 3.11; ledger F21 and F22 "Fix built, pending rollout"; the devnet plan in docs/plans/finality-v3-rollout-devnet.md. The live devnet was never touched; every network below ran on ports 29700 to 29799, suffix 970.

+

F22, what was wrong. The cloud logs of the healthy stretch 11:45 to 14:00 UTC (212 indices, 12 miners; tools/finality-attacks/vote-timing.py, output in infra/cloud-devnet/results/2026-10-04/f22-vote-timing.md): the node builds a certificate the instant the votes it holds meet Q3, median 1.24 s (p99 1.71 s) after the first node determined the checkpoint, with 7 to 10 of 12 signers (mean 8.27); 10.24 votes had been issued by then on average (two in flight: the miner's 1-s poll, the 250-ms gossip pump per hop, up to 289 ms RTT) and the last of the 12 was issued median 1.45 s, p90 2.36 s after the first determination. A 1-s hold after the first build would have carried all 12 votes at 192 of 212 indices; the other 20 are miners 01, 06 and 11 down together for 10 minutes (indices 377 to 396, the hop.sh restarts), an outage, not lag. There is no cut-off to lengthen: the fix is a second round. Presence needs nothing, since the block reading of Q2 credits a late vote once any block carries it.

+

The rule built. F22: the first certificate still forms at quorum (lock latency unchanged); once every voter has signed, or certificate_fold DAA seconds after the determination (FinalityParams::certificate_fold, 3 on devnet, 6 on mainnet, serde default 3 so every older override file parses), a node holding a certificate rebuilds it from every vote seen when heavier and gossips it; ingest_certificate replaces a held certificate with a verified heavier one over the same block; templates carry the held one; a lock is never withdrawn. F21: frozen_table finds the highest locked index below i whose block is an ancestor of C_i and takes its weight table (bans applied) while daa(C_i) < daa(C_f) + weight_window; evaluate requires the signers (and a held certificate's signers) to hold two thirds of it at its weights on top of Q3; a locked checkpoint is never downgraded; the LOCKED line carries the frozen fraction and index. Node tests (cargo test --release -p kaspa-consensus-core -p kaspa-consensus -- finality params, 20 of 20): frozen_table_holds_a_side_without_the_other_keys_for_one_window (A 60%, B 40%; B leaves; v2 locks A alone within 30 DAA of B's last block, v3 not before the last lock is one 60-DAA window old, then at once), fold_round_carries_late_votes_and_heavier_certificates_replace (4 of 6 lock, a fifth vote is folded in 2 DAA later, a lighter hand-built certificate is refused, a heavier one replaces), override_params_carry_the_finality_v3_activation, the fast-time file test extended to both fields.

+

Simulator (sim/finality_v2.py scenario M, --seeds 7,11, 496 s at nice 10; tables in sim/results_v2.md, "Rule v3"):

+
Measurev2 (rule as specified, view-local weights)v3 (plus the frozen table)
50/50, 60/40, 55/45 honest partitions, 12 days: first lock alone per sideday 10.2 / 10.1; 5.2 / never; 7.9 / 12.0never / never in every split; 0 conflicts; every pre-heal lock kept; first lock 0 min after the heal
50/50 and 60/40 for 31 days(as above)both sides at day 30.00, when the frozen table expires; first conflict day 30.00 to 30.06
70/30 for 150 and 360 minthe 70 side from minute 0 to 4, the 30 side never, 0 conflictsthe same
67/33 (the 4/2 split at exactly two thirds), 360 minthe 67 side locked in 1 of 2 seeds after 239 min (the 2.2% outage knife edge)never in 360 min
35% and 50% stop mining and signing at oncefirst lock day 1.7 and 10.1day 30.00 for both (the frozen table holds the departed keys until it expires)
equivocator across a 50/50 split, 30% / 33% / 34% of total(H: 0 / 0 / conflicts)0 / 0 / 21 to 69 conflicts from minute 14 to 78: the one-third bound of 3.11.2 is unchanged
+

Fast-time 3-node network (node tools/finality-attacks/v3.mjs, the target-finality build, infra/fast-time/override-60x.json merged with skip_proof_of_work and finality_v3_activation_daa 0, or the file's own "never" for the v2 control; W = 120 DAA; n1 listens, n0 and n2 dial it through TCP proxies that hold every byte 300 ms each way, the stand-in for tc/netem which macOS lacks, so n0 to n2 is 600 ms plus n1's relay; six vmine voters at 1/6 of 1 block/s in all; machine shared with other agents' builds and the live devnet). Raw tables and the v3 split's finality log lines in docs/benchmarks/finality-v3-2026-10-04/.

+
RunCriterionMeasuredVerdict
fold, v2 control, 480 s(baseline)12 locked indices per node; the certificate each node held at the end carried 4 or 5 of 6 votes (means 4.67 / 4.50 / 4.25 on n0 / n1 / n2), never 6; median lock latency 1,008 msthe F22 state reproduced with 300-ms links
fold, v3, 480 sthe held certificate carries at least 95% of connected keys' votes (6 of 6)11 locked indices per node; first-built certificates 4 or 5 of 6 (means 4.75 / 4.36 / 4.45, as under v2); held certificates 6 of 6 at 11 of 11 indices on every node (100%); 9 to 10 fold lines per node ("every voter signed", 0.3 to 1.4 s after the first build) and 1 to 4 replacements by a heavier gossiped certificate; 0 conflicting certificates; median lock latency 1,008 ms, unchangedPASS
split50, v2 control: 3/3 split 150 s (old bound W / (3R) = 80 s at R = 0.5 blocks/s per side), heal window 200 s(the fork of 3.7 item 9)side B (n1, n2) locked alone from 126 s after the cut, 3 locks; side A none; n0 redialled 72 s after the gate reopened; at the end 7 CONFLICTING certificate lines (4 on n0, 3 on n1) and 4 locked indices disagreeing across the three nodesthe fork, as on the morning's three-node and cloud runs
split50, v3: the same cutneither side locks during the split; heal; locking resumes on one chain; 0 conflicting certificates0 / 0 / 0 new locks during the 150 s (the v2 control locked at 126 s, so the frozen table held side B for the checkpoints of the last 24 s; the frozen table would have expired at 240 s); n0 redialled 72 s after the gate reopened; all three nodes resumed at index 7 and reached 13 inside the heal window; 0 conflicting certificates; 0 disagreeing locked indices; every post-heal LOCKED line names the frozen lock and its fraction (81 to 94% of the frozen table)PASS
split70, v3: 4/2 keys, the 4 side at 70% of weight (shares 0.175 x 4 against 0.15 x 2), 150 sthe 4 side locks during the split, the 2 side does not; 0 conflicts4 side: 4 new locks, the first 30 s after the cut; 2 side: 0; heal: all three at 17; 0 conflicting certificates; 0 disagreeing indicesPASS (6B at 70/30; exactly 4/6 is a knife edge under both rules, simulator row above)
+

What remains uncertain. (1) The v3 split's hold was observed over the last 24 s of a 150-s split (the control crossed at 126 s); a longer split under the 240-s expiry (say 200 s) would show more held checkpoints, and the "held by the frozen table" line is logged at debug, which the runs did not enable. (2) No cloud rehearsal: the 12-node the cloud provider network was destroyed at 15:30 UTC, so the 95% target is shown on three nodes with emulated 300-ms links and on the cloud logs' arithmetic, not on the cloud topology itself; the rollout plan names the re-creation and the partition experiment to run first. (3) The frozen reference is the node's own highest lock on the chain, not the certificate carried in C_i's past, so two honest nodes can test one checkpoint against tables 30 s apart; in a connected network those tables differ by a minute of blocks, under a partition both are pre-split, and no run showed a disagreement, but it is a property argued, not proved. (4) The price: a sudden departure of a third or more now pauses finality for a full window (30 days on mainnet) instead of 1.4 to 10 days; a gradual one costs nothing. the maintainers asked for the pause over the fork; the number is stated in spec 3.7 item 2. (5) The fold clock is in memory: a restarted node folds from daa(C_i) + depth, a few seconds late at worst. (6) Binaries, all from finality-fixes 6aa69a45, hashes and checks in the rollout plan's section 2: Mac native fe982a1d... (verified running), Linux 7c100fc2... (cargo-zigbuild, 34 min, not run on a Linux host), Windows cc1d1001... (mingw, 12 min 28 s, the v2 exe's DLL set, cannot run here); the Windows payload inputs were staged with push-inputs.sh --no-deploy into a scratch folder and NOT deployed (plan 7a).

diff --git a/site/journey.json b/site/journey.json index 3a9b0da29..d98366c50 100644 --- a/site/journey.json +++ b/site/journey.json @@ -50,6 +50,11 @@ } ], "log": [ + { + "date": "2026-10-04", + "text": ", finality rule v3: the frozen weight table and the certificate fold , simulator, unit tests, fast-time 3-node network with 300-ms links", + "short": ", finality rule v3" + }, { "date": "2026-10-04", "text": "First machine in the United States: a Windows laptop on an Intel integrated GPU, synced and voting", @@ -180,6 +185,11 @@ "text": "Devnet-v4 integration: nine branches merged, 3-node test network on the merged node, Windows cross-build", "short": "Devnet v4: nine branches merged into one node" }, + { + "date": "2026-10-03", + "text": "Difficulty controller: devnet record, simulator, Igneum dual-lane rule, 3-node CPU test network", + "short": "Igneum dual-lane difficulty rule built and simulated" + }, { "date": "2026-10-03", "text": "First devnet blocks on the real lottery hash: CPU, then Metal GPU, three worker implementations", @@ -239,16 +249,6 @@ "date": "2026-10-03", "text": "Proving v0: first SP1 proof of an Igneum block, Apple M5 Max CPU, loaded machine", "short": "First SP1 proof of an Igneum block, on a laptop CPU" - }, - { - "date": "2026-10-03", - "text": "Windows node package: igneumd cross-compiled for x86_64-pc-windows-gnu, two-peer sync test", - "short": "Windows node package: cross-compiled, two-peer sync" - }, - { - "date": "2026-10-03", - "text": "R3.26 / M15: PoW checked after the cheap checks, cache-build cap, attack before and after", - "short": "Cache-build attack closed: 10.6 s of rebuilds to 14 ms" } ] }