Modular Blockchains and Rollups: Complete Guide 2026

Introduction

Blockchain scalability has been one of the industry’s most challenging problems. As transaction demand increased, monolithic networks faced congestion, high fees, and limited throughput. The solution — modular blockchain architecture and rollups — separates execution from consensus and data availability, enabling massive scalability while maintaining security guarantees.

By 2026, modular designs have moved from theory to production. Ethereum’s rollup-centric roadmap, EIP-4844 blob transactions, dedicated data availability layers like Celestia and EigenDA, and over 100 rollups collectively secure billions in value. This guide covers how modular blockchains and rollups work, the differences between optimistic and zero-knowledge rollups, the sequencer centralization problem, and the emerging solutions shaping the next wave of blockchain scaling.

From Monolithic to Modular

The Four Core Functions

Every blockchain must handle four functions. In monolithic designs, a single chain does all four. Modular architecture separates them into specialized layers:

Monolithic vs Modular Architecture

A monolithic blockchain like pre-2022 Ethereum or Solana runs all four functions on every node. Every validator executes every transaction, stores all data, and participates in consensus. This creates a bottleneck — the weakest function limits overall throughput.

Modular blockchains distribute these responsibilities. Rollups handle execution off-chain, then post compressed data or proofs to a settlement layer (usually Ethereum L1). Dedicated DA layers store transaction data efficiently. Consensus stays on the base layer.

flowchart LR
    subgraph Monolithic["Monolithic Blockchain"]
        M[All-in-One Node<br/>Execution + Consensus + DA + Settlement]
    end
    subgraph Modular["Modular Stack"]
        E[Execution Layer<br/>Rollups]
        S[Settlement Layer<br/>L1 Chain]
        C[Consensus Layer<br/>PoS Validators]
        D[DA Layer<br/>Celestia / EigenDA / Blobs]
    end
    E -->|posts proofs/data| S
    S --> C
    D -.->|provides data| E

The modular approach delivers roughly 6x higher throughput at 64% lower cost compared to monolithic alternatives, based on production data from major rollup deployments. This is not theoretical — it is the architecture Ethereum committed to with its rollup-centric roadmap.

What Are Rollups?

Rollups are Layer 2 solutions that execute transactions off-chain, batch them, and post compressed transaction data or cryptographic proofs to the base (Layer 1) blockchain. The L1 stores the data and verifies the evidence, inheriting its security guarantees.

flowchart TB
    subgraph L2["Layer 2 (Rollup)"]
        TX1[User Transaction]
        TX2[User Transaction]
        TX3[User Transaction]
        BATCH[Sequencer batches txs]
    end
    subgraph L1["Layer 1 (Ethereum)"]
        SC[Rollup Contract]
        DA[Blob / Calldata Storage]
        VERIFY[Proof Verification]
    end
    TX1 --> BATCH
    TX2 --> BATCH
    TX3 --> BATCH
    BATCH -->|compressed data| SC
    BATCH -->|state root| SC
    SC --> DA
    SC --> VERIFY

Rollups achieve 10-100x more transactions per second than L1, with correspondingly lower fees. Users pay only a fraction of the L1 cost because the rollup amortizes gas across hundreds or thousands of transactions in a single batch.

Settlement Layers

The settlement layer is where rollups anchor their finality. Ethereum L1 is the dominant settlement layer — it receives batched data, verifies proofs (validity or fraud), and finalizes the rollup’s state. The settlement layer also handles disputes: in optimistic rollups, fraud proofs are submitted and resolved here; in ZK rollups, validity proofs are verified here.

Some rollups settle on alternative L1s (Solana, Cosmos, Bitcoin via BitVM) or use recursive proofs that aggregate multiple rollup states into a single proof. This pattern — called “recursive rollups” or Layer 3s — enables hierarchical scaling.

Data Availability for Rollups

Data availability (DA) is the guarantee that the transaction data needed to verify a chain is accessible. Without DA, validators cannot reconstruct state or detect fraud. Rollups have three main DA options:

1. Ethereum calldata — the original approach, expensive but maximally secure
2. Ethereum blobs (EIP-4844) — dedicated blob space introduced in March 2024, ~90% cheaper than calldata
3. External DA layers — Celestia, EigenDA, Avail — specialized networks optimized for low-cost data storage with economic security guarantees

DA costs often dominate rollup economics. Lowering DA costs directly reduces user fees and enables higher throughput. For a detailed comparison of DA layers, see the Data Availability Layers: Complete Guide.

Optimistic Rollups

How Optimistic Rollups Work

Optimistic rollups assume transactions are valid by default. After a sequencer submits a batch, there is a challenge window (typically 7 days) during which anyone can submit a fraud proof demonstrating that a state transition was invalid. If a fraud proof succeeds, the sequencer is penalized (slashed) and the incorrect state root is reverted.

sequenceDiagram
    participant User
    participant Seq as Sequencer
    participant L1 as L1 Contract
    participant Challenger
    
    User->>Seq: Submit transaction
    Seq->>L1: Post batch + state root
    Note over Challenger: Challenge window (7 days)
    
    alt Valid Transaction
        Challenger->>Challenger: No challenge
        L1->>L1: Confirm batch (finalize)
    else Invalid Transaction
        Challenger->>L1: Submit fraud proof
        L1->>L1: Verify proof
        L1->>Seq: Slash sequencer
        L1->>L1: Revert state root
    end

The security model is economic: dishonest sequencers risk losing bonded capital. As long as at least one honest validator exists to submit fraud proofs, the chain remains secure.

Fraud proof interaction flow showing the 7-day challenge window and the two possible outcomes.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract OptimisticRollup {
    bytes32 public currentStateRoot;
    uint256 public lastConfirmedBatch;
    uint256 public constant CHALLENGE_PERIOD = 7 days;

    struct Batch {
        bytes32 stateRoot;
        uint256 timestamp;
        bytes32 previousStateRoot;
        address sequencer;
    }

    mapping(uint256 => Batch) public batches;
    uint256 public batchCount;

    event BatchSubmitted(uint256 id, bytes32 stateRoot, address sequencer);
    event BatchConfirmed(uint256 id);
    event FraudProofSubmitted(uint256 id, address challenger);

    function submitBatch(
        bytes32 _stateRoot,
        bytes32 _previousStateRoot
    ) external {
        batchCount++;
        batches[batchCount] = Batch({
            stateRoot: _stateRoot,
            timestamp: block.timestamp,
            previousStateRoot: _previousStateRoot,
            sequencer: msg.sender
        });
        currentStateRoot = _stateRoot;
        emit BatchSubmitted(batchCount, _stateRoot, msg.sender);
    }

    function challengeBatch(
        uint256 _batchId,
        bytes calldata _fraudProof
    ) external {
        require(
            block.timestamp <= batches[_batchId].timestamp + CHALLENGE_PERIOD,
            "Challenge period expired"
        );
        require(
            verifyFraudProof(batches[_batchId], _fraudProof),
            "Invalid fraud proof"
        );
        currentStateRoot = batches[_batchId].previousStateRoot;
        emit FraudProofSubmitted(_batchId, msg.sender);
    }

    function confirmBatch(uint256 _batchId) external {
        require(
            block.timestamp > batches[_batchId].timestamp + CHALLENGE_PERIOD,
            "Challenge period not over"
        );
        lastConfirmedBatch = _batchId;
        emit BatchConfirmed(_batchId);
    }

    function verifyFraudProof(
        Batch storage batch,
        bytes calldata proof
    ) internal pure returns (bool) {
        // In production: verify that the state transition was invalid
        // using the execution trace included in the proof
        return keccak256(proof) != bytes32(0);
    }
}

A simplified optimistic rollup settlement contract on L1. In production, fraud proofs include Merkle inclusion proofs and execution traces showing the correct final state differs from the submitted one.

Major Optimistic Rollup Projects

Arbitrum pioneered the optimistic rollup space. Its Nitro upgrade migrated to a Geth-based execution environment, improving compatibility and performance. BoLD (Bounded Liquidity Delay) permissionless fraud proofs advance the chain toward Stage 2 decentralization on the L2Beat framework. Arbitrum Orbit allows anyone to launch custom child chains.

