How Layer 2 Scaling Works

Layer 2 scaling is the umbrella term for protocols and architectures that move transaction execution off a blockchain's base layer (Layer 1) while still inheriting its security guarantees. The core insight is straightforward: if every node on Ethereum must re-execute every transaction to validate the chain, throughput is fundamentally capped by the slowest full node. Layer 2 systems break this constraint by executing transactions elsewhere and posting only compact proofs or compressed data back to L1.

The result is orders-of-magnitude more throughput at a fraction of the cost, without sacrificing the censorship resistance and finality properties that make a blockchain useful in the first place. Understanding how this works requires grappling with the blockchain trilemma, the mechanics of fraud and validity proofs, data availability, and the economics that tie it all together.

The Blockchain Trilemma: Why L1 Cannot Scale Alone

Vitalik Buterin articulated the blockchain trilemma as the claim that a monolithic blockchain can optimize for at most two of three properties: decentralization, security, and scalability. Increasing throughput on L1 typically requires either raising hardware requirements (which reduces the number of people who can run a full node, harming decentralization) or weakening consensus guarantees (which harms security).

Ethereum L1 processes roughly 15-30 transactions per second. Bitcoin manages 3-7. Solana achieves thousands of TPS but requires validators with powerful hardware, concentrating the validator set. The trilemma is not an iron law of physics but rather a design constraint that monolithic L1 architectures have consistently failed to escape. Layer 2 solutions circumvent it entirely by shifting the scalability dimension off-chain while anchoring security to L1.

The Layer 2 Landscape

Layer 2 is not a single technology but a family of approaches. They share the principle that L1 acts as a court of last resort: the base chain stores enough information to reconstruct state or adjudicate disputes, while the bulk of computation happens elsewhere. The main categories are rollups (optimistic and ZK), state channels, Plasma, and Validiums.

Optimistic Rollups: Fraud Proofs and the Challenge Period

Optimistic rollups are the most widely deployed L2 scaling solution today. Arbitrum and Optimism (OP Mainnet) together process billions of dollars in daily transaction volume. The word "optimistic" refers to their core assumption: transactions are assumed valid by default, and only checked if someone raises a dispute.

How Optimistic Rollups Work

An optimistic rollup operates a chain off-chain with its own block production, but posts transaction data (in compressed form) to Ethereum L1 as calldata or blobs. A sequencer collects transactions from users, orders them, executes them to produce state updates, and posts the resulting data to L1. Here is the lifecycle:

1. Users submit transactions to the sequencer (or directly to L1 for censorship resistance).
2. The sequencer orders and executes transactions, producing new state roots.
3. Batches of compressed transaction data are posted to L1 as calldata or EIP-4844 blobs.
4. State roots are proposed on L1 alongside the data.
5. A challenge window opens (typically 7 days) during which any observer can submit a fraud proof if they believe the state root is incorrect.
6. If no fraud proof is submitted, the state root is finalized and withdrawals to L1 can be processed.

Fraud Proofs in Detail

The security of an optimistic rollup depends entirely on the ability of at least one honest observer to detect and prove fraud during the challenge window. The economics are asymmetric by design: the sequencer must post a bond, and if a fraud proof succeeds, that bond is slashed and partially awarded to the challenger.

Arbitrum uses interactive fraud proofs (also called "dissection" or "bisection"): the challenger and the proposer iteratively narrow down the disputed computation to a single instruction, which is then executed on L1. This approach is gas-efficient because only one opcode is ever replayed on-chain. Optimism originally used non-interactive fraud proofs, where the entire disputed transaction is re-executed on L1 via a special on-chain VM (the "cannon" fault proof system), though Optimism's architecture has evolved significantly.

A critical implication of the fraud proof mechanism is the 7-day withdrawal delay. Assets moving from L2 back to L1 cannot be released until the challenge period expires. This delay is a direct consequence of optimistic security: you must wait long enough for any honest verifier to catch fraud. Third-party liquidity bridges (like Across or Hop Protocol) offer faster withdrawals by fronting the funds and assuming the fraud risk themselves.

Sequencers and Centralization Concerns

Today, both Arbitrum and Optimism operate centralized sequencers run by their respective foundations. The sequencer has the power to order transactions (enabling MEV extraction) and can temporarily censor transactions (though users can always bypass the sequencer by posting directly to the L1 inbox contract). Both projects have roadmaps toward decentralized sequencing, but this remains an open problem. Shared sequencing protocols like Espresso and Astria aim to provide a decentralized sequencer layer that multiple rollups can share.

ZK-Rollups: Validity Proofs and Instant Finality

ZK-rollups (zero-knowledge rollups) take the opposite approach to optimistic rollups. Instead of assuming validity and waiting for fraud proofs, ZK-rollups prove that every batch of transactions was executed correctly by generating a cryptographic validity proof (a SNARK or STARK) and posting it to L1. The L1 contract verifies this proof, which is computationally cheap, and immediately accepts the new state.

