Layer 1 vs Layer 2: How Blockchains Scale

Short answer: A Layer 1 is the base blockchain that provides consensus, final settlement, and security. A Layer 2 executes transactions off the base chain and posts data or proofs back to Layer 1 to inherit that security. For Ethereum, the main Layer 2 design is the rollup, in optimistic and zero-knowledge forms.

If you own crypto or follow market coverage, you will see network names and fee comparisons that use L1 and L2 as if they explained themselves. Marketing has blurred the line between a true Layer 2 and any other chain connected to Ethereum. This guide explains what settles where, whose security you rely on, and where the trade-offs sit, with Ethereum as the focus. See live context on the markets page and definitions in the glossary.

Why scaling is hard

A public blockchain asks many independent computers to agree on the same transaction history. That agreement makes history hard to rewrite and creates a limit: if every node must re-execute every transaction, the network moves only as fast as a typical node can keep up. When demand rises, users compete for limited block space, fees rise, and small transactions become uneconomical on the base chain. Requiring much stronger hardware would reduce who can run a node and centralize the network. Ethereum instead keeps Layer 1 as the settlement and data layer and pushes most execution to Layer 2. For background, see how a blockchain works and proof of work versus proof of stake.

What a Layer 1 is

Base settlement

A Layer 1 is the primary blockchain, such as Bitcoin, Ethereum, or Solana. Here Layer 1 means Ethereum mainnet. Ethereum orders transactions into blocks, executes them in the Ethereum Virtual Machine (EVM), maintains state, and reaches consensus on the final history. Once finalized on Layer 1, a transaction is treated as settled by exchanges, bridges, and Layer 2 contracts. Ethereum measures time in slots of 12 seconds, with 32 slots forming a 6.4-minute epoch. A validator proposes a block in each slot, and finality follows across epochs. See the ETH page for market context.

Security budget

In proof-of-stake Ethereum, validators lock ETH, earn rewards for correct work, and risk penalties including slashing for provable misbehavior. The value at risk behind consensus is the security budget. Rewriting finalized history would require controlling and risking a large share of stake. A rollup does not recreate that budget. It posts commitments, data, and in some designs proofs to Layer 1 contracts. Ethereum validators secure what is posted, and the contract enforces the rules for accepting a new Layer 2 state.

Throughput constraint

Layer 1 throughput is limited by what every full node must download, execute, and store. Each block has a gas limit capping computation and data. Raising it sharply would raise hardware and bandwidth needs and shrink the set of independent verifiers. Ethereum scaling therefore centers on rollups: Layer 1 provides data availability and dispute resolution or proof verification, while most execution happens off Layer 1 and only a compressed record returns.

What a Layer 2 is

Execution off the base chain

A Layer 2 derives security from Layer 1. Ethereum documentation draws the line on that basis. A separate chain with its own security that merely connects by bridge is a different category, even if wallets look similar. In a rollup, users transact on the Layer 2 network, which executes in its own environment, maintains its own state, and periodically settles to Ethereum. An EVM rollup feels familiar in a wallet, but the transaction is sequenced on Layer 2 first and anchored to Layer 1 later.

Batching and posting back

A rollup does not submit each transaction to Ethereum separately. An operator collects many transactions, executes them, compresses the data, and submits a batch to a Layer 1 rollup contract with a commitment to the new state, commonly a state root, plus data sufficient to reconstruct the batch. Ethereum records the data and then either verifies a proof or leaves time for a challenge, depending on the family. One Layer 1 transaction can stand for many Layer 2 transactions, sharing the fixed cost of Ethereum across the batch. That sharing produces the fee saving.

Layer 2 is not a synonym for fast or cheap. The test is whether the chain posts data and commitments to Ethereum and relies on Ethereum contracts to enforce correctness and exits. If data stays only on the new chain under its own validators, it is a sidechain or separate Layer 1.

The two rollup families

Both post data to Layer 1 for independent reconstruction. They differ in how Ethereum is convinced a state is correct.

Optimistic rollups: fraud proofs and the challenge window

Optimistic rollups assume batches are valid and attach no proof of correct execution. Anyone can dispute a proposed state during a challenge period by producing a fraud proof, called a fault proof in Optimism terminology. Watchers re-execute the batch from Layer 1 data and compare results. If they find a mismatch, they challenge before the window closes. Modern systems narrow the dispute interactively to a single step that a Layer 1 contract checks. A successful challenge rejects the invalid claim and can penalize the proposer; with no successful challenge, the state is final for withdrawals and other Layer 1 actions. For Arbitrum One and OP Mainnet, official documentation states a 7-day challenge period on mainnet for canonical withdrawals. That is a parameter of those deployments, not every optimistic system. Security rests on at least one honest watcher with data and Layer 1 access.

