How Layer 2 Scaling Works

The Scaling Problem

Ethereum can process roughly 15 transactions per second on Layer 1. Visa processes 24,000. The gap is not a bug — it is a deliberate design choice. But it makes Ethereum unusable at scale without a second layer of infrastructure on top.

The constraint is the blockchain trilemma: any blockchain must trade off between decentralisation, security, and scalability. Ethereum chose decentralisation and security over throughput. Every full node must download, verify, and store every transaction — limiting throughput to what the average node can handle. Increasing the block size or frequency would exclude cheap hardware, centralising validation.

The cost of this choice became visible during DeFi Summer 2020 and the NFT boom of 2021. Gas prices on Ethereum L1 regularly exceeded $50–200 for a simple token swap — pricing out ordinary users entirely. Competing Layer 1s (Solana, Avalanche, BNB Chain) captured activity by offering faster, cheaper transactions — at the cost of greater centralisation.

Ethereum's answer was not to compromise its L1 properties but to scale off-chain: execute transactions in a separate environment, but inherit Ethereum's security by anchoring the results on L1. This is the Layer 2 paradigm.

How L2s Work

A Layer 2 is a separate blockchain that processes transactions faster and cheaper than Ethereum, then periodically posts a compressed summary to Ethereum L1 to inherit its security. Users transact on L2; Ethereum provides the ultimate settlement guarantee.

The core mechanic is batching. Instead of posting every transaction to Ethereum (expensive), the L2 collects thousands of transactions, executes them off-chain, and posts only a compressed summary — called a batch or rollup — to Ethereum. The data required to reconstruct L2 state is published on-chain, so anyone can verify or reconstruct the L2 state from L1 data alone.

This is the key security property: L2 security is inherited from Ethereum, not independent of it. If the L2 operator (sequencer) posts fraudulent state, either a fraud proof or a validity proof will catch it — depending on the rollup type. The user never has to trust the sequencer; they only trust Ethereum.

1. 1
   User submits a transaction to the L2

   The transaction is submitted to the L2 sequencer — either via a public RPC or directly. The sequencer orders and includes the transaction in an L2 block within seconds.

2. 2
   Sequencer orders and executes transactions

   The sequencer executes transactions deterministically and produces a new L2 state root. This is fast — no global consensus required at this stage.

3. 3
   Transactions are batched and compressed

   Hundreds to thousands of L2 transactions are compressed into a batch. Compression ratios of 10–100× are common. The batch is signed by the sequencer.

4. 4
   Batch is posted to Ethereum L1

   The compressed batch (and in some cases, a cryptographic proof) is posted to an Ethereum smart contract as calldata or a blob. This anchors L2 state in Ethereum's history.

5. 5
   Finality is reached

   For optimistic rollups: finality after the 7-day fraud proof window. For ZK rollups: finality as soon as the validity proof is verified on L1 (~15–60 min).

Optimistic Rollups

Optimistic rollups assume transactions are valid unless proven otherwise. The sequencer posts state roots to Ethereum without a proof — and a 7-day window allows anyone to challenge fraudulent submissions.

The name "optimistic" captures the assumption: we optimistically accept the sequencer's state root as correct. If it is wrong, a challenger can submit a fraud proof — a transaction that proves, on-chain, that a specific execution step was incorrect. The fraud proof identifies the exact instruction that was wrong and forces the EVM to re-execute only that step, rather than the entire batch. This is called interactive bisection or multi-round fraud proofs.

The 7-day challenge window is a security parameter, not a technical constraint. It must be long enough for an honest challenger to detect fraud, prepare a proof, and submit it to Ethereum — even under adversarial conditions (censorship, high gas prices). Shorter windows reduce user friction but increase the attack surface. Some protocols are exploring trusted execution environments (TEEs) to allow shorter windows.

The economic model is important: challengers receive a bond from the fraudulent sequencer as a reward for catching the fraud. Sequencers must also post a bond that is slashed if their state root is successfully challenged. This makes fraud economically irrational — the cost of being caught far exceeds any profit from fraudulent state transitions.

ZK Rollups

ZK rollups post a cryptographic validity proof alongside each batch. The proof mathematically guarantees that every transaction in the batch was executed correctly. No trust is required — and no challenge window is needed.

The proof is a ZK-SNARK (Succinct Non-interactive ARgument of Knowledge) or ZK-STARK (Scalable Transparent ARgument of Knowledge). Both can compress the verification of millions of computations into a proof that Ethereum can check in a single transaction. The "succinct" in SNARK means the proof is tiny (hundreds of bytes) regardless of how large the underlying computation was.

The challenge is zkEVM compatibility. The EVM was not designed with ZK proving in mind — its opcodes and state model are expensive to prove in ZK circuits. zkEVM projects classify their compatibility on a spectrum from Type 1 (fully equivalent to Ethereum, slowest to prove) to Type 4 (transpiles Solidity to ZK-friendly code, fastest). Most production zkEVMs today are Types 2–3: bytecode-compatible but with some performance differences.

Sequencers & Decentralisation

Every major L2 today relies on a single centralised sequencer — a server run by the project team that orders all transactions. This is the most significant centralisation risk in the current L2 landscape.

The sequencer is responsible for ordering transactions (deciding which come first in a block), executing them, and posting batches to Ethereum. A centralised sequencer can:

Censor transactions — refuse to include specific transactions, targeting addresses, protocols, or countries. Unlike Ethereum L1 (where multiple block builders compete), an L2 with one sequencer has no redundancy.

Extract MEV — reorder transactions to frontrun users, extract sandwich attack profits, or sell priority ordering to searchers.

Go offline — if the sequencer stops working, the L2 halts. Users can still withdraw to L1 (via "escape hatches" or force-inclusion mechanisms), but the L2 stops processing new transactions.

