Source: Proofs, Arguments, and Zero-Knowledge, Section 18.5

Relaxed R1CS

We’ll prove knowledge of a witness for a relaxed R1CS instance.

We’ll have the following public values:

  • Matrices
  • Vectors
  • Scalar

An the following committed values:

  • Witness vector
  • Slack vector

Let , . We want to make the claim that:

Folding two instances

Let be randomly picked by the verifier. Then, we set:

Where are the cross-terms:

The result is also a valid relaxed R1CS instance! The prover can commit to , , and using a homomorphic vector commitment, then the validator samples

A Large non-interactive Argument

For each application of the circuit, the verifier keeps track of:

  • The current round number
  • The values and (determining )
  • The values
  • : The commitment to
  • : The commitment to

The protocol proceeds as follows:

  • In each round, the prover sends , , and
  • In round 1, the verifier sends the round number to 1, , (the input to the incremental computation), and to a commitment to the vectors of all s
  • Otherwise, the verifier increments the round number and updates the running instance as described above
  • In the final round, the prover also outputs a SNARK for the folded instance, e.g. using a generalization of Spartan with Bulletproofs

The proof is the concatenation of all the values kept track of by the verifier + the final SNARK.

Proving the folding

Idea: Augment the circuit to do the verifier’s work in each step:

  • All verifier’s variables become public inputs
  • All prover inputs become private input (except , which the circuit already computes)
  • The new values of the verifier’s variables become public output
    • Question: How do we make sure these outputs are actually used as inputs in the next step?

The extra work that has to be computed in the circuit amounts to:

  • Invoking a cryptographic hash function to obtain via the Fiat-Shamir transformation
  • A few field multiplications and additions over
  • Computing the updates of the homomorphic commitments
    • Dominates the recursion overhead if the hash function is SNARK-friendly
    • In the case of Pedersen Commitments: One group exponentiation and one group multiplication for each of the two commitments

One needs a cycle of curves, but they do not need to be pairing-friendly. The original function needs to be efficiently computable over both fields!