Implementation of the R1CS compiler

[juja256]

Hello!
Despite, informally arithmetic circuits in this implementation are named "r1cs" they aren't actually true R1CS circuits in their canonical form
$A\mathbf{z} \circ B\mathbf{z} = C\mathbf{z}$. Current circuits representation is, without a doubt, a great and convenient one, but I'm wondering:

• why the current implementation calls arithmetic circuits "R1CS" while they are not actually in canonical "R1CS" form.
• if you have any plans for implementing true R1CS circuits compiler that could for example be compatible (in terms of circuit representation/encoding etc.) with other R1CS compilers, such as circom etc. Bunz in his thesis paper presented a bulletproofs variant for R1CS circuits with committed witness (into only one curve point, despite the original arithmetic circuits protocol where each witness scalar must be committed separately). After that Gil Segev revised a security proof that bridges a completness-soundness gap of the original Bunz work additionally achieving zero-knowledge with a zero-knowledge variant of the inner product argument.
  @cathieyun

[cathieyun]

You are correct, we are slightly abusing the "R1CS" terminology here. We originally implemented our library to have a compatible R1CS API with the Zcash Groth16 library, so that you could build a "R1CS circuit" that was generic over Groth16 and Bulletproofs. That's what informed the design (as well as the limitations of what you could do with Bulletproofs, at the time of implementation).

We don't have plans for implementing a true R1CS circuit compiler, but could be open to contributions from the community.