Layer 2 Scaling

A decentralized blockchain is slow for a structural reason: every node executes every transaction and stores the result. Raising throughput at layer 1 means raising the hardware requirements to run a node, which reduces how many people can — and the whole security argument rests on many independent people being able to.

Rollups resolve this by separating execution from settlement. Transactions execute on a separate chain with high capacity, and only compressed data plus a correctness guarantee are posted to layer 1. Ethereum verifies that guarantee without re-executing anything, so users get L1-grade security at a fraction of the cost. This is now Ethereum's stated roadmap rather than one option among several: the base layer settles and provides data availability, and applications live on L2.

The two families differ in what "correctness guarantee" means. Optimistic rollups assume validity and allow anyone to challenge it during a window. ZK rollups post a cryptographic proof that leaves nothing to assume.

TL;DR

The Architecture

The security claim rests on one property: the data needed to reconstruct L2 state is published to L1. If the sequencer disappears tomorrow, anyone can rebuild the chain's state from L1 data and withdraw. That's the line separating a rollup from a sidechain, and it's why data availability is the binding constraint on cost.

Optimistic vs. ZK Rollups

Optimistic rollups

The design assumes at least one honest party watches and challenges. The 7-day window exists to guarantee that party has time to act even under censorship pressure — which is also why native withdrawals to L1 take a week.

ZK rollups

Comparison

The practical convergence: ZK rollups are becoming EVM-equivalent, optimistic rollups are adding ZK proofs for faster finality, and the distinction matters less to application developers each year. Both deploy the same Solidity.

Data Availability

Rollup cost is dominated by what it posts to L1, not by execution.

EIP-4844 (proto-danksharding) introduced blobs: a separate, cheap data space with its own fee market, pruned after roughly 18 days. That's long enough for anyone to reconstruct state or challenge a batch, and it removed the requirement to pay permanent calldata prices for temporary data. L2 fees dropped by an order of magnitude or more when it shipped.

The DA spectrum

⚠️ Warning: If data is withheld, users cannot prove their balances and cannot exit — even with a valid execution proof. Validiums trade a real security property for cost. That can be the right call for a game or a high-frequency application, and it is not the same guarantee as a rollup.

Sequencers

The sequencer receives transactions, orders them, and produces L2 blocks. Nearly every production L2 runs exactly one, operated by the rollup team.

What a centralized sequencer cannot do: steal funds or forge state. Every batch is validated on L1 by a fraud or validity proof.

What it can do: censor your transaction, reorder for MEV, and stop entirely — halting the chain.

The mitigation is the forced inclusion or escape hatch: submit your transaction directly to the L1 contract, and the rollup must include it within a bounded delay. It's slow and expensive, and it's the difference between "the operator can inconvenience you" and "the operator can trap your funds." Check that any L2 you rely on has one and that it's actually been exercised.

Decentralized sequencing — shared sequencers, PoS sequencer sets, based rollups that inherit L1 proposers — is active work and largely not yet shipped.

Bridges

Moving assets between chains is the ecosystem's most-exploited component by a wide margin.

Native rollup bridges

Deposits and withdrawals through the rollup's own L1 contract, secured by the rollup's proof system. Deposits are fast (minutes); withdrawals take the challenge window on optimistic rollups and proof time on ZK rollups. This is the safest path, and the one to use for large amounts.

Third-party bridges

Liquidity networks and message-passing bridges that front you funds on the destination chain immediately, avoiding the delay. The security depends entirely on their own model — usually a multisig or a validator set, occasionally an optimistic or light-client design.

The pattern in every large bridge incident is the same: a trusted signer set or a signature verification flaw, not a flaw in the underlying chains. For significant value, use the native bridge and wait; use fast bridges for convenience amounts you'd accept losing.

Building on an L2

For application developers the practical picture is straightforward: deploy the same Solidity, with the same tooling, and pay a fraction of the fees.

Differences that do matter:

Best Practices

Use the native bridge for anything you'd mind losing

Third-party bridges optimize for speed and add their own trust assumptions. The delay on a native withdrawal is the price of the rollup's actual security guarantee.

Verify the chain has a working escape hatch

Forced inclusion via L1 is what makes sequencer centralization tolerable. Confirm the mechanism exists, understand its delay, and prefer chains where it's been tested rather than merely specified. L2BEAT tracks this per chain.

Don't treat L2 confirmation as settlement

For anything that triggers irreversible off-chain action or cross-chain movement, wait for the batch to finalize on L1. An L2 receipt is fast and is not the same guarantee.

Optimize calldata, not just execution

On rollups, the dominant cost is data posted to L1. Compressing arguments, using smaller types in calldata, and batching operations save far more than shaving opcodes.

Design for multiple chains from the start

Users and liquidity are spread across L2s, and that's unlikely to consolidate. Deterministic deployment addresses (CREATE2) across chains, chain-aware configuration, and a clear story for cross-chain state make later expansion tractable.

Read the specific chain's differences before deploying

"EVM-equivalent" covers a range. Timestamp semantics, gas accounting, precompile availability, and aliasing behavior vary. The documentation differences page for each chain is short and worth reading in full.

Monitor sequencer health as a dependency

If your application requires timely transactions, sequencer downtime is an outage for you. Detect it and degrade gracefully — several protocols check a sequencer uptime feed before honoring price-sensitive operations, which is a good pattern.

Common Mistakes

Treating an L2 confirmation as final for bridging

Assuming msg.sender is unchanged across the bridge

Relying on block.number for timing

Using a fast bridge for large transfers

Calling a validium a rollup

Ignoring sequencer downtime in price-sensitive logic

FAQ

Which L2 should I build on?

For EVM equivalence, tooling maturity, and liquidity today: Arbitrum, Base, or OP Mainnet. For fast finality and cheap proofs: zkSync Era, Linea, or Scroll. For a genuinely different execution model with strong native account abstraction: Starknet. In practice, existing liquidity, the ecosystem your users are already in, and grant availability decide this more often than architecture — the contracts are usually identical either way.

Why does withdrawing from an optimistic rollup take seven days?

The window is the time available for someone to submit a fraud proof if the sequencer posted an invalid state root. It's sized to remain safe even if an attacker attempts to censor challengers on L1 for an extended period. Third-party liquidity bridges front you funds immediately for a fee and take on the wait themselves — convenient, and a different trust model.

Are L2s as secure as Ethereum?

A true rollup with a working proof system and data on L1 inherits Ethereum's security for the correctness of state transitions. It does not inherit it for liveness — a centralized sequencer can censor or halt — nor for the correctness of the rollup's own contracts and proof system, which are additional code that can be wrong. L2BEAT publishes a per-chain risk assessment, and reading it for anything you depend on is worthwhile.

What's the difference between an L2 and a sidechain?

Data availability and settlement. A rollup posts its data to Ethereum and its state transitions are verified there, so users can always reconstruct state and exit unilaterally. A sidechain has its own consensus and its own security budget, and a bridge between them is just a bridge — if the sidechain's validators collude, there's no recourse from L1. Polygon PoS is a sidechain; Arbitrum is a rollup.

Will L2s fragment liquidity permanently?

It's the main open problem. Current mitigations are cross-chain messaging standards, shared or based sequencing, intent-based bridging where solvers handle routing, and chain abstraction in wallets so users stop thinking about which chain they're on. The direction of travel is toward users not knowing or caring; the infrastructure isn't there yet.

Does account abstraction work differently on L2?

Generally better. Several L2s have native account abstraction (Starknet and zkSync treat every account as a smart account), and on the rest, ERC-4337 works with dramatically lower gas costs — which is what makes sponsored transactions and batched operations economically sensible. Much of the improvement in Web3 onboarding UX has come from this combination.

Related Topics

References