TLDR:

• Ethereum state grows 100 GB yearly; 20x scaling would create 8 TB state in four years for builders. 
• Strong statelessness and state expiry solutions face backwards compatibility issues with existing apps. 
• New temporary storage resets monthly while UTXO systems enable zero-duration expiry for cost savings. 
• Developers can keep using permanent storage initially, then migrate to cheaper tiers over time gradually. 

Ethereum co-founder Vitalik Buterin has unveiled a comprehensive proposal to address state scaling challenges on the network.

The plan introduces new forms of state storage alongside existing mechanisms to achieve 1000x scalability. Posted on February 5, Buterin’s proposal acknowledges that while Ethereum has clear pathways for scaling execution and data, state scaling remains fundamentally different and requires innovative solutions.

Asymmetric Scaling Challenge Creates Need for Alternative Approach

Buterin outlined in his post on X that Ethereum faces different scaling realities across three critical resources. “We want 1000x scale on Ethereum L1. We roughly know how to do this for execution and data. But scaling state is fundamentally harder,” he stated.

Execution can achieve 1000x gains through ZK-EVMs, while data scaling reaches similar levels via PeerDAS technology. However, state scaling lacks such breakthrough solutions.

Current state grows at 100 GB annually, and a 20x increase would create 2 TB yearly growth. After four years, this results in 8 TB total state size that builders must maintain.

The proposal explains that database efficiency and syncing present major obstacles. Modern client databases struggle with multi-terabyte states because writes require logarithmic tree updates.

Buterin emphasized that state differs fundamentally from computation and data. Builders need complete state to construct any block, regardless of gas limits.

This reality demands conservative scaling approaches and eliminates many sharding techniques that work for other resources. The network cannot rely on professional builders alone, as permissionless block building requires reasonable setup costs.

Strong Statelessness and Expiry Mechanisms Face Compatibility Issues

The post analyzed why previously proposed solutions fall short of requirements. Strong statelessness would require users to specify accessed accounts and storage slots while providing Merkle proofs.

This approach creates three major problems: dependency on off-chain infrastructure, backwards incompatibility with dynamic storage access patterns, and increased bandwidth costs reaching 4 KB per simple ERC20 transfer.

State expiry designs also encounter fundamental obstacles. Creating new accounts requires proving nothing existed at that address throughout Ethereum’s entire history.

Repeated regenesis schemes demand N lookups for account creation in year N. Address period mechanisms attempt mitigation but break compatibility with existing ERC20 contracts that use opaque storage slot generation.

Buterin noted these explorations reveal important patterns. “Replacing all state accesses with Merkle branches is too much, replacing exceptional-case state accesses with Merkle branches is acceptable,” he explained.

The analysis points toward tiered state systems that distinguish high-value frequently accessed state from lower-value rarely accessed state. However, backwards compatibility proves extremely difficult since lower tiers cannot support dynamic synchronous calls at all.

New Storage Types Enable Developer Choice Between Cost and Flexibility

The proposal introduces temporary storage that resets monthly and UTXO-based systems as primary solutions. Buterin described his vision: “The most practical path for Ethereum may actually be to scale existing state only a medium amount, and at the same time introduce newer forms of state that would be extremely cheap but also more restrictive.”

Temporary storage suits throwaway state for auctions, governance votes, and game events. ERC20 balances could use resurrection mechanisms with bitfields tracking historical state usage.

This design would support 8 TB of temporary state monthly with only 16 GB permanent storage for tracking. UTXO systems take expiry to its logical extreme with zero-duration periods.

Buterin envisions user accounts and smart contract code remaining in permanent storage for accessibility. NFTs and token balances would migrate to UTXOs or temporary storage, while short-term event state uses temporary mechanisms.

Core DeFi contracts would stay permanent for composability, but individual positions like CDPs could move to cheaper tiers. Developers can initially use permanent storage exclusively, then optimize over time as the ecosystem adapts.