The Praxeology of Privacy ~ Chapter 16: Zero-Knowledge Proofs

"In cryptography, a zero-knowledge proof is a method by which one party can prove to another party that a given statement is true, without conveying any information apart from the fact that the statement is indeed true."

Goldwasser, Micali, and Rackoff^1^

Introduction

Zero-knowledge proofs represent one of the most remarkable achievements in modern cryptography: the ability to prove that a statement is true without revealing any information beyond the truth of the statement itself. For privacy, this capability is transformative. Traditional verification requires disclosure; zero-knowledge verification does not.

This chapter examines how zero-knowledge proofs work, what they enable, and their limitations. The technology remains complex, but its privacy implications are straightforward: verification without surveillance becomes possible.

16.1 The Verification Dilemma

Traditional Verification Requires Disclosure

Consider common verification scenarios. To prove identity, one shows identifying documents; the verifier sees name, address, photo, document numbers, and more data than the verification requires. To prove legal age for purchasing alcohol, one shows ID; the merchant learns the exact birthdate, name, and address when all they need is confirmation of being over 21. To prove professional qualification, one shows certificates; the verifier learns issuing institution, dates, grades, and potentially other credentials on the same document. To prove creditworthiness, one shares financial statements; the verifier learns income sources, spending patterns, account balances, and transaction history.

In each case, verification reveals more information than logically necessary for the verification's purpose.

The Privacy Cost

This over-disclosure has costs. Each verification adds to databases, and over time, entities accumulate comprehensive profiles from individually minor disclosures. More data creates more targets; data breaches expose information that privacy-preserving verification would never have collected. Disclosed data enables inferences, and knowing someone's birthdate and zip code often suffices to uniquely identify them. Verifiers accumulate information while individuals cannot audit how it is used, creating systematic power imbalance.

The Fundamental Dilemma

The dilemma: verification requires information, but providing information destroys privacy. Traditional systems force a choice between participating in verification-requiring activities or maintaining privacy.

Zero-knowledge proofs resolve this dilemma by separating what is proven from what is revealed.

16.2 The ZK Concept: Proving Without Revealing

Interactive Proofs

The original zero-knowledge concept involves interactive protocols.^1^ A prover wants to convince a verifier of a statement without revealing underlying information. They engage in a protocol where the verifier poses challenges and the prover responds.

The tunnel analogy illustrates the concept. Picture a horseshoe-shaped tunnel with both ends opening onto the same clearing. Deep inside, where the two paths meet, sits a locked door. Alice claims she knows the combination. Bob stands in the clearing where he can see both tunnel exits but cannot see inside. Alice enters while Bob looks away. Bob then calls out "come out the left exit" or "come out the right exit." If Alice knows the combination, she can always comply, unlocking the door if necessary. If she does not, she is trapped on whichever side she entered and has only a 50% chance of guessing correctly. After twenty successful rounds, Bob is virtually certain Alice knows the combination, yet he never learned what it is.

This is zero-knowledge: Bob learns only that Alice knows the secret, not the secret itself.

Non-Interactive Proofs

Modern applications typically use non-interactive zero-knowledge proofs (NIZKs). Instead of a back-and-forth protocol, the prover generates a single proof that anyone can verify.

Non-interactivity enables practical applications: proofs can be attached to transactions, stored on blockchains, or verified by multiple parties without prover involvement.

Formal Properties

Zero-knowledge proof systems have three properties.^2^ Completeness means that if the statement is true, an honest prover can convince an honest verifier. Soundness means that if the statement is false, no cheating prover can convince an honest verifier except with negligible probability. Zero-knowledge means the verifier learns nothing beyond the truth of the statement; even after seeing the proof, the verifier cannot extract additional information. Soundness and zero-knowledge are in tension: strong soundness requires the proof to "contain" something about the statement; zero-knowledge requires the proof to reveal nothing. Cryptographic constructions achieve both properties through mathematical techniques that seem almost magical.

16.3 Types: SNARKs, STARKs, Bulletproofs

Different zero-knowledge proof systems make different tradeoffs. The main constructions in current use are:

SNARKs

Succinct Non-interactive Arguments of Knowledge (SNARKs) produce very small proofs (often under 300 bytes) that are fast to verify.^3^

Traditional SNARKs require a "trusted setup": generating initial parameters through a ceremony that, if compromised, would allow fake proofs. However, transparent SNARKs now exist that eliminate this requirement. Systems like Spartan and Plonky2 achieve SNARK-like properties without trusted setup, using different cryptographic techniques. The tradeoff is typically somewhat larger proofs or slower proving times compared to trusted-setup SNARKs.

