Requirement Idea: Snapshot as a Service

[marioevz]

AI generated issue

Idea: provide a service that gives us a ready-to-use execution client snapshot for a specific chain head, without each user having to manually mount datadirs, start clients, and wire RPC endpoints themselves.

Why this is needed

In the discussion, the current workflow for stateful benchmarking and fixture generation depends on a specific chain head plus a client snapshot that matches it. That creates friction because the snapshot is large, setup is manual, and the consumer and filler both need to use the exact same starting state. In practice, this makes iteration slower and makes CI automation harder. A service layer would hide that complexity and return a usable RPC endpoint for the requested head and client. It would also make it easier to support repeatable stateful test generation, payload generation, and benchmark execution from a shared starting point.

Problem it solves

• Manual snapshot mounting is hard and slow.
• Large snapshots are awkward to serve and consume.
• Stateful fixtures are anchored to a specific chain head, so both producer and consumer need the same exact starting point.
• Current setup makes quick debugging, repeated local testing, and CI automation more difficult.

Proposed concept

A user or CI job requests:

• a chain head / snapshot identifier
• a client implementation
• optionally a network/config profile

The service then:

• finds the matching snapshot
• mounts or restores it in the background
• starts the requested client against that snapshot
• verifies readiness
• returns usable endpoints, ideally RPC / engine / auth configuration

So instead of handling datadirs directly, the caller asks for “head X on client Y” and receives a running environment.

Ideal requisites

Core functional requirements

• Request by exact chain head or equivalent immutable snapshot ID.
• Request by client type (for example, Geth, Nethermind).
• Return a fully configured RPC endpoint instead of a raw snapshot.
• Optionally return engine/auth endpoints if needed for tooling flows.
• Guarantee the environment is started from the exact requested state.

Reliability requirements

• Health-check the client before returning it.
• Confirm the exposed node matches the requested head.
• Make startup reproducible across local usage and CI.
• Support repeated access to the same snapshot without bespoke manual setup.

Usability requirements

• Abstract away datadir mounting and client bootstrapping.
• Be simple enough that tooling can call it automatically from CI.
• Support quick debugging and fast iteration for developers.
• Minimize manual configuration at call time.

Benchmarking / testing requirements

• Work for state fulfilling and stateful benchmark generation.
• Allow fixture generation and benchmark execution to share the same snapshot origin.
• Support automation of releases or payload generation in CI if the snapshot can be requested programmatically.

Future-friendly requirements

• Support multiple networks / benchmark chains.
• Support snapshot lifecycle/versioning.
• Potentially allow predefined initial states derived from state actor patterns or benchmark account sets discussed in the meeting.

[jochem-brouwer]

Will link this effort to generate deterministic state locally: https://github.com/ethereum/state-actor

If we add metadata to "where to find snapshot" (or: how to generate snapshot) then the toolchain would look like this:

1. Figure out how to retrieve snapshot (download/generate (by e.g. state-actor), or it already exists locally). The snapshot should have (for current benchmark type) access to the head block (thus including the state) the benchmarks are built on. (These benchmarks thus are the existing benchmarks: they "only" bench execution and not behavior like syncing)
2. Figure out if the payloads for the benchmark exists. If not, generate those (ideally by: feat(tests): stateful test filling for benchmark tests #2637)
3. Run benchmarks using a runner (e.g. benchmarkoor)

[LouisTsai-Csie]

According to the decision on our meeting:

Summary

• We're moving from snapshot to state-actor approach
• State-actor allows us to start a Kurtosis package and mount the database directly, eliminating manual client setup

Action Items

• Louis: Experiment with state-actor and report on required infrastructure and EELS integration
• Jochem: Work on repricing state integration; Louis will assist with verification