feat(aztec-nr): Compute unconstrained tag in Noir over PXE and generalize get_next_tagging_index oracle by vezenovm · Pull Request #23796 · AztecProtocol/aztec-packages

vezenovm · 2026-06-02T13:24:49Z

New get_app_tagging_secret oracle rather than get_next_app_tag_as_sender and computing the tag in the PXE
get_next_constrained_tagging_index -> get_next_tagging_index(secret, mode)

This PR bumped ORACLE_VERSION_MAJOR from 27 to 28 in aztec-nr/aztec/src/oracle/version.nr and yarn-project/pxe/src/oracle_version.ts, but missed the duplicate constant in the parallel sublib that protocol contracts depend on (noir-contracts/contracts/protocol/ aztec_sublib/src/oracle/version.nr). Protocol contracts were therefore still being compiled with major=27, and PXE rejected them at runtime with 'Incompatible private environment version: expected oracle major version 28, got 27', breaking every e2e test that loads a protocol contract.

nchamo

Should we be merging noir-projects/noir-contracts/pinned-standard-contracts.tar.gz? Or was that an accident?

nchamo · 2026-06-02T19:41:03Z

-        get_next_app_tag_as_sender(sender, recipient)
+        let secret = get_app_tagging_secret(sender, recipient);
+        let index = get_next_tagging_index(secret, ONCHAIN_UNCONSTRAINED);
+        poseidon2_hash([secret, index as Field])


We don't need to do it in this PR, but I'm curious about how this will change we start supporting constrained

nchamo · 2026-06-02T19:54:28Z

+/// This is the secret half of unconstrained-delivery tag derivation. The simulator performs the ECDH multiply -
+/// which needs the sender's master incoming viewing secret key and so can only run in the PXE - siloes the result
+/// to the calling contract, and returns it. The caller finishes the tag by obtaining an index from
+/// [`get_next_tagging_index`] and hashing the two together. Handshake-origin sends skip this entirely: the registry
+/// provides the secret instead.


I don't like this doc very much. "the secret half" is not clear enough for me. The ECDH multiply is to detail oriented. Actually, I think it would we best if we don't mention ECDH here, since maybe there is another way the secret was originated

I think we could rename the oracle to reflect that this is a tagging secret that is not calculated by contracts. It's hold or calculated somewhere else, and this oracle is meant to retrieve it. That's the diff between using this oracle and the secrets we calculate in contracts (like handshakes): the origin

Am I making sense? Do you see this differently?

I'm having doubts about my previous comment. So feel free to ignore it or share your opinion, I think I mixed things

The comment is still a little unclear either way as it is too much in the internals. I will edit it.

I edited the comments to be more general and I think they are clearer now.

No issue, fixes confusing CI errors I ran into on #23796 when the `aztec_sublib` oracle version was not updated http://ci.aztec-labs.com/83a883aee887f12c: <details><summary>Details</summary> <p> ``` 17:46:29 17:46:29 ● e2e_blacklist_token_contract transfer public › failure cases › transfer from a blacklisted account 17:46:29 17:46:29 TypeError: Cannot read properties of undefined (reading 'check') 17:46:29 17:46:29 22 | 17:46:29 23 | afterEach(async () => { 17:46:29 > 24 | await t.tokenSim.check(); 17:46:29 | ^ 17:46:29 25 | }); 17:46:29 26 | 17:46:29 27 | it('transfer less than balance', async () => { 17:46:29 17:46:29 at Object.check (e2e_blacklist_token_contract/transfer_public.test.ts:24:22) 17:46:29 17:46:29 ● e2e_blacklist_token_contract transfer public › failure cases › transfer to a blacklisted account 17:46:29 17:46:29 Simulation error: Incompatible private environment version: The contract was compiled with an older version of Aztec.nr than your private environment supports. Recompile the contract with a compatible version of Aztec.nr. See https://docs.aztec.network/errors/8 (expected oracle major version 28, got 27) 17:46:29 17:46:29 at ContractClassRegistry.publish 17:46:29 at MultiCallEntrypoint.entrypoint 17:46:29 17:46:29 Cause: 17:46:29 Incompatible private environment version: The contract was compiled with an older version of Aztec.nr than your private environment supports. Recompile the contract with a compatible version of Aztec.nr. See https://docs.aztec.network/errors/8 (expected oracle major version 28, got 27) 17:46:29 17:46:29 85 | if (major !== ORACLE_VERSION_MAJOR) { 17:46:29 86 | const hint = major > ORACLE_VERSION_MAJOR ? 'The contract was compiled with a newer version of Aztec.nr than your private environment supports. Upgrade your private environment to a compatible version.' : 'The contract was compiled with an older version of Aztec.nr than your private environment supports. Recompile the contract with a compatible version of Aztec.nr.'; 17:46:29 > 87 | throw new Error(`Incompatible private environment version: ${hint} See https://docs.aztec.network/errors/8 (expected oracle major version ${ORACLE_VERSION_MAJOR}, got ${major})`); 17:46:29 | ^ 17:46:29 88 | } 17:46:29 89 | this.contractOracleVersion = { 17:46:29 90 | major, 17:46:29 17:46:29 at PrivateExecutionOracle.assertCompatibleOracleVersion (../../pxe/dest/contract_function_simulator/oracle/utility_execution_oracle.js:87:19) ``` </p> </details> We are told there is an oracle mismatch, but there is nothing to indicate it is in the aztec-nr sublib as I had already updated the actual aztec-nr version constant. The error also only comes about at runtime in an e2e test. We should be able to error out in the pre-existing `check_oracle_version` scripts for pxe/txe.

