Layer 2 Scaling Deep Dive — Rollups, Channels & Sidechains

In this tutorial, you'll learn about Layer 2 Scaling Deep Dive. We cover key concepts, practical examples, and best practices to help you understand and apply this topic effectively.

Layer 2 scaling solutions Process transactions off the main Blockchain (Layer 1) and submit compressed proofs or batched results, dramatically increasing throughput while inheriting L1 security guarantees.

Why Layer 2 Scaling Matters

Ethereum handles ~15 transactions per second. Visa handles ~24,000. Without L2 solutions, Blockchain cannot compete with centralized systems. L2s bring TPS from dozens to thousands while keeping costs cents per Transaction. DodaTech's research team evaluates L2 solutions for optimal dApp deployment across the Web3 ecosystem.

The L2 Landscape

graph TD
    subgraph L2[Layer 2 Solutions]
        Rollups[Rollups]
        Channels[State Channels]
        Sidechains[Sidechains]
        Plasma[Plasma]
        Validium[Validium]
    end

    subgraph Rollups
        OR[Optimistic Rollup
Arbitrum, Optimism]
        ZKR[ZK Rollup
zkSync, StarkNet]
    end

    subgraph Channels
        LN[Lightning Network
Bitcoin]
        SC[State Channels
Ethereum]
    end

    subgraph Sidechains
        Polygon[Polygon PoS]
        Gnosis[Gnosis Chain]
    end

    L2 --> Rollups
    L2 --> Channels
    L2 --> Sidechains
    L2 --> Plasma
    L2 --> Validium

    style L2 fill:#3b82f6,color:#fff

Optimistic Rollups

Optimistic rollups assume all transactions are valid unless someone submits a fraud proof during a challenge period (typically 7 days).

// optimistic_rollup_sim.js
class OptimisticRollup {
    constructor(challengePeriodDays = 7) {
        this.state = { balances: {} };
        this.batches = [];
        this.challengePeriod = challengePeriodDays * 86400;
    }

    submitBatch(transactions, sequencer) {
        const batch = {
            id: this.batches.length + 1,
            transactions,
            sequencer,
            timestamp: Date.now(),
            challenged: false,
            finalized: false
        };
        this.batches.push(batch);
        console.log(`Batch #${batch.id} submitted by ${sequencer}`);
        console.log(`Contains ${transactions.length} transactions`);
        console.log(`Challenge period: ${this.challengePeriod / 86400} days`);
        return batch;
    }

    challengeBatch(batchId, challenger) {
        const batch = this.batches[batchId - 1];
        if (!batch || batch.finalized) return false;

        batch.challenged = true;
        console.log(`Batch #${batchId} challenged by ${challenger}!`);

        // In production, fraud proof verification happens here
        const fraudDetected = Math.random() > 0.9;

        if (fraudDetected) {
            console.log("FRAUD DETECTED! Sequencer penalized.");
            return true;
        }
        console.log("Challenge resolved — batch valid.");
        return false;
    }

    finalize(batchId) {
        const batch = this.batches[batchId - 1];
        if (!batch || batch.challenged) return;
        batch.finalized = true;
        console.log(`Batch #${batchId} finalized. Transactions irreversible.`);
    }
}

const rollup = new OptimisticRollup();
const batch = rollup.submitBatch(
    Array(100).fill({ from: "Alice", to: "Bob", amount: 1 }),
    "SequencerNode1"
);
rollup.challengeBatch(1, "ValidatorNode5");
rollup.finalize(1);

Expected output:

Batch #1 submitted by SequencerNode1
Contains 100 transactions
Challenge period: 7 days
Batch #1 challenged by ValidatorNode5!
Challenge resolved — batch valid.
Batch #1 finalized. Transactions irreversible.

ZK Rollups

Zero-Knowledge rollups generate cryptographic proofs that batch transactions are valid. No challenge period needed.

// Simplified ZK rollup verifier interface
contract ZKVerifier {
    address public verifierContract;

    // Verify a ZK proof that batch is valid
    function verifyBatch(
        bytes calldata proof,
        bytes32 newStateRoot,
        bytes32 oldStateRoot
    ) external returns (bool) {
        // Calls ZK proof verification contract
        (bool success, ) = verifierContract.call(
            abi.encodeWithSignature(
                "verify(bytes,bytes32,bytes32)",
                proof, newStateRoot, oldStateRoot
            )
        );
        require(success, "ZK proof verification failed");
        stateRoot = newStateRoot;
        emit BatchVerified(newStateRoot);
        return true;
    }

    event BatchVerified(bytes32 indexed stateRoot);
}

State Channels — Lightning Network

State channels allow two parties to transact off-chain, only submitting the final state to L1.

Lightning Network Payment Flow:

Alice opens channel    Alice → Bob: 0.01 BTC    Bob → Alice: 0.005 BTC
with 0.1 BTC deposit  (off-chain signed)       (off-chain signed)
       │                      │                       │
       ▼                      ▼                       ▼
┌─────────────┐    ┌──────────────────┐    ┌──────────────────┐
│ On-chain tx │    │ Off-chain update │    │ Off-chain update │
│ Open channel│    │ Balance: A=0.09  │    │ Balance: A=0.085 │
│ TVL: 0.1 BTC│    │         B=0.01   │    │         B=0.015  │
└─────────────┘    └──────────────────┘    └──────────────────┘

After 1000 microtransactions:
Final state submitted on-chain: Alice 0.05, Bob 0.05
Only 2 on-chain transactions for 1000 payments!

Sidechains (Polygon PoS)

Sidechains have independent validator sets and consensus mechanisms. They don't inherit L1 security.

# sidechain_security_analyzer.py
def analyze_sidechain_security(name, validators, consensus, tvl):
    """
    Assess sidechain security compared to rollups.
    """
    eth_validators = 1_000_000  # Ethereum's validator count
    security_ratio = validators / eth_validators

    print(f"=== Sidechain Security: {name} ===")
    print(f"Validators: {validators:,}")
    print(f"Consensus: {consensus}")
    print(f"TVL: ${tvl}B")
    print(f"Validators vs Ethereum: {security_ratio:.4%}")

    if security_ratio < 0.01:
        print("Risk: VERY HIGH — small validator set")
        print("A 51% attack costs much less than on Ethereum")
    elif security_ratio < 0.1:
        print("Risk: MODERATE — larger set but still centralized")
    else:
        print("Risk: LOW — comparable to L1 security")

    print(f"\nIf {validators * 2 // 3:,} validators collude:")
    print("Funds can be stolen from the bridge")
    print("No recourse — sidechain has its own consensus")

analyze_sidechain_security("Polygon PoS", 100, "Proof of Stake", 6.8)

Expected output:

=== Sidechain Security: Polygon PoS ===
Validators: 100
Consensus: Proof of Stake
TVL: $6.8B
Validators vs Ethereum: 0.0100%
Risk: VERY HIGH — small validator set
A 51% attack costs much less than on Ethereum

If 66 validators collude:
Funds can be stolen from the bridge
No recourse — sidechain has its own consensus

Plasma and Validium

Plasma — Child chains that periodically commit Merkle roots to L1. Data is held on-chain, but computation is off-chain. Limited by data availability challenges.

Validium — Like ZK rollups but data is stored off-chain. Higher throughput (100,000+ TPS) but introduces data availability assumptions. If the data availability committee goes offline, funds can be frozen.

Tradeoffs Summary

Common Mistakes

1. Confusing sidechains with rollups: Polygon PoS is NOT a rollup. It has its own validators and doesn't inherit Ethereum's security.
2. Forgetting the 7-day challenge period: Withdrawing from Arbitrum to L1 takes 7 days. Plan ahead or use bridges for faster exits.
3. Sending ETH directly to an L2 address from L1: Use the official bridge. Direct transfers are lost.
4. Overlooking data availability in Validium: If the committee goes offline, no one can prove ownership of funds.
5. Assuming all L2s are equally EVM-compatible: ZK rollups have limited EVM support. Not all Solidity code works without modification.
6. Not accounting for L2-specific gas patterns: On rollups, calldata is expensive. Optimize for data compression.

Practice Questions

1. What is the fundamental difference between Optimistic and ZK rollups?
2. Why is Polygon's security model different from Arbitrum's?
3. How does the Lightning Network achieve unlimited TPS?
4. What is the data availability problem in Validium?
5. What happens during an Optimistic rollup's challenge period?

Answers:

1. Optimistic assumes validity (fraud proofs catch cheaters after 7 days). ZK proves validity mathematically (instant finality).
2. Arbitrum inherits Ethereum's validator set (L1 security). Polygon has 100 validators — 66 colluding can steal funds.
3. Lightning Network opens a channel on-chain, then conducts unlimited off-chain updates. Only the final state hits L1 — 2 on-chain transactions for millions of payments.
4. Data is stored off-chain with a committee. If the committee is unavailable, users can't prove ownership of funds to L1.
5. During 7 days, anyone can submit a fraud proof proving a batch is invalid. If proven, the sequencer is penalized and the batch is reverted.

Challenge: Calculate the cost savings of using an L2 vs L1 for 1000 token transfers. Assume L1 gas = 25 Gwei, L2 gas = 0.1 Gwei, standard transfer = 21000 gas on L1.

FAQ

What's Next

Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro.