QTube LearnEthereum and scaling Advanced
Layer 2
“Layer 2” is used loosely. On Ethereum, a careful meaning is an off-chain execution system that **derives security from Ethereum** through on-chain data or commitments and a proof or dispute system that lets Ethereum enforce the published rules. **Optimistic rollups** accept state claims provisionally and allow challenges with fault (often called fraud) proofs. **ZK rollups** require validity proofs for state updates. **Sidechains** are separate chains with their own consensus; a bridge does not make them L2s. Sequencers, upgrade keys and data-availability choices limit the slogan “inherits L1 security.” Other ecosystems use “L2” for different constructions. This article uses Ethereum rollups as the main case study and labels that scope.
In brief
“Layer 2” is used loosely. On Ethereum, a careful meaning is an off-chain execution system that derives security from Ethereum through on-chain data or commitments and a proof or dispute system that lets Ethereum enforce the published rules. Optimistic rollups accept state claims provisionally and allow challenges with fault (often called fraud) proofs. ZK rollups require validity proofs for state updates. Sidechains are separate chains with their own consensus; a bridge does not make them L2s. Sequencers, upgrade keys and data-availability choices limit the slogan “inherits L1 security.” Other ecosystems use “L2” for different constructions. This article uses Ethereum rollups as the main case study and labels that scope.
Why people move activity off the base layer
ethereum.org’s scaling page states the problem: as more people use Ethereum, capacity limits raise gas prices and slow inclusion. Making the base chain hold more data and do more computation tends to raise the cost of running a node, which can centralize validation. So the community’s main path has been to keep Ethereum as a settlement and data layer and to execute elsewhere.
Vitalik Buterin’s January 2021 essay An Incomplete Guide to Rollups draws the same fork: scale the base chain (harder to verify, more centralized) or change how the chain is used so that most activity happens in a layer-2 protocol whose on-chain contract checks deposits, withdrawals and proofs.
That is an Ethereum design conversation. Bitcoin’s Lightning Network is a different layer-2 idea (payment channels). Solana’s throughput strategy is mostly a faster L1, not an Ethereum-style rollup stack. Do not import Ethereum’s L2 vocabulary onto those systems without checking.
Settlement and data availability
Two jobs get mixed under “security.”
Settlement is where disputes are resolved and where withdrawals become final in the base chain’s sense of final. For an Ethereum rollup, that is an Ethereum contract.
Data availability (DA) is whether the data needed to reconstruct the rollup’s state is actually published where honest parties can get it. Buterin’s essay is blunt: putting data “on IPFS” does not work for this purpose, because IPFS does not give consensus that the data is available. The data has to be on a chain (or another system with a DA guarantee).
In the textbook rollup model, data on Ethereum lets independent parties reconstruct state and use the proof or exit mechanisms. Working software and usable contract escape paths are still required. If data is held only by the operator, users may be unable to prove what they own. That distinction is why validiums (validity proofs, data off Ethereum) and plasma (fraud proofs, data elsewhere) are not the same as rollups, even when marketing calls everything “L2.”
ethereum.org’s consumer L2 hub now uses “stores its data on the Ethereum main network” as a practical test for whether a network is a rollup-style extension. That is a useful filter. It is not a complete security audit.
Rollups
A rollup publishes compressed transaction data and state commitments to L1, though projects may submit them through separate transactions and actors. An L1 contract uses the rollup’s dispute or validity-proof rules to decide which state commitments can support withdrawals and other cross-layer messages.
Computation and storage happen off L1. Compressed transaction data is published through L1's data-availability mechanism. Buterin calls this a hybrid: not fully off-chain (channels, plasma) and not fully on-chain. Compression is why the scaling factor can be large — his 2021 table compared ~112 bytes for an L1 ETH transfer with ~12 bytes in a rollup.
There are two proof families.
Optimistic rollups
ethereum.org’s optimistic-rollup page describes state claims as provisionally accepted. There is a challenge period during which an eligible party can dispute an invalid claim with a fault/fraud proof. A successful challenge rejects the bad state claim; exact consequences and who may challenge depend on the implementation. If a claim survives the window, contracts can rely on it for actions such as withdrawals.
Withdrawals to L1 typically wait out that window — often described as about seven days in both Buterin’s 2021 essay and ethereum.org. Liquidity providers can buy a pending withdrawal and pay the user on L1 sooner; that is a credit relationship, not faster protocol finality.
Security, in the textbook model, depends on at least one honest party watching, having the required data, and being able to get a challenge included on L1. Live systems may restrict who can participate or retain an emergency override, so the implementation must be checked rather than inferred from the word “optimistic.”
Zero-knowledge (validity) rollups
A validity rollup’s L1 state update requires a validity proof (a SNARK or similar) showing that the proposed new state follows the rollup’s rules. The L1 verifier checks the proof. There is no optimistic challenge window, but a withdrawal is not final until the relevant proof and exit transactions have been accepted and finalized on L1.
The tradeoff, in Buterin’s 2021 comparison, is heavier proving cost and, at that date, harder general-purpose EVM equivalence. The technology has moved quickly since; this article does not claim a 2021 snapshot is still the engineering frontier. The conceptual split — challenge after the fact versus proof up front — remains.
Sequencers
Someone has to order transactions and publish batches. That someone is usually a sequencer.
Buterin lists a zoo of sequencer policies: anyone may publish (wasteful races), a single sequencer (live as long as that actor is live), auctions, proof-of-stake selection, delegated voting. ethereum.org describes the common live pattern: a sequencer has priority access and is the only party that normally submits to the on-chain contract; users can often fall back to an L1 inbox if the sequencer censors them.
A centralized sequencer can reorder (MEV), delay, censor, or go offline. A well-designed rollup provides an L1 path for transaction inclusion or exit, but its delay and capabilities are implementation-specific. “Still” depends on that escape hatch working and on the required data being available. A sequencer is a centralized component inside a system that may otherwise derive security from L1.
Bridges, deposits and withdrawals
Entering a rollup usually means depositing assets into an L1 bridge contract; the L2 mints a representation. Leaving burns on L2 and unlocks on L1 after the rollup’s finality rule (challenge window, or proof verification).
Bridges are their own risk. The EEA DeFi guidelines treat bridge contracts as honeypots. A rollup’s canonical bridge is part of the rollup’s security model. A third-party bridge to the same L2 is a different trust assumption. Native USDC on an L2 is not the same as USDC locked in an unofficial wrapper.
Optimistic withdrawals through a canonical bridge usually wait through a challenge window. Validity-proof systems can avoid that window, although proof production and bridge mechanics still take time. Neither is instant in the L1-finality sense until the L1 transaction that completes the exit is itself finalized.
Security inheritance is not absolute
Marketing line: “L2 inherits Ethereum’s security.”
More accurate:
- A rollup that posts its data to Ethereum lets Ethereum enforce the published rules of that rollup — if those rules are correctly implemented, if fraud/validity proofs work, and if users can transact on L1 when they need to.
- An upgrade key can change those rules. Many live rollups have admin or security-council upgrade paths. That is a governance assumption, not an L1 assumption.
- L2Beat’s Stages Framework measures rollup maturity through decentralization and trust minimization: Stage 0 roughly means control remains with a few entities, while Stage 2 is much more constrained by code. L2Beat explicitly says the stage is not a complete security or bug-risk rating.
- A sidechain has its own consensus. Ethereum does not check its blocks, and a two-way bridge does not transfer Ethereum’s consensus guarantees to it.
- A validium has validity proofs but not Ethereum DA. Users depend on whoever holds the data.
- If the honest watcher set is empty, optimistic security degrades.
ethereum.org’s scaling page already distinguishes rollups (security from L1) from sidechains, plasma and validium (different trust). Its consumer hub is more salesy. This article follows the scaling page.
The word “Layer 2” elsewhere
- Bitcoin: Lightning and other channel systems are often called L2. They do not post per-transaction calldata to Bitcoin in the rollup sense. They are a different paradigm (Buterin’s essay treats channels as a separate family).
- Marketing: any faster chain that bridges to Ethereum may call itself L2. Check DA, proofs and upgrade keys.
- L3s: Buterin has a later essay on when extra layers make sense. Out of scope here.
There is no official Ethereum L2, just as there is no official Ethereum client. ethereum.org says so.
Sources & further reading
-
An Incomplete Guide to Rollups
Secondary · Analysis
Conceptual source for channels, plasma, rollups, optimistic versus validity proofs, sequencers, data availability, and compression; dated engineering comparisons are treated as historical.
-
Scaling
Primary · Documentation
Ethereum’s taxonomy of rollups, sidechains, plasma, validiums, channels, and their different security relationships to L1.
-
Optimistic Rollups
Primary · Documentation
Challenge periods, fault proofs, sequencers, L1 submission paths, data publication, and the honest-party assumption.
-
Zero-knowledge rollups
Primary · Documentation
Validity-proof verification, L1 settlement, on-chain data availability, operator censorship, and exit mechanics.
-
Intro to Ethereum Layer 2: benefits and uses
Primary · Documentation
Consumer framing, data-on-Ethereum filter, design-maturity warning, and statement that there is no official Ethereum L2; promotional fee figures are not used.
-
Rollup protocol overview
Primary · Documentation
Concrete OP Stack example of blob data publication, a single sequencer, L1 transaction submission, state commitments, fault challenges, and a seven-day withdrawal window.
-
The Stages Framework
Secondary · Analysis
Directly retrieved framework for rollup maturity, decentralization, and trust minimization; explicitly not a complete security or bug-risk score.
-
EEA DeFi Risk Assessment Guidelines
Primary · Documentation
Independent industry specification supporting bridge, privileged-operator, and upgrade risks.