What are layer 2 solutions?

The scalability problem

Public blockchains ask every participating node to re-execute and store every transaction. That redundancy is the source of their security: anyone can independently check the chain’s history. It is also the source of their throughput ceiling. If a network wants more transactions per second, the obvious levers are larger blocks or faster block times — but both raise the hardware, bandwidth, and storage burden of running a full node.

As those requirements climb, fewer people can afford to operate independent nodes, and the network drifts toward a smaller set of well-resourced operators. This is the heart of what is often called the scalability trilemma: pushing hard on raw throughput tends to come at the expense of decentralization or security. The base layer can stay decentralized and secure, but it cannot, on its own, also become a high-throughput global settlement engine without compromise.

Layer 2 (L2) is the response. Rather than forcing more work onto the base layer, an L2 performs the work elsewhere and uses the base layer to keep that work honest.

What a layer 2 actually is

A layer 2 is a separate system that processes transactions off the main chain — referred to as layer 1 (L1) — and then commits the results back to L1. The defining property of a true L2 is that it inherits the security of the base chain. Users should be able to rely on L1 to guarantee the correctness and availability of their L2 funds, even if the L2’s own operators misbehave or disappear.

Ethereum’s documentation frames the base layer as a settlement and data-availability foundation, with L2s acting as a “network of networks” built on top of it. The L2 handles the heavy lifting of execution; L1 provides the anchor of trust.

This is a meaningfully different model from simply running a second blockchain. The strength of the guarantee depends on how the L2 talks to L1 — specifically, what data and proofs it publishes there.

Rollups, sidechains, and state channels

Three broad families are usually grouped under “scaling solutions,” but they make very different trust assumptions.

Rollups

A rollup executes transactions off-chain, bundles many of them together, and posts a compressed summary of that batch — crucially, including the underlying transaction data — to L1. Because the data lives on the base chain, anyone can reconstruct the rollup’s state and verify it. As Vitalik Buterin puts it in An Incomplete Guide to Rollups, rollups “move computation (and state storage) off-chain, but keep some data per transaction on-chain.” That published data is what lets the system stay trust-minimized. Rollups are the design the ecosystem has converged on, and they split into two enforcement styles, covered below.

Sidechains

A sidechain is an independent blockchain with its own validators and consensus rules, connected to L1 by a bridge. It does not post its transaction data or proofs to the base layer, so its security comes entirely from its own validator set. Sidechains can offer high throughput and low fees, but a user’s funds are only as safe as the sidechain’s own consensus and its bridge. Under the strict modern definition, a sidechain is not a layer 2, because it does not inherit base-layer security.

State channels

State channels let a fixed group of participants transact directly among themselves off-chain, exchanging signed messages, and touch the base layer only to open and close the channel. They can deliver near-instant, near-free transactions for the parties involved, and the base layer adjudicates disputes. The trade-offs are that participants must lock funds up front, must stay online to defend against an outdated state being submitted, and channels work best for repeated interactions between known counterparties rather than open, arbitrary activity.

Optimistic vs. ZK rollups

Within the rollup family, the key question is how L1 becomes convinced that a batch of off-chain transactions was processed correctly. There are two answers.

Optimistic rollups assume batches are valid by default and rely on fraud proofs to catch cheating. After a batch is posted, there is a challenge window — commonly around seven days — during which any watcher can submit evidence that the batch was invalid. If a valid challenge succeeds, the bad batch is reverted and the proposer is penalized. This keeps on-chain costs low in the normal case, but it means full withdrawals to L1 must wait out the challenge period.

ZK rollups (also called validity-proof or zero-knowledge rollups) take the opposite stance: they publish a cryptographic validity proof with each batch that mathematically demonstrates the batch was processed correctly. L1 verifies the proof before accepting the batch, so there is no need for a dispute window and withdrawals can finalize much faster. The cost is greater technical complexity and the computational expense of generating proofs.

The trade-off, in short, is waiting versus proving: optimistic rollups defer verification and add a delay, while ZK rollups verify up front at the price of heavier cryptography. ZK rollups are covered in depth in the companion article.

Why data availability is the linchpin

The single property that separates a trust-minimized rollup from a sidechain is data availability — the guarantee that the underlying transaction data is published somewhere anyone can retrieve it.

If the data is available, users can always reconstruct their balances and exit to L1, even if every L2 operator vanishes. If the data is withheld, neither fraud proofs nor validity proofs help a user recover funds they can no longer reconstruct. This is why rollups post data to the base layer and why tracking sites such as L2BEAT classify systems partly by where they put their data. Designs that move data availability off the base chain — variants known as validiums and optimiums — gain throughput but reintroduce a trust assumption about whoever holds that data.

Takeaway

Layer 2 is less a single technology than a strategy: keep execution off the base chain, keep verification and data on it. Rollups are the strongest expression of that strategy today, with the optimistic-versus-ZK distinction governing how correctness is enforced and how quickly funds can leave. When evaluating any “scaling solution,” the most revealing questions are where the data lives and what guarantees the base layer actually provides — everything else follows from those answers.