feat(avm)!: Derive is_infinite flag from point coordinates#22564
Open
MirandaWood wants to merge 8 commits into
Open
feat(avm)!: Derive is_infinite flag from point coordinates#22564MirandaWood wants to merge 8 commits into
is_infinite flag from point coordinates#22564MirandaWood wants to merge 8 commits into
Conversation
8f3f2d6 to
50d4a19
Compare
IlyasRidhuan
approved these changes
Apr 21, 2026
1ede827 to
09131db
Compare
a76c688 to
ed831c6
Compare
09131db to
b01d712
Compare
MirandaWood
added a commit
that referenced
this pull request
May 12, 2026
…#22921) This branch solely contains the changes needed to remove the `is_infinite` flag from our `StandardAffinePoint` C++ wrapper. Now, we check whether `x` and `y` are zero to assign an `inf` underlying point. Will close [Foundation AVM Issue 17](https://linear.app/aztec-foundation/issue/AVM-17/remove-is-inf-flag-from-avms-standardaffinepoint) --- Stack: - #22745 - #22564 - `mw/avm-rem-inf-point-wrapper` <-- here - #22795 - #22945 - #23031
MirandaWood
added a commit
that referenced
this pull request
May 12, 2026
…y) (#22795) This branch includes the changes to remove the `is_infinite` flag from our point representation and conceptually treating a point as infinite iff its coordinates are `(0, 0)`. It only contains logic changes within the AVM for the above and does not touch the opcode - this is in a lower PR - so the **CI will probably fail**. Will close [Foundation AVM Issue 18](https://linear.app/aztec-foundation/issue/AVM-18/remove-is-inf-flag-from-resulting-ec-points-in-avm-circuits) --- Stack: - #22745 - #22564 - #22921 - `mw/avm-explore-remove-is-inf` <-- here - #22945 - #23031
MirandaWood
added a commit
that referenced
this pull request
May 13, 2026
…#22945) This branch includes the changes to remove the `is_infinite` flags from the ECADD opcode fn signature. The actual EC logic changes come above this PR in the stack, and any changes outside the AVM will be below. For ease of review, I've separated into commits: - **feat: remove inf flags from ecadd opcode - ec flow only** Isolated to the EC flow only (does not change registers so non avm tests will fail) - f**eat: rem infs from fuzzer (only gadget fuzzer tested)** Isolated fixes to get the fuzzer(s) compiling Will partially close [Foundation AVM Issue 19](https://linear.app/aztec-foundation/issue/AVM-19/) (the following PR #23031 with ts/rs changes will fully close it). Note that the opcode mismatches that in ts so **CI will fail** until #23031 is merged into this branch! --- Stack: - #22745 - #22564 - #22921 - #22795 - `mw/avm-rem-inf-opcode-ecadd` <-- here - #23031
MirandaWood
added a commit
that referenced
this pull request
May 15, 2026
… AVM only) (#23031) This branch includes the changes to remove the `is_infinite` flags from the ECADD opcode fn signature which reside outside `vm2`. This includes the transpiler, ts simulator, and anything required in ACIR. Note that ACIR and noir's black box still use [the flags](https://github.com/AztecProtocol/aztec-packages/blob/b30fe8f401d7af45148071924b22b3f377750eaf/barretenberg/cpp/src/barretenberg/dsl/acir_format/ec_operations.hpp#L34) and represent points by a[ triple of elements.](https://github.com/noir-lang/noir/blob/bc4a37e2994ebc7d44ae98be81e18606b2231c61/acvm-repo/bn254_blackbox_solver/src/embedded_curve_ops.rs#L98) Since this touches both private and public execution, I think it's out of scope of this task to update these. Will partially close [Foundation AVM Issue 19](https://linear.app/aztec-foundation/issue/AVM-19/) (the previous PR with AVM changes will close the initial portion) --- Stack: - #22745 - #22564 - #22921 - #22795 - #22945 - `mw/avm-rem-inf-opcode-ecadd-ext` <-- here
MirandaWood
added a commit
that referenced
this pull request
May 15, 2026
…#22921) This branch solely contains the changes needed to remove the `is_infinite` flag from our `StandardAffinePoint` C++ wrapper. Now, we check whether `x` and `y` are zero to assign an `inf` underlying point. Will close [Foundation AVM Issue 17](https://linear.app/aztec-foundation/issue/AVM-17/remove-is-inf-flag-from-avms-standardaffinepoint) --- Stack: - #22745 - #22564 - `mw/avm-rem-inf-point-wrapper` <-- here - #22795 - #22945 - #23031
814108b to
5d86655
Compare
MirandaWood
added a commit
that referenced
this pull request
May 15, 2026
…y) (#22795) This branch includes the changes to remove the `is_infinite` flag from our point representation and conceptually treating a point as infinite iff its coordinates are `(0, 0)`. It only contains logic changes within the AVM for the above and does not touch the opcode - this is in a lower PR - so the **CI will probably fail**. Will close [Foundation AVM Issue 18](https://linear.app/aztec-foundation/issue/AVM-18/remove-is-inf-flag-from-resulting-ec-points-in-avm-circuits) --- Stack: - #22745 - #22564 - #22921 - `mw/avm-explore-remove-is-inf` <-- here - #22945 - #23031
MirandaWood
added a commit
that referenced
this pull request
May 15, 2026
…#22945) This branch includes the changes to remove the `is_infinite` flags from the ECADD opcode fn signature. The actual EC logic changes come above this PR in the stack, and any changes outside the AVM will be below. For ease of review, I've separated into commits: - **feat: remove inf flags from ecadd opcode - ec flow only** Isolated to the EC flow only (does not change registers so non avm tests will fail) - f**eat: rem infs from fuzzer (only gadget fuzzer tested)** Isolated fixes to get the fuzzer(s) compiling Will partially close [Foundation AVM Issue 19](https://linear.app/aztec-foundation/issue/AVM-19/) (the following PR Note that the opcode mismatches that in ts so **CI will fail** until --- Stack: - #22745 - #22564 - #22921 - #22795 - `mw/avm-rem-inf-opcode-ecadd` <-- here - #23031
MirandaWood
added a commit
that referenced
this pull request
May 15, 2026
… AVM only) (#23031) This branch includes the changes to remove the `is_infinite` flags from the ECADD opcode fn signature which reside outside `vm2`. This includes the transpiler, ts simulator, and anything required in ACIR. Note that ACIR and noir's black box still use [the flags](https://github.com/AztecProtocol/aztec-packages/blob/b30fe8f401d7af45148071924b22b3f377750eaf/barretenberg/cpp/src/barretenberg/dsl/acir_format/ec_operations.hpp#L34) and represent points by a[ triple of elements.](https://github.com/noir-lang/noir/blob/bc4a37e2994ebc7d44ae98be81e18606b2231c61/acvm-repo/bn254_blackbox_solver/src/embedded_curve_ops.rs#L98) Since this touches both private and public execution, I think it's out of scope of this task to update these. Will partially close [Foundation AVM Issue 19](https://linear.app/aztec-foundation/issue/AVM-19/) (the previous PR with AVM changes will close the initial portion) --- Stack: - #22745 - #22564 - #22921 - #22795 - #22945 - `mw/avm-rem-inf-opcode-ecadd-ext` <-- here
Collaborator
Flakey Tests🤖 says: This CI run detected 1 tests that failed, but were tolerated due to a .test_patterns.yml entry. |
is_infinite flag from point coordinatesis_infinite flag from point coordinates
…#22921) This branch solely contains the changes needed to remove the `is_infinite` flag from our `StandardAffinePoint` C++ wrapper. Now, we check whether `x` and `y` are zero to assign an `inf` underlying point. Will close [Foundation AVM Issue 17](https://linear.app/aztec-foundation/issue/AVM-17/remove-is-inf-flag-from-avms-standardaffinepoint) --- Stack: - #22745 - #22564 - `mw/avm-rem-inf-point-wrapper` <-- here - #22795 - #22945 - #23031
…y) (#22795) This branch includes the changes to remove the `is_infinite` flag from our point representation and conceptually treating a point as infinite iff its coordinates are `(0, 0)`. It only contains logic changes within the AVM for the above and does not touch the opcode - this is in a lower PR - so the **CI will probably fail**. Will close [Foundation AVM Issue 18](https://linear.app/aztec-foundation/issue/AVM-18/remove-is-inf-flag-from-resulting-ec-points-in-avm-circuits) --- Stack: - #22745 - #22564 - #22921 - `mw/avm-explore-remove-is-inf` <-- here - #22945 - #23031
…#22945) This branch includes the changes to remove the `is_infinite` flags from the ECADD opcode fn signature. The actual EC logic changes come above this PR in the stack, and any changes outside the AVM will be below. For ease of review, I've separated into commits: - **feat: remove inf flags from ecadd opcode - ec flow only** Isolated to the EC flow only (does not change registers so non avm tests will fail) - f**eat: rem infs from fuzzer (only gadget fuzzer tested)** Isolated fixes to get the fuzzer(s) compiling Will partially close [Foundation AVM Issue 19](https://linear.app/aztec-foundation/issue/AVM-19/) (the following PR Note that the opcode mismatches that in ts so **CI will fail** until --- Stack: - #22745 - #22564 - #22921 - #22795 - `mw/avm-rem-inf-opcode-ecadd` <-- here - #23031
… AVM only) (#23031) This branch includes the changes to remove the `is_infinite` flags from the ECADD opcode fn signature which reside outside `vm2`. This includes the transpiler, ts simulator, and anything required in ACIR. Note that ACIR and noir's black box still use [the flags](https://github.com/AztecProtocol/aztec-packages/blob/b30fe8f401d7af45148071924b22b3f377750eaf/barretenberg/cpp/src/barretenberg/dsl/acir_format/ec_operations.hpp#L34) and represent points by a[ triple of elements.](https://github.com/noir-lang/noir/blob/bc4a37e2994ebc7d44ae98be81e18606b2231c61/acvm-repo/bn254_blackbox_solver/src/embedded_curve_ops.rs#L98) Since this touches both private and public execution, I think it's out of scope of this task to update these. Will partially close [Foundation AVM Issue 19](https://linear.app/aztec-foundation/issue/AVM-19/) (the previous PR with AVM changes will close the initial portion) --- Stack: - #22745 - #22564 - #22921 - #22795 - #22945 - `mw/avm-rem-inf-opcode-ecadd-ext` <-- here
5d86655 to
af9e010
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Update
Will also close Foundation AVM Issue 13
Note that this is currently being used as a base for removing the flag from AVM's point representation (Foundation AVM Issue 14):
fix(avm): AVM gadget fuzzers fixes #22745(in merge train)is_infiniteflag from AVM ECC & update noir submodule with serialization changes #23342 (ACIR changes from chore: update noir submodule with serialization changes #23155 for removinginf)is_infiniteflag from point coordinates #22564 <-- hereis_infiniteflag from point wrapper constructor #22921 ✅is_infiniteflag from AVM (PIL and EC points only) #22795 ✅is_infiniteflags from ECADD opcode (outside AVM only) #23031 ✅Everything in this branch has been reviewed, see above PRs for individual work ⬆️
[OLD] Overview
Will close AVM-248
As a kind of stopgap before removing the
is_infiniteflag completely from the AVM (AVM-266), we now follow Noir behaviour more closely by derivingis_inffrom coordinates inside the circuits ((x, y) == (0, 0) ? is_inf == true). This replaces previous logic remapping points to (0, 0) fromis_inf.This method relies on the on curve check (for
(0, 0) ==> is_inf) and some new relations enforcing coordinates (foris_inf ==> (0, 0)) rather than (more expensive) error handling. However this does mean that the former will fail with an on curve error whereas the latter will simply fail a relation.