All current SNARKs rely on cryptographic assumptions vulnerable to quantum computing attacks. Zcash uses SNARKs for shielded transactions.

STARKs

Scalable Transparent Arguments of Knowledge (STARKs) eliminate the trusted setup requirement.^4^ STARKs offer transparency (no trusted setup), rely on minimal cryptographic assumptions (hash functions), are quantum-resistant, and scale well to large computations. However, they produce larger proofs (tens to hundreds of kilobytes) and involve more complex verification.

StarkWare uses STARKs for Ethereum scaling solutions.

Bulletproofs

Bulletproofs are designed for range proofs and similar applications.^5^ They require no trusted setup, produce moderate proof sizes, and are efficient for range proofs (proving a value is in a range without revealing it). However, verification is slower than SNARKs, and they are not as general-purpose as SNARKs/STARKs.

Monero uses Bulletproofs for confidential transactions.

Choosing Among Constructions

The constructions differ across several dimensions. Traditional SNARKs produce tiny proofs (around 300 bytes) with fast verification but require a trusted setup and are not quantum-safe; transparent SNARKs eliminate the trusted setup at some cost to proof size or proving time. STARKs avoid the trusted setup and offer quantum resistance but generate much larger proofs (around 100 kilobytes) with moderate verification speed. Bulletproofs occupy a middle ground with medium-sized proofs (around 2 kilobytes) and no trusted setup, though verification is slower and they lack quantum resistance.

The right choice depends on application requirements. Blockchain base layers typically favor small proofs (SNARKs). Applications requiring post-quantum security favor STARKs. Range proofs in confidential transactions often use Bulletproofs.

16.4 Applications: Zcash, Rollups, Identity

Private Cryptocurrency: Zcash

Zcash implements shielded transactions using SNARKs.^6^ Users can transact with fully hidden sender, receiver, and amount. The blockchain records that a valid transaction occurred without revealing its details.

The proof demonstrates that input notes exist and are unspent, the sender possesses spending keys, input and output values balance, and no double-spending occurs. All this without revealing which notes are spent, who receives funds, or what amount transfers.

Zcash demonstrates zero-knowledge proofs deployed at scale in adversarial conditions. However, adoption of shielded transactions remains limited; most Zcash transactions are transparent, resembling ordinary Bitcoin transactions.^7^ Many exchanges require transparent addresses for deposits and withdrawals, undermining the privacy benefits. The shielding technology works, but network effects and regulatory pressure limit its use.

Zcash also illustrates both the risks of complex cryptography and the importance of ongoing maintenance. In 2019, a vulnerability was discovered in the original Sprout proving system that could have allowed undetectable inflation. The bug existed since launch; no exploitation was detected, and the Sapling upgrade (deployed in 2018) had already fixed it before the vulnerability was publicly disclosed. The Zcash team's practice of deploying cryptographic upgrades allowed the fix to precede public knowledge of the bug. The discovery demonstrated that even carefully designed systems can harbor critical bugs, making active protocol development essential. Zcash continues to undergo upgrades; the protocol is actively maintained and improved.

Blockchain Scalability: Validity Rollups

Zero-knowledge proofs enable "rollups" that scale blockchain throughput.^9^ A rollup executes many transactions off-chain, then posts a proof to the main chain that all executions were valid.

The main chain verifies only the proof, not the individual transactions. This achieves throughput scaling (many transactions compressed to one proof), security inheritance (main chain validates correctness), and data availability (transaction data can be reconstructed).

StarkNet, zkSync, and similar systems use this approach for Ethereum scaling.

Identity and Credentials

Zero-knowledge proofs enable privacy-preserving identity verification. The core insight: most verification situations require proving a property, not revealing the underlying data. A bar needs to know you are over 21, not your exact birthdate. A lender needs to know you can repay, not your complete financial history. A service needs to know you are a licensed professional, not your home address.

Traditional verification bundles necessary proof with unnecessary disclosure. Showing a driver's license to prove age reveals name, address, birthdate, driver's license number, and photo. Each of these data points creates risk: identity theft, targeted harassment, database breach exposure. The verification accomplished its purpose; the disclosure exceeded its purpose.

Zero-knowledge credentials invert this relationship. Age verification allows proving that age exceeds a threshold without revealing birthdate; the proof demonstrates "birthdate < (today - 21 years)" without exposing the birthdate itself. The verifier learns exactly what they need (legal age confirmed) and nothing more. Credential verification allows proving possession of a valid credential (degree, license, membership) without revealing identifying details; the verifier learns the credential is valid without learning who holds it. An employer can verify professional licensure without learning the candidate's home address or when they obtained the license. Selective disclosure allows proving only specific properties from a rich credential containing many attributes; from a driver's license, one can prove only "state of residence" without revealing name, address, or birthdate.

