How a rollup borrows Ethereum's security

The big idea: do the work elsewhere, but show it to everyone

Picture a stock exchange's trading floor. Millions of orders cross it every minute — fast, cheap, chaotic. But the floor itself proves nothing; at the close of every minute a clerk staples a photocopy of every order slip, plus the new account balances, into a fireproof public vault that the whole city can open and read. The floor is where the work happens. The vault is slow and expensive, but impossible to forge. A rollup is exactly this split: a fast execution layer does the work up top, and an incorruptible public vault — Ethereum's base layer — sits underneath, holding the evidence.

More precisely: a rollup is a layer-2 chain that executes transactions off the base chain, then posts two things back to Ethereum (L1): the transaction data, and a commitment to the resulting state (a single hash called the state root). Crucially, it does not ask L1 to re-run every transaction. It asks L1 only to store the evidence and to serve as the final judge. That one move is what lets a rollup scale.

The previous guide pinned the bottleneck: every full node re-executes every transaction, so you cannot just make blocks bigger without pushing small validators offline and eroding decentralization — the scalability trilemma. Rollups sidestep it. Move execution off-chain, keep only the data and dispute-resolution on-chain, and L1 nodes no longer re-run the rollup's transactions in the common case. You get an order of magnitude more throughput without asking each node to do an order of magnitude more compute.

Inside a rollup: the sequencer, the batch, and the L1 contract

1. You sign an L2 transaction and send it to the rollup's sequencer — not to L1. It looks and feels like sending an ordinary Ethereum transaction, just to a different endpoint.
2. The sequencer orders the incoming transactions and executes them against the current L2 state, computing the new state off-chain.
3. Periodically it bundles hundreds or thousands of transactions into a batch, compresses the data, and posts it to a smart contract on L1 — together with the new state root, its commitment to the resulting state.
4. The L1 contract records two things, permanently: the batch's data (this is the data availability) and the new state root, slotted into its ordered history.
5. The L2 state is now anchored to L1. It inherits L1's data availability and settlement, and becomes final when the underlying L1 block finalizes — subject to the validity check the next two guides cover.

// Simplified L1 rollup contract: settlement + data anchor
contract Rollup {
    bytes32[] public stateRoots;            // one commitment per batch

    // The sequencer submits a batch. The COMPRESSED transaction data is
    // passed in calldata (post-EIP-4844, in a cheaper blob) so that it is
    // PUBLISHED on L1 for everyone to read and replay.
    function submitBatch(
        bytes   calldata txData,            // <-- data availability lives here
        bytes32          newStateRoot,      // <-- commitment to the state after txData
        bytes   calldata proof              // validity proof (zk); empty for optimistic
    ) external onlySequencer {
        bytes32 prevRoot = stateRoots.length == 0
            ? GENESIS_ROOT
            : stateRoots[stateRoots.length - 1];

        // ZK-rollup:         verify now, accept only a correct transition
        //   require(verifier.verify(prevRoot, newStateRoot, txData, proof));
        // Optimistic-rollup: store optimistically; a fraud proof can revert
        //   this root during the challenge window (next guide).

        stateRoots.push(newStateRoot);
        emit BatchSubmitted(stateRoots.length - 1, newStateRoot, keccak256(txData));
    }
}

The state root is a single hash that commits to the entire L2 state — every account balance and contract slot — exactly the way Ethereum's world-state trie root commits to all of L1. The txData is the compressed list of inputs. Together they say: *here is what came in, and here is the state it produced.* Anyone holding both can check the claim for themselves.

What 'borrowing security' actually means

A sidechain runs its own validators and stands on its own security. A rollup deliberately does the opposite — instead of manufacturing its own security, it borrows three concrete guarantees from L1:

1. Data availability. Because the batch data is published on L1, it is exactly as available as Ethereum itself — no separate set of operators has to be trusted to keep it around.
2. Settlement and dispute resolution. The L1 contract is the single source of truth for the canonical state root. It verifies validity proofs or adjudicates fraud proofs, and the rollup's state is as final as the L1 block that anchors it — this is what makes L1 the rollup's settlement layer.
3. Censorship resistance and trustless exit. Even if the sequencer censors you or vanishes, you can force-include a transaction — or directly trigger a withdrawal — through the L1 contract, so you can always get your funds out.

This is the line between a true L2 and a mere sidechain. A true L2 derives its users' safety — above all, the ability to withdraw — from L1, not from a separate trust set. Seen through the trilemma, a rollup keeps L1-grade decentralization and security for the things that matter, and moves only the execution off to a faster layer.

Why data availability is the whole game