How ZK-Rollups Work

The architecture mirrors optimistic rollups in many ways: a sequencer collects and orders transactions, executes them, and posts compressed data to L1. The key difference is what happens next: instead of a challenge window, a prover generates a succinct proof that the state transition is valid. The L1 smart contract verifies this proof on-chain in a single transaction.

1. The sequencer collects, orders, and executes transactions off-chain.
2. The prover takes the transaction batch and generates a validity proof (SNARK or STARK). This is computationally expensive and may take minutes to hours.
3. The proof and compressed state diff are posted to L1.
4. The L1 verifier contract checks the proof. If valid, the state is immediately finalized. No challenge window required.

The immediate finality is a significant advantage: withdrawals from a ZK-rollup to L1 can be processed as soon as the proof is verified, with no multi-day delay.

The Major ZK-Rollup Projects

zkSync Era (by Matter Labs) uses a custom SNARK-based proving system and supports full EVM compatibility through its zkEVM. It compiles Solidity to a custom bytecode that is then proven in a ZK circuit.

StarkNet (by StarkWare) uses STARKs (Scalable Transparent Arguments of Knowledge) instead of SNARKs. STARKs have no trusted setup requirement (they are "transparent") and are post-quantum resistant, but produce larger proofs. StarkNet uses its own language (Cairo) and VM rather than direct EVM equivalence.

Polygon zkEVM aims for near-perfect EVM equivalence, executing Ethereum bytecode directly inside a ZK circuit. This makes it easy for existing Ethereum applications to deploy without code changes, but achieving efficient ZK proofs for the EVM's complex instruction set is an enormous engineering challenge.

Scroll and Linea are additional zkEVM projects taking slightly different approaches to the same problem: proving EVM execution efficiently.

SNARKs vs STARKs

The choice between SNARK and STARK proof systems involves tradeoffs in proof size, verification cost, prover time, and trust assumptions. SNARKs generally produce smaller proofs (a few hundred bytes) that are cheaper to verify on-chain, but many SNARK constructions require a trusted setup ceremony. STARKs produce larger proofs (tens of kilobytes) but require no trusted setup and are resistant to quantum computing attacks. Both are types of zero-knowledge proofs, though rollups primarily use the "succinctness" property (proof is small and fast to verify) rather than the "zero-knowledge" property (hiding inputs).

State Channels: Off-Chain for Fixed Participant Sets

State channels predate rollups and represent the earliest L2 scaling approach. The Lightning Network on Bitcoin is the most prominent example; Raiden Network is the Ethereum equivalent.

A state channel works by locking funds in an on-chain multisig contract, then allowing two (or more) participants to exchange signed state updates off-chain. Only two on-chain transactions are required: one to open the channel and one to close it. Between those two transactions, the participants can exchange thousands of updates instantly and for free.

How State Channels Operate

1. Open: Participants deposit funds into a smart contract on L1, establishing the channel.
2. Transact: Participants exchange signed messages representing balance updates. Each message includes a monotonically increasing nonce. No on-chain transactions occur.
3. Close: Either participant submits the latest state to the on-chain contract. A dispute period allows the other party to submit a more recent state (with a higher nonce) if the closer tried to cheat.

State channels are extremely efficient for their use case but have significant limitations. They require all participants to be online and watching for fraud, they only work for a fixed set of participants (you cannot send to someone you do not have a channel with, unless you route through intermediaries), and they cannot support general-purpose smart contracts. The Lightning Network solves the routing problem with a network of payment channels and hash time-locked contracts (HTLCs), but the complexity is substantial.

Plasma: The Predecessor to Rollups

Plasma was proposed by Vitalik Buterin and Joseph Poon in 2017 as a framework for creating child chains anchored to Ethereum. Each Plasma chain has its own block production and posts periodic commitments (Merkle roots of its state) to L1. Users can exit the Plasma chain by submitting a Merkle proof demonstrating they own funds.

Plasma's key limitation is the data availability problem: the Plasma operator can withhold block data, making it impossible for users to construct the exit proofs they need to withdraw their funds. While exit games and mass exit mechanisms were designed to handle this, the complexity proved unworkable for general-purpose computation. Plasma works reasonably well for simple payment use cases but fails for arbitrary smart contract state, because proving ownership of complex state in an exit game is extremely difficult.

Rollups solved Plasma's core problem by posting all transaction data on-chain: if the data is on L1, it is always available, and anyone can reconstruct the full state. This insight is why rollups supplanted Plasma as the dominant L2 paradigm.

Validiums: Rollup Proofs Without On-Chain Data

