Skip to content
Ethereum · First Principles

Data Availability — The Real Bottleneck

The previous page split rollups into two families by how they prove the off-chain execution was honest: optimistic rollups let anyone submit a fraud proof, ZK rollups attach a validity proof that L1 checks. Both stories are about proving the state transition is correct. This page is about the quieter half of the guarantee — the half that, if you get it wrong, makes both kinds of proof worthless.

Here is the uncomfortable claim this page defends: a rollup can post a perfectly valid proof and still rob you, if it does not also publish the underlying transaction data. Correctness is not the same as availability. A proof tells you the new state root is right; it does not, by itself, tell you what the new state actually is. And if you cannot reconstruct the state — your own balance included — you cannot spend, you cannot exit, and no one can build the very fraud proof the security model depends on. That gap is called the data-availability problem, and once you see it, you see why Ethereum’s entire scaling roadmap (blobs, danksharding) is aimed at it rather than at making the EVM faster.

What “data availability” actually means

Section titled “What “data availability” actually means”

Data availability (DA) is the guarantee that the data behind a batch was actually published, so that anyone who wants it can download it. That is the whole definition. It is not about storage forever, and it is not about correctness. It is a much narrower, sharper property: at the moment a rollup announced “I processed these N transactions and the new state root is X,” was the content of those N transactions made public, so that any independent party could fetch it and check the claim for themselves?

Split the two things a rollup asserts about a batch, because the whole page turns on keeping them separate:

   A rollup batch makes TWO claims. Do not conflate them.


   (1) VALIDITY / CORRECTNESS   "applying these txs to the old state
                                 yields new state root X"
                                 └─ proven by: a validity proof (ZK)
                                    or the absence of a fraud proof (optimistic)


   (2) AVAILABILITY             "here are the actual txs — anyone can
                                 download the bytes and see them"
                                 └─ proven by: the data being PUBLISHED
                                    somewhere every verifier can reach


   You need BOTH. A true-but-unavailable batch is as dangerous as a false one.

Verification-by-everyone — the property this whole book keeps returning to — is impossible without (2). A full node’s job is to independently re-derive the state from raw transactions so it trusts no one. If the raw transactions were never published, there is nothing to re-derive from. The node is reduced to believing the operator’s summary, which is exactly the trusted-middleman failure the overview warned against. Availability is not a nice-to-have bolted onto rollups; it is the precondition that makes “don’t trust, verify” mean anything at all.

Why data availability is required even for ZK rollups

Section titled “Why data availability is required even for ZK rollups”

The instinct after the last page is: ZK rollups attach a validity proof, so L1 mathematically confirms the state transition is correct — surely that’s enough? It is not, and understanding why is the crux of this page.

A validity proof proves a relationship: “there exists a set of transactions that, applied to the old state root, produces the new state root, and every one of them was valid.” It proves that such a batch exists. It does not hand you the batch. The proof can be true while the transactions themselves are locked in the operator’s private database.

Now put yourself in the user’s shoes. You want to know your balance so you can spend it. Where does your balance live? In the rollup’s state — a big Merkle/Verkle tree whose root L1 now knows. To produce a spendable claim on your funds you need the tree, not just its root: you need the current leaves and the Merkle path that proves your account’s balance under that root. You reconstruct that tree by replaying every transaction from the published data. No data, no tree; no tree, no proof-of-balance; no proof-of-balance, no way to move or exit your money.

   What the pieces give you:


   validity proof  ─►  "the new root X is correct"        (you believe the root)
   published data  ─►  replay txs ─► rebuild the state ─► your Merkle proof
                                                          (you can now EXIT / spend)


   With the proof but NOT the data:
     the root is provably correct, and you are provably locked out.

This is the counter-intuitive result worth memorizing: a ZK proof guarantees you the state is correct, and gives you no ability whatsoever to act on it. It is a certified-accurate ledger you are not allowed to read. That is why even the most cryptographically pure ZK rollup, to inherit L1 security, must publish its transaction data on Ethereum. The proof and the data solve two different problems, and you are not safe until both are solved.

The failure mode: the data-withholding attack

Section titled “The failure mode: the data-withholding attack”

Give the abstraction teeth with the concrete attack it defends against. Call it the data-withholding attack, and walk it through both rollup families.

A dishonest rollup operator (a sequencer) produces a batch, commits the new state root to L1, and — crucially — does not publish the transactions that justify it. It keeps the data private.

