# Workflow A: Head-of-Chain Execution & Tracing — Replica Plan **Goal:** Serve `eth_call` / tracing at the **tip** (and most recent 128 blocks), without running more full nodes and easy spin-up of new instances (i.e. [Workflow A](https://notes.ethereum.org/UI6ScbXsS7ypqVZY6ZeDWA#A-Head-of-Chain-Execution-amp-Tracing)). **Model:** **Captain → Followers** - **Captain:** one live writer. - **Followers:** read-only replicas serving RPC, fed by captain snapshots + state diffs. --- ## Architecture (high-level) - **Base snapshot** of state at block **S** (exported every **3–4 hours**). - **State diffs** from **S → H** applied by followers to "sync". - Followers keep 128 in-memory snapshot layers for reorgs and simulations. - Followers run a new Geth mode: blockchain disabled (no consensus/validation), state-only, RPC server + tracer. ## Snapshot production (captain) Captain should be able to generate a full state snapshot while keeping in sync. Two variants: 1) DB→DB export: open a new Pebble, copy from live, close, release as snapshot. 2) Export-to-file: no compaction on captain; requires ingest on follower. It comes down to a trade-off between captain load vs follower sync speed. Cadence: every 3–4 hours; ## Delivery In the end the snapshot artifact will be files that have to be delivered based on the capabilities of the running infra. (TODO) ## Forward sync after snapshot import - Captain persists per-block state diffs. We think the pathdb in-memory snapshot layers are a possible fit. They will have to be persisted for a certain duration of time (say 1 day). - Followers long-poll diffs and apply: S + diffs → H. - Follower keeps the state at 128 blocks behind and keeps the most recent diffs are in-memory layers for reorg and allowing reads of more than just the tip. ## Implementation plan - **P0:** Explore snapshot generation via pebbledb. The realities of the generation process will inform future steps. - **P1:** Persistence of in-memory snapshot layers for serving via RPC. - **P2:** Minimal follower mounting base snapshot; serve `eth_call` at that block. - **P3:** Add diffs + in-memory layers + reorg handling. --- ## Honorary mention: Redis-based replication (alternative) Captain writes its state snapshot into a Redis instance; Redis handles **sync** between instances. A follower spins up alongside a new Redis and serves `eth_call` from it. Requirements: Redis features for atomic writes (captain), persistence (followers), and replication between instances. The in-memory snapshot layers (~128 blocks) are also written to Redis so followers can serve very recent state.