What are zero-knowledge proofs for?

Share on

Zero-knowledge proofs are usually explained as a privacy tool and filed under cryptocurrency. Both habits undersell them. ZK is now shipping in Google Wallet, built into the EU's age-verification app, and the technology Ethereum is rebuilding its core around. 

This piece sets out what zero-knowledge proofs actually do, what they are being used for, and why a zkVM turns them from a specialist instrument into something any programmer can use.

Computation doesn't carry evidence

A bank balance, a vote count, an insurance decision, an AI model's answer: most of what institutions tell us is the output of a computation we never see. Trust in those outputs has only ever had two sources. Either you trust whoever ran the computation, or you redo it yourself.

Both options fail as computation grows. Redoing the work caps every system at the capacity of its weakest checker: an auditor samples a fraction of the ledger, a regulator reconstructs events months later, and a blockchain asks thousands of machines to re-execute every transaction, buying trust at the price of throughput. Trusting the operator fails differently. The operator can be wrong, compromised, or lying, and nothing in the result itself would show it.

A zero-knowledge proof is the third option. It is a short certificate, produced alongside a computation, with three properties that do not normally coexist:

  • Anyone can check it in milliseconds, whatever the size of the computation it covers. Verifying a proof of a million transactions costs about the same as verifying a proof of ten.
  • It could not have been forged. Producing a valid proof of a false statement is as hard as breaking the underlying cryptography. For STARKs, the hash-based family introduced in 2018 by Eli Ben-Sasson, co-founder of Zcash and StarkWare, that means hash functions: the same class of primitive that Bitcoin’s proof-of-work rests on.
  • It can withhold the inputs. The proof certifies that the computation was done correctly without revealing the data it ran on. This is the "zero-knowledge" part, and the name undersells the object: hiding is optional, verification is the core.

One caveat here, because it frames everything below. A proof certifies that a specific, named program was executed correctly on committed inputs. It does not certify that the program was the right program to run. ZK moves the question of trust from executions, which have always been invisible, to programs, which can be published, read and audited. 

That is a trade in the right direction, but it is a trade, and we will come back to it.

What changed: the zkVM

For the first decade of practical ZK, each application was handmade. To prove a computation, engineers re-expressed it as an arithmetic circuit, a fixed web of additions and multiplications, then wrote and audited custom cryptography around that circuit. Every application was a research project. Every change to the program meant redoing the cryptography. The economics confined ZK to a handful of high-value deployments, nearly all of them inside crypto, and gave the technology its reputation as something only cryptographers could operate.

A zkVM removes the per-application cryptography. Instead of building a circuit for a program, it implements a processor: the constraints are written once, for an instruction set, and from then on any program that compiles to that instruction set can be proven, unchanged. The cryptographic work is done one time, by the zkVM's authors, and inherited by every program afterwards.

Ziren, the open-source zkVM we build at ZKM, proves MIPS32 execution. Programs written in Rust, C and Go compile to it with standard toolchains and come out the other side with proofs attached. The scale this permits is the point: Ziren was the first zkVM to prove Geth, the software that runs most Ethereum nodes, without modifying the Go compiler, and it has proven Ethereum mainnet blocks end to end. Geth is not a demonstration program. It is hundreds of thousands of lines of production Go, written over a decade with no thought of ever being proven.

The answer to "what can ZK do" used to be "whatever cryptographers have built so far". With a zkVM it has the same answer as "what can software do".

How proving an application changed: hand-built circuits against a general-purpose zkVM.

What the proof replaces

Applications of ZK sort by what the proof substitutes for. There are four substitutions, and every deployment we know of is one of them, or a combination.

The four substitutions behind every ZK application.

Re-execution

Where verification currently means redoing the work, a proof collapses the cost of checking. One machine computes and proves; everyone else verifies in milliseconds.

Ethereum is the clearest commitment to this idea. Today every validator re-executes every transaction in every block, which is why the chain's throughput is bounded by what a modest machine can re-execute. In January 2026 the Ethereum Foundation's zkEVM team published a roadmap for validators that verify a proof of each block instead of re-executing it, with proofs delivered inside windows of a few seconds. The design splits roles: provers, which can be serious hardware, race to prove each block once; validators, which can be laptops and eventually phones, check the proof. 