A Validium is architecturally identical to a ZK-rollup except that transaction data is stored off-chain rather than posted to L1. The validity proof is still posted and verified on L1, so the L1 contract always knows the state is correct, but users must trust that the data is available somewhere (a committee, a separate DA layer, etc.) to reconstruct state and generate exit proofs.

StarkWare's StarkEx operates in Validium mode for some applications (like dYdX v3 and Immutable X). The tradeoff is straightforward: dramatically lower costs (no L1 data posting) at the expense of weaker security guarantees. If the data availability committee colludes or goes offline, users may be unable to prove ownership of their assets and exit.

Volitions are a hybrid model where users can choose per-transaction whether to store data on-chain (rollup mode) or off-chain (validium mode), balancing cost and security based on the value of the transaction.

Data Availability: The Linchpin of Rollup Security

Data availability (DA) is the most critical and often misunderstood component of rollup architecture. The question it answers is simple: can anyone who needs the transaction data actually access it? If data is unavailable, rollup security degrades to that of a Validium or worse. For optimistic rollups, unavailable data means fraud proofs cannot be constructed. For ZK-rollups, unavailable data means users cannot prove their balances to exit.

EIP-4844: Proto-Danksharding and Blob Transactions

Before March 2024, rollups posted data to Ethereum as calldata within regular transactions. Calldata is stored permanently by all Ethereum nodes and is expensive: it costs 16 gas per non-zero byte. For rollups that post megabytes of data daily, this was the dominant cost.

EIP-4844 (activated in the Dencun upgrade) introduced a new transaction type: blob-carrying transactions. Blobs are large chunks of data (~128 KB each) that are committed to via KZG polynomial commitments but are not stored permanently by the execution layer. Consensus nodes guarantee blob availability for approximately 18 days, after which they can be pruned. This is sufficient for rollup security because the challenge period (7 days for optimistic rollups) is shorter than the availability window.

EIP-4844 reduced rollup costs by roughly 100x overnight. Crucially, blobs have their own fee market, separate from the L1 execution gas market, so rollup data costs do not spike when L1 is congested with DeFi activity.

Full Danksharding (the next step, still in research) will expand from the current 3-6 blobs per block to potentially 64-256 blobs per block, using data availability sampling (DAS) so that individual nodes only need to download a random subset of the data to probabilistically guarantee the full data is available.

Alternative DA Layers: Celestia, EigenDA, Avail

Not all rollups post data to Ethereum. Alternative data availability layers offer even cheaper DA at the cost of different security assumptions:

• Celestia is a purpose-built DA layer that uses data availability sampling (DAS) with erasure coding. Celestia light nodes can verify data availability by sampling random chunks, without downloading the full data. Rollups that use Celestia for DA are sometimes called "Celestiums" and inherit Celestia's security rather than Ethereum's.
• EigenDA leverages Ethereum's validator set through EigenLayer restaking. Validators who restake their ETH attest to data availability, providing economic security proportional to the restaked amount. This approach ties DA security to Ethereum's economic security without burdening all Ethereum nodes with the data.
• Avail (originally incubated by Polygon) is another dedicated DA chain using KZG commitments and DAS, similar in concept to Celestia but with different implementation choices.

The tradeoff is always the same: cheaper data availability at the cost of relying on a separate security model rather than Ethereum L1's full validator set.

Rollup Economics: Where the Costs Go

Understanding rollup economics requires decomposing the costs. A rollup has two major cost categories: L1 costs (posting data and proofs to Ethereum) and L2 execution costs (running the sequencer and, for ZK-rollups, the prover).

L1 Data Costs

Before EIP-4844, L1 data costs comprised 80-95% of total rollup operating costs. Rollups compress transaction data aggressively: signatures are removed (since the sequencer has already verified them), addresses are replaced with indices, and zero bytes are optimized. A typical Ethereum transaction is ~110 bytes; after rollup compression, it can be as small as ~12-16 bytes.

Even after EIP-4844, L1 data remains the largest cost component, though the absolute numbers are much lower. Rollups amortize this cost across all transactions in a batch: the more transactions per batch, the lower the per-transaction L1 cost.

Proof Costs (ZK-Rollups Only)

ZK-rollups incur an additional cost for proof generation. Running the prover requires specialized hardware (high-memory machines, sometimes GPUs or FPGAs) and significant computation time. However, proof generation costs are amortized across all transactions in the batch, and proof verification on L1 is constant-cost regardless of batch size. This means ZK-rollups have strong economies of scale: a batch of 10,000 transactions has roughly the same proof cost as a batch of 1,000.

Revenue Model

Rollups charge users a transaction fee that covers L1 costs, L2 execution costs, and a margin. The sequencer collects this fee and also captures MEV (Maximal Extractable Value) from transaction ordering. The profit margin has been a point of controversy: centralized sequencers capture all MEV without sharing it with users or the L1.

