feat: allow avoiding commitments in non-native arithmetic using constant points for Schwartz-Zippel lemma

[ivokub]

The commitments are optional in the sense that if the circuit definition doesn't use the features which require commitment, then we do not compute it. However, there are two main features which currently have hard-dependency on commitments:

• non-native arithmetic
• range checking

For range checking it is essentially possible to override the frontend.Builder to omit the Commit method which forces to use less efficient method for range checking (binary decomposition).

But for non-native arithmetic we do not have such override yet. It can be essentially done as instead of doing Schwartz-Zippel lemma on random point we evaluate at n constant points where n is degree of the polynomials we check. For Groth16 it shouldn't increase the circuit size too much actually, but requires a lot of refactoring.

We do not have it planned yet, but imo it would be a good option to have. I'll rename the issue to keep track of it in the future when planning further releases.

[zilong-dai]

cool. thx

[zilong-dai]

I have impl Check() method and remove Commit() method to use the the native rangechecker like https://github.com/zilong-dai/gnark/commit/ada9b5b3dcb7f53725dda79fb69babc87ef017e9. I wondered if there are some security issues.

[ivokub]

If you have just removed it and the circuit compiles, then should be no issue.

[zilong-dai]

ok, thanks a lot