6.6 KiB
Igneum Miner 0.3.14: node-only, the execution layer survives a deep reorg and a moved pruning point; prepared to the gate, 6 October 2026
Release engineer, from 15:55 UTC, on the coordinator's decision of 15:53Z (the "0.3.13.1" name is refused by the ship tooling, so 0.3.14).
Worktree /Users/joshm/Projects/igneum-wt-ship0314, branch release-0.3.14 from master 2cf8851 (the 0.3.13 merge); the fork worktree
vendor/igneum-node-0314, branch release-0.3.14-node, at bb43e9a8 (the 0.3.13 node) until the proving agent's fix lands on it. The
0.3.13 recipe; igneum-labs commits; times UTC.
1. Why, and what it carries
After 0.3.13's publish 2 (6 October, release-0.3.13.md section 4a): the fresh rule armed at DAA 198,000 inside the rollout window, the
chain ran two-sided for a minute, the hands took a 274-chain-block reorg, and the exec layer on every executing node replayed from genesis
("reorg deeper than the snapshot ring"), overwrote its good snapshot with a tip-0 one, and could not take the restart path again because the
devnet's pruning point had moved from bb45cf0d (DAA 45,537) to eb2a5d70 (DAA 88,763), stranding the anchor 27,276. Every node reads
eth_blockNumber 0 and paidShards 0 since 15:44:47Z; the chain, the finality locks and the hash are untouched.
| Change | Where | State |
|---|---|---|
| A deep reorg never replays from genesis on a pruned node: the follower unwinds through its persisted generations, else requests a peer's snapshot (protocol 16); a good snapshot is never overwritten by a tip-0 one | the proving agent's fix branch off bb43e9a8 | (pending) |
| A moved pruning point does not strand the anchor: a node keeps executing from its persisted state; the anchor is for a node with nothing | the same | (pending) |
A flag file (--igneum-exec-snapshot) that cannot be read or whose sha does not match fails loudly at start (on the seed, as user igneum, a file under /root was ignored silently and the node replayed genesis, 16:16Z) |
the proving agent's branch | (pending) |
| The p2p snapshot path refuses a snapshot at or below the node's own tip, below the restart, or at tip 0 (the seed pulled and loaded a 2,629-byte tip-0 snapshot from a fleet box at 16:16:30Z) | the same | (pending) |
The hands' and the seed's restart scripts: IGNEUMD_EXEC_SNAPSHOT / IGNEUMD_EXEC_SNAPSHOT_FILE (the flag; on the seed the file installed for the igneum user under /var/lib/igneum-v4, the quoted EXTRA_ARGS) and IGNEUM_EXEC_RESET (the persisted exec files deleted after the stop); node 1 on its own eth port 26791 |
32e004f, 0585b9e, db1205b, dd9044e, 08ddee7 (this branch; release-0.3.13 carries the 26791 line only) |
in |
| The six version files | 4b25760 |
in |
No re-pin of the anchor (the coordinator's decision). If the fix is code-only the object is CARRIED OVER (the thirteen-field one, digest b18ed271... unchanged) and this is ONE publish; if a field changes, the 0.3.12 two-publish shape.
2. The order at the go
Runbook: the session scratchpad's r0314/rollout-0314.sh (the 0.3.13 one with the names moved; step_1a_* is the whole hand swap when the
object is carried over).
| Step | What | Gate |
|---|---|---|
| 0 | the baseline: step_check_observer reads 0 / genesis-or-snapshot-at-0 / 0 shards today |
|
| 1 | the observer, node 1 (on its own eth port 26791 now) and the seed on the 0.3.14 binary with the SAME thirteen-field file | each prints b18ed271...; within minutes eth_blockNumber climbs to the sink, igneum_getExecStatus startedFrom "snapshot" (the persisted generation) or "restart at chain block 27276" (if the walk can meet it) or a peer's snapshot, blocked null; igneum_getProvingStatus active, paidShards >= 1,482 |
| 1b DEVNET 2 (the project lead, 17:0xZ: every release crosses the rented fleet as its own staging chain first) | after the payload (the inputs, the Windows run, the DMG) and the Rust suite on PC 2: the payload URL and the manifest contents to the fleet agent; the cut waits on its devnet2-gate PASS line | zero rejected blocks across the activation, exec roots agreeing on every box, a segment record paid, every node on the new version |
| 2 | the ship (--from ci, consensus carried over), then update-now Mac, PC 2, PC 1 (no activation height anywhere near the window) |
each node's exec back the same way |
| 3 | the fleet agent's boxes on the new Linux node (handed before the publish), the sweep, the proving agent's fresh join on the rented 4090 | the per-node times |
2a. The fallback (the coordinator's rule, 17:0xZ)
If the proving agent's exec fix has an ETA past 19:00Z, 0.3.14 ships without it. Without it there is NO node change: the 0.3.14 node is
bb43e9a8, the 0.3.13 node; the tree then carries miner-ui-3 ae88457 (the UI rewritten, 35 UI tests), master cc89e3f and the two hand-node
restart scripts (the snapshot flag, the reset step, node 1's own eth port, the stop() fix: hand tooling, not a payload). That cut is
app-side, the object carried over, no node restart anywhere, and does nothing for the exec layer or proving (the PCs stay at exec 0 until
a node cut; the hands execute on the snapshot path). The proving agent's branch at 17:00Z: 591581b8 (the export carries execRestart), no
deep-reorg rule, no snapshot floor, no loud flag file yet; its ETA asked at 16:49Z.
3. Builds and artefacts (to fill when the fork tip is set)
4. The rollout (to fill at the go)
4a. The recovery on the shipped binary (16:11 to 16:18Z), before this cut
The proving agent's export of node 1's copy (13:45Z: tip chain block 130,272, 4,612 blocks below the fork point, 114,830,936 bytes, sha256
ac101f13576179fd7d7f5e8ee902c9a7b6cc47730e3a3c069f389f0ca46d9221) loaded through --igneum-exec-snapshot=<file>,0x<sha> after the persisted
tip-0 files were deleted: the observer 16:11:18Z (startedFrom snapshot, eth_blockNumber 136,415 at 16:12:03Z and climbing, blocked null,
paidShards 1,482, paidWei 1825.699240038 IGN), node 1 16:11:32Z (136,459, on 26791), the seed 16:18:01Z (136,636). Three traps on the way:
the hands script's pgrep -f matched the caller's own shell when the pattern's text sat in the command (11 minutes lost; a rule: a
restart script's pattern never appears in the caller's command line, and pgrep excludes the caller); the seed's env file is sourced, so an
unquoted EXTRA_ARGS with a space ran the flag as a command and the unit crash-looped eight times (the seed off the air 16:14 to 16:16Z);
the unit's user could not read a file under /root and the flag did nothing, silently. The PCs and the fleet's boxes stay at 0 until this
cut or the same manual recovery (the fleet agent has the recipe; the PCs' app node takes no flag).