Based Rollups: L1-Sequenced Scaling

A based rollup (or "L1-sequenced rollup") is a rollup where Ethereum L1 validators serve as the sequencer. Instead of having a dedicated sequencer that orders transactions, the rollup's transaction ordering is determined by the L1 block proposer who includes the rollup's data.

Based rollups offer compelling properties:

• Inherit L1 liveness and censorship resistance from day one, with no separate sequencer to centralize or decentralize.
• No sequencer MEV extraction — MEV goes to L1 validators through existing mechanisms.
• Atomic composability with L1 is easier because the same block proposer orders both L1 and L2 transactions.
• Simpler architecture — no sequencer infrastructure to operate or decentralize.

The tradeoff is that based rollups have L1 block time latency (12 seconds on Ethereum) for transaction confirmation, compared to the sub-second soft confirmations that a dedicated sequencer can provide. This may be acceptable for many applications but is a dealbreaker for latency-sensitive use cases like high-frequency trading.

Taiko is the most prominent based rollup project. The design is still maturing, and hybrid approaches that combine a fast pre-confirmation layer with based sequencing for final ordering are being explored.

The Rollup-Centric Roadmap

In late 2020, Vitalik Buterin proposed that Ethereum's long-term scaling strategy should center on rollups rather than on increasing L1 throughput. This "rollup-centric roadmap" has since become Ethereum's official scaling strategy. The core idea is that Ethereum L1 optimizes for three things:

1. Consensus and security — L1 remains the settlement layer with the strongest decentralization and security properties.
2. Data availability — L1 expands its capacity to store rollup data (via EIP-4844 and eventually full Danksharding).
3. Proof verification — L1 provides efficient on-chain verification of rollup proofs (via precompiles for pairing operations, hash functions used in STARKs, etc.).

In this model, nearly all user-facing transactions occur on L2 rollups, and L1 serves as the secure foundation. The endgame envisions thousands of rollups sharing Ethereum's security, with cross-rollup bridges and shared sequencing enabling interoperability.

This approach has influenced the broader blockchain ecosystem. Other L1 chains have adopted similar rollup-centric strategies, and the distinction between "L1" and "L2" has become a fundamental architectural concept in blockchain design.

Comparison of L2 Approaches

The following table summarizes the key tradeoffs across Layer 2 scaling approaches:

The L2 Fragmentation Problem

As the number of L2s has proliferated, a new challenge has emerged: liquidity and user experience fragmentation. Each rollup is its own execution environment with its own state, meaning assets on Arbitrum are not natively accessible from Optimism. Users must bridge assets between rollups, paying fees and waiting for finality. Developers must decide which rollup to deploy on, and liquidity is split across dozens of chains.

Several approaches aim to address this:

• Shared sequencing (Espresso, Astria) enables atomic transactions across multiple rollups by having a single sequencer order transactions for all of them.
• Cross-rollup messaging protocols (LayerZero, Axelar, Hyperlane) provide bridging infrastructure but with varying trust assumptions.
• Superchain architectures (Optimism Superchain, Polygon AggLayer) aim to create networks of rollups that share security and can interoperate natively.
• Intent-based bridging (Across, UniswapX) uses market makers to fill cross-chain orders, abstracting bridge complexity from users.
• Chain abstraction protocols aim to make the underlying chain invisible to users, routing transactions to the optimal chain automatically.

The Endgame: Where L2 Scaling Is Heading

The trajectory of L2 scaling is toward a world where users never interact with L1 directly. Transaction fees on rollups are already sub-cent for many operations, and they will continue to drop as DA capacity expands and proving technology matures. Several trends are converging:

• ZK proof commoditization: Proof generation is becoming faster and cheaper. Hardware acceleration (GPUs, FPGAs, ASICs) will drive proving costs toward negligible levels, eventually making ZK-rollups strictly superior to optimistic rollups (which exist primarily because ZK proving was too slow and expensive when they launched).
• Full Danksharding: Ethereum will eventually support 64+ blobs per block with data availability sampling, providing abundant, cheap DA that renders alternative DA layers unnecessary for chains that want Ethereum-grade security.
• Decentralized sequencing: The current centralized sequencer model will give way to decentralized or shared sequencing, removing the last major centralization vector from rollup architectures.
• Application-specific rollups: Rather than general-purpose L2s, we may see rollups customized for specific use cases (gaming, DeFi, social) with tailored execution environments and DA choices.

Layer 2 scaling is not a temporary workaround while L1 catches up. It is the permanent architecture of scalable blockchains. The Ethereum network's explicit strategy is to become the best possible settlement and data availability layer, with all user-facing activity happening on L2. This modular design, where execution, settlement, and data availability are separated into specialized layers, represents the most promising path to blockchain scalability without sacrificing the decentralization that makes blockchains worth using in the first place.