Several projects are implementing these concepts. Polygon ID (now Privado ID) enables issuance and verification of credentials where holders can generate zero-knowledge proofs demonstrating credential properties.^8^ A credential holder can prove they are a member of a group, meet an age threshold, or hold a valid license without revealing the credential itself or their identity. The system separates the credential (which contains rich data) from the proof (which reveals only what the verifier needs).

zkPass takes a different approach, enabling zero-knowledge proofs from existing Web2 documents.^9^ Users can prove properties from their driver's license, utility bills, or financial records without uploading those documents to a third party. The proof generation happens on the user's device; the verifier receives only the proof, not the underlying document. This bridges the gap between existing identity infrastructure and zero-knowledge verification.

The implications for regulatory compliance are significant. Current know-your-customer (KYC) requirements force users to surrender comprehensive identity documents to every service requiring verification. Each disclosure creates a database that can be breached, subpoenaed, or misused. Zero-knowledge KYC (ZK-KYC) offers an alternative: prove compliance without disclosure. A user could prove "identity verified by licensed institution" without revealing the identity itself to downstream services. The compliance requirement is met; the surveillance infrastructure is not created.

This remains largely speculative as deployed regulation. Regulators accustomed to comprehensive disclosure may resist verification methods they cannot inspect. But the technical capability exists to satisfy regulatory purposes while minimizing privacy invasion. Whether regulators will accept ZK-KYC depends on policy choices, not technical limitations.

The privacy implications extend beyond individual transactions. Identity verification currently creates comprehensive profiles as a side effect. Each age check, address verification, and credential presentation adds to dossiers that follow individuals across contexts. Zero-knowledge verification prevents this accumulation. Each proof reveals only what that specific verification requires; nothing aggregates across verifications because nothing is revealed to aggregate.

Not all projects in this space equally prioritize privacy. Worldcoin, for instance, uses zero-knowledge proofs to verify "unique human" status while collecting biometric iris scans centrally. The ZK proof protects subsequent verification events, but the initial biometric collection creates exactly the centralized database that privacy-preserving identity should avoid. The technology enables privacy; whether implementations actually provide privacy depends on the full system design.

Current vs. Speculative Applications

Currently deployed and working applications include Zcash shielded transactions, rollup-based scaling (StarkNet, zkSync), and Tornado Cash-style mixing. Experimental but promising applications include privacy-preserving identity systems, zero-knowledge machine learning proofs, and cross-chain verification. Highly speculative applications include universal verifiable computation replacing trust entirely, zero-knowledge voting at scale, and comprehensive privacy-preserving compliance systems.

The technology is real and deployed in important applications, but not every proposed use case is equally mature.

16.5 Economic Implications: Verification Markets

Verification as Scarce Service

Proof generation requires computational resources. Complex proofs (large computations) require substantial computation to generate, even though verification is fast.

This creates markets for proof generation. Users who need proofs but lack computational resources can pay provers to generate proofs on their behalf. The prover learns the witness (underlying data) but this can be mitigated through trusted provers (centralized but efficient), multi-party computation (no single prover learns the witness), or hardware security modules (provers cannot extract witnessed data).

Economic Efficiency Gains

Zero-knowledge systems can reduce verification costs throughout the economy. Proving regulatory compliance without exposing business details reduces the friction of regulation while maintaining its intent. Verifiable credentials that cannot be forged reduce fraud verification overhead. Proving aggregate statistics without exposing individual data enables data-driven decisions without privacy sacrifice.

These efficiency gains are speculative at current deployment scale but suggest significant economic value if zero-knowledge systems achieve broad adoption.

16.6 Limitations

Trusted Setup Requirements

Many SNARK constructions require a "trusted setup": an initial ceremony generating parameters that all future proofs and verifications use. If the ceremony is compromised (someone retains the "toxic waste" used to generate parameters), they can create fake proofs that verify correctly.

Trusted setups come in several varieties with different tradeoffs. Per-circuit setups, as used in Zcash's original Sprout system, require a new ceremony for each application or circuit change; any modification to the computation being proved requires discarding the old parameters and running a new trusted setup. Universal setups, as in systems like PLONK and Marlin, generate parameters that work for any circuit up to a certain size; one ceremony can serve many applications, though the ceremony itself remains a trust assumption. Transparent setups eliminate the requirement entirely: STARKs and some newer SNARKs like Spartan derive their parameters from public randomness, requiring no ceremony and leaving no toxic waste that could be retained.

Mitigations for systems requiring trusted setup include multi-party computation ceremonies where only one participant needs to be honest and Powers of Tau ceremonies with thousands of participants. But applications with strict trust requirements may prefer transparent constructions despite their larger proofs.

The trusted setup is a real limitation that responsible implementations take seriously.

Computational Intensity

Proof generation is computationally expensive. Simple proofs take seconds; complex proofs can take minutes or hours. This limits applications where latency matters.

Verification is fast (often milliseconds), but generation is the bottleneck. Hardware acceleration (GPUs, FPGAs, ASICs) can help but does not eliminate the fundamental computational cost.

Implementation Complexity

Zero-knowledge proof systems are mathematically sophisticated. Implementation bugs can destroy security properties. A bug might allow invalid proofs to verify (soundness failure). A bug might leak information through the proof (zero-knowledge failure). Subtle implementation errors have affected deployed systems.

Audit difficulty is high. Few people can competently review ZK implementations. This concentrates trust in small expert communities.

What ZK Proofs Cannot Solve

Chapter 13 examined what cryptography cannot solve in general: endpoint security, metadata exposure, physical coercion, key authenticity. Zero-knowledge proofs inherit these limitations and add ZK-specific constraints.

The most significant is the garbage-in-garbage-out problem, often called the oracle problem. A zero-knowledge proof verifies that a computation was performed correctly on given inputs. It says nothing about whether those inputs were true. An application that claims "this loan is collateralized" using a ZK proof has proven only that the computation was done correctly on the price data it received; if that price data was stale, manipulated, or simply wrong, the proof is meaningless. No amount of cryptographic sophistication can bridge the gap between "correctly computed" and "actually true." Proving you processed oracle data correctly does not prove the oracle provided accurate data. This limitation is fundamental: ZK proofs verify computation, not reality.

Zero-knowledge adds complexity that may be unnecessary. When the verification problem does not require hiding information, simpler cryptographic tools suffice. Adding ZK machinery where it is not needed increases attack surface and implementation difficulty without corresponding benefit.

Chapter Summary

Zero-knowledge proofs resolve the verification dilemma by enabling proof without disclosure. The formal properties of completeness, soundness, and zero-knowledge ensure that true statements can be proven, false statements cannot, and proofs reveal nothing beyond statement truth.

Different proof systems make different tradeoffs. SNARKs produce tiny proofs but require trusted setup and are vulnerable to quantum attack. STARKs eliminate trusted setup and provide quantum resistance but produce larger proofs. Bulletproofs work well for range proofs without trusted setup. Choice depends on application requirements.

Current applications include Zcash shielded transactions, validity rollups for blockchain scaling, and experimental identity systems. The technology is real and deployed, though many proposed applications remain speculative. Economic implications include markets for proof generation and potential efficiency gains from privacy-preserving verification.

Zero-knowledge proofs represent a breakthrough in privacy technology: verification without disclosure. Current deployments demonstrate the technology works. Broader adoption depends on continued development of more efficient constructions and practical implementations.

---

Footnotes

^1^ Shafi Goldwasser, Silvio Micali, and Charles Rackoff, "The Knowledge Complexity of Interactive Proof Systems," SIAM Journal on Computing 18, no. 1 (1989): 186-208.

^2^ For accessible introduction to zero-knowledge proofs, see Matthew Green, "Zero Knowledge Proofs: An Illustrated Primer," A Few Thoughts on Cryptographic Engineering (2014).

^3^ Jens Groth, "On the Size of Pairing-Based Non-interactive Arguments," Advances in Cryptology - EUROCRYPT 2016 (2016): 305-326.

^4^ Eli Ben-Sasson et al., "Scalable, Transparent, and Post-Quantum Secure Computational Integrity," CRYPTO 2018 (2018).

^5^ Benedikt Bünz et al., "Bulletproofs: Short Proofs for Confidential Transactions and More," IEEE Symposium on Security and Privacy (2018): 315-334.

^6^ Eli Ben-Sasson et al., "Zerocash: Decentralized Anonymous Payments from Bitcoin," IEEE Symposium on Security and Privacy (2014): 459-474.

^7^ For rollup designs, see Vitalik Buterin, "An Incomplete Guide to Rollups," Ethereum Blog (2021).

^8^ Polygon ID (rebranded as Privado ID) documentation at https://docs.privado.id/. See also "Introducing Polygon ID, Zero-Knowledge Identity for Web3," Polygon Technology Blog (2022), and Identity Foundation, "Guest Blog: Polygon ID—Verifiable Credentials Meet Web3."

^9^ zkPass documentation at https://docs.zkpass.org/. zkPass uses Three-Party TLS (3P-TLS) and Multi-Party Computation to enable zero-knowledge proofs from HTTPS website data without exposing raw documents.

---

Precious chapter:

Next Chapter: