Data Availability Sampling (DAS)

What Is Data Availability Sampling?

Data availability sampling is a technique that lets blockchain nodes confirm a block's data was published to the network without downloading the entire block. Instead of requiring every node to fetch all block data, DAS lets each node randomly request a small number of chunks and use cryptographic proofs to verify their correctness. If enough random samples check out, the node gains a high probabilistic guarantee that the full data is available and reconstructable.

The core problem DAS solves is straightforward: rollups post transaction data to a base layer so that anyone can reconstruct state and verify execution. But as the volume of rollup data grows, requiring every node to download everything defeats the purpose of scaling. A block producer could also publish a block header while withholding the underlying data, preventing others from verifying transactions. DAS ensures that even resource-constrained light clients can catch this attack without trusting anyone.

How It Works

DAS combines three components: erasure coding to add redundancy, polynomial commitments to enable verification, and random sampling to provide probabilistic guarantees.

Erasure Coding

Before sampling can happen, block data is expanded using Reed-Solomon erasure coding. This transforms the original data into a larger dataset with built-in redundancy:

1. The original block data (M chunks) is treated as evaluations of a polynomial
2. The polynomial is evaluated at additional points, producing 2M total chunks (a 2x extension)
3. Any M of the 2M chunks are sufficient to reconstruct the original data

This means a malicious block producer must withhold at least 50% of the extended data to prevent reconstruction. Even hiding a small portion of the original data causes roughly half the extended data to be missing, making the withholding attack detectable with relatively few random samples.

In practice, many DAS implementations use a 2D erasure coding scheme. The data is arranged in a square matrix and erasure-coded in both row and column dimensions. For a k x k original matrix, the extended matrix becomes 2k x 2k. This reduces fraud proof sizes and simplifies verification compared to 1D encoding.

KZG Polynomial Commitments

Sampling alone is not enough: a node must verify that each sampled chunk is consistent with the committed data. DAS uses KZG (Kate-Zaverucha-Goldberg) polynomial commitments for this purpose. A block producer commits to the data polynomials, and any node can verify a sampled chunk against the commitment with a compact proof.

Key properties of KZG commitments that make them ideal for DAS:

• Constant proof size: each commitment and proof is 48 bytes, regardless of the dataset size
• Fast verification: checking a proof requires only two elliptic curve pairing operations
• Homomorphic: commitments can be combined algebraically, enabling consistency checks across rows and columns of 2D-encoded data

KZG commitments require a one-time trusted setup ceremony to generate public parameters. Ethereum's KZG ceremony attracted over 141,000 contributors, and the scheme's security requires only that a single participant was honest and destroyed their secret contribution.

Random Sampling and Probabilistic Guarantees

With erasure coding and commitments in place, the sampling process is simple: a light client randomly requests a small number of chunks from different network peers and verifies each against the KZG commitment. If all sampled chunks are valid and available, the node concludes the full data was published.

The security guarantee is probabilistic. With 2D erasure coding, an attacker must withhold at least 25% of shares to prevent reconstruction. Each random sample has a 3/4 chance of hitting an available chunk even when data is being withheld. For Q independent samples, the probability of falsely accepting unavailable data is (3/4)^Q:

With roughly 30 random samples, a light node achieves 99.99% confidence that the data is available. When many light nodes sample independently, the network collectively ensures enough data is sampled for full reconstruction.

Simplified DAS Flow

1. Block producer encodes data
   Original: [D1, D2, D3, D4]
   Erasure-coded: [D1, D2, D3, D4, E1, E2, E3, E4]
   (any 4 of 8 chunks reconstruct the original)

2. Block producer commits
   KZG commitment = Commit(polynomial)
   Published in block header alongside data roots

3. Light node samples
   Request random chunks: [D2, E4, D3]
   Verify each against KZG commitment
   All valid → high confidence data is available

4. Network-wide guarantee
   ~1,000+ light nodes each sample independently
   Collectively, enough chunks are verified for reconstruction

DankSharding and Ethereum's DAS Roadmap

Ethereum's approach to DAS follows a multi-phase rollout, building infrastructure incrementally:

Proto-Danksharding (EIP-4844)

