The dream of Ethereum becoming a true "world computer" hinges on solving one of the most persistent challenges in blockchain: the scalability trilemma—achieving decentralization, security, and scalability simultaneously. For years, this has been considered nearly impossible. But with the introduction of Danksharding, a revolutionary new sharding design proposed by Ethereum researcher Dankrad Feist, that may finally be changing.
This article breaks down Danksharding and its foundational upgrade, EIP-4844 (Proto-Danksharding), in plain English. Whether you're new to Web3 or a seasoned builder, you'll walk away understanding how Ethereum plans to scale securely—without sacrificing its core principles.
Why Ethereum Needs Scalability
Since its launch in 2014, Ethereum has redefined what blockchains can do. With smart contracts, it enabled decentralized applications (DApps), paving the way for innovations like DeFi, NFTs, and GameFi. But as adoption surged, so did performance issues.
The Bottleneck: Congestion and High Gas Fees
When too many users interact with Ethereum at once, the network becomes congested—like traffic piling up at a red light. Transactions slow down, and users compete to get theirs processed first by increasing their gas fees. This "gas war" can make simple interactions cost tens or even hundreds of dollars.
A famous example? The 2017 CryptoKitties craze, which nearly brought Ethereum to a standstill and spiked gas fees to over $100 per transaction.
Understanding Ethereum’s Performance Limits
Unlike Bitcoin, which handles simple transfers, Ethereum processes complex smart contract logic. Its throughput isn’t fixed—it depends on how much data each block contains.
Key facts:
- Each block has a gas limit of 30 million, with a target of 15 million.
- Block size averages 60–70 KB, ranging from 5 KB to 160 KB.
- Blocks are produced every 12 seconds.
- Average throughput: 13–30 TPS, peaking at around 45 TPS.
Compare that to Visa’s tens of thousands of TPS, and it’s clear: Ethereum must scale to fulfill its global ambitions.
👉 Discover how next-gen blockchain scaling is unlocking massive growth opportunities.
The Blockchain Trilemma: Decentralization vs. Security vs. Scalability
Ethereum’s challenge isn’t just technical—it’s philosophical. The blockchain trilemma states that public blockchains can’t fully achieve all three of:
- Decentralization: Many independent nodes maintain the network.
- Security: High cost to attack ensures network integrity.
- Scalability: High transaction throughput for mass adoption.
Ethereum prioritizes decentralization and security. But boosting scalability often requires trade-offs—like increasing node hardware demands, which risks centralization.
So how do you scale without compromising the foundation?
Current Ethereum Scaling Solutions
To address scalability while preserving decentralization, Ethereum relies on two main paths: Layer 2 (L2) and sharding.
Layer 2: Off-Chain Scaling
Layer 2 solutions process transactions off the main chain (Layer 1), then post results back to Ethereum—retaining security while reducing load.
Rollups: The Leading L2 Approach
Rollups batch hundreds of transactions into a single on-chain submission. Two main types:
- Optimistic Rollups: Assume transactions are valid by default. A challenge period (usually one week) allows disputes. Lower compression, longer finality.
- ZK Rollups: Use zero-knowledge proofs to cryptographically verify transactions. No challenge period needed, higher efficiency, but harder to build.
While L2s improve scalability, they still depend on Ethereum’s base layer capacity. That’s where sharding comes in.
The Original Sharding Plan: Sharding 1.0
Before Danksharding, Ethereum planned Sharding 1.0—splitting the network into up to 64 parallel chains, each handling part of the data load.
How It Worked
- Each shard processed its own transactions.
- The Beacon Chain coordinated consensus and linked shards via crosslinks.
- Validators were randomly assigned to shard committees every epoch (6.4 minutes).
Problems with Sharding 1.0
Despite its promise, Sharding 1.0 faced major hurdles:
- High Development Complexity: Managing 64 chains increased system fragility.
- Data Synchronization Overhead: Validators had to sync new shard data every epoch—too demanding for average nodes.
- Storage Bloat: Total data growth accelerated, pushing node requirements higher.
- No MEV Mitigation: Did nothing to stop exploitative practices like MEV (Maximal Extractable Value).
MEV—where validators reorder or insert transactions for profit—leads to issues like:
- Sandwich attacks on DEX trades
- Network congestion
- Centralization pressure (richer validators gain more power)
Because of these flaws, Sharding 1.0 was shelved in favor of a more elegant solution: Danksharding.
Introducing Danksharding: A Paradigm Shift
Danksharding rethinks sharding not as parallel chains, but as a data availability layer optimized for Rollups. It enables massive scalability while keeping nodes lightweight and decentralized.
The journey begins with EIP-4844, also known as Proto-Danksharding.
EIP-4844: Proto-Danksharding and Blob Transactions
EIP-4844 introduces a new transaction type: the blob-carrying transaction.
Key features:
- Each blob is ~128 KB; one transaction can carry two blobs (256 KB).
- Target: 8 blobs per block (~1 MB); max: 16 blobs (~2 MB).
- Blobs are stored temporarily—likely 30 days—then pruned.
Why is this a game-changer?
- Ethereum’s average block is ~85 KB. Adding 1–2 MB per block dramatically increases L2 data capacity.
- Annual blob data: 2.5–5 TB, far exceeding Ethereum’s total historical ledger size (~1 TB).
- Since blobs are temporary, long-term storage burden on nodes remains low.
👉 See how cutting-edge blockchain upgrades are creating new investment frontiers.
Who Stores Blob Data Long-Term?
Ethereum’s role isn’t eternal storage—it’s a secure, real-time bulletin board. Anyone needing historical blob data (e.g., L2 projects, decentralized storage networks like IPFS or Filecoin) can download and preserve it during the retention window.
This model keeps Ethereum lean while empowering other protocols to handle archival needs.
Danksharding: The Full Vision
EIP-4844 is just the first step. Full Danksharding will scale blob capacity from 2 MB to up to 32 MB per block, enabling Rollups to achieve 100,000+ TPS.
But how can nodes handle such massive data without becoming centralized?
Solving the Node Burden Problem
Two major challenges arise when scaling data:
- Node Overload: Downloading multi-megabyte blobs every 12 seconds is impractical for consumer hardware.
- Data Availability: How do we ensure blob data is truly accessible without forcing every node to store it all?
Danksharding solves both with innovative cryptography and architecture.
Core Technologies Behind Danksharding
Data Availability Sampling (DAS)
Instead of downloading entire blobs, nodes perform random spot-checks on small pieces of data.
Here’s how it works:
- Blobs are split into tiny fragments.
- Nodes randomly sample a few fragments.
- If enough samples are available across the network, the system assumes full data is accessible.
With enough nodes sampling, the chance of missing critical data is negligible—ensuring availability with minimal overhead.
Erasure Coding
To make DAS reliable, Danksharding uses erasure coding—a technique that expands original data with redundant fragments.
Crucially:
➡️ Nodes only need to retrieve 50% or more of the fragments to reconstruct the full blob.
This drastically reduces the risk of data loss—even if many nodes miss samples.
KZG Polynomial Commitments
How do nodes know sampled fragments are legitimate? Enter KZG commitments, a cryptographic tool that proves a fragment belongs to the original blob.
Think of it like a cryptographic fingerprint for polynomial functions—ensuring integrity without revealing full data.
Together, erasure coding and KZG commitments make DAS secure and efficient—enabling high throughput without bloating node requirements.
Proposer-Builder Separation (PBS)
As blob sizes grow, creating blocks becomes resource-intensive—only powerful nodes could manage it, risking centralization.
Danksharding counters this with Proposer-Builder Separation (PBS):
| Role | Responsibility | Node Type |
|---|---|---|
| Builder | Gathers transactions, creates full block with blobs | High-performance, potentially centralized |
| Proposer | Selects block header from builders, proposes it | Low-resource, decentralized |
This separation allows anyone to participate as a proposer—even on modest hardware—while builders handle heavy lifting.
But doesn’t this give builders power to censor or manipulate transactions?
Fighting MEV: crList and Two-Slot PBS
Anti-Censorship List (crList)
To prevent censorship, proposers publish a crList—a list of pending mempool transactions that builders must include (unless gas limit is reached).
This ensures:
- No hidden private transactions
- No arbitrary transaction filtering
- Reduced MEV exploitation like sandwich attacks
Builders can still reorder transactions within the crList—but they can’t exclude them unfairly.
Two-Slot PBS
An advanced PBS design where:
- Builders submit block headers + bids.
- Proposers accept the highest bid.
- After validation, builders reveal the full block body.
- If they fail to deliver, they lose rewards.
This two-step process introduces competition among builders. As they bid against each other, profits from MEV get redistributed to proposers—promoting decentralization.
Yes, there’s a trade-off: two slots mean 24-second finality instead of 12 seconds. But ongoing research aims to optimize this delay.
👉 Explore how blockchain innovations are reshaping digital economies worldwide.
Frequently Asked Questions (FAQ)
What is Danksharding?
Danksharding is Ethereum’s next-generation scaling solution that uses data blobs and advanced cryptography to massively increase throughput while keeping nodes lightweight and decentralized—primarily benefiting Layer 2 rollups.
How does EIP-4844 reduce gas fees?
By providing cheaper data storage via blob transactions, EIP-4844 lowers the cost for rollups to post data on Ethereum—directly reducing user fees on L2 networks like Arbitrum and Optimism.
What are blob transactions?
Blob transactions carry large amounts of temporary data (~128 KB each) that are deleted after ~30 days. They’re designed specifically for rollups to scale efficiently without burdening long-term node storage.
Does Danksharding make Ethereum centralized?
No. Through techniques like Data Availability Sampling and Proposer-Builder Separation, Danksharding maintains decentralization by allowing low-spec devices to participate in verification—even as data capacity grows.
When will Danksharding launch?
EIP-4844 (Proto-Danksharding) is expected in the Cancun upgrade, following Shanghai. Full Danksharding will roll out in later phases as infrastructure matures.
How does Danksharding impact Layer 2 projects?
It’s transformative. With vastly more data space at lower cost, L2s can support high-frequency applications—think decentralized social media, real-time gaming, and mass-market DeFi platforms previously impossible on-chain.
Conclusion: A New Narrative for Public Blockchains
Danksharding represents more than just a technical upgrade—it’s a fundamental reimagining of blockchain scalability.
By combining:
- Temporary blob storage
- Data Availability Sampling
- Erasure coding and KZG commitments
- Proposer-Builder Separation
- Anti-MEV mechanisms like crList
Ethereum is poised to break the trilemma myth—not by sacrificing decentralization or security, but by innovating around them.
The result? A future where decentralized verification meets centralized-level performance, opening the door to truly global applications.
As Vitalik Buterin puts it: "The Surge is coming."
With Danksharding at its core, Ethereum isn’t just upgrading—it’s rewriting the rules of what blockchains can achieve.