…e_execution_oracle.ts Co-authored-by: Nicolas Chamo <nicolas@chamo.com.ar>

vezenovm · 2026-06-02T20:28:46Z

Should we be merging noir-projects/noir-contracts/pinned-standard-contracts.tar.gz? Or was that an accident?

Looks to be intended. The tarball is an existing pinned artifact, and looks to be getting refreshed along with the other standard contracts after the oracle version change.

nchamo

Great work!

Co-authored-by: Nicolas Chamo <nicolas@chamo.com.ar>

BEGIN_COMMIT_OVERRIDE chore: document browser kv-store backend migration (AztecProtocol#23779) feat(aztec-nr): Compute unconstrained tag in Noir over PXE and generalize get_next_tagging_index oracle (AztecProtocol#23796) refactor(txe): migrate rpc_translator to typed oracle registry (AztecProtocol#23530) feat(pxe)!: allow apps to inject tagging secrets into getPendingTaggedLogs (AztecProtocol#23777) feat(txe): add oracle roundtrip test framework (AztecProtocol#23537) fix: embedded wallet defaults to proposed (AztecProtocol#23819) feat(aztec-nr): discover non-interactive handshakes in the registry (AztecProtocol#23806) refactor(txe): normalize deploy and addAccount to oracle registry (AztecProtocol#23536) fix: wait for checkpoint during sandbox setup (AztecProtocol#23834) feat(standard-contracts): graduate handshake registry to standard contract (AztecProtocol#23833) END_COMMIT_OVERRIDE

get_app_tagging_secret and generalize get_next_tagging_index

c15afe8

vezenovm requested a review from nventuro as a code owner June 2, 2026 13:24

vezenovm changed the title ~~feat: Compute unconstrained tag in aztec-nr and generalize get_next_tagging_index oracle~~ feat(aztec-nr): Compute unconstrained tag in Noir over PXE and generalize get_next_tagging_index oracle Jun 2, 2026

vezenovm added 5 commits June 2, 2026 09:49

Merge branch 'merge-train/fairies' into mv/f-695-get-app-tagging-secret

1db0f03

Merge branch 'merge-train/fairies' into mv/f-695-get-app-tagging-secret

7d772b0

restore standard contract addresses

df8dedc

oracle version

b40c6c7

chore: re-pin standard contracts and regenerate addresses for oracle v28

5e173ac

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

AztecBot and others added 3 commits June 2, 2026 17:58

message delivery constants shared

9da00ac

Merge branch 'merge-train/fairies' into mv/f-695-get-app-tagging-secret

8cdeff5

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

vezenovm requested a review from nchamo June 2, 2026 18:54

vezenovm mentioned this pull request Jun 2, 2026

chore(ci): Static oracle version check #23805

Merged

nchamo reviewed Jun 2, 2026

View reviewed changes

vezenovm and others added 2 commits June 2, 2026 16:18

Update yarn-project/pxe/src/contract_function_simulator/oracle/privat…

62da1a7

…e_execution_oracle.ts Co-authored-by: Nicolas Chamo <nicolas@chamo.com.ar>

Update yarn-project/pxe/src/contract_function_simulator/oracle/privat…

1d3bdc6

…e_execution_oracle.ts Co-authored-by: Nicolas Chamo <nicolas@chamo.com.ar>

vezenovm added 8 commits June 2, 2026 16:31

fix(aztec-nr): return optional app tagging secret

dfddd8b

docs: clarify invalid recipient tagging fallback

92cf11f

comments

dab69e8

.

e3600b4

fmt'

876500f

one more

c3177a3

cleanup

177e564

fix: move tagging delivery mode mapping

c917c85

vezenovm requested a review from nchamo June 2, 2026 21:05

fmt

5cc119c

nchamo approved these changes Jun 3, 2026

View reviewed changes

vezenovm and others added 3 commits June 3, 2026 09:45

Update noir-projects/aztec-nr/aztec/src/oracle/notes.nr

1a4cd61

Co-authored-by: Nicolas Chamo <nicolas@chamo.com.ar>

Update noir-projects/aztec-nr/aztec/src/oracle/notes.nr

1c1ce78

Co-authored-by: Nicolas Chamo <nicolas@chamo.com.ar>

use map_or_else and comments on consts

5316a90

vezenovm enabled auto-merge (squash) June 3, 2026 13:49

vezenovm merged commit e3871cb into merge-train/fairies Jun 3, 2026
12 checks passed

vezenovm deleted the mv/f-695-get-app-tagging-secret branch June 3, 2026 14:19

AztecBot mentioned this pull request Jun 3, 2026

feat: merge-train/fairies #23815

Merged

Conversation

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

Uh oh!

Uh oh!

nchamo left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

nchamo Jun 2, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

nchamo Jun 2, 2026

Choose a reason for hiding this comment

Uh oh!

nchamo Jun 2, 2026

Choose a reason for hiding this comment

Uh oh!

vezenovm Jun 2, 2026

Choose a reason for hiding this comment

Uh oh!

vezenovm Jun 2, 2026

Choose a reason for hiding this comment

Uh oh!

vezenovm commented Jun 2, 2026

Uh oh!

nchamo left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

vezenovm commented Jun 2, 2026 •

edited

Loading