Chapter 18: Layer 2 Scaling: Rollups, State Channels, and Sidechains

"The blockchain trilemma is not a law of physics. It is a challenge of engineering." — Vitalik Buterin

In Chapter 11, we explored Ethereum's architecture in detail — the Ethereum Virtual Machine, smart contracts, gas mechanics, and the account-based model that makes it a general-purpose computation platform. We saw a system of extraordinary flexibility and security. But we also saw a system that, by design, asks every full node on the planet to re-execute every transaction that every user submits. That design choice — the source of Ethereum's trustlessness — is also the source of its most pressing limitation.

Ethereum processes roughly 15 transactions per second. Visa's network handles approximately 65,000 transactions per second at peak capacity. Bitcoin manages about 7. These numbers are not bugs. They are direct consequences of how decentralized consensus works: every node validates every transaction, and the network moves at the speed of its slowest honest participant. You cannot simply crank up the throughput of a Layer 1 blockchain without sacrificing something fundamental — decentralization, security, or both.

This chapter is about the engineering solutions that have emerged to break through that bottleneck without breaking the security guarantees that make blockchains valuable in the first place. These solutions — collectively called Layer 2 (L2) scaling — represent one of the most active and consequential areas of blockchain development. They are not theoretical curiosities. As of early 2025, Layer 2 networks on Ethereum collectively hold over $40 billion in Total Value Locked (TVL) and process more transactions per day than Ethereum mainnet itself.

We will examine four major approaches: optimistic rollups, ZK-rollups, state channels, and sidechains. We will compare their security models, latency characteristics, costs, and developer experience. And we will end with the modular blockchain thesis — the increasingly influential idea that the future of blockchain architecture lies not in monolithic chains that do everything, but in specialized layers that each do one thing well.

By the end of this chapter, you will be able to evaluate any Layer 2 solution by asking the right questions: Where does execution happen? Where does data live? What security guarantees does the user actually get? And what are the trust assumptions hiding behind the marketing?

18.1 The Scaling Problem

To understand why Layer 2 solutions exist, you must first understand why Layer 1 scaling is so hard. The difficulty is not a matter of bandwidth or CPU speed. It is a fundamental consequence of how decentralized consensus operates.

The Throughput Bottleneck

A blockchain is, at its core, a replicated state machine. Every full node maintains a complete copy of the current state (all account balances, all smart contract storage) and applies the same sequence of transactions in the same order to arrive at the same result. This is what makes the system trustless: you do not need to trust any particular node, because you can verify everything yourself.

But this architecture means that the throughput of the entire network is bounded by what a single node can process. If Ethereum produces a block every 12 seconds and each block has a gas limit of 30 million gas, then the total computation the network can perform per second is fixed — regardless of how many nodes are running.

Let's put concrete numbers on this:

The gap between Ethereum's 15 TPS and Visa's 65,000 TPS is not a small engineering problem. It is a factor of over 4,000. During periods of high demand — an NFT mint, a DeFi protocol launch, a market crash — Ethereum's limited throughput translates directly into sky-high gas fees. In May 2022, during the Otherside NFT mint by Yuga Labs, some users paid over $14,000 in gas fees for a single transaction. Others paid thousands in gas and still had their transactions fail.

Why Naive Solutions Fail

The obvious solution — just make blocks bigger — is a trap. To understand why, consider what happens when you increase block size or reduce block time:

Bigger blocks mean each node must download, validate, and store more data per unit time. This raises the hardware requirements to run a full node. When hardware requirements rise, fewer people can afford to run nodes. When fewer people run nodes, the network becomes more centralized. And centralization undermines the entire security model.

This is not hypothetical. Bitcoin's block size debate of 2015-2017 was precisely about this tradeoff. The Bitcoin Cash fork chose bigger blocks (8 MB, later 32 MB). The result was a network with far fewer full nodes and a fraction of Bitcoin's security budget.

Faster block times create a different problem. If blocks are produced faster than they can propagate through the network, honest nodes will frequently disagree about which block was first. This increases the rate of orphaned blocks (valid blocks that get discarded because another block at the same height was seen first) and reduces the effective security of the chain. Reducing block time without proportionally increasing bandwidth effectively weakens the consensus mechanism.

Sharding the state — splitting the blockchain into parallel chains that each handle a subset of transactions — is a promising long-term approach, but it introduces enormous complexity. How do you handle transactions that touch state on multiple shards? How do you prevent an attacker from concentrating power on a single shard? Ethereum originally planned to implement execution sharding, but the complexity proved so significant that the roadmap was revised. The current plan (as of 2025) is to shard only data availability, not execution — and to let Layer 2 solutions handle the execution scaling.

The Blockchain Trilemma

Vitalik Buterin formalized this tension as the blockchain trilemma: a blockchain can optimize for at most two of three properties:

1. Decentralization — anyone can run a node and participate in consensus
2. Security — the network can resist attacks from well-funded adversaries
3. Scalability — the network can process a large number of transactions quickly

A centralized database achieves security and scalability but not decentralization. A blockchain with tiny blocks achieves decentralization and security but not scalability. A blockchain with enormous blocks might achieve scalability and security but sacrifices decentralization.

Layer 2 solutions represent an attempt to escape this trilemma — not by breaking it, but by separating concerns. The key insight: you do not need every node to execute every transaction if you can prove that the transactions were executed correctly.

18.2 The Layer 2 Idea

