From f5b06885f4cf4f04cb3aa57435ef10c7ace8b9f4 Mon Sep 17 00:00:00 2001 From: dbanks12 Date: Wed, 28 Feb 2024 17:55:29 +0000 Subject: [PATCH] chore(aztec-nr): clarify in comments that nullifier computation does not need to include siloed note-hash for protocol security --- noir-projects/aztec-nr/aztec/src/note/utils.nr | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/noir-projects/aztec-nr/aztec/src/note/utils.nr b/noir-projects/aztec-nr/aztec/src/note/utils.nr index 41af73a6ed7..123417def28 100644 --- a/noir-projects/aztec-nr/aztec/src/note/utils.nr +++ b/noir-projects/aztec-nr/aztec/src/note/utils.nr @@ -74,6 +74,14 @@ pub fn compute_note_hash_for_consumption(note: Note) -> Field where Not // contract address and then nonce. This hash will match the existing leaf in the private // data tree, so the kernel can just perform a membership check directly on this hash/leaf. compute_unique_siloed_note_hash(note) + // IMPORTANT NOTE ON REDUNDANT SILOING BY CONTRACT ADDRESS: The note hash computed above is + // "siloed" by contract address. When a note hash is computed solely for the purpose of + // nullification, it is not strictly necessary to silo the note hash before computing + // its nullifier. In other words, it is NOT NECESSARY for protocol security that a nullifier + // be computed from a siloed note hash. After all, persistable note hashes and nullifiers are + // siloed by the kernel circuit. That being said, the siloed note hash computed above CAN be + // used for nullifier computation, and this achieves the (arguably unnecessary) property that + // nullifiers are computed from a note hash's fully-computed private data tree leaf. } }