What Are Rollups? Optimistic vs ZK Explained

What a rollup actually does, mechanically

If you've read our Layer 1 vs Layer 2 guide, you already know a rollup is how most L2s inherit their L1's security. Here's the part that guide only touched on: what happens, step by step, to your transaction.

A rollup executes transactions on its own separate chain, away from the L1. It doesn't ask the L1 to process each one individually. Instead, it collects a batch, potentially thousands of transactions, and compresses them down into a single, compact piece of data. That compressed batch is what actually gets posted back to the L1.

This is the whole trick. The L1 never has to execute your individual swap or transfer itself. It just has to store (and, depending on the design, verify) one small batch that represents thousands of transactions. Since the L1's own capacity is the bottleneck, cutting the amount of work it does per user transaction is what makes rollups so much cheaper and faster than transacting on the L1 directly. The rollup still leans on the L1 for security and for data availability (making sure the underlying transaction data is actually published somewhere anyone can check), it just doesn't burden the L1 with re-running every transaction one at a time.

Where rollups differ from each other is in how the L1 gets convinced that a batch is legitimate. That's where optimistic and zk rollups take genuinely different approaches.

Optimistic rollups: assume it's valid, then leave a window to prove otherwise

An optimistic rollup does exactly what the name implies. When it posts a batch to the L1, it doesn't include any proof that the transactions inside are correct. It just assumes they are, and the L1 accepts the batch on that assumption.

To make that safe, the system adds a challenge window, commonly around a week, during which anyone watching the network can submit a fraud proof. A fraud proof is a specific claim: "transaction number X in this batch was invalid, and here's the evidence." If someone submits a valid fraud proof in time, the disputed part of the batch gets rolled back and the rollup's state gets corrected. If the challenge window passes with no successful challenge, the batch is treated as final.

The catch is withdrawals. If you want to move funds from an optimistic rollup back to the L1, you technically have to wait out that full challenge window before the L1 will treat your withdrawal as settled and final. In practice, plenty of users don't wait: third-party liquidity providers will front you the funds immediately, minus a fee, and then collect the actual withdrawal themselves once the window closes. That's convenient, but it's a workaround for the delay, not a way the delay goes away.

ZK rollups: prove it's valid up front, skip the waiting

A zero-knowledge rollup (zk-rollup) takes the opposite approach. Instead of assuming a batch is valid and giving people time to challenge it, it generates a validity proof alongside the batch itself: a cryptographic proof that mathematically demonstrates every transaction in that batch was executed correctly.

The L1 can check that proof almost instantly. It doesn't need to re-run the transactions or trust anyone's word for it, the math either checks out or it doesn't. Because there's no assumption being made and no need to leave a window open for someone to dispute it, there's no challenge period. That's why withdrawals from a zk-rollup back to the L1 can settle much faster than from an optimistic one.

The tradeoff has historically been on the engineering side. Generating these validity proofs is computationally intensive, and building that proving process to handle arbitrary, general-purpose smart contract activity (not just simple transfers) used to be a much harder problem than building an optimistic rollup. That gap has been closing steadily as the underlying proof systems and tooling mature, but it's part of why optimistic rollups had a head start in supporting complex applications.

The core tradeoff, side by side

• Optimistic rollups. Simpler, more mature technology, and generally easier to make fully compatible with existing smart contract code written for the L1. The cost is a real withdrawal delay (or a fee if you want your funds sooner via a third party).
• ZK rollups. Faster finality and faster withdrawals, since there's no challenge window to sit through. The cost has been more complex, newer technology, and historically more work to support the full range of smart contract activity, though that gap keeps shrinking.

Neither approach is simply better in every respect. It's a genuine engineering tradeoff between "prove correctness up front" and "assume correctness, then police it after the fact." This is still an active, evolving area of blockchain design, and some newer rollup designs blend elements of both approaches or keep chipping away at each side's weak points, so the gap between them is narrower today than it was a couple of years ago.

Why this matters if you're actually using one

Most of the time, using a rollup feels the same regardless of which type it is: you send transactions, they confirm quickly, and fees are lower than doing the same thing on the L1. The difference only shows up when you want to move funds back to the L1. If you're on an optimistic rollup, budget for that challenge-window wait (or the fee to skip it). If you're on a zk-rollup, withdrawals should settle much faster.

It's worth knowing which type of rollup you're actually using before you need to move funds, not after you've already started a withdrawal and are wondering why it hasn't shown up. Rollups aren't the only way chains are approaching scaling either. If you want to see how some newer architectures split up the work differently, our guide to modular blockchains is a good next read, and if you want a refresher on where rollups fit against the major chains generally, see our guide to Ethereum, Solana, Bitcoin and the rest.