Disclaimer: The following blog is a proposal from the Stateless Consensus team. Content may not imply consensus views, and the EF is a broad organization that includes a healthy diversity of opinion across Protocol and beyond that together strengthen Ethereum. Special thanks to Ladislaus von Daniels and Marius van der Wijden for reviewing this article.

Ethereum has grown from a small experimental network into a critical piece of global infrastructure. Every day it settles billions of dollars in value, coordinates thousands of applications, and anchors an entire ecosystem of L2s.

All of this ultimately relies on a single underlying component: state.

What is “state” and why it matters

A user’s balance is not stored in their wallets: It lives in Ethereum’s state. The state can roughly be thought of as “everything Ethereum knows right now”:

• Accounts
• Contract storage (all the data contracts have written)
• Bytecode (the logic that runs when you use a smart contract)

State underpins almost everything:

• Wallets use it to show balances and past actions.
• Dapps query it to know which positions, orders or messages exist.
• Infrastructure (explorers, bridges, indexers, etc.) reads it constantly to provide services on top.

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 L1 comes with consequences

Ethereum has been on a multi-year journey to scale: L2s, EIP-4844, gas limit increases, gas repricings, and enshrined Proposer-Builder Separation (ePBS). Each step lets the network handle more activity, but they introduce more challenges.

Challenge #1 – State keeps growing

Ethereum’s state size only goes one way: up. Every new account, storage and bytecode write adds data the network has to keep forever.

This has concrete costs:

• Validators and full nodes must store more data. This introduces additional work in the database that is less efficient as the state grows larger.
• RPC providers need to keep the full state available so any account or storage can be queried at any time.
• Syncing becomes slower and more fragile as the state grows.

Figure 1. New state added per week in the past year (EIP-8037)

Gas limit increases amplify state growth, since they allow more writes per block. Other chains already experience this problem. With growing state sizes, running a full node is unrealistic for average users, which pushes state into the hands of a few large providers.

On Ethereum, most blocks are already produced by sophisticated builders. One concern is how many independent parties can still build blocks end-to-end when it matters. If only a tiny set of actors can hold and serve the full state, censorship resistance and credible neutrality suffer, because fewer parties can build blocks that include censored transactions.

As a partial silver lining, mechanisms like FOCIL and VOPS aim to preserve censorship resistance even in a world with specialized builders. But their effectiveness still depends on a healthy ecosystem of nodes that can access, hold, and serve the state without prohibitive cost. Keeping state growth under control is therefore a prerequisite, not an optional optimization.

To determine when this would become a problem, we are actively measuring and stress-testing:

• When state growth becomes a scaling bottleneck.
• When state size makes it hard for nodes to follow the head of the chain.
• When client implementations start failing under extreme state size.

Find more details at bloatnet.info.

Challenge #2 – In a stateless world, who holds and serves the state?

Even if Ethereum stayed at today’s gas limit forever, we would eventually run into state growth issues. At the same time, the community clearly wants more throughput.

Statelessness removes a big constraint: validators no longer need to hold the full state to validate blocks, they can just verify proofs. This is a major scalability win that lets us meet the community’s demand for higher throughput, and it also makes explicit something that used to be implicit: state storage can become a separate, more specialized role instead of being tied to every validator.

At that point, most state is likely to be stored only by:

• Block builders
• RPC providers
• Other specialist operators like MEV searchers and block explorers

In other words, the state becomes much more centralized.

That has several consequences:

• Syncing gets harder: centralized providers could start gatekeeping access to the state, making it harder to spin up new providers.
• Censorship resistance weakens: censorship resistance mechanisms like FOCIL might be neutered due to the unavailability of censored state.
• Resilience and capture risk: if only a few actors store and serve the full state, outages or external pressure on them can quickly cut off access to large parts of the ecosystem.

Even if many entities store state, there’s no good way to prove they actually serve it, and there are few incentives to do so. Snap sync is widely served by default, but RPC is not. Without making state serving cheaper and generally more attractive, the network’s ability to access its own state ends up in the hands of few providers.

This also affects L2s. Users’ ability to force-include their transactions relies on having reliable access to the rollup contract state on L1. If L1 state access becomes fragile or highly centralized, those safety valves become much harder to use in practice.

Three broad directions we see

State Expiry

