Snapshots

Snapshots let a simulation capture state, run arbitrary operations, and restore the exact prior state:

State A ──(deposit, transfer, merge)──▶ State B
  ▲                                       │
  └──────────────── restore ──────────────┘

Semantics

• create_snapshot(name) captures the whole store — accounts, commitments, statuses, nullifiers, logs, sequence counters, version, and the snapshot registry as it stands — under a caller-chosen name. Duplicates are duplicate_snapshot.
• restore_snapshot(name) replaces the store with the captured state and re-registers the snapshot, so the same snapshot can be restored repeatedly. Restoring is exact: no diff, no reconciliation.
• delete_snapshot(name) removes a snapshot (unknown_snapshot if absent).

Why exactness matters

Restoring a baseline and re-running the same sequence reproduces the exact same results — including transaction IDs and commitments — because sequence counters are restored with the store. The random stream is part of the picture too: Environment::snapshot records the RNG position next to the store payload, and restore_snapshot rewinds the stream to that position, so a rerun draws the same blinding nonces and lands on the identical commitments, events, and state root. (This is why rerunning an operation sequence after a restore reproduces the exact final state; see docs/deterministic-execution.md.)

Snapshot/restore is the debugging and scenario-generation workflow: capture, experiment, restore, compare.

Cost model

Each snapshot clones the whole store: O(state) per snapshot and per rollback. This is a deliberate trade — exactness over incremental diffing — appropriate for a deterministic testing environment where states are small.