What is an EVM L2?

L2 in one paragraph

Layer 2 is a network that derives security from Ethereum (Layer 1) while executing transactions off the L1 mainnet. Users transact on the L2, paying L2 fees and getting L2 throughput. Periodically, the L2 publishes a compressed record of its activity back to Ethereum, which provides settlement and a backstop against fraud. An EVM L2 is one that runs the same Ethereum Virtual Machine - the same bytecode, the same opcodes, the same Solidity contracts - so existing tools work mostly unchanged.

If L1 is the courthouse, L2 is the shop floor. The shop floor handles most of the day's work; the courthouse is where disputes get settled.

Why L2s exist

Ethereum mainnet has a hard limit on how many transactions it can process per block. Demand routinely outstrips that limit, which pushes gas prices up and squeezes out lower-value activity. L2s exist to give that activity a cheaper venue while keeping Ethereum's settlement guarantees in reach.

Three goals drive the design:

• More throughput. Move execution off L1 so blocks are bigger, blocks come faster, or both.
• Lower fees. Amortise L1 settlement costs across many L2 transactions.
• Same trust model, as much as possible. Inherit Ethereum's security rather than starting a new validator set from scratch.

Different L2s make different trade-offs against those goals.

Rollups, in two flavours

The dominant L2 design today is the rollup: an L2 that posts transaction data (or a commitment to it) back to L1, plus a way for L1 to verify that the L2 followed its own rules. Rollups split into two camps based on how that verification works.

Optimistic rollups

Optimistic rollups assume L2 transitions are correct by default. When the sequencer posts a batch, anyone can challenge it within a fraud-proof window - usually about seven days - by submitting evidence that the batch contains an invalid transition. If no challenge appears, the batch finalises.

Pros: simpler proof system, EVM-equivalent execution, well-understood security model.

Cons: long withdrawal windows back to L1 unless you use a bridge with a liquidity provider that fronts the funds.

Configured optimistic-rollup L2s on tx.taxi include Arbitrum One, Optimism, and Base.

Zero-knowledge rollups

Zero-knowledge (zk) rollups attach a succinct cryptographic proof to each batch, demonstrating that the L2 transitions were valid without anyone having to re-execute them. L1 verifies the proof and accepts the batch immediately.

Pros: fast finality (no fraud-proof wait), strong cryptographic guarantees.

Cons: proving is computationally expensive, and full EVM equivalence is harder to engineer than in an optimistic rollup.

Configured zk-rollup L2s on tx.taxi include Scroll.

There are also designs that sit nearby: validiums (zk proof but data off L1), state channels, plasma chains, sidechains (security from their own validator set, not Ethereum). They are not all rollups, and the lines between L2 and "EVM chain with a different validator set" can get blurry. Polygon, for example, is historically a sidechain with its own consensus, while the newer Polygon zkEVM is a zk rollup.

What "EVM" buys you on an L2

An EVM L2 promises that Solidity contracts deployed to it will behave the way they do on Ethereum. The level of compatibility varies:

• EVM-equivalent - the L2 implements every opcode the same way Ethereum does, including gas costs. Existing contracts deploy unchanged.
• EVM-compatible - the L2 supports the same Solidity surface but may diverge on gas, precompiles, or some opcodes. Most contracts work; a few need adjustments.

The practical upshot for users: an L2 transaction looks identical to an L1 transaction. Same 0x-prefixed 66-character hash, same address format, same calldata shape. From the wallet's point of view, you just switch networks and keep going.

Transactions and where they live

Two different transactions are involved any time you act on an L2:

• The L2 transaction - executed on the L2, recorded in an L2 block, with an L2-specific hash. This is the one you see in your wallet and the one your dApp confirms against. It lives on the L2's explorer.
• The L1 batch transaction - the bundle the sequencer posts to Ethereum. It contains a compressed record of many L2 transactions (and on zk rollups, the validity proof). It has its own hash, lives on Etherscan, and represents settlement to L1.

So a single user action produces one L2 tx hash you care about, plus eventually a contribution to one L1 batch tx hash that mostly matters to infrastructure.

Block hash vs transaction hash covers the difference between those identifiers in more detail.

Looking up L2 activity

Each L2 has at least one dedicated explorer. The Etherscan family has direct deployments for several:

• Arbitrum One: Arbiscan
• Optimism: Optimistic Etherscan
• Base: BaseScan
• Polygon: PolygonScan
• BNB Smart Chain (an EVM chain, not strictly an L2): BscScan
• Scroll: Scrollscan

That UI consistency is deliberate. Once you know how to read an Etherscan page, you know how to read any of these. The chain switcher in the URL is often the only meaningful difference.

tx.taxi handles the network choice for you. When you paste an EVM address, the router defaults to a multichain aggregator that shows balances and activity across all configured EVM networks - so you do not need to know in advance whether the address has activity on Base, Arbitrum, Optimism, or all three. When you paste a transaction hash, tx.taxi inspects the configured explorers to find which network includes that hash and redirects accordingly.

Mental model

L2 addresses are L1 addresses on a different network. L2 transactions are L1-shaped transactions executed off mainnet. L2 explorers are L1 explorers configured against a different chain. The reason that consistency exists is that the "V" in EVM is the same VM on both layers - the difference is the network underneath, not the language above.

That is the whole pitch: same tools, more room.