When you look closely at how different blockchains scale, whether they’re monolithic, modular, or something in between, you eventually run into one unavoidable limitation:
can the nodes actually obtain all the data required to verify a block?
This problem is deceptively simple, but it defines the entire trust model of a blockchain. In the Bitcoin whitepaper, nodes must receive the full block to validate it. The Ethereum Yellow Paper requires full transaction input data for re-execution. Ethereum’s EIP-4844 and the Danksharding research introduce blob data that must be published and made available for sampling. Celestia’s DAS specifications require that nodes can reconstruct block data using probabilistic sampling. Even EigenDA, despite being a very different system, requires its AVS operators to store and serve replicated data chunks secured by restaked ETH.
Different languages, same rule:
if data is hidden, the security model collapses.
At its core, Data Availability (DA) is not a marketing term. It simply means that all the data needed to independently validate a block must be publicly accessible. Bitcoin expresses this through full block downloads. Ethereum expresses it through complete transaction inputs. Celestia uses data availability sampling. EigenDA uses replicated DA chunks validated by delegated operators. Architecturally they differ, but the expectation is identical — nodes must be able to retrieve every byte of data that influences state.
Blockchains implement this requirement in very different ways. Some merge DA directly into their L1 design. Others separate it completely. A third group provides DA as an external service. These distinctions matter more than people think.
In traditional monolithic blockchains — Bitcoin, pre-4844 Ethereum, Solana — DA is simply a built-in property of the L1. Nodes download the entire block, consensus and execution and DA all live inside one system, and scaling is limited precisely because full replication is required. This model has strong verification guarantees, but it doesn’t scale linearly.
Celestia takes a different approach. It is frequently referenced in discussions about modularity, but strictly speaking Celestia is an L1 that provides only consensus and DA. It does not execute transactions and does not act as a settlement layer. Its DA guarantees are enforced with Namespaced Merkle Trees and probabilistic data availability sampling, backed by fraud proofs. This was the first L1 specifically designed as a standalone DA layer.
EigenDA represents a third category. It is not a blockchain, not an L1, and it does not have its own consensus. Instead, it is implemented as an Actively Validated Service (AVS) on top of Ethereum’s restaking framework. Operators validate and serve DA chunks, and the security of the system ultimately depends on staked ETH. Rollups can use EigenDA without migrating to a different L1, because it delivers DA as a network-level service rather than as a base chain.
Even though these systems look completely different, they all follow the same operational logic. First, all raw input data required for block validation must be published — transaction lists, calldata, blob payloads, rollup batches, or chunked data segments. After publication, each system has its own distribution mechanism: full block propagation in Bitcoin and early Ethereum, blob propagation and attestations in modern Ethereum, sampling in Celestia, AVS-based replication in EigenDA. And finally, each system must prove availability: monolithic chains rely on full downloads, Celestia relies on sampling, Ethereum relies on validator attestations, and EigenDA relies on AVS-level validation.
One common misconception is that DA layers store state or execution logic. They don’t. DA layers and DA services store only the inputs required to verify a block. Bitcoin stores the full block bytes. Ethereum’s DA mechanism (post-4844) stores blobs and calldata, which the EVM does not execute. Celestia stores namespaced block data. EigenDA stores L2 batch data. None of these systems store actual state transitions or contract execution results — those belong to execution layers.
Since every primary source agrees on the same failure mode, it’s worth stating plainly:
if DA fails, the blockchain’s trust model breaks.
Nodes can’t re-execute blocks, fraud proofs cannot be verified, ZK proofs lose meaning, and rollups can’t reconstruct state. Invalid states can be finalized without anyone noticing. This is described directly in the Bitcoin whitepaper, the Ethereum Yellow Paper, the Celestia DAS spec, and EigenLayer's security documentation.
So the real picture is simple: DA is not a buzzword and definitely not synonymous with “modular blockchain.” It is a fundamental requirement that determines whether independent validation is even possible. Today we have three families of DA solutions:
Integrated DA: embedded directly into an L1; strong but limited by full replication.
Standalone DA layers (Celestia): an L1 whose entire purpose is consensus + DA, scaling through sampling.
DA-as-a-Service (EigenDA): validated by restaked ETH, independent of L1 consensus, consumed by rollups as a service.
Different architectures, but the same objective:
preventing anyone from hiding data and compromising the system’s integrity.
Without DA, decentralization is an illusion.