Optimistic rollups use fraud or fault proofs to contest incorrect state claims during a challenge process. ZK rollups require a validity proof before their settlement contract accepts a state update. The difference determines how an invalid claim is rejected. It does not by itself establish data availability, uninterrupted withdrawals, private transactions or safe upgrade authority.
Identify the claim before comparing the proof
A rollup has an execution history and a resulting state: account balances, contract storage and other information needed to process the next transaction. A state commitment is a compact cryptographic representation of that state. Accepting a commitment means accepting a particular result of applying the system's rules to particular inputs.
The relevant question is precise: starting from this accepted state, did these inputs produce this proposed next state under these execution rules? A familiar network name or a successful wallet notification cannot answer that question.
For a documented validity-proof example, ZKsync OS describes proving a transition from a known state commitment to a new one, with the pre-state and post-state bound into the proof's public inputs or their preimage. Its architecture also separates execution from proving. This is an architecture reference, not a claim that every ZKsync chain uses that implementation. ZKsync OS L1 integration.
The two broad designs place the check at different points:
| Question | Optimistic design | Validity-proof design |
|---|---|---|
| What supports a proposed state? | An assertion subject to the applicable challenge rules | A proof that the specified transition satisfies the proved rules |
| How is a wrong result stopped? | An eligible participant successfully contests it before acceptance conditions are satisfied | The verifier rejects a proof that fails its checks; an unproved update cannot pass the proof gate |
| What operational dependency matters? | A capable honest challenger must detect, submit and complete the necessary contest | A prover must produce an acceptable proof for valid progress |
| What remains to inspect? | Data, game rules, permissions, exit conditions and administrators | Data, proved program, verifier, exit conditions and administrators |
Ethereum's optimistic-rollup documentation describes the challenge model and the honest-participant assumption. An honest observer must be able to act through the actual mechanism; merely noticing an incorrect balance is insufficient. Ethereum optimistic-rollup security model.
Follow one unauthorized balance change
Consider a hypothetical two-account ledger, unrelated to any live chain. Alice owns 120 units and Bob owns 30. Alice signs one transfer of 20 units to Bob. Assume no fees, minting, burning, other accounts or other transactions. The correct result is Alice 100 and Bob 50.
An operator instead proposes Alice 100 and Bob 70. The transfer signature authorizes 20 units, but the proposed state credits Bob with 40. This is an execution error, not a dispute about whether the token's price is attractive.
| Ledger observation | Alice | Bob | Total | Assessment under the toy rules |
|---|---|---|---|---|
| Accepted starting state | 120 | 30 | 150 | Starting point |
| Correct result of the signed transfer | 100 | 50 | 150 | Valid transition |
| Operator's proposed result | 100 | 70 | 170 | Creates 20 unauthorized units |
The arithmetic is independently checkable: 120 − 20 = 100, 30 + 20 = 50, and 100 + 70 − 150 = 20 excess units. Conservation detects this particular error. It is not a complete verifier: moving 20 units to the wrong recipient could preserve the total while still violating the signed instruction.
In a real rollup, observers compare cryptographic commitments and authenticated execution inputs. They do not convince a settlement contract by uploading this table. The table isolates the wrong claim so that the security paths can be compared without hiding behind a network label.
The optimistic path needs an effective contest
Assume the incorrect commitment is proposed and all required batch data is available. An honest participant reproduces execution from the accepted starting state and obtains the correct result. The proposed commitment disagrees with that result.
That participant must use the deployed challenge mechanism, meet its permissions and financial requirements, and make the required moves within its clocks. If the participant cannot get its transactions included in time, having the correct answer locally does not complete the defense.
The OP Stack fault-proof specification illustrates how such a mechanism can avoid rerunning an entire history on Ethereum. It separates a program that derives the result from authenticated inputs, a virtual machine that can prove an instruction step, and an interactive dispute game. OP Stack fault-proof components.
Its documented Fault Dispute Game narrows disagreement over output roots and execution traces down to one instruction. The game then uses the VM to resolve that disputed step. These are properties of that specified game; other optimistic systems can use different proof mechanisms. OP Stack Fault Dispute Game.
In the hypothetical successful defense, the incorrect claim loses under the applicable rules. Rejecting it does not automatically accept a correct replacement; trace that replacement through its own acceptance conditions. If no effective challenge occurs and the design's acceptance conditions otherwise pass, the optimistic mechanism has missed the invalid claim. Counting the number of observers is less informative than establishing that at least one can actually finish the required contest.
The validity path needs a proof of the claimed result
Now submit the same incorrect result to a validity-proof design. Assume a sound proof system, a correctly implemented proved program and verifier, authenticated inputs, and no administrative bypass. Under those assumptions, the operator cannot produce an accepted proof that the signed 20-unit transfer yields Alice 100 and Bob 70.
A proof for the correct result does not authorize substituting the incorrect result: the proof must be bound to the claimed transition. If the operator submits no acceptable proof, the state update fails to cross the proof gate. Ethereum's documentation describes the verifier accepting the new root when the associated validity proof verifies. Ethereum validity-proof state updates.
This changes the failure path. An offline prover can delay valid progress without making the incorrect balance transition provable. Conversely, a defect in the verifier or in the rules being proved is a different problem from a dishonest operator failing to prove correct execution. A proof only establishes the statement its implemented system checks.
Neither design promises a beneficial trade. A correctly authorized swap with an unfavorable price can be a valid state transition. Verification of execution rules does not assess the user's economic decision.
A correct state and recoverable data are separate findings
Return to Alice's correct 100-unit balance. Knowing that a commitment represents a valid transition does not supply all the underlying data someone may need to reconstruct state or use a recovery procedure.
Inspect where the necessary data is published and how independent parties obtain it. ZKsync's data-availability documentation gives a concrete example: its rollup approach publishes state differences together with relevant logs, messages and bytecode for state reconstruction. It also distinguishes a validium configuration that keeps data off-chain and introduces additional availability risks. The proof label alone does not identify a particular chain's data arrangement. ZKsync data availability and reconstruction.
For a blob-based route, also record a historical-data retrieval or saved-state reconstruction method. EIP-4844 provides for blob data to be discarded after the required availability period, so initial publication is not proof of indefinite retrieval. EIP-4844 blob-retention model.
For the optimistic example, unavailable inputs can prevent an observer from reproducing execution and constructing the needed challenge. For the validity example, valid execution and access to recovery data remain different requirements. Record both instead of marking the network “verified” after finding one proof transaction.
Privacy is another separate property. A ZK rollup can use validity proofs while publishing public data sufficient to reconstruct its state. Ethereum's documentation explicitly describes that publication as public. Do not infer hidden balances, recipients or trading activity from “ZK” in a name. Ethereum rollup data publication.
Acceptance is only one step on the exit route
A sequencer response, data publication, accepted state claim and completed withdrawal can occur at different stages. The sequencer confirmation versus settlement guide provides the transaction-stage investigation that complements this mechanism comparison. The confirmations versus finality guide explains why an increasing block count also needs a specific settlement meaning.
Do not turn “no fraud-proof challenge window” into “instant withdrawal.” Proof production, submission, settlement-layer finality and the bridge's own release conditions still need evidence. As a specific reference design, the OP Stack's Stage One bridge-integration specification includes withdrawal proof maturity and a delay after game resolution; resolving a game is not the only release condition. OP Stack Stage One bridge integration.
A wallet can add earlier stages too. ERC-4337 defines UserOperations that bundlers package into a transaction. Use the UserOperation versus transaction distinction to check whether the request reached an included transaction before tracing that transaction into its rollup batch. A request identifier is not evidence that the settlement contract accepted the resulting state.
Administrative powers can also change the operational picture. That same Stage One specification gives a Guardian powers to pause the portal, blacklist games and change the respected game type. These specified Guardian permissions need a separate check against the actual deployment. They are not properties to assign to every optimistic chain.
For either proof family, identify who can replace settlement or verifier logic and what delays or emergency routes apply. The upgradeable-contract authority guide supplies that inspection method. A strong proof mechanism cannot answer who is permitted to change the mechanism tomorrow.
Complete a deployment-specific evidence sheet
Use one dated record for the exact network and native exit route under review. Documentation describes intended behavior; contract addresses, active configuration and on-chain records connect that description to the deployment.
| Evidence field | What to record | What an empty field leaves unresolved |
|---|---|---|
| Identity | Chain ID, settlement network, official bridge and verifier or game contracts | Whether the documents describe this route |
| State claim | Batch or block range, starting and proposed commitments, L1 transaction | Which transition is being accepted |
| Correctness mechanism | Active verifier and proof status, or game type, outcome, clocks and challenger access | Whether the claimed security check was usable and completed |
| Data availability | Publication location, required data, retention and independent retrieval or reconstruction method | Whether state can be recovered beyond an operator's RPC |
| Progress and exit | Prover/sequencer dependencies, forced routes where documented, release conditions and pauses | What happens when normal operators stop |
| Change authority | Upgrade controllers, emergency powers, applicable delays and pending changes | Whether the reviewed rules can change before an exit completes |
Classify each unresolved observation by its cause. A wrong proposed result is a correctness question. Missing reconstruction inputs are an availability question. No new proof for a valid batch is a progress question. A paused release is an exit-control question. Those findings call for different evidence.
Finish with a statement that can be checked: this exact transition is accepted by this mechanism, its recovery data is available through this route, and these authorities can change or pause the relevant contracts. Keep unknown fields visible. That record makes an optimistic-versus-ZK comparison useful for a real deployment.