jakiro
Author: Wei Han Ng, Carlos Pérez, stateless consensus research team; Translation: @bitchainvisionxiaozou
Ethereum has grown from a small, experimental network to a critical component of global infrastructure.It settles billions of dollars in daily settlement value, coordinates thousands of applications, and supports the entire Layer 2 network (L2) ecosystem.
It all ultimately relies on one core underlying component: state (state).
1, what is“Status“and its importance
A user’s balance is not stored in their wallet, but in the state of Ethereum.The state can be roughly understood as “everything Ethereum currently knows”: accounts, contract storage (all data written by the contract), bytecode (the logic that runs when using smart contracts).
State is the basis for almost all functionality:
Wallets rely on it to display balances and past operation records;
Decentralized applications (Dapps) query it to learn about existing positions, orders, or messages;
Infrastructure (block explorers, cross-chain bridges, indexers, etc.) continuously reads state to provide services on top of it.
If state becomes too large, too centralized, or difficult to serve, all of the above layers become more fragile, more expensive, and more difficult to decentralize.
2,L1Expansion has consequences
Ethereum has continued to work on network expansion for many years: through the second-layer network, EIP-4844, increasing the gas limit, gas fee repricing, and the built-in proposer-builder separation mechanism.Each step has improved network processing capabilities, but also brought new challenges.
Challenge 1: Status continues to expand
Ethereum’s state size is only increasing.Every new account, storage operation, and bytecode write permanently increases the amount of data the network must hold.
This results in specific costs:
Validators and full nodes must store more data.As the state scale increases, the database needs to handle additional workload and efficiency decreases.
The RPC service provider needs to remain fully accessible and ensure that any account or stored data can be queried at any time.
The growth of status results in slower node synchronization and reduced stability.
Increasing the gas limit increases state bloat because each block can accommodate more write operations.This problem has already occurred in other public chains.As the state scale expands, it is difficult for ordinary users to run full nodes, resulting in state data being concentrated in the hands of a few large service providers.
In Ethereum, most blocks have been produced by professional builders.The core concern is how many independent entities can still complete end-to-end block construction at the critical moment.If only a very small number of participants can store and provide complete state, censorship resistance and trusted neutrality will be compromised – because there will be fewer principals able to construct blocks containing censored transactions.
Part of the positive factor is that mechanisms such as FOCIL and VOPS are designed to ensure censorship resistance in the professional builder ecosystem.But its effectiveness still relies on a healthy ecosystem of nodes that 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 testing:
When does state growth become a scaling bottleneck?
When does the size of the state make it difficult for nodes to follow the chain head;
When client implementations fail at extreme state scales.
Challenge 2: In a stateless architecture, who is responsible for storing and providing state?
Even if Ethereum maintains the current gas cap permanently, we will eventually encounter the state inflation problem.At the same time, the community is clearly expecting higher throughput.
Stateless schemes remove a significant limitation: validators do not need to hold the full state to validate blocks, only proofs.This is an important scalability breakthrough that both addresses the community’s need for higher throughput and reveals a once-hidden fact that state storage can evolve into an independent and more specialized function, rather than being tied to each validator.
At that point, most of the state may be stored only by:
block builder;
RPC service provider;
Other professional operators (such as MEV searchers and block explorers).
In other words, the state will become more centralized.
This has multiple consequences:
Increased difficulty in synchronization: centralized service providers may begin to restrict access to status, making it difficult for new service providers to start;
Weakened censorship resistance: If censored status data cannot be obtained, anti-censorship mechanisms such as FOCIL may fail;
System resilience risk: If only a few entities store and provide complete status, their service interruption or external pressure will quickly cut off access to most components of the ecosystem.
Even though many entities store state, there is no effective way to verify that they actually provide services, and existing incentives are insufficient.Snapshot synchronization is widely supported by default, but RPC services are not.Without reducing the cost of state services and increasing their universal appeal, the network’s ability to access its own state will be limited to a small number of service providers.
This problem also affects Layer 2 networks.The ability of users to force packaged transactions relies on reliable access to the Rollup contract state on L1.If L1 state access becomes fragile or highly centralized, these safety valve mechanisms will be difficult to operate in practical applications.
3, the three major directions we see
(1) Status validity period
Not all state data is of equal permanent importance.Our recent analysis shows that approximately 80% of state data has not been accessed in more than a year.However, nodes still bear the cost of storing this state in perpetuity.
The core idea of the state validity mechanism is to temporarily remove the inactive state from the “active set” and then restore it through some form of proof when necessary.Broadly speaking, they can be divided into two major categories:
Category 1: Mark, Invalidation, Resurrection
Instead of treating all states as permanently active, the protocol marks rarely used states as inactive so that they no longer persist in 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 commonly used contracts and balances remain active and have low access costs, while long-forgotten states do not need to be continuously carried by each node and can still be recalled when someone needs them again.
Category 2: Multi-cycle failure mechanism
In a multi-period design, we do not invalidate individual entries, but periodically divide the state into periods (e.g., one period = one year).The current cycle is smaller and fully active, the old cycle is frozen from a real-time execution perspective, and new state is written to the current cycle.The old state can only be restored by proving its existence in the previous cycle.
The mark-invalidate-resurrection mechanism is usually more sophisticated and the resurrection process more straightforward, but the marking process requires additional metadata to be stored.Multi-cycle failures are conceptually simpler and more naturally integrated with archiving mechanisms, but resurrection proofs tend to be more complex and larger.
Ultimately, these two approaches share the same goal—keep the active state lean by temporarily removing inactive parts while providing a path to resurrection—but they make different trade-offs in complexity, user experience, and allocation of work to clients and infrastructure.
(2) Status archive
The status archive divides the status into cold and hot status.
Hot states are parts of the network that require frequent access;
Cold state is the part that is still important for history and verifiability but is rarely touched.
In the state archive design, nodes will explicitly store recently frequently used hot states and historical data separately.Even as the overall state continues to grow, the parts that need to be accessed quickly (hot data sets) can remain limited in size.In practice, this means that the execution performance of the node – especially the I/O cost of accessing the state – can remain basically stable over time, without declining as the chain ages.
(3) Lower the threshold for state storage and services
An obvious question is: can we achieve our goals while holding less data?In other words, can nodes and wallets be designed that do not require permanent storage of complete state and still function as valid participants?
One promising direction is partially stateless solutions:
Nodes store and provide only partial state (such as data related to a specific user or application);
Wallets and light clients take a more active role in storing and caching required state fragments, rather than relying entirely on a few large RPC service providers.If storage can be securely distributed to wallets and “niche” nodes, the burden on individual operators will be reduced, and the group of state holders will become more diverse.
Another direction is to lower the barriers to running useful infrastructure:
Simplify the process of deploying RPC nodes that only serve part of the state;
Design protocols and tools that 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 the key to several core issues for the future of the protocol:
To what extent does state size increase become a barrier to participation?
When validators can safely validate blocks without requiring state, who will store the state?
Who will provide status services to users?What’s the incentive?
Some issues are yet to be determined, but the direction is clear: reduce the constraints of state on performance, reduce storage costs, and improve service accessibility.
Our current focus is on advancing low-risk, high-return work:
Archiving scheme
We are trying out-of-protocol solutions to control active state size while relying on archiving solutions to store historical data.This will provide real-world data on performance, user experience, and operational complexity.If the verification is valid, it can be promoted to an in-protocol upgrade if necessary.
Some stateless nodes and RPC enhancements
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 nodes do not store all state;
Allow multiple nodes to collaborate to provide complete state services;
Increase the diversity of RPC service providers and avoid single point bottlenecks.
These projects have been carefully selected for their immediate utility and forward-looking compatibility: they will both enhance the current health of Ethereum and lay the foundation for deeper protocol upgrades in the future.
