feat(aztec-nr): Get tagging index for constrained delivery by vezenovm · Pull Request #23359 · AztecProtocol/aztec-packages

vezenovm · 2026-05-18T09:37:48Z

Adds a new get_next_constrained_index_oracle that accepts an app siloed secret (expected to be returned from the handshake registry utility contract added in feat(aztec-nr): V2 handshake registry for non interactive constrained delivery #23278
Extend the sender tagging store to key by a different type of secret (app supplied secret rather than fetched/computed from the PXE)

…eNote, Context>, Context>, Context> and additional test

…hake_registry_contract/src/main.nr Co-authored-by: Nicolas Chamo <nicolas@chamo.com.ar>

…ined index

… dom sep The new DOM_SEP__CONSTRAINED_MSG_LOG_TAG domain separator added in this PR adds one assert_dom_sep_matches_derived call, which pushes to both seen_u32 and seen_values. constants_tests::hashed_values_match_derived sized the tester at <71, 64>, so the extra push overflowed the BoundedVec ("push out of bounds" at bounded_vec.nr:186). Bump to <72, 65> to match the actual 72 value / 65 u32 hashed entries.

…next_app_tag_as_sender-for-constrained' into maxim/f-668-aztec-nr-extend-get_next_app_tag_as_sender-for-constrained

nchamo

I haven't done an in-depth review, but I have some question that we should address before that

nchamo · 2026-05-20T13:42:39Z

-export const CONTRACT_INSTANCE_PUBLISHED_MAGIC_VALUE = 10538216027419913765597387738085647348651103543680388181336823392401502757423n;
-export const CONTRACT_INSTANCE_UPDATED_MAGIC_VALUE = 20721543224513346060908370400407150739273836456436647488068002302723900469047n;
+export const CONTRACT_CLASS_PUBLISHED_MAGIC_VALUE =
+  14907836659448373306373608164128296596488873008270905914742877230397948162628n;


I think a lot of the changes here are not related to your change. Can we revert them?

nchamo · 2026-05-27T17:51:14Z

+/// As with the unconstrained variant, the simulator persists the index increment only if the tagged log is found in
+/// an actual block - a reverting transaction can otherwise cause the sender to accidentally skip indices and later
+/// produce notes that are not found by the recipient.
+pub unconstrained fn get_next_constrained_index(app_siloed_secret: Field) -> u32 {


I have a few thoughts about this:

The name it not clear, what about get_next_tagging_index?

I'm thinking if it makes sense to force this for constrained only? What if we had get_next_tagging_index(secret, kind)? Maybe it makes sense to have something like that in the future

get_next_constrained_tagging_index?

I'm not sure about designing for a kind parameter as generalizing here feels a bit pre-mature. The design for unconstrained tagging is quite different than constrained, thus that is why we made this entirely separate oracle rather than extending get_next_app_tag_as_sender.

Yeah, I'm not saying we should extend or replace get_next_app_tag_as_sender. It just feels weird to me to force this oracle to be for constrained delivery only while we could easily accept an unconstrained secret and also return the next tagging index.

While I don't see a use case for it today, I'm thinking that it might make sense to make the oracle as generic as possible. Specially when the cost to do so is close to 0, right? I'm not completely sold on the idea, but I wanted to bring it up

I brought up get_next_app_tag_as_sender as it feels like the same reasoning applies here. Unconstrained tagging intentionally has the PXE derive and return the full tag while in constrained tagging we only need the PXE to reserve the next index as the app holds the secret. It feels as though we would be extending the Noir oracle surface/API without a use case. I guess I ultimately am just hesitant to generalize when I don't know what the generalized version will look like in the future.

Ok, makes sense. But let's rename to get_next_constrained_tagging_index please

nchamo · 2026-05-27T18:09:54Z

+ * Both shapes expose `{ secret, app }` and a `kind` literal discriminator, plus a self-describing `toString()` so
+ * they can share storage that keys on `secret.toString()`.
+ */
+export type AppTaggingSecret = ExtendedDirectionalAppTaggingSecret | ConstrainedAppTaggingSecret;


I'm curious about this. What if only had:

type AppTaggingSecret = { secret: Fr, app: AztecAddress, kind: 'constrained' | 'unconstrained' }

It could be a class if we need it. And then, when converting to string, we could to:
${kind}:${secret}"${app}

And when converting from string, we could check if `.split(":") has length 2 or 3. If it's 2, then we know it's unconstrained (and we leave a comment explaining that we are keeping it that way for backwards compatibility purposes)

Would that be possible? I think that it makes sense to generalize the concept of AppTaggingSecret and just have one, instead of having multiple

Do you see a reason why this wouldn't work?

There shouldn't be anything preventing that design. I considered generalizing in that direction too, which is why both secret shapes now share the same sender-side storage path.

However, I decided to maintain the separate types internally as the ExtendedDirectionalAppTaggingSecret is used in various places such as recipient syncing and I wanted to preserve existing APIs. We do still have one "app tagging secret" abstraction here, the internal representation is just a union of types rather than a unified single concrete type.

Ultimately I was trying to reduce unrelated changes in this PR (e.g., unrelated call-sites of ExtendedDirectionalAppTaggingSecret). If you feel strongly about this structure I can migrate fully to a single AppTaggingSecret type here, but I think this is a reasonable follow-up refactor. I could also stack the PR on this one to split out unrelated changes a bit more.

nchamo · 2026-05-27T18:13:50Z

+   * @param appSiloedSecret - The app-siloed shared secret retrieved from the handshake registry by the caller.
+   * @returns The next index to use for this secret.
+   */
+  public async getNextConstrainedIndex(appSiloedSecret: Fr): Promise<number> {


Does this detect already if another PXE with the same recipient-sender pair used an index? For example, PXE A uses 1, so PXE B detects it and moves on to index 2

Maybe the unconstrained path already did it, what why I'm asking. It would be a nice e2e test to have if I'm being honest

I realized I edited the tag computation in yarn-project/pxe/src/tagging/sender_sync/sync_sender_tagging_indexes.ts but didn't update any tests in yarn-project/pxe/src/tagging/sender_sync/sync_sender_tagging_indexes.test.ts. Do you think that would be sufficient for testing here? Looking at "step 1: highest finalized index is updated" this looks like basically what we want to test.

You are right, that is exactly what we needed. I love it when the code already works as expected 🎉

No need to do anything else

The siloing only checks unconstrained tags still though. So I will extend that one test to check both tag kinds.

Co-authored-by: Nicolas Chamo <nicolas@chamo.com.ar> Co-authored-by: Maxim Vezenov <mvezenov@gmail.com>

…f-668-aztec-nr-extend-get_next_app_tag_as_sender-for-constrained # Conflicts: # yarn-project/pxe/src/contract_function_simulator/oracle/oracle.ts # yarn-project/pxe/src/oracle_version.ts

AztecBot · 2026-05-27T20:44:17Z

Flakey Tests

🤖 says: This CI run detected 1 tests that failed, but were tolerated due to a .test_patterns.yml entry.

\033FLAKED\033 (8;;http://ci.aztec-labs.com/c14de6f625aa9d0f�c14de6f625aa9d0f8;;�):  yarn-project/end-to-end/scripts/run_test.sh simple src/e2e_p2p/broadcasted_invalid_block_proposal_slash.test.ts (169s) (code: 0) group:e2e-p2p-epoch-flakes

## Summary Renames `ExtendedDirectionalAppTaggingSecret` to `AppTaggingSecret`, including the source file, exports, call sites, tests, and generated API references. This prepares for #23359 to make `AppTaggingSecret` the single concrete tagging secret type with a `kind` discriminator. Review context: #23359 (comment) --------- Co-authored-by: AztecBot <tech@aztec-labs.com>

…f-668-aztec-nr-extend-get_next_app_tag_as_sender-for-constrained # Conflicts: # yarn-project/pxe/src/contract_function_simulator/execution_tagging_index_cache.ts # yarn-project/pxe/src/contract_function_simulator/oracle/private_execution_oracle.ts # yarn-project/pxe/src/storage/tagging_store/sender_tagging_store.test.ts # yarn-project/pxe/src/storage/tagging_store/sender_tagging_store.ts # yarn-project/pxe/src/tagging/reconcile_tagging_index_ranges.ts # yarn-project/pxe/src/tagging/sender_sync/utils/load_and_store_new_tagging_indexes.ts # yarn-project/stdlib/src/logs/app_tagging_secret.test.ts # yarn-project/stdlib/src/logs/app_tagging_secret.ts # yarn-project/stdlib/src/logs/index.ts # yarn-project/stdlib/src/logs/tagging_index_range.ts # yarn-project/stdlib/src/tests/factories.ts

vezenovm and others added 10 commits May 14, 2026 10:52

udpates to handshake registry

98b9784

nargo fmt

27e5a5e

clean up bug repros and link to TODO

381858d

fmt

fff3541

constants test update

3202ab1

switch to handshakes: Map<AztecAddress, Owned<PrivateMutable<Handshak…

49bfefc

…eNote, Context>, Context>, Context> and additional test

remove old comment referencing issue

d00136d

Update noir-projects/noir-contracts/contracts/message_discovery/hands…

76c025e

…hake_registry_contract/src/main.nr Co-authored-by: Nicolas Chamo <nicolas@chamo.com.ar>

pr comments, cleanup, additional tests

75554b1

extend sender tagging store and make a new oracle to get next constra…

9a451ef

…ined index

vezenovm requested review from LeilaWang and nventuro as code owners May 18, 2026 09:37

merge conflicts w/ fairies

14d22ca

vezenovm added the claudebox Owned by claudebox. it can push to this PR. label May 18, 2026

fix: bump HashedValueTester capacities for new constrained-msg dom sep

bfb03bf

vezenovm removed the claudebox Owned by claudebox. it can push to this PR. label May 18, 2026

vezenovm requested a review from nchamo May 20, 2026 13:29

merge w/ fairies

aa3d1e6

vezenovm added the claudebox Owned by claudebox. it can push to this PR. label May 26, 2026

vezenovm removed the claudebox Owned by claudebox. it can push to this PR. label May 26, 2026

vezenovm added 2 commits May 26, 2026 14:26

test cleanup

36d355d

Merge remote-tracking branch 'origin/maxim/f-668-aztec-nr-extend-get_…

3bad347

…next_app_tag_as_sender-for-constrained' into maxim/f-668-aztec-nr-extend-get_next_app_tag_as_sender-for-constrained

nchamo reviewed May 27, 2026

View reviewed changes

vezenovm commented May 27, 2026

View reviewed changes

Comment thread noir-projects/aztec-nr/aztec/src/keys/ecdh_shared_secret.nr Outdated

vezenovm and others added 2 commits May 27, 2026 14:41

Apply suggestions from code review

cbc905b

Co-authored-by: Nicolas Chamo <nicolas@chamo.com.ar> Co-authored-by: Maxim Vezenov <mvezenov@gmail.com>

comment

0d1e1c5

vezenovm mentioned this pull request May 27, 2026

refactor: rename app tagging secret #23602

Merged

Merge remote-tracking branch 'origin/merge-train/fairies' into maxim/…

cc18df1

…f-668-aztec-nr-extend-get_next_app_tag_as_sender-for-constrained # Conflicts: # yarn-project/pxe/src/contract_function_simulator/oracle/oracle.ts # yarn-project/pxe/src/oracle_version.ts

vezenovm added 5 commits May 27, 2026 17:35

docs: wrap constrained tagging comment

cbf7fed

test: clarify app tagging kind parsing

8188a7d

refactor: clarify constrained tagging index oracle

ccf6647

no need for sileodTagFor

4e77dc0

Conversation

vezenovm commented May 18, 2026

Uh oh!

nchamo left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nchamo May 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vezenovm May 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nchamo May 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

AztecBot commented May 27, 2026

Flakey Tests

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

nchamo May 27, 2026 •

edited

Loading

vezenovm May 27, 2026 •

edited

Loading

nchamo May 27, 2026 •

edited

Loading