Zero-Knowledge Proofs Explained: ZK-SNARKs, ZK-STARKs and Blockchain
A zero-knowledge proof is a cryptographic technique allowing a prover to convince a verifier that a statement is true without revealing the secret information supporting it, beyond what the protocol is designed to disclose. In blockchains, ZK proof systems can validate computations, demonstrate membership or support privacy-preserving applications. ZK-SNARK and ZK-STARK refer to families with different efficiency, setup and cryptographic assumptions; neither automatically makes every blockchain transaction private.
ZK technology is often marketed as synonymous with privacy, scalability and decentralisation. Those goals are related but distinct. This guide explains the role of witnesses and public inputs, the correctness properties of a proof, the importance of proving-system assumptions and how a validity rollup can use proofs even while publishing extensive transaction data.
Key takeaways
- A proof verifies a defined statement under specified cryptographic assumptions.
- Completeness, soundness and zero-knowledge are distinct properties.
- ZK-SNARKs can be succinct; some constructions require trusted setup.
- ZK-STARKs often use transparent setups and may have larger proofs.
- Validity proofs do not automatically conceal metadata, wallet identities or transaction amounts.
Prover, verifier and witness
A prover possesses a witness: information that establishes why a public statement is true under a defined relation. The verifier checks a compact proof against agreed verification rules and public inputs. A valid proof can show that a computation satisfied constraints without making the witness public. However, the amount of information revealed depends on which inputs the application deliberately exposes. A protocol could prove a private balance condition while still publishing a public wallet address.
Completeness and soundness
Completeness means an honest prover with a valid witness can produce a proof the verifier accepts, under the scheme’s stated conditions. Soundness means an adversary without a valid witness should not be able to convince the verifier of a false statement except with a negligible probability under the cryptographic model. These properties are not equivalent to security of the surrounding smart contract or business logic. A perfectly valid proof can attest to a flawed condition if developers encoded the wrong statement.
The zero-knowledge property
The zero-knowledge aspect means a verifier learns no additional secret information beyond what follows from the intended public statement and outputs under the scheme’s formal definition. It does not mean an observer can never learn who submitted the transaction, its timing or its related on-chain activity. IP addresses, funding patterns, public events and user-interface data can still reveal identity. Real privacy depends on the whole system, not a single proof primitive.
ZK-SNARK fundamentals
SNARK stands for Succinct Non-Interactive Argument of Knowledge. Succinct proofs can be relatively small and quickly checked, making them attractive when on-chain verification costs matter. However, different SNARK constructions use different mathematical assumptions and may require trusted setup ceremonies to generate public parameters. Some modern constructions reduce or alter setup requirements. It is inaccurate to say all SNARKs share one universal proving cost, setup or security trade-off.
What a trusted setup involves
Some proving systems rely on common public parameters generated from secret randomness. If toxic waste from a vulnerable setup is retained by malicious parties, the security model may be broken. Multi-party setup ceremonies attempt to reduce this trust by relying on at least one honest participant properly destroying secret inputs. A transparent setup avoids particular trusted-parameter assumptions, but may introduce different proof sizes and performance costs. Setup security is one dimension of evaluating the scheme.
ZK-STARK fundamentals
STARK stands for Scalable Transparent Argument of Knowledge. It generally emphasises transparent public-parameter generation and particular proof techniques that scale to large computations. STARK proofs can be larger than some SNARK proofs, making data publication and verification costs relevant. Prover speed, verifier speed and recursion depend on the specific implementation and computation being proven. A comparison that declares one family categorically superior on all metrics is unsound.
Proof generation versus proof verification
The prover may perform intensive computation to turn a batch of operations into a succinct mathematical proof. Verification can be much cheaper, allowing one verifier to check correctness without repeating every computational step. But the actual economics depend on proof type, hardware, batching, system design and the on-chain cost of submitting proofs and data. A low proof verification cost does not mean the application has no infrastructure or data-availability expenses.
ZK rollups and validity proofs
A ZK rollup batches transactions, executes them in its own environment and submits evidence of valid state transitions according to the settlement design. Depending on the architecture, it may use public transaction data so users can reconstruct or audit state, even though correctness is cryptographically verified. The term ‘ZK’ in this context may describe validity proofs rather than confidential transactions. Rollup security also depends on data availability, upgrade authority, bridges and settlement assumptions.
Recursive proofs and aggregation
Recursive proving combines proofs or allows a proof to verify another proof under appropriate constructions. This can reduce the size of evidence needed to attest to many calculations and support scalable verification. The design has costs in complexity, prover workload and cryptographic assumptions. A product claiming enormous throughput because of recursion should be evaluated against actual data availability, transaction submission and end-user confirmation times, not just proof size.
Privacy applications beyond transfers
Zero-knowledge systems can demonstrate age eligibility, group membership, valid credentials or correct calculations without disclosing all underlying records. But the relying party must still trust that the original credential issuer used accurate information and that the system’s public statement corresponds to the desired rule. Proofs do not magically establish real-world truth from false inputs. Privacy leaks can occur through repeated use of the same account or through correlated external observations.
Where protocol security can fail
Bugs in circuits, incorrect public inputs, faulty proving-key management and verifier-contract vulnerabilities can undermine the promises of an otherwise respected proving scheme. Upgradable components or privileged administrators can create additional trust assumptions. A formal proof of one property does not necessarily cover asset custody, bridge settlement or governance. Technical audits should inspect not only cryptographic libraries but also the application-level rules encoded into the proof.
A research framework for ZK claims
Specify precisely what statement is being proven, which data remain public, which party controls the prover and which verifier accepts the result. Record the trusted setup model, proof sizes, verification costs, hardware requirements and independent security review. For a rollup, assess data availability and exit mechanisms. For a privacy application, examine address linkage and network metadata. This disciplined analysis prevents conflating transaction validity, scalability and anonymity.
Worked example
Imagine an applicant must prove they are at least 18 without disclosing their exact date of birth. A credential can encode the date under a recognised issuer’s signature, and a ZK circuit can prove that the age threshold is satisfied at a chosen date while hiding the birth date, provided the implementation meets its security model. The verifier still has to trust that the issuer authenticated the date correctly.
Suppose a rollup processes a batch of 10,000 account updates and generates a proof verifying that every update followed the agreed state-transition rules. A settlement contract could validate the proof without independently executing all 10,000 updates. That does not mean users’ transfers are hidden; public transaction data and accessible account links may remain visible. It also does not guarantee those accounts cannot be frozen through a separate bridge or governance rule.
Professional comparison table
| Property | Typical SNARK family | Typical STARK family |
|---|---|---|
| Proof size | Often compact | Often larger |
| Setup | Construction-specific; may need trusted setup | Typically transparent |
| Verification | Designed for efficient checking | Can have higher proof verification overhead |
| Main use | Validity, privacy, aggregation | Scalable validity computations |
| Automatic financial privacy? | No | No |
Research and risk checklist
Start with official specification and audited implementation. Ask whether the protocol is proving correctness, privacy, membership, or several properties. Verify trusted setup assumptions, user-data disclosure, data availability and the role of any centrally controlled proving service.
Separate cryptographic security from economic asset security. A rollup can verify transactions correctly while its bridge, governance keys or sequencer create distinct risks. Benchmark claims about throughput should include real on-chain proof verification and data costs, not simply simulated execution speed.
Frequently asked questions
Does ZK mean every transaction is anonymous?
No. Validity proofs can operate with substantial public data and addresses.
What is the difference between SNARKs and STARKs?
They are proof-system families with different setup, size, performance and cryptographic assumptions.
What is a witness?
The private information or computation record showing why a proven statement is true.
Does a valid ZK proof show a real-world claim is true?
Only relative to the encoded statement and authenticated inputs; false source records can still produce misleading conclusions.
Can a zk-rollup be unsafe?
Yes. Bridge, upgrade, data-availability and implementation risks remain despite valid state proofs.
Sources and further reading
- Ethereum.org: Zero-Knowledge Proofs
- Ethereum.org: Privacy Applications Using ZK
- Ethereum.org: Layer 2 Rollups
Further Traders MBA education: Ethereum Layer 2 rollups explained and smart contract audit limitations.
Education only: neither yield, protocol security nor asset returns are guaranteed. Smart-contract, validator, custody and volatile-market risks can cause partial or total loss.