/state-sync-pruning

name: "state-sync-pruning"
description: "L1 trigger - audits state sync, snapshot integrity, checkpoint trust, pruning race conditions, and state growth attacks."

Injectable Skill: State Sync and Pruning

> **L1 trigger**: `L1_PATTERN=true` AND (`sync/` OR `snap_sync` OR `fast_sync` OR `statesync` OR `pruning` OR `snapshot/` detected in recon subsystem map) > **Inject Into**: `depth-state-trace` or `depth-edge-case` > **Language**: Go and Rust > **Finding prefix**: `[SS-N]` > **Status**: v0.1 draft, Round 4 exemplars pending

Orchestrator Decomposition Guide

• Sections 1, 2: depth-state-trace (sync protocol state)
• Sections 3, 4: depth-edge-case (pruning races, growth)
• Section 5: depth-external (checkpoint trust)

When This Skill Activates

Recon identifies state sync or pruning code. State sync is the mechanism by which a new node catches up without replaying the entire history; pruning is how an existing node garbage-collects old state. Both are subtle: a bug in either can corrupt the node's state silently, leading to later divergence.

1. Sync Mode Fingerprinting

Identify the sync mode(s) supported:

| Mode | Description | Trust model | |---|---|---| | **Full sync** | Replay every block from genesis | Trustless (modulo consensus rules) | | **Fast sync** | Download headers + recent state trie | Trusts weak subjectivity checkpoint | | **Snap sync** (Ethereum) | Download flat account snapshots in ranges | Healing phase verifies root | | **Warp sync** (Parity) | Download a snapshot of state at a past block | Trusts snapshot root | | **State sync** (Cosmos) | Download state at a trusted height from peers | Trusts a configured height/hash | | **Checkpoint sync** (Beacon) | Trusts a recent finalized checkpoint root | Weak subjectivity | | **Portal Network** | Content-addressed historical storage | Trustless per item |

Write the mode(s) into the finding header.

2. Root / Checkpoint Trust

Every non-full sync mode depends on a root or checkpoint. Verify the trust chain:

1. **Where does the checkpoint come from?** Hardcoded? CLI flag? RPC? Config file? 2. **What signs it?** Nothing (pure trust)? A hardcoded key? The current validator set? 3. **Validity period**: is the checkpoint rejected if older than X? Stale checkpoints permit long-range attacks. 4. **Rollback**: if a checkpoint turns out to be invalid mid-sync, does the node recover cleanly?

Tag: `[SYNC-TRUST:{source}:{validation}]`

**Historical exemplar class**: unsigned-checkpoint sync in early Cosmos clients; trust-anchor bypass in early beacon chain clients.

3. Snapshot Integrity

For any sync mode that downloads bulk state (snap, warp, state sync):

3a. Chunk verification

• State is downloaded in chunks. Is each chunk verified against the root as it arrives?
• Or is all data downloaded first, then verified at the end (bad — wasted bandwidth on poisoned chunks)?
• What happens if a peer serves a chunk that hashes correctly but whose content violates invariants (e.g., negative balance)?

3b. Duplicate account / missing account

• Can the same account appear in two chunks? How is the conflict resolved?
• Can an account be missing from all chunks? Is there a completeness check?

3c. Healing phase

• After bulk download, the "healing" phase typically walks the trie and fetches missing nodes. Verify:
• Is the healing phase bounded in time/attempts?
• Can a malicious peer serve nodes that hash correctly but belong to a different subtrie?

3d. Parallel peer downloads

• If multiple peers serve chunks in parallel, how are conflicts resolved?
• Can a slow peer hold up the whole sync?

Tag: `[SNAPSHOT:{integrity-class}]`

4. Pruning Safety

Pruning removes old state to save disk. Bugs here corrupt the active state.

4a. Reference counting

• Most pruning uses reference counts on trie nodes. Is the ref count atomic with state writes?
• On reorg, are ref counts correctly adjusted? **Frequent bug source.**

4b. In-flight reads

• Can a pruning operation race with an active read? (e.g., RPC `eth_getProof` reading historical state while pruner deletes it)
• Is there a read lock, a MVCC snapshot, or a pruning-delay grace period?

4c. Pruning boundaries

• Which blocks are pruned? How deep is the retained window?
• Is the window configurable? What's the minimum safe window vs fork-choice requirements?
• Beacon chain: pruning cannot go past the latest finalized checkpoint. Is this enforced?

4d. Archive vs pruned mode

• If the node supports archive mode, is the code path strictly disabled when pruning is enabled? Mixed-mode bugs exist.

4e. Persistence atomicity across logical units

A persistence unit is any tuple of writes that must commit or abort together for higher-level state to stay consistent (block body + receipts + state root; header + total-difficulty + canonical-hash mapping; snapshot chunk + chunk manifest). A node crash BETWEEN the writes of a logical unit leaves partially-applied state that the restart path may silently accept.

Methodology — enumerate as a table, one row per logical unit:

| Logical Unit | Writes In Order | Fence (txn commit / fsync / batch) | Restart Recovery | Torn-Write Risk |

For each row: 1. Read the write sequence from the code. Do all writes happen under the SAME DB transaction / batch that commits atomically, or are they split across multiple commits? 2. If split, what happens if the process dies between commits? Does the next start detect and roll back, complete the remaining writes, or silently accept the partial state? 3. OS-level torn writes: for any write that bypasses the DB's own atomicity (direct `write` + `fsync` to a file), verify that either the write is ≤ 4 KiB (page-atomic on most filesystems) or the file uses a write-then-rename pattern with `fsync` on the parent directory. 4. Windows-specific: `rename` is NOT atomic over an existing file on pre-Windows-10 / some network filesystems; `MoveFileEx` with