Skip to content
Ethereum · First Principles

The Danksharding Roadmap

The previous page shipped EIP-4844 — Proto-Danksharding and Blobs: Ethereum gave rollups a dedicated, cheap data lane, a small handful of ~128 KB blobs per block, priced by their own fee market and deleted after a few weeks. That page ends on a cliffhanger. Blobs made rollup data cheaper, but they did not repeal the law from Data Availability — The Real Bottleneck: every full node still downloads every blob to confirm the data was actually published. The blob count is small on purpose, because the moment you demand more blobs, you demand more bandwidth from every verifier — and you are back to spending decentralization for throughput.

This page is about the escape hatch. Full danksharding is the multi-year plan to raise blob capacity by an order of magnitude without asking any single node to download all the data. The trick is to let nodes sample — check a few random pieces and reason, statistically, that the whole thing must be available. It is the most direct answer this part gives to the scalability trilemma: a way to raise scalability that does not force every node to store everything, and so does not quietly buy speed with decentralization.

A warning up front, in keeping with this book’s honesty about volatile facts: the roadmap is a direction, not a schedule. Ethereum ships in incremental hard forks, target dates slip, and blob counts are raised gradually and conservatively. Treat every date and number on this page as shape, not gospel (as of mid-2025). What is durable is the mechanism; that is what we spend the page on.

The problem full danksharding solves

Section titled “The problem full danksharding solves”

Recall the binding constraint. A rollup’s dominant cost is not executing its transactions off-chain — that is cheap and can be scaled by throwing hardware at a sequencer. The cost is publishing the transaction data to L1 so that anyone can independently reconstruct the rollup’s state and, if the sequencer lies, challenge it. If the data is not published, an optimistic rollup cannot be fraud-proven and a ZK rollup cannot be followed (you would have a valid state root but no way to know your own balance). Data availability is the product Ethereum’s base layer actually sells to rollups.

So the throughput of the whole rollup ecosystem is gated by one number: how much data can L1 guarantee is available per block? With EIP-4844 that number is a few blobs — deliberately tiny, because of the wall we keep hitting:

   naive "just add more blobs":


   target 6 blobs/block   → every node downloads ~0.75 MB/block  (fine)
   target 64 blobs/block  → every node downloads ~8 MB/block     (painful)
   target 256 blobs/block → every node downloads ~32 MB/block    (only datacenters
                                                                  can keep up)


   more blobs ⇒ more bandwidth per verifier ⇒ fewer verifiers ⇒ less trustless

Full danksharding’s goal is to break that line: many more blobs per block, while each node downloads only a small, fixed amount regardless of the total. If that sounds like it violates conservation of effort — verifying something without looking at all of it — the resolution is a genuinely clever combination of two old ideas: erasure coding and random sampling.

Data-availability sampling, from first principles

Section titled “Data-availability sampling, from first principles”

The question every honest node must answer about a block is not “is this data correct?” but the sneakier “is this data available — was all of it actually published, so that anyone who wants it can get it?” A malicious block producer’s attack is to publish most of the data but withhold a sliver, hoping no one notices the missing piece until it is too late to challenge. So the node needs a cheap way to be confident the entire blob space was published, without downloading the entire blob space.

Step 1 — erasure coding makes “a little missing” impossible

Section titled “Step 1 — erasure coding makes “a little missing” impossible”

Take the blob data and erasure-code it: expand it with redundancy so that the original can be reconstructed from any sufficiently large fraction of the pieces. Ethereum’s target is 2× expansion — encode the data so that any 50% of the encoded pieces is enough to rebuild 100% of the original (this is Reed–Solomon coding, the same math behind QR codes and RAID).

This is the pivotal move. Once data is erasure-coded, an adversary can no longer hide a small omission:

   plain data:      withhold 1 byte out of a million → almost impossible to detect
                    by sampling; you'd have to check nearly every byte.


   erasure-coded:   to make the data UNrecoverable, the adversary must withhold
                    MORE THAN 50% of the pieces. Hiding "a little" is now useless —
                    only hiding "a lot" breaks availability.

Erasure coding converts a needle-in-a-haystack problem (“is any one piece missing?”) into a coin-flip problem (“is more than half missing?”). And more than half missing is trivially catchable by random sampling.

Step 2 — random sampling catches “a lot missing” cheaply

Section titled “Step 2 — random sampling catches “a lot missing” cheaply”

Now each node asks the network for a handful of random pieces of the encoded data. If the block producer withheld more than 50% of the pieces (the only way to actually make the data unrecoverable), then each random request has better than a 50% chance of hitting a missing piece. Ask for enough independent samples and the probability that all of them happen to land on the published half becomes vanishingly small.

   Suppose the producer withheld enough to break availability (>50% missing).
   Probability one random sample lands on an AVAILABLE piece:  ≤ 0.5


   after  k independent samples all "available":
     P(the node was fooled) ≤ 0.5^k


     k = 10  →  ≤ 1 in ~1,000
     k = 20  →  ≤ 1 in ~1,000,000
     k = 30  →  ≤ 1 in ~1,000,000,000

