Ethereum Foundation researchers warn of storage burden from 'state bloat,' propose paths to ease node bottleneck

The Ethereum Foundation’s Stateless Consensus team has outlined a series of ideas to curb “state bloat,” warning that the network’s ever-expanding record of accounts, contract storage, and bytecode is becoming increasingly difficult for node operators to store, serve, and sync.

Ethereum’s “state” encompasses everything the network currently knows, including account balances, contract storage, and the code that powers applications. The Foundation said the system has become a critical piece of global infrastructure that “settles billions of dollars in value” and coordinates thousands of applications.

But EF researchers say its importance has now presented a serious issue: the state only grows; it never shrinks.

As more data accumulates, running a full node becomes more expensive and fragile. An EF blog post noted that “if the state becomes too large, too centralized, or too difficult to serve, all of these layers become more fragile, more expensive, and harder to decentralize."

Scaling improvements such as Layer 2 expansion, EIP-4844 (proto-danksharding), and gas limit increases have enabled more activity, but they also accelerate the growth of the state.

The researchers cautioned that if only a small set of sophisticated operators can afford to store and serve the full state, Ethereum’s censorship resistance, neutrality, and resilience could weaken. The team said it is actively stress-testing to determine when “state growth becomes a scaling bottleneck,” when “state size makes it hard for nodes to follow the head of the chain,” and when “client implementations start failing under extreme state size.”

Stateless validation raises a new question: who stores the data?

Ethereum’s long-term roadmap includes statelessness, which focuses on allowing validators to verify blocks without holding the full state.

While this reduces the burden on validators and unlocks higher throughput, it also shifts responsibility for storing the historical state to a smaller, more specialized group. The researchers wrote that in a stateless design, “most state is likely to be stored only by: block builders, RPC providers [and] other specialist operators like MEV searchers and block explorers.”

That centralization, the team said, introduces challenges around syncing, censorship resistance, and resilience to outages or external pressure.

Three proposed pathways

The Stateless Consensus team proposed three potential approaches to make storing and serving state more manageable.

The first, State Expiry, removes inactive data from the active set while allowing users to revive it with proofs. The team said roughly “80% of the state has not been touched for more than 1 year,” yet all nodes must still store it today. Two variants are under consideration: “mark, expire, revive,” which flags and removes seldom-used entries, and “multi-era expiry,” which rolls data into eras and freezes older ones.

The second path, State Archive, separates hot state from cold state. Hot data remains bounded and fast to access, while cold data is preserved for history and verifiability. This would allow node performance to “stay roughly stable over time, instead of degrading as the chain ages,” even as total state grows.

The final option, Partial Statelessness, allows nodes to store only subsets of the state, while wallets and light clients cache the data they rely on. This could broaden participation by lowering storage costs and reducing dependence on major RPC providers.

Across all three approaches, the goal is to “reduce state as a performance bottleneck, lower the cost of holding it, and make it easier to serve.”

What’s next?

The EF said it is prioritizing practical efforts that can deliver benefits today while preparing for more ambitious protocol changes in the future.

According to the post, these include archive development, improvements to RPC infrastructure, and making it easier to run partial stateless nodes. The team also emphasized that these initiatives were chosen because “they are immediately useful and forward-compatible.”

Moving forward, the foundation has invited developers, node operators, and infrastructure teams to participate.

“As we iterate, we’ll keep sharing our progress and our open questions. But we can’t solve this in isolation,” the researchers wrote. “If you are a client developer, run a node, operate infrastructure, build on Layer 2s, or simply care about Ethereum’s long-term health, we invite you to get involved: share feedback on our proposals, join the discussion on forums and calls, and help test new approaches in practice.”

The update comes as the Ethereum Foundation has stepped up communication around long-term protocol development.