All major L2 teams have roadmaps for decentralised sequencing. Approaches include round-robin sequencer sets, PoS sequencer elections, and shared sequencing layers like Espresso or Astria that serve multiple rollups. The technical challenge is maintaining low latency while distributing sequencing authority — a hard problem that no team has fully solved at production scale.

Data Availability

For an L2 to inherit Ethereum's security, the data needed to reconstruct L2 state must be publicly available. This is the data availability (DA) problem — and it determines both the security and the cost of every rollup.

If transaction data is not available, users cannot prove their L2 balance and cannot withdraw to L1. This is the "data withholding attack": a malicious operator posts a batch to Ethereum but withholds the actual transaction data. Users cannot reconstruct state and cannot generate fraud proofs. Ethereum cannot verify whether the data is valid if it cannot see the data.

EIP-4844 (Proto-Danksharding), shipped in March 2024, was the most impactful Ethereum upgrade for L2s since rollup theory was developed. It introduced a new transaction type called a blob — a sidecar of up to 128kB carrying rollup data. Blobs use a separate fee market (blob gas), are available to full nodes for ~18 days (long enough for fraud proofs), and are then pruned. The result: L2 fees dropped 80–99% overnight. Arbitrum fees fell from ~$0.50 to ~$0.005 per transaction.

The long-term roadmap is full Danksharding: scaling blob capacity from the current target of 3 blobs/block to 64 blobs/block using data availability sampling (DAS). DAS allows light nodes to verify that data was made available without downloading it all — by randomly sampling small pieces and using erasure coding to guarantee that if enough samples are available, the full data can be reconstructed. This is expected to increase L2 throughput by another 10–100× beyond EIP-4844.

Bridges & Withdrawals

Moving assets between Ethereum L1 and an L2 requires a bridge — a pair of smart contracts that lock assets on one side and release them on the other. The security of withdrawals is one of the most critical and misunderstood properties of any L2.

Native bridges are operated by the rollup protocol itself. They are the canonical path for deposits and withdrawals. A deposit (L1 → L2) is fast: the L1 contract locks ETH or tokens, and the L2 recognises the deposit in the next batch. A withdrawal (L2 → L1) is slow — limited by the rollup's finality model.

For optimistic rollup native withdrawals, the 7-day challenge window means you must wait a full week for your ETH to arrive on L1. Fast withdrawal services (Across, Hop, Synapse) solve this by fronting liquidity: a liquidity provider instantly sends ETH on L1, waits out the challenge window to claim from the bridge, and charges a small fee for the service.

For ZK rollup withdrawals, the wait is ~15–60 minutes for the validity proof to be generated and verified. No challenge window is needed — the proof is final. This is a significant UX advantage of ZK over optimistic rollups for capital-intensive users.

Major L2 Ecosystems

Five networks dominate the L2 landscape today — three optimistic rollups and two ZK rollups — each with distinct technical designs, governance models, and ecosystem strategies.

Beyond these five, the L2 landscape has fragmented into hundreds of application-specific chains (appchains). The OP Stack enables teams to launch an L2 in days; the ZK Stack, Polygon CDK, and Arbitrum Orbit offer similar frameworks. Game studios, social apps, exchanges, and DeFi protocols are all launching dedicated chains — trading ecosystem composability for customisation and sovereignty.

L3s (Layer 3s) take this further: an appchain deployed on top of an L2, inheriting L2 security while posting data to the L2 rather than Ethereum directly. Arbitrum Orbit chains settling on Arbitrum One are L3s. The security model is weaker (L3 security ≤ L2 security ≤ L1 security), but fees are even lower.

Risks & Trade-offs

L2s inherit Ethereum's security — but only partially, and with significant caveats. The current generation of rollups introduces new failure modes that users and developers must understand.

The most underappreciated risk is upgrade keys. Every major rollup today has admin keys — multisigs or DAO-controlled contracts — that can upgrade the bridge contracts and rollup smart contracts. A malicious upgrade could drain all bridged funds with no fraud proof or challenge window. The L2Beat website tracks the "stage" of each rollup's decentralisation, rating them from Stage 0 (training wheels on, admin keys can override everything) to Stage 2 (fully permissionless, no admin override). As of 2025, most major rollups are at Stage 1 or below.

The Endgame

Vitalik Buterin's "rollup-centric roadmap" positions L2 rollups as the permanent execution layer of Ethereum. The endgame is a world where users transact on rollups, and Ethereum L1 serves exclusively as a settlement and data availability layer.

Full Danksharding — the final phase of Ethereum's scaling roadmap — will increase blob capacity from 3 to 64 blobs per block, each 128kB. Combined with data availability sampling, this will allow light nodes to verify availability without downloading full blocks. The result: Ethereum L1 capable of hosting thousands of transactions per second worth of rollup data, at negligible cost per transaction.

The cross-rollup fragmentation problem is the unsolved challenge. Today, liquidity is siloed across dozens of L2s. Bridging between L2s requires going through L1 (slow) or using third-party bridges (risky). Shared sequencing networks (Espresso, Astria), native interoperability frameworks (OP Stack Superchain, ZK Stack Hyperchains), and cross-chain messaging protocols (LayerZero, Wormhole, CCIP) are all attacking this problem — but no solution has achieved the seamless UX of a single chain.

The long-run equilibrium may look like this: a small number of sovereign L2s (each with strong security and deep liquidity) host most DeFi activity, while thousands of appchains handle specialised use cases — gaming, social, enterprise — at the L3 level. Ethereum L1 becomes the global settlement layer, processing only the most critical state roots and DA commitments. Users may not know or care which chain they are on.