So with a few dozen tiny sampled pieces — kilobytes, not megabytes — a node can conclude the data is available with overwhelming confidence, no matter how large the total blob space is. That is the whole magic: sampling cost is roughly constant while total capacity grows. Ten thousand nodes each sampling a different random 30 pieces collectively touch enough of the data to guarantee it can be reconstructed, yet no single node downloaded more than a sliver. This is data-availability sampling (DAS).

Step 3 — KZG commitments stop the producer from lying about the pieces

Section titled “Step 3 — KZG commitments stop the producer from lying about the pieces”

There is one hole left. Random sampling only works if the pieces a node receives are the genuine encoded pieces — a producer could hand you correct-looking bytes that don’t actually belong to a valid encoding. This is where the KZG polynomial commitment from EIP-4844 does its second job.

Each blob is already committed to with a KZG commitment (a 48-byte fingerprint of the polynomial that represents the blob). KZG has a property plain hashes lack: you can produce a short proof that “this specific piece is the correct value of the committed polynomial at this specific position,” and anyone can verify that proof against the 48-byte commitment alone. So when a node samples a piece, it also gets a KZG proof and checks it. A producer cannot feed you a forged piece that passes — it would have to break the cryptographic commitment. KZG is what makes each sample trustworthy; erasure coding plus sampling is what makes the whole trustworthy.

   full danksharding, one block:


   rollups' data ─► erasure-code (2×) ─► arrange as a 2D grid of pieces
                                             │
                                    KZG commit to each row/column
                                             │
        ┌────────────────────────────────────┴───────────────┐
        ▼                                                     ▼
   each validator samples a few RANDOM cells + KZG proofs   light clients do the same
        │                                                     │
   all proofs check  &  >50% of cells respond               → "data is available"
        │
        └─► conclude: the ENTIRE blob space was published,
            without any one node downloading all of it

Proto-danksharding was step one; full danksharding is the destination

Section titled “Proto-danksharding was step one; full danksharding is the destination”

It helps to see the two as one continuous plan, deliberately split so value ships early.

  • Proto-danksharding (EIP-4844), shipped March 2024 in the Dencun fork. It introduced the blob transaction type, the separate blob fee market, the blob KZG commitment, and blob expiry — the entire economic and data plumbing of danksharding — but with one crucial simplification: every node still downloads every blob. No sampling yet. This is why the blob count had to stay small (a target of 3 and a max of 6 blobs per block at launch). Proto-danksharding is danksharding’s skeleton, load-bearing but not yet scaled.
  • Full danksharding, the multi-year target. It keeps everything EIP-4844 built and adds the missing organ: data-availability sampling, so nodes stop downloading full blobs and start sampling. Only once DAS is live can the blob count safely rise into the dozens or hundreds, because the per-node cost stops tracking the total. There is no single flag-day “danksharding is done” fork; it arrives as a sequence of upgrades (peer-to-peer sampling networking, then increasing blob counts), each shipped when it is safe.

The mental model: EIP-4844 built the pipes and the meter; full danksharding widens the pipes once sampling makes it safe to do so.

An honest look at the roadmap and its dates

Section titled “An honest look at the roadmap and its dates”

This book states settled facts confidently and hedges volatile ones. Danksharding is squarely in the second bucket, so here is the hedge, explicitly.

  • Dates slip, and that is normal. Ethereum ships through named hard forks (Dencun, Pectra, Fusaka, and beyond). Danksharding is not one fork; it is a program spread across several. Any specific “danksharding ships in year N” claim you read should be treated as an aspiration that has already moved before and may move again.
  • Blob counts rise gradually, not in one leap. The safe path is to raise the target and max blob counts a few at a time (as the Pectra 2025 bump did), observe real-world bandwidth and node health, then raise again. Even after sampling lands, expect the ecosystem to walk the blob count up, not sprint.
  • Intermediate steps have their own names. A stepping-stone often discussed under the label PeerDAS ships a first version of the sampling networking layer before the full end-state. Whether a given fork delivers “real” DAS or a precursor is exactly the kind of detail that shifts; do not memorize which fork does what.

The honest summary: the mechanism (erasure coding + sampling + KZG) is settled and well-understood; the delivery timeline is not, and pretending otherwise would be exactly the kind of false precision this book warns against. When you need a current number, check the state of the live network — not this page.

Tie-back to the trilemma

Section titled “Tie-back to the trilemma”

Every page in this part is measured against the scalability trilemma: you cannot raise scalability without paying in security or decentralization — unless you change what verification requires. That is precisely what data-availability sampling does.

