From aa82d179901f9ba0c8cbbabe1629fbc472678919 Mon Sep 17 00:00:00 2001 From: igneum-labs <337424239+igneum-labs@users.noreply.github.com> Date: Mon, 5 Oct 2026 13:17:12 +0000 Subject: [PATCH] site: rebuilt (journey picks up the program id entry) --- site/bench.html | 16 ++++++++++++---- site/index.html | 2 +- site/journey.json | 34 +++++++++++++++++----------------- 3 files changed, 30 insertions(+), 22 deletions(-) diff --git a/site/bench.html b/site/bench.html index ba8983136..ced6b28e2 100644 --- a/site/bench.html +++ b/site/bench.html @@ -171,12 +171,12 @@ th{font-family:var(--f-mono);font-size:12px;letter-spacing:.12em;text-transform:
-
64 entries, newest at the bottom
+
65 entries, newest at the bottom

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

@@ -486,8 +486,16 @@ th{font-family:var(--f-mono);font-size:12px;letter-spacing:.12em;text-transform:

Uncertain. (1) Every run is fast time (W = 120 DAA, ban 120, depth 20) on three nodes with 100-ms links; the mainnet values are 30 days, 30 days and 60 blocks. (2) The ban run shows one equivocation at one index; the red team's s1 (equivocation at every index, two keys) was re-run on the new build only through the red team's f23 above (0 refusals where the evening had 9 / 3 / 4). (3) The digest-less allowance on devnet and simnet is deliberate for the rollout and is a hole until removed. (4) The reorg run's final pass had the majority lock no index during the first 60 s of the split, so the re-determination at 8 and 9 was exercised, the pending-certificate path only at 10 and 11; the first pass exercised the opposite. (5) The un-determination rule has a unit test and one network pass (reorg-final2) in which the shallow-sink case did not recur, so the rule is exercised by the test, not by a run; the case needs a split whose difficulty drifts enough for blue work to overtake blue score, which happened once in four runs. (6) The red team's f24b is a window-length partition at 6 blocks/s, so it measures F21's stated limit, not F24; a 4/2 cut under 20 s at that rate would be the F24 case.

5 October 2026, live devnet: the first shards proven, verified and paid

Proving v0 activated at DAA 84,100 (manifest consensus.override, every node restarted with the same file; a hand node restarted early with another value was refused by the digest handshake and sat isolated for 20 minutes until it was restarted with the same file). The first proof records came from PC 2's RTX 5090 (SP1 CUDA under WSL2, app 0.3.7, node 2b6d23ef) and were verified by the Apple M5 Max node's verifier (igneum-prove-host --mode verify, the only block producer with a verifier until 0.3.7 put one on every machine) and paid at the carrying chain block.

-
WhatMeasured
First shard record in the pool (observer)10:51 UTC, block 94,904 on the live page, prover key e809e396, shard 0, 0 pgas (an empty shard)
Paid shards by 10:53 UTC (Mac node igneum_getProvingStatus)3 shards, 3.370437410 IGN in total, pool balance 68,601.72 IGN
Pool at that moment4 entries: 3 pending, 1 failed verification, 0 verified-and-waiting
Non-empty shardsnot yet: the exporter's post-root assertion fires on blocks with content (58,584 to 58,984 on 5 October); investigation open
-

Commands: curl -X POST http://127.0.0.1:26800 -d '{"jsonrpc":"2.0","id":1,"method":"igneum_getProvingStatus","params":[]}' on the Apple M5 Max; node tools/logs.mjs for PC 2's prover lines (prover: block N shard 0 assigned to win-1ccfe586-1-1: export, cut, prove (CUDA), sign, submit).

+
WhatMeasured
First shard record in the pool (observer)10:51 UTC, block 94,904 on the live page, prover key e809e396, shard 0, 0 pgas (an empty shard)
Paid shards by 10:53 UTC (Mac node igneum_getProvingStatus)3 shards, 3.370437410 IGN in total, pool balance 68,601.72 IGN
Pool at that moment4 entries: 3 pending, 1 failed verification, 0 verified-and-waiting
Non-empty shardsnot yet: the exporter's post-root assertion fires on blocks with content (58,584 to 58,984 on 5 October); investigation open
The assertion, explained (12:30 UTC, branch prover-match)Not block content. Every block it fired on is empty (PC 2's export logs: 58,752 to 58,843 hit the assertion; 58,584 to 58,740 hit the backslash path of 6d51e53), one reward plus the pool credit, no transactions, no payouts. PC 2's exporter was a stale build: the panic names shard.rs:175, the line before commit 1251f0a moved the assert to 179, and that core's planner gave an empty segment the pre-root as its post-root while the statement applied the rewards (left = the node's root after the rewards, right = the root before them, as the log shows for 58,752). The core at master reproduces 58,927 and 59,192 with the node's roots, and the same shape (59,507: one reward to the same miner) was proven and paid after the 10:49 and 10:52 UTC rebuilds on PC 2. Branch prover-match: fixture block-58927-empty-reward.json, export/tests/fixtures.rs (every fixture reproduces; an empty segment ends at the root after the rewards), and a source stamp on the first line of the exporter and the host so a stale binary names itself. The guest is untouched: built in one directory, master and the branch give byte-identical loadable segments for the shard program and the aggregator (shard program id 0x1ec8b941 at master in that directory). Noted on the way: the same sources built in three directories on this Mac gave two different guest ELFs (text segment c173b3de in the main checkout and in a fresh worktree, 830f7433 in the branch's worktree, shard program id 0x366e2aca there), so the program id is not yet a pure function of the sources on a native build; SP1's docker build is the reproducible path and is not in use. Open item.
+

Commands: curl -X POST http://127.0.0.1:26800 -d '{"jsonrpc":"2.0","id":1,"method":"igneum_getProvingStatus","params":[]}' on the Apple M5 Max; node tools/logs.mjs for PC 2's prover lines (prover: block N shard 0 assigned to win-1ccfe586-1-1: export, cut, prove (CUDA), sign, submit).

+

5 October 2026, the program id split: why the Apple M5 Max rejected PC 2's proofs, and the verifier at 114 s

+

Machine: Apple M5 Max under the live devnet node, the Metal miner and two other agents' builds (every number here is wall time under that load, taken through the measure lock). Code: proving/igneum-prove on branch program-id, SP1 6.8.1, circuit v6.1.0.

+
HostBuiltShard program idSource
Mac, shipped (Igneum Miner.app/Contents/Resources/bin/igneum-prove-host, app 0.3.7)5 Oct 10:48, release tree on the Apple M5 Max0x0559759b3d8740b26ceceb2c56054b89194878ab691b018d7dd2f8af2f2242ddits own --mode verify setup line
PC 2, WSL2 CUDA (<server path>)4 Oct 19:00Z, package sources0x05db1aca65f8ae9d585c7bd178a832d92a67275857f21c0d484a58c06dba61a3app log run-20261004-r3-shards (node tools/logs.mjs job-collect-pc2-applog-paid-1ccfe586); confirmed by the sp1_vk_digest inside its proof of block 59507 shard 0 (below)
Mac, fresh worktree igneum-wt-programid5 Oct 12:07Z, same sources as the shipped host0x0dfade071ffc05a50be5f7e6640fb12638bac0ea63697ec252863f55658be16aigneum-prove-pin
+

Three builds of the same guest sources, three ids. Cause: host/build.rs compiled the guest with sp1_build::build_program on whatever machine built the host, and the guest ELF depends on where it is built. Shown by strings on the two Mac ELFs: 946 anonymous symbol names differ, and the crate hash of igneum_prove_core is Csl6o96CsXEfN_ in the main checkout against Cs5Jl7brLd39a_ in the worktree (cargo's -C metadata for a path crate includes the checkout path, and rustc's symbol names carry it); the ELFs also embed ~/.cargo/registry/... panic-location strings, which differ again on Linux. A different ELF is a different verifying key, so every verifier rejects every other machine's proof ("sp1 vk hash mismatch" inside SP1's verify_compressed), and the node log showed it as a bare NOT VERIFIED after 114 s to 138 s. Over the same window the Apple M5 Max's pool read 16 entries, 9 failed, 0 verified, 22 shards paid (included by PC 2's own node).

