Full nodes require full history. A canonical Ethereum node must store over 1.5TB of historical data to verify new blocks. This hardware requirement prices out individuals, centralizing node operation with professional data centers and infrastructure providers like Infura and Alchemy.
the-ethereum-roadmap-merge-surge-verge
Blog
Ethereum Storage and Decentralization Limits
An analysis of how Ethereum's growing state size creates a centralizing force, the technical roadmap to mitigate it (The Verge), and the fundamental trade-offs that remain.
introduction
THE STATE BLOAT
The Silent Centralizer: Ethereum's Storage Problem
Ethereum's requirement for full nodes to store the entire chain history creates a centralizing force that contradicts its decentralized ethos.
State growth is unbounded. Every new smart contract and NFT mint permanently expands the global state. Projects like EIP-4444 propose pruning historical data after one year, but this shifts trust to third-party data providers, creating a new decentralization bottleneck.
Rollups exacerbate the issue. Layer 2s like Arbitrum and Optimism post compressed transaction data to Ethereum as calldata, but this still contributes to the historical bloat. The upcoming EIP-4844 (Proto-Danksharding) introduces blob storage as a cheaper, ephemeral alternative, but node storage remains the ultimate constraint.
key-trends
ETHEREUM'S DATA CRISIS
The State of the State: Three Inconvenient Truths
Ethereum's security model is buckling under the weight of its own success, exposing fundamental limits in data availability and decentralization.
01
The Problem: Full Nodes Are an Endangered Species
Running a full node requires storing the entire chain state, a ~1.5 TB and growing requirement. This creates centralization pressure, as only well-resourced entities can participate in consensus validation.
- <1% of Ethereum nodes are archive nodes.
- Sync times can exceed 2 weeks, crippling network resilience.
- This creates a security bottleneck, concentrating trust in a few large providers like Infura and Alchemy.
1.5 TB+
State Size
<1%
Archive Nodes
02
The Solution: Statelessness & Verifiability
The endgame is a stateless client model, where nodes verify blocks without storing state. This relies on advanced cryptography like Verkle Trees and ZK-SNARKs to provide proofs of execution.
- Verkle Trees reduce witness sizes from ~200 KB to ~150 bytes.
- Enables lightweight validation, potentially on mobile devices.
- Shifts trust from data storage to cryptographic verification, a more scalable security primitive.
~150 B
Target Witness
1000x
Efficiency Gain
03
The Bridge: Modular Data Layers (EigenDA, Celestia, Avail)
While core protocol upgrades take years, modular data availability layers offer an immediate offload. Rollups can post data and proofs to these specialized chains, reducing Ethereum's blob burden.
- EigenDA offers 10 MB/s throughput at ~90% lower cost than Ethereum calldata.
- Celestia and Avail use data availability sampling for lightweight verification.
- This creates a multi-layered security model, but introduces new trust assumptions and bridging complexity.
10 MB/s
DA Throughput
-90%
Cost vs. ETH
DECENTRALIZATION'S HARD LIMIT
Ethereum State Growth: A Historical Snapshot
Historical growth of Ethereum's core state data, illustrating the scaling constraints of a full node's storage and sync requirements.
| State Metric | Genesis (2015) | Pre-Merge (2022) | Post-Dencun (2024) | Projected (2028) |
|---|---|---|---|---|
Full Node Storage (GB) | ~15 GB | ~1,200 GB | ~1,800 GB |
|
State Size (Accounts/Storage) | ~1.2M slots | ~260M slots | ~340M slots |
|
Archive Node Storage (TB) | < 0.1 TB | ~12 TB | ~18 TB |
|
Initial Sync Time (Days) | ~0.5 days | ~7-14 days | ~10-20 days |
|
Annual State Growth Rate | ~200% | ~40% | ~25% | ~30% (est.) |
Prunes Full History | ||||
Primary Growth Driver | Core Protocol | DeFi (Uniswap, Aave) | L2s & Restaking (Arbitrum, EigenLayer) | L2s & Account Abstraction |
deep-dive
THE DATA BOTTLENECK
The Verge: Ethereum's Bet on Statelessness
Ethereum's current storage model is the primary constraint on decentralization, forcing the Verge upgrade to pursue statelessness.
State growth is exponential. The Ethereum state—the database of all account balances and smart contract storage—grows with every transaction. This creates a hardware requirement spiral that pushes node operators to expensive, centralized cloud services, undermining the network's core value proposition.
Statelessness inverts the model. Instead of nodes storing the entire state, they verify proofs against a constant-sized commitment, like a Verkle tree root. Clients only need the data for the transactions they process, slashing storage needs from terabytes to kilobytes.
The bottleneck is proof size. Current Merkle proofs are too large for block propagation. The Verge's shift to Verkle trees and polynomial commitments (like KZG) creates smaller, constant-sized proofs, enabling lightweight stateless clients without sacrificing security.
Witness data becomes the new commodity. With statelessness, block builders must provide the 'witness' data (proofs) for each transaction. This creates a new specialized market for data availability, similar to roles filled by EigenLayer operators or Celestia validators in modular stacks.
risk-analysis
ETHEREUM'S SCALING PARADOX
The Unresolved Tensions & Bear Cases
Ethereum's security is its greatest asset and its most binding constraint, creating fundamental trade-offs for state growth and decentralization.
01
The State Bloat Problem
Ethereum's full state must be stored by every node, creating an unsustainable growth trajectory. This directly threatens decentralization by raising hardware requirements.
- State size grows by ~50-100 GB/year, pushing >1 TB total.
- Running a full archive node requires >12 TB SSD, costing >$1k/month in infrastructure.
- Solutions like Verkle Trees and EIP-4444 (history expiry) are multi-year projects.
>1 TB
Total State
$1k/mo
Node Cost
02
The Data Availability Bottleneck
Rollups are constrained by Ethereum's ~80 KB/sec data bandwidth (calldata), creating a hard cap on total L2 throughput and keeping fees volatile.
- At peak demand, >90% of a rollup's fee is for posting data to L1.
- Proto-Danksharding (EIP-4844) introduces blob space, increasing capacity to ~1.3 MB/sec.
- This is a stopgap; full Danksharding aims for ~1.3 MB/sec per slot, but requires years of development.
80 KB/s
Current Limit
~16x
Blob Gain
03
The Centralizing Force of MEV
Maximal Extractable Value creates economic incentives that centralize block production. Proposer-Builder Separation (PBS) is a theoretical fix with practical risks.
- Top 3 builders often control >60% of blocks, creating relay trust assumptions.
- Enshrined PBS is complex and may not arrive until post-Single Slot Finality.
- In the interim, MEV-Boost and private order flows cement the builder oligopoly.
>60%
Builder Share
2026+
E-PBS ETA
04
The L1 as a Settlement-Only Chain
The endgame vision of Ethereum as a pure settlement and data availability layer risks ceding economic activity and innovation to more agile, centralized L2s.
- L2 sequencers capture most transaction fees and user activity, creating value leakage.
- Inter-L2 bridging and composability remain fragmented challenges (see LayerZero, Across).
- Ethereum's security becomes a commoditized backend, potentially reducing its fee premium and staking yield attractiveness.
>90%
Txn on L2
High
Bridging Risk
future-outlook
THE STATE BLOAT PROBLEM
Beyond the Verge: The Permanent Storage Trade-Off
Ethereum's core decentralization is threatened by the unchecked growth of its historical state, forcing a fundamental choice between permanence and accessibility.
Ethereum's state is permanent bloat. The protocol's design mandates that all historical state, including defunct smart contract storage, persists forever on every full node. This creates an ever-increasing hardware burden that centralizes node operation to professional entities.
The Verge upgrade is not a solution. EIP-4444 and Verkle trees optimize future state storage and witness sizes. They do not address the existing petabyte-scale historical data already stored by nodes like Erigon and Nethermind.
The trade-off is explicit. The community must choose between absolute state permanence and network decentralization. Proposals like EIP-4444's historical expiry force old data to be served by decentralized p2p networks or services like Ethereum Attestation Service.
Evidence: Running an archive node today requires over 12 TB of SSD storage. Without pruning historical data, this cost will continue its parabolic rise, directly contradicting Ethereum's credibly neutral and permissionless ideals.
takeaways
ETHEREUM'S DATA LAYER
TL;DR for Protocol Architects
The base layer's storage model is a bottleneck for decentralization and scalability. Here's the landscape of constraints and emerging solutions.
01
The Problem: State Bloat is a Centralizing Force
Full nodes require >1 TB of SSD to sync, growing at ~50 GB/month. This creates prohibitive hardware costs, pushing validation to centralized providers like Infura and Alchemy. The network's security model weakens as the cost of running a node exceeds rational economic incentives.
>1 TB
Node Size
~50 GB/mo
Growth Rate
02
The Solution: Statelessness & State Expiry
Core protocol upgrades to fundamentally change the node requirement.\n- Verkle Trees: Enable stateless clients, requiring only a ~1 MB witness instead of full state.\n- EIP-4444: Executes state expiry, pruning historical data after ~1 year to cap growth.\n- Portal Network: A decentralized peer-to-peer network for serving expired historical data.
~1 MB
Witness Size
~1 Year
Expiry Window
03
The Workaround: Modular Data Layers
Offload data availability (DA) to specialized layers to reduce L1 burden. This is the core thesis behind rollups and EigenDA.\n- Celestia & Avail: Sovereign rollup DA layers with ~$0.001/MB costs.\n- EigenDA: Restaking-secured DA with ~$0.0001/MB projected costs.\n- EIP-4844 (Proto-Danksharding): Native L1 blob space for rollups, a ~10x cost reduction vs. calldata.
~100x
Cost Diff.
~10x
Blob Savings
04
The Trade-off: Data Availability vs. Security
Using an external DA layer introduces a new security assumption. You are trading Ethereum's consensus security for cost savings.\n- EigenDA: Security scales with Ethereum restaking TVL (~$20B).\n- Celestia: Relies on its own proof-of-stake validator set.\n- Design Choice: High-value dApps (e.g., Uniswap, Aave) will likely pay for L1 DA; high-throughput apps (social, gaming) will opt for modular DA.
$20B+
Restaking TVL
New Assumption
Security Model
05
The Reality: Historical Data is a Public Good
Even with state expiry, access to pruned history is essential for indexing, explorers, and fraud proofs. The Portal Network (Ethereum's DHT) and projects like Reth and Erigon aim to serve this data in a decentralized manner. This is a critical, often overlooked, piece of infrastructure for long-term verifiability.
P2P DHT
Portal Network
Essential
For Fraud Proofs
06
The Bottom Line: Design for the Multi-DA Future
Architects must now explicitly choose a data availability layer. Your stack is no longer just L1 vs. L2.\n- Interoperability: Use EigenDA for cost, fall back to Ethereum for security.\n- Tooling: Ensure clients (e.g., OP Stack, Arbitrum Nitro) support configurable DA.\n- Cost Model: Factor blob gas and external DA pricing into your protocol's economic design.
Configurable
DA Stack
Explicit Choice
Architectural
ENQUIRY
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.
NDA Protected
Confidentiality24h Response
Time to ValueDirectly to Engineering Team
No Sales Fluff10+
Protocols Shipped
$20M+
TVL Overall