Implement Flag-Based Verification for Recursive SNARK Proofs & In-Circuit Signatures

[lucasmenendez]

Description

This PR addresses issue #1429 by introducing a more flexible mechanism for recursive proof verification. Instead of immediately asserting proof validity (via api.Assert), the new approach returns a flag—1 for valid and 0 for invalid—that can be conditionally enforced later. This design allows developers to aggregate multiple proofs (even when some are intentionally invalid) and decide which ones must be fully verified.

Key changes include

• ProofIsValid: A new method for the in-circuit Groth16 proof verifier that returns a verification flag instead of asserting immediately.
• SignIsValid: A similar method for ECDSA in-circuit signatures, returning the result of the assertion rather than forcing it.
• In-circuit Algebra Field Enhancements: New methods such as IsEqual, IsZero, and IsOnCurve to provide more nuanced in-circuit comparisons.
• Pairing Interface Update: The in-circuit Pairing interface now includes a new IsEqual method that returns a flag, aligning with the behavior of ProofIsValid and SignIsValid.

This is an initial implementation that works well and passes all tests, paving the way for more comprehensive support for flexible, conditional proof verification.

Fixes #1429

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How has this been tested?

• All tests pass locally.
• Tested on existing recursive verification circuits to ensure that the new flag-based approach correctly accumulates proof validity.
• Practical example here (proof verification) and here (signature check).

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 (not needed)
• 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