clet.xyz

Ethereum, once a nascent experimental network, has matured into a cornerstone of the global digital infrastructure. Billions of dollars in value are settled daily, thousands of applications are coordinated, and an entire ecosystem of Layer 2 (L2) scaling solutions is anchored to its robust foundation. At the heart of this complex and vital ecosystem lies a single, indispensable component: state. This article, a proposal from the Stateless Consensus team, explores the profound significance of Ethereum’s state, the challenges posed by its relentless growth, and the innovative directions being pursued to ensure the network’s continued scalability and decentralization. While this content represents a proposal, it does not necessarily imply consensus views across the Ethereum Foundation, an organization that champions a diverse range of opinions. Special acknowledgment is extended to Ladislaus von Daniels and Marius van der Wijden for their invaluable review of this article.

Understanding Ethereum’s State: The Network’s Collective Memory

To grasp the challenges and future trajectory of Ethereum, it is essential to understand what constitutes its "state." Contrary to common misconception, a user’s cryptocurrency balance is not stored within their wallet. Instead, these balances, along with all other account information, smart contract data, and bytecode, reside within Ethereum’s overarching state. The state can be broadly conceptualized as a snapshot of "everything Ethereum knows right now." It is the persistent ledger that records the current status of all accounts, smart contracts, and their associated data.

This state is the bedrock upon which almost every aspect of the Ethereum network operates. It underpins:

• Account Balances: The fundamental record of how much Ether and tokens each address holds.
• Smart Contract Storage: The data and variables that smart contracts utilize to function and maintain their internal logic.
• Contract Code: The executable bytecode of all deployed smart contracts, enabling their functionality.
• Network Parameters: Critical information that governs the operation of the Ethereum Virtual Machine (EVM) and consensus mechanisms.

Any degradation in the state’s integrity, size, or accessibility—whether it becomes too large, too centralized, or too difficult for nodes to serve—directly impacts the robustness, cost-effectiveness, and decentralization potential of all the layers built upon it, including L2 solutions and dApps.

The Double-Edged Sword of Layer 1 Scaling

Ethereum’s journey towards enhanced scalability has been a multi-year endeavor, marked by significant upgrades and innovations. These include the widespread adoption of L2 solutions, the implementation of EIP-4844 (Proto-Danksharding) to reduce transaction fees on L2s, increases in the gas limit to allow for more computation per block, gas repricing mechanisms, and the ongoing development of enshrined Proposer-Builder Separation (ePBS). While each of these advancements has enabled the network to process a greater volume of activity, they have also introduced new and complex challenges, primarily related to the management of the network’s state.

Challenge #1: The Ever-Expanding State

The state of Ethereum is characterized by a unidirectional growth pattern: it only increases. Every new account created, every storage slot written to, and every piece of bytecode deployed adds data that the network is obligated to retain indefinitely. This perpetual accumulation has tangible and significant costs.

The increase in state size directly translates to increased hardware requirements for running a full node. This includes demands on disk space, memory, and processing power. As these requirements escalate, the barrier to entry for individuals wishing to operate a full node rises, potentially leading to a less decentralized network where only those with substantial resources can participate.

The introduction of mechanisms like gas limit increases, while boosting transaction throughput, also amplifies state growth. This is because a higher gas limit permits more state-modifying operations within a single block. This phenomenon is not unique to Ethereum; other blockchain networks have already grappled with the implications of ballooning state sizes. As state grows, running a full node becomes increasingly unfeasible for average users, concentrating the responsibility of state storage and serving into the hands of a limited number of large infrastructure providers.

Currently, a significant portion of Ethereum blocks are already produced by sophisticated builders. A critical concern arising from state growth is the potential erosion of censorship resistance and credible neutrality. If only a select few entities possess the capacity to hold and efficiently serve the complete state, their ability to influence block inclusion becomes more pronounced. This scenario could lead to a situation where fewer parties are capable of constructing blocks that include transactions they might otherwise censor, undermining a core tenet of blockchain decentralization.

While efforts like EIP-7805 (FOCIL) and the VOPs (Validity-Only Partial Statelessness) initiative aim to preserve censorship resistance even within a framework of specialized builders, their efficacy remains contingent on a vibrant ecosystem of nodes capable of accessing, storing, and serving the state without prohibitive costs. Therefore, managing state growth is not merely an optimization; it is a foundational prerequisite for the network’s long-term health and decentralization.

The Stateless Consensus team is actively engaged in measuring and stress-testing the network to anticipate when state growth will become a critical issue. Data from the past year, as illustrated in Figure 1, shows the consistent addition of new state per week, highlighting the continuous nature of this challenge. Tools like bloatnet.info are being developed to provide real-time insights into these metrics.

Challenge #2: The Shifting Landscape of State Ownership and Service

The advent of "statelessness" in Ethereum signifies a paradigm shift where validators are no longer required to store the entire blockchain state to validate blocks. Instead, they can rely on cryptographic proofs to verify the validity of transactions. This is a pivotal development for scalability, enabling the network to meet the growing demand for higher throughput. Crucially, statelessness also formalizes a separation that was previously implicit: state storage can evolve into a specialized role, distinct from the validator’s function.

In a predominantly stateless world, the responsibility for storing the majority of the state is likely to fall upon a more concentrated group of entities, such as:

• Dedicated State Providers: Specialized services designed to store and serve the full Ethereum state.
• Archive Nodes: Nodes that maintain a complete historical record of the state, often for specific use cases.
• Infrastructure Providers: Large-scale operators of blockchain infrastructure.

This concentration inherently leads to increased centralization of state storage and serving. The implications of this are multifaceted:

• Increased Centralization Risk: A smaller number of entities holding the state increases the risk of collusion, censorship, or single points of failure.
• Potential for Censorship: If state access becomes controlled by a few, those entities could potentially censor transactions by refusing to serve necessary state data.
• Impact on L2s: The ability of L2 solutions to ensure users can force-include their transactions relies on reliable access to the rollup contract state on Layer 1. If L1 state access becomes fragile or highly centralized, these crucial safety mechanisms become more difficult to utilize in practice.

Furthermore, even with multiple entities storing state, there remains a challenge in reliably proving that they are actively serving it. While mechanisms like snap sync are widely supported, access to state data via RPC endpoints is not always universally available or performant. Without initiatives to make state serving more economical and attractive, the network’s ability to access its own history and current status could become concentrated in the hands of a limited number of providers.

Navigating the Future: Three Broad Directions for State Management

To address these pressing challenges, the Ethereum community is actively exploring several broad strategic directions for managing the network’s state. These approaches aim to mitigate state growth, reduce the burden on individual nodes, and ensure continued decentralization and accessibility.

State Expiry: Pruning the Inactive Past

A fundamental observation is that not all state data holds equal importance over time. Recent analysis suggests that a significant portion, approximately 80%, of Ethereum’s state has remained untouched for over a year. Yet, nodes are currently burdened with the perpetual cost of storing this inactive state. State expiry is a conceptual framework designed to address this by temporarily removing infrequently accessed state from the "active set" of data that nodes must maintain, while still allowing for its retrieval via proofs when needed.

Two primary categories of state expiry are being considered:

1. Mark, Expire, Revive: This approach involves marking rarely used state as inactive. Such state would no longer reside in the active set maintained by every node but could be revived if a user provides a proof of its prior existence. This ensures that frequently accessed contracts and balances remain readily available and inexpensive to access, while dormant state does not impose a burden on all nodes but can be reactivated if required.

2. Multi-Era Expiry: In this design, individual state entries are not expired. Instead, the state is periodically rolled into distinct "eras" (e.g., each era representing one year). The current era is fully active and accessible, while older eras are frozen for live execution. New state is then written into the current era. Accessing old state from previous eras would necessitate presenting proofs confirming its existence.

The "mark-expire-revive" method offers more granular control and potentially simpler revival processes, but it requires the storage of additional metadata. Conversely, multi-era expiry is conceptually simpler and aligns well with archival strategies, but the proofs for revival can be more complex and larger in size. Both approaches share the common objective of keeping the active state manageable by temporarily archiving inactive components, while preserving the ability to reinstate them. However, they differ in their trade-offs regarding complexity, user experience (UX), and the computational load placed on clients and infrastructure.

Further exploration of these concepts can be found in proposals such as EIP-3713 (State Expiry) and discussions within the Ethereum Magicians community.

State Archive: Separating the Hot from the Cold

The state archive approach fundamentally separates the "hot" (frequently accessed) state from the "cold" (infrequently accessed) state. This strategy acknowledges that while the total state of Ethereum will continue to grow, the portion requiring rapid access can be kept bounded.

In a state archive architecture, nodes would explicitly store recent, actively used state separately from older, less frequently accessed data. This distinction is crucial because it ensures that a node’s execution performance, particularly the Input/Output (I/O) costs associated with state access, can remain relatively stable over time. Without such a separation, performance would inevitably degrade as the blockchain ages and the total state expands indefinitely.

Making State Holding and Serving More Accessible

A pertinent question arises: can the network function effectively with less data being held by every participant? In other words, can nodes and wallets remain valuable components of the ecosystem without the obligation to store the full state indefinitely?

One promising avenue is partial statelessness. This involves developing nodes and wallets that can operate effectively by holding only a subset of the state or by relying on proofs for data they do not possess. This significantly reduces the resource requirements for participants, potentially democratizing node operation.

Another critical direction is to lower the barrier to entry for running useful infrastructure. This encompasses improving the efficiency of state synchronization, reducing the computational overhead for serving state data, and enhancing the reliability and performance of RPC endpoints. By making it easier and more economical for a wider range of entities to host and serve state, the network can foster a more decentralized and resilient infrastructure.

Detailed explorations of these ideas are available in resources such as "A Pragmatic Path Towards Validity-Only Partial Statelessness (VOPs)" and ongoing discussions on client development forums.

The Road Ahead: Charting Ethereum’s State Future

The management of Ethereum’s state lies at the nexus of some of the most critical questions shaping the protocol’s future. These include:

• Scalability: How can Ethereum handle exponentially increasing transaction volumes without compromising performance?
• Decentralization: How can the network ensure that a broad range of participants can run nodes and contribute to its security and operation?
• Accessibility: How can the cost and complexity of interacting with and maintaining the Ethereum network be reduced for users and developers?

While some of these questions remain open, the overarching direction is clear: to reduce state as a performance bottleneck, lower the cost of holding it, and make it easier to serve.

The current priorities of the Stateless Consensus team are focused on low-risk, high-reward initiatives that actively contribute to these goals. These include:

• Archive Solutions: Experimentation with out-of-protocol solutions that aim to keep the active state bounded by relying on archives for older data. These experiments will provide crucial real-world data on performance, UX, and operational complexity. Successful implementations may pave the way for in-protocol changes if deemed necessary.

• Partial Stateless Nodes and RPC Enhancements: Recognizing that most users and applications interact with Ethereum via centralized RPC providers, the team is working on improvements designed to:

  • Enhance the performance and reliability of RPC services.
  • Enable partial stateless nodes to function more effectively, reducing the state burden.
  • Develop more efficient methods for clients to access state data.

These projects are strategically chosen for their immediate utility and forward compatibility. They are designed to strengthen Ethereum’s health in the present while simultaneously laying the groundwork for more ambitious protocol upgrades in the future.

As this iterative process unfolds, progress updates and open questions will continue to be shared. However, addressing these complex challenges cannot be achieved in isolation. Developers of Ethereum clients, node operators, infrastructure providers, L2 builders, and all stakeholders invested in Ethereum’s long-term viability are encouraged to participate. By providing feedback on proposals, engaging in forum discussions and calls, and actively testing new approaches, the community can collectively shape a more scalable, decentralized, and resilient Ethereum.