The journey of Ethereum scaling has been marked by significant pivots, none more impactful than the shift from a complex, multi-layered sharding system to a streamlined, rollup-centric roadmap. This transformation, moving from traditional "blocks" to the novel concept of "blobs," represents a fundamental rethinking of how to scale the world’s leading smart contract platform without compromising its security or decentralization.
A Brief History of Sharding Designs
Ethereum's initial scaling vision, often referred to as "Serenity," was structured in phases. Sharding, or "Phase 1," was originally intended to precede "Phase 2," which involved the introduction of execution environments on the Beacon Chain. However, a clear priority emerged: the mainnet Ethereum Virtual Machine (EVM) demanded precedence, and the development of a "Phase 2" execution layer (potentially based on eWasm) was perpetually delayed.
The specifications for Phase 1 underwent numerous rewrites even before the Beacon Chain launched. Key changes included:
- A reduction in the number of planned shards, from 1024 to 64.
- Designs for ideal cross-shard communication (crosslinks) to enable seamless interoperability.
- A new custody proof design that moved away from frequent verification to rare, intentional proof-of-custody losses.
Early sharding research was incredibly ambitious, exploring complex concepts like cross-domain message passing, eWasm-based execution environments, statelessness with dynamic state access, and shard committees. While intellectually fascinating, these concepts threatened to add immense complexity to the already challenging task of building and securing the base layer (L1), which was beginning to solidify.
The Pivot to a Rollup-Centric Future
A crucial insight changed everything: if L1 could focus exclusively on solving the data availability problem, most other complexities could be offloaded to Layer 2 (L2) developers. Data availability sampling (DAS) emerged as the elegant solution to the L1 data problem. This new direction was crystallized by Vitalik Buterin in late 2020 with the publication of "A Rollup-Centric Ethereum Roadmap."
This roadmap proposed a fundamental shift:
- Simplify L1: Reduce base layer complexity. The Beacon Chain was already complex enough.
- Scale with Data: Increase scalability primarily by providing massive amounts of cheap, available data.
- Embrace L2: Encourage innovation and scaling on Layer 2 through rollups, which would utilize this cheap L1 data for security.
The role of L1 would no longer be to execute all transactions itself but to become a robust data and settlement layer, securing a vibrant ecosystem of L2 rollups.
The Birth of the "Blob"
With the new direction set, researchers like Vitalik Buterin and Dankrad Feist began working on early designs for data availability. A key terminological shift occurred during this period. The concept of a "shard data blob" emerged, eventually shortened to just "blob."
This was more than just a name change. It signified a move away from the idea of independent "shard chains" with their own blocks and metadata. Instead, "blobs" would be simple, large packets of data attached to Beacon Chain blocks, their sole purpose being to carry data for L2s. The ecosystem lovingly dubbed this new data space "blobspace."
The design evolved throughout 2021, initially considering complex structures involving separate blob-builders and blob-proposers. However, the philosophy of minimalism prevailed. The design was simplified to be "beacon-proposer-centric," making it primarily a networking challenge rather than a deep consensus-level change. This was arguably the fifth major iteration of sharding design, and its simplicity was its strength.
The Path to Proto-Danksharding: EIP-4844
By early 2022, urgency was growing. The high cost of calldata on Ethereum was making L2s less competitive. Short-term solutions like EIP-4488 were discussed, but these were seen as unsustainable, as calldata carried legacy overhead that L2s didn't need.
The answer was the new sharding design, now known as danksharding. To reach the full vision incrementally, Vitalik proposed a two-path approach, leading to the development of EIP-4844, or proto-danksharding. This EIP, a collaborative effort by client teams and researchers, implemented the foundational components for full danksharding:
- Introducing the transaction format that carries blobs.
- Implementing the consensus rules for validating blob data.
- Laying the groundwork for the peer-to-peer networking of blobs.
Proto-danksharding doesn't include data availability sampling yet; that is reserved for the full danksharding upgrade. However, it delivers the core feature: cheap, abundant data for L2 rollups by introducing blobspace. 👉 Explore the latest scaling strategies
The Future: Full Danksharding and Beyond
Proto-danksharding is the crucial first step. The full danksharding upgrade will introduce data availability sampling, enabling the network to securely validate that blob data is available without any single node needing to download it entirely. This will unlock even greater data capacity for the ecosystem.
Several key insights are guiding this future development:
- L1 Inclusion Latency: The impact of L1 data inclusion latency on L2 performance is often overestimated. The trade-offs for more bandwidth are considered worthwhile.
- Networking: Gossip and TCP DHTs are insufficient for the task. Robust UDP-based DHT overlays are preferred, which also ties into the need for future discv5 extensions to support light nodes.
- Peer-to-Peer Robustness: Sampling relies on good peer connections, necessitating robust, score-first peer selection designs.
- Privacy and Sybil Resistance: The design prefers lightweight communication, even with less Sybil resistance, over compromises to validator privacy on the p2p layer. Future ZK-based solutions could enhance Sybil resistance.
Frequently Asked Questions
Q: What is the main difference between the old sharding and the new danksharding vision?
A: The old vision involved multiple parallel chains ("shard chains") executing transactions. The new, danksharding vision simplifies L1 to be a data availability platform. Execution is delegated to Layer 2 rollups, which post their data to L1 as "blobs" for security.
Q: What is a "blob" in Ethereum?
A: A blob is a large packet of data (~128 KB) attached to a Beacon Chain block. It is much cheaper than similar calldata and is designed specifically for Layer 2 rollups to post their transaction data securely onto Layer 1.
Q: What is the purpose of EIP-4844 (Proto-Danksharding)?
A: EIP-4844 introduces the scaffolding for full danksharding. It implements the transaction type for blobs and the consensus logic for their validation, immediately providing cheaper data for L2s while paving the way for the full data availability sampling upgrade later.
Q: When will full danksharding with data availability sampling be implemented?
A: There is no official timeline. Full danksharding is a significant upgrade that requires extensive research, development, and testing. It will likely follow the successful deployment and stabilization of proto-danksharding on the mainnet.
Q: How do blobs benefit the average user?
A: Blobs provide L2 rollups with drastically cheaper data storage on Ethereum L1. This reduction in cost allows L2s to lower their transaction fees, making activities like trading, minting NFTs, and using dapps much more affordable for end-users.
Q: Will danksharding make Ethereum more decentralized?
A: Yes, that's the goal. By employing data availability sampling, full danksharding will allow even light clients with minimal resources to verify that all data in a block is available. This strengthens the network's decentralization and security. 👉 View real-time network tools