Verification stops being the bottleneck on throughput, and decentralization stops being the casualty of scale, because adding verifiers is nearly free. 

The work is already public on Ethproofs, the Foundation's open proving dashboard led by researcher Justin Drake. zkVM teams prove live mainnet blocks and publish their proving times and costs block by block, with real-time eligibility set at ten seconds and per-proof costs for the leaders down to fractions of a cent.

The goal, in Vitalik Buterin's words, from his October 2024 Verge roadmap post.

The harder version of the same substitution is a verifier that cannot re-execute at all. 

Bitcoin is the extreme case: it cannot run EVM computation under any setting of any parameter. GOAT Network, a Bitcoin-secured zkEVM, exists on the far side of that constraint. Ziren proves the network's state transitions, and the BitVM3 bridge design makes those proofs enforceable on Bitcoin itself. The computation Bitcoin could never perform becomes a claim Bitcoin can hold to account.

The pattern generalizes past blockchains: a phone checking work done by a data center, a regulator checking a bank's model run, a browser checking a server. Wherever verifiers are weaker than provers, or outnumber them, proofs are the only arrangement in which checking keeps up.

Disclosure

Where proving something currently means showing the record, a proof separates the claim from the data behind it.

This is the substitution now reaching people who have never heard of ZK, because regulators forced the question. Age checks became a legal requirement at scale in the UK and across Europe, and the obvious implementation, uploading your identity document to every website that needs your age, is a privacy failure by construction. The deployed answer is a proof. In 2025 Google announced zero-knowledge age verification in Google Wallet and committed its ZK components to open source. The European Commission's age-verification blueprint app, which it urged member states in April 2026 to roll out this year, proves that the holder falls in an age range without sharing a birth date, and EU digital identity wallets are due to citizens by the end of 2026. These are the widest deployments of zero-knowledge cryptography so far, and none of them is a cryptocurrency.

The general shape underneath: prove the predicate, withhold the record. Over eighteen, without the birthday. Solvent, without the balance sheet. Clear of a sanctions list, without the customer file. Qualified, without the transcript. Institutions have always faced a forced choice between demonstrating things about their data and protecting it; proofs end the forced choice.

It is worth answering the standard objection here. "If the data stays hidden, you've built a black box" has it backwards. Disclosure in a ZK system is a design parameter, not a casualty: a system can be built so that nothing is revealed to anyone, or so that a named auditor can open specific records, or so that everything becomes public after a time lock. The system is as transparent as its rules require, and the rules are in the program, which is public. Hidden data and accountable computation stop being opposites.

Trust in the operator

Where a result currently rests on the reputation of whoever produced it, a proof lets the result carry its own evidence.

The near-term version is outsourced computation: when a cloud provider, a counterparty or a pool of anonymous machines runs your workload, a proof establishes that they ran your program rather than a cheaper approximation of it. The version that matters more arrives with AI. A model's answer is the output of a computation performed by someone with every incentive to economize: serve a smaller model than advertised, skip the safety pass, quietly degrade under load. 

Proof of inference, which we have written about previously, is the receipt that closes the gap: a proof that this committed model, on this input, produced this output. The research frontier moved quickly from toy networks to real ones; in August 2025, Lagrange's DeepProve generated a proof of a full GPT-2 inference. Routine proving of frontier-scale models is not close yet. But the trajectory is the same one zkVMs traveled, and the demand side is new: autonomous agents are beginning to transact with money and authority, and an agent cannot be deposed, cross-examined or held to its word. 

Machines that act on our behalf will be held accountable by evidence or not at all.

Repetition

Where the same computation is currently redone because the result can't be carried, a proof makes computation a durable artifact: performed once, verified forever, by anyone, at almost no cost.