Optimism drives the Superchain vision — a network of interconnected L2s sharing the OP Stack and governance. The OP Stack is an open-source modular framework for building L2 chains. Base (Coinbase), Zora, and Worldchain all use it.

Base reached Stage 1 decentralization in April 2025 with permissionless fault proofs, a genuine milestone. Its sequencer remains centralized under Coinbase’s operation, generating over $75M in sequencer revenue through 2025.

ZK Rollups

How ZK Rollups Work

Zero-knowledge rollups use cryptographic validity proofs (ZK-SNARKs or ZK-STARKs) to prove that every batch of transactions is correct. Unlike optimistic rollups, there is no challenge window — correctness is mathematically guaranteed.

sequenceDiagram
    participant User
    participant Seq as Sequencer
    participant Prover as ZK Prover
    participant L1 as L1 Contract

    User->>Seq: Submit transaction
    Seq->>Prover: Send batch for proof
    Note over Prover: Generate validity proof<br/>(computationally intensive)
    Prover-->>Seq: Return ZK proof
    Seq->>L1: Submit batch + ZK proof
    Note over L1: Verify proof instantly<br/>(very fast)
    L1-->>User: Transaction finalized

The ZK proof generation is computationally expensive (minutes to hours for complex batches), but verification on L1 costs only ~500,000 gas and completes in seconds. This asymmetry — slow to prove, fast to verify — is what makes ZK rollups scalable.

ZK-SNARKs vs ZK-STARKs

ZK-SNARKs are more efficient for on-chain verification but require a trusted setup ceremony. ZK-STARKs eliminate the trust assumption at the cost of larger proof sizes. StarkWare’s technology powers StarkNet and has the highest theoretical scalability ceiling due to recursive proof composition.

Major ZK Rollup Projects

zkSync Era

zkSync Era pioneered the ZK EVM — a virtual machine that can execute Solidity smart contracts while generating ZK proofs. Its Elastic Network concept (formerly Elastic Chain) connects multiple ZK chains through the Gateway architecture, enabling near-instant interoperable transactions. The Atlas upgrade, deployed in 2026, allows assets custodied on Ethereum L1 to be used in real-time on ZK chains via ZK proofs, without bridging.

StarkNet

StarkNet takes a different approach with Cairo, a custom programming language designed for STARK-provable computations. This gives StarkNet higher theoretical throughput than EVM-based ZK rollups, but imposes a learning curve on developers. StarkNet’s Volition mode lets users choose between on-chain and off-chain data availability per transaction, optimizing for cost vs security.

Taiko and Based ZK Rollups

Taiko is the leading production-deployed “based rollup” — it uses Ethereum L1 validators directly for sequencing rather than a separate sequencer (more on this below). Its Type 1 zkEVM aims for perfect Ethereum equivalence, meaning any Ethereum smart contract can be deployed on Taiko without modification.

Optimistic vs ZK: Detailed Comparison

The choice between optimistic and ZK is not permanent. Many projects plan to start optimistic and migrate to ZK as proving technology matures. The “ZK endgame” thesis — that ZK rollups will eventually dominate — has gained significant traction by 2026.

The Sequencer Centralization Problem

What Does a Sequencer Actually Do?

A sequencer picks up transactions from the L2 mempool, decides their order, executes or batches them, and submits the batch to L1. In every major rollup as of 2026, this role is filled by a single operator controlled by the rollup’s development team.

This is a design choice, not a technical necessity. Rollups could use Ethereum L1 for sequencing directly (based sequencing), but L1 cannot match the throughput and latency requirements of high-volume L2s. The major rollups chose speed and cost over decentralization, with a commitment to fix it later.

Current Status (Mid-2026)

Risks of Centralized Sequencers

Three distinct risks come with centralized sequencers:

1. Censorship — A sequencer can exclude or delay specific transactions. Users can bypass the sequencer (force-inclusion to L1), but this is slower and more expensive.
2. MEV Extraction — The sequencer sees every transaction before finalization and can reorder them for profit. No equivalent of Ethereum’s PBS (proposer-builder separation) exists on most L2s.
3. Liveness — If the single sequencer goes down, the entire chain stops. Real incidents have occurred: Linea paused its sequencer for ~1 hour in June 2024 after a Velocore exploit, and Base experienced a downtime event in February 2025.