Before sampling, “more data available” meant “more bandwidth for every full node,” which meant fewer people could run one, which meant less decentralization. Sampling severs that link. It lets total blob capacity grow while the cost to any individual verifier stays roughly flat, so you can scale throughput without pushing verification out of ordinary hands. It even strengthens the lightest participants: a light client that samples a few pieces gets a real data-availability guarantee, something it could never afford by downloading full blocks.

   the trilemma escape:


   old law:   scalability ⇑  ⇒  per-node cost ⇑  ⇒  decentralization ⇓
   with DAS:  scalability ⇑  ⇒  TOTAL data ⇑ but PER-NODE sampling cost ≈ flat
                             ⇒  decentralization held  ✓

This is why data-availability sampling is the intellectual endpoint of the whole part. Rollups (page 3) moved execution off L1; blobs (page 6) gave that off-chain data a cheap home; and sampling is the mechanism that lets that home grow arbitrarily large while keeping the base layer verifiable on a normal machine. It is not a loophole in the trilemma so much as a redefinition of the constraint: the binding cost stops being “how much data exists” and becomes “how much data each verifier must personally touch” — and that second number, sampling keeps small.

The architect’s lens

Section titled “The architect’s lens”
  • Why does it exist? Because proto-danksharding relieved the price of rollup data but not its ceiling: every node still downloads every blob, so the blob count must stay tiny. Full danksharding exists to lift that ceiling by an order of magnitude without raising per-node bandwidth in lockstep.
  • What problem does it solve? Guaranteeing that a large volume of rollup data was actually published (data availability) without asking any single verifier to download all of it — the last hard limit on rollup throughput after the data-availability bottleneck is understood.
  • What are the trade-offs? It adds real complexity — erasure coding, a 2D data layout, KZG proofs per sample, and a new peer-to-peer sampling network — and its guarantee is statistical (overwhelming, but not literally 100%) rather than the “I downloaded all of it” certainty of full nodes today. That complexity is why it is arriving in stages, not one fork.
  • When should I avoid it? As an application or rollup developer, you never opt out of it — it is base-layer plumbing. But do not plan around a specific date or blob count for it: build so your rollup works at today’s blob capacity and simply gets cheaper as capacity rises, rather than assuming a jump that may slip.
  • What breaks if I remove it? Without sampling, the only way to add data capacity is to make every node download more, which re-couples scalability to per-node cost and reinstates the trilemma. Remove sampling and Ethereum’s data throughput is permanently capped at “whatever a home node can download every 12 seconds” — the rollup roadmap stalls at proto-danksharding.

Check your understanding

Section titled “Check your understanding”
  1. Full danksharding’s headline goal is “many more blobs per block without any node downloading all the data.” Name the two independent ideas that combine to make that possible, and say what each one contributes.
  2. Erasure coding expands the data with 2× redundancy so any 50% suffices to reconstruct it. Why is that specific property what makes random sampling an effective availability check — what would go wrong if the data were not erasure-coded?
  3. A node samples 20 random pieces and every one comes back available. Roughly how confident can it be that the full data was published, and why does that confidence stay the same even as the total blob count grows into the dozens?
  4. What job do KZG commitments do in data-availability sampling that erasure coding and random sampling alone cannot do?
  5. Restate, using this part’s recurring framing, why data-availability sampling counts as an escape from the scalability trilemma rather than just another point on it.
Show answers
  1. Erasure coding and random sampling (with KZG commitments securing each sample). Erasure coding expands the data so that it can only be made unrecoverable by withholding more than half of the pieces — it converts “a tiny bit missing” (undetectable) into “a lot missing” (easy to catch). Random sampling then catches that “a lot missing” case cheaply: a few dozen random pieces are enough to be almost certain more than half was published. Together they let a node verify availability by touching only kilobytes.
  2. Because erasure coding guarantees that breaking availability requires withholding more than 50% of the pieces, so each random sample has better than even odds of hitting a missing piece — a handful of samples then drives the fooled-probability toward zero. Without erasure coding, an adversary could withhold a single tiny piece; to detect that by sampling you would have to check nearly every piece, which defeats the entire point of sampling.
  3. About 1 in a million or better: if availability were actually broken (>50% withheld), the chance all 20 independent samples land on the published portion is at most 0.5²⁰ ≈ 1/1,000,000. The confidence is independent of total size because it depends only on the fraction withheld and the number of samples, not on how many total pieces exist — so more blobs don’t require more sampling per node.
  4. KZG commitments let a node verify that each individual sampled piece is a genuine value of the committed data at that position, via a short proof checked against the 48-byte commitment. Without them, a producer could hand over correct-looking but forged pieces that pass a naive check; erasure coding and sampling assume the pieces are authentic, and KZG is what guarantees that authenticity.
  5. The trilemma says raising scalability costs security or decentralization because more capacity usually means more work per verifier. Data-availability sampling breaks the “because”: it lets total data grow while the amount each individual node must personally download stays roughly constant. So scalability rises without per-node cost rising, decentralization is preserved, and the binding constraint is redefined from “how much data exists” to “how much data each verifier must touch” — which sampling keeps small.