Rollups under the hood - batches, fraud proofs, ZK, blobs and withdrawals

In the article Layer 2 and rollups we explained the idea: execute transactions outside Ethereum and borrow security from it. Here we look into the mechanism: how data reaches Ethereum, how correctness is proved and why withdrawal is arranged as it is.

The general rollup pipeline

1. The user sends a transaction to the sequencer (the operator's server).
2. The sequencer orders transactions, executes them on its EVM-like engine and at once returns a "pre-confirmation".
3. A group of transactions is compressed into a batch and published to Ethereum (the data).
4. With the batch the L2's new state (a state root) is published.
5. The rollup's contract on Ethereum accepts the new root either at once or after verification.

Crucially: enough data lies on L1 for anyone to reproduce the L2 state afresh. This is called data availability. Without it an operator could "freeze" users.

Publishing data: calldata and blobs

Batches used to be published as calldata of ordinary transactions - expensive, because these bytes are stored forever and had to be paid for at L1's gas price.

With the Dencun upgrade (March 2024) EIP-4844 brought a new data type - blobs:

• a blob is a chunk of data up to 128 KiB;
• blobs have a separate fee market, independent of ordinary gas;
• nodes keep blobs for about 18 days, then delete them (on L1 only a commitment, a hash-like "mark", remains).

After blobs arrived, fees on L2 fell several times over, because the expensive part - publishing data - got cheaper. A retention of 18 days is enough for anyone to fetch the data and verify the result.

Two ways to prove correctness

Optimistic rollups

"We believe it until proven otherwise."

1. The operator publishes a new state root and does not prove it.
2. A challenge window begins (usually 7 days).
3. Any observer who spots an error submits a fraud proof. The L1 contract verifies it by re-executing the disputed section.
4. If the proof is right, the wrong root is cancelled and the operator is penalised. Otherwise, when the window ends, the root is considered final.

Only one honest party able to check and complain is needed. Plus: simple and EVM-compatible. Minus: withdrawing funds takes a week.

ZK rollups (with validity proofs)

"Prove it in advance."

1. The operator executes the batch and builds a cryptographic proof (SNARK or STARK) that the move from the old state to the new one was made by the rules.
2. The L1 contract verifies the short proof (quickly and cheaply, regardless of batch size).
3. After verification the root is accepted at once.

Plus: no waiting window, fast withdrawal. Minus: building a proof requires heavy computation (the cost for the "prover"), and EVM compatibility is harder to achieve.

Forced inclusion

What if the sequencer censors your transaction? A rollup has a mailbox contract on L1. You can send a transaction there directly: after a set time the sequencer must include it, or anyone can force it through. This provides "censorship resistance" at the price of delay and an L1 fee.

How withdrawal to L1 works

An L2 → L1 message (for example withdrawing ETH) works like this:

1. On L2 the user burns or locks tokens and creates a message.
2. The message ends up in data fixed in the state root.
3. After the challenge window ends (or after a ZK proof is verified) the user presents on L1 a proof of inclusion of the message in this root - essentially a branch of a Merkle tree.
4. The L1 bridge contract verifies the proof and releases the assets.

This explains both the withdrawal delay (waiting for the window to end) and why fast third-party bridges exist: they give you money at once and then wait for the withdrawal themselves.

The fee structure

A transaction on L2 pays for two things:

• execution on L2 (cheap);
• publishing data on L1 (your transaction's share of the batch and blob).

The more efficient the compression and the larger the batch, the smaller the share. A comparison of networks is in the article how to choose a network.

Stages of decentralisation

Not all rollups are equally reliable. Stages are distinguished:

• Stage 0: the system works but relies largely on trusted operators and administrators' keys.
• Stage 1: proofs already work, and a security council can intervene only in limited cases.
• Stage 2: fully governed by code, administrators have almost no influence.

Most L2s are still at early stages. When assessing a network for a large sum, look at who can upgrade the contracts and whether there is a timelock (proxies and upgradeability).

What this means for a Coin-Trust user

• A deal on Base executes quickly and cheaply, but finality in the Ethereum sense arrives after publication and (for an optimistic rollup) the end of the window.
• The escrow contract runs inside the L2 like an ordinary contract; its address and rules are the same (CREATE2).
• For large sums, take the L2's security assumptions into account.

What to read next

Learn who earns from ordering transactions and what danger this poses: MEV and front-running. Or how to make a wallet smarter: account abstraction.