Zero-Knowledge Proofs in 2026: What Is Actually Production-Ready

In 2024, proving an Ethereum block took minutes and a datacenter. By late 2025, it took seconds on hardware you could fit under a desk. That roughly 45x collapse in proving cost is why zero-knowledge proofs quietly moved from cryptography conferences into Google Wallet and EU identity regulation. This post is the state of the field for architects: which zkVMs are safe to build on, what proving really costs, what works on a phone, and where the security bodies are buried. It pairs with our pragmatic guide to building with ZK and FHE, which covers when to use any of this at all.

Engineering perspective, not a vendor pitch. Vendor benchmarks are labeled as such, and numbers we could not independently confirm are hedged. Reference points come from Wavect's zero-knowledge and web3 work.

What changed between 2024 and 2026?

Three shifts, each of which changes what you should build:

• zkVMs replaced hand-written circuits. You now write ordinary Rust, compile it to a RISC-V target, and the zkVM produces a proof that the program ran correctly. The circuit-DSL era, with its months of specialist work per feature, is ending for general-purpose use cases.
• Proving got roughly 45x cheaper in one year. The Ethereum Foundation set concrete real-time proving targets in July 2025: under 10 seconds for 99 percent of mainnet blocks, on a rig costing at most 100,000 dollars, drawing at most 10 kilowatts, with proofs under 300 KiB and no trusted setup (Ethereum Foundation, July 2025). By the end of 2025, multiple teams were hitting those targets, and the average cost to prove a block on the public ethproofs tracker fell from 1.69 dollars in January to under 4 cents in December (ethproofs.org).
• Big tech shipped ZK identity. Google Wallet verifies "over 18" with a zero-knowledge proof and open-sourced the underlying Longfellow library in July 2025 (google/longfellow-zk). This is the clearest signal yet that ZK left the blockchain niche.

Which zkVM should you build on?

The zkVM is the pragmatic entry point for most teams: normal Rust in, proof out. The field in mid-2026:

Our default recommendation is boring: SP1 or RISC Zero, because both have survived independent benchmarking, formal verification work on their constraint systems, and real adversarial usage. An independent eight-zkVM benchmark by Fenbushi Capital in August 2025 found these two, alongside OpenVM, delivering the most robust overall performance, with their GPU provers showing near-constant memory use while several younger zkVMs' proving time and memory ballooned with input size (Fenbushi Capital). Pick the newer systems only if their specific advantage (single-GPU cost, proof size, WASM support) is your bottleneck.

How fast and cheap is proving, really?

The numbers that matter for a build decision:

• Latency: real-time proving of Ethereum blocks (10 to 12 seconds for blocks with hundreds of transactions) is demonstrated on rigs of 16 consumer GPUs. Smaller programs prove in seconds on a single GPU.
• Cost: around 4 cents per Ethereum block proof on average across the ethproofs leaderboard by late 2025, down 45x in a year. For an application-sized proof, think fractions of a cent at scale. Verification is constant-time and effectively free, which is the entire economic point: prove once, verify everywhere.
• Proof size: modern STARK-based systems wrap their proofs in a final Groth16 or PLONK proof for cheap on-chain or on-device verification, landing in the tens-of-KB to sub-KB range. One caveat: that final wrap reintroduces pairing-based cryptography, so if post-quantum resistance is a requirement, stay with the raw hash-based STARK and accept the larger proof.

What this means outside crypto: any batch computation whose correctness a third party must trust (a settlement run, a compliance calculation, an ML inference) can now carry a proof for cents. The cost objection to ZK is largely dead for server-side proving.

"The 45x cost collapse in one year means the question changed from 'can we afford to prove this' to 'what is worth proving'."

Can you prove things on a phone or in a browser?

Yes, within limits, and this is where the most interesting non-crypto products live:

