Disclaimer: The following analysis is a proposal from the Stateless Consensus team. It’s crucial to understand that content presented here may not represent a universal consensus view, as the Ethereum Foundation is a diverse organization that fosters a healthy array of opinions across its Protocol and broader ecosystem, all contributing to Ethereum’s strength. Special thanks to Ladislaus von Daniels and Marius van der Wijden for their valuable review of this article.
Main Facts: The Unseen Foundation and Its Mounting Pressure
Ethereum, once a nascent experimental network, has rapidly matured into a critical pillar of global digital infrastructure. Each day, it facilitates the settlement of billions of dollars in value, orchestrates thousands of decentralized applications (dApps), and serves as the foundational anchor for an entire ecosystem of Layer 2 (L2) scaling solutions. Yet, at the heart of this sprawling and dynamic network lies a single, often-overlooked component: state.
The state can be broadly understood as "everything Ethereum knows right now" – a comprehensive, real-time snapshot of the blockchain’s entire history and current configuration. It’s a living, evolving ledger that records:
- The balance of every account.
- The code of every smart contract deployed.
- The storage variables and data held within those contracts.
- The nonces of every account (ensuring transaction order).
A user’s Ether balance, for instance, isn’t physically stored in their digital wallet; it resides as an entry within Ethereum’s global state. This state underpins virtually every interaction and layer of the network, from the execution of smart contracts on Layer 1 (L1) to the security assurances provided to L2s, and the very functionality of dApps, wallets, and blockchain explorers.
However, this foundational component is facing an existential challenge. If the Ethereum state becomes excessively large, increasingly centralized in its storage, or too difficult for network participants to access and serve efficiently, the entire decentralized edifice risks becoming more fragile, more expensive, and ultimately, less robustly decentralized. This growing burden poses fundamental questions for Ethereum’s long-term health and its core principles of censorship resistance and credible neutrality.
Chronology: Ethereum’s Scaling Journey and Its Unintended Consequences
Ethereum’s journey has been defined by an ambitious multi-year roadmap aimed at enhancing its scalability and throughput. Significant milestones include the pivot towards a rollup-centric strategy with the advent of L2s, the implementation of EIP-4844 (proto-danksharding) to reduce data availability costs, strategic gas limit increases, dynamic gas repricing mechanisms, and the eventual enshrined Proposer-Builder Separation (ePBS) to mitigate Maximal Extractable Value (MEV) concerns.
Each of these advancements has been crucial in allowing the network to handle more activity, reduce transaction costs, and expand its utility. Yet, they introduce a complex paradox: while designed to scale the network, they inadvertently amplify the problem of state growth. More activity, more transactions, and more data availability inevitably lead to a larger, more complex state that the network must maintain.
Supporting Data & Implications: The Unrelenting Growth of State
The Ethereum state size, by its very nature, only moves in one direction: up. Every new account creation, every smart contract deployment, and every storage write adds permanent data that the network is committed to preserving indefinitely. This constant accretion incurs concrete and escalating costs for those operating the network’s foundational infrastructure:
- Storage Costs: Full nodes require increasingly larger and faster storage devices, translating to higher hardware expenses.
- I/O Performance: Accessing and writing to a burgeoning database significantly degrades input/output (I/O) performance, slowing down block processing, initial synchronization times for new nodes, and overall network responsiveness.
- Network Bandwidth: A larger state means more data must be transmitted and synchronized across the peer-to-peer network, straining bandwidth resources.
- CPU Demands: Verifying state transitions and executing transactions on a larger state tree requires more computational power, adding to CPU overhead.
As illustrated by Figure 1 (based on EIP-8037 data), the rate at which new state is added each week demonstrates this relentless expansion. The "bloatnet.info" initiative actively monitors and stress-tests these metrics to understand the current and projected impact.
The most significant implication of this unchecked growth is centralization. As state sizes balloon, running a full node becomes an increasingly resource-intensive and expensive undertaking, pushing it beyond the reach of average users. This inevitably concentrates the responsibility of holding and serving the full state into the hands of a few large, professional infrastructure providers.
This centralization has profound consequences for Ethereum’s core values:
- Censorship Resistance: If only a small, sophisticated set of actors can afford to run full nodes and build blocks end-to-end, the network’s ability to resist censorship is compromised. Fewer independent parties mean a greater potential for collusive behavior to exclude specific transactions or users.
- Credible Neutrality: A network where access to foundational state information is controlled by a few large entities risks losing its credible neutrality, potentially leading to unfair advantages or biases in transaction inclusion.
While mechanisms like FOCIL (Forced Transaction Inclusion List) and VOPS (Validity-Only Partial Statelessness) aim to preserve censorship resistance in a world with specialized builders, their effectiveness hinges on the existence of a healthy, diverse ecosystem of nodes capable of accessing, holding, and serving the state without prohibitive costs. Keeping state growth under control is, therefore, not merely an optimization but a fundamental prerequisite for maintaining Ethereum’s decentralized ethos.
Official Responses: Navigating Statelessness and State Management
Even if Ethereum’s gas limit were to remain static, the network would eventually face insurmountable state growth issues. The community’s clear demand for higher transaction throughput necessitates a shift towards statelessness. This paradigm-altering change allows validators to verify blocks by simply checking cryptographic proofs, rather than needing to store the entire network state locally. This is a monumental scalability win, unlocking the potential for significantly higher transaction volumes.
However, this transition makes explicit what was once implicit: state storage will become a separate, more specialized role no longer tied to every validator. In a largely stateless world, the full network state is likely to be stored and served primarily by:
- Large, centralized infrastructure providers (e.g., RPC providers like Infura, Alchemy).
- Sophisticated block builders and relayers within the MEV supply chain.
- Potentially, specialized data archiving services.
This leads to the uncomfortable reality that much of the state could become more centralized, presenting its own set of challenges:
- Increased Fragility: Relying on a limited number of state providers creates single points of failure, making the network more vulnerable to outages or attacks.
- Higher Costs: Users and L2s might face increased costs to access state from centralized providers, as these services will need to cover their significant infrastructure expenses.
- Censorship Vectors: Centralized state providers could become choke points, enabling selective denial of service or transaction censorship.
- L2 Security Implications: The ability for L2 users to "force-include" transactions onto L1 (a critical safety valve for rollup security) depends on reliable access to the L1 rollup contract state. If L1 state access becomes fragile or highly centralized, these safety mechanisms become much harder to utilize in practice.
Furthermore, there’s a current lack of clear protocol-level incentives or mechanisms to ensure that entities storing the state are reliably serving it. While services like Snap Sync are widely supported, general RPC access to historical or less-used state is not guaranteed. Without making state serving cheaper and more attractive, the network’s overall ability to access its own data risks being concentrated in the hands of a few.
To address these multifaceted challenges, the Stateless Consensus team identifies three broad directions for future development:
1. State Expiry
State expiry is a conceptual framework designed to manage the ever-growing state by intelligently distinguishing between "hot" (active) and "cold" (inactive) data. Recent analysis has shown that approximately 80% of the Ethereum state has remained untouched for over a year, yet every full node still bears the cost of permanently storing this inactive data. State expiry aims to temporarily remove such inactive state from the "active set" that nodes must maintain, requiring a specific proof to bring it back when needed.
Two primary categories of state expiry are being explored:
- Mark, Expire, Revive: In this model, the protocol would identify and "mark" rarely used state entries as inactive. These entries would then be removed from the active set that every node maintains. However, they could be "revived" and brought back into active use if a user or contract provides a cryptographic proof demonstrating its prior existence and validity. This approach keeps the frequently accessed contracts and balances "hot" and cheap to access, while reducing the burden of storing long-forgotten data on every node. It tends to be more fine-grained, simplifying the revival process, but necessitates storing additional metadata to track inactive state.
- Multi-era Expiry: This design proposes periodically "rolling" the state into distinct "eras" (e.g., annually). The current era would remain small and fully active, while older eras would be effectively frozen from the perspective of live execution. New state would exclusively be written into the current era. To interact with or revive data from an older era, proofs would be required to demonstrate its existence and state within that specific historical context. This approach is conceptually simpler and aligns well with archiving strategies, though the revival proofs for older eras can be more complex and larger.
Both categories share the overarching goal of bounding the active state size by temporarily removing inactive components, while still providing robust mechanisms for their retrieval. They present different trade-offs in terms of implementation complexity, user experience, and the computational burden placed on clients and broader infrastructure.
2. State Archive
State archiving is a complementary approach that explicitly separates the "hot" and "cold" portions of the state.
- Hot State: This refers to the recent, frequently accessed state data that is critical for real-time transaction processing and immediate dApp interactions.
- Cold State: This encompasses older, less frequently accessed historical data that, while still part of Ethereum’s immutable ledger, isn’t required for immediate operational needs.
In a state archive design, nodes are configured to explicitly store and manage these two categories of data separately. Even as the total cumulative state continues its inevitable growth, the "hot set" – the portion requiring fast access – can remain bounded in size. This crucial distinction ensures that the execution performance of a node, particularly the I/O costs associated with accessing state, can remain relatively stable over time, rather than degrading proportionally with the chain’s age. This method helps preserve node efficiency and maintain a responsive network even as the blockchain matures.
3. Making it Easier to Hold and Serve State
Beyond managing the state itself, a vital direction involves making it inherently easier for various participants to hold and serve state information, even if they don’t store the full, historical state. The core question here is: can we design nodes and wallets that remain useful and contribute to decentralization without needing to store the full state indefinitely?
One promising avenue is partial statelessness:
- Client-Specific State: Individual clients (or light clients) could be designed to store only the subset of state relevant to their specific accounts, contracts, or interests, rather than the entire global state. This would significantly reduce their storage and processing requirements.
- Specialized State Providers: The ecosystem could evolve to include specialized entities or services dedicated solely to storing and serving specific portions of the state on demand, perhaps leveraging technologies like Verkle Trees for efficient proof generation.
Another critical direction involves lowering the barrier to running useful infrastructure:
- Enhanced Light Clients: Developing more robust and feature-rich light clients that can reliably verify transactions and interact with the network without downloading the entire blockchain state.
- Distributed RPC Networks: Fostering the growth of decentralized RPC (Remote Procedure Call) networks that distribute the burden of state serving across many participants, reducing reliance on centralized providers.
- Incentive Layers for State Serving: Introducing economic incentives within the protocol to reward entities for reliably storing and serving state data. This could transform state provision from an unrewarded burden into a sustainable service.
These efforts are vital for democratizing participation, enabling a broader array of individuals and smaller entities to contribute to the network’s health without facing prohibitive hardware or operational costs.
What’s Next? Paving the Road Ahead
Ethereum’s state management stands quietly at the nexus of some of the most profound questions facing the protocol’s future: how to balance scalability with decentralization, how to ensure censorship resistance in a high-throughput environment, and how to maintain credible neutrality as the network evolves.
While some of these questions remain open and subject to ongoing research, the overarching direction is clear: reduce state as a performance bottleneck, lower the cost of holding it, and make it easier for a diverse set of participants to serve it.
The immediate priorities of the Stateless Consensus team are focused on low-risk, high-reward initiatives that provide tangible benefits today while paving the way for future protocol enhancements:
- Archive Solutions (Out-of-Protocol First): The team is actively experimenting with solutions that can manage active state within current protocol constraints, relying on external archiving for older data. This pragmatic approach will yield invaluable real-world data on performance, user experience, and operational complexity. If these out-of-protocol solutions prove successful and necessary, they could inform and eventually be integrated into in-protocol changes.
- Partial Stateless Nodes and RPC Enhancements: Recognizing that most users and dApps interact with Ethereum via centralized RPC providers, efforts are underway to:
- Optimize RPC services to reduce their load and improve data access efficiency.
- Enhance the capabilities of light clients and partial stateless nodes to empower more users to interact directly with the network without relying entirely on large providers.
- Improve the underlying mechanisms for generating and verifying proofs, which are fundamental to enabling partial statelessness.
These projects are deliberately chosen for their immediate utility and forward-compatibility. They are designed to make Ethereum healthier and more resilient today, while simultaneously laying crucial groundwork for more ambitious, protocol-level changes down the line.
The challenges of state growth and management are complex, requiring collaborative effort across the entire Ethereum ecosystem. As the Stateless Consensus team iterates and refines its approaches, it commits to transparently sharing its progress and open questions. This is not a task to be solved in isolation. Client developers, node operators, infrastructure providers, L2 builders, and anyone invested in Ethereum’s long-term health are invited to get involved: share feedback on proposals, join the ongoing discussions on forums and community calls, and help test new approaches in practice. Only through collective dedication can Ethereum successfully navigate this silent challenge and secure its decentralized future.