+

Fix: the guests are pinned build artefacts (proving/igneum-prove/elf/: both ELFs, both verifying keys, manifest.json with SHA-256 hashes and ids), embedded by the host and checked at every start; --mode verify runs on SP1's light verifier with the pinned key, no prover client and no key setup; the verify line prints the id the proof was made with next to ours. Pinned set: shard 0x0dfade07...be16a, aggregator 0x135e67e7...6c62.

+
Verify of PC 2's proof of block 59507 shard 0 (1,272,897 bytes) on the Apple M5 MaxSetupVerifyVerdict
Before: shipped host, ProverClient::from_env + two key setups125.82 s0.383 sNOT VERIFIED, no reason given
Before, as the node saw it (blocks 59373 and 59402)138.6 s and 114.4 s in all0.409 s and 0.104 sNOT VERIFIED
After: pinned key, light verifier (program-id host, same proof)2.085 s0.002 s (refused on the program id before any field arithmetic)NOT VERIFIED, program id 0x05db1aca...61a3 IS NOT OURS 0x0dfade07...be16a; 2.35 s wall, exit 3
After, known-good case: block 56 shard 0 proven with the pinned ELF on this Mac (--mode compressed, 558,137 cycles, prove 1,066 s under load 113), verified against its real statement1.323 s0.108 sVERIFIED, program id ... (ours); 1.80 s wall, exit 0
+

Before: 127.0 s wall per proof on the Apple M5 Max (the node saw 114 s to 139 s). After: 1.8 s to 2.4 s wall, under the 2 s target for the verify call itself; the remaining 1.3 s to 2.1 s is SP1's light verifier construction plus paging a 58 MB binary under load, and would shrink in a long-lived verifier process. Unit tests (cargo test -p igneum-prove-host --bin igneum-prove-host): the embedded files hash to the manifest, the embedded keys derive the manifest's ids, a changed file is refused; the ignored test re-runs SP1's setup on the embedded ELFs and gets the pinned ids. tools/ci/pinned-guests-check.sh was shown failing on an empty elf/ and passing on the pinned one.

+

What every machine must do: the pinned shard id 0x0dfade07...be16a differs from every id now running (Mac 0x0559759b..., PC 2 0x05db1aca...), so this is a guest change for the whole devnet, and proofs in flight at the switch are rejected by a verifier that has moved. Rollout order (proving/README.md, "Pinned guest programs"): provers off on every machine; wait until igneum_getProvingStatus shows an empty pool on every node; install the host built from this elf/ on every node (Mac DMG; PCs through igneum-prove-wsl2.zip, whose package carries elf/, so the WSL build embeds the same files); confirm igneum-prove-host --mode id prints the same shard id everywhere; provers back on. From then on a differing id is impossible without a change to the committed elf/.

Generated from the repository at build time. Times are UTC. Machine names are model names.

diff --git a/site/index.html b/site/index.html index 2d60d9222..d7ff28d9e 100644 --- a/site/index.html +++ b/site/index.html @@ -654,7 +654,7 @@ pre{margin:0;font-family:var(--f-mono);font-size:13px;line-height:1.6;color:var( - +