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!