There’s a common misconception among Ethereum users that optimistic rollups take 7 days to finalize. Or at least much longer than ZK rollups. This confuses rollup finality with the bridge withdrawal delay, let’s look at how it actually works.

If finality was defined by the proof system (either fault/fraud proofs or ZK proofs), what would happen when a proof fails? You might assume the chain rolls back it’s state somehow, but it would be disastrous to roll back (reorg) the entire chain after days or even an hour.

In fact, finality actually happens just as quickly on an optimistic rollup as on a ZK rollup, and it has nothing to do with the bridge!

If I buy your car, and I pay you on OP Mainnet, when is it safe for you to let me drive away? Hint: it’s not 7 days!

All optimistic rollups are similar, but let’s use Optimism as an example.

The pieces of the OP Stack

• Rollup node (and execution engine): Together these are the node software (the blockchain client). You can run this at home and have a local view of the canonical L2 chain.
• Sequencer: This is an instance of the node software that produces new blocks, accepting transactions directly from users (and also “forced inclusion” transactions that were submitted on L1).
• Batcher: submits new blocks generated by the sequencer to the L1 (Ethereum). It submits these blocks as opaque data (typically “blob transactions”).
• Bridge: a smart contract on L1 (Ethereum) that accepts deposits of ETH and tokens from L1, and allows those assets to be withdrawn once they’re no longer being used on L2.

Derivation (do rollups even have consensus?)

In an L1 blockchain like Bitcoin or Ethereum the ordering of the blocks (the canonical chain) is determined by a group of nodes (the validators or miners) coming to consensus.

A rollup is simpler: the canonical chain is determined by what’s stored in the blobs on Ethereum. Derivation is the process by which the node software builds it’s view of the chain from the data it reads from Ethereum.

So a rollup uses Ethereum’s consensus and finality. Once those blobs are in finalized Ethereum blocks they’re not changing. The finalized rollup chain is the version of the chain that can be derived from finalized data on Ethereum L1.

[!note] 💡 The finalized rollup chain is the version of the chain that can be derived from finalized data on Ethereum L1.

So when can I take your car?

When I send you the ETH for your car on OP Mainnet you’ll see the balance on your account reflected as soon as the sequencer creates a block with that transaction. But, as you know, it’s still not finalized so don’t give away your car key yet!

Once the batcher has submitted the new blocks to L1 your node will be able to read that blob data from Ethereum. They are now “safe” L2 blocks, and once the Ethereum blocks containing those blobs are finalized then they are now finalized on the rollup! Now you can give me the key!

What’s the 7 days then?

You can trust the chain state because you’re running a node. But other observers of the chain who aren’t running their own node might need some sort of proof.

The bridge is one such user! It needs a view of the L2 chain, but since it’s just a smart contract on L1 it has no way to query an L2 node for the finalized state. You need to convince it of the state somehow. On a ZK rollup that’s done by giving it a validity proof to verify. And on an optimistic rollup you do that by giving it a valid fault proof (by playing a “dispute game”) if it should not allow the withdrawal, and this is what takes the time. So even though it’s finalized on the chain, the bridge takes 7 days to be sure of the chain state, so it delays withdrawals.

These different views of chain safety are called confirmation rules. The bridge has a different confirmation rule than the node itself.

The proof is the bridge’s way of running a node

If it was OK to fully trust the rollup chain operator then the bridge wouldn’t need a view of the L2 state. The chain operator could simply post L2 state roots for the withdrawals onto L1, and the bridge would just trust them. But then the operator could also post invalid state roots and steal the money. Or at least block your withdrawals if they stopped doing their job.

So the OP Stack has permissionless fault proofs, allowing anyone to post state roots to L1, and this means the bridge needs a proof to be sure they’re valid.

The bridge can’t run a node. But if someone else ran the derivation process using some type of verifiable computation, then the bridge could simply verify it.

Optimistic rollups use a dispute game for this, but ZK proofs and dispute games are both types of verifiable computing: they allow anyone to run some computation and prove that they ran the right thing, and ran it correctly.

Summary

So a rollup node’s view of finality is different from the bridge’s view of finality.

The rollup node itself knows that a block is finalized when it retrieved that block from a finalized L1 blob. It knows that data is securely stored on Ethereum and it re-executed the transactions so it knows the state is correct.

But the bridge needs to be convinced by a proof, and that’s what takes the time.

PS… want to help build the Optimism proof system?

I’m hiring engineering roles for the Proofs team at OP Labs. Take a look at our open roles, apply, and get in touch with me if you have questions or to let me know you’ve applied.