Zero-knowledge rollups: validity proofs

ZK rollups, or validity rollups, prove correctness upfront. The operator generates a cryptographic validity proof that a batch followed the rollup rules and submits it to a verifier contract on Layer 1. Only if the proof verifies does Ethereum accept the new state root. Proofs are succinct, far cheaper to verify than re-execution, using SNARK or STARK constructions with different setup and size trade-offs. Because validity is proven before acceptance, there is no 7-day challenge period. A withdrawal finalizes once its batch is proven and verified on Layer 1 and the user provides an inclusion proof. Proving and inclusion still take time, so exits are not instant. Data is still published to Ethereum as calldata or blobs so users can reconstruct state and exit if the operator stops.

As an illustrative example, take a batch of transfers. An optimistic system posts data and the claimed end state and waits for objections. A ZK system must produce a proof for the batch and have Ethereum verify it before accepting the end state. The difference is clearest at withdrawal and in when Layer 1 treats a state as final.

Sidechains are not Layer 2s

A sidechain is an independent blockchain parallel to Ethereum, connected by a bridge, with its own consensus, block parameters, validators, and history. It does not post rollup data and state changes to Ethereum for enforcement and does not inherit Ethereum security. EVM compatibility means Solidity contracts port easily; it does not transfer security. If sidechain validators collude, Ethereum cannot reject the state because it never agreed to enforce it. A rollup exit, by contrast, runs through Layer 1 contracts governed by posted data and proofs. Both models face contract, bridge, and operational risk. The difference is the trust base: a rollup points to Layer 1 contracts and proof rules, while a sidechain also requires trust in a separate consensus system.

Named examples

Classifications follow official project documentation and Ethereum scaling documentation.

Arbitrum One is a general-purpose optimistic rollup by Offchain Labs, governed by the Arbitrum DAO (Ethereum Layer 2 overview; Arbitrum docs). It executes on Arbitrum, posts batch data to Ethereum, and posts assertions subject to a documented 7-day dispute window. Batch data and the assertion settle to Ethereum, confirmable after the challenge period.

OP Mainnet is the OP Stack main network and an optimistic rollup (Optimism docs). It executes on its own network and publishes data to Ethereum. State commitments finalize after the fault-proof window, currently 7 days. Batch data and output roots settle to Ethereum.

Base is an optimistic rollup built with the OP Stack, developed by Coinbase (Ethereum Layer 2 overview lists Base as such; docs at docs.base.org). Execution occurs on Base, batches publish to Ethereum, and canonical withdrawals follow the OP Stack fault-proof period. Batch data and accepted state outputs settle to Ethereum.

zkSync Era is a ZK rollup built with the ZK Stack (ZKsync docs). Chains process off-chain, generate validity proofs, and submit them to Ethereum contracts that verify and update state, with data published for reconstruction. The validity proof, its state commitment, and published data settle to Ethereum, with no optimistic challenge period.

Starknet is a permissionless Layer 2 validity rollup using STARK proofs (Starknet docs). Transactions are bundled off-chain, a STARK proof is verified by an Ethereum contract, and the state update is accepted. Starknet uses Cairo and native account abstraction rather than direct EVM equivalence, a developer distinction that does not alter its rollup status. The proof, state update, and availability data settle to Ethereum.

Polygon requires care. Polygon PoS is a sidechain: Ethereum sidechain documentation lists it as such. It runs its own proof-of-stake validators and bridge and does not post rollup batches for Ethereum to enforce. Polygon zkEVM is a ZK rollup: Polygon documentation describes validity proofs verified on Ethereum and posting data and proofs on Ethereum for reconstruction, with sequencer and aggregator roles. Its batches and verified proofs settle to Ethereum. The two Polygon networks have different security models.

The withdrawal row describes the canonical bridge using the network's own Layer 1 contracts. Third-party bridges may pay sooner from their own liquidity; they add contract and counterparty terms and do not change canonical timing.

Data availability in plain English

Data availability asks whether the inputs behind a state update are published so others can check the work. Without the data, watchers cannot detect optimistic fraud, users cannot prove ownership to withdraw, and a replacement node cannot rebuild state if the operator stops. The operator would be trusted to reveal who owns what. Rollups post data to Ethereum, compressed and in differing formats, but sufficient for independent reconstruction. Borrowing that availability is part of borrowing Ethereum security.

Rollups historically posted data as calldata, which is available in Ethereum history but competes with execution data and persists permanently, at higher cost. EIP-4844, live in the Dencun upgrade in March 2024 as proto-danksharding, added blob-carrying transactions. A blob is a large data package separate from EVM execution. The EVM cannot read its contents; a commitment is referenced on-chain and consensus clients serve the data for a limited window that Ethereum documentation sets at 4,096 epochs, about 18 days. That window allows download, verification, challenges, and archival by rollup infrastructure without permanent storage on every Ethereum node. Blobs have a separate fee market priced for temporary availability. They do not execute contracts and do not remove the rollup's duty to serve history after the window.

Sequencers and centralization

A sequencer orders Layer 2 transactions, forms blocks or batches, and submits data and commitments to Layer 1. Most current rollups use a single sequencer run by the project team, a fact stated plainly in project documentation alongside decentralization roadmaps. A single sequencer is simpler, gives fast preconfirmations, and eases upgrades and incident response. The trade-off is concentration: the operator can delay or exclude transactions, exercise ordering discretion within protocol limits, concentrate ordering-related value often called MEV, and halt progress if it goes offline. Posted data and Layer 1 proof enforcement prevent Ethereum from accepting a false state as final in a sound implementation, and many designs add a Layer 1 forced-inclusion or exit path, with differing speed and usability. Those safeguards protect final integrity and eventual exit more than ordering fairness or uptime. Ask who sequences today, what happens if it stops, whether forced inclusion exists, and how far sequencing decentralization has progressed.

Fees: why L2 is cheaper, what L1 still charges

Layer 2 fees fall because execution moves off Layer 1, many transactions share one Layer 1 submission, data is compressed, and blobs price data posting separately. The user fee is not independent of Ethereum. It typically covers Layer 2 execution and sequencing, posting batch data as calldata or blobs, Layer 1 gas for commitments and, for ZK systems, proof verification, and a buffer for price movement before settlement. Fees can therefore rise when Ethereum or blob demand is busy even if the rollup is quiet. Quotes vary by wallet in how they estimate and present these parts.

Risk note on fees: quotes are estimates. Congestion, batch timing, and proof costs can change the amount consumed at settlement. Confirm network, amount, and any token approval before signing, and test small amounts on unfamiliar routes. This explains fee construction and is not a judgment on buying any network or asset.

Bridging and its risks

A canonical bridge uses contracts on Ethereum and the Layer 2 plus a messaging system. A deposit locks or escrows the asset on Layer 1 and credits a representation on Layer 2. A withdrawal reverses this after the rollup settlement condition is met: the challenge period for optimistic rollups, or proof verification for ZK rollups. The Layer 1 contract requires the withdrawal to be in a final state with a proof of inclusion, not merely a Layer 2 receipt.

Bridge contracts pool value and enforce accounting across networks, making them high-value targets. Bugs in logic, upgrade controls, key management, or third-party validator and relayer assumptions can permit unauthorized minting or release. Industry security work treats bridges as a recurring risk category. This guide states the risk generically; official project post-mortems are the source for any specific incident. Canonical rollup bridges draw security from Ethereum settlement and the proof system but remain upgradeable contracts in many deployments. A fast third-party bridge pays from its own liquidity while awaiting canonical settlement, making the service your immediate counterparty. Use bridges linked from official documentation, verify the destination network, test with a small transfer, retain hashes from both chains, and revoke unused approvals.

Risk note on bridging: transfers are not reversible payments. A wrong network, address format, or unofficial site can cause irreversible loss. Canonical optimistic withdrawals take the full challenge wait, so do not bridge funds needed at once on Layer 1. A fast bridge does not remove settlement risk; it relocates and reprices it.

How to read a network's claims

Where is data posted? Ethereum calldata or blobs sufficient for reconstruction supports a rollup claim. Data held only on the new chain points elsewhere. How does Ethereum judge correctness? A challenge period with fraud proofs signals an optimistic rollup; a Layer 1-verified validity proof signals a ZK rollup; no Ethereum judgment means a separate system decides. Who sequences and who can upgrade? A single sequencer is common and is a centralization trade-off; upgrade keys and timelocks show how quickly rules can change. What is the canonical exit and its duration? That describes leaving if the operator stops. Deposit speed does not answer it. These questions identify the layer and trust base; they do not judge an application's quality or an asset's merits. Use the glossary for terms and keep technical checks separate from the markets page.

