A Complete Guide to Layer 2 Scaling Solutions

Layer 2 refers to scaling designs that execute transactions outside the base chain and then hand data or proofs back to that chain for verification and settlement. This spreads computation and data costs across many transactions, but networks differ in how much of mainnet's security they actually inherit.

Deciding whether a network really qualifies as Layer 2 cannot rest on whether it is cheaper than mainnet, nor on how the project brands itself. Keep asking: who verifies the state, where transaction data is stored, whether users can still submit transactions or exit through mainnet when the sequencer fails, and who controls contract upgrades.

Why Can Layer 2 Lower Transaction Costs?

Every transaction on Ethereum mainnet occupies scarce execution and data space. Rollups execute large volumes of transactions on L2, compress them into batches, and submit those batches to Ethereum, so many transactions share the cost of L1 data publication and verification.

An L2 transaction usually passes through the following stages:

1. The user picks the target network in a wallet and signs; the transaction first goes to an L2 sequencer or node.
2. The sequencer decides transaction ordering, the execution environment computes balance and contract state changes, and a fast confirmation is returned.
3. A batching service compresses many transactions and publishes the data needed to reconstruct state to Ethereum, commonly carried in Blobs.
4. Optimistic Rollups wait for incorrect states to be challenged, while ZK-Rollups generate validity proofs for Ethereum contracts to verify.
5. Once the state settles under protocol rules, users can withdraw assets to L1 through that network's bridging process.

This also explains why "the wallet shows success," "the L2 block is confirmed," "the batch has been posted to L1," and "the state has finally settled" are not the same moment. Applications can accept the faster L2 confirmation, but high-value settlement pays much closer attention to batch and proof status.

What Is the Difference Between Optimistic Rollups and ZK-Rollups?

Both move execution off-chain and rely on Ethereum for data availability and settlement. The main difference lies in how Ethereum confirms that the L2 state is correct.

Optimistic Rollups do not skip verification entirely; they place the opportunity to catch errors inside the challenge period. ZK-Rollups are not risk-free either: a validity proof only shows that the proven state transition follows the circuit rules, and it cannot audit application contracts, governance permissions, or bridged assets on the user's behalf.

For details on each route, see Optimistic Rollups: Arbitrum and Optimism and ZK-Rollups: ZKsync, Starknet, and Scroll.

How Do Rollups, Validiums, Sidechains, and State Channels Differ?

Scaling designs come with many names, and the easiest things to confuse are "where computation happens" and "where the data needed to reconstruct state is stored." Proving that a state is correct does not guarantee that the data is available.

Although Polygon PoS submits checkpoints to Ethereum, current official documentation still describes it as an EVM-compatible sidechain. A checkpoint is not the same as Ethereum verifying every one of its state transitions batch by batch. For more on this technical evolution, read What Is a Sidechain: The Evolution of Polygon's Technical Roadmap.

Layer 2 in the Bitcoin ecosystem is defined somewhat differently. The Lightning Network uses payment channels, while Stacks has its own execution, ledger, and BTC anchoring mechanism, so Ethereum's Rollup taxonomy does not transfer directly. For the specific differences, see Bitcoin Layer 2: Lightning Network and Stacks.

What Makes Up L2 Gas Fees?

An L2 fee is not a fixed discount. What a Rollup user pays can usually be broken into:

Total network fee = L2 execution fee + L1 data publication fee + protocol surcharge

The L2 execution fee depends on local gas prices and how much computation a contract performs; the L1 data fee depends on the compressed size of the transaction, the price of Ethereum Blobs or calldata, and network settings. A simple transfer, a token approval, and a complex DeFi transaction can cost very different amounts even on the same network.

The full cost of use should also include cross-chain bridge fees, swap slippage, and the fees required to exit to the target chain. A single screenshot of "current average gas" cannot represent the next specific transaction. For a practical method of choosing, continue with How to Choose an L2 Network.

Where Are the Main Trust Boundaries in Layer 2?

"Settles to Ethereum" does not mean every part of the stack is already decentralized. When reviewing an L2, separate at least these five layers:

Bridged assets introduce separate risks of their own. The same stablecoin on an L2 may be the issuer's native version, a mapped version minted after the official bridge locks funds, or a third-party bridge wrapper. An identical ticker does not mean an identical redemption path.

Are Layer 2 and Layer 1 Complementary or Competitive?

From the standpoint of protocol division of labor, they are mainly complementary. L2 supplies cheaper execution space, while L1 supplies settlement, data availability, and dispute resolution. L2 activity also consumes L1 data space and requires ETH to pay submission costs on Ethereum.

From the user and application standpoint, they also compete for transactions, liquidity, and developer attention. Multiple L2s can turn into islands, leaving users to absorb the cost of bridging, acquiring gas assets, and telling different token versions apart. For a fuller view of where responsibility sits, see The Relationship Between Layer 2 and Layer 1.

Base and Linea illustrate two concrete routes. Base uses the OP Stack and a fault proof system, while Linea uses a zkEVM with validity proofs. Read Base's L2 Strategy and The Linea zkEVM Guide respectively.

What Should You Look At First When Evaluating a Layer 2?

Do not start from token price moves or advertised TPS. Checking in the following order makes it far easier to find the issues that actually affect how you use assets:

1. Confirm the network type. Distinguish Rollups, Validiums, sidechains, and state channels, and check whether official documentation agrees with independent risk research.
2. Locate the data and the proofs. Confirm where data is published, whether the proof system is actually live, and which stages the state passes through before settling on L1.
3. Review the permissions. Record the sequencer, core contract upgraders, security council, and emergency pause holders, and do not treat a roadmap as the current state.
4. Walk the exit path end to end. Verify the official bridge, the challenge or proof wait, L1 gas, supported token versions, and any backup exit mechanism.
5. Compare the experience last. Only then compare application coverage, wallet support, liquidity, real gas costs, and service stability.

FAQ

Is ETH on a Layer 2 the same on-chain balance as ETH on Ethereum mainnet?

No, they are balances on different chains. Once assets bridge into an L2, the corresponding balance appears on the target network; returning to mainnet follows the bridge's messaging and exit rules. Always check the network when depositing.

Does a failed L2 transaction still consume gas?

It can. Once a transaction has been executed, it consumes ordering and computation resources even if the contract reverts. Transactions rejected in the wallet and never broadcast usually produce no on-chain gas cost.

Does depositing and withdrawing L2 assets through a centralized exchange avoid bridge risk?

A platform may handle the fund movement internally so that users never operate the official bridge themselves, but the risk does not disappear. It is replaced by conditions such as platform support, suspended deposits or withdrawals, and matching the correct asset version.

Can L2 TPS figures be compared side by side?

No. Projects may count transactions, user operations, batches, and test environments differently. Throughput is also shaped by block limits, data publication, and real demand, so it should be read alongside verifiable on-chain activity and security assumptions.