The Rollup Pattern — Execute Off-Chain, Settle On L1

The scalability trilemma left us with a constraint that felt like a dead end: a single chain cannot be simultaneously decentralized, secure, and high-throughput, because every full node must re-execute every transaction and store the result forever. Making the chain faster by asking nodes to do more work just prices out the small validators and quietly recentralizes the network — the very thing we were protecting.

The rollup pattern is Ethereum’s chosen way out, and it is a genuinely clever sidestep rather than a violation of the trilemma. The core move: stop asking L1 to execute the transactions, and ask it only to order the data and hold the money. Execution happens off-chain, in bulk, on cheaper hardware; Ethereum keeps just enough information to let anyone reconstruct and check the result — and to let a cheated user walk their funds back to L1 without anyone’s permission. This page builds that pattern from first principles, and then draws the sharp line between a rollup that actually inherits Ethereum’s security and something that only looks like one.

The core idea: separate execution from settlement

Recall from World state & roots that a blockchain is a deterministic state machine: a world state, plus a rule apply(tx) that advances it, plus a 32-byte state root that fingerprints the whole world. The expensive part is running apply for every transaction on thousands of machines. The agreement part — checking that everyone reached the same world — is cheap, because it’s just comparing roots.

A rollup drives a wedge into exactly that seam. It splits the job a monolithic chain does all at once into two layers:

   ┌─────────────────────────────────────────────────────────────┐
   │  L2 (the rollup)   — EXECUTION                               │
   │  runs apply(tx) for thousands of txs on one fast machine     │
   │  produces: new state root  +  the raw tx data that got there │
   └───────────────────────────┬─────────────────────────────────┘
                               │ posts a BATCH
                               │  • compressed transaction data
                               │  • old root → new root commitment
                               ▼
   ┌─────────────────────────────────────────────────────────────┐
   │  L1 (Ethereum)     — SETTLEMENT + DATA AVAILABILITY          │
   │  does NOT re-run the txs                                      │
   │  does: order the batches, store the data so anyone can        │
   │        reconstruct L2 state, hold the bridged funds           │
   └─────────────────────────────────────────────────────────────┘

Ethereum, in a rollup world, is no longer the computer that runs your transaction. It is the court and the vault: it timestamps an immutable record of what happened (the data), it holds the canonical claim about the resulting state (the root), and it custodies the actual ETH and tokens. The rollup is the fast machine that does the computing and then files its paperwork with the court.

What “a batch” actually contains

A rollup doesn’t post one transaction at a time — that would be as expensive as just using L1. It accumulates hundreds or thousands of L2 transactions, then posts a single batch to an L1 contract. Two things go up:

The compressed transaction data. Enough bytes for anyone to replay the batch themselves and independently derive the new state. This is the non-negotiable part — we’ll see why in a moment, and the whole of Data availability is devoted to it.
A state-root commitment. A claim of the form “starting from root 0xOLD, applying this batch yields root 0xNEW.” That single 32-byte 0xNEW is the rollup asserting the new state of its entire world.

   L2 mempool:  tx₁ tx₂ tx₃ … tx₉₉₉   (executed off-chain, in order)
                       │
                       ▼  batch them
   ┌─────────────────────────────────────────────┐
   │ BATCH → L1 contract                          │
   │   data:  compress(tx₁ … tx₉₉₉)               │
   │   claim: root_before 0xOLD → root_after 0xNEW │
   └─────────────────────────────────────────────┘

The L1 contract records this. Crucially, it does not itself run tx₁ … tx₉₉₉ to check the claim — that’s the whole point; re-executing on L1 is exactly the cost we refused to pay. Instead, the validity of the 0xOLD → 0xNEW claim is enforced by a proof mechanism, and which mechanism you pick is the great fork in rollup design, covered next page in Optimistic vs ZK rollups. For now, hold this: the batch posts a claim, and there is some mechanism by which a false claim can be rejected.

The three roles

A rollup has three parties. Understanding who can do what — and, more importantly, who you are not forced to trust — is the whole security story.

The sequencer: orders and executes

The sequencer is the operator’s server. It receives L2 transactions from users, decides their order, runs them through the L2’s EVM, and periodically publishes batches to L1. It is fast because it’s (usually) a single machine — no global consensus round per block — which is precisely why L2 transactions confirm in milliseconds and cost a fraction of L1.

This centralization sounds alarming, and it is a real limitation — a single sequencer can censor you (refuse to include your transaction) or reorder transactions for profit (MEV). But note the two things it fundamentally cannot do, because of how the other two roles are constructed:

It cannot steal your funds, because the funds live in an L1 contract that only releases them per rules the sequencer doesn’t control.
It cannot forge state, because a false 0xOLD → 0xNEW claim is rejectable by the proof mechanism, and because the raw data is public so anyone can check.

A dishonest sequencer is an annoyance (censorship, delay), not a theft. Getting that distinction into the architecture is the entire craft of rollup design.

The L1 contract: holds funds and the canonical root

On Ethereum sits the rollup’s bridge/verifier contract. It is the source of truth, and it does three jobs:

Custody. When you deposit ETH into the rollup, you send it to this contract on L1. Your L2 balance is just a bookkeeping entry that says “the contract owes me this.” The real coins never left Ethereum.
Canonical state root. The contract stores the current accepted L2 state root. A new batch updates it only if the batch’s claim survives the proof mechanism.
Withdrawal enforcement. To exit the rollup, you prove against this stored root that you own an L2 balance, and the contract releases the corresponding L1 funds.

Because this contract is an ordinary Ethereum smart contract, it inherits all of Ethereum’s security: the same validators, the same finality, the same censorship resistance. That inheritance is the reason a rollup can be a real L2 and not just a faster database.

The user: can force-exit

Here is the role that turns the whole thing from “trust me” into “verify me.” A user must be able to get their funds out even if the sequencer disappears, goes rogue, or tries to censor them — with no cooperation from the operator.

Two mechanisms make this real:

Forced inclusion. Rollups expose an L1 path to submit an L2 transaction directly through the L1 contract, bypassing the sequencer. If the sequencer ignores you, you drop your transaction into an L1 inbox the sequencer is contractually obliged to eventually process — or the chain is considered stalled and other escape hatches open.
The escape hatch / force-exit. In the worst case (sequencer permanently gone), the design lets a user prove their L2 balance directly against the canonical root stored on L1 and withdraw, without the operator ever signing anything.

   Normal path:   user → sequencer → batch → L1   (fast, cheap)

   Sequencer censors or vanishes:
                  user ─────────────────────► L1 contract
                     "here is my tx / here is my balance proof"
                  L1 processes it or lets me exit — no operator needed

If this force-exit path exists and works, the sequencer’s power is bounded: the worst it can do is make you wait and pay L1 gas to leave. If it does not exist, the operator can hold your funds hostage — and then you don’t have a rollup, you have a custodian with extra steps.

The litmus test for a real L2

We can now state the single question that separates a genuine rollup from an impersonator, and it is the book’s throughline made concrete:

If the operator cheats or disappears, can I recover my funds by appealing to Ethereum alone — without trusting the operator?

If yes, you have real L2 security: the rollup inherits Ethereum’s guarantees, because your ultimate recourse is an L1 contract backed by every Ethereum validator. If no, you have a system that merely looks like a rollup but is trust-based underneath — however fast and cheap it is.

Two ingredients make the answer “yes,” and both are non-negotiable:

The state claim must be enforceable on L1 — via a fraud proof or a validity proof — so a false 0xOLD → 0xNEW cannot become canonical.
The data must be available — published somewhere anyone can read — so that you (or a watcher acting for you) can reconstruct the true state and build the proof you’d need to exit. A proof mechanism you can’t feed data to is a lock with no key.

Miss either one and the litmus test fails. This is why the next several pages of this part — proofs, then data availability, then EIP-4844 blobs — are not side details. They are the two legs the security stands on.

Rollups vs sidechains vs validiums

The same litmus test cleanly sorts the family of “L2-ish” designs. The dividing questions are: where does the transaction data live? and whose security do you inherit?

System	Executes off-chain?	Tx data posted to Ethereum?	Security you inherit	Can you exit without the operator?
L1	no (on-chain)	n/a — it is the chain	Ethereum, fully	n/a
Rollup	yes	yes (compressed)	Ethereum (data + proof on L1)	yes
Validium	yes	no (kept off-chain)	Ethereum for validity only	only if the off-chain data is served
Sidechain	yes (own chain)	no	its own validators, not Ethereum	no — you trust its bridge

Read the table as a gradient of trust:

A sidechain (e.g. a chain with its own proof-of-stake validator set, bridged to Ethereum) has its own security entirely. Its bridge holds your L1 funds, and the sidechain’s own validators decide who gets them. If they collude or get hacked, your Ethereum-side funds can be drained. It is a separate chain you bridge to — the exact thing a rollup is defined against.
A validium keeps execution honest with a validity proof posted to L1 (so state can’t be forged) but stores the transaction data off-chain, with a committee. This makes it cheaper than a rollup, but it re-introduces a trust assumption at the weak leg: if that committee withholds the data, you can no longer construct your exit proof, and your funds can be frozen (not stolen, but stuck). Validity without availability is only half the guarantee.
A rollup posts both the enforceable state claim and the data to Ethereum. That is why it, and only it, passes the litmus test with no extra trust assumptions.

The one-line taxonomy: a rollup is the design that puts both legs — proof and data — on Ethereum. Move either leg off-chain and you’ve traded down to a validium or a sidechain.

Why this is cheaper than doing everything on L1

It’s worth being precise about where the savings come from, because it’s not magic and it’s not free — it’s a specific reallocation of work.

A monolithic L1 pays, per transaction, for execution (every node runs apply), storage (every node keeps the result), and consensus (every node agrees on the order). A rollup removes the first two costs from Ethereum’s shoulders and keeps only a slimmed-down version of the third:

Execution moves off-chain. L1 nodes never run the L2’s thousand transactions. They run one cheap contract call that records a batch. The heavy EVM work happens once, on the sequencer, instead of thousands of times across the L1 network.
You post data, not computation. Ethereum’s job shrinks to storing bytes and ordering them — no re-execution. Storing a byte is vastly cheaper than executing a transaction that touches storage.
Compression squeezes the bytes. Because you’re now paying for data rather than computation, shrinking the data directly shrinks the bill. Rollups aggressively compress: drop signatures that a validity proof already vouches for, replace addresses with short indices, use default-heavy encodings, and amortize per-batch overhead over thousands of transactions.

   On L1, per tx:   [ execute ]·N nodes  +  [ store ]·N nodes  +  [ order ]
   On a rollup:     [ execute ]·1 (sequencer)  +  L1 stores COMPRESSED data + 1 root
                    └── amortized over the whole batch ──┘

The saving is roughly the batch size times the compression ratio: a thousand transactions share the fixed L1 cost of one batch post, and each contributes only its compressed data footprint rather than its full execution-and-storage cost. That is the entire economic engine of the rollup pattern — and it also tells you the remaining bottleneck is the cost of the data on L1, which is exactly what EIP-4844 blobs attacks.

After a rollup executes off-chain, its dominant on-chain cost is the L1 space its compressed data consumes. A rough decomposition of an L2 transaction fee:

   L2 execution (sequencer compute)     ── tiny, off-chain, ~free to you
   L2 data footprint on L1              ── the DOMINANT cost
   share of batch's fixed L1 overhead   ── amortized ÷ (txs per batch)

   fee ≈  L2_exec  +  (your_compressed_bytes × L1_data_price)
                    +  (batch_L1_overhead ÷ txs_in_batch)

Two levers therefore drive L2 fees down: bigger batches (spread the fixed overhead over more transactions) and cheaper L1 data (lower the price per byte). EIP-4844’s blobs pulled the second lever hard; after the Dencun upgrade on 13 March 2024, typical fees on major rollups fell substantially — in the period following the upgrade, often to well under a cent (as of this writing, 2024). Exact figures move with L1 congestion and blob demand, so treat any single number as a snapshot, not a constant.

Under the hood — the deposit / withdraw round trip

Following a single ETH through a rollup makes the roles click into place.

   DEPOSIT
   1. You call deposit() on the L1 bridge contract, sending 1 ETH.
   2. The 1 ETH now sits in the L1 contract — it never leaves Ethereum.
   3. The sequencer sees the deposit and credits your L2 account (+1 ETH).
      Your L2 balance is a claim: "the L1 contract owes me 1 ETH."

   USE
   4. You transact freely on L2 — fast, cheap. Batches post to L1 as you go,
      each advancing the canonical root the L1 contract stores.

   WITHDRAW
   5. You submit an L2 withdrawal; it lands in a batch; L1's root now reflects
      "this account is owed 1 ETH on L1."
   6. You prove, against that L1-stored root, that you hold the withdrawal.
   7. The L1 contract releases 1 ETH to you.

The withdrawal step is where the proof mechanism gates you: on an optimistic rollup you wait out a challenge window before step 7; on a ZK rollup a validity proof lets the contract release sooner. Either way, notice what step 6 requires — the data behind the batch must be available for you to build the proof. The round trip is the litmus test in motion: at no point did you need the sequencer’s permission to get your ETH back.

The architect’s lens

The rollup is a deliberate division of labor between two layers — interrogate it before you chase a TPS headline.

Why does it exist? Because the trilemma says a single chain can’t scale execution without shedding decentralization — so rollups move execution off Ethereum while keeping Ethereum as the settlement and data-availability backstop.
What problem does it solve? Cheap, high-throughput transactions that still inherit Ethereum’s security: a user who is cheated or censored can force-exit to L1 and recover funds without trusting the operator. It attacks the trilemma by splitting execution (off-chain) from settlement (on-chain).
What are the trade-offs? A (usually) centralized sequencer can censor or extract MEV; withdrawals can be slow (a challenge window) or proof-heavy (ZK); and the whole guarantee leans on data availability — publish the data or the exit proof can’t be built.
When should I avoid it? When you’re willing to trust an operator or a validator set for lower cost — a sidechain or validium is cheaper but fails the litmus test; and for tiny, self-contained apps the bridging round trip and exit latency may not be worth it.
What breaks if I remove it? Ethereum is forced to scale execution on L1 itself — bigger blocks, heavier nodes, fewer independent verifiers — reintroducing exactly the centralization the rollup-centric roadmap exports off-chain to avoid.

Check your understanding

In one sentence, what does a rollup post to L1 in each batch, and which of those two things does Ethereum re-execute?
The sequencer is (usually) a single centralized machine. Name two things it can do to you and two things it cannot — and explain why the “cannot” list holds.
State the litmus test for a genuine L2, and name the two ingredients that must both be present for the answer to be “yes.”
A validium uses a validity proof (so state can’t be forged) but keeps transaction data off-chain. Why does it still fail the litmus test, and what specifically can go wrong for a user?
Explain precisely why a rollup transaction is cheaper than the same transaction on L1. Which cost is removed from Ethereum entirely, and which cost becomes the new dominant one?

Show answers

Each batch posts compressed transaction data plus a state-root commitment (a claim root_before → root_after). Ethereum re-executes neither — it stores the data and records the root claim; the claim’s validity is enforced by a fraud or validity proof, not by L1 re-running the transactions.
Can: censor you (refuse to include your tx) and reorder transactions for MEV. Cannot: steal your funds or forge state. It can’t steal because the funds sit in an L1 contract it doesn’t control, which releases them only per fixed rules; it can’t forge because a false root claim is rejectable by the proof mechanism and the raw data is public, so anyone can check the true state.
The test: if the operator cheats or disappears, can I recover my funds by appealing to Ethereum alone, without trusting the operator? The two required ingredients are (a) an enforceable state claim on L1 (fraud or validity proof), and (b) data availability — the transaction data must be published so you can reconstruct state and build your exit proof.
Because it satisfies only one of the two legs. The validity proof secures correctness, but keeping data off-chain (with a committee) means that if the committee withholds the data, a user can no longer construct the proof needed to exit. Funds aren’t stolen, but they can be frozen — validity without availability is only half the guarantee, so it fails the test.
On L1 every node executes and stores each transaction, plus orders it. A rollup removes execution from Ethereum entirely (it happens once on the sequencer, not N times across L1) and posts only data rather than computation. Ethereum’s remaining job — storing and ordering compressed bytes — is far cheaper, so the new dominant cost is the L2’s data footprint on L1, which compression and cheaper blobspace then attack.