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.