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.

Monolithic blockchains implement all four core functions (execution, consensus, settlement, data availability) inside a single L1 protocol and a single validator set.

Modular blockchains separate these functions into layers: one layer specializes in consensus + DA, another in execution (rollups / app-chains), and optionally a third in settlement.

Both architectures rely on the same foundational components:

1. Execution — transaction processing and state transitions

2. Consensus — agreement on block ordering

3. Data Availability (DA) — guarantee that block data is accessible to the network

4. Settlement — proofs, dispute resolution, and finality across layers

The difference is how these functions are distributed.

Concept: a single L1 handles everything.

• One unified base layer:

  • all nodes execute all transactions,

  • participate in consensus,

  • store and serve all block data.

• Tightly coupled stack:

  • execution, consensus, and DA are embedded into one protocol,

  • upgrading one component typically requires a hard fork.

Examples of this architecture class (not marketing, only classification): early Ethereum, Bitcoin-like L1s, Solana — all execute and verify everything at the base layer.

Concept: each layer specializes in a specific function.

This category includes designs like Celestia-style modular stacks.

• Consensus + DA layer

  • orders data and ensures its availability;

  • does not run a global VM.

• Execution layers (rollups / app-chains / sovereign chains)

  • run their own VM and maintain their own state;

  • publish data or proofs to the DA layer.

• Settlement layer (optional)

  • verifies proofs, manages finality, handles inter-rollup disputes.

Layers can be combined (e.g., consensus + DA on one chain, execution on others).

1. Execution environment

   • one VM for all applications,

   • shared global state.

2. Consensus engine

   • PoW/PoS embedded in L1,

   • all nodes validate all blocks.

3. Data availability

   • DA is inherent to L1 full nodes.

4. P2P layer

   • one network for all blocks and mempool traffic.

5. RPC / indexing

   • single RPC interface over one global state.

6. Security model

   • security of all apps = security of L1.

1. Consensus + DA layer

   • ensures ordering and data availability (often with sampling).

2. Execution layers

   • rollups or app-specific chains with their own state machines.

3. Settlement layer

   • stores state roots, verifies proofs, finalizes execution layers.

4. Bridging architecture

   • message-passing and asset transfer between layers.

5. P2P networks

   • separate networks for DA and for execution layers.

6. Tooling

   • shared SDKs or layer-specific toolchains.

1. User sends a transaction to an L1 node.

2. The transaction propagates across one P2P network.

3. A validator/miner:

   • forms a block,

   • executes all transactions,

   • updates global state.

4. All full nodes:

   • download the block,

   • re-execute every transaction to verify it,

   • agree on finality via consensus.

5. Data is stored on the same chain (DA is internal).

Property: full validation requires full execution of all transactions.

1. User sends a transaction to the rollup/execution node.

2. Execution layer:

   • orders transactions,

   • executes them locally,

   • produces a batch.

3. Execution layer publishes:

   • raw transaction data, state diffs, and/or proofs
     to the DA + consensus layer.

4. DA layer includes the data in its blocks and ensures availability.

5. Settlement layer (if separate):

   • verifies proofs and finalizes the rollup state.

Property: validation relies on DA guarantees + cryptographic proofs, not full execution by all nodes.

• Single L1 network

• One unified protocol and VM

• One security domain

• Scaling mostly via:

  • protocol optimizations,

  • sharding within a single L1 (if implemented)

• DA layers for ordering + availability

• Execution chains (rollups, app-chains, sovereign chains)

• Settlement hubs for proof verification and finality

• Standards for messaging, bridging, and DA APIs

• Ability to mix VM types and execution models

1. Simple trust model — one validator set secures everything

2. Strong atomic composability — all apps share one state

3. Simpler architecture — fewer moving parts

4. Straightforward developer experience — uniform VM and L1 rules

1. Scalability via specialization

   • DA is optimized for data throughput

   • Execution layers scale independently

2. High architectural flexibility

   • different VM types

   • different security and execution models

   • pluggable DA layers

3. Low-cost chain deployment

   • new execution chains can “rent” security/DA

4. Lower node requirements (execution layers)

   • heavy work shifts to DA and proof layers

1. Scalability limits — every node must do everything

2. Protocol ossification — difficult to integrate new VMs, DA schemes

3. Resource competition — all applications share blockspace

1. Higher system complexity

   • multiple protocols and interlayer interfaces

2. Expanded security assumptions

   • DA layer security

   • rollup correctness

   • bridge integrity

3. Liquidity and UX fragmentation

   • state and assets distributed across many execution chains

4. Higher developer complexity

   • understanding DA, settlement, proofs, and bridging

• From 2023–2025, blockchain R&D increasingly favors modular stacks:

  • independent DA layers,

  • rollup-driven scaling,

  • separation of execution from L1 consensus.

• Monolithic L1s continue evolving primarily through protocol optimization, not architectural decomposition.