Proofs compose. A proof can attest to the verification of other proofs, so a tree of them compresses arbitrarily much computation into one certificate; a verifier checks the root and has checked everything underneath. This is not exotic machinery. It is how production systems already work: the design paper for Ziren documents a recursion tree of 149 proofs standing behind a single final certificate for a block's execution. Recursion is what lets one small proof speak for an entire chain's history, lets systems consume each other's state without replaying it, and makes verification the one cost in computing that does not grow with the work it covers.

What a proof does not do

A technology earns a serious hearing by being clear about its edges. Four of them.

A proof does not choose the statement. It certifies the program you committed to, so a flawed program yields a perfectly valid proof of a flawed result. The honest description of ZK is that it converts runtime trust into design-time trust: you no longer trust executions you cannot see, and in exchange the program itself, which is public and inspectable, must deserve the scrutiny it can now receive.

A proof does not remove implementation risk. The mathematics can be sound while the code implementing it has bugs, and a bug in a proof system fails quietly. This is why the center of competition among proof systems has been shifting from speed to security, and why the maturing of the field looks the way it does: measured security rather than asserted security. Ziren’s code has been through that measurement: seven months of responsible disclosure with the Ethereum Foundation, Consensys Diligence and TU Wien found five bugs, one of them fixed upstream in LLVM, and produced two hardened releases, alongside an independent review of the execution model by Veridise. This work continues, and the mathematics side is quantified in the design paper for Ziren, published in October 2026 on the IACR Cryptology ePrint Archive: more than 100 bits of interactive soundness per proving stage and 93.5 bits composite across the full recursion tree, with the hypotheses the end-to-end claim rests on stated. We publish the numbers, the assumptions and the findings because security is not a property anyone finishes; it is work that continues, in the open, and stating what remains is part of it.

A proof does not make data free. Proofs compress computation, not data. A verifier still needs access to the data a statement refers to, which is why data availability remains its own engineering problem with its own solutions, and why latency floors are set by networks rather than by proving.

A proof is not free to produce. Proving carries a large constant-factor overhead over native execution, and that overhead is the engineering frontier of the whole field. It has fallen far enough that Ethereum now plans for whole blocks to be proven within seconds of being built, which would have read as fantasy three years ago. The economics that result are lopsided in a useful way: one party pays the proving cost so that checking, for everyone else, forever, rounds to zero. It pays wherever verifiers outnumber provers, or cannot re-execute, which is most of the interesting cases.

Why demand is arriving now

The common complaint about ZK inside crypto has been that the capability outran the demand: the industry's favorite workloads never needed succinctness or privacy. What has changed is that the demand is arriving from outside.

Regulation arrived first. Age and identity rules in the UK and EU made privacy-preserving verification a compliance requirement, and ZK went from research topic to shipping feature in Google Wallet, with the EU's own blueprint app behind it.

Ethereum arrived second. The largest smart-contract network re-architecting itself around proof verification is the strongest statement yet that re-execution does not scale, and it pulls an entire supply chain with it: zkVMs, provers, hardware, formal verification.

AI arrives third, and will be the largest. Software is increasingly written by machines, executed by machines, and transacted between machines, and the number of computations no human will ever review is growing without bound. Reputation, audit and deposition were trust mechanisms designed for people. Evidence that travels with the result is the one that works between machines.

None of this requires a prediction. All three are in motion, on public timelines, with shipping dates.

The result

A result used to be an assertion made by whoever computed it. With a proof attached, it is a fact that anyone can check, at negligible cost, without seeing the private data behind it and without knowing or trusting the machine that produced it. Zero-knowledge proofs make correctness a property of computation itself, rather than a property of institutions, and a zkVM extends that property to any program a developer can write.

ZKM builds zero-knowledge proving infrastructure for verifiable computing. Its open-source general-purpose zkVM, Ziren, proves MIPS32 execution for Geth and programs in Rust, C and Go. The design paper is on the IACR Cryptology ePrint Archive, and the code is open for anyone to read, run and prove with.