Deployed in the Dencun upgrade (March 2024), proto-danksharding introduced blob-carrying transactions with KZG commitments and a separate fee market for blob data. However, it does not include data availability sampling: all nodes must still download every blob in full. Proto-danksharding established the transaction format and commitment scheme that full DankSharding will build upon, starting with a target of 3 blobs (roughly 384 KB) per block. For a deeper look at the economics, see the EIP-4844 blob fee market analysis.

PeerDAS (EIP-7594)

Activated in the Fusaka upgrade (December 2025), PeerDAS allows nodes to verify blob availability through peer-based sampling rather than downloading every blob. Blob parameters were raised from 6 to 14 (target) and 9 to 21 (max) per block. PeerDAS represents a major step toward full DAS but still does not implement the complete sampling protocol for light clients.

Full DankSharding

Named after researcher Dankrad Feist, full DankSharding is Ethereum's endgame for data availability. It targets up to 256 blobs per block (roughly 30 MB), a roughly 60x increase over proto-danksharding. The design uses 2D KZG commitments over a 512 x 512 sample matrix, where each validator stores a subset of rows and columns. Full DankSharding is targeted for post-2026, with no confirmed mainnet date yet.

Other Implementations

Several purpose-built data availability layers already use DAS in production, serving as the DA backend for rollups across multiple ecosystems:

• Celestia: launched in October 2023, uses 2D Reed-Solomon encoding with Namespaced Merkle Trees. Supports 8 MB blocks on mainnet and demonstrated 128 MB blocks on testnet (April 2025). Over 56 rollups use Celestia for data availability.
• Avail: uses KZG commitments (validity proofs rather than fraud proofs) with Nominated Proof-of-Stake consensus. Supports 4 MB blocks with 250ms pre-confirmations and roughly 20-second finality.
• EigenDA: built on EigenLayer's restaking infrastructure, uses Reed-Solomon coding with KZG commitments. Achieved 100 MB/s throughput in its V2 release, relying on economic security (slashing) rather than DAS-based light client verification.

Use Cases

Rollup Scaling

DAS is primarily designed to scale rollups. Both optimistic rollups and ZK-rollups need to post transaction data to a base layer so that anyone can reconstruct state and verify execution. Without DAS, the base layer's data throughput is bottlenecked by how much every node can download. With DAS, the base layer can support orders of magnitude more data without increasing individual node requirements.

Light Client Security

DAS dramatically improves the security model for light clients. Before DAS, a light client checking only block headers had no way to know whether the underlying data was actually published. It had to trust full nodes or accept the risk of data withholding attacks. With DAS, a light client can independently verify data availability using a few dozen random samples and modest bandwidth.

Modular Blockchain Architecture

The rise of modular blockchains separates execution, consensus, and data availability into distinct layers. DAS is the enabling technology for dedicated DA layers. Rollups can use a specialized DA layer with DAS guarantees instead of posting all data directly to an expensive execution layer, reducing costs while maintaining security.

Risks and Considerations

Network Assumptions

DAS relies on a sufficient number of honest light nodes sampling independently. If too few nodes participate in sampling, the network cannot guarantee enough chunks are verified for full reconstruction. Estimates suggest roughly 1,000 or more honest light clients are needed to ensure reliable reconstruction. A network partition or low light client adoption could weaken the guarantee.

Trusted Setup Requirements

KZG-based DAS schemes require a trusted setup ceremony. While Ethereum's ceremony had over 141,000 participants (requiring only one to be honest), the reliance on a one-time ceremony is a philosophical concern for some in the community. Alternative commitment schemes exist but come with tradeoffs in proof size and verification speed.

Reconstruction Complexity

While sampling is lightweight, actual data reconstruction from erasure-coded chunks is computationally expensive. If a full node needs to reconstruct missing data, it must perform polynomial interpolation across many chunks. In a 2D scheme, worst-case reconstruction may require 75% of shares (though recent research from a16z proposes reducing this to 25% through bivariate polynomial interpolation).

Quantum Vulnerability

KZG commitments rely on the hardness of the discrete logarithm problem on elliptic curves, which is vulnerable to quantum computers running Shor's algorithm. If sufficiently powerful quantum computers emerge, the trusted setup could be compromised. Research into post-quantum alternatives (such as hash-based commitments) is ongoing but involves significant tradeoffs in proof size and verification efficiency.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.