Frequently Asked Questions

Is every chain connected to Ethereum a Layer 2?

No. A Layer 2 posts data and commitments to Layer 1 and lets Ethereum contracts enforce correctness by fraud proofs or validity proofs. A sidechain uses its own consensus and a bridge without rollup enforcement on Ethereum. Polygon PoS is a sidechain and Polygon zkEVM is a ZK rollup.

Why do Arbitrum One and OP Mainnet withdrawals take about 7 days?

Their canonical bridges wait through the documented fault-proof challenge period. Anyone can challenge the state containing the withdrawal during those 7 days. After finalization, the withdrawal completes on Layer 1. Third parties may advance funds sooner on their own terms.

Do ZK rollups have the same wait?

No. zkSync Era, Starknet, and Polygon zkEVM verify a validity proof on Ethereum before accepting state, so there is no 7-day dispute window. Users wait for proving, submission, and Layer 1 inclusion, which varies.

What does a sequencer do?

It orders transactions, forms batches, and submits data and commitments to Layer 1. Most major rollups use one team-run sequencer today, giving fast preconfirmations but concentrated ordering and a liveness risk. Proof systems and Layer 1 data prevent false final states, and some designs allow forced inclusion via Layer 1.

What are blobs?

Blob data from EIP-4844, live since Dencun in March 2024, lets rollups post batch data in a separate temporary market. The EVM cannot read blobs, and Ethereum serves the data for about 18 days (4,096 epochs in Ethereum documentation) for verification and reconstruction before pruning. Rollups serve older history themselves.

Is a sidechain less secure than a rollup?

It uses different security: its own validators rather than Ethereum stake and Layer 1 enforcement, usually a far smaller set. Evaluate it as trust in a separate chain, not inherited Ethereum security.

Why do Layer 2 fees rise when Ethereum is busy?

Each batch buys Layer 1 data space and gas for commitments and, for ZK rollups, proof verification. Expensive Layer 1 or blob markets raise that shared input cost, even though Layer 2 execution remains cheaper than direct Layer 1 use.

Sources

Ethereum, Scaling, on Layer 2 security from mainnet and sidechains as a separate category. https://ethereum.org/en/developers/docs/scaling/

Ethereum, Intro to Ethereum Layer 2, listing Base as an OP Stack optimistic rollup and Arbitrum One as a general-purpose optimistic rollup. https://ethereum.org/en/layer-2

Ethereum, Optimistic Rollups, on offchain execution, calldata and blobs, fraud proofs, challenge period, and settlement. https://ethereum.org/en/developers/docs/scaling/optimistic-rollups/

Ethereum, Zero-knowledge Rollups, on validity proofs verified on Ethereum, data availability, and sequencer roles. https://ethereum.org/en/developers/docs/scaling/zk-rollups/

Ethereum, Sidechains, on independent consensus, no inherited Ethereum security, with Polygon PoS as an example. https://ethereum.org/en/developers/docs/scaling/sidechains/

Ethereum, Danksharding and EIP-4844, on blobs, EVM inaccessibility, 4,096 epochs (about 18 days), and Dencun in March 2024. https://ethereum.org/en/roadmap/danksharding/

Optimism, OP Stack documentation, on rollups publishing data to Ethereum and fault proofs with a 7-day challenge window. https://docs.optimism.io/stack/getting-started

Arbitrum documentation, on Arbitrum One as an optimistic rollup and the seven-day dispute window. https://docs.arbitrum.io/

Base documentation. OP Stack optimistic classification is in the Ethereum Layer 2 overview. https://docs.base.org/

ZKsync, protocol overview, on ZK Layer 2 rollups, validity proofs verified on Ethereum, and data availability. https://docs.zksync.io/zksync-protocol/rollup

Starknet documentation, on Starknet as a permissionless Layer 2 validity rollup using STARK proofs settled on Ethereum. https://docs.starknet.io/

Polygon, zkEVM documentation, on validity proofs verified on Ethereum and posting data and proofs on Ethereum. https://docs.polygon.technology/

Ethereum, Bridges, on bridge contracts and cross-chain asset movement risks. https://ethereum.org/en/developers/docs/bridges/