The fundamental principle behind all Layer 2 scaling solutions can be stated in a single sentence: execute transactions off the main chain, but use the main chain as a court of final appeal.

Think of it this way. Imagine a legal system where every contract dispute, no matter how minor, goes to the Supreme Court. The Supreme Court is very secure — its judgments are final and nearly impossible to overturn. But it can only hear 15 cases per day. The backlog grows. Costs skyrocket. People wait months for resolution.

The solution is not to make the Supreme Court hear cases faster (which might compromise the quality of its judgments). The solution is to create lower courts — arbitration panels, mediators, small claims courts — that handle the vast majority of disputes quickly and cheaply, while preserving the right to escalate to the Supreme Court when something goes wrong.

Layer 2 solutions are those lower courts. The Layer 1 blockchain (Ethereum, in most cases) serves as the Supreme Court — the final arbiter of truth that everyone trusts.

How It Works in Practice

Every L2 solution follows a common pattern:

1. Users deposit funds from L1 into a smart contract on the main chain (the "bridge" contract)
2. Transactions are executed off-chain on the L2 system, which maintains its own state
3. Some compact proof or summary is periodically posted back to L1, anchoring the L2 state to the security of the main chain
4. Users can withdraw funds back to L1, subject to some delay or proof requirement

The critical question — the question that separates the different L2 approaches — is: what exactly gets posted back to L1, and how does L1 know that the L2 state is correct?

• Optimistic rollups post the state root and assume it is correct unless someone challenges it
• ZK-rollups post the state root along with a mathematical proof that it is correct
• State channels only touch L1 at channel open and close (and in disputes)
• Sidechains run their own consensus and use bridges to move assets between chains

Each approach makes different tradeoffs between security, latency, cost, and complexity. The rest of this chapter examines each one in detail.

The Data Availability Problem

Before diving into specific solutions, we need to address a subtle but critical issue that affects all L2 designs: data availability.

When an L2 posts a state root to L1, that state root is just a hash — a 32-byte summary of the entire L2 state. If someone wants to verify that the state root is correct, they need access to the underlying transaction data. But where does that data live?

If the transaction data is only available from the L2 operator, users face a problem. A malicious operator could post an invalid state root and then refuse to share the data needed to prove it is invalid. This is called a data withholding attack, and it is one of the most subtle failure modes in L2 design.

The solutions to this problem vary by approach:

• Rollups (both optimistic and ZK) post compressed transaction data to L1 as calldata (or, after EIP-4844, as blobs). This means anyone can reconstruct the L2 state from L1 data alone.
• Validiums post only the proof to L1, keeping data off-chain. This is cheaper but introduces a data availability assumption.
• Sidechains keep data on their own chain. L1 has no access to it.

Data availability is the key differentiator between a rollup (which inherits L1 security) and a validium or sidechain (which does not). We will return to this distinction throughout the chapter.

18.3 Optimistic Rollups

Optimistic rollups are the most widely adopted Layer 2 scaling solution as of 2025, with the two largest — Arbitrum and Optimism — collectively securing over $25 billion in TVL. The name "optimistic" refers to their core assumption: transactions are assumed to be valid unless someone proves otherwise.

How Optimistic Rollups Work

The mechanics of an optimistic rollup proceed in several stages:

Step 1: Transaction Submission. Users submit transactions to the rollup. These transactions look just like Ethereum transactions — they have a sender, a receiver, a value, and calldata. But instead of being sent to Ethereum mainnet, they are sent to the rollup's sequencer.

Step 2: Sequencing. The sequencer is a node (or set of nodes) that orders transactions, executes them against the rollup's state, and produces new state roots. In most current implementations (Arbitrum, Optimism), the sequencer is a single centralized entity operated by the rollup team. This is a temporary expedient — decentralizing the sequencer is an active area of development — but it is important to understand. The sequencer can censor transactions (by refusing to include them) or reorder them (to extract MEV), but it cannot steal funds. If the sequencer goes down, users can always force-include their transactions by submitting them directly to the L1 contract — a process called force inclusion.

Step 3: Batch Submission. The sequencer periodically batches many L2 transactions together and posts the batch to Ethereum as calldata in a single L1 transaction. This is where the cost savings come from. Instead of each transaction paying for its own L1 gas, hundreds or thousands of transactions share the cost of a single L1 transaction.

To understand the compression, consider a simple ETH transfer:

• On Ethereum L1: A transfer costs 21,000 gas (~$2-5 at typical gas prices)
• On an optimistic rollup: The same transfer costs the rollup about 16 bytes of calldata per transaction (compressed). At 16 gas per byte of calldata, that's 256 gas per transaction. If the batch contains 1,000 transactions, each user pays 1/1,000th of the L1 overhead plus the 256 gas for their compressed data. Total cost: $0.01-0.10.

Step 4: State Root Assertion. Along with the batch, the sequencer posts a state root — a cryptographic commitment to the entire L2 state after executing all the transactions in the batch. This state root is like a fingerprint of the L2 state.

Step 5: The Challenge Period. Here is where "optimistic" enters the picture. After the state root is posted, there is a challenge period — typically 7 days — during which anyone can dispute the state root by submitting a fraud proof.

Fraud Proofs: The Security Mechanism

A fraud proof is a demonstration that the posted state root is incorrect — that the sequencer made an error (or cheated) when executing the transactions. The challenge mechanism works differently depending on the rollup:

Arbitrum uses interactive fraud proofs. When a challenger disputes a state root, the challenger and the asserter engage in a back-and-forth bisection protocol on L1. They repeatedly narrow down the disagreement until they isolate a single instruction — a single step of the EVM — where they disagree about the output. That single instruction is then executed on L1, and the chain determines who is correct. The loser forfeits their bond (typically substantial — tens of thousands of dollars in ETH).

The beauty of this approach is efficiency: no matter how many transactions are in the batch, the on-chain cost of resolving a dispute is proportional to log(n) (where n is the number of computational steps), because the bisection protocol halves the search space at each round.

Optimism originally planned to use non-interactive fraud proofs (also called single-round proofs), where the entire disputed execution is replayed on L1 in one shot. This is simpler but more expensive for large computations. In practice, Optimism launched without a functional fraud proof system and operated with training wheels (a multisig that could override the rollup state) for over two years. The first permissionless fraud proof system — the "Fault Proof VM" — was activated on Optimism mainnet in June 2024, marking a significant milestone.

The Honest Minority Assumption

The security model of an optimistic rollup requires only that at least one honest participant is watching the chain and willing to submit a fraud proof if they detect an invalid state root. This is sometimes called the 1-of-N assumption — out of N watchers, only one needs to be honest.

This is a remarkably weak trust assumption. Compare it to a multisig (which requires M-of-N honest signers) or a sidechain (which requires a majority of validators to be honest). With an optimistic rollup, a single whistleblower can protect the entire system.

However, the assumption is weaker than it appears in two ways:

