-
Notifications
You must be signed in to change notification settings - Fork 275
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide an implementation of a note with a single field from aztec.nr #2948
Comments
If the contents of this note are intended to be private, it should also include some randomness, correct? |
Isn't the randomness injected as part of the |
If so than we can close this one #2921 |
@spalladino randomness is not injected as part of the NoteHeader! https://aztecprotocol.slack.com/archives/C03P17YHVK8/p1698050504536559?thread_ts=1698049801.852819&cid=C03P17YHVK8 |
Well, damn. Seems like this is an easy footgun. How can we alert users if they've forgotten to include randomness generation in their notes..? |
this came up a couple of times. The consensus from the team was we need to do minimal behind-the-scenes magic for devs so they know exactly what is happening and learn how to handle privacy leakage |
Because I never said it explicitly, I believe this should have randomness added to it! cc @benesjan since looks like Jan will pick it up :) |
If we add randomness to the note then the only difference between a @spalladino Or am I missing something here? Why the grantees didn't use |
@benesjan because the note doesn't have an owner. They are using it to store a constant value, set at construction time, that is immutable and needs to be accessed from private state. The note is not broadcasted, but manually added to the pxe by the dapp. This means that most likely they would not need randomness for the note, unless they wanted to keep it private across a set of users, in which case they could distribute that randomness from a gated frontend. More info on their scenario here and here. |
@spalladino That makes sense. Thank you for the context. I will just put assert false in the broadcast method. |
Storing a single field value in a private note in a singleton requires the user to write the following boilerplate code. Until we have something to autogenerate this code (noir macros or code generators), we should provide an implementation for it from aztec.nr, similar to how we do with the value note.
The text was updated successfully, but these errors were encountered: