Disclaimer: The following blog is a suggestion from the Stateless Consensus team. Content may not imply a consensus view, and EF is a broad organization with a healthy diversity across the protocol and beyond, and together they 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 to an important part of the global infrastructure. Every day, we settle billions of dollars in value, orchestrate thousands of applications, and power the entire L2 ecosystem.
All of these ultimately depend on one underlying component. state.
What is “state” and why is it important?
User balances are not stored in wallets, but in Ethereum state. State can be loosely thought of as “everything Ethereum knows at the moment.”
- account
- Contract storage (all data contracts are written)
- Bytecode (the logic executed when using a smart contract)
The state supports almost everything.
- The wallet uses this to display balances and past actions.
- Dapps run queries to find out which positions, orders, or messages exist.
- The infrastructure (explorers, bridges, indexers, etc.) will always read it and serve it on top.
When a state becomes too large, too centralized, or too difficult to serve, all of these layers become more vulnerable, more expensive, and harder to decentralize.
Scaling L1 has consequences
Ethereum has undergone several years of scaling efforts, including L2, EIP-4844, increasing gas limits, resetting gas prices, and proposer-builder separation (ePBS). Each step allows the network to handle more activity, but introduces more challenges.
Challenge #1 – The state continues to grow
Ethereum state size only increases in one direction. Each new account, storage, and bytecode write adds data that the network must retain forever.
This has specific costs.
- Validators and full nodes need to store more data. This causes additional work in the database and becomes less efficient as the state grows.
- The RPC provider must keep a complete state available so that the account or storage can be queried at any time.
- As the state grows, synchronization becomes slower and more fragile.
Figure 1. New states added weekly over the past year (EIP-8037)
Increasing the gas limit amplifies the state increase by allowing more writes per block. Other chains are already experiencing this problem. As the size of state increases, it becomes impractical for the average user to run a full node, leaving state in the hands of a few large providers.
In Ethereum, most blocks are already created by sophisticated builders. One concern is how many independent parties will be able to build blocks end-to-end when it matters. When only a small number of actors can hold and serve a complete state, resistance to censorship and reliable neutrality are undermined because fewer parties can build blocks containing censored transactions.
As a partial silver lining, mechanisms like FOCIL and VOPS aim to remain censorship-resistant even in a world of professional builders. However, its effectiveness still relies on a healthy ecosystem of nodes that can access, maintain, and provide services without incurring prohibitive costs. Therefore, controlling state growth is a must, not an optional optimization.
We are actively measuring and stress testing to determine when this becomes an issue.
- When state growth becomes a scaling bottleneck.
- When the size of the state makes it difficult for nodes to follow the beginning of the chain.
- When client implementations start failing with extreme state sizes.
For more information, please visit bloatnet.info.
Challenge #2 – In a world without states, who will hold and serve the state?
Even if Ethereum stayed at today’s gas limit forever, it would eventually run into state growth problems. At the same time, the community clearly wants increased throughput.
Making it stateless removes major constraints. Validators no longer need to maintain complete state to verify blocks, they only need to verify proofs. This is a huge scalability benefit, allowing us to meet community demands for higher throughput and making what was previously implicit now explicit. State storage can be an independent, more specialized role rather than tied to all validators.
At that point, most state can only be saved by:
- block builder
- RPC provider
- Other specialized operators such as MEV searchers and block explorers
In other words, the state is even bigger. centralized.
This has several implications.
- Difficult to sync: A centralized provider may start gatekeeping access to the state, making it difficult to launch new providers.
- Weakening resistance to censorship: Censorship resistance mechanisms like FOCIL can be disabled due to unavailability of censorship state.
- Resilience and risk capture: If only a few actors store and provide complete state, an outage or external pressure on an actor can quickly cut off access to large parts of the ecosystem.
Even if many organizations keep the nation, there is no good way to prove that they actually serve the nation, and there is little incentive to do so. Snap sync is widely provided by default, but RPC is not. Unless we make state services cheaper and generally more attractive, the ability to access the network’s own state will remain in the hands of a small number of providers.
This also affects L2. The ability of users to force inclusion of their transactions depends on ensuring that they have access to the state of the rollup contract on L1. When access to L1 state becomes weak or highly centralized, these safety valves become much more difficult to use in practice.
Three major directions we are considering
Status expiration date
Not all nations will be equally important forever. Our recent analysis found that approximately 80% of the state has been untouched for more than a year. However, nodes still incur the cost of maintaining state forever.
State expiration is the general concept of temporarily removing inactive state from the “active set” and requiring some form of proof to return it when needed. Broadly speaking, there are two broad categories:
1. Marks, expiration, and reinstatement
Instead of treating all states as permanently active, the protocol can mark rarely used states as inactive so that they no longer exist in the active set maintained by all nodes, but can be revived later with evidence that they were previously present. In reality, frequently used contracts and balances are always hot and cheap to access, while long-forgotten states do not burden all nodes and can be brought back if needed again.
2. Expiration dates for multiple eras
In a multi-era design, states are periodically rolled into eras (for example, 1 era = 1 year) rather than expiring individual entries. The current era is small and fully active, the old era is frozen in terms of live execution, and the new state is written into the current era. An old state can only be restored if there is evidence that it existed in a previous era.
Mark, expire, and reinstate tend to be more fine-grained, making reinstatement easier, but marking requires storing additional metadata. Multi-era expiration dates are conceptually simple and pair more naturally with archives, whereas resurrection proofs tend to be more complex and extensive.
Ultimately, both categories aim to have the same goal: temporarily remove inactive parts to keep active states small while providing a way to bring them back to life, but they make different trade-offs in terms of complexity, UX, and how much work is placed on the client and infrastructure.
Additional information:
state archives
State archives are an approach that separates the hot and cold parts of a state.
- A hot state is one that the network needs to access frequently.
- The cold state is all about things that remain important to history and verifiability but are rarely touched on.
In a state archive design, nodes explicitly store frequently used recent state separate from older data. Parts that require fast access (hot sets) may remain limited even as the overall state continues to grow. In practice, this means that the execution performance of a node, especially the I/O cost of accessing state, can remain more or less stable over time, rather than decreasing as the chain ages.
Make the state easier to hold and provide
The obvious question is: Can you do enough work with less data? In other words, can nodes and wallets be designed that are still useful participants without storing their complete state forever?
One promising direction is partial statelessness.
- A node maintains and provides only a subset of state (for example, the part that is relevant to a set of users or applications).
- Wallets and light clients take a more active role in storing and caching the parts of the state they are interested in, rather than relying completely on a few large RPC providers. Being able to securely distribute storage across wallets or “niche” nodes reduces the burden on a single operator and allows for a more diverse set of state holders.
Another direction is to lower the barriers to running useful infrastructure.
- Makes it easier to spin up nodes that can serve RPCs for partial state.
- We design protocols and tools to allow wallets and apps to discover and combine multiple partial sources, rather than relying on a single complete RPC endpoint.
These ideas are discussed in more detail below.
What’s next?
The state of Ethereum is quietly at the center of some of the biggest questions about the protocol’s future.
- How big can a nation get before it becomes a barrier to participation?
- Once validators can safely verify blocks without it, who will store it?
- Who will provide services to users and under what incentives?
Although some of these questions are still unanswered, the direction is clear. Reduce performance bottlenecks, lower cost of ownershipand make it easier to provide.
Our priority today is to focus on low-risk, high-reward jobs that help:
archive solution
We are experimenting with out-of-protocol solutions to keep active state limited while relying on archives of old data. It should give you real-world data on performance, UX, and operational complexity. Once proven successful, changes within the protocol can be made as needed.
Partial stateless nodes and RPC enhancements
Most users and apps interact with Ethereum through a centralized RPC provider. We are working on improvements such as:
- It makes running a node easier and cheaper, even if the node doesn’t maintain all the state.
- Enables multiple nodes to work together to provide a complete state surface.
- Increase diversity among RPC providers so that no single actor becomes the bottleneck.
These projects were intentionally chosen because they are immediately useful and upwardly compatible. These projects will make Ethereum healthier today, while also preparing the ground for more ambitious protocol changes in the future.
As you iterate, continue to share your progress and any unanswered questions. However, this cannot be solved alone. If you’re a client developer, running nodes, operating infrastructure, building on L2, or simply care about the long-term health of Ethereum, we want you to join us. Please share your feedback on our proposals, participate in discussions on our forums and calls, and help us test new approaches in practice.
