igneum/docs/plans/exec-sync.md

4.2 KiB

Exec sync: the executor's state after the pruning point left genesis (6 October 2026)

What happened

The devnet's pruning point left genesis on 6 October 2026 at about 11:40Z (chain block 27,276, DAA 45,537). Every node pruned the block bodies and acceptance rows below it and kept the headers and ghostdag rows. The execution layer's state lived only in memory and was rebuilt from genesis at every start; every node had restarted for 0.3.11 and 0.3.12. From 11:40Z every node read eth_blockNumber 0x0 and igneum_getProvingStatus active false: no balances, no proving work list, no payouts, mining untouched. No hand ran --archival, so no data dir on the network holds the bodies the state was built from, and the state cannot be rebuilt from genesis anywhere.

The fix, fork branch exec-sync-0313 (off the 0.3.12 node 83089544), node only

Commit What
4f05e56a the exec state persisted to the data dir every 5 minutes and at stop (two generations; resumed at start when its tip is still a chain block); --igneum-exec-snapshot=<path>[,<sha256>] and igneum_exportExecSnapshot; the loud status when the follower cannot execute (warn every minute, igneum_getExecStatus.blocked, the proving status's execSync)
3bd31a20 the snapshot served and fetched over p2p at protocol 16 (messages 76 and 77, 1 MiB chunks, the sha256 on every chunk); a blocked executor asks one peer every 20 s; --igneum-exec-snapshot=peer
efa6924d, 7cb712f5, 80674943 the archival walk: the selected-parent chain read from the ghostdag store when the virtual-chain query refuses a tip below the retention root; the mergeset order rebuilt from ghostdag rows when the acceptance row is pruned
3dd9b2c9 the exec restart: exec_restart_number and exec_restart_hash in the override object (in the digest once set): header-only records below R, the EVM state fresh at R, executed from R's body on; the status reports the pruning point and the retention root with their chain block numbers
05e93f0e exec_restart_trust_daa: a shard record carried below it pays as carried, without the native-statement veto and the assignee check

Measured on a copy of node 1's data dir (the Mac, tools/lock/with-lock.sh run)

Figure Value
The pruning point and retention root, node 1 and the observer chain block 27,276, hash bb45cf0dd2d7cc97ebfa5a2701527c09a8ede5d32de74efead9caa293b15688a, DAA 45,537; its body held on both
Bodies below it gone ("cannot find full block" at chain block 1)
Replay from 27,276 to the sink (130,073, then 130,272) 92 s and 93 s wall from the node's start, over 2,000 chain blocks a second
Without the trust rule paidShards 0: every historical record vetoed (the records attest the original state roots)
With exec_restart_trust_daa 200,000 paidShards 1,482, paidWei 1,825.70 IGN (node 1 read 1,261 and 1,573 at 08:30Z; the chain moved on)
PC 2's payout address at the tip 267,648 IGN
The persisted file 114,830,936 bytes, 130,273 records (1,200 full), 31 accounts
Resume after a restart 9 s, no replay

What it means

Tier Before the fix After the cut with the three fields
Every node, home miner, rig, pool an empty EVM since 11:40Z: no balances, no proving, no payouts; mining fine the chain's state from chain block 27,276 on, rebuilt in about 90 s at the switch; every restart after that resumes in seconds
Miners rewards invisible rewards since R back (PC 2: 267,648 IGN); the rewards of chain blocks 0 to 27,275 (the devnet's first 12 hours) lost, the project lead's call on seeding them
Provers payouts invisible every carried record since proving v0 paid as carried (1,482 shards); new proofs verify against the new state from the trust DAA on
Joiners today an empty EVM for ever IBD gives the pruning point 27,276 and the bodies from it, so a fresh node replays the same 90 s with no snapshot; once the pruning point moves past R the p2p snapshot (protocol 16) starts it

Open

The fresh-join time on a rented box (in progress); the trust DAA's value (at or above the switch); the first 12 hours' rewards (the project lead); the p2p snapshot's fast-time harness case; --archival on at least one hand from now on.