1. The honest party must actually be running. If nobody is watching, nobody will challenge. Rollup teams typically run their own watchers, and there are incentives for third parties to do so (the challenger wins the asserter's bond), but the system only works if at least one watcher is operational.

2. The honest party must be able to get their fraud proof transaction included on L1. If L1 is congested or if the attacker is censoring fraud proof transactions on L1, the challenge period might expire before the fraud proof lands. This is a subtle but real attack vector.

The 7-Day Withdrawal Delay

The challenge period creates the most user-visible consequence of optimistic rollups: withdrawals from L2 to L1 take approximately 7 days. This is because L1 cannot be sure that the L2 state root is correct until the challenge period expires without a successful fraud proof.

In practice, this delay is mitigated by liquidity providers who offer "fast withdrawals." A user who wants to withdraw immediately can sell their L2 assets to a liquidity provider (at a small fee), and the liquidity provider waits out the 7-day period. Services like Across Protocol, Hop Protocol, and Stargate Finance specialize in this.

Arbitrum and Optimism: The Two Giants

Arbitrum, developed by Offchain Labs, launched its mainnet (Arbitrum One) in August 2021. It uses the Nitro tech stack, which compiles smart contracts to WebAssembly (WASM) for execution, with a WASM-based fraud proof system. Arbitrum pioneered the interactive fraud proof model and has consistently held the largest TVL of any L2.

Optimism, developed by OP Labs, launched its mainnet in January 2022. It uses a modified version of the EVM called the "OP Stack" and has become notable for its governance experiment — the Optimism Collective, which includes both a Token House (governance by OP token holders) and a Citizens' House (governance by reputation). Optimism also introduced the concept of "Superchains" — multiple L2 chains sharing the same tech stack and eventually the same sequencer set.

Both Arbitrum and Optimism offer EVM equivalence, meaning that any smart contract that works on Ethereum will work on the rollup with minimal or no modification. This is a major advantage for developer adoption.

18.4 ZK-Rollups

If optimistic rollups are the "trust but verify" approach, ZK-rollups are the "don't trust, prove" approach. Instead of assuming state transitions are correct and waiting for someone to challenge them, ZK-rollups accompany every state update with a cryptographic validity proof that mathematically guarantees the state transition is correct.

How ZK-Rollups Work

Step 1-3: Same as optimistic rollups. Users submit transactions, a sequencer orders and executes them, and batches are submitted to L1 with compressed transaction data.

Step 4: Proof Generation. Here is where ZK-rollups diverge. After executing the batch, the rollup's prover (a specialized, computationally intensive node) generates a cryptographic proof — specifically, a zero-knowledge proof or more accurately a validity proof — that attests: "The new state root is the correct result of applying these transactions to the previous state root."

The proof is generated off-chain (it would be far too expensive to generate on-chain) but it can be verified on-chain cheaply. This is the magic of zero-knowledge proof systems: generating a proof is computationally expensive, but verifying one is cheap.

Step 5: On-Chain Verification. The proof is submitted to a verifier contract on L1, which checks it in a single transaction. If the proof is valid, the new state root is accepted immediately. There is no challenge period.

The Zero-Knowledge Proof Systems

The term "zero-knowledge" in ZK-rollup is somewhat misleading. In classical cryptography, a zero-knowledge proof is one that reveals nothing beyond the truth of the statement being proved. In the context of rollups, the proofs used are more accurately called validity proofs — they prove that computation was done correctly. Some ZK-rollup proofs do have the zero-knowledge property (they don't reveal the transaction details), but this is not the primary purpose. The primary purpose is validity: proving correctness.

Two major proof systems dominate the ZK-rollup landscape:

SNARKs (Succinct Non-interactive Arguments of Knowledge) produce small, constant-size proofs (~200-300 bytes) that are cheap to verify on-chain. Most SNARK systems require a trusted setup — a one-time ceremony in which cryptographic parameters are generated. If the setup is compromised (if anyone retains the "toxic waste" from the ceremony), they could create false proofs. Modern implementations use multi-party computation ceremonies involving thousands of participants, making compromise extremely unlikely. ZK-rollups using SNARKs include zkSync Era and Scroll.

STARKs (Scalable Transparent Arguments of Knowledge), developed by StarkWare (the company behind StarkNet), have no trusted setup requirement — they are "transparent." They also rely on hash functions rather than elliptic curves, making them potentially resistant to quantum computing attacks. The tradeoff is that STARK proofs are larger (tens to hundreds of kilobytes), making them more expensive to verify on-chain. However, proof generation for STARKs is often faster, and the proofs can be recursively composed to reduce size.

The Computational Overhead of Proof Generation

Generating a validity proof is computationally intensive. A single proof for a batch of transactions might require thousands of CPU-hours. This is not an exaggeration — early ZK-rollup provers required clusters of GPUs running for minutes to generate proofs for even modest batches.

The economics work because the proving cost is amortized across all transactions in the batch. If generating a proof costs $100 in compute and the batch contains 10,000 transactions, the proving cost per transaction is $0.01. As proof generation hardware improves and algorithms get more efficient, these costs continue to decline.

The major ZK-rollup teams have invested heavily in prover optimization:

• StarkNet uses the Cairo programming language, which is specifically designed to produce STARK-friendly execution traces
• zkSync Era compiles Solidity (and other EVM languages) into a custom zero-knowledge circuit using their LLVM-based compiler
• Scroll focuses on byte-level EVM equivalence, aiming to prove every EVM opcode exactly as it executes on Ethereum

The EVM Compatibility Spectrum

One of the biggest challenges for ZK-rollups is achieving compatibility with the Ethereum Virtual Machine. The EVM was not designed with provability in mind. Certain EVM opcodes (like KECCAK256, which is a hash function used ubiquitously in Ethereum) are extremely expensive to prove in a zero-knowledge circuit.

This has led to a spectrum of approaches, articulated by Vitalik Buterin in a 2022 blog post:

StarkNet is outside this classification entirely — it uses its own VM (the Cairo VM) and its own programming language (Cairo), which is not EVM-compatible at all. Developers must rewrite or compile contracts specifically for StarkNet.

Advantages of ZK-Rollups Over Optimistic Rollups

The fundamental advantage is clear: no challenge period. Once a validity proof is verified on L1, the state is final. Withdrawals from a ZK-rollup to L1 can be processed in minutes (the time to generate and verify a proof), not days.

Additional advantages include:

• Stronger security guarantee: The security does not depend on anyone watching the chain. Mathematical proofs are valid regardless of whether anyone checks them.
• Better capital efficiency: Because there is no 7-day delay, capital is not locked up waiting for finality.
• Privacy potential: The zero-knowledge property can be used to hide transaction details while still proving correctness (though most current ZK-rollups do not implement this).

Current Limitations

Despite these advantages, ZK-rollups face significant challenges:

• Prover centralization: Proof generation requires expensive hardware. Currently, all major ZK-rollups run centralized provers. Decentralizing the prover is an open research problem.
• EVM compatibility complexity: Achieving full EVM equivalence in a ZK circuit is extraordinarily difficult. This limits developer adoption compared to optimistic rollups, which offer seamless compatibility.
• Higher L1 gas cost per proof: Verifying a SNARK or STARK on L1 costs ~300,000-500,000 gas. This fixed cost must be amortized over enough transactions to be economical.
• Maturity: ZK-rollups are newer technology. The cryptographic systems are complex, and bugs in the prover or verifier could be catastrophic.

18.5 Optimistic vs. ZK: The Comparison

The choice between optimistic and ZK-rollups is not a matter of one being "better" — it is a matter of tradeoffs suited to different use cases and different time horizons.

Comprehensive Comparison Table

The Long-Term View

A widely held view in the Ethereum community — expressed by Vitalik Buterin and others — is that ZK-rollups are the long-term winning architecture, but optimistic rollups are winning today because they shipped first with better EVM compatibility.

The reasoning: as ZK proof technology matures, proving costs will decrease, EVM compatibility will improve, and the inherent advantages of validity proofs (instant finality, no challenge period, mathematical security) will dominate. The question is whether this transition happens in two years or ten.

In the meantime, the two approaches are converging. Optimistic rollups are exploring hybrid designs that incorporate ZK proofs for certain operations. ZK-rollups are improving EVM compatibility to reduce friction for developers migrating from L1 or optimistic rollups.

The Shared Bottleneck: Data Availability

Despite their differences, both optimistic and ZK-rollups share a common cost bottleneck: posting transaction data to L1. In both cases, the raw transaction data (or a compressed version of it) must be available on L1 so that anyone can verify the rollup's state. This data posting typically accounts for 80-90% of the total L2 transaction cost.

This shared bottleneck is why EIP-4844 (which we will discuss in Section 18.8) was so transformative for both types of rollups.

18.6 State Channels

State channels are the oldest Layer 2 scaling concept, predating rollups by several years. The most famous implementation is the Lightning Network for Bitcoin, which launched in beta in 2018. The concept is simple and elegant: two parties open a private channel, transact between themselves as many times as they want off-chain, and settle the final result on-chain.

How State Channels Work

Opening the Channel. Two parties — let's call them Alice and Bob — each deposit funds into a multisig smart contract on L1. This creates a channel between them. The deposit transaction is the only one that touches L1 during normal operation.

Off-Chain Transactions. Once the channel is open, Alice and Bob can exchange signed messages that represent state updates — payments back and forth. These messages are not transactions on any blockchain. They are simply cryptographically signed data that both parties store locally.

For example, if Alice deposits 1 ETH and Bob deposits 1 ETH:

• Initial state: Alice: 1 ETH, Bob: 1 ETH
• Alice pays Bob 0.3 ETH: Alice: 0.7 ETH, Bob: 1.3 ETH
• Bob pays Alice 0.1 ETH: Alice: 0.8 ETH, Bob: 1.2 ETH
• ... (thousands of transactions can happen in seconds, for free)

Each state update is signed by both parties and includes a nonce (sequence number) that increases with each update.

Closing the Channel. When Alice and Bob want to settle, either party can submit the latest signed state to the L1 contract. If both parties agree (cooperative close), the funds are distributed immediately according to the final state. If there is a dispute (one party tries to submit an old state to cheat), the other party has a dispute period to submit the more recent state (with the higher nonce). The contract always honors the state with the highest nonce.

The Lightning Network

The Lightning Network is a network of state channels built on top of Bitcoin. Its key innovation is multi-hop routing: Alice does not need a direct channel with every person she wants to pay. If Alice has a channel with Bob, and Bob has a channel with Carol, Alice can pay Carol through Bob, using Hashed Timelock Contracts (HTLCs) to ensure that the payment is atomic — either it completes entirely or it reverts entirely.

As of early 2025, the Lightning Network has:

• ~16,000 public nodes
• ~60,000 public channels
• ~5,000 BTC in public channel capacity (~$350 million at $70,000/BTC)

The actual capacity is larger, because many channels are private (not advertised to the network).

Lightning has found significant adoption in specific use cases:

• El Salvador's Chivo wallet (the government-sponsored Bitcoin wallet) uses Lightning for retail payments
• Nostr (the decentralized social media protocol) uses Lightning for micropayments ("zaps")
• Cash App and Strike integrate Lightning for instant Bitcoin transfers

Raiden Network (Ethereum)

The Raiden Network is Ethereum's equivalent of Lightning — a network of state channels for ERC-20 token transfers. However, Raiden has seen far less adoption than Lightning, primarily because:

1. Ethereum's smart contract capabilities make rollups more attractive (you can roll up arbitrary computation, not just payments)
2. The Lightning Network benefits from Bitcoin's simpler scripting model, where state channels are one of the few viable scaling options
3. Rollups have largely overtaken state channels as the dominant L2 narrative on Ethereum

Strengths of State Channels

• Instant finality: Off-chain transactions are confirmed the moment both parties sign them. Latency is limited only by network round-trip time — typically milliseconds.
• Effectively zero fees: Once the channel is open, transactions cost nothing. There is no gas, no sequencer fee, no proof generation cost.
• Privacy: Off-chain transactions are visible only to the channel participants. The blockchain sees only the open and close transactions.
• Theoretical infinite throughput: There is no limit to how many transactions can occur in a channel per second, because they are just message exchanges between two parties.

Limitations of State Channels

• Requires both parties to be online (or to have a watchtower monitoring on their behalf). If Alice goes offline and Bob submits an old state, Alice must respond during the dispute period or lose funds.
• Capital lockup: Funds must be locked in the channel for the duration. If Alice locks 1 ETH in a channel with Bob, that ETH cannot be used for anything else until the channel is closed.
• Not suitable for general computation: State channels work well for payments and simple state transitions between known parties. They do not work well for complex smart contract interactions or for transactions involving unknown parties (like a decentralized exchange where you do not know your counterparty in advance).
• Routing complexity: Multi-hop payments require finding a path through the network with sufficient liquidity at every hop. This is a hard graph-theoretic problem, and routing failures remain a significant usability issue on the Lightning Network.
• Liquidity fragmentation: Capital is locked in specific channels. A merchant who wants to receive Lightning payments must maintain channel liquidity with many counterparties.

When State Channels Make Sense

State channels are ideal for frequent, bidirectional payments between known parties — the scenario where their strengths (instant, free, private) are maximized and their weaknesses (capital lockup, online requirement) are minimized. Gaming applications, streaming micropayments, and retail point-of-sale transactions are natural fits.

For general-purpose smart contract execution, rollups have largely won the L2 competition on Ethereum.

18.7 Sidechains

Sidechains occupy a distinct position in the Layer 2 landscape — and, strictly speaking, many researchers argue they are not true "Layer 2" solutions at all. A sidechain is an independent blockchain with its own consensus mechanism that is connected to a "parent" chain (like Ethereum or Bitcoin) through a bridge.

How Sidechains Work

A sidechain operates as a standalone blockchain. It has its own validators, its own block production, its own state, and its own security budget. The connection to the parent chain is established through a bridge contract:

1. Deposit: A user locks assets on the parent chain by sending them to the bridge contract
2. Minting: The sidechain mints equivalent assets on its chain (wrapped tokens)
3. Transacting: The user transacts on the sidechain, which is typically faster and cheaper than the parent chain
4. Withdrawal: When the user wants to return to the parent chain, they burn the wrapped tokens on the sidechain, and the bridge contract releases the original assets on the parent chain

Polygon PoS: The Dominant Sidechain

Polygon PoS (formerly Matic Network) is the most widely used sidechain connected to Ethereum. It uses a Proof-of-Stake consensus mechanism with ~100 validators and produces blocks every ~2 seconds with transaction costs of fractions of a cent.

Polygon PoS achieved massive adoption during the DeFi and NFT booms of 2021-2022, largely because it offered EVM compatibility (any Ethereum dApp could be deployed on Polygon with minimal changes) and extremely low fees. Major protocols like Aave, Uniswap, and SushiSwap deployed on Polygon, and the chain attracted significant user traffic.

However, Polygon PoS's sidechain architecture means its security is fundamentally different from a rollup:

• Polygon PoS has ~100 validators. Its security depends on a majority of these validators being honest. If 67% of validators collude, they can produce invalid blocks, censor transactions, or steal funds.
• A rollup's security depends on Ethereum's ~900,000 validators. Even if the rollup's sequencer is malicious, users can always verify the state and withdraw to L1.

This distinction is not academic. The Ronin bridge hack of March 2022 (which targeted the Axie Infinity sidechain) resulted in $625 million stolen when attackers compromised 5 of 9 bridge validators. A rollup-based architecture would not have been vulnerable to this type of attack.

Sidechains vs. Rollups: The Security Difference

The key distinction deserves explicit emphasis:

Rollups inherit the security of L1. Even if every rollup operator is malicious, users can force-withdraw their funds to L1 by interacting directly with the rollup's L1 contract. The L1 contract enforces the rules, and L1's full validator set secures those rules.

Sidechains have independent security. If the sidechain's validator set is compromised, users cannot rely on L1 to protect them. The bridge contract on L1 can only release funds when the sidechain's validators authorize it — and if those validators are corrupt, they can authorize fraudulent withdrawals.

This does not mean sidechains are useless. For many applications, the security of a well-run sidechain with 100 staked validators is more than sufficient, and the performance benefits (very low fees, very fast confirmation) are significant. But users should understand that they are trusting the sidechain's validator set, not Ethereum's.

Polygon's Evolution: From Sidechain to ZK

Polygon has recognized this limitation and is actively transitioning from a sidechain model to a ZK-rollup model. The Polygon 2.0 roadmap envisions:

• Polygon zkEVM: A true ZK-rollup that posts validity proofs to Ethereum (launched in mainnet beta in March 2023)
• Polygon CDK: A toolkit for creating custom ZK-powered L2 chains
• AggLayer: An aggregation layer that connects multiple Polygon chains with unified liquidity

This transition illustrates a broader trend: the industry is moving toward rollup-based architectures with stronger security guarantees, and sidechains are either evolving or being superseded.

Other Notable Sidechains

• Gnosis Chain (formerly xDai Chain): An Ethereum sidechain using a delegated Proof-of-Stake consensus with ~120 validators. Notable for its use in prediction markets (Gnosis's core product) and for accepting DAI as its native gas token.
• Ronin (rebuilt): After the 2022 hack, Ronin was rebuilt with a larger and more decentralized validator set. It remains the primary chain for Axie Infinity and other Sky Mavis games.

18.8 The Modular Blockchain Thesis

For the first decade of blockchain development, the dominant architecture was monolithic: a single chain handled execution, consensus, settlement, and data availability all in one. Bitcoin, Ethereum, Solana, and most other Layer 1 chains follow this model. Every node does everything.

The modular blockchain thesis challenges this approach. It argues that the most efficient and scalable architecture is one where different layers specialize in different functions:

• Execution layer: Where transactions are actually processed and state transitions happen (rollups)
• Settlement layer: Where disputes are resolved and finality is guaranteed (Ethereum L1)
• Data availability layer: Where transaction data is stored and guaranteed to be accessible (Ethereum L1, Celestia, EigenDA)
• Consensus layer: Where the ordering of data is determined

The Case for Modularity

The argument for modularity is essentially the argument for specialization in any engineering system. A monolithic chain must make compromises — it cannot simultaneously optimize for execution throughput, data availability, and decentralized consensus. By separating these functions, each layer can be optimized independently.

Consider the analogy to computer architecture. Early computers were monolithic — the CPU, memory, and I/O were tightly coupled. Modern computers separate these functions: the CPU handles computation, RAM provides fast temporary storage, SSDs provide persistent storage, and the network card handles communication. Each component is optimized for its specific function, and the system as a whole is far more capable than any monolithic design could be.

Celestia: The Data Availability Layer

Celestia (launched mainnet in October 2023) is the most prominent example of a purpose-built data availability (DA) layer. Celestia does only one thing: it orders data and guarantees that it is available. It does not execute transactions. It does not settle disputes. It simply provides a "bulletin board" where rollups can publish their transaction data.

Celestia achieves high data throughput through a technique called Data Availability Sampling (DAS). Instead of requiring every node to download every piece of data, DAS allows light nodes to verify data availability by downloading only a small random sample. Using erasure coding (the same technique used in RAID storage), the protocol can guarantee that if even a fraction of the data is available, the entire dataset can be reconstructed.

The implications for rollup economics are significant. Currently, rollups post data to Ethereum as calldata or blobs, which is expensive because Ethereum's block space is in high demand. A rollup that posts data to Celestia instead pays Celestia's (much lower) DA fees while still posting its state root to Ethereum for settlement. This creates a new category: sovereign rollups — rollups that use Celestia for data availability and have their own settlement rules, not necessarily anchored to Ethereum.

EIP-4844 and Proto-Danksharding

While Celestia represents external modularity (a separate chain for DA), Ethereum has pursued internal modularity through EIP-4844, also known as Proto-Danksharding. Implemented in the Dencun upgrade of March 2024, EIP-4844 introduced a new transaction type that carries blobs — large (~128 KB) chunks of data that are:

• Available for a limited time (~18 days, long enough for rollups to use)
• Priced in a separate fee market from regular execution gas
• Not accessible to the EVM (smart contracts cannot read blob data)

Before EIP-4844, rollups posted data as calldata, which competed with regular transactions for the same block space. After EIP-4844, rollups post data as blobs in a separate fee market, dramatically reducing costs. In the immediate aftermath of the Dencun upgrade, L2 transaction fees dropped by 90% or more:

Proto-Danksharding is called "proto" because it is a stepping stone toward full Danksharding, which will increase the number of blobs per block from 6 to potentially 64 or more, and implement Data Availability Sampling to further reduce node requirements. Full Danksharding is expected to make Ethereum capable of supporting hundreds of rollups simultaneously with negligible DA costs.

The Modular Stack in Practice

As of 2025, the modular blockchain stack is taking shape:

Execution: Hundreds of rollups (Arbitrum, Optimism, Base, zkSync, StarkNet, Scroll, Linea, Mantle, and many more) provide execution environments with different tradeoffs.

Settlement: Ethereum L1 serves as the primary settlement layer, but some rollups experiment with alternative settlement (e.g., settling on Arbitrum instead of directly on Ethereum, creating "L3" chains).

Data Availability: Ethereum (via blobs), Celestia, EigenDA, Avail, and Near DA provide competing data availability solutions with different security and cost profiles.

Consensus: Ethereum's Proof-of-Stake consensus (powered by ~900,000 validators) provides the strongest consensus guarantee, but modular DA layers have their own consensus mechanisms.

The Debate: Ethereum-Centric vs. Sovereign Modularity

The modular thesis has created a philosophical split in the blockchain community:

The Ethereum-centric view holds that Ethereum should be the settlement and data availability layer for all rollups. In this view, rollups that post data elsewhere (to Celestia, for example) are trading away Ethereum's security guarantees for cost savings — a tradeoff that may not be worth it. Vitalik Buterin has argued that Ethereum's roadmap should make DA on Ethereum cheap enough that there is no economic reason to go elsewhere.

The sovereign modularity view holds that different applications have different security needs, and it is wasteful to force a gaming rollup (which might process millions of low-value transactions) to pay for the same level of DA security as a DeFi rollup handling billions in TVL. In this view, Celestia and similar DA layers serve an important role by providing cheaper DA for applications that do not need Ethereum-grade security.

The resolution may be that both views are correct for different use cases. High-value financial applications will likely always prefer Ethereum DA for its security guarantees. Lower-value, higher-throughput applications may prefer cheaper alternatives.

18.9 The L2 Ecosystem Today

The Layer 2 ecosystem has grown from a theoretical concept to a multi-billion-dollar reality. Understanding the current state of this ecosystem is essential context for evaluating where blockchain technology is headed.

TVL and Adoption Metrics

As of early 2025, the L2 landscape on Ethereum includes:

Several trends stand out:

1. Optimistic rollups still dominate in TVL and transaction volume, largely because they launched earlier and offer better EVM compatibility.
2. Base (built by Coinbase on the OP Stack) has become one of the largest L2s by transaction volume, driven by Coinbase's massive user base and integration.
3. ZK-rollups are growing rapidly but from a smaller base, with improving EVM compatibility driving adoption.
4. Total L2 transaction volume exceeds Ethereum L1 — a milestone first crossed in mid-2024.

The Fragmentation Problem

The proliferation of L2s has created a new challenge: liquidity fragmentation. Assets and liquidity are spread across dozens of L2s, making it difficult for users to move between them and for dApps to access deep liquidity.

Consider a user who has ETH on Arbitrum but wants to use a dApp deployed on Base. They must:

1. Bridge ETH from Arbitrum to Ethereum L1 (waiting 7 days for the official bridge, or paying a fee for a fast bridge)
2. Bridge ETH from Ethereum L1 to Base (paying another bridging fee)

This is expensive, slow, and creates a poor user experience. Cross-L2 bridges (like Across, Stargate, and Hop) address this by enabling direct L2-to-L2 transfers, but they add their own trust assumptions and fees.

The industry is working on several solutions:

• Shared sequencing: Multiple L2s sharing the same sequencer, enabling atomic transactions across chains (proposed by Espresso Systems, Astria)
• Chain abstraction: Middleware that lets users interact with any L2 without knowing or caring which chain their assets are on (proposed by projects like NEAR's chain signatures, Socket, and Particle Network)
• Superchains: Clusters of L2s built on the same stack (like Optimism's Superchain or Polygon's AggLayer) with native interoperability

The Sequencer Centralization Problem

A persistent criticism of the current L2 landscape is sequencer centralization. In almost every major rollup, the sequencer — the entity that orders transactions and produces blocks — is a single server run by the rollup team.

This matters for several reasons:

• Censorship: A centralized sequencer can censor specific transactions or users
• MEV extraction: The sequencer has first access to transaction ordering and can extract maximal extractable value
• Liveness: If the sequencer goes down, the L2 stops producing blocks (though users can still force-include transactions via L1, this is slow and expensive)

Every major rollup team has stated plans to decentralize their sequencer, but as of early 2025, none have fully done so. The technical challenge is significant: decentralized sequencing must balance latency (users want fast confirmation), throughput (ordering must be efficient), and fairness (MEV should be distributed or minimized).

Security Stages

The L2Beat research team introduced a helpful framework for evaluating L2 security, classifying rollups into three stages:

• Stage 0: "Full training wheels." A multisig or centralized operator can override the rollup's state. The fraud proof or validity proof system exists but can be bypassed.
• Stage 1: "Limited training wheels." The proof system is functional, but the rollup retains a Security Council that can intervene in emergencies (e.g., to fix bugs in the proof system). At least 75% of the Council must agree, and there is a delay before interventions take effect.
• Stage 2: "No training wheels." The proof system is the sole arbiter of the rollup's state. The Security Council (if one exists) can only act on provably sound changes with significant delays.

As of early 2025, most rollups are at Stage 0 or Stage 1. Arbitrum was one of the first to reach Stage 1 in late 2024. Reaching Stage 2 requires battle-tested code, formal verification of critical contracts, and a level of maturity that the ecosystem is still working toward.

The Rise of L3s and App-Chains

A notable recent development is the emergence of Layer 3 (L3) chains — rollups that settle on other rollups rather than directly on Ethereum L1. The logic is straightforward: if an L2 rollup inherits Ethereum's security by posting proofs to L1, then an L3 chain can inherit the L2's security by posting proofs to the L2. This creates a recursive structure:

• L1 (Ethereum): Settlement and ultimate security
• L2 (e.g., Arbitrum): General-purpose execution with L1 security
• L3 (e.g., an Arbitrum Orbit chain): Application-specific execution with L2 security

Arbitrum Orbit, Optimism's OP Stack, and zkSync's Hyperchains all support this pattern. The appeal is clear: an L3 chain can be customized for a specific application (a game, a social network, a financial protocol) with its own gas token, governance, and throughput parameters, while still deriving security from the broader ecosystem.

Critics argue that L3s offer diminishing security returns — each additional layer adds latency to finality and complexity to the withdrawal path. Vitalik Buterin has suggested that L3s make sense primarily for specialized purposes (like privacy or custom execution environments) rather than simply as "cheaper L2s." The debate continues, but the trend toward application-specific chains — whether deployed as L2s or L3s — reflects a broader movement toward a multi-chain future where different applications have different infrastructure needs.

The User Experience Challenge

Perhaps the most significant barrier to L2 adoption is not technical but experiential. For a non-technical user, the current L2 landscape is bewildering: dozens of chains, each with its own bridge, its own block explorer, its own wallet configuration. Users must understand concepts like "switching networks" in MetaMask, managing gas tokens on different chains, and navigating bridge interfaces that carry real financial risk.

The long-term vision of chain abstraction — where users interact with applications without knowing or caring which chain they are on — remains aspirational. Achieving it requires progress on multiple fronts: intent-based architectures (where users express what they want and solvers figure out the routing), account abstraction (ERC-4337 and beyond, enabling smart contract wallets that handle cross-chain complexity), and standardized bridging protocols that reduce the risk and friction of moving between chains.

Until this user experience gap is closed, the L2 ecosystem will remain primarily accessible to crypto-native users who are willing to navigate its complexity. Closing this gap is arguably the single most important challenge for the L2 ecosystem in the coming years.

18.10 Summary and Looking Ahead

This chapter has covered a vast landscape of Layer 2 scaling solutions, each representing a different answer to the same fundamental question: how do we scale blockchain throughput without sacrificing the security and decentralization that make blockchains valuable?

The core insight is that you do not need every node to execute every transaction. You need every node to be able to verify that transactions were executed correctly — and that verification can be done far more efficiently than execution itself.

Optimistic rollups verify through social consensus: assume correctness, challenge if wrong. They are mature, EVM-compatible, and dominate today's L2 landscape.

ZK-rollups verify through mathematics: prove correctness with every batch. They offer stronger guarantees and faster finality but face higher computational costs and EVM compatibility challenges.

State channels verify through bilateral agreement: transact freely off-chain, settle disputes on-chain. They are ideal for frequent payments between known parties but ill-suited for general computation.

Sidechains do not verify through L1 at all — they run independent consensus. They offer high performance but at the cost of independent security assumptions.

The modular blockchain thesis ties these threads together: the future is not one chain that does everything, but a stack of specialized layers — execution rollups on top, settlement and data availability on the bottom — each optimized for its function.

As we move to Chapter 19, we will examine the DeFi protocols that are the primary users of this Layer 2 infrastructure — the decentralized exchanges, lending protocols, and yield aggregators that have created a parallel financial system on these chains. Understanding L2 scaling is essential context for understanding DeFi, because the economics of DeFi are profoundly shaped by transaction costs. A DEX trade that costs $50 on L1 and $0.02 on L2 is not just cheaper — it enables entirely different applications, from micropayments to high-frequency market-making, that are simply impossible at L1 cost levels.

The scaling story is far from over. Full danksharding, decentralized sequencers, real-time proving, cross-L2 interoperability, and shared security models are all active frontiers. But the foundation has been laid: Layer 2 works, it scales, and it is where the vast majority of blockchain activity will happen in the years ahead.

Key Takeaway: Layer 2 solutions do not weaken blockchain security — they leverage it. By using L1 as a secure foundation and moving execution off-chain, rollups achieve the throughput of centralized systems while preserving the trust guarantees of decentralized ones. The question is no longer whether L2 scaling works, but which approach best fits each application's requirements for security, cost, latency, and developer experience.