The single most important word in 'rollup' is data. A state root on its own is just a number: it records that the sequencer claims the new state is X. It does not tell you whether X is correct, and it does not tell you your own balance. Everything rests on the transaction data being published, so that anyone — not only the sequencer — can recompute the state from scratch.

Because the L2's state-transition rule is public and deterministic, the inputs (the posted transactions) plus the rule fully determine the output (the new state root). Having the data on L1 grants three powers:

1. Reconstruct. Anyone can replay the published data from the genesis block and independently rebuild the entire L2 state — no permission from the sequencer required.
2. Challenge or verify. An honest party who recomputes a different result can prove the posted root is wrong (a fraud proof), or the validity proof can be checked against the published inputs.
3. Exit. You can compute your own balance from the data and prove it to the L1 contract to withdraw — even if the sequencer is gone forever.

It also explains where a rollup's cost goes. The expensive part is not computation — it is the bytes published to L1. Compression is therefore the core craft of a rollup:

One ETH transfer, measured as bytes PUBLISHED to L1:

  As a normal L1 transaction ............... ~110 bytes
      nonce ............ ~3
      gas price ........ ~8
      gas limit ........ ~3
      to (address) ..... 21
      value ............ ~9
      signature ........ ~67

  As a compressed rollup transaction ....... ~12 bytes
      nonce ............ dropped  (read from L2 state)
      gas params ....... dropped  (shared by the whole batch)
      to ............... ~4       (an index into the state, not 20 bytes)
      value ............ ~3       (compact "scientific-notation" encoding)
      signature ........ dropped  (a zk-rollup's validity proof already
                                   attests every signature)

  ~10x smaller per transaction, and the one-time cost of opening a batch
  is split across the hundreds of transactions packed inside it.
  (Figures are illustrative, from rollup research. An optimistic rollup
   must keep signatures, so it compresses somewhat less.)

That is why the scaling story is, underneath, a data story. The next guides return to it: EIP-4844 blob transactions gave rollups a dedicated, cheap data lane on L1, and data-availability sampling plus danksharding push that frontier much further still.

Rollup vs sidechain vs validium: where the data and the security live

All three move execution off Ethereum and feel almost identical to use — fast, cheap, an account that holds tokens. They differ on two questions: where is the data, and where does security come from?

1. Sidechain (e.g. Polygon PoS, Gnosis Chain): its own consensus and its own validator set — data and security both live off Ethereum. The bridge is a trusted lock-and-mint contract guarded by the sidechain's own validators; if they collude or are hacked, the bridged funds can be lost. Fast and cheap, but you are trusting a wholly separate system.
2. Validium: posts the state commitment to L1 (so L1 still verifies correctness, usually via a zk proof) but keeps the data off-chain, held by a data-availability committee. Correctness is strong, but if the committee withholds the data you can be frozen out of your funds. A volition design lets each user choose rollup-mode or validium-mode per transaction.
3. Rollup: posts both the data and the commitment to L1. It fully inherits L1 data availability and settlement — the most secure of the three, and the most expensive, precisely because publishing the data costs L1 gas.

  data location        correctness secured by    can you always exit?      type
  ---------------------------------------------------------------------------------
  published on L1      L1 proof / fraud proof    yes                       ROLLUP
  off-chain committee  L1 validity proof         only if data is released  VALIDIUM
  the chain itself     its own validator set     only if they stay honest  SIDECHAIN

Two flavors, and the honest fine print

Every rollup must answer one question: how does L1 become convinced the posted state root is correct? There are two answers, and they define the next two guides.

1. Optimistic rollups (Arbitrum, Optimism) assume the posted root is valid and let anyone submit a fraud proof during a challenge window — typically about seven days — to overturn a lie. A single honest verifier is enough to keep the chain safe; the price is a long withdrawal delay. This is the optimistic rollup design.
2. ZK (validity) rollups require the sequencer to post a succinct validity proof that the L1 verifier checks immediately, rejecting any incorrect root outright. The reward is near-instant finality and fast withdrawals; the cost is heavy proving and the hard engineering of a zkEVM. This is the zk-rollup design.

Real rollups today are not yet the pure ideal, and it pays to know the gaps:

1. Most rollups still run a single, centralized sequencer. It cannot steal your funds, but it can reorder, censor, or go offline; forced inclusion via L1 is the backstop, and decentralizing the sequencer is active, unfinished work.
2. Many keep an admin multisig that can upgrade the contracts — and in principle change the rules. These 'training wheels' are tracked publicly by L2BEAT's Stage 0/1/2 maturity framework; check a chain's stage before trusting it with size.
3. Fraud-proof and validity-proof systems are still maturing — some chains marketed as 'optimistic' have not yet enabled permissionless fraud proofs, which means the safety net is not fully live.