A layer 2 rollup executes transactions outside a base blockchain and uses that chain for data availability and settlement. An Ethereum rollup can share the cost of publishing data across many transactions. For a trading desk, the fee to trade on layer 2 (L2) and the time until withdrawn collateral is spendable on Ethereum (L1) are separate inputs. Ethereum's optimistic rollup guide · Ethereum's validity rollup guide
What Ethereum receives
A sequencer typically orders transactions for L2 execution. A batch groups transactions, sometimes across several L2 blocks, for publication. The rollup also commits to a proposed result, typically through a state root, a cryptographic fingerprint of the resulting balances and contract state. The commitments and the batch data can arrive on Ethereum in separate transactions. Optimism's transaction finality guide · ZKsync transaction lifecycle
The root identifies a particular state. To recover that state independently, nodes also need the underlying data. OP Mainnet publishes compressed transaction data that nodes can replay with the rollup rules and prior state. In the ZKsync Era design, nodes can instead apply published state diffs (changes to storage), with supporting data such as new contract bytecode. Either design relies on data availability through Ethereum. Ethereum's data availability guide · ZKsync's state reconstruction guide
Sharing one batch's data cost
Suppose publishing the data for a fictional batch of 100 transactions costs 0.02 ETH. Under equal allocation, each transaction accounts for the following share.
That is an accounting allocation of the L1 data expense. The user's bill follows the network's fee schedule, which may account for how much data a transaction contributes and charge separately for L2 execution or other components. OP Mainnet's fee documentation
Batch publication shares a data cost across transactions. Ethereum consensus finality and canonical bridge release follow different rules. The arrows show dependencies, with no time scale.
When can collateral leave the rollup?
In an optimistic rollup, a proposed result can stand if it survives the dispute process. A challenger can recompute the result from available data and contest an invalid claim through a fault-proof system. This design depends on someone able and willing to raise a valid challenge in time. In a validity rollup, often called a ZK rollup, an Ethereum verifier contract checks a cryptographic proof of the state transition before the result can be accepted. Time to generate and submit the proof and any protocol execution delay still matter. Ethereum's fault-proof overview · Ethereum's validity proof overview · ZKsync's execution delay
A sequencer receipt gives an early L2 confirmation. Ethereum inclusion of the batch data is a later event, and L1 finality of that inclusion comes later still. On OP Mainnet, Optimism documents a typical 15–30 minutes from submission until Ethereum finalises the transaction's data. Withdrawals through its Standard Bridge have a separate seven-day wait. The withdrawal claim must meet the dispute and proof-maturity rules, and an L1 transaction must execute the release. OP Mainnet's finality guide · Optimism Portal specification
A desk can record the L2 balance and pending withdrawal separately from collateral already released on Ethereum. The release also depends on the bridge and verification contracts, including any governance authority that can upgrade them or pause withdrawals. An earlier payout from a third-party bridge depends on that bridge's liquidity and contracts. Optimism's privileged roles · Ethereum's guide to rollup exits
Sources
- Ethereum developer documentation on optimistic rollups, validity rollups and data availability.
- Optimism's guides to transaction finality, OP Mainnet finality, transaction fees and privileged roles, and the Optimism Portal specification.
- ZKsync documentation on state reconstruction, the transaction lifecycle and the execution delay.