Layer 2 rollups explained: optimistic, zk, and sidechains compared

The problem: one chain, every node, every transaction

A base blockchain — Layer 1 — typically requires every participating node to process and independently verify every transaction. That's the source of its security: no single party can slip a fraudulent transaction past the network, because thousands of independent computers are all checking the same math.

It's also the source of its ceiling. If every node has to process every transaction, the network's total throughput is capped by what an ordinary computer running a node can handle — not by what the busiest, best-resourced participant could do. Add more users, and you don't get more capacity; you get a longer queue and higher fees, because block space is fixed and demand isn't.

This is usually described as a trilemma: a base chain can prioritize decentralization, security, and scalability, but tends to max out two at the expense of the third. Push throughput up by requiring beefier hardware to run a node, and you shrink the pool of people who can afford to validate — decentralization erodes. Keep node requirements low so anyone can participate, and you cap throughput.

Layer 2s are an attempt to sidestep the tradeoff rather than solve it directly: move the transaction processing off the base chain, but find some way to still inherit its security. How well that actually works depends entirely on the design, and the designs are not interchangeable.

Optimistic rollups: assume it's valid, argue later

An optimistic rollup batches up hundreds or thousands of transactions, executes them off-chain, and then posts the resulting data back to the base chain. Critically, it does not prove the batch is correct at the time of posting. It just asserts it, and the base chain accepts the assertion — optimistically.

To keep that honest, there's a challenge window, typically around seven days, during which anyone watching the chain can submit a fraud proof showing that a specific batch was computed incorrectly. If a challenge succeeds, the fraudulent batch is reverted and the party who posted it loses a bond they staked to do so. If no one challenges within the window, the batch is treated as final.

This is why withdrawing funds from an optimistic rollup back to the base chain takes about a week in the default case. The withdrawal isn't slow because of network congestion — it's slow because the protocol needs the full challenge window to elapse before it can be confident nobody is going to prove the underlying batch fraudulent. Third-party liquidity providers will often front you the funds instantly for a fee, but that's a separate service sitting on top of the rollup, not the rollup itself moving faster.

The appeal of the optimistic design is simplicity: you don't need to prove general-purpose computation cryptographically, you just need a mechanism for someone to catch and punish bad actors after the fact. That's a much easier engineering problem, which is part of why optimistic rollups were practical to build for arbitrary smart contract execution earlier than their zk counterparts.

Zero-knowledge rollups: prove it, don't assert it

A zk rollup also batches transactions and executes them off-chain, but instead of posting a bare assertion and waiting for someone to object, it posts a cryptographic proof alongside the batch — typically a zk-SNARK or zk-STARK — demonstrating that the new state is the correct result of executing those transactions. The base chain verifies the proof directly, which takes a small, fixed amount of computation regardless of how many transactions were in the batch.

There's no challenge window because there's nothing to challenge. Either the proof verifies or it doesn't, and that check happens in the same transaction that posts the batch. Withdrawals can be near-instant once the proof settles, instead of waiting out a multi-day window.

Architecturally this is the more elegant answer to the problem — you get mathematical certainty instead of an economic incentive scheme built on watchdogs and bonded challengers. The catch has historically been generality. Proving "this arbitrary contract executed correctly" in zero-knowledge is a much harder computational problem than proving a fixed, narrow computation like a token transfer. Early zk rollups were mostly limited to specific use cases — payments, simple swaps — for exactly this reason. General-purpose zk rollups capable of running arbitrary smart contracts have become practical more recently, and proof generation itself remains computationally expensive, which shows up as higher operational cost passed through to fees.

Sidechains: a different chain wearing a bridge

Sidechains get lumped in with rollups in casual conversation, but they're a structurally different thing. A sidechain is an independent blockchain with its own validator set, its own consensus rules, and its own security budget. It is connected to the main chain only via a bridge — a piece of infrastructure, often a multisig or a separate smart contract, that locks assets on one side and mints a representative asset on the other.

The critical distinction: a rollup posts data or proofs back to the base chain, so the base chain's security is doing real work in verifying the rollup's state. A sidechain posts nothing back. Its validators could theoretically approve an invalid state, and the main chain would have no way of knowing, because it isn't checking. The main chain only sees the bridge contract, and the bridge contract only knows what its own operators tell it.

That means a sidechain's security is a function of its own validator set — how many validators there are, how they're selected, how much is at stake if they collude — plus the security of the bridge itself. Bridges have a poor track record as an attack surface, generically, because they concentrate a large amount of value behind a comparatively small and often permissioned set of keys or contracts. A sidechain can be fast and cheap precisely because it isn't burdened by the base chain's verification process, but that speed comes from opting out of the base chain's guarantees, not from a clever way of keeping them.

The security spectrum, side by side

The pattern across the row is straightforward: the more a system relies on posting verifiable information back to the base chain, the stronger the inherited security and the more that strength costs in complexity, fees, or withdrawal delay. The more a system operates independently, the cheaper and faster it can be, and the more you're trusting a separate, smaller set of parties instead.

What you're actually trusting when you bridge funds over

None of this is visible from a wallet UI. A deposit screen that says "bridge to network X" looks the same whether X is a zk rollup with a base-chain-verified proof system or a sidechain secured by nine validators and a multisig bridge. The interface abstracts away exactly the distinction that matters for your funds' security.

Before moving meaningful size onto any L2, it's worth answering three questions concretely rather than taking the marketing at face value: Does this network post data or proofs back to the base chain, or does it just have a bridge? If it has a challenge window, how long is it, and does that match your liquidity needs — is a week-long withdrawal delay acceptable for this position, or do you need same-day exit? And if it's a zk system, is the proof actually verified on the base chain, or is "zk" being used as a marketing label for a system that still relies on a trusted operator for parts of its pipeline (some early zk-labeled systems retained centralized sequencers or provers as a practical bootstrapping step, which is a meaningfully weaker guarantee than the fully trustless end state).

None of these questions require reading the codebase — they're usually answered directly in the project's own documentation, if you look for the words "fraud proof," "validity proof," or "bridge contract" rather than the word "Layer 2" itself. Treat the label as marketing and the mechanism as the thing you're actually trusting.