Layer One, Layer Two and Bridges

Networks with lower fees can look similar in a wallet while relying on different security arrangements. Layer one, layer two, sidechain and bridge are not interchangeable words. We will map the route an asset takes and identify who or what must continue working for the asset to be usable and withdrawable.

Education only. Crypto assets can lose substantial value or become worthless. No lesson requires buying an asset, depositing money or sharing real passwords, private keys or recovery words.

Ask why Ethereum needs to scale

Think about a popular bus route at rush hour. The bus has a fixed number of seats. When more people want to ride than there are seats, the operator could raise the fare until enough people give up, and the ones who pay most get on first.

Ethereum's blocks work like that bus. In the gas and token lessons in Level 4 you saw that each block has a maximum size, and that the base fee rises when blocks are full. That space inside blocks is called blockspace, and there is only so much of it. When many people want it at once, fees climb, and small transfers become expensive compared with the amounts being moved.

Ethereum could make blocks much bigger, but bigger blocks need more powerful computers to check them. Fewer people could run a node, and the network would drift towards those who can afford the hardware. So instead of squeezing everyone onto the main bus, Ethereum adds more vehicles that report back to it, called layer 2s.

The bus analogy has a limit. A bus company can buy a bigger bus overnight. Ethereum's limits are deliberate trade-offs that protect decentralisation, which is why extra capacity is built on top of Ethereum.

Separate layer 1 from layer 2

You have met one layer 2 already: the Lightning Network on Bitcoin, from the transaction and fee lessons in Level 1. On Ethereum, most layer 2s are rollups. In the Ethereum and contract lessons in Level 4 you also met the Dencun upgrade of March 2024, whose "blobs" gave rollups a cheaper place to store their data on Ethereum and cut their fees.

The phrase "relies on that layer 1 for security" is the important part. It is what separates a true layer 2 from a network that only looks like Ethereum. To see how a rollup earns that link, look at what it actually does with your transactions.

Know why a sidechain is different

Imagine a neighbouring town linked to your city by a bridge. It has its own council, its own police and its own rules. You can cross over and shop there cheaply, but if its council makes a bad decision, your city's courts can't overturn it.

A sidechain is that neighbouring town. ethereum.org describes it as a separate blockchain that runs independently of Ethereum and connects to it through a two-way bridge. It uses its own way of agreeing on blocks, and, unlike a rollup, it does not post its transaction data back to Ethereum. Polygon PoS and Gnosis Chain are examples that ethereum.org lists, named here only to illustrate the category.

Many sidechains run the EVM, so addresses and apps look exactly like Ethereum's. That is convenient but confusing: the same 0x address can exist on several networks, so check which network you are sending on, as in the transfer checking lesson in Level 2. And because a sidechain secures itself, ethereum.org warns that a group of its validators acting together could commit fraud.

You may have noticed "upgrade keys" in that table. Many rollups are still young, and their builders can change the rules. That is what L2BEAT measures.

A layer-one network supplies its own base execution or settlement system under its consensus rules. A separate chain is not automatically Ethereum layer two because it uses familiar addresses or software. A lower displayed fee does not establish equivalent security. The user's route may also depend on an exchange that supports only part of the system. Names help orient you, but mechanisms explain what happens under stress.

Optimistic rollups use a process that can challenge invalid results under their rules. Validity-proof rollups use proofs intended to establish the correctness of specified state transitions. Both descriptions cover families of implementations, not identical products. Proofs must be available and checked under the actual system, and other dependencies can remain.

A sequencer commonly orders transactions and may be concentrated in an operator or limited set. Data availability concerns whether the information needed to verify or reconstruct the state can be obtained. Settlement concerns how results are accepted by the relevant base system. Ask what happens when the sequencer is unavailable, whether alternative submission exists and which administrative controls can change the system. Security should be described component by component.

Picture an office where a hundred staff have expense claims. Instead of head office checking every receipt, a team leader collects a week of claims and sends one summary with copies of the receipts. Head office files the summary, and anyone can recheck it from the copies.

Compare optimistic and zero knowledge rollups

