Fix: edge cases in std/algebra elliptic curve arithmetic circuit (emulated and 2-chains)

[yelhousni]

Description

• Fix edge cases in std/algebra involving scalars 0 and points (0,0) using the UseSafe option.
• Fix bug when scalar is 1 in scalarMulGeneric, scalarBitsMulGeneric and related methods.
• Fix fix: PLONK verifier gadget in-circuit without commitments #964 (but the fix is commented out to save constraints for the cases with appi.Commit that we use in Linea)

Type of change

• Bug fix (non-breaking change which fixes an issue)

How has this been tested?

• Current tests
• New tests for missing methods
• New tests taking into accounts all edge cases

How has this been benchmarked?

Constraints count doesn't change when UseSafe option is not used (except for scalarMulGeneric), which is what interests us the most for our use-cases. The option is to capture all edge cases in all use-cases.
Best thing forward is to add relevant emulated circuits to internal/stats.

Checklist:

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• I did not modify files generated from templates
• golangci-lint does not output errors locally
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[ivokub]

Looks good, however I think for scalarmul by constant we can have fast paths which do not perform computations.

Dunno about PLONK verifier options though - I think they are good to have but not essential. I think we can implement them later (but creating an issue for tracking), it is up to you.

[yelhousni]

Looks good, however I think for scalarmul by constant we can have fast paths which do not perform computations.

Dunno about PLONK verifier options though - I think they are good to have but not essential. I think we can implement them later (but creating an issue for tracking), it is up to you.

Applied fast path for constScalarMul when s==0. For the case s==1 I didn't do it since we never use this method anyway and we can also specialize paths for s==2 and so on.. but s==0 is just to have the exposed method working for all cases even if it's never used in our use-cases. For the plonk option I will create an issue and close this PR. Wdyt?

[ivokub]

Applied fast path for constScalarMul when s==0. For the case s==1 I didn't do it since we never use this method anyway and we can also specialize paths for s==2 and so on.. but s==0 is just to have the exposed method working for all cases even if it's never used in our use-cases. For the plonk option I will create an issue and close this PR. Wdyt?

Yep, I agree - lets only handle s==0 in the fast path and everything else in regular path. Your changes look good 👍 !

And I also agree with handling PLONK verifier options in separate PR. It is nice to have but nothing critical.