Merged
Conversation
Contributor
Author
This stack of pull requests is managed by Graphite. Learn more about stacking. |
benesjan
force-pushed
the
09-29-refactor_cleaning_up_tagging_oracles
branch
from
745bc29 to
ac2a7bf
Compare
benesjan
force-pushed
the
09-29-refactor_cleaning_up_tagging_oracles
branch
2 times, most recently
from
ee33e77 to
a576c5c
Compare
benesjan
force-pushed
the
09-29-refactor_cleaning_up_tagging_oracles
branch
from
a576c5c to
326a25f
Compare
benesjan
force-pushed
the
graphite-base/17372
branch
from
0da23a5 to
4b1c2cf
Compare
benesjan
changed the base branch from
graphite-base/17372
to
09-26-refactor_dropping_getnotes_from_testwallet
This was referenced Sep 30, 2025
benesjan
changed the base branch from
09-26-refactor_dropping_getnotes_from_testwallet
to
graphite-base/17372
benesjan
force-pushed
the
09-29-refactor_cleaning_up_tagging_oracles
branch
from
326a25f to
a758ed1
Compare
benesjan
force-pushed
the
graphite-base/17372
branch
from
4b1c2cf to
0da23a5
Compare
benesjan
force-pushed
the
09-29-refactor_cleaning_up_tagging_oracles
branch
from
a758ed1 to
bf802de
Compare
benesjan
changed the title
benesjan
force-pushed
the
09-29-refactor_cleaning_up_tagging_oracles
branch
from
bf802de to
15b4247
Compare
nventuro
approved these changes
Sep 30, 2025
Comment on lines
-8
to
-12
| pub struct IndexedTaggingSecret { | ||
| app_tagging_secret: Field, | ||
| index: u32, | ||
| } | ||
|
|
Contributor
There was a problem hiding this comment.
Why was this a proto struct?
Contributor
Author
There was a problem hiding this comment.
It was introduced in this PR by Grego. I don't really know but I guess it was because we have the TS counterpart and we wanted to have a matching struct in Noir.
| return toForeignCallResult(witness.toNoirRepresentation()); | ||
| } | ||
|
|
||
| async utilityGetIndexedTaggingSecretAsSender(foreignSender: ForeignCallSingle, foreignRecipient: ForeignCallSingle) { |
Contributor
There was a problem hiding this comment.
Huh, rpc translator does not handle privateIncrementAppTaggingSecretIndexAsSender, so you were not forced to update to privateGetNextAppTagAsSender. I thought the class had been setup with zod to typecheck that all are handled, but it seems I was wrong.
Could you add the oracle, and maybe take a quick look to see if you can get the zod thing working? i.e. that when a txe session dispatches to the rpc translator we know that a) the fn is one of the allowed ones, and b) that all allowed fns are handled
Contributor
Author
There was a problem hiding this comment.
Added the missing method in 171b7ba and will try to figure out the zod thing in a separate PR.
benesjan
force-pushed
the
09-29-refactor_cleaning_up_tagging_oracles
branch
from
3788ddb to
309fc54
Compare
In this PR I merge `getIndexedTaggingSecretAsSender` and `incrementAppTaggingSecretIndexAsSender` and `get_app_tag_as_sender` into single `get_next_app_tag(sender, recipient)`. This results in the app tag being computed in TS and not in Noir. The motivation for this is that to improve robustness of tagging as described in [this post](https://forum.aztec.network/t/on-note-discovery-and-index-coordination/7165) we need to associate a given index with tx hash and this is the first step in that direction. ### Note for reviewer This is a breaking change because it changes oracles but I don't think a dev would ever call these oracles directly so I didn't bother with writing migration notes. If the reviewer thinks it should be done then LMK and I can add it. Co-authored-by: Jan Beneš <janbenes1234@gmail.com>
AztecBot
force-pushed
the
09-29-refactor_cleaning_up_tagging_oracles
branch
from
171b7ba to
dfe7b5c
Compare
ludamad
pushed a commit
that referenced
this pull request
Dec 16, 2025
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
3 participants
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.
In this PR I merge
getIndexedTaggingSecretAsSenderandincrementAppTaggingSecretIndexAsSenderandget_app_tag_as_senderinto singleget_next_app_tag(sender, recipient). This results in the app tag being computed in TS and not in Noir.The motivation for this is that to improve robustness of tagging as described in this post we need to associate a given index with tx hash and this is the first step in that direction.
Note for reviewer
This is a breaking change because it changes oracles but I don't think a dev would ever call these oracles directly so I didn't bother with writing migration notes. If the reviewer thinks it should be done then LMK and I can add it.