EraE supersedes Era1 as the EL history archive format and is capable of encoding pre-merge, transition, and post-merge epochs in a single format. EraE files will be generated for the entire chain history, replacing Era1 for most purposes. Both formats use the same e2store container and share most entry types. The key differences in eraE are: Grouped layout: Era1 interleaves entries per block (header₀ body₀ receipts₀ td₀ header₁ body₁ ...). EraE groups entries by type (header₀ header₁ ... body₀ body₁ ... receipts₀ receipts₁ ...). Slim receipts (type 0x0a) instead of legacy compressed receipts (type 0x05). These use the eth/69 encoding: [tx-type, post-state-or-status, cumulative-gas-used, [logs...]], which exclude the bloom filter. ComponentIndex (type 0x3267) instead of Era1's BlockIndex, enabling variable numbers of components per block (e.g. TotalDifficulty is omitted post-merge). No Accumulator or TotalDifficulty for pure post-merge epochs. Transition epochs (spanning the merge) include both. An eraE file holds up to 8192 blocks. Files are named <network>-<epoch>-<hash>.erae, where <hash> is the first 4 bytes (hex) of the last block hash in the epoch. Each archive directory includes a checksums.txt with per-file SHA-256 hashes.
2/26/2026Why This Matters Growing gas limits drive faster state growth, making the database layer a critical bottleneck. At 60M gas: ~124 GiB/year state growth; at 100M gas: ~197 GiB/year. Consequences include longer sync times, degraded access latency, and higher hardware requirements for node operators. Current Client DBs Client DB Engine Approach Roadmap Geth
1/30/2026Motivation The client ecosystem is different to how it was a few years ago. Today operators can choose between multiple high-quality clients, with new ones joining the ranks. Practical information about the clients exists but it is scattered across repos, websites, X threads and tribal memory. This makes it difficult for operators to make informed and use-case dependent decisions. Abstract We propose a dashboard which serves factual objective information about clients and surfaces the trade-offs that node operators care about, to help with the decision fatigue. Goals Help node operators choose the right client for their use-case
1/5/2026by 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/2025