Private Message Delivery
In Aztec, users need to pass private information between each other. Whilst Aztec enables users to share arbitrary private messages, we'll often frame the discussion towards a sender sharing the preimage of a private note with some recipient.
If Alice executes a function that generates a note for Bob:
- Alice will need to encrypt that note such that Bob, and only Bob is able to decrypt it.
- Alice will need to broadcast the encrypted note ciphertext so as to make it available for Bob to retrieve.
- Alice will need to broadcast a 'tag' alongside the encrypted note ciphertext. This tag must be identifiable by Bob's chosen note discovery protocol but not identifiable by any third party as "intended for Bob".
Requirements
- Users must be able to choose their note tagging mechanism. We expect improved note discovery schemes to be designed over time. The protocol should be flexible enough to accommodate them and for users to opt in to using them as they become available. This flexibility should be extensible to encryption mechanisms as well as a soft requirement.
- Users must be able to receive notes before interacting with the network. A user should be able to receive a note just by generating an address. It should not be necessary for them to deploy their account contract in order to receive a note.
- Applications must be able to safely send notes to any address. Sending a note to an account could potentially transfer control of the call to that account, allowing the account to control whether they want to accept the note or not, and potentially bricking an application, since there are no catching exceptions in private function execution.
- Addresses must be as small as possible. Addresses will be stored and broadcasted constantly in applications. Larger addresses means more data usage, which is the main driver for cost. Addresses must fit in at most 256 bits, or ideally a single field element.
- Total number of function calls should be minimized. Every function call requires an additional iteration of the private kernel circuit, which adds several seconds of proving time.
- Encryption keys should be rotatable. Users should be able to rotate their encryption keys in the event their private keys are compromised, so that any further interactions with apps can be private again, without having to migrate to a new account.