Loading article...
Rollups execute transactions off chain and post data to Ethereum for security. Learn how optimistic and ZK rollups work, their trade-offs, and how to choose and use them.
Rollups are Ethereum's main scaling method today. A rollup runs transactions off chain, then posts the data to Ethereum. Ethereum checks the data and holds the canonical state. You get higher throughput and lower fees, with security tied to Ethereum.
A rollup is a separate chain that settles on Ethereum. It executes transactions on its own virtual machine. It batches those transactions, compresses them, and publishes the data to Ethereum. Ethereum stores the batch, tracks the rollup's state root, and enforces the rules for withdrawals and disputes.
If the rollup fails or an operator disappears, anyone can rebuild the rollup state from the data on Ethereum. That is what separates a rollup from a sidechain or a validium, which keep data elsewhere and do not inherit the same guarantees.
If you only use Ethereum mainnet today, this guide helps you know when to move to a rollup and which type fits your use case.
All rollups share the same basic flow. The difference is how Ethereum decides a state update is valid.
After step 6, Ethereum considers the state update settled. Bridges then use that settled root to complete deposits and withdrawals.
Ethereum provides two guarantees for rollups:
EIP-4844 is Proto-Danksharding. It went live with the Dencun upgrade on March 13, 2024. It added the blob transaction type and a separate blob fee market. More than 90 percent of rollup cost before the upgrade came from posting data. Research on the first 180,000 blocks before and after Dencun measured a 71 percent drop in total fees paid by rollups and a 54 percent drop in gas used for data posting, with total data posted rising as rollups posted more often. Optimistic rollups shifted more sharply to blobs than ZK-rollups, because ZK batches still include proof verification data that must stay in calldata.
The change is not the end state. The next step is full Danksharding with data availability sampling (DAS) and proposer-builder separation (PBS). The Ethereum roadmap describes it as a further 100 to 1000x scale up in blob space, with the goal of sub-cent transactions across many rollups. Work is in progress.
Optimistic rollups assume a batch is valid unless someone proves it is not. The model is often called innocent until proven guilty.
During the challenge window, anyone can keep building on top of an unconfirmed root, but those later blocks can be reverted if their parent is found invalid.
Older single-round designs required re-executing the whole disputed transaction on L1 and publishing per-transaction state commitments, which was gas heavy. Multi-round bisection reduces on chain work to one step and avoids publishing intermediate commitments for every transaction.
The security assumption is one honest validator. You need at least one party watching the posted data, willing to pay gas to challenge, and able to get its challenge transaction included on Ethereum within the window. If no one watches, an invalid root can finalize. That is why operators must stake a bond, for example Optimism documents a suggested 0.08 ETH initial bond per FaultDisputeGame and roughly 14 ETH locked if you propose hourly across a 7 day window, and Arbitrum One requires a one-time 3600 WETH stake to join as a validator under BoLD.
ZK-rollups prove validity up front with cryptography. The model is guilty until proven valid.
Two proof systems are in production:
Both systems share a property: the L1 verifier can confirm correctness without re-running every transaction.
Each offers a different point on the zkEVM spectrum. Polygon zkEVM, Scroll, and Linea aim for EVM equivalence or close to it. Taiko positions as a Type 1 zkEVM that aims to match Ethereum's execution exactly. All verify validity proofs on Ethereum before accepting state.
Proving simple transfers is straightforward. Proving arbitrary EVM execution is hard. The EVM has many opcodes, gas rules, and state touches in memory, stack, and storage. A zkEVM must recreate that logic inside a circuit and prove each step correctly. That is why full EVM support came later for ZK-rollups than for optimistic rollups, and why prover costs remain the main trade-off.
| Feature | Optimistic rollups | ZK-rollups |
|---|---|---|
| Validation method | Fraud proofs during a challenge window. State accepted unless a valid challenge proves fraud. | Validity proofs verified on L1 before state is accepted. |
| Challenge period | Yes. Typically about 7 days on OP Stack chains, 6.4 days on Arbitrum One under BoLD. | No challenge period. Finality follows proof verification and L1 confirmation. |
| Withdrawal through the canonical bridge | About 7 days. Fast liquidity bridges exist but charge a fee and add their own trust assumptions. | No 7 day wait. Users still wait for batch inclusion, proof generation, and L1 confirmation, often minutes to a few hours. |
| Security model | Cryptoeconomic. Needs at least one honest watcher and bonded sequencer. Misbehavior is penalized by slashing. | Cryptographic. Math guarantees the state transition is valid if the verifier contract accepts the proof. |
| EVM compatibility | High today. Most contracts deploy with little or no change. | Improving fast. zkEVMs now support most Solidity contracts, but edge cases and gas differences remain. Check your specific rollup. |
| Proving cost | Low. Fraud proof computation is done by ordinary nodes. | High. Provers need specialized hardware, often GPUs, and the work is done by a small set of operators today. |
| Data posted to L1 | Full batch data must be on L1 for challengers to check. | Also posts data for reconstruction, but can use stronger compression since validity does not depend on re-execution. |
| Examples | Arbitrum One, OP Mainnet, Base | zkSync Era, Starknet, Polygon zkEVM, Scroll, Linea |
Fees.
On Ethereum's scaling page, rollups are described as roughly 5 to 20 times cheaper than L1 today, with ZK designs aiming for 40 to 100 times cheaper as compression improves and blob space grows. Your actual fee includes three parts: the L1 data cost (blob or calldata), the rollup execution fee, and for ZK the cost to generate and verify the proof spread across the batch. Large batches amortize cost, but posting small batches often can raise your cost. Finality for your use case.
If you need to exit to L1 through the canonical bridge, optimistic means a week of waiting. That matters for treasury rebalancing or for apps that must unwind on L1 quickly. Validiums and sidechains offer faster exits but give up Ethereum data availability. Third party bridges that front you the funds on L1 are useful, but they rely on liquidity providers and introduce counterparty risk. EVM fit.
For a direct lift of an existing dApp, optimistic is still the fewest changes. For high volume apps where proof cost can be spread over many transactions, ZK can be cheaper per user operation at scale. Starknet's median batch in recent analysis held over 30,000 user operations, compared with about 800 for zkSync Era at that time, which illustrates how aggregation changes the economics. Hardware and decentralization.
Running a ZK prover requires high spec machines. That tends to centralize proving today. Optimistic proving is lighter, any full node can challenge with ordinary hardware. Both types still commonly run a centralized sequencer that orders transactions and can earn ordering value. Etherscan and L2Beat track which rollups have open sequencer or prover sets and which still use a permissioned allowlist or a security council that can pause or override. Censorship and liveness.
A sequencer can delay or reorder your transaction until you use force inclusion through L1. That delay costs you time, not safety, because you can still force an exit using the data on L1. If a ZK operator stalls, you can also force an exit if the rollup contract allows it. Check whether your chosen rollup has escape hatches enabled and how long they take.
**Use L2Beat and the project's docs. For general DeFi and NFTs, Arbitrum One, OP Mainnet, or Base are common. For apps that prize fast canonical withdrawals, look at zkSync Era or Starknet. 2. **Add the network to your wallet.
All of these rollups use Ethereum addresses. Add the RPC from the official docs or via chainlist. Fund it with a bridge. The canonical bridge is the safest but respects the withdrawal delay. For the first deposit, start with a small amount. 3. **Track finality.
A fast confirmation from the sequencer is not L1 finality. If you plan to bridge back to L1 soon, check the rollup explorer for batch posting status. For optimistic you will see the 7 day window, for ZK you will see when the validity proof is verified. 4. **Choose your bridge deliberately.
Canonical bridges are secured by the rollup's Ethereum contracts. Third party bridges and aggregators are faster for optimistic withdrawals but add fees and separate risk. Do not put more through them than you can afford to wait on if they pause. 5. **Watch blob fees.
After Dencun, blob base fees are the key cost lever. Explorers show pending blobs per block. High demand can raise blob fees, and Starknet notes it can fall back to calldata when blobs are expensive.
On Arbitrum and OP Stack you can usually deploy compiled Solidity with Hardhat or Foundry unchanged. Test gas and calldata use specifically. The rollup charges an L1 data fee that reflects what you publish. 2. **Adapt for ZK constraints.
On zkSync Era, Starknet, Scroll, or Linea, run the project's compiler and test suite. On Starknet you write in Cairo. On zkSync you use its zksolc path. Measure proof-related limits like maximum batch size and pubdata overhead per blob. 3. **Handle cross chain timing.
L1 to L2 messages take minutes. L2 to L1 messages from optimistic rollups take about a week via the canonical path. Do not build logic that assumes a synchronous call back. 4. **Plan for sequencer downtime.
Add a UI path that submits through L1 if the sequencer does not include a transaction. Test force inclusion on testnet so support can guide users. 5. **Audit bridge assumptions.
Keep custody logic on Ethereum. Use the rollup's official bridge contracts for high value exits. If you use a liquidity provider, bound your exposure.
Rollups inherit Ethereum security only when data is on Ethereum and the proof or fraud system is live and permissionless. Many rollups still operate with a single sequencer and a small prover set with upgrade keys held by a multisig or council that can pause the bridge. L2Beat flags these as stage 0 or stage 1 systems for a reason. This is not a flaw unique to one team, it is the staged path most teams are on. Assume sequencer control until the docs show it is decentralized, and review upgrade delays and guardian roles before you lock large value.
A second risk is cost volatility. Blob space is limited to 3 target and 6 maximum blobs per block. If many rollups compete for that space, blob fees rise. Sequencers decide between blobs and calldata based on that fee, which changes your L2 fee from block to block.
A third risk is proof system bugs. Optimistic systems depend on correct bisection and one-step logic. ZK systems depend on correct circuits and verifier contracts. Both have been audited, but both have had fixes. Keep a watch list for upgrades.
Bigger blocks need larger nodes and more specialized hardware. That reduces the number of people who can run a node and hurts decentralization. Rollups keep Ethereum's base layer small and secure while adding throughput in a separate layer that still settles on Ethereum.
A rollup publishes batch data to Ethereum and Ethereum enforces validity. A sidechain runs its own consensus and does not publish data to Ethereum, so it has separate security. A validium publishes a validity proof to Ethereum but keeps data off Ethereum, so you must trust its data holders to remain available.
To give any watcher time to post a fraud proof and get it included on Ethereum, even if the attacker tries to censor challenges. Seven days, or 6.4 days under Arbitrum BoLD, is a policy choice that balances user wait time against censorship risk. Shorter windows are possible via extra bridges, but they move the trust elsewhere.
No. They skip the 7 day challenge window, but you still wait for your transaction to be included in a batch, for the prover to generate the proof, for the proof to be verified on Ethereum, and for the bridge message to be relayed. That is usually minutes to a few hours, not seconds, and it depends on batch cadence and L1 load.
A properly operating rollup that posts data to Ethereum and enforces fraud or validity proofs is more secure than a sidechain, but it is not identical to using L1 directly. You add dependence on sequencer liveness, proof correctness, and bridge contracts. Check the rollup's stage, audit history, and upgrade mechanism.
Blobs are 128 KiB binary fields carried in type 3 transactions. They are not kept in Ethereum's execution state. Consensus nodes hold them for about 18 days, then prune. Rollup operators and indexers that need longer history must store and serve the data themselves.Which rollup should I pick today? Pick by your constraint. If you need the fewest code changes and broad tooling, use an optimistic rollup like Arbitrum One or an OP Stack chain. If you need faster canonical exits and can handle zk tooling or Cairo, use a ZK-rollup like zkSync Era or Starknet. Check current fees on an L2 fee tracker, and verify the rollup's data availability is on Ethereum, not external.
Explore more guides and career playbooks