What Is a Zero-Knowledge Proof in Software?

A zero-knowledge proof is a cryptographic method that lets one party, the prover, convince another party, the verifier, that a statement is true without revealing anything beyond the fact that it's true.¹² The classic explanation is the Ali Baba cave: two paths inside a circular cave meet at a locked door, and a person who knows the password can walk in one path and come out the other every time, proving they know the secret without ever saying it aloud. Software teams are now building that same trick into real systems, and it changes what "proving" something to a vendor, a regulator, or another piece of software actually requires.

Shafi Goldwasser, Silvio Micali, and Charles Rackoff formalized the idea in 1985 at MIT, and it sat mostly in academic cryptography for two decades before blockchain systems dragged it into production engineering.¹²³ Cryptographer Matthew Green of Johns Hopkins has called it "probably the most useful technology we've got, and we've barely begun to use it."³

What are the three properties every zero-knowledge proof must have?

For a proof system to count as a real zero-knowledge proof, it has to satisfy three formal properties.¹⁴

1. Completeness. If the statement is true, an honest prover can always convince an honest verifier.
2. Soundness. If the statement is false, no prover, however clever, can convince the verifier otherwise, except with a probability so small it's treated as zero.
3. Zero-knowledge. The verifier learns nothing beyond the single fact that the statement is true. No underlying data, no extra context, nothing they could reuse for anything else.

That third property is the one doing the real work for software teams. It's the difference between a system that hands over data and hopes it's handled correctly, and a system that never hands over the data at all.

How does a zero-knowledge proof actually work?

Every zero-knowledge proof involves three things: a statement (the claim being made, like "this user is over 18" or "this transaction balances"), a witness (the private data that makes the statement true, like the actual birth date), and a proof (a compact piece of evidence that the witness exists and satisfies the statement, generated without exposing the witness itself).⁵⁶

Building one starts with translating a computation into an arithmetic constraint system, commonly R1CS or the newer PLONKish format. That's what lets a verifier check the math without re-running the original computation or seeing the original inputs.⁶ A developer writes logic in a domain-specific language, compiles it into that constraint system, and the compiler outputs a proving key and a verifying key.⁵

Early ZKP systems were interactive: prover and verifier went back and forth multiple rounds before the verifier was convinced. Almost nothing built in software today works that way. Modern systems use non-interactive proofs, where the prover generates a single proof once, and anyone, including systems the prover never talks to directly, can verify it later with no further exchange.¹⁷ That's what makes ZKPs usable for asynchronous, machine-to-machine verification instead of a live cryptographic back-and-forth.

SNARKs, STARKs, and Bulletproofs: which one do developers actually use?

Most production ZKP work today happens inside one of three proof families, and they trade off differently on size, setup, and future-proofing.

• zk-SNARKs (Succinct Non-Interactive Arguments of Knowledge) produce tiny proofs, around 200 bytes regardless of how complex the underlying statement is, and verify fast.⁸ The catch is a trusted setup ceremony: a one-time process that generates secret parameters, and if those parameters are ever compromised, the whole system's soundness is at risk.⁴ Verifying a single SNARK proof on Ethereum costs roughly 500,000 gas.¹
• zk-STARKs skip the trusted setup entirely. Setup is transparent, meaning there's no secret material to protect, and because they rely on hash functions rather than elliptic curve cryptography, they resist future quantum computing attacks in a way SNARKs currently don't.⁴ The tradeoff is bigger proofs and higher verification costs.¹
• Bulletproofs trade some of the SNARK proof-size advantage for the same trusted-setup-free property, and tend to show up in confidential transaction systems rather than general-purpose computation.

None of these is strictly "better." A team choosing between them is really choosing between proof size, setup risk, and how much they care about a threat model that includes future quantum computers.

Why this matters if you're building instead of buying

Most SaaS trust is a promise, not a proof. A vendor tells you data is encrypted at rest, tells you deletion requests are honored, tells you customer data isn't used to train their models. You can't check any of that. You're trusting their word, their SOC 2 report, and their incident response team.

Zero-knowledge proofs flip that relationship. Instead of trusting a vendor's word about how a computation ran, you can build the check into your own system and get a mathematically verifiable answer.⁹ Emerging enterprise zero-knowledge database designs are built explicitly around this shift, from "trust the vendor's word" to "verify the vendor's proof."⁹

