What Is Danksharding? Ethereum's Next Scaling Step Explained

Why Ethereum needs a new data layer in the first place

Ethereum's block space is small on purpose. Every full node on the network has to download, store, and verify every transaction, and the protocol is tuned so a consumer laptop with a solid-state drive can keep up. That choice is what makes Ethereum credibly neutral: anyone, anywhere, can run a node, check the chain for themselves, and refuse to follow a censored or invalid history.

The problem is throughput. With roughly 15 million gas per block and a 12-second slot, the L1 itself can only fit a small amount of activity. For years the community's bet has been that most user transactions will live on Layer 2 rollups, which batch users' transactions and post a compressed summary back to Ethereum, using L1 as a settlement and data-availability layer.

That bet only works if posting data to L1 is cheap. In 2023, before EIP-4844, rollup fees were dominated by calldata costs, and a single swap on a popular L2 could cost several dollars during busy periods. To get to cents-per-swap economics, the data layer itself has to grow by roughly two orders of magnitude. Doing that without breaking the "a node can run on a laptop" property is exactly what danksharding is designed to solve.

How danksharding differs from the old "shard chains" idea

For most of Ethereum's history, the consensus was that scaling meant building 64 separate shard chains, each processing its own transactions in parallel, and stitching them together with cross-shard communication. That plan had serious problems: it was complex to implement, hard to reason about for application developers, and it left most of the security and composability on a single chain anyway.

Danksharding, named after researcher Dankrad Feist, throws most of that out. Instead of 64 execution chains, Ethereum keeps one execution layer and turns the consensus layer into a high-throughput data layer. There are no shards in the original sense. Instead, the system attaches large binary objects called blobs to each block, and a separate mechanism called data availability sampling lets light clients confirm that the data was actually published without downloading the whole thing.

In other words, "sharding" in the danksharding world is not about splitting execution. It is about splitting the job of storing and verifying blob data across many nodes while keeping the chain itself a single, unified object. That sounds like a small rebrand, but the engineering consequences are large. The validator set only has to verify one chain, cross-rollup communication stays simple, and the data layer can be scaled up or down with the same machinery.

Data availability sampling, explained without the math

The core trick behind danksharding is data availability sampling (DAS). The intuition is borrowed from erasure coding, the same kind of math that lets a streaming video recover from packet loss.

Here is the simplified version. A block producer takes the blob data for a slot and extends it with redundant mathematical chunks, so that any half of the chunks is enough to reconstruct the whole. That extended data is then spread across a wide set of nodes. Each light client, instead of downloading the full blob, randomly requests a few small chunks from random peers. If every request comes back with a valid chunk, the client becomes statistically very confident the full data was actually published. If a malicious block producer tried to hide even a small piece of the data, the random sampling would catch the gap almost certainly.

This is the part that lets Ethereum scale data without scaling what each node has to store. A light node with limited bandwidth can confirm availability of a large blob by asking for, say, 16 samples, while the network as a whole holds the full data across many machines. As the data per block grows, you don't ask every node to store more, you ask the network to spread the data wider and let sampling do the verification.

The catch is that DAS only works if a peer-to-peer network can actually fetch, gossip, and serve all those samples reliably, and if the cryptography underlying the erasure coding is implemented correctly. PeerDAS, an interim design being researched by the Ethereum Foundation, softens the assumption: it samples from peers rather than from a fully distributed data set, which is easier to deploy but gives slightly weaker guarantees. Full danksharding-grade DAS is the later, harder step.

From a few blobs to millions: the throughput story

Numbers help anchor this. After EIP-4844, the proto-danksharding design ships with a target of roughly 3 blobs per block, where each blob is about 125 kilobytes. That works out to a few hundred kilobytes of blob data per slot, which is already a meaningful bump over the old calldata-only regime and is the main reason L2 swap fees dropped sharply in 2024.

Full danksharding envisions a much more aggressive target. The roadmap currently points toward 16 megabytes of blob data per slot, with 32 blobs of roughly 500 kilobytes each being one commonly cited design point. Multiplied out over Ethereum's slot cadence, that is on the order of a million blobs per day, compared to a few tens of thousands today. Layer 2 rollups would, in theory, have so much cheap data space available that their fees collapse to near the cost of actually executing and proving the transactions themselves.

Those numbers are not promises. They are design targets inside a research agenda. The team has explicitly said the full-danksharding target is a "north star," and that intermediate stages, especially PeerDAS, will ship first and inform whether the final numbers are realistic. The honest framing is that blob throughput is expected to rise in steps, with the biggest jumps only coming after years of testing.

What this means for Layer 2 fees and rollup economics

The whole point of danksharding is to lower L2 fees, so it is worth being concrete about the mechanism. A rollup like Arbitrum, Optimism, Base, or zkSync posts a compressed batch of user transactions to Ethereum along with a proof. Pre-4844, that batch lived in calldata, which competed with all other L1 transactions for space. Post-4844, it lives in blobs, which have a separate fee market and were designed to be cheap.

So far, the savings are real but uneven. During quiet network conditions, an L2 swap can already cost a few cents. During peak demand, fees still spike because the blob market has a target of 3 blobs per block and a maximum of 6, and demand can exceed that small supply. Full danksharding grows that supply by orders of magnitude, which should compress the worst-case fee spikes and let rollups pass through most of the savings as either lower user fees or higher margins.

Two caveats matter here. First, rollup fees are a function of the L1 data price, the rollup's own execution and proving costs, and the rollup's fee model. A rollup can choose to keep fees sticky and capture the data savings as profit. Second, the proof systems for zk-rollups are still expensive to run, and until those costs come down, the floor on L2 fees is set by proving, not by data availability. Danksharding moves the dominant cost, but it does not eliminate every cost.

Risks: hardware, centralization, and the roadmap slipping

Scaling the data layer is not free, and the costs show up in three uncomfortable places.

The first is validator hardware. To participate in full danksharding, a validator has to handle larger blocks, more network traffic, and, in some designs, store a non-trivial slice of blob data. The Ethereum community is explicit that this is a deliberate trade-off: full nodes can stay light by using sampling, but consensus validators are expected to grow. The risk is that the threshold crosses the line from "comfortable on a mid-range server" to "you really want a dedicated machine," which gradually squeezes out hobbyist stakers.

The second is centralization. The most efficient way to run large-scale blob storage and sampling is to operate a professional staking and data-services business, which tilts the validator set toward a small number of large operators like Lido, Coinbase, Binance, and a handful of well-capitalized staking pools. If a majority of stake ends up in the hands of a few entities, the censorship-resistance and credible-neutrality properties that motivated the scaling plan in the first place get weaker. Danksharding does not cause this centralization by itself, but it amplifies whatever centralization pressures already exist.

The third is the simplest: the roadmap could slip or be re-scoped. The 2022 Merge, the 2024 Dencun upgrade that shipped EIP-4844, and the move to proof-of-stake each ran behind early timelines. Full danksharding is, by the Ethereum Foundation's own description, a multi-year research and engineering effort with no firm ship date. PeerDAS is the more concrete near-term step, and even it is staged in phases. Anyone building a product or investment thesis on the assumption that "full danksharding will be live in 18 months" is making a guess.

Timeline, milestones, and what to watch

The current sequence, as of the most recent devnet and protocol roadmap discussions, looks like this. The first proto-danksharding step, EIP-4844 with a small blob market, is already live on mainnet. The next milestone is a blob-throughput increase, sometimes called "blob parameter tuning," that grows the target and maximum blobs per block without changing the underlying cryptography. After that, the team is working toward PeerDAS, a partial data availability sampling design that lets validators store only a fraction of the blob data and reconstruct the rest from peers.

Full danksharding-grade DAS, with 16-megabyte blobs, the full sampling network, and the associated peer-to-peer redesign, sits further out. Realistic estimates from core researchers put it on a horizon of multiple years, with the possibility that intermediate stages will be the practical ceiling for some time.

For anyone following this space, the signals that matter are not price action but the usual mix of specification documents on ethereum.org and the Ethereum research forums, the inclusion of new EIPs in devnets, the blob counts and fee behavior observed on mainnet, and the cadence of hard forks. If blob fees start spiking frequently at the current target, that is a signal that supply growth is overdue. If PeerDAS ships to a public testnet, that is a signal that the sampling layer is becoming concrete.

How to follow the danksharding roadmap the smart way

Danksharding will arrive in pieces, not as a single switch, and the most common mistake is to treat each step as if it were the whole thing. The right mental model is that proto-danksharding is the data-layer upgrade you have already paid for, PeerDAS is the data-layer upgrade you are likely to get next, and full danksharding is a research target whose final shape may differ from the diagrams circulating today. Zippfeed tracks Ethereum scaling news with sentiment scoring (bullish, neutral, or bearish) and an importance rating, so you can separate genuine protocol progress from speculation and hype as the roadmap unfolds.