Layer 2s & Scaling

What Layer 2 is

A Layer 2 (L2) is a network that sits on top of a base blockchain (the “Layer 1” or L1) and handles most of the transaction load, settling back to the L1 for security. The L2 does the work; the L1 keeps the record honest. The point is to get the throughput and low fees of a fast chain while inheriting the security and decentralization of the slow, careful base chain underneath.

The motivating problem is simple: major public L1s process only a few to a few dozen transactions per second, because every node verifies every transaction. That is the property that makes them credibly decentralized — anyone can run a node on a cheap computer — and it is also a hard ceiling on throughput. You can raise the ceiling by making blocks bigger or requiring more powerful hardware, but only by pricing most people out of running a node, which erodes the whole point. Layer 2 is the answer to the question how do you scale without sacrificing the property that makes the chain worth using.

Why scaling is hard

The fundamental tension is the blockchain trilemma: you can have at most two of decentralization, security, and scalability. A chain anyone can validate on a laptop (decentralization) that is expensive to attack (security) cannot also process millions of transactions per second, because every one of those transactions must be re-executed by every node. The blockchain topic page covers the trilemma in depth; the relevance here is that L2s are the main strategy for getting all three by splitting the job.

The naive fix — just make blocks bigger — is the path the block-size war was fought over on Bitcoin. It works, up to a point, but every increase in block size pushes up the hardware requirements to run a node, and over time the node count falls as only data centers can keep up. The chain gets faster and less decentralized. The L2 approach is the opposite bet: keep the L1 small and verifiable by anyone, and put the scale somewhere that does not require every node to do every unit of work.

The layered model

The layered model splits the blockchain's job in two. The L1 base layer is optimized for one thing: being a maximally secure, minimally expressive settlement and data-availability layer that anyone can verify. The L2 is optimized for a different thing: executing huge numbers of transactions cheaply, then posting a compressed summary — and enough data to reconstruct state — back to the L1.

The key word is inheritance. A good L2 inherits the L1's security: even if every L2 operator disappeared, users could still recover their funds from the data posted on the L1. This is what separates a real L2 from a sidechain (below), which simply runs its own consensus and does not inherit anything from the base chain. The distinction is the difference between “secured by Ethereum” and “secured by a separate, smaller network that happens to be connected to Ethereum.”

This is the explicit strategy of Ethereum, whose roadmap is officially “rollup-centric”: the L1 is deliberately kept lean so it can serve as a strong, cheap data layer for many rollups, rather than trying to host all applications itself.223

State channels & Lightning

The oldest L2 idea is the state channel. Two parties open a channel with one on-chain transaction, then exchange signed updates off-chain as fast as they like (each update just re-balances the channel), and close it with one final on-chain transaction. In between, they can transact thousands of times with zero on-chain footprint and instant finality. The Lightning Network is the canonical example, on Bitcoin.220

Channels scale by routing payments across a network of them: to pay someone you have no channel with, the network finds a path through intermediaries, using HTLCs (hash-locked contracts) so each hop is atomic — either the whole payment completes or none of it does. The strengths are speed and near-zero cost. The weaknesses are real: channels need capital locked up to be useful (liquidity), routing is a hard distributed problem, and the network is vulnerable to channel jamming attacks that are still being solved.222 Channels work best for payments and simple two-party state; they are a poor fit for the shared, public state that smart-contract applications need.

Rollups

The dominant L2 design today is the rollup. A rollup executes transactions off-chain on its own sequencer, then posts the compressed transaction data and a commitment to the new state to the L1. Because the data is on the L1, anyone can reconstruct the rollup's state and — if the design is sound — prove that the sequencer cheated. This is what makes a rollup a real L2 rather than a sidechain: the L1 holds the receipts, so the L2 cannot silently rewrite history.

Rollups come in two families, distinguished by how they prove the posted state is correct: optimistic rollups assume validity and rely on fraud challenges, and zero-knowledge rollups post a cryptographic validity proof so the L1 mathematically cannot accept an invalid state. The two have meaningfully different tradeoffs.

Optimistic rollups

An optimistic rollup assumes the sequencer's batches are valid and gives anyone a challenge window (typically about a week) to submit a fraud proof if they spot an invalid state transition. If a valid proof is posted, the batch is reverted and the dishonest party is slashed. If no one challenges in time, the state is accepted as final. Arbitrum, Optimism, and Base are the leading examples, and all are EVM-compatible — an Ethereum contract runs on them almost unchanged, which is why they absorbed Ethereum's application ecosystem so quickly.