More articles
Hello World ‘Special Edition’ Newsletter
It’s safe to say that February 2024 was the month that truly put ZKM on the map! After months of intense preparation and ardent building in relative stealth, we revealed several mouth-watering new developments in the build-up to our genesis launch of the House of ZK, which lit-up EthDenver!
ZKM Prover: Proof Generation and Aggregation
The ZKM Prover employs Plonky2 to construct a zero-knowledge proof system. Its primary steps involve generating, aggregating, and compressing proofs for each Plonkish table. The process is detailed below.
What are zero-knowledge proofs for?

Zero-knowledge proofs are usually explained as a privacy tool and filed under cryptocurrency. Both habits undersell them. ZK is now shipping in Google Wallet, built into the EU's age-verification app, and the technology Ethereum is rebuilding its core around. 

This piece sets out what zero-knowledge proofs actually do, what they are being used for, and why a zkVM turns them from a specialist instrument into something any programmer can use.

Computation doesn't carry evidence

A bank balance, a vote count, an insurance decision, an AI model's answer: most of what institutions tell us is the output of a computation we never see. Trust in those outputs has only ever had two sources. Either you trust whoever ran the computation, or you redo it yourself.

Both options fail as computation grows. Redoing the work caps every system at the capacity of its weakest checker: an auditor samples a fraction of the ledger, a regulator reconstructs events months later, and a blockchain asks thousands of machines to re-execute every transaction, buying trust at the price of throughput. Trusting the operator fails differently. The operator can be wrong, compromised, or lying, and nothing in the result itself would show it.

A zero-knowledge proof is the third option. It is a short certificate, produced alongside a computation, with three properties that do not normally coexist:

  • Anyone can check it in milliseconds, whatever the size of the computation it covers. Verifying a proof of a million transactions costs about the same as verifying a proof of ten.
  • It could not have been forged. Producing a valid proof of a false statement is as hard as breaking the underlying cryptography. For STARKs, the hash-based family introduced in 2018 by Eli Ben-Sasson, co-founder of Zcash and StarkWare, that means hash functions: the same class of primitive that Bitcoin’s proof-of-work rests on.
  • It can withhold the inputs. The proof certifies that the computation was done correctly without revealing the data it ran on. This is the "zero-knowledge" part, and the name undersells the object: hiding is optional, verification is the core.

One caveat here, because it frames everything below. A proof certifies that a specific, named program was executed correctly on committed inputs. It does not certify that the program was the right program to run. ZK moves the question of trust from executions, which have always been invisible, to programs, which can be published, read and audited. 

That is a trade in the right direction, but it is a trade, and we will come back to it.

What changed: the zkVM

For the first decade of practical ZK, each application was handmade. To prove a computation, engineers re-expressed it as an arithmetic circuit, a fixed web of additions and multiplications, then wrote and audited custom cryptography around that circuit. Every application was a research project. Every change to the program meant redoing the cryptography. The economics confined ZK to a handful of high-value deployments, nearly all of them inside crypto, and gave the technology its reputation as something only cryptographers could operate.

A zkVM removes the per-application cryptography. Instead of building a circuit for a program, it implements a processor: the constraints are written once, for an instruction set, and from then on any program that compiles to that instruction set can be proven, unchanged. The cryptographic work is done one time, by the zkVM's authors, and inherited by every program afterwards.

Ziren, the open-source zkVM we build at ZKM, proves MIPS32 execution. Programs written in Rust, C and Go compile to it with standard toolchains and come out the other side with proofs attached. The scale this permits is the point: Ziren was the first zkVM to prove Geth, the software that runs most Ethereum nodes, without modifying the Go compiler, and it has proven Ethereum mainnet blocks end to end. Geth is not a demonstration program. It is hundreds of thousands of lines of production Go, written over a decade with no thought of ever being proven.

The answer to "what can ZK do" used to be "whatever cryptographers have built so far". With a zkVM it has the same answer as "what can software do".

How proving an application changed: hand-built circuits against a general-purpose zkVM.

What the proof replaces

Applications of ZK sort by what the proof substitutes for. There are four substitutions, and every deployment we know of is one of them, or a combination.

The four substitutions behind every ZK application.

Re-execution

Where verification currently means redoing the work, a proof collapses the cost of checking. One machine computes and proves; everyone else verifies in milliseconds.