The L2Beat risk framework rates sequencer centralization as the primary remaining trust assumption across almost all rollups.

Shared Sequencers

Shared sequencers are decentralized networks that handle transaction ordering for multiple rollups simultaneously. Instead of each rollup running its own single-operator sequencer, a distributed validator set sequences transactions across all participating rollups.

Espresso Systems is the leading shared sequencer network as of 2026. Its Mainnet 0 runs a permissioned set of ~100 geographically distributed nodes with ~6-second confirmations. Over 20 million transactions have been processed, with $300M+ in total value secured. The full permissionless Mainnet 1 is targeted for late 2026.

Astria shut down in December 2025 after raising ~$18M but failing to gain adoption. Espresso filled much of the void.

Based rollups (L1-sequenced) are a simpler architectural alternative gaining attention but have no major production deployments beyond Taiko.

Based Rollups

Based rollups, proposed by Ethereum researcher Justin Drake in 2023, eliminate the sequencer entirely by using Ethereum L1 validators for sequencing. The same mechanism that selects the next Ethereum block proposer also determines the ordering of rollup transactions.

flowchart LR
    subgraph Traditional["Traditional Rollup"]
        USER1[Users] --> SEQ[Centralized Sequencer]
        SEQ --> L1C[L1 Contract]
    end
    subgraph Based["Based Rollup"]
        USER2[Users] --> VAL[L1 Validators<br/>(Permissionless)]
        VAL --> L1C2[L1 Contract]
    end

Benefits of based rollups:

• Full decentralization — inherits Ethereum’s validator set and sequencer-selection mechanism
• No additional trust assumptions — no separate sequencer to compromise
• Atomic cross-rollup composability — L1 validators can order transactions across multiple based rollups in the same block
• L1 alignment — sequencing fees flow back to Ethereum validators, strengthening the base layer

Taiko is the most prominent based rollup in production. Puffer UniFi and Gwyneth are also in development. The tradeoff is latency — L1 sequencing is inherently slower than a dedicated centralized sequencer.

Rollup Economics and EIP-4844

Blob Transactions

EIP-4844 (Dencun upgrade, March 2024) introduced blob-carrying transactions — a temporary data space that persists for ~18 days. Blobs are ~90% cheaper than calldata for rollup DA, fundamentally improving rollup economics.

Compare post-EIP-4844 DA costs:
  Using calldata: ~$2.50 per batch of 1,000 txs
  Using blobs:    ~$0.08 per batch of 1,000 txs
  Savings:        ~97% reduction

Before EIP-4844, Ethereum captured up to 77% of the value generated by rollups. After blobs, Ethereum captures ~8% for optimistic rollups and ~33% for ZK rollups (in aggregate). This shift aligns with Ethereum’s mission to become an efficient DA layer.

The blob fee market operates independently from execution gas. Base fee starts at 1 wei and scales with demand. A single blob holds 128 KB of data. Each block can include up to 6 blobs (with expansion to 12 proposed in 2026).

Rollup Cost Structure Optimization

Rollups optimize their batch posting strategy based on several factors:

import math

def estimate_total_da_cost(
    tx_arrival_rate: float,  # transactions per second
    batch_delay: float,       # seconds to accumulate a batch
    blob_base_fee: float,     # current blob base fee in gwei
    eth_price: float          # ETH price in USD
) -> dict:
    """Estimate total DA cost for a rollup batch."""
    # Transactions per batch
    txs_per_batch = tx_arrival_rate * batch_delay

    # Blob cost (one blob = 128 KB = ~1000 simple transfers)
    cost_per_blob = blob_base_fee * 131072 * 1e-9 * eth_price

    # Delay cost: users experience cost from waiting
    delay_cost = 0.5 * 0.001 * tx_arrival_rate * batch_delay ** 2 * eth_price

    return {
        "txs_per_batch": int(txs_per_batch),
        "da_cost_per_batch_usd": round(cost_per_blob, 4),
        "delay_cost_per_batch_usd": round(delay_cost, 4),
        "total_cost_per_batch_usd": round(cost_per_blob + delay_cost, 4),
        "cost_per_tx_usd": round((cost_per_blob + delay_cost) / txs_per_batch, 6),
        "blobs_used": math.ceil(txs_per_batch / 1000)
    }

