Rollup
Layer 2 that batches transactions and settles results on a base chain.
A rollup is a layer 2 system that executes many transactions outside a base blockchain and submits batched data, state commitments, and proofs back to it. The base layer verifies the rollup's settlement rules instead of executing every transaction directly. This design can increase throughput and lower per-transaction fees while retaining defined base-layer security guarantees.
Users send transactions to the rollup, where a sequencer commonly orders them into layer 2 blocks. The system computes a new state and publishes required information to a contract on layer 1. If the rollup stops operating, available transaction data and escape mechanisms should let others reconstruct state and withdraw according to the protocol. Actual recovery paths vary and may not be fully permissionless.
Optimistic rollups assume submitted state is correct unless challenged through a fraud or fault-proof process. ZK rollups provide validity proofs that demonstrate a batch followed specified computation rules. These approaches differ in proof cost, withdrawal timing, compatibility, and operational complexity. The label alone does not reveal whether proofs, decentralized challengers, or emergency exits are live in production.
Rollups matter because base chains have limited block space. Batching spreads data and settlement costs across many users, making payments, trading, games, and social applications cheaper. Rollups can still compete for layer 1 data, so fees may rise when the base layer is congested. Some systems publish data elsewhere, which can reduce cost while introducing a separate data-availability security model.
Risks include contract bugs, compromised upgrade keys, centralized sequencers, incorrect proofs, unavailable data, bridge exploits, and censorship. A sequencer can influence ordering and may delay transactions, even if it cannot create valid withdrawals. Canonical bridges generally follow protocol settlement rules, while fast bridges use liquidity providers or separate verification assumptions. Users must evaluate each bridge independently.
Before using a rollup, verify the official network, canonical bridge, fee asset, proof status, upgrade controls, withdrawal period, and data-availability method. Developers should handle reorganizations, cross-layer message delays, RPC failures, and changing fee estimates. Rollups are not separate from layer 1 security, but neither do they inherit every guarantee automatically. Their safety depends on complete proof, data, contract, and exit designs.
Frequently asked questions
- A rollup publishes transaction data or enough information to reconstruct state, then relies on base-layer contracts to verify fraud proofs or validity proofs and enforce settlement. Users must be able to exit according to those rules. Security weakens when data is unavailable, proofs are incomplete, contracts are upgradeable by a small group, or the bridge has privileged controls.
- Optimistic rollups accept state claims unless someone proves a fault during a challenge period, which commonly delays native withdrawals. ZK rollups submit cryptographic validity proofs that the batch follows defined rules, allowing faster state confirmation after proof verification. Both batch data and depend on contracts, sequencers, software, and data availability. Their exact security and compatibility differ by implementation.
- Users may need to bridge assets, switch networks, hold a separate fee token, wait for withdrawals, and distinguish canonical bridges from faster third-party services. Fees fluctuate with base-layer data costs and batch demand. Sequencer outages can delay inclusion, while wallet or exchange support may be incomplete. Applications should explain finality, bridge routes, and recovery options before users deposit.