Return to the expense claims sent to head office. One way to check the summary is to publish it and allow a defined period for a challenge. An optimistic rollup uses a related idea: a state claim can be challenged through the actual dispute system. The challenge period and who can use that system depend on the project and its current contracts. Some common withdrawal routes involve roughly a week, but that is not a universal rule for every network or transfer.

A second approach supplies a mathematical validity proof that the receiving verifier checks. A validity rollup does not need the same fraud-challenge waiting period, although proof generation, submission, settlement and the withdrawal interface can still take time. A name containing zero knowledge does not, by itself, promise private transactions. The proof may be used to establish correct computation while transaction data remains public.

The office analogy has a limit. A human certificate relies on the auditor's judgement. A cryptographic proof is checked according to a verification system, whose design and implementation still need scrutiny. Both types of system also have questions about data availability, administrators, upgrades, sequencer outages and emergency exits. A sound proof mechanism is one part of the complete route.

Read a layer 2 s maturity with L2BEAT

L2BEAT's stages framework helps describe how much a rollup still depends on permissioned control. Broadly, Stage 0 has substantial operator control, Stage 1 meets defined limits on those powers, and Stage 2 aims for stronger control through the system's rules.

The precise criteria evolve. Read the framework version, the project's current assessment, upgrade powers, proof system, data availability and exit conditions. Do not memorise a number of days from an old table and assume it applies to every project or every later framework revision.

Deposits withdrawal waits and representations

A deposit route moves or represents value according to the system's bridge or messaging rules. A withdrawal can require waiting, proof submission or another sequence. Fast third-party routes may provide liquidity while introducing additional counterparties and fees. Do not assume the quickest interface uses the same process as the canonical withdrawal mechanism.

Identify the exact token received. It may be an issuer-supported token, a native asset or a bridged representation with different backing. Fees may be needed on both networks, and sending out of the destination can require its native fee asset. Check supported networks and instructions at every endpoint. A successful deposit does not prove that the future exit will be cheap, immediate or available through the same service.

Bridges and the full dependency path

Think about a cloakroom at a concert. You hand over your coat, and the attendant gives you a numbered ticket. Inside the venue, the ticket stands for your coat. At the end of the night, you hand back the ticket and get your coat.

A lock-and-mint bridge works the same way. You send ETH to a bridge contract on Ethereum, which locks it in a vault. The bridge then creates, or mints, the same amount of a matching token on the other network. When you want to return, you send that token back; the bridge burns it and unlocks your ETH on Ethereum. ethereum.org also describes burn-and-mint designs and liquidity networks, where providers hold funds on both networks and swap with you for a fee instead of locking and minting.

The cloakroom analogy breaks down in an important way. Thieves in a cloakroom take a few coats. A bridge vault holds everyone's locked funds in one place, and the tokens on the other network are only worth something while it stays full. If the vault is emptied, or someone mints tokens without locking anything, those tokens can lose their backing overnight.

The minted token on the other side has a name: it is a wrapped token.

A bridge's past transaction volume is not a complete security assessment. You need the current design and version, not merely a label saying cross-chain.

Open diagram at original size ↗

Read diagram as text

Outbound: the user locks 1 ETH in a bridge contract. A message or proof authorises minting 1 bridged ETH on the other network.

Return: burn the bridged unit and satisfy the bridge’s requirements to unlock the original ETH.

The pooled locked assets are marked as a target for stolen validator keys, a signature-check bug or a bad upgrade. Other bridge designs and withdrawal paths differ.

Costs and paper practice without a real bridge

This lesson requires a route diagram and a checklist, not a real bridge transaction. Use a supplied fictional source and destination. State the asset identity, fee assets, confirmation or withdrawal assumptions, administrator powers and unresolved questions. If any endpoint is unsupported or uncertain, the correct outcome is to pause rather than fill the gap with an assumption.

If you later examine a real route, use current official instructions and repeat the Level 2 transfer checks. Do not experiment with funds merely to establish whether a bridge is legitimate. A small successful transfer can test one current route without certifying contract security or long-term redemption. Understanding the dependency path is the learning objective; completing an irreversible transfer is not.

Try the following questions aloud or on paper before opening the worked answers. Compare your reasoning as well as your final answer.

References and further reading