Saying “the transaction went through on an Ethereum L2” hides several different systems. A user signs an operation in one execution environment, a sequencer can order it in milliseconds, data can be published through another path, and the strongest economic settlement only arrives after L1 accepts the relevant batch, proof or dispute result. An L2 is therefore not “Ethereum, only faster.” It is a separate protocol that moves some work away from L1 while trying to preserve selected guarantees of the base layer.
L1 and L2 are not simply two floors of the same program
Layer 1 is the base blockchain system: consensus, validators, canonical history, data availability and final settlement rules. For Ethereum, that is Mainnet. Layer 2 is a separate execution protocol that handles user operations away from L1 and then anchors its result back to the base layer.
The important question is not which network is faster, but which function each layer performs. If execution moves to L2, who verifies the resulting state transition? Where are the data required for independent reconstruction? Who can recover state if the sequencer disappears? When does a withdrawal become settled on L1? Those answers define the security model.
Three functions worth separating
A useful architecture model splits the system into execution, data availability and settlement. Execution computes the new state. Data availability ensures that independent parties can obtain enough information to verify or reconstruct that state. Settlement resolves disputes or verifies compact evidence and anchors the result in a more secure system.
- **Execution:** where VM opcodes and application state changes actually run.
- **Data availability:** where transaction data or equivalent reconstruction data are published.
- **Settlement:** where proofs are accepted, fraud disputes are resolved and the state root becomes economically anchored.
Why this decomposition matters more than advertised TPS
Two networks can advertise similar throughput while relying on very different assumptions. One posts data to Ethereum blobs and verifies proofs on Mainnet. Another keeps data with a separate committee. A third has its own validator set and only connects to Ethereum through a bridge. Transactions-per-second tells you almost nothing about that distinction.
A rollup moves execution while anchoring verifiability to L1
A rollup executes user transactions away from Ethereum Mainnet, groups them into batches and publishes the required data and commitments to L1. The efficiency gain comes from sharing one publication cost across many operations and from avoiding ordinary L1 re-execution of every L2 transaction.
But “rollup” does not mean L1 knows nothing about what happened. The core idea is to leave enough information and protocol logic on the base layer that the L2 cannot silently make an arbitrary invalid state final.
What a sequencer actually does
The sequencer receives L2 transactions, determines their order and usually gives users very fast preliminary confirmations. In most production rollups this component is still far more centralized than the Ethereum validator set. That is an intentional operational trade-off: UX gains low latency, while the system introduces an entity that can go offline, delay users or censor ordering.
The sequencer should not be able to turn an arbitrary invalid state into final history. Published batches, forced-inclusion mechanisms, proof systems and settlement contracts constrain its authority.
Soft confirmation is not L1 finality
A wallet can show success immediately after sequencer acceptance. That is useful for applications, but it is not the same as L1 settlement. Batch publication, proof generation, a challenge period and Ethereum finality can still remain ahead.
The faster an L2 interface feels, the more important it is to ask what has actually happened: sequencer acceptance, L2 block inclusion, data publication, proof verification or L1 finality?
Optimistic rollups assume correctness until a valid challenge proves otherwise
An optimistic rollup executes transactions offchain and publishes results plus transaction data to Ethereum. It does not attach a validity proof to every batch. Instead, a state update is treated as acceptable unless someone produces a valid fraud or fault proof during the defined challenge window.
That is the meaning of “optimistic.” The system initially accepts offchain computation while preserving a protocol path to dispute a bad transition. Independent challengers need the underlying data, so data availability is not an implementation detail—it is part of fraud-proof security.
Fraud proofs and the challenge period
If an operator posts an incorrect result, another party can begin a dispute. The exact mechanism varies by protocol: interactive proofs, fault-proof VMs and other constructions all try to reduce the question to something L1 can decide objectively.
The challenge period creates the characteristic withdrawal UX. A user can receive an L2 success signal almost immediately, while a canonical bridge withdrawal can wait for the dispute window. Liquidity providers can make exits feel faster, but then the user replaces protocol delay with liquidity-provider assumptions.
Why a fraud proof is useless without data
You cannot prove execution was wrong if honest participants do not have the transaction inputs or state-reconstruction data. That is why optimistic rollups publish data to Ethereum through calldata or blobs. Ethereum’s own documentation explicitly ties onchain data availability to the ability to reproduce state and challenge invalid operations.
ZK rollups replace the dispute window with a validity proof
A ZK rollup also executes transactions away from Mainnet, but it accompanies state updates with a cryptographic validity proof. The L1 verifier checks evidence that the new state follows correctly from the old state under the rollup’s rules.
This is a fundamentally different correctness path. Instead of “accept unless challenged,” it is closer to “accept after a compact proof verifies.” The same challenge period is not required for computation correctness.
A validity proof does not make data availability optional
A proof establishes correctness of a transition, but users still need data to know their balances, build new transactions and independently reconstruct the chain. A classic ZK rollup therefore publishes state-reconstruction data to L1.
If validity proofs are verified on Ethereum while transaction data are kept elsewhere, the architecture moves toward a validium-like model. Computation correctness remains cryptographically protected, while exit and state-reconstruction assumptions now depend on an external data-availability system.
ZK does not automatically mean private
Zero-knowledge proof systems can hide witnesses, but a ZK rollup may use validity proofs purely for scalability while publishing enough data for transparent state reconstruction. “ZK equals privacy chain” is therefore a misleading shortcut.
Data availability is the most underrated part of rollup security
It is easy to treat the proof as the entire security model. But a proof answers a specific mathematical question. Correct state transition does not automatically guarantee that independent users can access the state data required to keep the network usable.
After EIP-4844, Ethereum provides blob space designed primarily for L2 data. Rollups can publish compressed transaction information in blobs more cheaply than persistent calldata. Ethereum guarantees blob availability for a limited protocol window; long-term archival becomes an ecosystem responsibility afterward.
Calldata and blobs solve a similar problem differently
Calldata becomes part of normal Ethereum history and remains available with chain data. Blobs are cheaper for rollups and use a separate fee market, but they are not intended as permanent execution-state storage. Fraud-proof systems need challenges to be constructible while protocol-level data availability is guaranteed.
A data-availability committee changes the trust model
If a system posts commitments to Ethereum but keeps transaction data with a separate committee, users gain cheaper publication at the cost of another assumption. The committee can fail or refuse to reveal data. A validity proof can still establish correctness of the accepted state while doing nothing by itself to guarantee future access to that state.
A sidechain is not an L2 in the strict rollup sense
A sidechain has its own consensus and validator set. It can connect to Ethereum through a bridge, support the EVM and look almost identical in a wallet. But its security is not automatically inherited from Ethereum’s validator set.
If sidechain validators agree on history under their own rules, Ethereum Mainnet usually does not run an embedded fraud or validity mechanism that rejects that history. A bridge may instead trust signatures, a multisig or another validator set.
Rollups and sidechains differ in the root of final security
| Property | Optimistic rollup | ZK rollup | Sidechain |
|---|---|---|---|
| Execution | Off L1 | Off L1 | On its own chain |
| State verification | Fraud/fault proof | Validity proof | Own consensus |
| Data availability | Usually Ethereum calldata/blobs | Usually Ethereum calldata/blobs | Own network |
| Settlement | Ethereum L1 | Ethereum L1 | Own consensus + bridge |
| Main added risk | Sequencer + dispute assumptions | Prover/sequencer + DA assumptions | Validator/bridge trust model |
A sidechain can be fast and useful, but calling it “the same kind of L2” because it has an EVM and a bridge hides the key question: who gets the final authority to decide which state is correct?
The L1–L2 bridge is part of the security boundary
To move an asset into a rollup, an L1 bridge contract usually locks or accounts for the asset on Ethereum while L2 reflects the corresponding balance. A withdrawal must eventually convince the L1 contract that the user has a valid claim to receive the asset back.
With a canonical bridge, that logic is tightly coupled to rollup settlement. If the bridge accepts a state root that completed the expected proof or dispute path, it can release funds under protocol rules. A third-party bridge adds another trust layer: liquidity providers, multisigs, message validators or a separate verification protocol.
Forced inclusion and escape hatches
If a sequencer censors a user, a mature rollup design tries to preserve a path through L1. The user can submit an operation directly to a contract or invoke a forced-transaction or withdrawal mechanism. Details differ, but the goal is consistent: the sequencer should not be the only entity capable of permanently controlling exit.
Why you must verify the escape hatch in production
A whitepaper design and deployed contracts are not always identical. A mechanism can exist conceptually while depending on pause controls, upgrade admins, a proof system or a fault-proof component that is not yet fully active. Real security analysis must inspect the actual deployed version and governance state.
L2 finality is a timeline, not one timestamp
For an application, “final” can mean safe enough to update its local UI. For a bridge, it can mean safe enough to release value on L1. For a protocol engineer, it can mean an L1 finalized block already contains the accepted proof or an irreversible dispute outcome.
A useful timeline is:
- The wallet signs the L2 transaction.
- The sequencer accepts and orders it.
- The transaction enters an L2 block or batch.
- Batch data or commitments are published on L1.
- The fraud window completes or the validity proof verifies.
- The relevant L1 transaction reaches the required finality.
The same transaction can be “successful” at stage two for UX and still be inappropriate for a large irreversible external settlement at stage three.
What can actually stop an L2
A rollup inherits part of Ethereum’s security while service availability can depend on a smaller set of components. Sequencer outages can halt normal UX. Prover outages can delay ZK settlement. Fault-proof infrastructure matters to optimistic dispute safety. Upgrade keys can alter contracts.
A serious L2 review should therefore check more than the proof type:
- how many sequencers exist and how failover works;
- who controls upgrade keys and emergency pause authority;
- where data availability is provided;
- whether permissionless proofs or challenges are active;
- whether forced inclusion and forced withdrawal are usable;
- how long canonical exit takes;
- whether bridges depend on separate multisigs or validator sets.
How to read an L2 explorer without fooling yourself
An L2 explorer shows block numbers, transaction status, gas and contract events, but you still need to know which layer you are observing. An L2 block number is not an Ethereum block number. An L2 timestamp does not prove the batch is already on L1. “Success” means execution succeeded under L2 rules, not that a withdrawal has fully settled.
For a critical transaction, verification should go both directions: first confirm execution on the L2 explorer, then use L1 or rollup-specific data to inspect the batch, state root, proof or challenge status. For large bridge transfers this is much more informative than a single green checkmark.
Where the transaction actually executes
In a rollup, the user’s smart-contract transaction normally executes inside the L2 VM, not inside Ethereum Mainnet’s EVM as an ordinary L1 transaction. Ethereum receives aggregated commitments, data and proof- or dispute-related messages. L1 protects the result not necessarily by replaying every user transaction, but by validating compact protocol evidence.
That is the scalability win: expensive per-user execution moves away from L1 while the base layer provides consensus, data availability and settlement for aggregated results.
What remains on L1
L1 contains rollup contracts, deposits and withdrawals, state commitments, proof or dispute logic and published data or blobs. It also provides the final accounting base for canonical bridge operations and recovery paths.
What remains on L2
L2 contains user accounts, contracts, local blocks, transaction ordering, execution receipts and application state. To developers this can feel like another EVM chain, but economic finality is built through the connection back to L1.
The main conclusion
An L2 is not a magical accelerator above Ethereum. It is an architectural division of responsibilities. Execution moves into a cheaper environment, data availability preserves independent verification and reconstruction, and settlement sends disputes or validity evidence back to the base layer.
Optimistic rollups rely on available data and the ability to prove errors. ZK rollups rely on validity proofs but still need data availability for permissionless state reconstruction. Sidechains use their own consensus and therefore have a different security root.
The most useful habit is to stop asking only “how many TPS does this L2 have?” and instead ask four questions: where does the transaction execute, where are the data, who can challenge or prove the state transition, and what mechanism lets a user recover funds if the sequencer disappears?
FAQ
Does an L2 transaction execute on Ethereum Mainnet?
Usually not. User execution happens in the L2 VM. Ethereum receives data and commitments and verifies a fraud/fault proof or a validity proof according to the specific rollup architecture.
Why can optimistic withdrawals take longer than ZK withdrawals?
Optimistic designs need time for participants to challenge an incorrect state update. A ZK rollup can complete its correctness path after a validity proof verifies, although practical latency still depends on batch, proof and L1 publication pipelines.
Can a sequencer steal funds?
In a correctly designed rollup, a sequencer should not be able to make an arbitrary invalid state final by itself. It can still affect ordering, latency and censorship, while upgrade and bridge assumptions need separate review.
Are sidechains and L2s the same thing?
No. A sidechain usually has its own validator consensus and does not inherit Ethereum settlement security in the same way a rollup does. A bridge connects systems; it does not automatically turn a sidechain into a rollup.
What is data availability in plain English?
It is the guarantee that the information required to verify and reconstruct state is accessible to independent participants. Without that data, a proof or dispute system can be insufficient for permissionless recovery.
Why are L2 fees lower if data still goes to Ethereum?
Because many L2 transactions are aggregated, compressed and published more efficiently, including through blobs. The cost of L1 publication is shared across many users.
This material is educational and informational. It is not financial advice or a trading signal.