Reduce the constant private logs length

[iAmMichaelConnor]

The only thing seemingly requiring the current number of fields (it's something like 16 or 18) is our own "contract instance deployment" contract, where data about the contract instance (something like 16 fields) is broadcast. We can still make a private log be 8 fields, and then simply split that 16-field log into two 8-field private logs.

Why 8 fields?

We should validate that this is an acceptable number, but 16 is too high, since all example contracts use far fewer fields per log, so users would be burning blob money on padding.

TODO: How much money per Field? How much money per tx? How much money per block? (Range of estimates, depending on blob gas market).

A basic token note, which uses AES might contain this data:

• Tag (Field)
• Epk (Field + 1 bit)
• Header Ciphertext (16 bytes)
  • Log Type Id / Note Type Id / Proper Ciphertext Length (all 3 of these things might be conveyed through a single id).
• Storage Slot (1 Field)
• Value (Maybe u128, Maybe 1 Field... let's say 1 Field).
• Owner (1 Field)
• Sender (1 Field)
• Memo (1 Field)
• AES Padding (Up to 16 bytes)

That's 7 Fields + 1 bit + 2 * 16 bytes. Hmmm... ok so 8 fields might not be enough.

You'll notice I added a Sender and Memo field: that's after a chat w/ Joe on token standard requirements.

Non-token use cases might not need those extra two fields.

Also note: Other encryption schemes use more data than AES:

• Poseidon2 adds 1/2/3/4 extra fields to the length, depending on the plaintext length.
• El Gamal (for example's sake, and because a homomorphic encryption scheme is used by some prominent privacy protocols) roughly doubles the message length.
• Post-quantum schemes are big, so would need to span logs, or possibly leverage (overload) the contract_class_log, or require a protocol upgrade to change private log lengths.
• Rescue Prime... I don't know how long it is, but it's used in the space.

Of course, alt encryption schemes can always break their logs into chunks (albeit a faff), but poseidon2 encryption will be common (I've already seen it a few times in the wild, on Aztec).

Ignoring the post-quantum bullet (to simplify the conversation), there's a hint that 8 fields isn't actually enough, and perhaps 16 fields is actually more attractive. I'm mentally being "sticky" against powers of 2. We could also choose a length between 8 and 16.

It could be that an outcome of this rambling issue is that 16 is actually a good length after all. Or maybe 12 is the best number. We need an upper bound that's a good balance between reducing costs for common use cases, and flexibility. We can also always socially introduce a few log length privacy sets (as a social experiment): 8, 12, and 16, and therefore leave the max "private log" length untouched at 16.

cc @LeilaWang @nventuro

[iAmMichaelConnor]

Some $ costs of blob fields, if my old spreadsheet is right. So depending on the market, the log-only cost of a tx ranges from completely negligible to <$20 in bull market conditions that we've seen in the past, to <$100 for finger-in-the-air future bull market conditions.

The final number in each pick is the headline dollar cost of the logs of a tx.

Note: in the $100 bull market scenario, an ETH tx would be $210.

Current market conditions (bearish):

Bull market conditions ($3500 eth, 250gwei/gas) (but without blob price discovery, so setting blob gas price at 1gwei):

Bull market conditions (with blob gas price equal to normal gas price, to see what happens):

Bull market conditions (with blob gas price equal to the highest number it's ever been (585 gwei/blobgas):

Mega bull market conditions (10k eth, 1kgwei/gas, 1kgwei/blob_gas) (this scenario is pretty unlikely, in terms of blob gas cost, I would hope):