Against an optimistic rollup. The security model says “assume the batch is honest unless someone submits a fraud proof within the challenge window.” A fraud proof is a re-execution: to build one, a watcher must take the disputed transactions, run them, and demonstrate the operator’s claimed root is wrong. But you cannot re-execute transactions you were never given. By withholding the data, the operator makes the fraud proof impossible to construct. The challenge window elapses with no challenge — not because the batch was honest, but because no one could prove it wasn’t. A false state finalizes. The safety mechanism didn’t fail; it was starved of its input.

Against a ZK rollup. The validity proof still forces the arithmetic to be honest — the operator cannot commit to a state root that doesn’t follow from some valid batch. So they cannot mint themselves coins. But they can still freeze everyone out: by withholding the data, they deny every user the state they need to build an exit proof. Your funds are provably intact and completely inaccessible. The operator holds the ledger hostage. Depending on the rollup’s escape-hatch design, this can range from a temporary liveness failure to a permanent loss if there is no data-independent way to force-exit.

   THE DATA-WITHHOLDING ATTACK


   operator: commit new state root to L1  ✔   (visible)
   operator: publish the batch's txs      X    (WITHHELD)


   optimistic rollup ─► no data ─► no fraud proof can be built
                                   ─► a lie finalizes unchallenged
   zk rollup         ─► arithmetic stays honest (proof forces it)
                        BUT no data ─► no user can build an exit proof
                                   ─► funds frozen / held hostage


   In BOTH cases the proof machinery is intact and USELESS,
   because its fuel — the published data — was withheld.

The lesson is blunt: a validity proof or a fraud proof is only as strong as the availability of the data it operates on. Withhold the data and you have neutralized a mechanism that, on paper, looked airtight. This is why “is the data available?” is not a footnote — it is the question the whole security model quietly rests on.

On-chain DA vs off-chain DA: rollup vs validium

Section titled “On-chain DA vs off-chain DA: rollup vs validium”

Because publishing data to Ethereum L1 costs real gas, and because that cost dominates a rollup’s economics (the overview showed the per-user cost is batch overhead ÷ N), there is enormous pressure to put the data somewhere cheaper. Where a system publishes its data is exactly what separates a true rollup from its weaker cousins. This is the single most important classification in L2 design, and it is a security distinction, not a performance one.

  • On-chain DA (a true rollup). The transaction data is published on Ethereum itself — historically in calldata, now in blobs. Ethereum’s own consensus guarantees the data was available: if it weren’t, the block wouldn’t have been valid, and the whole network wouldn’t have accepted it. Availability inherits full L1 security. Anyone, at any time, using only Ethereum, can reconstruct the rollup’s state and challenge or exit. This is what earns the name rollup.
  • Off-chain DA (a validium, or a rollup backed by a DA committee). The proof still goes to L1 — so correctness is still enforced — but the data is kept off Ethereum: held by a Data Availability Committee (DAC), a set of signers who attest “yes, we have the data and will serve it,” or on a separate DA network. This is cheaper, sometimes dramatically so, because you are not paying L1 for the bytes. But availability now rests on a weaker trust assumption: you are trusting that committee (or that external network) not to collude and withhold. If they do, you are back in the data-withholding attack — with a valid proof and no way to exit.
   PROOF (correctness)        DATA (availability)         name
   ─────────────────────      ──────────────────────      ─────────
   on L1                      on L1  (calldata/blobs)     ROLLUP      full L1 security
   on L1                      off-chain (DAC / DA net)    VALIDIUM    weaker: trust the committee
   on L1                      on-chain when contested     VOLITION    user picks, per-tx


   Everyone posts the proof. The security tier is decided by WHERE THE DATA LIVES.

A volition lets each user choose per transaction: rollup-mode (data on L1, full security, higher cost) or validium-mode (data off-chain, committee trust, lower cost). The mere existence of volition makes the point unmissable — the proof is held constant across both modes, and the entire security difference is where the data goes. Data availability is the variable that sets the trust level.

Map this back to the part’s recurring test: if the L2 lies, can I still appeal to a chain I don’t have to trust, and win? For a true rollup the answer is yes, because the data is on that chain. For a validium the answer is only if the committee cooperates — you have swapped a trustless guarantee for a trust-minimized one. That is a legitimate engineering trade for some applications (high-throughput gaming, exchanges), but you must make it with eyes open: off-chain DA is not a rollup, and it does not inherit L1 security.

The scaling tension, stated precisely

Section titled “The scaling tension, stated precisely”

Now the bottleneck is visible. Making a rollup secure means publishing all its transaction data on L1 so anyone can download it. But L1 block space is scarce and expensive — that scarcity is the fee market doing its job. So a rollup’s cost and throughput are governed not by how fast it computes off-chain (which is cheap and unbounded) but by how much data it must publish on-chain per batch. Data availability is the scaling ceiling.

