Support private Maps of different note types in the same contract in compute_hash_and_nullifier

[spalladino]

Today we usually implement compute_hash_and_nullifier as a switch on the storage slot: depending on the slot, we delegate this computation to a different note implementation. But how does this work if we have two Maps of different note types? A Map basically hashes its slot with the key (same as in Solidity). So, for a note stored in a map, the compute_note_hash_and_nullifier would get a random slot that the function cannot know to which map it belongs, so it cannot know to which note implementation delegate the computation. This means we cannot have two maps of different note types in the same contract.

[spalladino]

A faint memory from a few months ago was if we can encode note structs to have unique ids, then providing the storage slot & the note struct id might suffice.

From @iAmMichaelConnor

[LeilaWang]

There was a discussion to always include an id, or a function selector which can process the specific note type, to the encrypted data. But there are some creative ways to figure this out before we add another field to it.

If it's hard to tell by looking at the storage slot, we can:

• check the size of the preimage, assuming the field of the "larger" note at index n (where n >= smaller_note.size) won't be zero. (Or maybe we can pass the size of the preimage to the function?)
• check the value of a field (e.g., the 2nd field of one of the note type should be the caller's address)(should unconstrained functions also have some sort of context?).
• emit an extra identifier for a note type if there's no way to distinguish it from others.

[spalladino]

Requested by @30mb1 on Discord