The dream of Ethereum becoming a true "world computer" hinges on solving one of the most persistent challenges in blockchain: the blockchain trilemma—the idea that a decentralized network cannot simultaneously achieve decentralization, security, and scalability. For years, this trilemma has limited blockchain adoption. But with the introduction of Danksharding and its foundational upgrade, EIP-4844 (Proto-Danksharding), Ethereum may finally have a viable path forward.
This article breaks down these complex concepts in plain language, making them accessible even to Web3 beginners. We'll explore how Ethereum plans to scale securely without sacrificing its core principles—and why this could redefine the future of public blockchains.
Why Does Ethereum Need Scaling?
Since its inception in 2014, Ethereum has evolved from a simple smart contract platform into the backbone of decentralized applications (DApps), powering innovations like DeFi, NFTs, and GameFi. But as adoption surged, so did performance bottlenecks.
The Scaling Challenge
Imagine a highway during rush hour. If too many cars enter at once, traffic slows down. In blockchain terms, when too many users interact with Ethereum simultaneously, the network becomes congested. Transactions take longer to confirm, and users compete by increasing their gas fees—essentially tipping validators to prioritize their transactions.
One infamous example was the 2017 CryptoKitties craze, which clogged the network and drove gas fees into the hundreds of dollars per transaction. This wasn’t an anomaly—it highlighted a systemic issue.
Ethereum’s current throughput is limited:
- Blocks are produced every 12 seconds.
- Each block has a gas limit of 30 million, with a target of 15 million.
- On average, blocks contain 160–300 transactions, translating to roughly 13–45 transactions per second (TPS).
Compare that to Visa’s tens of thousands of TPS, and it’s clear: Ethereum must scale to fulfill its vision.
👉 Discover how next-gen blockchain scaling can unlock new possibilities in decentralized finance.
The Blockchain Trilemma: Decentralization vs. Security vs. Scalability
The blockchain trilemma posits that public blockchains can only optimize two out of three key properties:
- Decentralization: The degree to which control is distributed across independent nodes.
- Security: Resistance to attacks, ensured by high consensus costs.
- Scalability: The ability to process large volumes of transactions efficiently.
Ethereum prioritizes decentralization and security, meaning any scaling solution must not compromise node accessibility. If running a node becomes too resource-intensive, fewer people will participate—leading to centralization.
Thus, the challenge is clear: scale without raising barriers for validators.
Current Ethereum Scaling Solutions
To address scalability, Ethereum has pursued two main strategies: Layer 2 (L2) rollups and sharding.
Layer 2 Rollups
Rollups execute transactions off-chain and post compressed data back to Ethereum (Layer 1), inheriting its security while reducing costs. There are two primary types:
- Optimistic Rollups: Assume transactions are valid by default, allowing a challenge period (typically one week) for fraud proofs.
- ZK Rollups: Use zero-knowledge proofs to mathematically verify transaction validity instantly, offering faster withdrawals and higher efficiency.
While rollups improve scalability, they still rely on Ethereum’s base layer for data availability—a bottleneck that limits their full potential.
Sharding: Scaling at the Base Layer
Sharding aims to increase Ethereum’s on-chain capacity directly. Unlike earlier sharding designs, the new approach—Danksharding—is built around L2 rollups, creating a synergistic ecosystem where Ethereum becomes a highly scalable data availability layer.
But before diving into Danksharding, let’s examine why the original sharding plan was abandoned.
The Original Sharding Plan: Sharding 1.0
Initially, Ethereum proposed splitting the network into up to 64 parallel chains (shards), each handling separate transactions and coordinating through the Beacon Chain via crosslinks.
However, Sharding 1.0 faced critical issues:
1. Technical Complexity
Building and maintaining 64 interoperable chains introduced immense development overhead and increased the risk of bugs or failures.
2. Data Synchronization Overhead
Validators were randomly reassigned to different shards every epoch (~6.4 minutes). This required constant syncing of shard data—challenging for nodes with limited bandwidth.
3. Storage Bloat
Each shard generated its own data stream, exponentially increasing long-term storage demands for full nodes—threatening decentralization.
4. MEV Amplification
Maximum Extractable Value (MEV)—profit gained by reordering or censoring transactions—was not addressed. High MEV incentivizes validator centralization, as well-resourced entities dominate block production.
These limitations led researchers to rethink the entire sharding paradigm—giving rise to Danksharding.
Introducing Danksharding: A New Vision for Scalability
Proposed by Ethereum researcher Dankrad Feist in late 2021, Danksharding reimagines sharding not as multiple chains, but as a unified data availability layer optimized for rollups. It introduces several groundbreaking technologies:
- Blob-carrying transactions (EIP-4844)
- Data Availability Sampling (DAS)
- Erasure coding
- KZG commitments
- Proposer-Builder Separation (PBS)
Let’s break them down.
EIP-4844: Proto-Danksharding – The Foundation
EIP-4844, also known as Proto-Danksharding, lays the groundwork by introducing a new transaction type: blob-carrying transactions.
What Are Blobs?
Blobs are large data containers (~128 KB each) attached to blocks:
- Each block can carry up to 16 blobs (2 MB total).
- Blob data is stored temporarily (~30 days), then pruned.
- Unlike regular transaction data, blobs don’t execute code—they only store data.
This design offers massive benefits:
- Current average block size: ~85 KB
- Additional blob space per block: up to 2 MB
- Annual blob data volume: ~2.5–5 TB—several times larger than Ethereum’s entire historical state
Crucially, because blobs are temporary, they don’t burden nodes with permanent storage growth—making scalability sustainable.
👉 See how emerging blockchain upgrades are reshaping digital asset ecosystems.
Why Blobs Matter for Rollups
Rollups currently post all transaction data on-chain as calldata, consuming expensive block space. With blobs:
- Data is cheaper to post
- More transactions fit per block
- L2 fees drop significantly
This makes EIP-4844 a game-changer for rollup-based scaling—even before full Danksharding launches.
FAQ: What Happens When Blob Data Is Deleted?
Ethereum isn’t designed for permanent data storage. Instead, it acts as a secure bulletin board:
- Data must remain available long enough for interested parties (e.g., L2 operators, storage protocols) to retrieve and archive it.
- After deletion, historical data can be sourced from decentralized storage layers like IPFS or Arweave.
Full Danksharding: Scaling to 16–32 MB Per Block
While EIP-4844 supports up to 2 MB of blob data per block, full Danksharding will expand this to 16–32 MB, enabling Ethereum to support hundreds of thousands of TPS across rollups.
But such massive data increases pose two major risks:
- Node overload from downloading and storing huge datasets
- Data availability attacks, where malicious proposers hide parts of the data
Danksharding solves both with Data Availability Sampling (DAS).
Data Availability Sampling (DAS): Verify Without Downloading
Instead of requiring every node to download all blob data, DAS allows nodes to randomly sample small portions of the data and verify its availability statistically.
Here’s how it works:
- A blob is split into hundreds of fragments.
- Each node downloads only a few random fragments.
- If enough samples are confirmed across the network, the system assumes the full data is available.
This drastically reduces bandwidth requirements while preserving security—so long as there are enough honest nodes participating.
To make DAS robust, Danksharding uses two cryptographic tools: erasure coding and KZG commitments.
Erasure Coding: Reconstruct Data from Partial Fragments
Erasure coding ensures that even if some data fragments are missing, the original blob can still be reconstructed—as long as over 50% of fragments are available.
Using mathematical interpolation (e.g., polynomial functions), erasure coding expands a dataset so that recovery is possible from any majority subset. This makes accidental or malicious data loss extremely unlikely.
For example:
- Original blob split into 100 pieces
- Encoded into 200 pieces using erasure coding
- Only 101 pieces needed to reconstruct the original
This redundancy enables secure sampling while minimizing trust assumptions.
KZG Commitments: Prove Data Integrity
Nodes sampling fragments need assurance that those fragments belong to the real blob—not fabricated ones. That’s where KZG commitments come in.
A KZG commitment is a cryptographic proof that binds all fragments to a single mathematical structure (a polynomial). Validators can check whether any given fragment matches the original blob without seeing the whole dataset.
Think of it like a digital fingerprint: anyone can verify a part belongs to the whole, without needing access to everything.
Together, erasure coding and KZG commitments enable secure, lightweight verification—making large-scale sharding feasible without compromising decentralization.
Proposer-Builder Separation (PBS): Mitigating MEV Risks
As blob sizes grow, creating blocks becomes more resource-intensive—favoring well-resourced validators and risking centralization. To prevent this, Danksharding implements Proposer-Builder Separation (PBS).
Under PBS:
- Builders: High-performance nodes that create fully assembled blocks (including blobs).
- Proposers: Regular validators who select which builder’s block to include—without knowing its contents in advance.
This separation ensures that even lightweight nodes can participate in consensus while allowing specialized builders to handle complex tasks.
But PBS raises concerns about censorship: what stops builders from excluding certain transactions?
Enter crList (Censorship Resistance List).
Censorship Resistance List (crList): Preventing Transaction Suppression
To prevent builders from manipulating transaction order or omitting specific transactions:
- The proposer publishes a list (crList) of pending mempool transactions.
- Builders must include all crList transactions in their proposed blocks.
- Builders cannot insert private MEV-generating trades outside this list.
This ensures fairness and preserves Ethereum’s anti-censorship ethos—even in a builder-dominated environment.
A proposed enhancement—Two-Slot PBS—further strengthens this model by introducing a bidding phase and delayed block body revelation. While it extends block time to 24 seconds temporarily, it increases competition among builders and redistributes MEV profits more equitably.
👉 Explore how decentralized networks are evolving with next-generation consensus models.
Frequently Asked Questions (FAQ)
Q: What is the difference between EIP-4844 and full Danksharding?
A: EIP-4844 introduces blob-carrying transactions with up to 2 MB of additional data per block—laying the foundation for scalability. Full Danksharding expands this to 16–32 MB using advanced techniques like DAS and PBS for maximum throughput.
Q: Does Danksharding make Ethereum centralized?
A: No. By using data availability sampling and proposer-builder separation, Danksharding maintains decentralization. Light nodes can verify large datasets without storing them fully, preserving accessibility.
Q: How does Danksharding reduce gas fees?
A: By providing cheap data storage via blobs, rollups can batch more transactions at lower cost—directly reducing user fees on L2 platforms.
Q: When will EIP-4844 launch?
A: EIP-4844 is expected to go live with Ethereum’s Cancun upgrade, following the Shanghai hard fork—potentially in early 2025.
Q: Can other blockchains adopt Danksharding?
A: Yes. The core ideas—data availability sampling, PBS, erasure coding—are being explored by various modular blockchains aiming to scale securely.
Q: Is MEV eliminated under Danksharding?
A: Not entirely—but significantly reduced. With crList and competitive builder markets, opportunities for harmful MEV (like sandwich attacks) are minimized.
Conclusion: A New Era for Public Blockchains
Danksharding represents a paradigm shift—not just for Ethereum, but for blockchain scalability as a whole. By combining:
- Efficient blob storage (EIP-4844)
- Secure data verification (DAS + erasure coding + KZG)
- Decentralized block construction (PBS + crList)
Ethereum moves closer than ever to resolving the blockchain trilemma. It achieves scalability through rollup-centric design while preserving decentralization and security.
The implications are profound:
- Rollups gain ultra-low-cost data posting
- Users enjoy near-instant, affordable transactions
- New "killer apps" in gaming, social media, and microtransactions become viable
- Modular blockchain architectures thrive alongside Ethereum
Far from being just another upgrade, Danksharding could usher in a new narrative for public ledgers—one where performance doesn’t come at the cost of openness or trustlessness.
As development progresses toward full implementation, one thing is certain: Ethereum isn’t just evolving—it’s redefining what’s possible in decentralized computing.