What is a data availability layer, and how does Celestia's data availability sampling work? · Jumpstart Blockchain
What is a data availability layer, and how does Celestia's data availability sampling work?
A DA layer guarantees rollup data was published. Celestia erasure-codes blocks into a 2D square, so light nodes sampling a few random shares catch withholding; fraud proofs catch bad encoding.
A data availability layer is a chain whose main job is to order data and guarantee that it was actually published, so anyone who needs it can download it. It doesn't execute that data or check whether the transactions inside it are valid. Rollups need exactly this: their state can only be verified or challenged if the batch data behind it is public. Celestia is a chain built for that one job, and its key trick, data availability sampling (DAS), lets a light node become confident a large block was published by downloading only a few small random pieces of it.
The data availability problem
A block header commits to its data with a Merkle root. A light client can check that the header is signed by consensus, but a Merkle root says nothing about whether the data behind it was ever released. A malicious block producer can publish a valid-looking header and withhold part of the block.
For a rollup, that is fatal in different ways:
Optimistic rollups rely on someone re-executing batches to challenge a bad state root. If the batch is withheld, nobody can build a fault proof.
ZK rollups can prove the new state is valid, but if the transaction data is withheld, users can't reconstruct the state, prove their balances or exit.
Making everyone download every block fixes this, but caps throughput at what a modest node can handle. DAS removes that cap.
Modular vs monolithic chains
A monolithic chain such as Ethereum L1 or Solana does execution, settlement, consensus and data availability in one protocol. A modular stack splits them: a rollup executes, a settlement layer verifies proofs and bridges, and a DA layer orders and publishes data.
Celestia is deliberately minimal. It runs consensus (built with the Cosmos SDK and CometBFT, with TIA as its staking and fee token) and publishes data. It has no general-purpose smart contracts and never interprets the rollup data it stores.
How Celestia arranges a block
Block data is split into fixed-size shares of 512 bytes. The shares are laid out in a k × k original data square, then extended with 2D Reed-Solomon erasure coding:
Each row is extended with parity shares to length 2k.
Each column is then extended the same way, giving a 2k × 2k extended data square.
Every row and every column is now an erasure-coded codeword: any k of its 2k shares are enough to recover the whole row or column. The producer computes a Merkle root for each of the 2k rows and 2k columns, and the data root in the block header commits to all 4k of those roots.
The useful consequence is that to make the block unrecoverable, a producer has to withhold at least (k+1)² of the 4k² shares, which is just over 25% of the extended square. Hiding a small piece doesn't work, because honest nodes can rebuild it from the rest.
How light nodes sample
A light node downloads the header and the row and column roots, then asks the network for a handful of shares at random coordinates, each with a Merkle proof against its row or column root.
If the block is unrecoverable, at least 25% of shares are missing, so each random sample has at least a 1-in-4 chance of hitting a missing one. The chance that s samples all miss is at most:
P(undetected) <= (3/4)^s
s = 8 -> about 0.10
s = 16 -> about 0.010
s = 30 -> about 0.00018
The number of samples needed doesn't grow with block size. Bigger blocks mean more work for full nodes, but a light node's cost grows only with the number of row and column roots, the square root of the data.
Sampling has a collective side too. Enough light nodes sampling different shares means the network as a whole holds enough of the square to reconstruct it. Security therefore assumes a sufficient number of honest light nodes, and that each light node is connected to at least one honest full node.
Fraud proofs for bad encoding
Sampling proves shares are available, not that the producer extended the square correctly. A producer could fill parity shares with garbage, so that the "recoverable" data doesn't decode to what the roots commit to.
Celestia handles this with a bad encoding fraud proof (BEFP). A full node that reconstructs a row or column and finds that its shares aren't a valid Reed-Solomon codeword broadcasts the shares it has for that row, with Merkle proofs. A light node re-encodes that one row, sees the mismatch and rejects the block. The proof is only one row's worth of data, so it scales with the square root of the block, not the whole block.
Namespaced Merkle trees
Hundreds of rollups share one Celestia block, and each wants only its own data. Every share carries a namespace (a 1-byte version plus a 28-byte ID), and each row and column root is built as a namespaced Merkle tree (NMT). Leaves are sorted by namespace, and every internal node records the minimum and maximum namespace beneath it.
A node can then serve a rollup "all shares for namespace N" with a proof of completeness: the neighbouring namespace ranges show nothing in N was left out. A rollup node downloads its own data, not the whole block.
Blobs and PayForBlobs
Rollups publish data as blobs. A blob is submitted in a transaction containing a MsgPayForBlobs (PFB) message, which names the namespace, the blob size and a share commitment, a Merkle-style commitment to the blob's shares that later lets anyone prove the blob is included in a given block. The fee is paid in TIA, and the gas charged grows with the number of bytes (shares) the blob occupies.
With a running celestia-node light node, submitting and reading a blob from the CLI looks like this:
# submit a blob under a 10-byte user namespace
celestia blob submit 0x42690c204d39600fddd3 'gm'# fetch it back using the height and commitment returned above
celestia blob get HEIGHT 0x42690c204d39600fddd3 COMMITMENT
Rollups on Celestia and Blobstream
A chain that executes on its own, settles to Ethereum and posts data to Celestia needs Ethereum contracts to be convinced that the data really was published on Celestia. Blobstream relays commitments to Celestia data roots onto Ethereum and other EVM chains. Its newer versions, built with Succinct, use ZK proofs of a Celestia light client rather than a set of trusted signers. A settlement contract can then check a batch against a relayed data root.
Integrations exist for major rollup stacks, including OP Stack's alt-DA mode and Arbitrum Orbit; details change between releases, so check the framework's current docs.
Note the terminology: because the data isn't on Ethereum, L2BEAT-style classifications call such chains optimiums or validiums, not rollups. Their safety adds Celestia's consensus and Blobstream to the trust assumptions.
Compared with Ethereum's blobs and PeerDAS
Ethereum added its own blob space with EIP-4844 in the Dencun upgrade (March 2024): 128 KiB blobs committed with KZG polynomial commitments, priced in a separate blob fee market and pruned after about 18 days. Initially every consensus node downloaded every blob. Pectra (2025) raised the blob target.
PeerDAS (EIP-7594), shipped in the Fusaka upgrade in late 2025, brought sampling to Ethereum. Each blob is erasure-extended, and each node custodies and serves only some columns of the extended data, sampling the rest from peers. Blob-parameter-only forks since then have been raising blob limits step by step.
Celestia
Ethereum (EIP-4844 + PeerDAS)
Purpose
DA and ordering only
General-purpose L1 that also offers DA
Erasure coding
2D Reed-Solomon over the block
Per-blob extension, columns sampled by nodes
Commitments
Namespaced Merkle trees
KZG commitments
Bad encoding
Caught by fraud proofs (BEFP)
Ruled out by KZG proofs, no fraud proof needed
Who samples
Light nodes, by design
Mainly full and validator nodes
Fee token
TIA
ETH
Settlement on Ethereum
Via Blobstream; chain is a validium/optimium
Native; chain is a rollup
Summary
Data availability means a block's data was published and can be downloaded. It is not execution or permanent storage.
Celestia erasure-codes each block into a 2k × 2k square, so withholding anything meaningful requires hiding over a quarter of it.
Light nodes sample a few random shares; after s samples the chance of missing a withholding attack is at most (3/4)^s.
Bad encoding fraud proofs catch garbage parity; namespaced Merkle trees let each rollup fetch and verify only its own data.
Ethereum's blobs keep data on L1 with KZG commitments and now sample via PeerDAS. Choosing Celestia instead trades Ethereum's DA guarantees for Celestia's, bridged through Blobstream.
