layer-2.wiki — The Layer-2 Knowledge Base

What is Layer-2?

A Layer-2 (L2) is any protocol that processes transactions outside of a base blockchain (the Layer-1) while relying on that base chain for final settlement, security, and data availability. Rather than competing with the L1 for blockspace, an L2 outsources execution, compresses many transactions into a single batch, and posts a succinct record back to L1.

The term is broad. In current usage it most often refers to rollups, but it also covers state channels, plasma, and validiums. What unites these designs is a separation of execution from settlement.

Note

The phrase “Layer-2” predates rollups. Early discussions in 2017–2018 used it primarily to mean payment channels and the Lightning Network. Today the term is dominated by rollup-based designs.

Why scale at Layer-2?

Base layers face an inherent trilemma between scalability, security, and decentralization. Increasing throughput on L1 typically demands heavier nodes, undermining decentralization. L2s sidestep this by performing computation off-chain and using the L1 only as a verifiable bulletin board.

A useful intuition: the L1 is the courtroom; the L2 is the office where work is actually done. Disputes — and only disputes — escalate to the courtroom.

Tip

If you remember one slogan: “execute off-chain, settle on-chain.” Almost every L2 design choice is a different answer to how much of each.

Core Concepts

To read fluently across L2 documentation it helps to anchor on a small set of definitions. The terms below recur constantly in protocol specifications, audit reports, and academic papers.

Execution Environment

An execution environment is the virtual machine in which user transactions are interpreted. Most L2s today are EVM-equivalent or EVM-compatible; some target alternative VMs such as the CairoVM or SVM.

// minimal example: a transaction signed for an L2 EVM
const tx = {
  chainId:   10,                  // L2 chain id
  to:        "0x4200…0006",
  value:     0,
  data:      "0xa9059cbb…",        // ERC-20 transfer
  gasLimit:  100_000,
  type:      2
};

Settlement Layer

Settlement is the act of finalizing a state transition such that it cannot be reverted without violating the security of the L1. For rollups this happens when the state root is accepted by the L1 contracts, either after a fraud-proof window (optimistic) or after a validity proof has been verified (zk).

Warning

“Soft finality” offered by an L2 sequencer is not the same as L1 settlement. Until the batch is posted and finalized on the base layer, transactions can in principle be reordered or censored by a malicious sequencer.

Bridges & Messaging

A bridge is the contract pair that lets messages and tokens cross between L1 and L2. Native bridges are part of the rollup protocol and inherit its security; third-party bridges trade speed for additional trust assumptions.

Cross-chain messages are typically modeled as a tuple (sender, receiver, payload, nonce). The receiving chain validates the message either by reading a Merkle proof against a known state root or by waiting for a relayer attestation.

Rollups

Rollups execute transactions off-chain and post a compressed record of those transactions — together with a new state root — to the base layer. They differ chiefly in how the new state root is justified.

Optimistic Rollups

Optimistic rollups assume that posted state roots are correct unless challenged. A fraud proof window (commonly seven days) gives any observer time to submit a counter-claim. If the challenge succeeds, the offending batch is rolled back; otherwise the state finalizes.

Notable implementations: Arbitrum, Optimism, Base, Mantle.

ZK Rollups

Zero-knowledge rollups attach a succinct cryptographic proof — a validity proof — to every batch. The L1 contract verifies the proof; if it passes, the new state root is final. Withdrawal latency is therefore bounded by proof generation rather than a challenge window.

Notable implementations: zkSync Era, StarkNet, Scroll, Polygon zkEVM, Linea.

Comparison Table

The following table summarizes the structural differences between the two dominant rollup families. Numbers are illustrative; consult primary sources for the latest figures.

Property	Optimistic Rollup	ZK Rollup
Validity mechanism	Fraud proof on dispute	Validity proof every batch
Withdrawal latency	~ 7 days	Minutes – hours
EVM equivalence	Native, mature	Approaching parity
Prover cost	None on happy path	Significant per batch
Trust assumption	1-of-N honest watcher	Cryptographic soundness
Quantum resistance	Inherits L1	Depends on proof system

Data Availability

Data availability (DA) is the property that batch data is published in a form that any observer can retrieve. Without DA, a malicious operator could withhold the state and freeze user funds.

On-chain DA

The strongest model: every batch’s data is published as L1 calldata or blob data (after EIP-4844). Costs are bounded by L1 blob pricing.

DA Committees & Volitions

Some L2s offload DA to an external committee (a DAC) or to a dedicated DA layer such as Celestia or EigenDA. A volition is a hybrid model where users choose, per transaction, whether their data is posted on-chain or off-chain.

Note

An L2 that does not publish data on the base layer is sometimes called a validium rather than a rollup proper.

Proofs

The cryptographic backbone of rollups. Two families dominate practice today.

Fraud Proofs

An interactive or non-interactive procedure by which a challenger demonstrates that an asserted state root is invalid. Modern designs use a bisection game to reduce a disputed batch to a single off-chain instruction, which the L1 then re-executes.

Validity Proofs

Succinct proofs — most commonly SNARKs or STARKs — attesting that a batch was executed correctly under the rules of the L2’s execution environment.

# abstract verify call on L1
function verifyBatch(
    bytes32 oldRoot,
    bytes32 newRoot,
    bytes   batchData,
    bytes   proof
) external returns (bool) {
    return verifier.verify(oldRoot, newRoot, batchData, proof);
}

Ecosystem

The L2 ecosystem is broad and moves quickly. The list below is intentionally non-exhaustive and is maintained by community editors.

Arbitrum — Optimistic rollup, Nitro stack, multi-round fraud proofs.
Optimism — Optimistic rollup, OP Stack, single-round Cannon proofs.
Base — OP-Stack rollup operated by Coinbase.
zkSync Era — ZK rollup, LLVM-based zkEVM, custom account abstraction.
StarkNet — ZK rollup, CairoVM, account abstraction at the protocol level.
Scroll — Bytecode-equivalent zkEVM rollup.
Polygon zkEVM — Type-2 zkEVM with shared validity sequencing roadmap.
Linea — Type-2 zkEVM by ConsenSys.

Glossary

A short, opinionated lexicon for first-time readers. Each entry links into the body of the article above.

Sequencer: The node responsible for ordering and batching L2 transactions before they are posted to L1.
State Root: The Merkle root of the L2’s state at a particular block height; the artifact that gets settled on L1.
Calldata: The transaction input field on Ethereum, historically used by rollups to publish batch data.
Blob: A new data type introduced by EIP-4844 (proto-danksharding) that provides cheap, ephemeral data availability for rollups.
Validium: A rollup-like construction that posts validity proofs on-chain but keeps batch data off-chain.
TVL: Total Value Locked — the aggregate value of assets held in a protocol.
TPS: Transactions Per Second — a coarse-grained throughput metric.
Finality: The point at which a transaction can no longer be reverted under the protocol’s assumptions.

References & Further Reading

1. Buterin, V. An Incomplete Guide to Rollups. 2021.
2. Adler, J. & Quintyne-Collins, M. Building Scalable Decentralized Payment Systems. 2019.
3. Goldwasser, S., Micali, S., & Rackoff, C. The Knowledge Complexity of Interactive Proof Systems. SIAM J. Comput., 1989.
4. Ethereum Foundation. EIP-4844: Shard Blob Transactions.
5. StarkWare. Volition: A New Hybrid Data Availability Model. 2021.