• Mobile proving. The Mopro toolkit wraps Circom, Halo2, and Noir provers for iOS and Android, and native mobile proving runs up to 10x faster than the same prover in a browser via WASM (zkmopro.org). Proofs over identity documents, email contents, and small credentials are practical on a mid-range phone in seconds.
• zkEmail. Prove facts about a DKIM-signed email ("this address received a termination letter from employer X") without revealing the email. Powerful, but note the security section below: its regex component had eleven confirmed constraint bugs found by fuzzing in 2025.
• zkTLS. Prove facts about any HTTPS session, turning every website into a verifiable data source without the site's cooperation. Two architectures compete: MPC-based (TLSNotary lineage, productionized by Pluto, and Opacity with slashing-backed security) versus proxy-based (Reclaim Protocol, faster but with a weaker trust model) (tlsnotary.org). Pick MPC-based where the proven fact has adversarial value; proxy-based where speed and coverage matter more.
• ZK passports and personhood. Self, Rarimo, and Anon Aadhaar prove age, nationality, or uniqueness from government documents via NFC chips or signed QR codes. World ID has millions of verified users on Semaphore-based proofs. This category went from demo to deployed apps in about 18 months.

Where is ZK winning outside crypto?

Identity, and the timing is regulatory. Every EU member state must offer a European Digital Identity Wallet by the end of 2026 under eIDAS 2.0, and the framework explicitly favors selective disclosure. Google aimed its open-sourced Longfellow ZK library squarely at this, with age assurance as the first use case (Google, July 2025).

One pragmatic gotcha that most coverage misses: the EU wallet's current architecture reference framework mandates salted-hash credential formats (ISO mdoc and SD-JWT VC), which offer selective disclosure but at best limited unlinkability, and the cryptographic schemes that would fix that (BBS-family signatures, ZK-SNARK-based credentials) are not yet approved by SOG-IS, the EU's crypto evaluation body. That bars them from public-sector deployments for now and confines them to private-sector pilots (documented in ETSI TR 119 476). If you are building EUDI-adjacent products, design so the credential format can be swapped when approval lands. For the broader landscape of non-crypto applications, see our earlier post on ZK use cases outside crypto.

Is zkML real yet?

Half of it is. Split the term:

• Proof of inference ("this exact model produced this output") is approaching practical for small and mid-size models. Lagrange's DeepProve reports proving a full GPT-2 class (124M parameter) inference and claims order-of-magnitude speedups over the prior EZKL baseline, with the framework now open-source (Lagrange, vendor benchmark). Treat vendor numbers with care, but the trajectory is unambiguous.
• Private inference via ZK (hiding the input while proving the computation) remains niche and expensive. If input privacy is the goal, FHE or a confidential GPU is usually the better tool; we cover that trade-off in the FHE post and the decision framework.

Frontier-model zkML (proving a Llama-class inference) is still research. Anyone selling it today as production is selling a roadmap.

Which language and toolchain should you pick?

The honest default for a product team in 2026: a Rust zkVM for anything general, Noir when proof size or client-side proving forces a custom circuit. The proving overhead of a zkVM versus a hand-tuned circuit is real, but proving costs fell far enough that engineering time now dominates the equation for most applications.

What breaks? The security failure modes.

• Under-constrained circuits are the dominant bug class. A missing constraint means the verifier accepts proofs of false statements, silently. The zkFuzz research tool found 85 bugs, including 59 zero-days with 39 confirmed by developers, across 452 public circuits (arXiv 2504.11961). Budget for both an audit and fuzzing; they catch different bugs.
• Audits are necessary, not sufficient. RISC Zero paid a 50,000 dollar bounty for a soundness bug found after prior audits. ChainLight found a soundness bug in zkSync Era's production ZK-EVM in 2023. The takeaway is not "these teams are careless", they are among the best in the field. It is that ZK soundness bugs are uniquely hard to see and uniquely catastrophic, so layered assurance (audit, fuzzing, formal verification, bounty) is the norm now.
• Avoid per-application trusted setups. The first documented in-the-wild ZK exploits targeted circuits with mishandled Groth16 trusted setups, not the proof math (zkSecurity, 2025). STARK-family transparent systems make the whole ceremony unnecessary, which is one reason the Ethereum Foundation's real-time proving spec simply bans trusted setups.