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

release 0.3.14: the plan skeleton (node-only; the exec layer survives a deep reorg and a moved pruning point)

Browse source 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
igneum-labs 2026-10-06 15:54:14 +00:00
parent f66dde68bd
commit 93c3b1fc59
1 changed files with 41 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

41
docs/plans/release-0.3.14.md Normal file
View file

@ -0,0 +1,41 @@
# 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) |
| The six version files | (the bump commit) | |
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 |
| 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 |
## 3. Builds and artefacts (to fill when the fork tip is set)
## 4. The rollout (to fill at the go)
## 5. Owed