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!