Zero Knowledge Proofs
How can you prove a claim without revealing the private information behind it?
Prove what matters without exposing everything else.
First Principles Building Blocks: Zero-knowledge proofs (ZKPs) solve a seemingly impossible problem: how can one party convince another that a statement is true without disclosing any underlying information? This cryptographic primitive enables verification without exposure—a foundation for privacy-preserving computation.
How It Works
ZKPs involve two parties: a prover (who holds secret knowledge) and a verifier (who needs conviction without the secrets).
Three Essential Properties
| Property | What It Guarantees |
|---|---|
| Completeness | Honest provers always convince honest verifiers |
| Soundness | Dishonest provers cannot fake valid proofs |
| Zero-Knowledge | Verifiers learn nothing beyond "statement is true" |
The Classic Example
You can prove you know the prime factorization of 2023 (7 × 17 × 17) without ever revealing those factors. Through repeated cryptographic challenges, the verifier becomes arbitrarily confident while learning nothing about the actual factors.
Types of ZKPs
| Type | Strengths | Trade-offs |
|---|---|---|
| zk-SNARKs | Small proofs, fast verification | Requires trusted setup |
| zk-STARKs | No trusted setup, quantum-resistant | Larger proof sizes |
| Specialized Protocols | Optimized for specific operations | Limited flexibility |
SNARKs (Succinct Non-Interactive Arguments of Knowledge) dominate current deployments due to their compact proofs and rapid verification.
STARKs (Scalable Transparent Arguments of Knowledge) sacrifice proof size for transparency and post-quantum security.
Prime Use Cases
1. Privacy-Preserving Identity
Prove attributes without revealing identity:
- "I am over 18" without showing your birthdate
- "I am a licensed professional" without exposing your license number
- "I have sufficient funds" without disclosing your balance
2. ZK-Rollups
Bundle thousands of transactions into a single proof. The verifier checks one proof instead of processing every transaction—enabling massive throughput while inheriting Layer 1 security guarantees.
3. Confidential Transactions
Execute financial operations on transparent ledgers while hiding:
- Transaction amounts
- Sender/receiver identities
- Business logic details
4. Verifiable Computation
Delegate computation to untrusted servers, then verify correct execution without re-running the work. Critical for:
- Cloud computing integrity
- Supply chain verification
- Auditable AI inference
Why ZKPs Matter
ZKPs resolve the fundamental tension between transparency (verifying correct behavior) and privacy (protecting sensitive information).
ZKPs let a verifier check a bounded claim while receiving less private information.
For Web3 and decentralized systems, this enables:
- Permissionless verification without intermediaries
- Selective disclosure of credentials and attributes
- Scalable consensus without computational bottlenecks
- Regulatory compliance while preserving user privacy
Sovereignty Boundary
A ZKP answers a narrow question: can a verifier accept a claim without receiving the private witness? It does not answer who issued the credential, who controls account recovery, where application data persists, which model learns from behaviour, or which objective directs attention.
Treat it as one layer in a larger control stack:
| Layer | What a ZKP can contribute | What still needs governance |
|---|---|---|
| Identity | Prove a credential or attribute selectively | Issuance, custody, recovery, revocation |
| Data | Avoid disclosing inputs used to establish a claim | Collection, storage, deletion, secondary use |
| Computation | Prove a specified computation was executed | Whether the specified objective was worth executing |
| AI and attention | Prove a bounded model or ranking claim | Model choice, training data, interface, and human purpose |
Self-sovereign identity connects this proof primitive to the data, model, and attention controls that people and organisations still need.
Sui zkLogin example
Sui zkLogin combines an OpenID credential, an ephemeral key, a user salt, and a zero-knowledge proof so a transaction can be authorised without publishing the sensitive OAuth identifier on-chain. It improves onboarding and reduces on-chain identity disclosure. It does not remove dependence on the identity provider or govern the application's later use of behavioural data.
Read the Sui implementation boundary before using zkLogin as evidence for a wider sovereignty claim.
Failure Modes
- Wrong statement: the proof faithfully verifies a claim that does not protect the outcome people need.
- Witness leakage: surrounding metadata, application logs, or service design reveal what the proof hides.
- Trusted-service dependency: proving, identity, salt, recovery, or revocation infrastructure recreates a central control point.
- Proof theatre: a valid proof is presented as evidence that the wider data, model, or governance system is trustworthy.
- Unusable sovereignty: proof generation, recovery, or consent is too difficult for the subject to exercise meaningful control.
Engineering Integration
Framework Landscape
| Framework | Language | Best For |
|---|---|---|
| Circom | DSL | Circuit design, mature ecosystem |
| Noir | Higher-level DSL | Accessible ZKP development |
| RISC Zero | Rust | General-purpose zkVM |
| SP1 | Rust | Performance-focused zkVM |
Integration Path
1. Define what to prove vs. what to hide
↓
2. Select framework matching your constraints
↓
3. Design circuits (computation as constraints)
↓
4. Generate proving/verification keys
↓
5. Integrate proof generation & verification into your stack
Architectural Pattern
Key Considerations
- Proof generation is expensive: Runs on client or dedicated prover infrastructure
- Verification is cheap: Runs on-chain or server-side in milliseconds
- Circuit complexity matters: More constraints = slower proving
- Trusted setup (SNARKs): Use established ceremonies or consider STARKs
Learn More
- ZKPs Explained - Chainanalysis — Accessible introduction with practical context
- NIST ZKP Overview (PDF) — Technical foundations and security properties
- Circom Documentation — Hands-on circuit development tutorial
- RISC Zero Developer Hub — Build ZKPs in Rust without cryptography expertise
- Zero Knowledge Podcast — Deep dives with researchers and builders
Questions
Which claim must be verified, which facts must remain private, and who controls the services surrounding the proof?
- SNARKs require a trusted setup ceremony — what happens if that ceremony was compromised, and how do you know if it was?
- If proof generation is expensive, who pays for the prover infrastructure — and does that cost recentralise the system?
- ZKPs enable "auditable AI inference" — how does this interact with proprietary model weights that the model owner does not want to disclose?
Changes my mind: evidence that exposing the private witness produces the same privacy, security, and coordination outcome at lower total risk.
Next question: what is the smallest claim your system must prove without learning the underlying data?
Context
- Self-Sovereign Identity — apply selective proof inside the wider identity, data, model, and attention stack.
- Verifiable Truth — decide which claim must be independently checkable.
- Sui Technical — inspect zkLogin as a bounded implementation example.
- Principles — test whether the proof serves a worthwhile purpose before optimising it.