Authors: Wei Han Ng, Carlos Pérez, Stateless Consensus Research Team; Translator: Jinse Finance
Ethereum has grown from a small, experimental network into a key component of the global infrastructure. It settles billions of dollars worth of transactions daily, coordinates thousands of applications, and underpins the entire Layer 2 (L2) network ecosystem.
Ultimately, all of this depends on a core underlying component: state .
1. What is " state " and what is its importance?
A user's balance is not stored in their wallet, but rather in the Ethereum state. The state can be roughly understood as "everything that Ethereum currently knows": accounts, contract storage (all data written to contracts), and bytecode (the logic that runs when using smart contracts).
State is the foundation of almost all functionality:
The wallet relies on it to display the balance and past transaction history;
Decentralized applications (DApps) query it to understand their existing holdings, orders, or messages;
Infrastructure (block explorers, cross-chain bridges, indexers, etc.) continuously reads the state in order to provide services on top of it.
If the state becomes too large, too centralized, or unable to provide services, all of the above layers will become more fragile, more costly, and more difficult to decentralize.
2. L1 expansion will have corresponding consequences.
Ethereum has been working on network expansion for years: through Layer 2 networks, EIP-4844, increasing the gas cap, repricing gas fees, and the built-in proposer-builder separation mechanism. Each step has improved network processing capacity, but has also brought new challenges.
Challenge 1: Continuous Expansion of Momentum
Ethereum's state size only increases, never decreases. Every new account, storage operation, and bytecode write permanently adds to the data the network must retain.
This incurs specific costs:
Validators and full nodes must store more data. As the state size increases, the database needs to handle the additional workload, and its efficiency decreases accordingly.
RPC service providers must maintain full accessibility, ensuring that any account or stored data can be queried at any time.
State growth leads to slower node synchronization speed and decreased stability.
Increasing the gas cap exacerbates state bloat because each block can accommodate more write operations. Other public blockchains have already experienced this problem. As the state size increases, it becomes difficult for ordinary users to run full nodes, leading to state data becoming concentrated in the hands of a few large service providers.
In Ethereum, most blocks are already produced by professional builders. The core concern is how many independent entities can still complete end-to-end block building at critical moments. If only a very small number of participants can store and provide the complete state, censorship resistance and trust neutrality will be compromised—because fewer entities will be able to build blocks containing censored transactions.
One positive factor is that mechanisms like FOCIL and VOPS aim to ensure censorship resistance within a professional builder ecosystem. However, their effectiveness still depends on a healthy node ecosystem, where nodes can access, store, and provide state data at an affordable cost. Therefore, controlling state growth is a necessary prerequisite, not an optional optimization.
To determine the critical point of the problem, we are actively conducting stress tests:
When does state growth become a bottleneck for scaling?
When does the state size make it difficult for a node to follow the chain head?
When does the client implementation fail under extreme state scale?
Challenge 2: In a stateless architecture, who is responsible for storing and providing the state?
Even if Ethereum permanently maintains its current gas cap, we will eventually encounter the state bloat problem. Meanwhile, the community clearly expects higher throughput.
The stateless approach eliminates a major limitation: validators do not need to hold the complete state to verify blocks, only proofs. This is a significant scalability breakthrough, meeting the community's demand for higher throughput and revealing a previously implicit fact—state storage can evolve into an independent and more specialized function, rather than being tied to each validator.
At that time, most of the state may be stored by only the following entities:
Block builder;
RPC service provider;
Other specialized operators (such as MEV searchers and block explorers).
In other words, the state will become more centralized.
This will have multiple consequences:
Synchronization becomes more difficult: Centralized service providers may begin to restrict access to state, making it difficult for new service providers to start up;
Reduced resistance to censorship: If the status data to be censored cannot be obtained, anti-censorship mechanisms such as FOCIL may become ineffective.
System resilience risk: If only a few entities store and provide complete state, service interruptions or external stress will quickly cut off access to most components of the ecosystem.
Even though many entities store state, there is a lack of effective ways to verify that they are actually providing services, and existing incentives are insufficient. Snapshot synchronization is widely supported by default, but this is not the case for RPC services. Unless the cost of state services is reduced and their general appeal is increased, the ability of networks to access their own state will be limited to a few service providers.
This issue also affects Layer 2 networks. A user's ability to force transaction packaging relies on reliable access to the state of the Rollup contract on Layer 1. If L1 state access becomes fragile or highly centralized, these safety valve mechanisms will be difficult to operate in practice.
3. The three main directions we see
(1) Status validity period
Not all state data is equally important indefinitely. Our recent analysis shows that approximately 80% of state data has not been accessed for over a year. However, nodes still incur the cost of permanently storing this state.
The core idea of state expiration mechanisms is to temporarily remove inactive states from the "active set" and restore them through some form of proof when needed. In general, they can be divided into two main categories:
Category 1: Marking, Expiration, Resurrection
The protocol no longer treats all states as permanently active. Instead, it marks rarely used states as inactive, removing them from the active set maintained by each node, while allowing them to be restored in the future through historical proof of existence. The practical effect is that frequently used contracts and balances remain active with low access costs, while long-forgotten states do not need to be continuously maintained by each node and can still be recalled when needed.
Category 2: Multi-cycle failure mechanism
In a multi-cycle design, instead of invalidating individual entries, we periodically divide the state into cycles (e.g., one cycle = one year). The current cycle is small and fully active, while older cycles are frozen from a real-time execution perspective, and new states are written into the current cycle. Old states can only be recovered by proving their existence in previous cycles.
The mark-invalidate-revive mechanism is generally more sophisticated, and the revive process is more direct, but the marking process requires storing additional metadata. Multi-cycle invalidation is conceptually simpler and integrates more naturally with archiving mechanisms, but the proof of revive is often more complex and larger in size.
Ultimately, both approaches share the same goal—to keep the active components streamlined by temporarily removing inactive parts while providing a way to revive them—but they make different trade-offs in terms of complexity, user experience, and the allocation of workload to clients and infrastructure.
(2) Status archiving
State archiving categorizes states into cold and hot states.
The hot state is the part of the network that needs to be accessed frequently;
The cold state refers to the part of the record and verifiability that is still important but rarely touched.
In the state archiving design, nodes explicitly store frequently used hot states separately from historical data. Even as the overall state continues to grow, the portions requiring rapid access (hot datasets) remain finite in size. In practice, this means that the node's execution performance—especially the I/O cost of accessing the state—remains relatively stable over time and does not decline with chain age.
(3) Lower the barrier to entry for state storage and services
One obvious question is: Can we achieve our goal while holding less data? In other words, can we design nodes and wallets that can still function as effective participants without permanently storing the complete state?
One promising direction is partially stateless solutions:
Nodes only store and provide partial state (such as data related to a specific user or application).
Wallets and light clients take a more proactive role in storing and caching the necessary state fragments, rather than relying entirely on a few large RPC service providers. By securely distributing storage across wallets and niche nodes, the burden on individual operators will be reduced, and the state holder community will become more diverse.
Another approach is to lower the barrier to entry for operating useful infrastructure:
Simplify the process of deploying RPC nodes that only serve a portion of the state;
Design protocols and tools to enable wallets and applications to discover and integrate multiple local data sources, rather than relying on a single complete RPC endpoint.
4. Future Direction
The state of Ethereum is quietly becoming key to several core issues for the protocol's future:
At what point does the size of a state become a barrier to participation?
When a validator can securely verify a block without state, who stores the state?
Who will provide status services to users? What will be the incentives?
Some issues remain unresolved, but the direction is clear: reduce the impact of state on performance, reduce storage costs, and improve service accessibility.
Our current focus is on advancing low-risk, high-return initiatives:
Archiving scheme
We are exploring an off-protocol solution to control the scale of active state while relying on an archiving scheme to store historical data. This will provide real-world data on performance, user experience, and operational complexity. If proven effective, it can be pushed forward as an in-protocol upgrade if necessary.
Some stateless nodes and RPC enhancement
Most users and applications interact with Ethereum through centralized RPC service providers. We are working on the following improvements:
Reduce the difficulty and cost of running nodes, even if the nodes do not store all states;
Allows multiple nodes to collaborate in providing complete state services;
Increase the diversity of RPC service providers to avoid single-point bottlenecks.
These projects were carefully selected because they combine immediate practicality with forward-looking compatibility: they can both improve Ethereum's current health and lay the foundation for deeper protocol upgrades in the future.
