Skip to main content
โšก Calmops

Modular Blockchains Complete Guide 2026: Celestia, Modular Architecture

Introduction

The blockchain industry has reached a critical inflection point. As demand for decentralized applications grows, traditional monolithic blockchains struggle to scale while maintaining security and decentralization. Enter modular blockchainsโ€”a paradigm shift that separates blockchain functions into specialized layers, enabling unprecedented scalability without compromising on security.

This comprehensive guide explores modular blockchain architecture, the leading projects like Celestia, and how this approach is reshaping the blockchain landscape in 2026.

Understanding Blockchain Functions

Before diving into modular blockchains, it’s essential to understand the four core functions that any blockchain must perform:

1. Execution

Execution refers to processing transactions and updating state. When a user sends a transaction, the execution layer processes it and modifies the blockchain state accordingly.

Examples: EVM execution, WASM runtime, transaction validation

2. Settlement

Settlement is the process of verifying proof of execution and resolving disputes. It provides finality and ensures that invalid state transitions can be challenged and reversed.

Examples: Fraud proofs, validity proofs, dispute resolution mechanisms

3. Consensus

Consensus ensures that all nodes agree on the order of transactions and the current state of the blockchain. It provides security by making it economically prohibitive to attack the network.

Examples: Proof of Work, Proof of Stake, PBFT

4. Data Availability

Data Availability (DA) ensures that transaction data is published and available for anyone to verify. This is crucial for light nodes and enables fraud proof generation.

Examples: Data availability sampling, erasure coding

Monolithic vs Modular Blockchains

Monolithic Blockchain Architecture

Traditional blockchains like Ethereum (pre-L2), Solana, and Avalanche are monolithicโ€”they handle all four functions on a single layer.

Monolithic Blockchain:
โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚         Execution Layer             โ”‚
โ”‚    (Smart Contract Processing)      โ”‚
โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค
โ”‚         Settlement Layer            โ”‚
โ”‚      (Fraud/Validity Proofs)       โ”‚
โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค
โ”‚          Consensus Layer            โ”‚
โ”‚    (Transaction Ordering)           โ”‚
โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค
โ”‚     Data Availability Layer         โ”‚
โ”‚       (Data Storage)                โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

Advantages:

  • Simpler architecture
  • Strong security guarantees from integrated design
  • Easier to reason about

Disadvantages:

  • Scalability trilemma: Must compromise on decentralization, security, or scalability
  • All nodes must process all transactions
  • Resource intensive

Modular Blockchain Architecture

Modular blockchains specialize in one or more functions while delegating others to separate layers.

Modular Blockchain:
โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚    Execution Layer (Rollups)        โ”‚
โ”‚  (Arbitrum, Optimism, zkSync)       โ”‚
โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค
โ”‚     Settlement Layer (L1)            โ”‚
โ”‚    (Ethereum, Celestia)            โ”‚
โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค
โ”‚      Consensus Layer (L1)           โ”‚
โ”‚    (Ethereum, Celestia)             โ”‚
โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค
โ”‚  Data Availability Layer (DA)      โ”‚
โ”‚    (Celestia, EigenLayer)           โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

Advantages:

  • Horizontal scalability through specialization
  • Each layer can optimize for its specific function
  • Lower hardware requirements for nodes
  • Greater flexibility in architecture choices

Disadvantages:

  • More complex architecture
  • Cross-layer communication overhead
  • Security assumptions must be carefully analyzed

The Rise of Celestia

What is Celestia?

Celestia is the first modular blockchain network specifically designed as a data availability and consensus layer. Launched in 2024, it provides the foundational infrastructure for scaling blockchain applications through data availability sampling (DAS).

Key Features

Data Availability Sampling (DAS):

Celestia enables light nodes to verify data availability without downloading the entire block. This is achieved through erasure coding and random sampling.

# Simplified data availability sampling
import random
import hashlib

