Skip to content
Financial Context Wiki

Validity Proof

A verification-first guide to validity proofs, public inputs, witnesses, proof-system assumptions, rollup state transitions, data availability, finality and operational failure modes.

Updated

For educational purposes only; not investment or security advice. A validity proof is only as reliable as its statement, public-input binding, proof system, verifier, data-availability path, contracts, operators, governance and settlement chain.

Direct answer

A validity proof is cryptographic evidence that a claimed computation satisfies a precisely defined relation. A verifier checks a proof against a verification key and public inputs. In a rollup, those inputs commonly bind a previous state root, a proposed state root and commitments to a transaction batch. If verification succeeds, the settlement contract may accept the new root without re-executing every transaction.

The guarantee is narrower than “the system is correct.” It depends on sound cryptography, the intended program or circuit, correct public-input encoding, an authentic verification key and correct verifier and state-update contracts. Verification alone does not prove that users can retrieve the underlying data, that the prover will remain live, that the settlement block is final, that an upgrade is benign or that a withdrawal path works. A validity proof may use a zero-knowledge proof system, but validity does not itself imply privacy.

1
Execute

The prover executes a batch or computation and records the resulting state transition.

How it works

  1. Pin the exact deployment: L1 and L2 chain IDs, rollup version, state-update contract, verifier address and bytecode, verification-key hash, proof system, circuit or program version, data-availability mode, admin powers, pause state and settlement-finality policy. The label validity proof is not a cross-system specification.
  2. Define the proved relation before interpreting the result. In compact form, Verify(vk, x, proof) = 1 should imply that there exists a witness w for which R(x, w) = 1, subject to the proof system’s soundness assumptions. Here vk is the verification key, x is the complete public input and R is the encoded rule set. The proof proves only that relation.
  3. Reconstruct the public inputs independently. Confirm the prior root is the contract’s accepted root; derive the batch or data commitment, chain and batch identifiers, post-state root, message or withdrawal roots and protocol parameters from canonical data. A valid proof bound to the wrong chain, root, program or batch is valid for the wrong claim.
  4. Verify the proof and the contract path. Run a compatible independent verifier, then inspect the onchain call, receipt, event, accepted batch number and storage change. Confirm that the state-update contract called the intended verifier and did not bypass, mock or replace the result through an upgrade or privileged branch.
  5. Verify data availability separately. Fetch the protocol-required transaction data, state differences, blob sidecars or committee-attested data; check their commitments and reproduce the state transition or exit witness. Proof validity can coexist with unavailable data, especially where a validium or external committee keeps data offchain.
  6. Track lifecycle states separately: generated, submitted, included, proof-verified, state accepted, settlement-safe, settlement-finalized and withdrawal-complete. Measure proving backlog and costs, sequencer and prover liveness, L1 inclusion, reorganizations, bridge delays, forced inclusion and escape procedures instead of calling all states “final.”
  7. Preserve reproducible evidence: contract addresses and code hashes, verification-key and program hashes, complete public inputs, proof bytes or durable reference, batch data, verification command and software version, transaction receipt, finalized block reference and successful exit test. Re-check after every upgrade.

Worked examples

  • Batch claim. A rollup processes 8,192 transfers. Its proof binds old root R0, new root R1 and batch commitment B7. Successful verification supports the claim “there exists a witness satisfying this circuit from R0 to R1 for B7.” It does not prove that B7’s bytes are retrievable, the sequencer included every submitted transaction or R1 is already finalized.
  • Recursive aggregation. An aggregator verifies 16 child proofs inside one parent circuit and submits one parent proof. If the parent verifies, the verifier accepts the aggregation relation and its bound child commitments. Auditors must still confirm the parent circuit checks every child, the ordering and public-input mapping; proof count alone does not establish this binding.
  • Hypothetical gas ledger. Suppose direct re-execution would use 24,000,000 gas, while proof verification uses 600,000 gas and required data publication uses 180,000 gas. The proof path totals 600,000 + 180,000 = 780,000 gas, a modeled reduction of (24,000,000 - 780,000) / 24,000,000 = 96.75%. Proving hardware, aggregation, failed submissions, storage, bridge operations and data-retention costs are excluded.

Risks

  • Checking the wrong chain, deployment, batch, verifier, verification key or circuit version.
  • A sound proof system faithfully proving an incomplete or incorrect circuit.
  • Public inputs omitting or misencoding a chain ID, root, batch, message domain or protocol parameter.
  • A verifier bug, precompile bug, unsafe library or incompatible implementation.
  • Compromised setup material or violated cryptographic assumptions.
  • Upgradeable contracts or governance replacing the verifier, key, program or acceptance rule.
  • Privileged bypasses, emergency modes, pauses or allowlists weakening the advertised path.
  • Proof-generation bugs, nondeterminism or different clients deriving different witnesses.
  • Prover centralization, censorship, outage, backlog or hardware failure halting state updates.
  • Missing transaction data, state differences, blobs, preimages or archive history.
  • Treating committee signatures or a data commitment as current data retrieval.
  • Accepting a proof transaction from an unsafe, reorganized or noncanonical settlement block.
  • Treating proof acceptance as immediate withdrawal completion or economic finality.
  • Failing to reproduce the state transition, balance, message or exit witness independently.
  • Underestimating verification gas, data fees, proof latency, bridge delays or recovery costs.
  • Assuming one rollup’s proof, availability and upgrade model applies to another deployment.

Common misconceptions

  • A verified validity proof proves every implementation detail and user-visible balance is correct.
  • Every validity proof is zero-knowledge and hides transaction data.
  • Validity proofs eliminate data-availability, sequencer-liveness and censorship risks.
  • Proof verification makes the settlement transaction instantly final and withdrawable.
  • A smaller proof or faster verifier automatically means a safer or cheaper system.

Sources

Navigation

Search the wiki...