Ethereum is the clearest commitment to this idea. Today every validator re-executes every transaction in every block, which is why the chain's throughput is bounded by what a modest machine can re-execute. In January 2026 the Ethereum Foundation's zkEVM team published a roadmap for validators that verify a proof of each block instead of re-executing it, with proofs delivered inside windows of a few seconds. The design splits roles: provers, which can be serious hardware, race to prove each block once; validators, which can be laptops and eventually phones, check the proof. 

Verification stops being the bottleneck on throughput, and decentralization stops being the casualty of scale, because adding verifiers is nearly free. 

The work is already public on Ethproofs, the Foundation's open proving dashboard led by researcher Justin Drake. zkVM teams prove live mainnet blocks and publish their proving times and costs block by block, with real-time eligibility set at ten seconds and per-proof costs for the leaders down to fractions of a cent.

The goal, in Vitalik Buterin's words, from his October 2024 Verge roadmap post.

The harder version of the same substitution is a verifier that cannot re-execute at all. 

Bitcoin is the extreme case: it cannot run EVM computation under any setting of any parameter. GOAT Network, a Bitcoin-secured zkEVM, exists on the far side of that constraint. Ziren proves the network's state transitions, and the BitVM3 bridge design makes those proofs enforceable on Bitcoin itself. The computation Bitcoin could never perform becomes a claim Bitcoin can hold to account.

The pattern generalizes past blockchains: a phone checking work done by a data center, a regulator checking a bank's model run, a browser checking a server. Wherever verifiers are weaker than provers, or outnumber them, proofs are the only arrangement in which checking keeps up.

Disclosure

Where proving something currently means showing the record, a proof separates the claim from the data behind it.

This is the substitution now reaching people who have never heard of ZK, because regulators forced the question. Age checks became a legal requirement at scale in the UK and across Europe, and the obvious implementation, uploading your identity document to every website that needs your age, is a privacy failure by construction. The deployed answer is a proof. In 2025 Google announced zero-knowledge age verification in Google Wallet and committed its ZK components to open source. The European Commission's age-verification blueprint app, which it urged member states in April 2026 to roll out this year, proves that the holder falls in an age range without sharing a birth date, and EU digital identity wallets are due to citizens by the end of 2026. These are the widest deployments of zero-knowledge cryptography so far, and none of them is a cryptocurrency.

The general shape underneath: prove the predicate, withhold the record. Over eighteen, without the birthday. Solvent, without the balance sheet. Clear of a sanctions list, without the customer file. Qualified, without the transcript. Institutions have always faced a forced choice between demonstrating things about their data and protecting it; proofs end the forced choice.

It is worth answering the standard objection here. "If the data stays hidden, you've built a black box" has it backwards. Disclosure in a ZK system is a design parameter, not a casualty: a system can be built so that nothing is revealed to anyone, or so that a named auditor can open specific records, or so that everything becomes public after a time lock. The system is as transparent as its rules require, and the rules are in the program, which is public. Hidden data and accountable computation stop being opposites.

Trust in the operator

Where a result currently rests on the reputation of whoever produced it, a proof lets the result carry its own evidence.

The near-term version is outsourced computation: when a cloud provider, a counterparty or a pool of anonymous machines runs your workload, a proof establishes that they ran your program rather than a cheaper approximation of it. The version that matters more arrives with AI. A model's answer is the output of a computation performed by someone with every incentive to economize: serve a smaller model than advertised, skip the safety pass, quietly degrade under load. 

Proof of inference, which we have written about previously, is the receipt that closes the gap: a proof that this committed model, on this input, produced this output. The research frontier moved quickly from toy networks to real ones; in August 2025, Lagrange's DeepProve generated a proof of a full GPT-2 inference. Routine proving of frontier-scale models is not close yet. But the trajectory is the same one zkVMs traveled, and the demand side is new: autonomous agents are beginning to transact with money and authority, and an agent cannot be deposed, cross-examined or held to its word. 

Machines that act on our behalf will be held accountable by evidence or not at all.

Repetition