class LightNode:
    def __init__(self, sampling_count=100):
        self.sampling_count = sampling_count
        self.connected_full_nodes = []
    
    def verify_data_availability(self, block_header):
        """
        Light nodes randomly sample shares to verify data availability
        """
        samples = []
        for _ in range(self.sampling_count):
            # Randomly select a share to query
            share_index = random.randint(0, block_header.num_shares - 1)
            share = self.query_share(block_header.block_hash, share_index)
            samples.append(share)
        
        # If all samples are received, with high probability, data is available
        if len(samples) == self.sampling_count:
            return True
        return False
    
    def query_share(self, block_hash, share_index):
        """Query a random full node for a specific share"""
        node = random.choice(self.connected_full_nodes)
        return node.get_share(block_hash, share_index)

Namespaced Merkle Trees (NMTs):

Celestia uses namespaced Merkle trees to organize data, allowing rollups to only download data relevant to them.

// Simplified NMT structure
type NamespaceMerkleTree struct {
    namespaceID []byte
    leaves     [][]byte
    tree       *MerkleTree
}

func (nmt *NamespaceMerkleTree) Insert(data []byte) {
    // Only insert data matching this namespace
    if bytes.HasPrefix(data, nmt.namespaceID) {
        nmt.leaves = append(nmt.leaves, data)
        nmt.tree.Insert(hash(data))
    }
}

func (nmt *NamespaceMerkleTree) GetProof(leafIndex int) *MerkleProof {
    // Generate proof for specific leaf
    return nmt.tree.GenerateProof(leafIndex)
}

Optimistic and ZK Rollups:

Celestia supports both optimistic and zero-knowledge rollups, providing flexibility for developers.

Celestia Ecosystem Projects

Project Type Description
Optimism L2 Rollup Ethereum Layer 2 using Celestia DA
Arbitrum L2 Rollup Ethereum Layer 2 with fraud proofs
zkSync Era L2 Rollup ZK rollup for Ethereum
Mantle L2 Rollup Modular L2 with Celestia DA
Dymension AppChain Rollup-as-a-Service platform
Caldera Rollup-in-a-Box One-click rollup deployment

Execution Layers: Rollups

Rollups are execution layers that process transactions off-chain while publishing data to a settlement layer.

Optimistic Rollups

Optimistic rollups assume transactions are valid by default and allow anyone to submit fraud proofs to challenge invalid transactions.

// Simplified optimistic rollup contract
contract OptimisticRollup {
    struct StateBatch {
        uint256 batchIndex;
        bytes32 stateRoot;
        bytes32 previousStateRoot;
        uint256 timestamp;
        address challenger;
    }
    
    mapping(uint256 => StateBatch) public stateBatches;
    uint256 public currentBatchIndex;
    uint256 public CHALLENGE_PERIOD = 7 days;
    
    event StateBatchAppended(uint256 indexed batchIndex, bytes32 stateRoot);
    
    function appendStateBatch(bytes32 _stateRoot, bytes32[] memory _batchInfo) external onlySequencer {
        require(_stateRoot != bytes32(0), "Invalid state root");
        
        stateBatches[currentBatchIndex] = StateBatch({
            batchIndex: currentBatchIndex,
            stateRoot: _stateRoot,
            previousStateRoot: currentBatchIndex == 0 ? bytes32(0) : stateBatches[currentBatchIndex - 1].stateRoot,
            timestamp: block.timestamp,
            challenger: address(0)
        });
        
        emit StateBatchAppended(currentBatchIndex, _stateRoot);
        currentBatchIndex++;
    }
    
    function challengeStateBatch(uint256 _batchIndex, bytes32 _preStateRoot, bytes32 _postStateRoot, bytes calldata _proof) external {
        StateBatch storage batch = stateBatches[_batchIndex];
        
        require(block.timestamp > batch.timestamp + CHALLENGE_PERIOD, "Challenge period not over");
        require(batch.challenger == address(0), "Already challenged");
        
        // Verify the fraud proof
        require(verifyFraudProof(_preStateRoot, _postStateRoot, _proof), "Invalid fraud proof");
        
        // Slash the sequencer
        sequencerBond -= SLASH_AMOUNT;
        payable(msg.sender).transfer(SLASH_AMOUNT);
        
        batch.challenger = msg.sender;
    }
}

