Module snapshot 

Immutable, shareable EVM state snapshots.

Two-tier copy-on-write model (Pillar A)

A snapshot is split into two tiers:

• a memoized immutable base (BaseState) flattening the cold layer-2 BlockchainDb index, shared across successive snapshots by Arc — both the base as a whole and each account’s storage map (Arc<HashMap<U256, U256>>) — so taking a snapshot when the cold index is unchanged is an Arc handle copy, never a per-slot deep copy;
• a small per-snapshot overlay folding the hot layer-1 CacheDB delta (committed sim changes, write-throughs, freshness corrections), which always shadows the base on a read.

super::EvmCache::snapshot memoizes the base (via the internal refresh_base) and folds only layer 1 fresh, so its cost tracks changed state, not total state. The retained super::EvmCache::snapshot_deep_clone produces the same two-tier shape with everything flattened into the base and empty overlay maps; it is the A/B benchmark baseline and the read-equivalence reference.

Reads stay O(1) HashMap lookups with no locks (Decision D1: Arc sharing, not a persistent/HAMT map), so the snapshot is Send + Sync and an EvmOverlay built from it is Send.

Per-simulation dirty layer

Each simulation does not mutate the shared snapshot. Instead it wraps the Arc<EvmSnapshot> in an EvmOverlay, which adds a per-simulation dirty layer on top: writes (committed account/storage changes, RPC fallbacks, freshness overrides) land in the overlay’s own maps and take precedence over the snapshot on subsequent reads. Two overlays built from the same Arc<EvmSnapshot> are fully isolated from one another, so simulations can run in parallel without contending for or corrupting the shared base state.

Structs

EvmSnapshot

Immutable EVM state snapshot — Send + Sync, shared via Arc across threads.