Provide an implementation of a note with a single field from aztec.nr

[spalladino]

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.

use dep::aztec::note::{
    note_header::NoteHeader,
    note_interface::NoteInterface,
    utils::compute_note_hash_for_read_or_nullify,
};
use dep::aztec::oracle::{
    get_secret_key::get_secret_key,
    get_public_key::get_public_key,
};
use dep::aztec::types::address::AztecAddress;

struct FieldNote {
    value: Field,
    header: NoteHeader,
}

global FIELD_NOTE_LEN: Field = 1;

impl FieldNote {
    fn new(_value: Field) -> Self {
        FieldNote {
            value: _value,
            header: NoteHeader::empty(),
        }
    }

    fn serialize(self) -> [Field; FIELD_NOTE_LEN] {
        [self.value]
    }

    fn deserialize(preimage: [Field; FIELD_NOTE_LEN]) -> Self {
        FieldNote {
            value: preimage[0],
            header: NoteHeader::empty(),
        }
    }

    fn compute_note_hash(self) -> Field {
        dep::std::hash::pedersen([
            self.value
        ])[0]
    }

    fn compute_nullifier(self) -> Field {
         0
    }

    fn set_header(&mut self, header: NoteHeader) {
        self.header = header;
    }
}

fn deserialize(preimage: [Field; FIELD_NOTE_LEN]) -> FieldNote {
    FieldNote::deserialize(preimage)
}

fn serialize(note: FieldNote) -> [Field; FIELD_NOTE_LEN] {
    note.serialize()
}

fn compute_note_hash(note: FieldNote) -> Field {
    note.compute_note_hash()
}

fn compute_nullifier(note: FieldNote) -> Field {
    note.compute_nullifier()
}

fn get_header(note: FieldNote) -> NoteHeader {
    note.header
}

fn set_header(note: &mut FieldNote, header: NoteHeader) {
    note.set_header(header)
}

global FieldNoteMethods = NoteInterface {
    deserialize,
    serialize,
    compute_note_hash,
    compute_nullifier,
    get_header,
    set_header,
};

[critesjosh]

If the contents of this note are intended to be private, it should also include some randomness, correct?

[spalladino]

Isn't the randomness injected as part of the NoteHeader, which is shared across all note types? cc @LeilaWang

[critesjosh]

If so than we can close this one #2921

[rahul-kothari]

@spalladino randomness is not injected as part of the NoteHeader! https://aztecprotocol.slack.com/archives/C03P17YHVK8/p1698050504536559?thread_ts=1698049801.852819&cid=C03P17YHVK8

[spalladino]

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..?

[rahul-kothari]

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

[rahul-kothari]

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 :)

[benesjan]

If we add randomness to the note then the only difference between a FieldNote and a ValueNote is the owner struct member. Given that now the notes have to have a broadcast method I effectively would need to store the owner as well to be able to fetch the pub key in broadcast. This would make a FieldNote and a ValueNote equivalent. If that's the case then there is nothing to do and we can probably close this.

@spalladino Or am I missing something here? Why the grantees didn't use ValueNote?

[spalladino]

@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.