# Scaling RPC Nodes Under Rising Gas Limits Goal: 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 ### A) Head-of-Chain Execution & Tracing **Methods:** `eth_call`, `eth_estimateGas`, `debug_traceCall`, `traceBlock`, `traceTransaction` **at head** **Why:** This is the **majority of traffic**. It hits the **latest state**. **Pain:** The only way to unburden existing nodes is to run more full nodes. **What we need:** a **lighter read-replica model** that shares a heavy state store, [Besu Fleet](https://consensys.io/blog/besu-fleet-the-future-of-rpc-scaling) style. ### B) Historical Execution & Tracing **Methods:** `eth_call`, `eth_estimateGas`, tracing **at block N** **Users:** explorers, analytics, debugging, incident response. **Pain:** Same as above. **What we need:** read-replica of partial/Erigon-style archive, which is harder. ### C) Recent-Window State Proofs **Methods:** `eth_getProof` for the **last X months** **Users:** optimistic rollups (fault proofs), some bridges. ORUs need ~**1 month** minimum; provider data shows **~4 months covers ~85%** of `eth_getProof` requests. **Pain**: The only way to serve these request is a full archive node, very heavy and brittle. **What we need:** partial archive nodes with configurable trie retention (X months). The idea is that a partial archive node with 4 months of trie history will still be more lightweight than a full archive node. ### D) Deep-History State Proofs (long tail) **Methods:** `eth_getProof` for **older blocks** (e.g., genesis–5M ≈ **~5%** of requests) **Users:** Not clear. **Pain:** The only way to serve these requests is a full archive node. **What we need:** external tooling to index trie history. Keep it off live nodes. ### E) Other `eth_getLogs` is a honorary mention but we believe it is largely solved by the new geth log indexer. --- ## 3) Assumptions & measurement Ask: Coordinate a short joint instrumentation effort (providers + clients) to keep these numbers current as gas limits move. - **Traffic mix telemetry:** % of QPS by method and by **age** (head vs recent window vs deep history). - **Latency SLOs:** target **p50/p95/p99** for (A) head execution/tracing and (B) historical execution/tracing under realistic load.
Last changed by  
 
Sina Mahmoodi
73

Read more

Inside the Shadow-Geth Grant: A Personal Journey into Making Ethereum Faster

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/2025
Client Summit

Invitees: ELs (incl. ethrex) CLs Etherscan Infura Alchemy Ankr Tenderly Quicknode

8/28/2025
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). 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/2025
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
Read more from Sina Mahmoodi
Published on HackMD