Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: use subtraction with reduce in AssertIsEqual #1026

Merged
merged 2 commits into from
Jan 30, 2024

Conversation

ivokub
Copy link
Collaborator

@ivokub ivokub commented Jan 30, 2024

Thanks @hussein-aitlahcen for reporting and helping to debug. It was a difficult one 👍

Description

To show that two field elements are equal, we instead show that the difference of the field elements is a multiple of emulated modulus. However, for computing the difference we used non-reducing version of subtraction to avoid infinite cycles. With the new mulmod implementation the reducing versions do not call AssertIsEqual anymore so the infinite cycles are averted. Previously, for some edge cases the difference may overflow scalar field and solving may fail (see here)

Fixes #1021

Type of change

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

How has this been tested?

Existing tests succeed.

  • Added TestIssue1021 for the minimal reproducible example.

How has this been benchmarked?

Not benchmarked.

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

To show that two field elements are equal, we instead show that the difference
of the field elements is a multiple of emulated modulus. However, for computing
the difference we used non-reducing version of subtraction to avoid infinite
cycles. With the new mulmod implementation the reducing versions do not call
AssertIsEqual anymore so the infinite cycles are averted. For some edge cases
the difference may overflow scalar field and solving may fail.
@ivokub ivokub added the bug Something isn't working label Jan 30, 2024
@ivokub ivokub requested a review from gbotrel January 30, 2024 13:01
@ivokub ivokub self-assigned this Jan 30, 2024
Copy link
Collaborator

@gbotrel gbotrel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One line PRs are easy to review :) .
This aside -- is it possible to write a test case that would have catch this in the emulated package? (non-regression purposes)

@ivokub
Copy link
Collaborator Author

ivokub commented Jan 30, 2024

One line PRs are easy to review :) . This aside -- is it possible to write a test case that would have catch this in the emulated package? (non-regression purposes)

Indeed! I forgot to include the regression test as I already had a test case when debugging for #1021, but didn't include here. I simplified it to make it as minimal as possible.

@ivokub ivokub merged commit 4b10f00 into master Jan 30, 2024
7 checks passed
@ivokub ivokub deleted the fix/emulated-assertequal-reduce branch January 30, 2024 17:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

bug: pairing check failing in computeLines
2 participants