That reframes the entire roadmap. The goal is not “make Ethereum compute faster.” It is “make it possible to publish far more data, and to verify that data is available, without asking every node to download all of it.” Hold that thought — it is the exact problem EIP-4844 blobs and danksharding exist to solve.

Data-availability sampling — verify availability without downloading everything

Section titled “Data-availability sampling — verify availability without downloading everything”

There is one more idea to plant, because the whole danksharding endgame rests on it. If security demands far more data on-chain than today, and if you still want ordinary people to verify the chain on modest hardware, you hit a wall: you cannot ask every light node to download every megabyte of every rollup’s data. That would re-create the very “bigger nodes, fewer verifiers” trap the overview rejected. So how can a node that downloads only a tiny fraction of the data become confident that all of it was published?

The answer is data-availability sampling (DAS), and it is genuinely clever. It works in two moves:

  1. Erasure coding. The data is expanded with a Reed–Solomon-style code so that the original can be reconstructed from any sufficiently large fraction of the pieces (say, any 50%). A crucial consequence: to hide any of the original data, a malicious publisher must withhold more than half of the encoded pieces. Small partial withholding becomes impossible — either almost everything is available, or a large, conspicuous fraction is missing.

  2. Random sampling. A light node then requests a handful of randomly chosen pieces. If the publisher is withholding enough to actually hide data (>50% of pieces), then each random request has a high chance of asking for a missing piece. A few dozen successful random samples drive the probability that a large fraction is secretly missing down to negligible. The node has verified availability probabilistically, without downloading the whole thing.

   DATA-AVAILABILITY SAMPLING, in one picture


   1. erasure-code the data:  original ──► expanded (reconstructable from ~50%)
      to hide ANY original byte, an attacker must withhold >50% of pieces.


   2. each light node asks for K random pieces:
        all K return  ─► availability very likely (repeat across many nodes)
        one is missing ─► alarm: data is being withheld


      P(large withholding goes undetected) shrinks fast with K and with
      the number of independent samplers. Many light nodes, each doing a
      little, collectively guarantee the whole blob is available —
      and NO single node downloaded all of it.

Notice what DAS buys: it lets the network scale the amount of available data with the number of participants, instead of demanding every participant handle the full load. It is the same trustless spirit as the rest of the book — don’t believe, check — but adapted so the check is cheap enough to survive at scale. DAS is why danksharding can aim for many large blobs per block while still being verifiable on a laptop. For now, hold the intuition: erasure coding makes partial hiding impossible; random sampling makes large hiding overwhelmingly detectable.

Under the hood — commitments, and the “is this the right piece?” problem

Section titled “Under the hood — commitments, and the “is this the right piece?” problem”

Sampling only works if a sampled piece can be checked against a commitment the whole network agreed on. Otherwise a malicious node could answer your random request with a plausible-looking but fabricated piece, and you’d accept garbage. So availability schemes pair erasure coding with a cryptographic commitment to the data — a short fingerprint, posted on-chain, that every piece can be proven to belong to.

Ethereum’s blob design uses a KZG polynomial commitment for this. The intuition, without the algebra:

  • The data is treated as the evaluations of a polynomial. The commitment is a single short value (a curve point) that binds that entire polynomial — you cannot find a different polynomial with the same commitment.
  • For any point, the prover can supply a tiny opening proof that “the polynomial committed to here really does take this value at that position.” The verifier checks it in constant time, without the rest of the data.
   commitment C  (short, on-chain)  ── binds ──►  the whole blob's polynomial


   sampled piece  +  opening proof  ──►  verifier checks: "does this piece
                                          match C at this position?"  O(1)


   => a node can trust each random sample it pulls WITHOUT trusting the peer
      that served it, and without holding the full blob.

This is the missing ingredient that makes sampling sound rather than merely hopeful: erasure coding forces large-scale withholding, random sampling detects it, and the commitment guarantees each sampled piece is authentic. The blobs page is where these KZG commitments first ship in production (for whole-blob verification), and danksharding is where they get extended to per-cell sampling. You don’t need the cryptography to hold the DA argument — but you should know availability rests on a committed structure, not raw bytes handed over on trust.

The architect’s lens