Key Characteristics:

  • 7-day challenge period for withdrawals
  • Fraud proof economics
  • Lower compute costs than ZK rollups

Zero-Knowledge (ZK) Rollups

ZK rollups use cryptographic validity proofs to prove the correctness of state transitions without re-executing transactions.

// Simplified ZK rollup contract
contract ZKRollup {
    Verifier public verifier;
    mapping(bytes32 => bool) public verifiedProofs;
    
    struct ZKBatch {
        uint256 batchIndex;
        bytes32 batchHash;
        bytes32 previousBatchHash;
        bytes32 snarkProof;
        uint256 timestamp;
    }
    
    mapping(uint256 => ZKBatch) public batches;
    uint256 public currentBatchIndex;
    
    function submitBatch(bytes32 _batchHash, bytes32 _previousBatchHash, bytes calldata _proof) external onlySequencer {
        // Verify the ZK proof
        require(verifier.verifyProof(_proof, _batchHash), "Invalid proof");
        
        verifiedProofs[_batchHash] = true;
        
        batches[currentBatchIndex] = ZKBatch({
            batchIndex: currentBatchIndex,
            batchHash: _batchHash,
            previousBatchHash: _previousBatchHash,
            snarkProof: bytes32(_proof[:32]),
            timestamp: block.timestamp
        });
        
        emit BatchSubmitted(currentBatchIndex, _batchHash);
        currentBatchIndex++;
    }
}

Key Characteristics:

  • Immediate finality (no challenge period)
  • More computationally expensive to generate proofs
  • Higher data efficiency

Data Availability Solutions

Ethereum dancun/Danksharding

Ethereum’s approach to data availability through danc sharding provides blobs instead of calldata for L2 data.

// EIP-4844 Blob transaction
struct BlobTx {
    address from;
    address to;
    uint256 value;
    uint256 nonce;
    uint256 gas;
    uint256 maxFeePerBlobGas;
    uint256 maxFeePerGas;
    uint256 maxPriorityFeePerGas;
    bytes calldata;
    uint64 blobVersionedHashesCount;
    uint256[4] blobVersionedHashes; // Up to 4 blob hashes
    bytes signature;
    uint64 chainId;
    uint64 reserved;
    bytes32 blobHash;
    uint64 blobKzgCommitment;
}

function processBlobTransaction(BlobTx calldata tx) internal {
    // Verify blob versioned hash
    require(tx.blobVersionedHashesCount > 0, "No blobs");
    
    // Verify KZG proof
    require(
        verifyKZGProof(tx.blobHash, tx.blobKzgCommitment, tx.blobVersionedHashes),
        "Invalid KZG proof"
    );
    
    // Process transaction
    _processTransaction(tx);
}

EigenDA

EigenDA is a data availability service built on EigenLayer, providing high-throughput DA for rollups.

Features:

  • 10MB+ per block
  • Decentralized operator network
  • Restaking security model

Comparison

DA Solution Throughput Decentralization Security Model
Celestia 1-10 MB/s High Native stake
Ethereum Danksharding ~1 MB/s Very High ETH stake
EigenDA 10+ MB/s Medium Restaked ETH
Avail ~1 MB/s High Native stake

Modular Architecture Patterns

Sovereign Rollups

Sovereign rollups have their own consensus and can fork independently from the settlement layer.

Sovereign Rollup Architecture:
โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚        Sovereign Rollup              โ”‚
โ”‚   (Own Consensus + Execution)        โ”‚
โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค
โ”‚     Data Availability (Celestia)    โ”‚
โ”‚      (Data Publishing + DAS)        โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

Advantages:

  • Independent governance
  • No dependency on L1 for upgrades
  • Complete sovereignty over chain history

Settlement Rollups

Settlement rollups use Ethereum or other L1s for settlement while maintaining execution independence.

Settlement Rollup Architecture:
โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚          Rollup (Execution)          โ”‚
โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค
โ”‚     Settlement (Ethereum L1)         โ”‚
โ”‚       (Fraud/Validity Proofs)        โ”‚
โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค
โ”‚   Data Availability (Celestia/Eth)   โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

