The scaling trilemma in practice
Base-layer blocks are deliberately small so ordinary machines can validate them, which caps throughput and keeps fees volatile under load. Layer 2s move execution off the base chain while still deriving their security from it, trading some of the base layer's guarantees for far more capacity.
- •L1 stays the settlement and data-availability anchor.
- •L2 executes transactions and posts compressed results back to L1.
- •Users get lower fees and faster confirmations without a new trust root.
Optimistic rollups
An optimistic rollup assumes batches are valid by default and posts them to L1 with a challenge window, typically about seven days. Anyone can submit a fraud proof during that window to revert an invalid batch, so the rollup only needs one honest watcher, not a majority.
- •Fast to build: near-EVM-equivalent execution (Arbitrum, Optimism).
- •Withdrawals to L1 are slow because they wait out the challenge window.
- •Fraud proofs are rarely used but must remain crediblely enforceable.
Zero-knowledge rollups
A ZK rollup generates a validity proof — a succinct cryptographic proof that the batch's state transition was computed correctly — and posts it alongside the new state root. L1 verifies the proof in one call, so there is no challenge window and withdrawals can finalize as soon as the proof lands.
- •SNARK/STARK proofs are cheap to verify even though they are expensive to generate.
- •Correctness is proven mathematically, not assumed and disputed.
- •zkEVMs aim for Solidity compatibility while proving EVM execution.
Data availability and bridging
A rollup is only as trustless as the data behind it: if transaction data isn't published somewhere retrievable, users cannot reconstruct their balances if the operator disappears. Rollups post calldata or use dedicated data-availability layers for this reason. Moving assets between L1 and L2 uses bridge contracts, which are a common target for exploits — canonical bridges audited alongside the rollup are safer than third-party ones.