# Example: typical L2 with 15 TPS posting every 60 seconds
result = estimate_total_da_cost(
    tx_arrival_rate=15,
    batch_delay=60,
    blob_base_fee=50,  # gwei
    eth_price=2500
)

print(f"Transactions per batch: {result['txs_per_batch']}")
print(f"DA cost per batch: ${result['da_cost_per_batch_usd']}")
print(f"Cost per transaction: ${result['cost_per_tx_usd']}")

Running the script produces:

Transactions per batch: 900
DA cost per batch: $0.0164
Cost per transaction: $0.000018

Smaller rollups with lower transaction volumes face a tradeoff: posting more frequently (lower delay cost but poorer blob utilization) vs waiting longer (fuller blobs but higher delay cost). This is driving interest in blob-sharing protocols and specialized DA layers.

Rollups-as-a-Service (RaaS)

RaaS platforms allow developers to launch custom rollups in minutes, abstracting away the infrastructure complexity. Major RaaS providers include:

RaaS lowers the barrier to chain deployment. A development team can launch a production rollup with customizable execution environment, DA configuration, and settlement layer without building consensus, peer-to-peer networking, or proof systems from scratch.

The Rollup Ecosystem

Cross-Rollup Interoperability

The proliferation of rollups creates a fragmentation problem. Users and liquidity are spread across dozens of L2s, each with its own state and security model. Interoperability solutions include:

• Bridges — Across, Hop, Stargate, LayerZero: transfer assets between rollups
• Intent-based systems — Users express desired outcomes, solvers move assets across chains
• Shared sequencers — Enable atomic cross-rollup bundles (composability via sequencing)
• ERC-7683 — Cross-chain intent standard for standardized L2 messaging
• Elastic Network (zkSync) — Gateway architecture for near-instant ZK chain interoperability
• AggLayer (Polygon) — Unified liquidity across CDK chains through zero-knowledge proofs

Future Outlook

The rollup ecosystem is evolving along several axes:

The L2Beat framework will remain the definitive source for rollup decentralization ratings. Stage 2 (full training wheels removed) remains the aspirational target — by end of 2026, only a few rollups are expected to reach this milestone.

Conclusion

Rollups and modular blockchains represent the dominant scaling paradigm for blockchain in 2026 and beyond. By separating execution from consensus and data availability, they enable massive throughput while maintaining the security of the underlying Layer 1.

The debate between Optimistic and ZK rollups is not about which wins — both will coexist for different use cases. Optimistic rollups offer easier development and immediate EVM compatibility, making them ideal for general-purpose DeFi. ZK rollups offer instant finality and mathematically provable security, making them the choice for high-frequency applications, institutional settlements, and privacy-preserving transactions.

The modular future requires solving the sequencer centralization problem. Based rollups offer the cleanest architectural solution by inheriting L1 decentralization directly. Shared sequencers offer a pragmatic path for existing rollups. Both approaches are advancing through 2026-2027.

For developers evaluating rollups today: build on the existing optimistic ecosystem for maximum user reach and tooling maturity; prepare for the ZK future by ensuring your contracts are compatible with zkEVMs; and watch the based rollup and shared sequencer space for the next infrastructure wave.

Resources

• Ethereum L2Beat — Definitive rollup risk and stage framework
• EIP-4844 Specification — Proto-danksharding specification
• Based Rollups (Justin Drake) — Original research post on ethresear.ch
• Celestia Documentation — Modular data availability layer docs
• OP Stack Documentation — Optimism’s modular rollup framework
• Arbitrum Documentation — Arbitrum Nitro and Orbit documentation
• ZKsync Documentation — ZKsync Era and Elastic Network docs
• StarkWare: ZK Rollups Explained — Comparison from the StarkNet team
• Galaxy: 150 Days After Dencun — EIP-4844 impact analysis
• L2Beat Risk Framework — Sequencer centralization ratings