# 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.
Last changed by  
 
Sina Mahmoodi
31

Read more

7002 withdrawal schedule

Adding a withdrawal requests to the queue costs 74160 gas per call, which means you can add ~480 withdrawals per block. Within two blocks, the fee to add more withdrawals to the queue will take roughly 2.6 million ETH in the next block. The amount of ETH needed to add another withdrawal will go down over the next blocks, but the curve of the increase is extremely steep. You can kinda think of it as if the 12.5% increase per block of 1559 is only applied every 480 blocks. So whenever this increase applied, the fee not only goes up by 12.5% but by (12.5%)^480, thus the fee increases quite suddenly. The fee will slowly go down on every block, but it will take 126 blocks until the fee is below 1 ETH to add a withdrawal to the queue. This means that an attacker can grief staking pools quite easily. NUMBERS

3/4/2025
Onchain day 6

Kurtosis challenge To run Kurtosis, you will need Docker. Check out the installation docs for Docker. Then see how to install Kurtosis. This is the configuration we will be using for our private network. It will include 3 nodes. 2 Geth<->Lighthouse pairs and one Geth<->Teku pair. It will additionally run dora the blockchain explorer. Save the following to a file basic.yaml. participants: - el_type: geth cl_type: lighthouse

2/13/2025
Writing a testcase for graphql

I'm adding a testcase for EIP-4844 which will be shipped in the Cancun hardfork. The graphql schema will change to include the additional fields in the block and transaction data structures. Refer to https://github.com/ethereum/execution-apis/pull/468 for the schema changes. The graphql simulator https://github.com/ethereum/hive/tree/master/simulators/ethereum/graphql comes with a chain. However this chain does not include 4844 blocks. So we need to update the chain and add new blocks + txes. For that we use https://github.com/s1na/graphqltestgen. graphqltestgen This tool is used to extend an existing chain which at first consisted of only frontier blocks and later extended with post-merge blocks. The benefit here is we can test the response at fork boundaries too. It takes in a genesis configuration assumed to be at ./genesis.json and the RLP-serialized list of blocks at ./chain.rlp. Note: you need to modify the code to implement the kind of block you want to add. The new chain will be written to ./newchain.rlp. Note since the merge forks happen after a given timestamp. Since the new block should be Cancun, the genesis file must be modified with a value for "cancunTime". To calculate the value, we need to know the timestamp of the last block. This is because the chain generator will automatically assign parentBlock + 10 as the timestamp of any new block. So I print the current header with go run main.go head to find out the latest timestamp.

10/3/2023
state

tracer hooks OnBalanceChange(addr common.Address, prev, new *big.Int, reason BalanceChangeReason) OnNonceChange(addr common.Address, prev, new uint64) OnCodeChange(addr common.Address, prevCodeHash common.Hash, prevCode []byte, codeHash common.Hash, code []byte) OnStorageChange(addr common.Address, slot common.Hash, prev, new common.Hash) OnLog(log *types.Log) OnNewAccount(addr common.Address) blockchain

8/8/2023
Read more from Sina Mahmoodi
Published on HackMD