VOLE-based ZK

What it enables

An open source VOLE-based prover facilitates rapid identity proofs while maintaining privacy on consumer hardware. It addresses the challenge that privacy-preserving proofs typically require expensive server infrastructure, yet interesting proofs like passport and email verification demand computationally intensive operations (RSA, SHA256, Keccak256). The system integrates existing audited circom circuit implementations, enabling mobile browsers to complete passport proofs within seconds without memory constraints.

How it works

The implementation employs VOLE in the head with a modified linear code based on the repeat-multiple-accumulate (RMA) code. This approach achieves dramatically better efficiency than mainstream proving systems, though sacrifices the succinctness needed for rollups. The “in the head” variant introduces roughly 2x performance overhead to enable noninteractivity, which the RMA code optimization helps mitigate.

VOLE-based ZK operates through two sequential phases:

1. Commitment / Preprocessing

VOLE execution creates a two-party commitment where the verifier obtains functions describing collinear points and the prover receives random points along those lines. Neither party accesses the other’s values. A prover demonstrates commitment opening by revealing one point to the verifier.

A derandomization step transforms the random value commitments into witness commitments.

2. Proving

Addition gates resolve trivially — the verifier simply adds her commitments. The linearly homomorphic nature of the VOLE commitment scheme makes all linear operations straightforward.

Multiplication gates require additional work: the prover submits committed values and furnishes correctness proofs using Quicksilver.

Once all gate outputs become known to the verifier, she may request the prover to reveal any public outputs.

Making It Noninteractive

A SoftSpokenOT-derived VOLE variant enables noninteractivity by ensuring prover-received outputs remain independent from the verifier’s randomness choices. This permits Fiat-Shamir generation of the verifier’s randomness.

However, this VOLE variant severely restricts the verifier’s random value options, creating a significant security vulnerability — in this case, only two possibilities exist. Linear codes counteract this by requiring the prover to correctly guess at least d secrets (where d represents the code’s minimum distance), substantially raising the security threshold.