Data Availability: The Foundation of Modular Blockchains
Data availability ensures blockchain nodes can always verify transactions. Learn how DA works, why it matters for rollups, and which DA layers are leading.
Key takeaways
- Data availability (DA) is the guarantee that all data required to validate a block is accessible to every participant in the network.
- DA ≠ Data Storage ≠ Data Retrievability. Each concept serves a different function. Conflating them leads to a misunderstanding of how modern blockchain security actually works.
- The DA problem arises when data volume grows faster than nodes can reasonably download and verify, making decentralized participation increasingly expensive.
- Modular blockchains solve this by separating DA into a dedicated layer, allowing rollups and L2s to publish data cheaply without compromising the base layer.
Data availability is what makes "don't trust, verify" actually possible. Without it, any node that wants to independently check the blockchain's state cannot, because the data it needs simply isn't there. In a one-line definition: DA is the assurance that all data required to validate a new block has been published and is accessible to the entire network.
This concept sits quietly underneath every major scaling discussion happening in crypto today. From Ethereum's rollup roadmap to the rise of modular blockchains, DA is the reason some architectures scale and others fail silently.
What Is Data Availability (DA) in Blockchain?
| Quick answer: Data availability is the property that guarantees every network participant can access the full data behind a proposed block – not just a summary or commitment, but the actual underlying transactions needed to verify it. |
Three concepts are easy to confuse here, but each means something distinct:
Concept | What it guarantees |
| Data Availability | Data has been published and is accessible right now for verification |
| Data Storage | Data is preserved somewhere in the long term |
| Data Retrievability | Data can be fetched upon request (but may not be live or public) |
A system can have retrievability without availability. For example, data stored in a private server can technically be "retrieved" but isn't available to independent verifiers. In blockchain, DA specifically means: can any node right now download and verify this block?
DA works like streaming a live sports match. It's about anyone being able to tune in and watch it as it happens. If the stream is blocked, you lose the ability to verify what occurred in real time, even if a recording might exist later.
Why this matters for trustlessness: Blockchains operate on the principle of "don't trust, verify." For this to hold, every participant must be able to independently check any block at any time. If a block producer publishes a block header but withholds the underlying transaction data, no independent node can confirm whether the block is valid. The "trustless" claim collapses the moment DA fails.
Why Is Data Availability Important?
| Quick answer: DA is important because without it, the entire security model of a blockchain can be silently undermined through a quiet omission of data. It is the difference between a network that can be independently audited and one where participants have to trust someone else's word. |
As blockchains grow, a structural tension emerges:
- More transactions → more data per block
- More data per block → higher cost and bandwidth to run a full node
- Higher node costs → fewer independent verifiers → more centralization
This is what's known as blockchain bloat, and it compounds over time. Ethereum's own history shows this clearly. As L2 adoption grew, rollups had to post their transaction data directly into Ethereum calldata, competing for the same block space as regular L1 transactions. This drove up fees for both L1 and L2 simultaneously.
The more serious variant is the data withholding attack. A malicious block producer publishes a block header (which looks valid) but withholds the transaction data behind it. Light nodes, which only check headers, cannot detect this. If other nodes can't download the data to re-execute and verify, they can't catch fraud. The result is that invalid state transitions can go undetected.
The stakes for rollups are especially high. Data availability accounts for roughly 95% of the costs that rollups pay. When DA is cheap and abundant, rollup economics improve dramatically. When it's scarce or expensive, it chokes the entire L2 ecosystem.
How DA Works in Modular Blockchain Architecture
| Quick summary: In modular blockchains, DA is separated into its own dedicated layer – independent from execution, settlement, and consensus. This separation is what allows each component to be optimized independently, rather than forcing every function to compete for the same limited resources. |
Here's how the full flow works in practice:
Step 1. Transactions are executed
A user submits a transaction to a rollup or L2 network. The rollup's sequencer processes it, running the smart contract logic, updating balances, and computing the new state.
Step 2. Transaction data is published
The rollup batches its transactions and publishes the raw data to a DA layer (this could be Ethereum blobs, Celestia, Avail, or another DA layer). The DA layer does not execute the transactions. Its sole role is to order, store, and prove that the data is available.
Step 3. Nodes verify data availability
Network nodes (including light nodes, depending on the DA solution) confirm that the data has been published and is accessible. In DAS-based systems, this doesn't require downloading the full dataset. Nodes sample random chunks and use cryptographic proofs (e.g., erasure coding + KZG commitments) to confirm the whole block is available.
Step 4. Users can independently reconstruct the blockchain state
Because the raw transaction data is available, any participant can re-execute those transactions and verify that the final state reported by the rollup is correct. This is what makes the system verifiable without trusting the rollup operator.
Author's note on what this changes:
The modular split of DA from execution is a more significant architectural shift than it appears. In a monolithic chain, a block producer who controls both execution and data publication has strong incentives to publish selectively – to show a favorable outcome and hide the supporting data. Separating these into distinct layers with different validator sets and incentives removes this single point of trust. What used to require trusting one actor now requires coordinating a failure across two independent systems. That's a structural change to the threat model. The most important insight in modular architecture is that it makes certain classes of attacks economically irrational rather than just technically difficult.
Current DA Solutions Compared
There is no single "best" DA solution. Each approach trades off between cost, decentralization, trust assumptions, and throughput. Choosing between them is one of the core architectural decisions facing any rollup builder today.
Quick comparison:
Celestia | Avail | EigenDA | |
| Architecture | Independent chain, DAS + fraud proofs | Independent chain, DAS + KZG (validity proofs) | DAC model, built on EigenLayer restaking |
| Throughput (current) | ~1.33 MB/s (8 MB blocks) | Comparable to Celestia | 15 MB/s (100 MB/s in V2 tests) |
| Trust model | Trust-minimized, publicly verifiable | Trust-minimized, publicly verifiable | Relies on restaker economic security; not publicly verifiable |
| Cost | ~$0.001–$0.81/MB | Comparable | Lower per MB for high-volume apps |
| Best for | Sovereign rollups, modular-first projects | Multichain / chain-agnostic apps | Ethereum-aligned rollups needing high throughput |
On-chain DA (Ethereum + EIP-4844 blobs)
The original approach: rollups post transaction data directly to Ethereum L1 as calldata, permanently stored on-chain. Before EIP-4844, this was the only option, and it was expensive, because rollup data competed with regular L1 transactions for block space.
EIP-4844 (Proto-Danksharding), shipped with Ethereum's Dencun upgrade in March 2024, changed this by introducing a new transaction type: blob-carrying transactions. Blobs are large data chunks attached to blocks, stored temporarily by consensus nodes for roughly 18 days before being pruned – unlike calldata, which is stored permanently.
Key updates since launch:
- BPO1 (Dec 2025): Blob target raised from 6 to 10, max from 9 to 15
- BPO2 (Jan 2026): Blob target raised to 14, max to 21, tripling original capacity in one month
- Planned roadmap: Target of 128 blobs per slot under full Danksharding; PeerDAS expected late 2026 or early 2027
The combined L2 ecosystem currently processes approximately 5,600 TPS, with projections of 24,000+ TPS as blob capacity continues to expand.
Trade-offs:
Pros | Cons |
✅ Maximum security and decentralization (Ethereum's full validator set) ✅ No external trust assumptions | ❌ Most expensive option per MB ❌ Limited throughput compared to dedicated DA layers |
Data Availability Committees (DAC)
A DAC is a small, permissioned group of trusted entities that store data off-chain and publish signed attestations confirming the data is available. The blockchain only stores these attestations.
Examples: StarkEx, Arbitrum Nova, and older versions of several validiums.
Trade-offs:
Pros | Cons |
✅ Very cheap and fast ✅ High throughput | ❌ Requires trusting committee members. If they collude or go offline, data can be lost or censored ❌ Users cannot independently verify availability without relying on the committee's signatures |
DACs work well for use cases where throughput matters more than trustlessness, such as gaming applications or high-frequency trading environments that accept a lighter trust model.
Data Availability Sampling (DAS)
DAS is a cryptographic technique that allows nodes to verify the availability of an entire block by downloading only a small, random sample of it, rather than the full dataset. This is enabled by erasure coding, which encodes data so that the full block can be reconstructed from any sufficiently large subset of chunks.
Even a lightweight node with limited bandwidth can participate in DA verification. This is a breakthrough for scalability. It means block sizes can grow without requiring every node to download proportionally more data.
DAS is the core technology behind Celestia and Avail DA, and is on Ethereum's roadmap under full Danksharding (via PeerDAS).
Trade-offs:
Pros | Cons |
✅ Trust-minimized – anyone can verify without downloading everything ✅ Enables large blocks without centralizing verification | ❌ Requires a sufficiently large and honest set of light nodes for security guarantees ❌ More complex to implement and audit than simpler models |
Dedicated DA Layers (Celestia, Avail, EigenDA)
These are blockchains or services purpose-built to provide DA as their sole function – no smart contracts, no native execution, no settlement. Rollups publish data here instead of to a congested L1.
All three combine some form of erasure coding and cryptographic proofs (KZG commitments or fraud proofs) to ensure data integrity at scale.
Leading DA Projects Today
| Quick summary: The DA layer market is a competitive infrastructure sector with measurable adoption, distinct technical philosophies, and real economic stakes for rollup builders. |
Celestia (TIA)
Celestia pioneered the dedicated DA layer category and remains the market leader. Its architecture is intentionally minimal: no smart contracts, no dApps – only blobspace and consensus. Rollups treat Celestia like an external data hard drive, publishing transaction data without touching Ethereum.
By mid-2025, more than 56 rollups were using Celestia as their DA layer, including deployments on Arbitrum Orbit, OP Stack, and Polygon CDK. The network has processed over 160 GB of rollup data in total and commands roughly 50% of the dedicated DA market. The Matcha upgrade (January 2026) enabled 128 MB blocks while reducing node storage requirements by 77%, significantly improving the economics for validators.
In March 2025, Eclipse's data posting cost averaged approximately $0.07/MB on Celestia, versus roughly $3.83/MB for Ethereum blobs, making Celestia over 55× cheaper per MB at that point in time.
EigenDA
EigenDA takes a fundamentally different approach. Rather than building a new chain, it leverages EigenLayer's restaking model. Ethereum validators who have restaked their ETH can opt in to provide DA guarantees, earning fees for doing so. This means EigenDA inherits Ethereum's economic security without requiring users to trust a new validator set from scratch.
Current throughput: 15 MB/s, with V2 tests reaching 100 MB/s – significantly higher than Celestia's current mainnet numbers. The operator network exceeds 200 nodes with over 40,000 individual restakers. Notable integrations include Mantle Network (reporting up to 80% cost reduction) and ZKsync Elastic Network.
Because EigenDA operates as a DAC rather than a publicly verified blockchain, end users cannot independently verify data availability. They rely on economic guarantees and slashing risks. For applications prioritizing raw decentralized verifiability, this matters.
Avail DA
Avail originated from Polygon but was designed as a chain-agnostic DA layer from day one, not tied to Ethereum or any single execution ecosystem. Unlike Celestia (fraud proofs) or EigenDA (DAC), Avail combines DAS with KZG polynomial commitments (validity proofs), providing faster cryptographic finality for data availability without a challenge period.
For a deeper look at how these two proof systems differ in rollup security, see Fraud Proofs vs. Validity Proofs: Key Differences in Rollup Security.
Avail is also building a broader modular infrastructure stack. Nexus (interoperability layer) and Fusion (security network layer) to complement its DA layer. It has secured 70+ partnerships, including Arbitrum, Optimism, Polygon, StarkWare, and zkSync.
Data Availability vs Data Storage vs Data Execution
These three terms are often used interchangeably, but they describe fundamentally different properties of a blockchain system. Conflating them can lead to serious architectural misunderstandings:
- Data Availability asks: Can every node verify right now that a block's data has been published? This is about presence and accessibility in the present moment. It's the property that makes independent verification of block validity possible. It doesn't require the data to be stored permanently.
- Data Storage asks: Where and for how long is data kept? Storage is about persistence, keeping data around for future queries, historical reference, or dispute resolution. Ethereum's calldata is permanently stored. Blobs introduced by EIP-4844 are pruned after ~18 days. Data stored on Filecoin or Arweave is designed for long-term preservation. A system can have robust storage while failing at availability (data exists somewhere but isn't accessible to verifiers).
- Data Execution asks: Who processes the logic of transactions and computes state changes? Execution is what runs smart contracts and updates balances. In a modular stack, this is entirely separate from DA. A rollup sequencer handles execution, while the DA layer only receives and proves the data that resulted from that execution. Celestia, for example, performs zero execution. It is a pure DA layer.
A useful summary:
DA = "Is this data available right now for anyone to verify?" Storage = "Will this data exist tomorrow, next year, forever?" Execution = "Who ran the logic that produced this data?"
In a modular blockchain, these three functions are separated by design. In a monolithic blockchain, they happen on the same layer, creating the throughput ceiling that modular architectures are built to break.
The Future of Data Availability
| At a glance: DA is transitioning from a niche infrastructure concern to the central battleground of blockchain scalability, and the architecture decisions being made today will define which rollups survive, how much transactions cost, and whether decentralized applications can reach mass-market scale. |
Several trajectories are worth watching:
1. Ethereum's path to full Danksharding
EIP-4844 was always a stepping stone. The full Danksharding specification targets 128 blobs per slot, combined with PeerDAS (Peer Data Availability Sampling) so validators only need to sample portions of blobs rather than download them entirely. This would multiply Ethereum's DA throughput by an order of magnitude. PeerDAS is expected to roll out in late 2026 or early 2027.
2. The DA market structure
By 2025, over 80% of Layer 2 activity was already relying on dedicated DA layers rather than Ethereum's base layer. The competitive dynamic is increasingly clear: Celestia competes on cost and sovereignty, EigenDA on throughput and Ethereum alignment, Avail on multichain flexibility. Each is attracting a distinct cluster of rollups. This fragmentation has real consequences. Rollups built on different DA layers cannot easily share liquidity or composability without bridges or intent protocols.
3. DA as commodity vs. DA as ecosystem
There's an argument that raw DA will eventually be commoditized. If that happens, the real competition shifts to ecosystem effects: which DA layer becomes the default in Arbitrum Orbit, OP Stack, or Polygon CDK tooling. Celestia's early-mover advantage here is significant. EigenDA's integration depth with EigenLayer is a counterweight. The winner of the infrastructure layer war won't necessarily be the technically superior option. It'll be the one developers reach for first.
Sources & Further Reading
- Ethereum.org – "Data Availability" https://ethereum.org/en/developers/docs/data-availability/
- Ethereum.org – "Danksharding" https://ethereum.org/en/roadmap/danksharding/
- Ethereum Improvement Proposals – "EIP-4844: Shard Blob Transactions" https://eips.ethereum.org/EIPS/eip-4844
- Celestia – "What Is Data Availability?" https://celestia.org/what-is-da/
- Avail Project – "A Guide to Selecting the Right Data Availability Layer" https://blog.availproject.org/a-guide-to-selecting-the-right-data-availability-layer/
FAQs About Data Availability in Blockchain
Technically, a chain can continue to produce blocks without full DA, but it loses the property that makes it trustless. Users and light nodes must then rely on third parties (validators, committees, or operators) to verify state correctness on their behalf. This reintroduces trust assumptions that blockchain was designed to eliminate.
