Rollups

A rollup collects many user transactions, orders and executes them in a separate environment, compresses the result, and posts data or commitments to a base chain such as Ethereum. The base layer does not re-execute every rollup transaction in the ordinary path, which allows more user activity per unit of base-chain block space.

The rollup's security depends on how the base chain can verify or challenge the claimed state transition.

Users submit transactions to a sequencer or ordering service. The rollup executes the batch and computes a new state root. A bridge contract on the base layer tracks deposits, withdrawals, and accepted rollup state. An optimistic rollup exposes claims to a challenge process; a ZK rollup submits a validity proof.

These components are separate trust surfaces. A decentralized proof system can still be paired with a centralized sequencer or upgrade key.

Independent parties need enough published data to reconstruct rollup state, detect invalid optimistic claims, or recover user balances. If the operator holds the only copy, users can become dependent on that operator even when the base-chain contract remains live.

Data availability is therefore part of rollup security, not an optional archival feature.

When users deposit assets, a base-chain bridge locks or records those assets while the rollup credits corresponding balances. Withdrawals reverse the process after the rollup's proof or challenge rules are satisfied. A flaw in bridge accounting, message verification, or upgrade authority can put all bridged value at risk.

Rollup analysis therefore starts with the bridge contract and proof assumptions, not only the transaction fee.

Base-layer validators do less application execution per user transaction, but the system must publish data, verify proofs or disputes, run sequencer infrastructure, and manage bridges. Latency can differ between transaction acceptance and base-layer finality.

Scaling is achieved by changing where work happens and how correctness is proven, not by making computation free.

A rollup moves much transaction execution away from the base chain while using the base chain for settlement, data publication, dispute handling, or proof verification. The rollup operator or sequencer batches many transactions, computes a new rollup state, and posts enough information to the base layer for the protocol's security model.

The critical distinction is how correctness is established. Optimistic rollups initially accept state-transition claims and rely on a challenge mechanism to detect fraud. Zero-knowledge or validity rollups submit a cryptographic proof that the stated transition satisfies a defined computation.

Neither model means “the base chain does everything.” The base chain verifies specific claims under the rollup contract and data rules. Users also depend on bridge logic, data availability, sequencer behavior, upgrade mechanisms, and the correctness of the rollup implementation.

Compression is a major source of scaling. The rollup can aggregate many user actions into less base-layer data and less base-layer execution than processing each action directly. But the design still consumes scarce base-layer resources, especially data publication.

When evaluating a rollup, separate execution, data availability, settlement, sequencing, proof generation, and bridging. The word “inherits security” is only meaningful after specifying which risks actually inherit base-layer guarantees and which remain rollup-specific.

1. What work does a rollup move away from base-layer execution?

2. Compare optimistic correctness proofs with validity proofs.

3. Why does a rollup still need data-availability design?

4. Name three rollup-specific risks that may remain even if the base chain is secure.

5. How does transaction compression contribute to scaling?

6. Correct this statement: “A rollup automatically has exactly the same security properties as its base chain.”