How do we broadcast encryptions of private state?

Aztec
1

In Aztec3, private state will be wrapped in a commitment, which looks something like:

h(contract_address, h(storage_slot, value, owner, salt, nonce))

The value itself might also be a hash of data. For example if it represents a struct, it’ll be a hash of the struct’s data members.

We need a way of transmitting the preimage of the commitment, and the preimage of the value, to the owner of the private state.

Questions:

  • Do we broadcast an encryption of the preimage?
  • How would we broadcast the data? L1? Nym? Other DA solution?
  • Which encryption scheme to use?
  • Do we enable devs to control which encryption scheme to use?
    • If so, we’d need to inject custom decryption code into the Private Client on a per contract basis.
  • Encrypted preimages of struct / array data will be variable in length, which will leak information about the function that’s been executed. Can we pad that data?
  • Do the preimages of commitments always follow the default layout as prescribed by Noir++?
    • Or, do we enable devs to design their own commitment preimages?
  • Do we emit the encrypted data as public inputs of the circuit?
  • Do we add constraints within the circuit to verify correct encryption?
  • Perhaps it’s actually always in the tx sender’s interest to provide the preimage data to the owner?
    • For example, in Aztec Connect, if the sender doesn’t provide a preimage to the recipient of value, it can be interpreted by the recipient that they were never paid.
    • If so, maybe we can trust that they transmit it somehow, and the protocol doesn’t need to expose a rigid way of transmitting the data.
27 Likes
2

Reviving this discussion thread:

The best DevEx would be to have a Noir keyword for emitting events. The Aztec rollup’s execution context would guarantee the following:

  1. The event payload made its way into Blob data via EIP 4848 with each rollup.
  2. Fee’s and metering would apply to the size of the event payload.
  3. The Noir Conract ABI should provide unconstrained functions for encoding / decoding events and encryption and decryption, allowing a developer to define implementations for a given contract / note implementation.

If we have the above, a developer can define custom encrypted data per transaction that can be broadcast. This could be encrypted note pre-images / viewing keys, metadata or KYC info.

Do we add constraints within the circuit to verify correct encryption?

Not sure this is needed, the developer can chose to do this if relevant to their application.

28 Likes