Skip to content

feat(aztec-nr)!: Remove nr Point struct in favour of EmbeddedCurvePoint#23392

Merged
MirandaWood merged 1 commit into
nextfrom
mw/rem-nr-point-struct
May 22, 2026
Merged

feat(aztec-nr)!: Remove nr Point struct in favour of EmbeddedCurvePoint#23392
MirandaWood merged 1 commit into
nextfrom
mw/rem-nr-point-struct

Conversation

@MirandaWood
Copy link
Copy Markdown
Contributor

@MirandaWood MirandaWood commented May 19, 2026

Summary

Removes the Point struct from aztec-nr in favour of Noir's native EmbeddedCurvePoint, now that we use the two element point representation. Largely nr changes but requires corresponding updates to ts.

Will close AVM Linear issue 15.

Partially based on this previous commit. for the portions just removing the nr struct. AVM changes are in the above linked PR or in #23342.

TODO/Outstanding

Update: Only small TODOs left over - see comments/code

  • Once the above public key changes are in (Linear issue AVM 22), most hacks/temp hashing solutions will be removed
  • Use a re-export for point.nr to expose the noir class
  • Empty classes
    • Note that the ts Point class still contains an is_infinite bool (from the previous work I based this on), which means ts serialisation often includes this extra element. This can be very awkward with infinity points. If we allow empty Point class instances in ts with this bool, then (0, 0) can mean [0, 0, true] OR [0, 0, false].
    • UPDATE: complete We could remove the is_infinite bool from the ts Point class so all representations are two element? The only reason I didn't do this is because the bool was kept in the previous work above.
    • Otherwise, we need to rework Empty() for classes such as KeyValidationRequest.

Closes https://linear.app/aztec-labs/issue/F-553/remove-custom-point-struct-and-use-embeddedcurvepoint-directly

@MirandaWood MirandaWood added the ci-draft Run CI on draft PRs. label May 19, 2026
Copy link
Copy Markdown
Contributor

@IlyasRidhuan IlyasRidhuan left a comment

Choose a reason for hiding this comment

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

The conflicts after merge-train will be pain but the changes largely look good

Comment thread noir-projects/aztec-nr/aztec/src/publish_contract_instance.nr Outdated
Comment thread yarn-project/foundation/src/curves/grumpkin/point.ts Outdated
Comment thread yarn-project/foundation/src/curves/grumpkin/point.ts Outdated
@MirandaWood MirandaWood force-pushed the mw/rem-nr-point-struct branch from 6a09e47 to b4c8b37 Compare May 21, 2026 17:11
Comment thread noir-projects/noir-protocol-circuits/crates/types/src/type_packing.nr Outdated
Comment thread yarn-project/stdlib/src/keys/public_key.ts Outdated
@MirandaWood MirandaWood changed the title feat(aztec-nr)!: WIP Remove nr Point struct in favour of EmbeddedCurvePoint feat(aztec-nr)!: Remove nr Point struct in favour of EmbeddedCurvePoint May 21, 2026
@MirandaWood MirandaWood marked this pull request as ready for review May 21, 2026 17:44
@MirandaWood MirandaWood requested review from Thunkar and benesjan and removed request for LeilaWang and jeanmon May 21, 2026 17:45
@MirandaWood MirandaWood added ci-full Run all master checks. and removed ci-draft Run CI on draft PRs. labels May 21, 2026
@MirandaWood MirandaWood requested a review from IlyasRidhuan May 22, 2026 08:34
Copy link
Copy Markdown
Contributor

@benesjan benesjan left a comment

Choose a reason for hiding this comment

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

LGTM!

Comment thread noir-projects/aztec-nr/aztec/src/utils/point.nr Outdated
Comment thread yarn-project/foundation/src/curves/grumpkin/point.ts Outdated
Comment thread yarn-project/stdlib/src/keys/public_key.ts Outdated
Comment thread yarn-project/foundation/src/curves/grumpkin/point.ts Outdated
@MirandaWood MirandaWood force-pushed the mw/rem-nr-point-struct branch from 7819615 to db7e934 Compare May 22, 2026 10:54
@MirandaWood MirandaWood added this pull request to the merge queue May 22, 2026
Merged via the queue into next with commit ae267e8 May 22, 2026
22 checks passed
@MirandaWood MirandaWood deleted the mw/rem-nr-point-struct branch May 22, 2026 13:20
Comment thread noir-projects/aztec-nr/aztec/src/keys/ephemeral.nr
Comment thread noir-projects/aztec-nr/aztec/src/utils/point.nr Outdated
Comment thread noir-projects/aztec-nr/aztec/src/utils/point.nr Outdated
// 4 prefix fields (salt, class_id, init_hash, immutables_hash) + 6 public-key fields + 1
// universal_deploy flag = 11.
let serialized_params: [Field; 11] = [salt, contract_class_id.to_field(), initialization_hash, immutables_hash]
// 4 prefix fields (salt, class_id, init_hash, immutables_hash) + 5 public-key fields + 1
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Are we going from 6 to 5 because we drop is_infinite?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Yep!

Comment thread yarn-project/foundation/src/curves/grumpkin/point.ts Outdated
Comment thread yarn-project/foundation/src/curves/grumpkin/point.ts
Comment thread yarn-project/simulator/src/public/avm/opcodes/ec_add.ts
Comment on lines +75 to +77
// Note: BB encodes infinity as x == y == Buffer of all ones.
// Infinity should never pass through here, but for correctness:
const ALL_ONES = (1n << 256n) - 1n;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Why do we not use the same serialization? And if we don't allow passing infinity to bb, why do we allow receiving it from it? Wouldn't it be easier to to disallow it everywhere?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I don't know why we don't use the same - the many reps of infinity has plagued us for a long time!
So yes ideally we would disallow it everywhere, but now we have no isInfinite flag that means we have two possibilities for infinities here:

  • BB's version (ALL_ONES) -> for now, I converted to inf, but can disallow
  • 'Empty' coordinates -> no flag means that this is identical to an inf, but disallowing here would mean we couldn't receive any empty points, which I imagine would cause a lot of problems
    So for now I didn't disallow for all cases just for consistency. Happy to do either though!

Comment on lines +78 to +79
if (data.x.toBigInt() === ALL_ONES && data.y.toBigInt() === ALL_ONES) {
return Point.ZERO;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This is quite confusing and error-prone - Point.ZERO is not a zero point, but actually the infinity point, which is disallowed in most places (e.g. as keys, in the bb boundary, etc.). People might do Point.ZERO thinking it's a simple way to get a no-op point and it's actually a trap.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Fair enough - I can rename to INF? The difficulty is that now an 'empty' point class is equivalent to the point at infinity.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Renamed to INFINITY here: #23507
(any comments I've marked as resolved were either already fixed here or are fixed in the PR above)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ci-full Run all master checks.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants