Skip to content
Financial Context Wiki

Zero-knowledge proof

A precise guide to zero-knowledge proofs: completeness, soundness, simulation, witnesses, setup assumptions, blockchain uses and verification risks.

Updated

For educational purposes only; not investment or security advice. A valid proof guarantees only the encoded statement under the proof system’s assumptions.

Direct answer

A zero-knowledge proof (ZKP) lets a prover convince a verifier that a statement is true without revealing the secret witness used to establish it. The formal guarantee is not that the transcript contains literally no information. It is that whatever an allowed verifier learns can be simulated without the witness, apart from what follows from the public statement.

A proof system is evaluated through three separate properties: completeness, so an honest prover with a valid witness is accepted; soundness, so a false statement is accepted only with negligible probability; and zero knowledge, so the witness remains hidden under the defined threat model. Many practical systems are computational arguments: their soundness holds against computationally bounded adversaries and depends on stated cryptographic assumptions.

Zero knowledge is also distinct from succinctness and validity. A proof can be zero knowledge but expensive to verify, succinct but reveal public data, or prove a correctly encoded relation that does not match the application’s intended rule.

1
Execute

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

How it works

Start with a public statement x, a private witness w and a precisely defined relation R. The prover generates a proof, and the verifier evaluates it with public parameters or a verification key. The intended soundness claim can be summarized as:

Verify(vk, x, proof) = 1 => exists w: R(x, w) = 1

The equation says only that a suitable witness exists for the encoded relation. It does not reveal the witness, authenticate offchain inputs, or show that R captures every business rule the application meant to enforce.

  • Interactive versus non-interactive. Early ZK protocols exchange challenges and responses. Non-interactive systems package the evidence into one proof, usually relying on setup material, a random-oracle model, or both.
  • Setup model. Groth16 gives very small proofs but uses circuit-specific structured setup. PLONK-style systems can use a universal, updatable structured reference string. STARK constructions avoid structured trusted setup, while typically producing larger proofs and relying on hashes and low-degree testing.
  • Arithmetization and commitments. Implementations translate a program into algebraic constraints, commit to witness-derived values, and use randomized checks so the verifier can test the computation without redoing it or seeing the witness.
  • Proof of knowledge. Some systems additionally claim that an accepting prover knows a witness, formalized through an extractor. That is a separate property and should not be inferred from the label “zero knowledge.”

Example

Suppose x contains a commitment and a threshold of 100 units, while w contains the committed balance and blinding factor. The relation checks that the commitment opens correctly and the balance is at least 100 units. A valid zero-knowledge proof can establish that relation without disclosing the exact balance.

The result does not by itself prove that the prover owns the account, that the funds are unencumbered, or that the same commitment was not reused. Those claims require additional constraints and public inputs.

On a shielded cryptocurrency, a circuit can enforce authorization, value conservation and non-duplication while hiding selected transaction details. On a validity rollup, a proof can certify a batch state transition; the system may still publish transaction data, so “ZK rollup” does not automatically mean private transactions.

Risks

  • An incomplete or incorrect circuit can prove the wrong rule perfectly.
  • Missing domain separation, chain identifiers, roots or commitments can bind a proof to the wrong context.
  • A compromised setup or retained toxic waste can break soundness in systems that require trusted setup.
  • Bugs in the prover, verifier, transcript, curve, hash, compiler or smart contract can invalidate the theoretical guarantee.
  • Public inputs, proof timing, transaction graphs, fees and network metadata can leak information outside the formal ZK statement.
  • Side channels in witness generation, browsers, hardware or remote proving services can expose secrets before proof generation.
  • Proof verification does not provide data availability, sequencer liveness, settlement finality, censorship resistance or safe upgrades.
  • Cryptographic assumptions and concrete security margins differ across proof systems; proof size or verification speed alone is not a security ranking.

Common misconceptions

  • “Zero knowledge means no data is revealed.” The public statement and any deliberately exposed outputs remain visible, and metadata may leak outside the proof model.
  • “A valid proof means the application is correct.” It means the encoded relation accepted. Circuit, integration and policy errors remain possible.
  • “All ZK systems have the same trust assumptions.” Setup ceremonies, curves, hashes, transcript models and upgrade controls differ materially.
  • “ZK is encryption.” Encryption hides data so an authorized party may decrypt it; a ZK proof establishes a claim without sending the witness for decryption.

Sources

Navigation

Search the wiki...