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

Avoiding zero in bach muls #905

Open
Tracked by #911
codygunton opened this issue Mar 12, 2024 · 1 comment
Open
Tracked by #911

Avoiding zero in bach muls #905

codygunton opened this issue Mar 12, 2024 · 1 comment

Comments

@codygunton
Copy link
Collaborator

codygunton commented Mar 12, 2024

As in the case of AztecProtocol/aztec-packages#5174, we sometimes encounter issues relating to our inability to handle scalar multiplication of EC points in the case where the scalar is 0. I believe: this could be fixed by simply checking whether z==0 before https://github.com/AztecProtocol/aztec-packages/blob/394a0e06928946c1c9eea1bdfec39269cb2d601a/barretenberg/cpp/src/barretenberg/ecc/groups/element_impl.hpp#L68, but we avoid this because of the cost of the check. Someone should determine whether this is really a concern, and if it is, we should identify some hot code paths and use a more robust method outside of those cases.

codygunton added a commit to AztecProtocol/aztec-packages that referenced this issue Mar 13, 2024
We systematize the work of
#4751 to avoid
scalar multiplication by 0, an issue that has arisen in various ways. In
our case, the acir test `6_array` was reliably failing (failing the with
`Trying to invert zero in the field`) about 1/256 of the time. The error
was thrown from
https://github.com/AztecProtocol/aztec-packages/blob/394a0e06928946c1c9eea1bdfec39269cb2d601a/barretenberg/cpp/src/barretenberg/ecc/groups/element_impl.hpp#L68
coming from this line in Zerormorph verification
https://github.com/AztecProtocol/aztec-packages/blob/394a0e06928946c1c9eea1bdfec39269cb2d601a/barretenberg/cpp/src/barretenberg/commitment_schemes/zeromorph/zeromorph.hpp#L622
Spawning an issue to handle this situation more systmatically:
AztecProtocol/barretenberg#905

The PR allowed the acir test to be run more than 512 times without any
issue.
AztecBot pushed a commit that referenced this issue Mar 14, 2024
We systematize the work of
AztecProtocol/aztec-packages#4751 to avoid
scalar multiplication by 0, an issue that has arisen in various ways. In
our case, the acir test `6_array` was reliably failing (failing the with
`Trying to invert zero in the field`) about 1/256 of the time. The error
was thrown from
https://github.com/AztecProtocol/aztec-packages/blob/394a0e06928946c1c9eea1bdfec39269cb2d601a/barretenberg/cpp/src/barretenberg/ecc/groups/element_impl.hpp#L68
coming from this line in Zerormorph verification
https://github.com/AztecProtocol/aztec-packages/blob/394a0e06928946c1c9eea1bdfec39269cb2d601a/barretenberg/cpp/src/barretenberg/commitment_schemes/zeromorph/zeromorph.hpp#L622
Spawning an issue to handle this situation more systmatically:
#905

The PR allowed the acir test to be run more than 512 times without any
issue.
@ledwards2225
Copy link
Collaborator

The use of the ECCOpQueue::append_nonzero_ops method on all circuits is inadvertently creating an interesting test case. Since this method updates the op queue ONLY (ultra and raw ops) but NOT the ecc_op block in the circuit, the translator and ECCVM are operating on a different set of ops from that of the Ultra circuit / Honk prover / Merge protocol. Eventually this discrepancy should lead to a proof that fails to verify but we need to think more about exactly where this should happen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants