Some advanced log layout user stories

[iAmMichaelConnor]

cc @nventuro

This doesn't affect the "protocol"; only aztec.nr. Aztec.nr is capable of these user stories, so this issue just lists some important examples to keep in mind when making changes, so that these user stories remain possible. This issue requests that we (eventually) add examples of the following:

• A user (smart contract dev) should be able to emit a "long log", by splitting it into chunks, where each "chunk" is a "private log". The encoding of this long log should be optimised to avoid wasting bytes (because bytes cost $).
  • Note: @LeilaWang is considering reducing private log lengths (See Reduce the constant private logs length #12773 ). The only thing seemingly requiring the current number of fields (it's something like 16 or 18) is our own "contract instance deployment" contract. In fact, that "contract instance deployment" contract will be our first example of a contract that emits a "long log" that needs to be split into chunks of (e.g.) 8. However, since that is a protocol contract, the way in which its "long log" is processed will likely be "special", and so we should write an example for a "regular" smart contract too.
• A user (smart contract dev) should be able to do so-called "hybrid encryption", as a bytes optimisation.
  • This is for when you want to encrypt the same data to multiple people.
  • Note: this bytes optimisation only "bites" (ha) if the log length for 1 person exceeds the length of a private log. If, say, a single encrypted payload uses up N private logs, then clearly emitting a version of this encrypted payload to M people would use up N * M private logs. With hybrid encryption, you emit the encrypted payload once (using up N private logs), and then encrypt the symmetric key to the M recipients. Those logs (encryptions of the symmetric key) would use up M private logs. So N + M logs altogether, and N + M is likely < N * M. Given that the encryption of the 16-byte symmetric key (for AES) is much smaller than a private log (even when including the tag and the epk), it's still wasteful to occupy an entire log for just that symmetric key. There might be ways to pack the M users' private logs into fewer logs, although our tagging scheme is very rigid: the first field of a log is the tag, and therefore it's 1 log per recipient. If logs weren't padded (and instead could contain zeros), this would be use fewer bytes, but at the expense of privacy sets. This use case led me to propose those schemes last year where a tail circuit could reorganise logs, to vastly improve privacy sets (whilst still retaining our nice tagging scheme rigidity).
• A user should be able to use custom encryption schemes.

A note on optimising bytes: Given that all logs must be padded to appropriate privacy sets (and given that we currently only encourage a single log privacy set of "Pad all the fields"), optimising bytes will only manifest as worthwhile in the case where a non-optimised log would "spill over" into an extra log. Nevertheless, we should optimise to avoid this spillover.

[iAmMichaelConnor]

Some potentially useful background in these old slides from mid-2024 https://docs.google.com/presentation/d/1LeQUNty5mRIu25iQ_nEplPYdIEEucbu3lEzTi2yldIc/edit#slide=id.g2f2201366fa_0_0 (Although, some details are clearly outdated).