privacy-scaling-explorations / sonobe

Experimental folding schemes library
https://privacy-scaling-explorations.github.io/sonobe-docs/
MIT License
205 stars 54 forks source link

When generating parameters, circom frontend should handle `ivc_input[i] * ivc_input[j] == c` types of constraints #104

Open dmpierre opened 6 months ago

dmpierre commented 6 months ago

When using the circom frontend, users will not be able to specify constraints equalling a constant c different from 0 (e.g. ivc_input[i] * ivc_input[j] == c). This is due to the fact that z_0, z_i are initialized as [0, ..., 0] here.

arnaucube commented 6 months ago

I'm unsure to understand this issue. The linked line sets to 0 only in the cases where the z_i is not set, which only happens when initializing the circuit (prior to setting any state value) in order to generate the r1cs constraints (but it does not check that the constraints are satisfied, so it should not be failing due this). Later, when doing the folding steps z_i takes the user defined value. Could you provide an example of circuit that triggers this error in order to debug it a bit?

dmpierre commented 6 months ago

Sorry, opened the issue quickly before leaving yesterday! Here are some details.

Posted an example [here](). The issue stems from the fact that examples generate params using init_ivc_and_decider_params. This will call get_r1cs, which in turn will call the generate_constraints method of the AugmentedFCircuit. This will trigger a check on whether the constraint system of the CircomFCircuit is satisfied or not. At that point z_i will be initialized as a zero vector.

I think that its important to track this one, since init_ivc_and_decider_params, although commented as for testing purposes, is used in most of the examples and tests across the repo. We might also want in the future to remind ourselves of this when writing the production-ready methods generating parameters.

arnaucube commented 6 months ago

Right, I see. Thanks for the details! This seems to be an issue of the Circom frontend, I was initially thinking that it might be regarding Nova logic. The check is inside generate_step_constraints of the CircomFCircuit, and the error does not happen on the arkworks frontend.

Maybe a solution is just to disable the line that checks cs.is_satisfied() in the circom frontend (frontend/circom/mod.rs#L124) for when the generate_step_constraints is called just to generate the r1cs constraints but not for doing actual folds.

Because this will happen not only with the described line from this issue, but with any circuit that expects the inputs to not be zeroes, where for the initialized nova (which uses zeroes to all values) will not satisfy the constraints of the FCircuit, which is normal.

dmpierre commented 6 months ago

c278b93 temporary disables constraints checks. In the future, we would like to:

  1. Keep this check
  2. Have a configuration conditional to disable it when running in --release mode