by jsvisaSeptember 2 2025 You can find the full report here: https://hackmd.io/@jsvisa/geth-pebble-grant-report Running a full Ethereum node has always appealed to me because it embodies the spirit of decentralization — you verify everything yourself and help secure the network. Go-Ethereum (Geth) is the most widely used execution client, so its performance determines how viable it is for everyday node runners, researchers, and infrastructure providers. This is my story as an external contributor funded by an Ethereum Foundation grant to work on PebbleDB performance, state size analysis, and code improvements. It was a rare chance to peek under the hood of Geth, experiment at massive scale, and push forward the limits of what the client can do. Why Benchmark and Analyse Geth? The grant’s aim was simple: measure where Geth struggles with very large databases and fix it. Over time the Ethereum state has ballooned as more contracts, tokens and users join the network. By the start of 2025 the database was hundreds of gigabytes and projected to keep growing at ~48 GiB per year. Rather than rely on gut feelings, I wanted concrete data, so the project was split into four phases:
9/3/2025Invitees: ELs (incl. ethrex) CLs Etherscan Infura Alchemy Ankr Tenderly Quicknode
8/28/2025Goal: 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). 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".
7/30/2025Goal: We assume gas-limit increases will proceed. This note identifies the RPC workflows most affected and highlights client + infra work the EF should resource to mitigate the worst cases. 1) Context More gas per block ⇒ more state writes per block ⇒ larger live state and higher state churn (cache misses, write amplification, compactions). The effect is two-fold: 1. nodes are more under strain, and 2. EVM simulations are heavier (e.g. due to large contract storage). A big operational pain point for providers is archive capability to serve real use-cases (e.g., ORU fault proofs). Full archive nodes are heavy and brittle. As gas limits rise, they become harder to run and maintain (disk, IOPS, compactions, sync, recovery). Goal: enable vertical scaling without “just run more full nodes.” 2) Workflows to prioritize
7/29/2025