That's the same instinct driving teams to build their own internal tools instead of renting another SaaS subscription for every workflow. If a small team can now maintain what used to require a full squad, and the build-versus-buy math already favors building for niche internal tools, ZKPs extend that logic one layer deeper: you don't just own the software, you own the verification. Some teams are applying that same principle to agent workflows themselves, building on platforms like Remy so the tools their staff rely on stay inside infrastructure they control rather than a vendor's black box.

Where are zero-knowledge proofs already running in production?

This isn't a blockchain-only idea anymore. It's shipping in consumer products most people use without knowing a ZKP is involved.

• Google Wallet uses a sumcheck-plus-Ligero proof system so a user can prove an attribute like "over 18" without exposing their ID data.¹⁰
• Cloudflare's zkAttest lets a browser prove it holds a genuine hardware security key without revealing which specific key it is.¹⁰
• TikTok built a zk-SNARK system so a remote party can trust a Trusted Execution Environment's attestation without having to trust the attestation server that issued it.¹⁰
• EZKL and other zkML toolkits let a team prove a machine-learning inference ran correctly, over public or private data and public or private model weights, without exposing the proprietary model or the input.¹⁰
• Bhutan became the first nation to anchor a population-scale national digital identity system on a public blockchain, letting nearly 800,000 citizens prove attributes like age or citizenship without exposing the underlying personal data or centralizing it in a single government database.¹¹¹²

Zero-knowledge use cases also show up in zkLogins, where a user proves ownership of a credential without ever sending the secret itself over the wire, and in governance systems where transparency and privacy have to coexist.⁷

The trust problem ZKPs are actually solving

Here's the part that should worry anyone signing SaaS contracts. Third-party access was linked to 35.5% of all data breaches in 2024, up 6.5 points from the year before.¹³ Verizon's DBIR found third-party involvement in breaches doubled year over year, from 15% to 30%, the largest single-year jump of any category it tracks.¹⁴ A breach involving a third party costs more than $5.08 million on average, and roughly 40% more to remediate than an incident that starts inside your own systems, because of the added legal and jurisdictional mess of untangling someone else's data-handling failures.¹⁴

That's the real cost of "trust the vendor." It's not hypothetical, and it's growing. It's also part of why teams are getting more deliberate about what access they hand to outside systems in the first place, whether that's an AI connector reading company files or a SaaS platform holding customer records. Zero-knowledge proofs give a concrete alternative: verify the claim mathematically instead of accepting it contractually. The market is responding accordingly. The global zero-knowledge proof market was valued at $3.4 billion in 2025 and is projected to reach $23.7 billion by 2034, a 24.1% compound annual growth rate.¹⁵

What does it actually take to build with ZKPs today?

This isn't drop-in tooling yet.

1. Pick a circuit language. Circom, Halo2, and Noir are the main options, and they aren't interchangeable. A proof generated in Circom won't verify in Noir without translation work.⁸
2. Handle the trusted setup, if you're using SNARKs. That means running or trusting a setup ceremony, and accepting the risk that comes with secret parameters existing at all.⁴
3. Budget for computational overhead. Generating a proof is far more expensive than running the original computation. Verifying it is cheap; proving it is not.
4. Expect asynchronous, not real-time, verification. Current proof-generation latency limits ZKPs to workflows that can tolerate a delay, not instant back-and-forth checks.⁸

None of that is a reason to skip ZKPs. It's a reason to scope the first use case narrowly: a specific compliance check, a specific attribute proof, not a full system rebuild.

Where this is headed: ZKPs and AI agents

The next frontier is agentic AI. An internal AI agent could prove it stayed within a spending budget, or that its output followed a specific compliance rule, without disclosing the financial data or the model internals that produced the answer.⁸ That's a meaningfully different governance model than the shadow AI problem most companies have today, where an agent's actions are logged after the fact and trusted by default.

Tooling fragmentation and proof latency mean this is still mostly asynchronous work, not a real-time control layer.⁸ But the direction is clear: as teams build more of their own agent infrastructure instead of renting it, cryptographic proof of correct behavior becomes a more honest substitute for a vendor's terms-of-service promise. That's the same governance instinct behind managing what an agent keeps in its working context: the less you have to take on faith, the less there is to go wrong quietly.

Zero-knowledge proofs aren't a blockchain novelty anymore. They're a practical answer to a question every engineering team eventually asks: how do you prove something is correct without handing over the thing you're trying to protect. That question only gets more urgent as more of the software running inside a company is built, not rented.