Danksharding is Ethereum's long-term plan to make data cheap and abundant without asking every computer on the network to store more. It is named after Dankrad Feist, the Ethereum Foundation researcher whose design underpins it. The idea sounds paradoxical: scale the network by having nodes deliberately hold less, and verify the rest by inspection rather than possession.
The point that trips up newcomers is what danksharding actually scales. It does not speed up Ethereum's own transaction execution. Instead it scales data availability — the guarantee that data a rollup posted really was published and can be retrieved by anyone who needs it. That guarantee is the quiet foundation the entire layer-2 ecosystem stands on, and making it cheap is what danksharding is for.
Why does availability matter so much? A rollup's security rests on a promise: if the rollup's operator ever misbehaves, anyone should be able to take the published data, replay it, and prove what the correct state should have been. That promise only holds if the data was genuinely made available in the first place. Withhold the data and no one can generate the proof, and the rollup's safety collapses. Danksharding exists to make that availability guarantee both ironclad and inexpensive, so the promise never depends on trusting the rollup to be honest.
01 — The Core Idea
The word "sharding" is a holdover from an older vision. Ethereum's original scaling roadmap called for roughly sixty-four shard chains — parallel chains that would each execute their own transactions, splitting the workload the way a database is split across servers. It was complex and never shipped.
02 — The Roadmap Pivot
In 2020 Ethereum pivoted to a rollup-centric roadmap. Execution would be pushed off to layer-2 rollups — separate chains that process transactions in bulk and post the results back to Ethereum. The base layer's job would shrink to two things: settling those results and guaranteeing the underlying data was available. Sharding survived the pivot, but its purpose narrowed. Danksharding shards only data, never execution, and every block still has a single proposer rather than sixty-four competing chains. The name kept the word; the design threw out the hard part. The happy coincidence is that the number sixty-four resurfaces — not as shard chains this time, but as the rough target for blobs per block in the full design, a reminder that the ambition scaled down in complexity without scaling down in capacity.
03 — Blobs: The New Data Lane
The first piece of danksharding to reach the mainnet was proto-danksharding, formally EIP-4844, which shipped in the Dencun upgrade in March 2024. It introduced a new kind of attachment to Ethereum blocks: the blob, short for binary large object. A blob is a fixed packet of roughly 128 kilobytes of data that rides alongside a block but lives in a separate lane from ordinary transactions.
Blobs have two properties that make them special. First, the EVM — the smart-contract engine that runs Ethereum's logic — cannot read a blob's contents; it can only see a short cryptographic fingerprint of it. Second, blobs are temporary: nodes prune them after about eighteen days, so they are never stored on-chain forever. Crucially, blobs are priced in their own blob gas market, an independent fee lane that floats separately from regular gas and stays very cheap when demand is low. That separate market is the reason blob space could be offered at a fraction of the cost of old-style permanent storage; the broader mechanics of Ethereum's fee system are covered in Why Are Gas Fees So High?
04 — Why Rollups Needed This
To see why blobs mattered, follow a rollup's money. A layer-2 batches thousands of transactions, then must publish the compressed data back to Ethereum so anyone can independently reconstruct and check the rollup's state. Before blobs, rollups posted that data as calldata — permanent block data stored by every node forever. It was secure, but it was the single largest line item in a rollup's cost, and it flowed straight through to users as fees.
Blobs gave rollups a purpose-built lane that is roomy, cheap, and deliberately temporary — because a rollup only needs its data to be available long enough for anyone to challenge or verify it, not for eternity. The effect was immediate. When Dencun activated, fees on the major rollups fell by roughly an order of magnitude, turning dollar transactions into cent transactions almost overnight. This served both major rollup families equally, a distinction explored in Optimistic vs ZK Rollups
The counterintuitive core. Danksharding's central trick is that no single node ever downloads all the data. Instead, each node checks a handful of random pieces — and if enough nodes each sample a few, the network can be statistically certain the whole dataset was published. Availability is proven by a crowd of spot-checks, not by anyone holding the full copy.
05 — Data Availability Sampling
That crowd-of-spot-checks technique has a name: data availability sampling, or DAS. Rather than force every node to download every blob, DAS lets a node request a few small, randomly chosen fragments. If those fragments come back, the node concludes with high confidence that all the data is available. Multiply that across thousands of nodes and the whole block is verified without anyone shouldering the whole load — which is precisely what lets the data lane grow while node hardware stays modest.
Two pieces of cryptography make this safe. Erasure coding expands the data with redundancy so that even if some fragments go missing, the original can be rebuilt from the pieces that remain — and it makes hiding data nearly impossible, since an attacker would have to withhold a large fraction to fool the samplers. KZG polynomial commitments, a compact cryptographic fingerprint, let anyone confirm a fragment genuinely belongs to the committed blob without trusting the sender. The commitments relied on a one-time trusted-setup ceremony that drew well over one hundred thousand contributors — among the largest such ceremonies ever run — and by design needs only a single honest participant to remain secure.
The elegance is in the asymmetry it creates. Publishing bad or incomplete data becomes statistically self-defeating: to slip missing data past the network, a dishonest block builder would have to fool an enormous number of independent random samples at once, and the erasure coding makes even that insufficient. Meanwhile an honest builder's data sails through, because every sample lands on real, verifiable fragments. Cheating is expensive and almost certain to fail; honesty is cheap and always passes. That lopsided arithmetic is what lets Ethereum trust a dataset it never fully downloads.
06 — From Proto to Full
Proto-danksharding was the beginning, not the destination. At launch, blocks targeted just three blobs and capped at six — a modest lane sized to be safe. Ethereum has been widening it in steps. The Pectra upgrade in 2025 roughly doubled blob throughput, and the Fusaka upgrade later that year shipped PeerDAS, the first real version of sampling among peers and a genuine milestone on the path to the full design. Follow-on parameter forks nudged the blob count higher still.
What remains ahead is full danksharding, whose design target is on the order of sixty-four blobs per block — roughly sixteen megabytes of data space in every slot, delivered through complete two-dimensional sampling. As of 2026 that endpoint is not yet live; the network is climbing toward it one carefully tested upgrade at a time. This deliberate, data-first path is central to Ethereum's modular strategy, examined in The Ethereum Thesis: Restaking & L2s
07 — Scaling Data, Not Execution
It is worth restating the point that separates danksharding from every other "scaling" headline. Danksharding does not make Ethereum itself process more transactions. It makes blob space larger and cheaper, and the actual throughput gains arrive on the rollups that consume that space. Ethereum becomes a high-assurance data and settlement layer; the rollups become the fast execution engines on top. Capacity is added by division of labor, not by making the base chain do more.
Preserving decentralization through all this leans on proposer-builder separation. Assembling a data-heavy block is demanding work handed to specialized builders, while ordinary validators simply sample to confirm the data is there. The heavy lifting is concentrated where it can be done efficiently; the verification stays light enough that a home validator on modest hardware can still take part. That balance — big capacity, small verification cost — is the whole reason danksharding is built the way it is.
08 — Where It Leaves Ethereum
Danksharding reframes what Ethereum is for. The base layer stops trying to be the world's fast computer and becomes instead the world's most reliable notice board — a place where rollups can post data cheaply and prove to anyone that it was published. Proto-danksharding already delivered the cheap part, and each upgrade since has widened the lane while keeping verification within reach of everyday hardware.
For everyday users, the payoff shows up most visibly as the near-free layer-2 transaction fees that followed the Dencun upgrade. For the network, the payoff is a scaling path that does not quietly centralize by demanding ever-beefier nodes. The endpoint — full danksharding — is not here yet, and the honest summary in 2026 is that Ethereum is walking a well-marked road rather than standing at its finish. But the direction is clear: cheap, abundant, sampled data availability as the bedrock beneath an economy of rollups.
"In the mouth of two or three witnesses shall every word be established." — 2 Corinthians 13:1
Methodology & Sources
This report draws on Ethereum Foundation roadmap documentation, the EIP-4844 specification, and upgrade records for Dencun, Pectra, and Fusaka, cross-checked by a parallel multi-agent research review. It is educational and is not investment advice.
All figures are directional. Blob size is stated as roughly 128 KB and the pruning window as about eighteen days; the full-danksharding target of around sixty-four blobs (~16 MB per block) is a design goal, not a shipped parameter. Blob limits have risen in stages — a target of three and maximum of six at the EIP-4844 launch in March 2024, roughly doubled at Pectra in 2025, with PeerDAS shipping in the Fusaka upgrade in December 2025 — and continue to change. Layer-2 fee reductions after Dencun are described as approximately an order of magnitude, a figure that varies by rollup and by day.
No verified security failure of the blob layer or danksharding protocol occurred in 2025 or 2026; large exploits reported in that period were application- and bridge-layer events unrelated to blobs or data availability sampling, and are deliberately excluded here. Verify current parameters via intelligencecrypto.org before relying on any number.