Tag logs as a sender

[nventuro]

Note logs currently look something like [ Epk, encrypted_payload ], with plaintext_payload = [ contract_address, storage_slot, note_type_id, note_preimage ].

In order for logs to be fetched via tags, we must add said tags at the beginning of the log (#9268). Tags are a single field which is then serialized into 32 bytes, and are computed as follows:

let tag: Field = hash([app_siloed_secret, recipient_address, index]);

where app_siloed_secret is obtained from PXE (#9378) and index is an incrementing counter that is ideally only used once in a single tag. For the hash function poseidon2 is likely a good fit.

The log will therefore then be [ tag, Epk, encrypted_payload ].

recipient_adddress

It should not be possible for third parties to fake our tags, since they will not know app_siloed_secret as it involves the secret key of either the sender or the recipient. If someone somehow did manage to produce valid tags, then that's still fine in that we only use tags to filter down logs and not process them all - PXE cannot be made to add bad notes to its database. However, we must consider the scenario in which both Alice and Bob want to send a note to each other at the same time.

If the tag only included the app-siloed secret and an index, then both parties might accidentally use the same index, since they cannot know their counterparty is also attempting sending at the same time. Such index reuse can result in very annoying user experience, so we also add the recipient address into the hash function to have Alice and Bob produce different tags.

Note that we cannot use the sender's address here, since that'd require recipients to know who might send them notes, in turn requiring PXE to reveal this information to apps, which as mentioned in #9365 is something we want to avoid.

index

This exists so that we can predict future tags: if we've seen the tag with index 3, then we know the next one will have index 4. This only works if the sender is cooperative and keeps track of their indices, which is not trivial in some scenarios (e.g. multiple devices). Some remedies exist in case the sender reuses indices (#9369), but they should definitely not skip any.

The simple and naive way for the sender to find the index to use is to iterate starting from 0 until they get a tag which does not exist (i.e. getTaggedLogs returns nothing), and then use that index. This can be improved by having PXE keep track of the last used indices (via #9368), so that we don't need to start from scratch each time. By checking that the tags have not yet been used we get some level of syncronization between multiple devices, but race conditions are still possible and may result in repeated tags.

---

In summary, what we need to do is:

• get the app-siloed shared secret for the recipient from the oracle
• get the latest used index
• compute tags with incrementing indices until we find one that hasn't been used
• compute the actual tag using the first unused index
• store the last used index in PXE