diff --git a/docs/bench-log.md b/docs/bench-log.md index bf151e2cf..ee14048ff 100644 --- a/docs/bench-log.md +++ b/docs/bench-log.md @@ -1017,3 +1017,17 @@ file, so an OTA-delivered v2 node would have forked at N; fixed with `node_overr (`igneum-app.json`, one `NODE_OVERRIDE_PARAMS` line in `packaging/mac/packaged-config.sh` read by both packagers; the engine writes `/app/override-params.json` and passes the flag). Rule: N = DAA at the manifest publish + 10,800 at least; since N is baked at the cut, choose DAA + 14,400 when committing the line and check at publish. + +## 4 October 2026, difficulty rule v2 activated on the live devnet at DAA 33,000 by height switch, no fresh chain + +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 Mac on its next check; the height had first been set to 46,500 and was moved to +33,000 at 17:55 BST by the same route. The height passed at 18:37 BST: 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). diff --git a/site/bench.html b/site/bench.html index ad0e323d3..b1d20fcca 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

@@ -267,7 +267,41 @@ footer{border-top:1px solid var(--line);padding-block:32px 48px;font-size:13px;c
StageApple M5 Max CPU (4 October, loaded)RTX 5090 (job id, UTC)
shard at S_p (block-338-shard1, 6.75 M pgas): execute60.0 M cycles, 9 per pgas, 6.9 s (block-344 shard 0, the same size)
shard at S_p: core proof (prove s, bytes, verify s)not run at S_p (200-pgas shard: 83.1 s, 7,310,257 B, 0.368 s)
shard at S_p: compressed proof (prove s, bytes, verify s)not run at S_p (200-pgas shard: 272.3 s, 1,272,897 B, 0.075 s)
two-shard block (block-341-shards2): compressed proof per shardnot run
two-shard block: aggregation (prove s, bytes, verify s)not run (three 200-pgas shards: 244.5 s, 1,272,909 B, 0.084 s)
two-shard block: end to end, first shard proof to the verified block proofnot run (three 200-pgas shards: 1,139 s)
four-shard block (block-344-shards4, near B_p): compressed proof per shardnot run
four-shard block: aggregation (prove s, bytes, verify s)not run (aggregator statement 1.66 M cycles)
four-shard block: end to endnot run
setup (one per program id)39.4 to 60.6 s (client plus two key setups)
GPU idle wait before the run, package download and extract, build (incremental)

Reading: pending the run. What it decides: the first S_p point (the shard stage time on the card against the 20 to 60 s proof lag of the litepaper), whether the P20 Drop fix holds on the GPU path (exit 0, no abort after the results), and the gap before the first compressed stage (the ten silent minutes of the v0 run).

4 October 2026, first outside machine on the devnet: an Apple silicon laptop through the Igneum Miner app

-

A friend of the project installed Igneum Miner 0.3.1 from the DMG on an Apple silicon laptop (machine id 3a9bf309, no toolchain, no instructions beyond the five steps in the morning summary: drag to Applications, Open Anyway in Privacy & Security once, Get started, Make me an address, Start mining). Node synced from the seed and the LAN-less path (the seed at the public address first), the Metal worker reported ready and the first block was accepted within the first minutes; after 7 minutes: 33 accepted blocks, 0 rejected, 21.0 MH/s average (24.3 MH/s at the moment of the report), CPU re-check OK on every share. Node 1 counted 7 peers with the laptop connected. The log intake received its uploads every minute under the per-install id, so the machine is observable without any contact from its owner. Observed by the team; the machine is not ours, so this is the first row that is not "the project's own hardware".

+

A friend of the project installed Igneum Miner 0.3.1 from the DMG on an Apple silicon laptop (machine id 3a9bf309, no toolchain, no instructions beyond the five steps in the morning summary: drag to Applications, Open Anyway in Privacy & Security once, Get started, Make me an address, Start mining). Node synced from the seed and the LAN-less path (the seed at the public address first), the Metal worker reported ready and the first block was accepted within the first minutes; after 7 minutes: 33 accepted blocks, 0 rejected, 21.0 MH/s average (24.3 MH/s at the moment of the report), CPU re-check OK on every share. Node 1 counted 7 peers with the laptop connected. The log intake received its uploads every minute under the per-install id, so the machine is observable without any contact from its owner. Observed by the team; the machine is not ours, so this is the first row that is not "the project's own hardware".

+

2026-10-04 (afternoon) proving v0 end to end on a 3-node test network (Mac, CPU prover)

+

Machine: Apple M5 Max, load 5 to 8 shared with the live devnet, other agents' builds and a Windows cross-build in the last minutes. Node: branch proving of the fork at 8c0cff15 (vendor/igneum-node-proving/target/release), 3 nodes on 127.0.0.1:29800+, network igneum-devnet-955, infra/fast-time/override-60x.json with skip_proof_of_work and proving_v0_activation_daa 60; three igneum-miner vmine producers sharing 1 block/s and voting; node 0 with IGNEUM_PROOF_VERIFIER = the SP1 host, nodes 1 and 2 in trust mode. Prover: proving/igneum-prove host built 14:58 (guest rebuilt with the payouts input), SP1_PROVER=cpu. Script: tools/proving-v0/run.mjs; report tools/proving-v0/report-2026-10-04.json. Second run; the first (14:08) failed at the carriage step because the template never carried the record section (fixed in 8c0cff15), everything before it identical.

+
StepMeasured
Activation DAA 60 reached62.8 s after start (DAA 65)
Transfer executed in chain block 6865.8 s
Shard plan of block 68: 1 shard, 200 pgas (one transfer, intrinsic only), 3 eligible keys of 67 window blocks, 3 assignees (every eligible key holds a slot), shard credit 633,911,390,000,000,000 weiidentical on nodes 0 and 1
igneum-prove-export on the chain export (68 segments)0.005 s; plan equals the node's (pre-root, post-root, links, receipts root, pgas)
igneum-prove-host --mode compressed, shard 0 of block 68execute 0.027 s, 293,603 cycles; compressed proof 61.3 s, 1,272,897 bytes, local verify 0.029 s; 70.3 s with setup
igneum-miner sign-record + igneum_submitProofRecord to node 1 (trust mode)accepted (native statement matched), 137.6 s after start
Record on node 0 over p2p (message 71)1.0 s after the submission
Carried by a block and paid on node 0 (chain block 150, carrier 0x8302cf39...)4.0 s after the submission
Node 0's verifier (SP1 compressed proof against the shard vk, statement compared)VERIFIED, 9.3 s in all (SP1 client and key setup; the verify itself 0.029 s)
Payout on all three nodes0x8cc1b0cf4062c00 wei on each; the payout address holds exactly the shard's credit; pool escrow 100.16 IGN after the payment
End to endPASSED in 150.6 s
+

Reading. The whole loop (plan, export, cut, prove, sign, submit, relay, verify, carry, pay) runs and three nodes agree on the payment. The exporter's cut equals the node's cut on the same trace, which is the condition for a prover to prove what the node pays. The 200-pgas shard is the smallest possible (one plain transfer); its 61 s compressed proof on this CPU is a correctness number, not a throughput number, and says nothing about S_p. The verifier's 9.3 s is nearly all SP1 setup per invocation (the pool runs one process per proof); a resident verifier would cut it to the 0.03 s verify. The trust-mode nodes carried the record before node 0 had verified it, which is the v0 limitation of spec 7.7 item 4 in one line: carriage and payout rest on the native statement, verification on the producer's pool policy.

+

4 October 2026, cloud devnet: 12 igneumd nodes in 5 locations, inter-region latency, two Singapore partitions, hash-rate steps (consensus-engineer)

+

Machines: 12 the cloud provider Cloud VMs (hel1 x3, fsn1 x3, ash x2, hil x2, sin x2; cx23 2 shared vCPU in the EU, cpx21 3 vCPU in the US, cpx22 in Singapore, nodes 08 to 11 ccx13 2 dedicated cores), Debian 12, chrony, private-network mode (one the cloud provider network per zone, four public gateways with NAT and one DNAT port per private node; infra/cloud-devnet/README.md). Node: igneumd 2.1.0 from devnet-v4 6457ca95 with igneum-pow 2ee37fa (the live devnet v4 build copied from the seed), network igneum-devnet-20, genesis bits 0x1e400000, 12 one-thread CPU miners with one BLS vote key each, sparse --addpeer ring plus chord (3 peers per node), finality interval 30, depth 20, weight window 7,200 DAA, floor 2/3 of total, dual-lane difficulty rule v1. Everything in infra/cloud-devnet/results/2026-10-04/ (summary.md, hop-series.tsv at 10 s, both partition directories, per-node logs).

+

Inter-region RTT (ms, median of pair averages, ping): hel1-fsn1 35, ash-hel1 118, ash-fsn1 135, hil-ash 75, hil-hel1 174, hil-fsn1 191, sin-hel1 188, sin-fsn1 205, sin-hil 238, sin-ash 289; inside a location 0.4 to 0.7.

+

Block propagation, 10-min window at 10:30 UTC, 644 blocks, 642 seen by at least 80% of nodes (arrival at a node minus the first arrival anywhere, across about 3 hops): p50 343 ms, p90 497 ms, p99 666 ms, max 2,313 ms. Per region p50 / p90 / p99: fsn1 239 / 470 / 491, ash 291 / 464 / 595, hel1 291 / 455 / 661, hil 357 / 632 / 698, sin 413 / 610 / 744.

+

Partition, Singapore (igneum-05 gateway and igneum-10 behind it, 2 of 12 miners) cut from the three other gateways for 10 min by iptables on the sin gateway (INPUT, OUTPUT and FORWARD, ports 26611 and 27001:27099), both sides mining:

+
Run (UTC)Window state at healMinority reorg depth at heal (05, 10)Majority reorgHeal: minority on the majority chain afterLocks, minorityLocks, majorityFirst lock after healConflicting locks
1: cut 11:09:22, heal 11:21:34filling, DAA 3,030 of 7,200431, 4962 (tip churn)10 s, 14 s (IBD of 643 / 646 headers, then the reorg)none possiblenone possiblenone possible0
2: cut 14:03:23, heal 14:15:36locking since index 208 (DAA 7,228, 12:12:07 UTC)423, 469011 s, 15 s426 at 14:03:21.8, 3.5 s before the cut; 427 to 440 determined, none locked427 to 447, every interval, 66.8% to 84.5% of total (437 and 439 at 66.8%, the floor is 66.7%)majority 448 at 13 s; minority adopted certificates 427 to 440 at 11 s and locked 441 itself at 12.5 s (85.0% of total)0 over 107 compared indices
+

Singapore held 15.8% of the window weight (579 + 557 blue blocks of 7,200). Reorg depth over the whole 4-hour run, every node: 37,113 chain removals, p50 1, p99 3, max 5 outside the two heals (443 to 516 at the heals).

+

Hash-rate steps (hop.sh; 4 threads on a 2-vCPU VM is x1.6 to x2.7 per node, measured from the miners' status lines):

+
StepNetwork hashDifficulty beforeFirst extreme (time after step)Settled whereRate while settling2-min rate within 10% of 60/min for 3 min
6 of 12 nodes to 4 threads0.159 to 0.226 MH/s, x1.4280.1k133.7k, x1.67 (6 min)134k, 90k, 129k, 95k over 20 min (±20%, 8-min period), then 95k to 122k47 to 83 blocks/min for 20 min, 50 to 70 after751 s
back to 1 threadx0.70115.0k75.7k, x0.66 (3 min)97k to 105k for the remaining 12 min (80k expected)40 to 57 blocks/min for 15 min, mean 49.5not within 900 s
hel1's 3 miners offx0.7597.1k51.2k, x0.53 (2 min)54k to 66k34/min in minute 1, then 45 to 68241 s
hel1 backx1.3254.1k86.6k, x1.60 (1 min)86k sliding to 78k over 17 min35 to 66 blocks/min, mean 55.1646 s
+

Reading. Latency: the real inter-region path is 0.3 to 0.7 s per block for 99% of blocks, under the 5-s bound behind GHOSTDAG k and well under spec 03 C1's 2-s inter-region assumption. Partition: the floor rule did what the design says (DECIDED 4 Oct 2026, O-3.15): the 15.8% side locked nothing, the 84.2% side locked every 30-s interval, no index was certified twice, and both sides were on one chain within 15 s of the heal with the minority's 420 to 500 blocks reorged out. The margin is thinner than the weights suggest: certificates carried 8 to 10 of 12 votes with everything connected (signed 66.7% to 89% of total at 14:00 UTC), so during the cut the majority locked at 66.8% twice; the missing votes are the open question (finality owner). Controller: with 12 small steady miners the dual-lane rule overshoots every step (x1.6 to x1.7 on x1.3 to x1.4, x0.53 on x0.75), swings ±20% for 20 min after a step up and then damps, and holds the rate 10 to 20% under target for 10 to 15 min after a step down; none of the settle times is near the simulator's 62 s for x50, and the /1.42 step had not settled in 15 min. The live devnet's two bursty GPU miners oscillate without damping; this network damps. Both regimes are now measured on real timestamps.

+

What failed: the first partition ran before the window had filled (no lock possible) and a second was added after the first lock, about USD 0.30; the script's sink-count heal criterion reported 539 and 768 s and is tip churn (replaced with the chain-removal heal time); its first-lock poll reported 807 s because it started after that wait (replaced with the journals); the Apple M5 Max hibernated on a flat battery from 11:56 to 13:16 UTC during the hop schedule, so the 4-thread phase ran 94 min instead of 15 (the scripts now hold the machine awake with caffeinate); the schedule's 4 threads gave x1.42, not x2.5. Another agent's difficulty-v2 rollout (infra/cloud-devnet/rollout-v2.sh, activation DAA 16,170) restarted every node one at a time between 14:14:40 and 14:18:05 UTC, the last 56 s of the second cut and its heal window: the cut-phase locks, the reorg depths and both minority heal times are unaffected (the minority reorgs at 14:15:47 and 14:15:51 came before those nodes' rollout restarts); the majority's first lock after the heal (448, 13 s) was on igneum-01 69 s after its own restart and carries that caveat. Finding for the execution owner: both minority nodes logged "[igneum-exec] reorg deeper than the snapshot ring; replaying from genesis" at both heals. Cost: USD 2.82 net by 14:34 UTC, USD 0.57 per hour while the network stays up (it was left running). Caveats: CPU hash rate only, one afternoon, 12 nodes not 1,000, clocks by chrony.

+

4 October 2026, correction: the 78-minute observer gap was the Apple M5 Max hibernating

+

The "observer fell 45 minutes behind" entry left the cause open. The cloud-devnet agent's logs show the Apple M5 Max hibernated on a 1% battery from 11:56 to 13:16 UTC: node 1, the observer node, observer.mjs, the Apple M5 Max miner and every agent on the machine stopped; the two PCs, the seed and the cloud network carried the chain (no gap in the chain itself: every block the observer later stored carried its original header time). The lag-proofing stays (it is right on its own), the restart loop stays, and the public-face watch now runs from the same machine, so it also sleeps when the Apple M5 Max does; the fix is the charger and keep-awake, not software. The cloud scripts now re-exec under caffeinate -i.

+

2026-10-04 (afternoon) the app's prover loop end to end on the Apple M5 Max (Igneum Miner engine, packaged binaries, private test network)

+

Machine: Apple M5 Max, load 2 to 31 through the runs (other agents' builds and a Linux cross-build of the SP1 host ran alongside). Network: tools/proving-v0/run.mjs --network-only (3 proving nodes on 29800+, igneum-devnet-955, 60x fast time, activation 60, node 0 with the SP1 verifier, nodes 1 and 2 in trust mode, three vmine voters at 1 block/s). App: app/igneum-app engine (release, commit 77ea5b6) staged at /tmp/igneum-app-proving with bin/ = the proving node and miner (vendor/igneum-node-proving/target/release), the Metal worker, igneum-prove-host and igneum-prove-export (proving/igneum-prove/target/release), and an igneum-app.json whose node_override_params is the fast-time profile with skip_proof_of_work and the activation height; environment IGNEUM_APP_DEVNET_SUFFIX=955, RPC 29850, peers 127.0.0.1:29811 and 29801. Driven through its own API (setup with a pasted address 0x4343..., start, api/prove {on:true}); the Proving tile read every 5 s from api/state.

+

Run 1 (14:36 to 14:49 UTC, mining on the Metal worker at 12 to 20 MH/s): tile states as they happened:

+
Wall (UTC)TileNote
14:36:53idle, "no shard assigned to this machine in the last 60 blocks", 3 blocks acceptedthe key needs 5 blue blocks in the 120-DAA window (dust)
14:37:49idle, 5 blocks acceptedeligible from here
14:37:59proving block 140 shard 0 (0 txs, 0 pgas), assigned 10, "proving on the CPU (slow)"the first plan after eligibility assigned the key to 10 of the last 60 shards
14:40:02submitted (proved 1, submitted 1)compressed proof 107.0 s; the app's node accepted the record (verify Off: the app's node has no verifier, it relays)
14:40:04(node log) chain block 259 paid 634,083,030,000,000,000 wei to 0x4343...2 s after the submission; carried by a trust-mode node's block
14:43:22, 14:46:12blocks 268 and 447 proved (143.1 s, 115.3 s) and paid the same waythe tile still said paid 0
+

Defect found and fixed (efb2c2e): the tile looked for the payment in the 60-block work list, and a 2-minute CPU proof is 120 blocks, so every paid shard had scrolled out before the next poll. Second defect found and fixed (12df531): a proof in flight outlived the app on quit (the host kept running); the host and the exporter are now polled children killed on quit, on switch-off and at the limit (checked after run 3: no host process left).

+

Run 2 (14:50 to 15:01): the difficulty had risen on the app's extra blocks (the controller holds 1 block/s, the voters supply that alone), the Metal worker found 2 blocks in 10 minutes, the key never reached 5 in the window, and the tile stayed idle: a machine without mining weight gets no assignment. Fixed by policy (77ea5b6): with nothing assigned, the loop takes an open shard (past its 10-DAA exclusive window, unpaid; spec 7.2 item 4 says anyone may prove it and is paid).

+

Run 3 (15:02 to 15:04, the fix above), tile states as they happened:

+
Wall (UTC)Tile
15:02:22(engine up, node restarting)
15:02:27proving block 1579 shard 0 (0 txs, 0 pgas, open), "proving on the CPU (slow)"
15:03:38submitted (proved 1, submitted 1), "block 1579 shard 0 submitted; paid when a block carries it"
15:03:49proving block 1650 shard 0 (open), paid 1, 637,452,090,000,000,000 wei (0.637 IGN)
+

Block 1579 shard 0: 233,576 cycles, execute 0.025 s, compressed 60.2 s, 1,272,897 bytes; node 0 shows the record carried by chain block 1655 and paid; the payout address's balance on node 0 was 163.15 IGN at the end (4 shard payouts of about 0.635 IGN each plus the mining rewards of run 1). The app's node, restarted twice, replayed the chain from genesis each time and re-applied the same three payouts (its log at 15:49:53 lists chain blocks 433, 618 and 756 paying blocks 268, 447 and 569), which is the determinism the rule needs.

+

Reading. The packaged loop works on a Mac with the CPU prover: 71 s from the tile saying proving to paid on the chain for the smallest shard. The two defects were in the tile's bookkeeping and the child's lifetime, not in the chain rules. The open-shard fallback is what makes a prover without mining weight useful; whether assignees should keep more of the pool is the O-5.1 question, untouched. Nothing here ran on Windows or on a GPU.

+

4 October 2026, difficulty v2 rollout rehearsal on the 12-node the cloud provider network, binaries for the devnet, the devnet plan (rollout engineer)

+

Builds (Mac M5 Max under other agents' load, nice 19, 4 cargo jobs, each into its own target directory seeded from an existing cache; the live binaries untouched), source vendor/igneum-node-v4 at 3bfe346f = a21ff239 (difficulty v2) plus a miner-only commit, so igneumd is the a21ff239 node: Mac arm64 144 s (vendor/igneum-node/target-v2/release/igneumd, sha256 8b0fbd27...), Linux x86-64 glibc 2.36 by cargo-zigbuild 173 s (infra/cross/out-v2/igneumd, 70751def...), Windows x86-64 by mingw 8 min 50 s (target-v2/x86_64-pc-windows-gnu/release/igneumd.exe, 27c2ce85...). Each carries the difficulty_v2_activation_daa parser; the Apple M5 Max binary printed Difficulty rule v2 from the override file: active from DAA score 123456 on a private suffix, the Linux one on all 12 cloud nodes. cargo test -p kaspa-consensus-core --lib params: 7 pass (the fast-time file already carries the field as never). Windows payload inputs pushed (payload-inputs.zip 66b4dc51...); no manifest published.

+

Rehearsal (infra/cloud-devnet/rollout-v2.sh; igneum-devnet-20, its own chain): N = DAA 14,362 + 1,800 = 16,170; staging the 47 MB binary to the four gateways from the Apple M5 Max then gateway to private node (the Apple M5 Max to Hillsboro ran at 32 KB/s; igneum-01 to igneum-04 server to server took 12 s); the 12 nodes rolled one at a time 14:14:39 to 14:18:16 UTC, 15 to 30 s each, every one rejoined within 5 to 15 s with its DAA within 2 of the reference. Watch to N + 600 (31 checks a minute apart): DAA spread 2 to 12 across nodes, difficulty within 1%, moving through N (76.7k at 16,161, 74.5k at 16,344, 86.8k at 16,740). Definitive: getVirtualChainFromBlock from a DAA-14,500 block on all 12 nodes returned the same chain block at DAA 16,062, 16,304, 16,565 and 16,797. No fork. Lesson: systemctl stop igneumd also stops the miner and the block log (Requires=); the script now starts all three (the block logs were off from the roll to 14:56 UTC).

+

Hash-rate step under v2 (hop.sh "half:4:600;all:1:600", 14:57 UTC) against the morning's v1 schedule, first 600 s of each step (results/2026-10-04/v2/compare.md): 2-min rate back within 10% of 60/min after 157 s (v1 161 s) on the step up and 172 s (v1 272 s) on the step down; neither rule holds the 3-min criterion inside 600 s on 12 CPU miners. After 300 s the v1 step-up difficulty swung 128k to 134k to 89k (max/min 1.51, std log D 0.169), the v2 one climbed 102k to 117k (1.15, 0.053); on the step down v2 reached the one-thread level (82k) by 600 s, v1 was at 100k after 600 s and 97k after 900 s. One run each, CPU miners, the v2 series has a bridged gap in its first two rows.

+

Devnet: docs/plans/difficulty-v2-rollout-devnet.md. The gap found: the app launched igneumd without an override file, so an OTA-delivered v2 node would have forked at N; fixed with node_override_params in the packaged config (igneum-app.json, one NODE_OVERRIDE_PARAMS line in packaging/mac/packaged-config.sh read by both packagers; the engine writes <app data>/app/override-params.json and passes the flag). Rule: N = DAA at the manifest publish + 10,800 at least; since N is baked at the cut, choose DAA + 14,400 when committing the line and check at publish.

+

4 October 2026, difficulty rule v2 activated on the live devnet at DAA 33,000 by height switch, no fresh chain

+

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).

diff --git a/site/build.mjs b/site/build.mjs index 18b21a518..4b8ce5499 100644 --- a/site/build.mjs +++ b/site/build.mjs @@ -177,6 +177,7 @@ if (existsSync(join(docs, 'bench-log.md'))) { ['First hourly program swap on the live devnet', 'First live hourly swap: no pause on Mac, NVIDIA or AMD'], ['First finality lock on the live devnet', 'First live finality lock: 77.4% of weight, 17 voters'], ['First machine on the Igneum Miner app', 'First machine on the one-click app: a 5090 at 118 MH/s'], + ['Difficulty rule v2 activated on the live devnet', 'Difficulty rule v2 switched on the live devnet by height, no fresh chain'], ['First outside machine on the devnet', 'First outside machine: a friend\'s Mac mining through the app'], ['Devnet v4 cut-over', 'Devnet v4 live: generator v2, two-thirds floor, fresh chain'], ]; diff --git a/site/journey.json b/site/journey.json index 0a8f01f07..0bebe2c11 100644 --- a/site/journey.json +++ b/site/journey.json @@ -50,6 +50,26 @@ } ], "log": [ + { + "date": "2026-10-04", + "text": "Cloud devnet: 12 igneumd nodes in 5 locations, inter-region latency, two Singapore partitions, hash-rate steps", + "short": "Cloud devnet: 12 igneumd nodes in 5 locations, inter-region latency" + }, + { + "date": "2026-10-04", + "text": "Correction: the 78-minute observer gap was the Apple M5 Max hibernating", + "short": "Correction: the 78-minute observer gap was the Apple M5 Max hibernating" + }, + { + "date": "2026-10-04", + "text": "Difficulty v2 rollout rehearsal on the 12-node the cloud provider network, binaries for the devnet, the devnet plan", + "short": "Difficulty v2 rollout rehearsal on the 12-node the cloud provider…" + }, + { + "date": "2026-10-04", + "text": "Difficulty rule v2 activated on the live devnet at DAA 33,000 by height switch, no fresh chain", + "short": "Difficulty rule v2 switched on the live devnet by height, no fresh chain" + }, { "date": "2026-10-04", "text": "Shard proving on the RTX 5090", @@ -229,26 +249,6 @@ "date": "2026-10-03", "text": "RTX 5090 through NVIDIA OpenCL", "short": "RTX 5090 through NVIDIA OpenCL" - }, - { - "date": "2026-10-03", - "text": "RTX 5090 first run", - "short": "RTX 5090 first run" - }, - { - "date": "2026-10-03", - "text": "RTX 5090, memory-hard dataset", - "short": "RTX 5090 on the memory-hard dataset" - }, - { - "date": "2026-10-03", - "text": "RTX 5090 ran two generated programs and matched the Apple M5 Max hash for hash, 192 of 192. Vendor independence measured on two vendors.", - "short": "RTX 5090 matches Apple silicon hash for hash, 192 of 192" - }, - { - "date": "2026-10-03", - "text": "Fuzzing: 10,200 random programs, 1.3 million hashes, zero GPU to CPU mismatches on Apple silicon.", - "short": "Fuzzing: 1.3 million hashes, zero GPU to CPU mismatches" } ] }