Modular Appchains

Appchains are application-specific blockchains that leverage modular infrastructure.

// Setting up a modular appchain with Cosmos SDK
package main

import (
    "github.com/cosmos/cosmos-sdk/server"
    "github.com/tendermint/tendermint/abci/example/counter"
    "github.com/tendermint/tendermint/libs/log"
)

func main() {
    // Create app chain
    app := counter.NewCounterApplication()
    
    // Connect to Celestia for DA
    celestiaClient := celestia.NewClient(
        celestia.RPCEndpoint("https://rpc.celestia.tools"),
        celestia.BridgeEndpoint("https://bridge.celestia.tools"),
    )
    
    // Start the application
    logger := log.NewNopLogger()
    _, _, err := server.NewServer(
        "tcp://0.0.0.0:26658",
        "socket",
        app,
        logger,
    )
    if err != nil {
        panic(err)
    }
}

Building on Modular Blockchains

Deploying a Rollup to Celestia

Step 1: Install Rollkit

# Install Rollkit
git clone https://github.com/rollkit/rollkit.git
cd rollkit
make install

# Verify installation
rollkit version

Step 2: Initialize Your Rollup

# Initialize rollup configuration
rollkit init <chain-id> --consensus.version 0.3.0.0

# Configure Celestia as DA
rollkit config set da.celestia http://localhost:26658
rollkit config set da.namespace 00000000000000000000000000000000000000000000deadbeef

Step 3: Configure Settlement

# config.yaml
settlement:
  type: "ethereum"
  config:
    rpc_url: "https://eth.llamarpc.com"
    chain_id: 1
    contract_address: "0x123..."

execution:
  engine: "evm"
  config:
    jwt_secret: "path/to/jwt.secret"
    execution_rpc: "http://localhost:8545"

Step 4: Start the Rollup

# Start the rollup node
rollkit start --rollkit.aggregator --rollkit.da_layer celestia

Using OP Stack with Celestia DA

# Install OP Stack
git clone https://github.com/ethereum-optimism/optimism.git
cd optimism

# Configure for Celestia DA
export CELESTIA_RPC=http://localhost:26658
export CELESTIA_KEY="your-celestia-key"

# Build and run
make op-node
./bin/op-node --rollup.sequencerhttp=https://mainnet-sequencer.optimism.io \
    --rollup.dac=http://localhost:9090 \
    --l2.jwt-secret=/path/to/jwt.secret

The Future of Modular Blockchains in 2026

1. Interoperability Protocols

Cross-chain communication becomes seamless as modular chains develop standard interfaces.

2. Shared Security Models

Restaking and shared security reduce the capital requirements for launching new chains.

3. ZK Proof Advancements

Improved ZK proving systems make ZK rollups more efficient and accessible.

4. Rollup-as-a-Service

Platforms like Caldera, Dymension, and Conduit make deploying rollups as easy as deploying smart contracts.

5. Data Availability Competition

Multiple DA layers compete, driving innovation in throughput, cost, and decentralization.

Emerging Projects

Project Category Status
EigenLayer Restaking/DA Mainnet
Avail DA Layer Mainnet
Eclipse SVM Rollup Testnet
Fuel Modular Execution Testnet
zkSync ZK Rollup Mainnet
Starknet ZK Rollup Mainnet

Conclusion

Modular blockchains represent a fundamental shift in how we build and scale decentralized systems. By separating concernsโ€”execution, settlement, consensus, and data availabilityโ€”each layer can optimize for its specific function while maintaining security through cryptographic proofs and economic guarantees.

In 2026, the modular ecosystem has matured significantly. Celestia leads the DA layer, ZK rollups have achieved mainnet production, and rollup deployment has become accessible to developers across the spectrum. The future belongs to specialized, interoperable chains that can scale horizontally while maintaining the security properties that make blockchain technology valuable.

Whether you’re a developer building dApps or an investor evaluating protocols, understanding modular architecture is essential for navigating the blockchain landscape of 2026 and beyond.

Resources

Comments