Not every piece of state is equally important forever. In our recent analysis, we have shown that roughly 80% of the state has not been touched for more than 1 year. However, nodes still bear the cost of holding the state forever.

State expiry is the general idea of temporarily removing inactive state from the “active set”, and requiring some form of proof to bring it back when needed. At a high level, we can think of two broad categories:

1. Mark, Expire, Revive
Instead of treating all of the state as permanently active, the protocol can mark rarely used state as inactive so it no longer lives in the active set every node maintains, while still allowing it to be revived later with a proof that it previously existed. In effect, frequently used contracts and balances stay hot and cheap to access, while long-forgotten state doesn’t burden every node but can still be brought back if someone needs it again.

2. Multi-era Expiry
In a multi-era design, we don’t expire individual entries, but periodically roll the state into eras (for example, one era = one year). The current era is small and fully active, older eras are frozen from the point of view of live execution, and new state is written into the current era. The old state can be reinstated only if it comes with proofs that it existed in a previous era.

Mark–expire–revive tends to be more fine-grained and makes reviving more straightforward, but marking requires additional metadata to be stored. Multi-era expiry is conceptually simpler and pairs more naturally with archiving, but the revival proofs tend to be more complex and larger.

Ultimately, both categories aim at the same goal—keeping active state small by temporarily removing inactive parts while still providing ways to revive them—but they make different trade-offs in complexity, UX, and how much work is pushed onto clients and infrastructure.

Additional readings:

• State Expiry: In-protocol vs. Out-of-protocol
• Compression-based state expiry

State Archive

State archive is an approach that separates hot and cold parts of the state.

• Hot state is what the network needs to access frequently.
• Cold state is everything that still matters for history and verifiability, but is rarely touched.

In a state archive design, nodes explicitly store recent, frequently used state from older data separately. Even if the total state keeps growing, the part that needs fast access (the hot set) can remain bounded. In practice, this means that the execution performance of a node—especially the I/O cost of accessing state—can stay roughly stable over time, instead of degrading as the chain ages.

Making it easier to hold and serve state

An obvious question is: can we do enough while holding less data? In other words, can we design nodes and wallets that are still useful participants without storing the full state forever?

One promising direction is partial statelessness:

• Nodes only hold and serve a subset of the state (for example, the parts relevant to a set of users or applications).
• Wallets and light clients take a more active role in storing and caching the pieces of state they care about, instead of relying entirely on a few big RPC providers. If we can safely decentralize storage across wallets and “niche” nodes, the burden on any single operator goes down, and the set of state holders becomes more diverse.

Another direction is to lower the barrier to running useful infrastructure:

• Make it easier to spin up nodes that can serve RPC for a partial state.
• Design protocols and tools so wallets and apps can discover and combine multiple partial sources instead of depending on a single full RPC endpoint.

We explore these ideas in more detail in:

• The Future of State, Part 1: OOPSIE – A new type of snap sync–based wallet/light client
• The Future of State, Part 2: Beyond the Myth of Partial Statefulness & The Reality of ZKEVMs

What’s Next?

Ethereum’s state is quietly at the center of some of the biggest questions for the protocol’s future:

• How large can the state grow before it becomes a barrier to participation?
• Who will store it, once validators can safely validate blocks without it?
• Who will serve it to users, and under what incentives?

Some of these questions are still open, but the direction is clear: reduce state as a performance bottleneck, lower the cost of holding it, and make it easier to serve.

Our priorities today are to focus on low-risk, high-reward work that helps:

Archive solutions
We are experimenting with out-of-protocol solutions to keep the active state bounded while relying on archives for older data. It should give us real-world data on performance, UX and operational complexity. If proven successful, we can push it into an in-protocol change if it’s necessary.

Partial stateless nodes and RPC enhancements
Most users and apps interact with Ethereum through centralized RPC providers. We are working on improvements that:

• Make it easier and cheaper to run nodes, even if they don’t hold every piece of state.
• Allow multiple nodes to cooperate to serve the full state surface.
• Increase diversity among RPC providers, so no single actor becomes a bottleneck.

These projects are deliberately chosen because they are immediately useful and forward-compatible: they make Ethereum healthier today while also preparing the ground for more ambitious protocol changes later.

As we iterate, we’ll keep sharing our progress and our open questions. But we can’t solve this in isolation. If you are a client developer, run a node, operate infrastructure, build on L2s, 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.