A rollup scales execution by preserving a verifiable path back to settlement

A layer 2 rollup executes transactions outside its layer 1 settlement chain while publishing commitments and enough data or proof material for the base layer to enforce the protocol's rules. Lower fees and faster confirmations are product outcomes; the defining engineering question is what a user can independently verify and recover if the sequencer, prover, challenger, bridge operator or governance system fails.

Rollups separate execution, ordering, data availability and settlement. A sequencer normally gives quick preconfirmations and orders L2 transactions, but it is not the final authority. Batches and state commitments are posted to L1, whose contracts accept proofs or adjudicate disputes. Applications must expose whether a transaction is merely sequencer-accepted, included in posted data, safe relative to an L1 origin, or finally settled.

Optimistic rollups accept state assertions provisionally. A challenge window lets an honest participant dispute an invalid transition through a fault-proof protocol. Safety therefore depends on available input data, at least one capable challenger, correct dispute contracts, sufficient time and live access to L1. Withdrawals commonly wait for the challenge period because an assertion cannot safely release L1 assets while it remains disputable.

Validity rollups submit a cryptographic proof that a batch transition satisfies a circuit. L1 verification can give faster cryptographic settlement than a challenge window, but the trusted setup, circuit correctness, prover implementation, verifier contract, proof-system assumptions and data-availability mode remain part of the trust model. A valid proof of a specified computation does not prove that the specification implements the intended application rules.

Data availability is distinct from data storage and execution correctness. Independent nodes need transaction inputs to reconstruct state, detect invalid optimistic assertions, generate witnesses, serve users and recover from operator failure. Ethereum blobs reduce rollup data cost through a separate fee market and commitment scheme, but blob contents are retained only temporarily; archival and indexing systems must preserve historical product needs without implying that archives are consensus.

Batch derivation must be deterministic. Given the same finalized L1 history and protocol configuration, honest nodes should derive the same ordered L2 inputs. L1 reorganizations can invalidate recent deposits or batches, so nodes and applications track unsafe, safe and finalized heads. A sequencer preconfirmation optimizes latency but carries reorg, omission and operator-equivocation risk until stronger confirmation arrives.

Censorship resistance requires an escape path. Users should be able to submit deposits or forced transactions through L1 and eventually advance or exit without the preferred sequencer. The exact delay, cost, queue rules and failure mode matter. A nominal forced-inclusion function is weak if governance can disable it instantly, data needed for exit is unavailable, or congestion makes it economically unusable.

Bridges are protocol state machines, not ordinary token transfers. A canonical deposit locks or escrows value on one layer and creates the corresponding claim on another. Withdrawals must bind origin chain, destination, sender, target, value, payload and a unique nonce, then prove inclusion and prevent replay before releasing funds. Third-party liquidity bridges offer faster exits by adding liquidity-provider, relayer and often separate verification assumptions.

Cross-domain calls are asynchronous. The destination can execute later, fail, be replay-rejected, or observe state that changed since initiation. Applications need explicit message status, idempotent handlers, retry and compensation behavior, bounded gas assumptions and authentication of both the messenger and original sender. Synchronous composability assumptions from one chain do not survive a bridge boundary.

Fees combine L2 execution, L1 data publication and sometimes operator margin. Compression, blob demand, calldata fallback, proof cost and congestion can all change the quote. Fee estimation must state what is included and tolerate delayed batch posting. Low L2 gas usage does not mean low total settlement cost.

Compatibility is not equivalence. An EVM-like rollup can differ in opcodes, gas accounting, block attributes, precompiles, transaction ordering, finality, RPC behavior and address aliasing. Tooling and contracts must be tested against the target network and protocol version. Porting bytecode successfully is not evidence that time, randomness, bridging or failure semantics remain correct.

Centralized sequencers can improve latency and reliability while creating censorship, outage and ordering concentration. Decentralizing sequencing may reduce some control but adds consensus, networking and cross-domain complexity. Evaluate concrete powers and recovery paths rather than a marketing label or node count.

Rollup upgrades can replace bridge, proof, sequencer and state-transition logic. Admin keys, security councils, timelocks and emergency bypasses may dominate the effective security model. Users need discoverable upgrade authority, delay, scope, monitoring and exit feasibility. A contract being deployed on L1 does not make its mutable logic trustless.

Operate rollups by monitoring the entire commitment pipeline: sequencer liveness and equivocation, L1 inclusion delay, batch gaps, blob or calldata publication, derivation agreement, state-root proposals, proof or challenge progress, bridge queues, withdrawal finalization, privileged changes and RPC disagreement. Rehearse sequencer outage, L1 reorg, prover backlog, invalid assertion, bridge pause and emergency upgrade.

The production invariant is recoverability: from canonical L1 inputs and published protocol data, independent implementations can derive the accepted L2 state, contest invalid claims and let users exercise bounded exit rights. Throughput is valuable only when these properties remain measurable under failure.

Worked example: where a rollup's cost actually goes

A rollup's per-transaction cost is dominated by what it must publish to L1, not by what it executes. For a batch of 1,000 simple transfers:

Component	Optimistic rollup	ZK rollup
L1 data per tx, compressed	~12 bytes	~12 bytes
L1 blob cost per tx	~$0.0021	~$0.0021
L1 verification, amortized	~$0.00004, and only if challenged	~$0.0004, always
L2 execution	~$0.00001	~$0.00001
Proving, amortized	none	~$0.0008
Withdrawal finality	7 days	~10-60 minutes

Both designs pay roughly the same dominant line — the L1 data — because both must publish enough for anyone to reconstruct L2 state. That is why blob capacity, rather than L2 throughput, is what caps rollup economics, and why doubling L2 execution speed barely moves the fee.

The 7-day window is not a performance number. It is the fraud-proof challenge period, and it follows from the security model:

Optimistic:  the state root is assumed valid.
             Safety needs >=1 honest party watching, able to land a fraud proof, within 7 days.
             Break it by censoring the challenger's L1 transaction for 7 consecutive days.

ZK:          the state root is accepted only with a validity proof.
             Safety needs the circuit to be correct, and the setup (if any) to be sound.
             Break it by finding a soundness bug -- no liveness assumption required.

Those are different trust assumptions, not different amounts of the same one. An optimistic rollup asks for a liveness assumption about watchers; a ZK rollup asks for a correctness assumption about a circuit. "ZK is more secure" is the wrong summary. They fail in different ways, and a bridge built on either inherits whichever assumption it rests on.