Section titled “The architect’s lens”
  • Why does it exist? Because a rollup’s security is not delivered by its proof alone. A proof certifies the state is correct; data availability certifies the state can be reconstructed and acted on by anyone. Without it, verification-by-everyone and force-exit are impossible, and the whole trust model collapses to “trust the operator.”
  • What problem does it solve? The data-withholding attack: an operator that commits a state root but hides the transactions, starving optimistic fraud proofs of their input and freezing ZK-rollup users out of their funds. Guaranteed availability makes withholding either impossible (on-chain DA) or detectable (sampling).
  • What are the trade-offs? On-chain DA gives full L1 security but is the dominant cost of running a rollup, because L1 block space is scarce and expensive. Off-chain DA (validium) is far cheaper but demotes you from a trustless guarantee to trusting a committee not to withhold.
  • When should I avoid it (on-chain DA)? When the application can genuinely tolerate a weaker trust assumption for a large cost saving — high-frequency gaming or an exchange’s internal ledger, where a committee-backed validium’s throughput matters more than a hard force-exit guarantee. Never for a system that must let users exit without anyone’s permission.
  • What breaks if I remove it? Every downstream safety mechanism. Remove available data and fraud proofs cannot be built, exit proofs cannot be constructed, full nodes cannot re-derive state, and a rollup silently becomes a trusted database with a valid-looking proof stapled to it — passing correctness checks while robbing or freezing its users.

Check your understanding

Section titled “Check your understanding”
  1. In one sentence each, distinguish the two claims a rollup batch makes — validity and availability — and explain why a valid-but-unavailable batch is as dangerous as an invalid one.
  2. A ZK rollup posts a validity proof that L1 verifies. Why does that proof, on its own, still leave a user unable to spend or exit their funds? What extra thing do they need, and what do they do with it?
  3. Walk through the data-withholding attack against an optimistic rollup and against a ZK rollup. Why is the outcome different, and why is neither acceptable?
  4. Distinguish on-chain DA from off-chain DA using the true-rollup-vs-validium split. Both post the proof to L1 — so what exactly is the security difference, and how does the part’s recurring test come out for each?
  5. Explain data-availability sampling in two moves. Why does erasure coding force an attacker to withhold more than half the pieces, and how does random sampling turn that into a check a light node can do without downloading everything?
Show answers
  1. Validity is the claim that applying the batch’s transactions to the old state root yields the new root X (correctness). Availability is the claim that the actual transaction bytes were published so anyone can download them. A valid-but-unavailable batch is as dangerous as an invalid one because no one can reconstruct the state from it — you cannot build a fraud proof, an exit proof, or re-derive your balance — so you are forced to trust the operator, which is the exact failure the security model exists to prevent.
  2. A validity proof proves only that some valid batch produces root X; it does not hand you the batch. Your balance lives as a leaf in the rollup’s state tree, and to spend or exit you need a Merkle proof of that leaf under root X. You build that proof by replaying every transaction from the published data to rebuild the tree. So the extra thing you need is the published transaction data; with it you reconstruct the state and produce your proof-of-balance. Without it the proof certifies a ledger you cannot read.
  3. Optimistic: fraud proofs require re-executing the disputed transactions; withholding the data makes that impossible, so the challenge window elapses unchallenged and a false state finalizes — the safety mechanism was starved of its input. ZK: the validity proof still forces the arithmetic to be honest (the operator can’t mint coins), but withholding the data denies every user the state needed to build an exit proof, so funds are provably intact yet frozen/held hostage. The outcomes differ (false-state-finalizes vs funds-frozen) because the proof types constrain different things, but neither is acceptable — both let a dishonest operator harm users despite intact proof machinery.
  4. On-chain DA (rollup): data is published on Ethereum itself (calldata/blobs), so availability inherits full L1 security — anyone can reconstruct state and exit using only Ethereum. Off-chain DA (validium): the proof still goes to L1 (correctness enforced) but the data is held by a DA committee or external network, so availability rests on trusting that committee not to collude and withhold. The security difference is entirely where the data lives, not the proof. The recurring test — if the L2 lies, can I appeal to a chain I don’t have to trust and win? — comes out yes for the rollup and only if the committee cooperates for the validium.
  5. Move 1 — erasure coding: the data is expanded with a Reed–Solomon-style code so the original is reconstructable from any ~50% of the pieces; therefore, to hide any original byte, an attacker must withhold more than half of the encoded pieces — small partial withholding is impossible. Move 2 — random sampling: a light node requests a handful of randomly chosen pieces; if more than half are being withheld, each random request is likely to hit a missing piece, so a few dozen successful samples drive the probability of undetected large-scale withholding to negligible. Together they let a node verify availability probabilistically while downloading only a tiny fraction, so availability scales with the number of samplers instead of demanding everyone download everything.