The rapidly growing demand for storage presents significant challenges for Ethereum nodes.
Authored by: EthStorage
Executive Summary
- Surging storage requirements pose substantial challenges for Ethereum nodes.
- Due to storage limitations, some clients have begun pruning historical data, leading to inconsistencies across full nodes.
- Standardization of historical data pruning is underway via EIP-4444 and EIP-4844.
- Recovering the latest L1/L2 state via historical replay now relies on centralized off-protocol services, sparking interest in decentralized alternatives.
- Ethereum Portal Network: A lightweight, decentralized P2P network for all Ethereum data types, designed for resource-constrained devices. Its historical and beacon chain networks are near-ready.
- EthStorage Network: An incentivized modular storage network for EIP-4844 BLOBs, currently operational on Sepolia testnet with community participation.
- Future goals include decentralized state networks, dynamic-sized data proofs, and browser-native decentralized access.
Background
On October 22, 2023, Péter Szilágyi, lead developer of Go-Ethereum (Geth), highlighted concerns over inconsistent data retention policies across Ethereum clients (e.g., Nethermind, Besu). This ignited debates on Ethereum’s storage roadmap.
Storage Challenges
Key Issues:
Escalating Storage Demands:
- Geth nodes require ~925 GB (628 GB for historical data; 269 GB for state data).
- Other clients reduce costs to ~300 GB by pruning history.
Lack of Protocol Incentives:
- No rewards/punishments for storing history, leading to altruism-dependent retention.
Upcoming DA Upgrades:
- EIP-4844 introduces 128 KB BLOBs, with future scaling to 256 BLOBs/block (~80 TB/year). Most nodes cannot handle this volume.
Ethereum Storage Roadmap
Proposals:
- EIP-4444: Allows pruning historical data >1 year old (~250 GB cap).
- EIP-4844: Discards BLOBs older than 18 days (~100 GB cap).
Consequences:
- New nodes cannot perform "full sync" and must rely on "snap sync," violating L2 security assumptions.
- L2s depend on centralized third parties (Infura, Etherscan) for historical data.
Core Questions:
- Can we achieve decentralized, protocol-incentivized storage solutions?
- How can Ethereum-native access be improved?
Solutions
1. Ethereum Portal Network
- Decentralized P2P Network: Lightweight JSON-RPC services via DHT (similar to IPFS but Ethereum-specific).
- Resource Efficiency: Runs on devices with minimal storage (e.g., Raspberry Pi).
- Current Status: Beacon/historical networks live; state network in development.
- Limitation: No direct storage incentives.
👉 Explore Ethereum’s lightweight Portal Network
2. EthStorage Network
- Incentivized BLOB Storage: Chain-linked proofs reward nodes for storing EIP-4844 data.
Key Features:
- 1/m trust model (no bridges).
- Dynamic fee allocation aligns costs with contributions.
- SNARK-powered proofs for efficiency.
- Testnet: Operational on Sepolia with 100+ participants.
- Limitation: Optimized for fixed-size BLOBs.
👉 Learn about EthStorage’s modular architecture
Future Developments
- Decentralized State Networks: Low-latency access to Ethereum state data.
- Portal-EthStorage Integration: Unified JSON-RPC for programmable BLOB access.
- Browser-Native Access:
web3://protocol (ERC-4804/6860) for direct dApp interactions. - Advanced Proofs: Support for dynamic-sized data (e.g., historical blocks).
FAQs
Q1: Why prune historical data?
A: To reduce node storage costs and standardize client behavior. EIP-4444/4844 formalize pruning rules.
Q2: How does EthStorage incentivize nodes?
A: Fees from put() calls are gradually distributed to nodes submitting valid storage proofs.
Q3: Can smartphones join the Portal Network?
A: Yes! Its lightweight design supports resource-constrained devices.
Q4: What’s the future of Ethereum storage?
A: Integration of decentralized networks, browser-native access, and scalable proofs for dynamic data.