ETHPragueConf 2025

Client-side proving and the future of World
05-27, 15:30–15:55 (CET), Root

Why client-side proving is a pre-requisite for privacy, our new client side proving efforts at World and how they are impacting our identity roadmap in the immediate to mid term.


ProveKit GitHub
Bringing privacy to everyone - Performant client-side proving for (the) World, a 🧵:

Constraints:
- 23M users around the globe, needs to be accessible
- hardware constraints on tail end distribution of low-end mobile phones
- true privacy requires client-side ZK and soundness
- products like NFC ID (passport proofs) have high blow up factors on constraints due to non-ZK friendly hashes, sig schemes, encryption, ...
- circuits should be ideally proven in < 1 min (UX)
- circuits can have up to 2^24 constraints
- World App binary size can't increase
- low end devices have up to 1 GB of free RAM or less available for the proving process
- since binary size can't grow on a per circuit basis, the proving system has to be transparent
- proofs need to be succinct, ideally constant size, verifiable onchain
- onchain calldata on World Chain is a bottleneck, with existing groth16 proof volume from World ID, you have ~20% of all execution gas and calldata consumed by g16 proof verifcations. ~10% with bn254 point compression
- ideally proofs can be aggregated with a lot of volume, assuming a latency gain tradeoff (time + < 1 extra min) to minimize onchain footprint
- fast serverside recursion of client-side proofs that are not succinct, succinctness is gained serverside
These constraints truly represent what one needs to solve in order to bringing truly scalable and privacy preserving ZK identity to the World. What products does this enable to reach the masses within ZK ID you may ask?
- Web proofs: Pluto, Opacity, Reclaim Protocol
- Storage proofs (assuming true eth light clients exist in the future): Herodotus Axiom, Lagrange
- ZKEmail
- zkLogin, zkJWT
- ZK KYC: ZK Passport, Self, Rarimo, World ID

OK This is all super cool, but how do you solve this?
Remco has been doing lots and lots of R&D (more at 2π.com together with the TFH applied research team and several external contributing parties.

  • Front-end: the Noir DSL - several ZK ID primitives above have implementations in Noir and we believe it's a best in class robust and ergonomic tool for ZK developers, huge improvement over Circom and easier to write (cryptography-agnostic frontend).

  • Proving system: Spartan NIZK by Srinath Setty

  • IOP/commitment scheme: WHIR by Giacomo Fenzi

  • Hash function: Skyscraper (even with recent attacks, with more rounds it can become secure, still faster than Poseidon2, time will tell)

  • Skyscraper paper

  • Attack on Skyscraper
  • Groth16 recursive Spartan verifier to achieve succinctness. We only care about achieving ZK (no private data / witness will ever appear serverside -> privacy achieved on the client) and soundness.
  • EVM groth16 verifier, also one Spartan proof != 1 g16, you can have a general g16 circuit aggregating an arbitrary amount of g16 proofs as big as the powers of Tau allow (2^28 constraints max Ptau)
  • client-side low level optimizations on the prover for ARM
  • GPU acceleration for the g16 prover serverside using Ingonyama's ICICLE (optional)
  • Rei Labs also has full formal verification pipelines for any gnark and Noir circuits using a circuit to Lean 4 extractor
    (1, 2)
  • ETHZurich Talk
  • NoirHack Talk

Research Engineer @ World Foundation. AGI believer. math. Ethereum. ZK. Rust. Angel investor.

This speaker also appears in: