A validity-proof rollup executes transactions outside its base layer, computes a proposed state transition, and submits a cryptographic proof of that transition for a base-layer verifier to check. If the verifier accepts the proof under the system’s rules, the proposed transition can update the rollup’s canonical state. This establishes a bounded claim about transition validity—not that transaction data is private, available for reconstruction, or covered by every other security property readers may care about. source

What zkp rollups prove—and what the proof does not establish

A state transition is a change from one recorded system state to another. In a validity rollup, a proof supports the claim that a proposed offchain transition satisfies the rules being checked by the rollup’s proof and verifier system. A base-layer verifier contract accepts the proposed transition after accepting its cryptographic validity proof. The proof is therefore about the validity of a specified transition, not a general certificate that every component or operation in the rollup is correct. source

The word “zero-knowledge” should not be taken to mean that every rollup hides its transaction data. In one privacy-application pattern, private witness data and offchain proof generation are separated from a public commitment and an onchain verifier. That describes a possible privacy architecture; it does not show that all rollups use it or that a rollup’s transactions are confidential. Whether transaction details are public or private must be checked in the particular system’s documentation. source

Proof validity is also distinct from data availability. A proof’s acceptance addresses whether the transition satisfies the rules covered by the proof. It does not, by itself, establish that users or other participants can obtain the information needed to reconstruct the resulting state. Nor does the proof alone establish what data was published, how long it can be retrieved, or what recovery process applies. These are separate design questions.

From submitted transactions to a new rollup state

The lifecycle begins when a user or application submits a transaction for the rollup to process. A sequencer is a component or role that arranges transactions into an order for processing. Sequencing arrangements can vary, so the general validity-proof model does not establish who receives submissions, who determines their order, or whether a particular deployment has one or more sequencing components. Those details need to come from the implementation’s technical documentation.

The rollup’s execution environment then applies the ordered transactions according to its rules and computes the resulting state transition. Execution is the step that determines what the transactions do to the rollup’s recorded state. The proof does not replace that computation: it is evidence used later to check the proposed result against the system’s rules. The exact execution environment, rules, and division of responsibilities are specific to the deployment.

The system organizes relevant transaction activity and resulting state changes into material for proof generation and settlement. In a validity rollup, execution and state storage occur off the base layer while state-change summaries and cryptographic validity proofs are submitted to Ethereum. source This is an architectural description, not a guarantee that every implementation uses the same batch format, submits identical data, or follows one timing schedule.

At this point, it is useful to distinguish the transaction record from the state update. Transactions describe the operations submitted for processing; the proposed state update describes their claimed effect under the rollup’s rules. The implementation determines which inputs and summaries are included in its proof process and which information is published for settlement or other purposes. A reader should not infer those contents merely from the label “zkp rollup.”

How proof generation and base-layer verification fit together

A prover generates a cryptographic proof for the proposed state transition. The proof is intended to let the system’s verifier check that the transition follows the rules represented in that proof system. The prover and verifier therefore have distinct roles: one produces the evidence; the other checks it. The specific proof construction, verifier implementation, and assumptions behind them are implementation-dependent. The available general evidence does not establish particular proving times, costs, or cryptographic assumptions.

The proof and proposed state update reach the base layer through the rollup’s settlement mechanism. For a validity rollup, a base-layer verifier contract accepts the proposed offchain state transition after accepting its validity proof. source In practical terms, this check lets the base layer accept a state update according to the verifier and the system’s protocol rules. It does not mean that the base layer re-executes every off-layer transaction, nor does it establish that all surrounding contracts or operational arrangements are error-free.

The verifier’s acceptance is also not a universal statement about finality. The evidence supports the verifier’s role in accepting a proposed transition, but does not define one settlement or finality rule for every rollup. To understand what acceptance means in a particular deployment, consult its protocol documentation for proof submission, settlement conditions, state updates, and any later changes to the accepted record.

Proof validity and data availability are separate requirements

A validity proof answers a correctness question: does the proposed state transition satisfy the rules the proof and verifier check? Data availability answers an access question: can participants obtain the information needed to reconstruct or continue from the rollup state? These questions are related in operation but are not interchangeable. Proof acceptance alone does not provide the underlying transaction information or establish that it can be retrieved. source

The rollup architecture described in the evidence submits state-change summaries and validity proofs to Ethereum, while execution and state storage occur offchain. source That description does not specify the data-publication arrangement of every implementation. In particular, it should not be expanded into a claim that all transaction data is posted to the base layer or that every user can reconstruct state in the same way.

This distinction matters when evaluating state recovery or a possible exit from the rollup. If the information needed to reconstruct state is unavailable, proof validity alone does not answer how participants can proceed. The evidence here does not establish specific availability guarantees, user exit routes, or recovery procedures for a named system. Those require direct documentation for that deployment, including what data is published and what mechanisms are defined for users.

Design tradeoffs to assess in a specific rollup

A technical review should first establish the scope of the proof claim. Identify what transition the proof covers, which rules it represents, and which base-layer contract verifies it. Then examine the proof system and verifier implementation in the deployment’s primary technical materials. The general validity-proof description does not establish that a particular proof system or verifier is free of flaws, or that its assumptions are appropriate for every use.

Next, trace the operating roles from submission through settlement. Find out who can sequence transactions, who executes them, who generates proofs, and which component submits the proof and proposed state update. Do not assume these roles are independent or distributed in a particular way: the available evidence gives the lifecycle’s broad structure, not an implementation’s operator arrangement.

Then review what information is published and what participants can retrieve. Ask which data supports reconstruction, where it is made available, and what the documentation says about recovery if a relevant component does not provide it. Proof validity and data availability must be assessed separately; evidence for one does not substitute for evidence for the other.

Finally, check the deployment’s documented settlement rules, upgrade controls, and user exit or recovery procedures. The general validity-proof architecture does not establish those implementation-specific features. Keep protocol behavior distinct from responsibilities assigned to operators, applications, contracts, or users, and treat undocumented conditions as unresolved rather than filling them in from the rollup label. This approach keeps the central distinction clear: the proof helps a base layer check a proposed state transition, while other design choices determine the data and operational conditions surrounding that accepted transition.

Sources and references