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

Snapshot sync: the morning's mechanism as it ran (the shipper's record: mini-snapshot.sh, the app's own quit, the whole devnet-4 tree tarred, 5.06 GB, sha256 5790ee71, 89 s to tar and 639 s to push, the node at lp-04's epoch-13 cut, the 2.0.2 root at 284fb765) and the served form it becomes (the exec state alone, 56 MB, as the first file; the consensus store optional; the certificate-anchored root the thing verified, the sha the transport check; one file per lock per seed)

Browse source 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
igneum-labs 2026-10-09 10:22:56 +00:00
parent 602f98b641
commit 4289f056f2
1 changed files with 6 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
docs/design/snapshot-sync.md
View file

@ -26,6 +26,12 @@ Start: the follower installs the snapshot as today (`load_snapshot`: the records
Two paths, both existing in shape: (a) P2P, as today's `IgneumRequestExecSnapshot` chunks from any connected peer that holds a snapshot — extended to carry the manifest first so the joiner runs section 3's steps (1)–(3) before it takes the chunks; (b) HTTPS from the seeds' download host (the shipper's `dl.igneum.network`), the file and `snapshot.json` beside it, the same manifest — the path a fresh install takes before it has peers, pointed at by the release manifest's `snapshot_url`. The seed cuts a new snapshot at every lock it holds past a fixed stride (every 3,600 blocks, the epoch) and keeps the last two; a joiner takes the newest whose lock it has verified.
## 5.1 The mechanism as it ran this morning (the shipper's record, 11:1x UK)
The reset's snapshot was cut by `~/mini-snapshot.sh` on the founder's mini (the copy in the shipper's scratch `r202/mini-snapshot.sh`; the consumer `/Users/joshm/igneum-fleet/morning-reset.sh`): the app asked to quit through its own API (`POST api/quit`: the miners stopped, then the node with its 10 s grace, so the node's own shutdown ran and its log holds "exec state persisted at stop"), the window host ended by its recorded pid, a refusal if any igneumd was still up; then `tar czf` of the WHOLE devnet-4 directory (`~/Library/Application Support/Igneum/devnet-4`, the one tree `igneum-devnet-4/` with consensus, the evm store, meta, the exec snapshot and the proof records; nothing split), a sha256 sidecar in shasum's format, the app relaunched on the same datadir, and the tarball pushed to build-1:/srv/artefacts/mini-dn4-snapshot/ with `sha256sum -c` there. The facts: `mini-dn4-snapshot-20261009-074452Z.tgz`, 5,057,533,265 bytes (7.5 GB on disk), sha256 5790ee71380cd60561a9af4ef4e405799638a75213a7600af9f0486855d2779c, tarred in 89 s on the M6, pushed in 639 s; the node stopped 08:44:57 to 08:46:21 UK at lp-04's chain's epoch-13 cut: tip 8c46c8a8…, DAA 46,800, EVM height 24,852, executed tip DAA 46,799; the epoch-13 seed block 284fb765's state root on that executor 0x3fde4beb339ab818b0b9fd3da0994d179500bea0144b649a0e90861b690ea3a8 (the 2.0.2 line's root, equal on build-1's kit-4 node). The hubs were started on it by the fleet lane's recipe (the node stopped by its pid file, the appdir moved aside, the tarball unpacked where `--appdir` points, the three hubs as SEED).
What the served form changes, as the shipper proposes and this design takes: a joiner must not fetch 5 GB to start. The first file is the executor's state alone — `exec-snapshot.bin` (56 MB at DAA 53,670 on a synced 2.0.3 node; the 5 GB tarball is block bodies and proof records, which a joiner syncs or drops by section 4) with its manifest (section 1); the consensus store (263 MB) is an optional second file for a joiner that wants headers and bodies without IBD; the thing verified is the certificate-anchored root (section 3), the tarball's sha256 the transport check only. One file per lock from each seed, named by the lock's DAA and the root, the newest served.
## 6. The 16 GB fit, stated
A joiner from the snapshot holds: the headers (about 300 bytes a block in memory during IBD, 16 MB at 54,000 blocks), the bodies above the snapshot (streamed, executed, thinned), the EVM state (tens of MB), the window's records (≤ 4.7 GB at today's rate), the consensus store's caches and the allocator's slack — a fresh install on a 16 GB machine syncs from the snapshot to the moving tip without the 0.65 GB-per-1,000-blocks growth, and a 2.0.2 node on 16 GB today walls at about DAA 8,000. Until 2.0.3.1 ships, /download and /miner state 64 GB for a fresh sync (the site lane, by 11:30 UK), or the recipe's snapshot by hand.