Rollups

Rollups use a data availability approach that determines how user data and state updates are published to the base chain. In optimistic rollups, there is a data availability layer that posts necessary transaction data after the optimistic period, enabling users and sequencers to reconstruct the state if needed. In ZK rollups, the proofs themselves are designed to be compact, but there is also data that must be posted to enable validators to verify proofs and recover state. The two most common strategies are: (1) publish data blobs that include all transactions in a batch, enabling anyone to recompute the state; (2) publish compressed or indexed data with on-chain commitments that reference the original transactions. Data availability is the backbone that preserves security when skipping full on-chain computation, ensuring that users can access the information required to challenge misbehavior or verify correctness.

Data availability also affects how nodes recompute state. Validators and sequencers rely on available data to reconstruct the exact sequence of transactions and verify the resulting state. If data is unavailable or incomplete, a validator cannot determine whether the rollup state is valid, which could lead to disputes or stalled finality. Therefore, robust data channels and redundancy are essential in Rollup designs. Operators may use data availability sampling techniques to reduce on-chain data load while preserving the ability to reconstruct state, balancing on-chain data with off-chain storage and retrieval.

A rollup must ensure integrity of state transitions through two levers: data availability and validity proofs (or fraud proofs). In a ZK rollup, the prover generates a cryptographic proof that the new state is correct given the old state and the batched transactions. The base chain verifies this proof without re-executing transactions, enabling high throughput with strong security guarantees. In optimistic rollups, the system trusts the batch to be valid initially and only checks correctness if someone submits a fraud proof within a designated challenge window. This model incentivizes validators to monitor batches and report misbehavior, while allowing fast initial throughput.

Security posture matters for developers choosing a rollup. ZK rollups typically require sophisticated proving systems and cryptographic assurances, which can increase development complexity but offer strong, near-instant finality. Optimistic rollups reduce proof costs but depend on economic incentives and social consensus to enforce correct behavior. Both approaches share goals: scalability, data availability, and robust security relative to the base chain. Practical deployments often balance cost, latency, and user experience, sometimes integrating bridging and sequencing layers to optimize for specific dApps.

A practical rollback to the concept of rollups involves understanding the architecture: the user interface and wallets submit transactions to a rollup smart contract on the base chain. The rollup operator or sequencer aggregates, validates, and batches these transactions off-chain, then posts data and/or proofs to the base chain. Validators on the base chain monitor the posted data or proofs and verify state transitions. For optimistic rollups, disputes are resolved via fraud proofs during a challenge period, after which the batch is finalized. For ZK rollups, the validity proof is verified on-chain; once accepted, the state update is final and requires minimal or no further on-chain disputes.

Security guarantees in rollups depend on: (a) data availability: can the data required to recompute state be accessed? (b) proof of correctness: is the state transition guaranteed to be valid? (c) dispute resolution: what mechanisms exist to challenge incorrect states? (d) economic incentives: are rewards and penalties aligned to promote honest behavior? Well-designed rollups implement redundant data channels, robust proofs, efficient dispute processes, and well-thought-out governance to align incentives.