How Avail DA Works
How Avail DA guarantees data availability through erasure coding, KZG commitments, data availability sampling, and nominated proof-of-stake consensus.
Avail DA's core job is to guarantee that data posted by rollups is available for anyone to retrieve and verify. It achieves this through a pipeline of cryptographic techniques and a consensus mechanism designed specifically for this purpose.
When a rollup submits data to Avail, it goes through this pipeline:
Erasure coding spreads data across redundant "shards" so that the original data can be reconstructed even if some shards are missing. In Avail, each row of the block data matrix is erasure-coded, effectively doubling its size.
This matters because a malicious block producer trying to hide even a single transaction would need to withhold a large portion of the block. Random sampling by light clients becomes far more likely to catch the gap. Without erasure coding, a bad actor could hide a small piece of data that sampling might miss. With it, any attempt to hide data requires withholding so much that it's nearly impossible to evade detection.
Each row of the erasure-coded matrix is committed to using KZG commitments. These are compact cryptographic proofs included in every block header that provide two guarantees:
DAS is how light clients verify that block data is available without downloading entire blocks. The process works like this:
Avail uses Nominated Proof of Stake (NPoS) for validator selection, combined with two Substrate-based protocols for block production and finality:
Validators in Avail don't execute transactions. They attest that data has been correctly packaged into blocks with valid KZG commitments. This is a lighter workload than execution-based chains, which is why Avail can support larger block sizes without proportionally increasing validator requirements.
A supermajority of validators must sign off on a block header (which includes the KZG commitments and a Merkle root of the data) for it to be finalized via GRANDPA. Once finalized, the data is considered available and immutable.
Block data lifecycle
- Data submission — The rollup posts transaction data via a
submitDataextrinsic, tagged with its App ID. - Matrix construction — The block data is chunked and arranged into a 2D matrix of equal-sized cells.
- Erasure coding — Each row of the matrix is extended using Reed-Solomon erasure codes, adding redundancy.
- KZG commitments — Each row is committed to using KZG polynomial commitments. These commitments are included in the block header.
- Consensus — Validators attest to the block header (which contains the commitments), finalizing it.
- Data availability sampling — Light clients randomly sample cells from the matrix to verify the data is available.
Erasure coding
KZG polynomial commitments
- Binding — It's computationally infeasible to produce a commitment that matches incorrect data. If the commitment is valid, the data is correct.
- Efficient verification — A light client can verify that any individual cell belongs to the committed row without downloading the full row. This is what makes cell-level sampling practical.
Data availability sampling (DAS)
- A light client receives a new finalized block header containing KZG commitments.
- It randomly selects a set of cells from the block's data matrix.
- It retrieves those cells — first from the peer-to-peer DHT network, then via RPC if needed.
- It verifies each cell against the KZG commitment in the header.
- It calculates a confidence score — the probability that the full block data is available given the number of cells successfully verified.
Note
Light clients that verify cells also re-share them on the peer-to-peer network, increasing overall data availability for the network. The more light clients sampling, the stronger the DA guarantee becomes.
Consensus: how blocks are finalized
| Protocol | Role |
|---|---|
| BABE (Blind Assignment for Blockchain Extension) | Block production — validators are assigned slots to produce blocks |
| GRANDPA (GHOST-based Recursive Ancestor Deriving Prefix Agreement) | Finality — validators vote to finalize chains of blocks |
Note
Next steps
- Understand how rollup data is organized with App IDs.
- Learn how transaction pricing works for data submissions.
- Run your own light client to participate in DAS.
- Become a validator on the Avail network.
How is this guide?