The tradeoff is the exit window. Withdrawing from an optimistic rollup to the L1 takes the full challenge period, because the L1 must wait to see if anyone disputes the withdrawal. Fast withdrawals are possible via liquidity providers who front the funds for a fee, but the protocol-level finality is deliberately slow. The other tradeoff is trust in the fraud-prover set: the system is only as honest as someone being willing and able to challenge bad batches, so permissionless force-inclusion and a healthy prover ecosystem matter.

ZK rollups

A zk-rollup posts a validity proof alongside its data — a cryptographic argument that the new state is the correct result of the posted transactions. The L1 does not trust the sequencer; it verifies the proof, and a verified proof means the state is mathematically correct, with no challenge window. This gives zk-rollups faster L1 finality and a stronger security model in principle. zkSync, Starknet, Linea, Polygon zkEVM, and Scroll are the main examples. The zero-knowledge deep dive explains the cryptography →

The cost is that generating proofs is computationally heavy — proving EVM execution in zk is hard, and the proving infrastructure is still maturing. zk-rollups have historically been harder to make fully EVM-equivalent than optimistic rollups, though “type-1” proving (full EVM equivalence) is arriving. They also depend on trusted setup ceremonies for some proof systems, a one-time trust assumption the ecosystem works hard to minimize. The trajectory is clearly toward zk — the stronger security model and faster finality are real advantages — but optimistic rollups have a head start in tooling, compatibility, and deployed liquidity.

Data availability & blobs

A rollup is only as cheap as the L1 data it must post. For years the dominant cost of running a rollup was buying L1 calldata space to store its compressed transaction batches — a cost the rollup passed on to users. The 2024 Dencun upgrade (EIP-4844, proto-danksharding) changed that by introducing blobs: a separate, cheaper, time-limited data type reserved for rollups.225 L2 fees collapsed overnight, often by an order of magnitude, and L2 activity surged.

The deeper concept here is data availability: the guarantee that anyone can retrieve the data needed to reconstruct and verify the rollup's state. Without data availability, a rollup cannot be challenged (optimistic) or reconstructed (in the worst case), and it degrades toward a sidechain. Blobs are cheap precisely because they are pruned after a period — the L1 guarantees availability long enough for anyone to challenge or exit, then drops the data, which is enough for security without burdening the L1 forever. Full danksharding, the next stage, scales blob throughput dramatically through data-availability sampling, letting nodes verify blobs without downloading them whole.

Sidechains & validiums

Not everything called an “L2” inherits L1 security, and the distinction matters for how risky the chain is.

• Sidechains run their own consensus and bridge to the L1, but do not post data or proofs to it. Polygon PoS is the classic example. They are fast and cheap and genuinely useful, but they are secured by their own validator set, not by Ethereum — a sidechain's failure mode is its own, and a bridge to it is a real bridge-risk exposure, not an inherited L1 guarantee.
• Validiums post a zk validity proof to the L1 (so computation is sound) but keep the data off-chain with a data-availability committee rather than on the L1. They are cheaper than full rollups because they post less to the L1, but they introduce a trust assumption: if the data-availability layer withholds data, users cannot exit or reconstruct state, even though the proofs were valid. StarkEx-based systems (e.g. some older Immutable and Sorare deployments) use this model.

The spectrum, from most-secured to least: zk-rollup (proof + L1 data) → optimistic rollup (challenge + L1 data) → validium (proof, off-chain data) → sidechain (own consensus). All four are useful; only the first two are really “secured by Ethereum,” and marketing that blurs the line is worth being skeptical of.

The L2 landscape

The L2 ecosystem is now large and crowded. The optimistic side is led by Arbitrum (the largest by activity), Optimism (the OP Stack, whose codebase Base and others share), and Base (Coinbase's L2, growing fast on distribution). The zk side is led by zkSync, Starknet, Linea, Polygon's various zkEVMs, and Scroll. Most are EVM-compatible; a few (Starknet) run custom VMs with their own languages (Cairo) for performance.

The current problem is the opposite of the old one: there is now too much cheap capacity spread across too many isolated chains. Liquidity fragments across L2s (a token pool on Arbitrum is not the same as one on Base), users must bridge between them, and each L2 has its own sequencer — usually a single centralized operator that orders transactions. The focus of the next phase is putting the pieces back together: shared sequencing so L2s can be interoperable, decentralized sequencers to remove the central point of failure, and account abstraction to hide the L2 boundaries from users entirely.

Bridges & interoperability

Moving assets between L1 and L2, or between L2s, requires a bridge. The simplest L2 bridges are native: deposits lock funds in an L1 contract that the L2 mints against, and withdrawals verify the L2's state root on the L1 — so an L2-to-L1 withdrawal inherits the L2's security and needs no third party. These are the safest kind, because there is no separate bridge contract to attack.

Cross-L2 bridges (between two different rollups) are harder and riskier: they require one chain to read or trust the state of another, often via a separate committee or a light-client proof, and these bridge contracts have been the single most-hacked category in crypto history — billions lost to compromised multisigs, fake deposits, and flawed verification logic.188 Bridge hacks deep dive → Try the cross-chain lab to see how bridging works.

Risks & limitations

• Sequencer centralization. Most rollups run a single sequencer that can censor or reorder transactions (extracting MEV) — a real centralization point that undermines the “decentralized” claim until the sequencer is decentralized or force-inclusion escape hatches are robust.
• Upgrade keys & multisigs. Many rollups still have an admin key that can upgrade the contracts — a backdoor that must be removed for the chain to be credibly decentralized, and a historical source of large losses when keys were compromised.
• Exit windows & data availability. Optimistic rollups require a live challenger during the window; validiums require the data-availability layer to actually serve data. If either fails at the wrong moment, funds can be stuck.
• Fragmentation. Liquidity, users, and state are spread across many L2s. Until interoperability improves, the user experience of “which chain am I on?” is a real friction, and bridging between them carries real risk.
• Smart-contract risk. Rollups are complex software; a bug in the rollup's contracts or prover can be catastrophic, and the audit surface is far larger than a simple token contract.
• L2 token value. Many L2s issue a governance token whose value depends on fee capture and sequencer decentralization actually happening — the same “does the token need to exist” question that applies to altcoins generally.

Scaling beyond Ethereum

The layered model is not Ethereum-only. Bitcoin's scaling story is also L2-centric, via the Lightning Network for payments and, more recently, the various rollup-like proposals (Stacks, BitVM-style designs) attempting to bring more computation to Bitcoin without bloating the base layer. Bitcoin chose the most conservative base layer and is correspondingly the most reliant on L2 for any throughput at all.

Other chains take the opposite approach: instead of a lean L1 plus L2s, they make the L1 itself fast and monolithic. Solana is the leading example, optimizing the L1 for throughput with a single, high-performance validator set and novel techniques (proof of history, parallel execution), and pushing some scale-out work to app-specific L2s (“L3”-style) only more recently. This is a different point on the trilemma — less L1 decentralization in exchange for not needing a complex L2 stack — and it works for applications that prioritize speed. The two philosophies (lean L1 + many L2s vs. fast monolithic L1) are the genuine fork in scaling design, and the market has room for both.

History & milestones

The road ahead

The scaling story has inverted. Five years ago the problem was not enough capacity and eye-watering fees; today it is too much cheap capacity fragmented across too many chains. The next phase of L2 work is about consolidation rather than raw throughput:

• Shared sequencing & interoperability. Letting L2s share a sequencer or settle to each other natively, so a user on one can transact with a contract on another without a risky bridge — re-uniting the fragmented ecosystem.
• Decentralized sequencers. Removing the single sequencer as a censorship and MEV point, via proposer-builder separation-style designs and shared sequencing layers.
• Proof recursion & aggregation. Recursively combining many rollup proofs into one, so a single L1 proof secures many L2s — cheaper verification and the foundation for an L3 layer of app-specific chains settling to L2s.
• Full danksharding. Scaling blob throughput by orders of magnitude via data-availability sampling, so the L1 can feed data to many more rollups cheaply.224
• Hiding the seams. Account abstraction and cross-chain intents so users simply transact and never have to know which L2 they are on — the ultimate goal of the layered model.

The throughline is that L2s solved the throughput problem and immediately created a fragmentation problem, and the work ahead is putting the fragmented pieces back into a single coherent experience — cheap and fast like an L2, but as seamless to the user as if there were only one chain. The Ethereum roadmap deep dive traces where this is all going. The bet, across the whole sector, is that the layered model — a small secure base and a rich ecosystem of specialized layers on top — is the sustainable way to scale a blockchain without sacrificing the decentralization that made it worth scaling in the first place.