add simplification flags to usage guide

[Metachaser24]

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context.
Mention the issue number that your changes are addressing. Use the format "Fixes #" to automatically link your pull request to the relevant issue.

Type of Change

documentation update. Added -O0 flag to the compilation step

Checklist:

[Divide-By-0]

Can you add a note about not using the default which is --O2 due to a hyperlink to addition constraint deletion: https://stackoverflow.com/questions/78136647/circom-does-not-create-a-constraint-for-addition

[saleel]

@Divide-By-0 Addition constraints are removed during optimization by subtracting the added value from out instead..right?
out = a * b + c become out - c = a * b, but the addition is still part of the R1CS?

[Divide-By-0]

Hmm, I'm under the impression there are cases where addition is removed from the r1cs. See https://stackoverflow.com/questions/78136647/circom-does-not-create-a-constraint-for-addition/78177349#78177349

And

https://stackoverflow.com/questions/77688466/circom-compiler-removes-crucial-constraint-after-simplication/78177354?noredirect=1#comment137833229_78177354

@Metachaser24 can you add these links as references to the docs?

[Metachaser24]

yes adding now

[saleel]

Did a quick test:

signal d <== b + 5;
c === a * d;

With -O0

[  ] * [  ] - [ 51 +main.b +21888242871839275222246405745257275088548364400416034343698204186575808495616main.d ] = 0
[ 21888242871839275222246405745257275088548364400416034343698204186575808495616main.a ] * [ main.d ] - [ 21888242871839275222246405745257275088548364400416034343698204186575808495616main.c ] = 0

With -O2

[ 21888242871839275222246405745257275088548364400416034343698204186575808495616main.a ] * [ 51 +main.b ] - [ 21888242871839275222246405745257275088548364400416034343698204186575808495616main.c ] = 0

Even though addition constraint is removed in O2, the result is effectively same. The addition output gets added on to the next constraint where its used.

Even when circuit has only one addition contract we cannot generate witness that doesn't match the condition even though r1cs are empty.
Edit: ^ this might be a property of snarkjs, and doesn't mean its not possible to produce fake witnesses that pass using other approaches

[saleel]

@Divide-By-0 @Metachaser24 I think O2 (default) should be used ideally as it reduce the total constraints without loosing intended assertions.
Or am I missing something?

[Divide-By-0]

@Divide-By-0 @Metachaser24 I think O2 (default) should be used ideally as it reduce the total constraints without loosing intended assertions. Or am I missing something?

I think there are cases where they do corrupt the logic of the circuit. One example is an addition constraint unconnected to anything else -- we used to have this for address plus one which wasn't constrained -- Pierre made a fake input pass for a similar case. I'm worried the pattern appears for other combinations of + and * as well.

[Divide-By-0]

In the worst case, it also gives proof malleability -- i.e. a nullifier constraint might have an addition somewhere then people might be able to forge a different nullifier that technically proves knowledge of preimage, but may not satisfy uniqueness any longer (since that specific value is no longer constrained).

[Divide-By-0]

Good to merge after resolving merge conflicts!