Where the same computation is currently redone because the result can't be carried, a proof makes computation a durable artifact: performed once, verified forever, by anyone, at almost no cost.

Proofs compose. A proof can attest to the verification of other proofs, so a tree of them compresses arbitrarily much computation into one certificate; a verifier checks the root and has checked everything underneath. This is not exotic machinery. It is how production systems already work: the design paper for Ziren documents a recursion tree of 149 proofs standing behind a single final certificate for a block's execution. Recursion is what lets one small proof speak for an entire chain's history, lets systems consume each other's state without replaying it, and makes verification the one cost in computing that does not grow with the work it covers.

What a proof does not do

A technology earns a serious hearing by being clear about its edges. Four of them.

A proof does not choose the statement. It certifies the program you committed to, so a flawed program yields a perfectly valid proof of a flawed result. The honest description of ZK is that it converts runtime trust into design-time trust: you no longer trust executions you cannot see, and in exchange the program itself, which is public and inspectable, must deserve the scrutiny it can now receive.

A proof does not remove implementation risk. The mathematics can be sound while the code implementing it has bugs, and a bug in a proof system fails quietly. This is why the center of competition among proof systems has been shifting from speed to security, and why the maturing of the field looks the way it does: measured security rather than asserted security. Ziren’s code has been through that measurement: seven months of responsible disclosure with the Ethereum Foundation, Consensys Diligence and TU Wien found five bugs, one of them fixed upstream in LLVM, and produced two hardened releases, alongside an independent review of the execution model by Veridise. This work continues, and the mathematics side is quantified in the design paper for Ziren, published in October 2026 on the IACR Cryptology ePrint Archive: more than 100 bits of interactive soundness per proving stage and 93.5 bits composite across the full recursion tree, with the hypotheses the end-to-end claim rests on stated. We publish the numbers, the assumptions and the findings because security is not a property anyone finishes; it is work that continues, in the open, and stating what remains is part of it.

A proof does not make data free. Proofs compress computation, not data. A verifier still needs access to the data a statement refers to, which is why data availability remains its own engineering problem with its own solutions, and why latency floors are set by networks rather than by proving.

A proof is not free to produce. Proving carries a large constant-factor overhead over native execution, and that overhead is the engineering frontier of the whole field. It has fallen far enough that Ethereum now plans for whole blocks to be proven within seconds of being built, which would have read as fantasy three years ago. The economics that result are lopsided in a useful way: one party pays the proving cost so that checking, for everyone else, forever, rounds to zero. It pays wherever verifiers outnumber provers, or cannot re-execute, which is most of the interesting cases.

Why demand is arriving now

The common complaint about ZK inside crypto has been that the capability outran the demand: the industry's favorite workloads never needed succinctness or privacy. What has changed is that the demand is arriving from outside.

Regulation arrived first. Age and identity rules in the UK and EU made privacy-preserving verification a compliance requirement, and ZK went from research topic to shipping feature in Google Wallet, with the EU's own blueprint app behind it.

Ethereum arrived second. The largest smart-contract network re-architecting itself around proof verification is the strongest statement yet that re-execution does not scale, and it pulls an entire supply chain with it: zkVMs, provers, hardware, formal verification.

AI arrives third, and will be the largest. Software is increasingly written by machines, executed by machines, and transacted between machines, and the number of computations no human will ever review is growing without bound. Reputation, audit and deposition were trust mechanisms designed for people. Evidence that travels with the result is the one that works between machines.

None of this requires a prediction. All three are in motion, on public timelines, with shipping dates.

The result

A result used to be an assertion made by whoever computed it. With a proof attached, it is a fact that anyone can check, at negligible cost, without seeing the private data behind it and without knowing or trusting the machine that produced it. Zero-knowledge proofs make correctness a property of computation itself, rather than a property of institutions, and a zkVM extends that property to any program a developer can write.

ZKM builds zero-knowledge proving infrastructure for verifiable computing. Its open-source general-purpose zkVM, Ziren, proves MIPS32 execution for Geth and programs in Rust, C and Go. The design paper is on the IACR Cryptology ePrint Archive, and the code is open for anyone to read, run and prove with.