[Enhancement] Execution-side (Reth) pruning mode for nodes — validate on testnet, then mainnet

[Richard1048576]

Motivation

Node storage grows unbounded with uptime. We want nodes to run in pruning mode — retaining only a recent window of blocks (e.g. the last 10,000) — so operators can run on far smaller disks. This must be validated on testnet first, then promoted to mainnet.

Scope of this issue is execution-side (Reth) pruning only; the consensus layer is not pruned here (but see acceptance item A below for a related check).

Requirements

1. Reth pruning flag — availability & RPC correctness

Reth ships built-in pruning flags. Verify they actually work on our execution layer and that RPC semantics stay correct.

• Pruning flag takes effect; node starts and keeps syncing / producing under it.
• latest always resolves to the chain head; newly produced blocks are immediately queryable.
• In-window historical queries succeed; out-of-window queries follow upstream Reth semantics (clean error, no crash, no stale/garbage data).

2. Custom-DB compatibility

If any component replaces Reth's StaticFiles or Reth's native DB with a custom store, confirm pruning still holds.

• (a) Enumerate every storage component and label each "needs pruning / does not".
• (b) For each component that needs pruning, document the concrete pruning mechanism and confirm by measurement that it actually prunes.

3. Storage footprint & semantic parity

• With a configured retention window (e.g. keep last 10,000 blocks), on-disk usage converges (stops growing monotonically) instead of climbing with uptime.
• Pruning boundary behavior matches upstream Reth item-by-item (what is kept, what is dropped, how the edge is handled).

Additional acceptance criteria

• A. Consensus-DB accumulation. Determine whether the consensus DB has any unbounded-growth tables (so that pruning the execution side doesn't just move the bloat to consensus). Pass = no unbounded accumulation, or any accumulation point is identified with a remediation plan. (priority: high)
• B. Empty / partial consensus DB. A node with an empty or partially-removed consensus DB (e.g. after deleting node data) can still come up and run, or the limitation is clearly documented. (priority: low)
• C. Pruned snapshot across roles. A pruned-snapshot bring-up works for Validator, VFN, and PFN — each role starts and syncs to chain head from a pruned snapshot. (priority: high)

Done criteria

All three role types run in pruning mode on testnet, storage converges to the target window, latest/RPC semantics match upstream Reth, and the consensus DB shows no new accumulation risk — then promote to mainnet.

Each checkbox should land with reproducible evidence (commands / logs / a storage-over-time curve) and must not regress consensus participation, block production, or peer connectivity.

Suggested sequencing

1. Requirements 1 + 2 (does the flag work; how do custom DBs prune) — these size the rest of the work.
2. Requirements 3 and acceptance C (window/semantics across the three roles).
3. Acceptance A alongside; B can follow later.

[github-actions]

This issue is stale because it has been open 45 days with no activity. Remove the stale label or comment - otherwise this will be closed in 15 days.