Broadcast the 'public key' and 'partial address' as L1 calldata, when deploying an account contract

[iAmMichaelConnor]

Currently, recipients have to be manually registered via the aztec rpc server. This approach doesn't scale, because if you call some function of some smart contract, you might need to encrypt a note for some counterparty that you've never interacted with before (the counterparty's address might only be derived at runtime!).

So (at least until we implement a better keys scheme) we need an aztec node to passively 'gobble up' the address, public key and partial address of every deployed account contract, so that the simulator can grab that information whenever a function wishes to perform an encryption.

Note:

• The act of querying this address data from a public node is leaky, if the user is not running their own public node. Research is underway to explore private retrieval.

Definition of "Done"

• An address, public key, and partial address are broadcast as calldata to L1
• All new such address data is gobbled up and stored in a db (I'm not sure by which module of the stack, but you'll know :) )
• Whenever a noir contract needs to generate an encrypted log for a recipient, it can call an oracle, passing the recipient's address. The simulator can (somehow) query the corresponding public key and partial address. The oracle returns this information to the circuit.
• All existing example Noir contracts are updated to use this new approach to encrypting notes (rather than registering a recipient).
• e2e tests are updated to use this approach (rather than registering a recipient).

Possibly blocked by #1139 (although if encryption is currently being correctly performed by typescript (as a hack vs encrypting within Noir), this issue is not blocked, because we can update the typescript code).

[benesjan]

I would approach this by renaming our ContractDeploymentEmitter back to UnverifiedDataEmitter and emit NewRecipient event in that. Does that sound good to everyone?

[iAmMichaelConnor]

I'm not sure. I suppose ContractDeploymentEmitter is still an accurate description. It's data which is emitted when an (account) contract is deployed. I think some people had confusion with the word "unverified", because the hash of the data is checked on L1 (so it is 'verified' in a way).

NewReceipient might not quite be the right name. It's simply "new address data", and all address data should be gobbled up into a db. ("Recipient" might not be the correct term. At the point the contract is deployed the data doesn't represent a "recipient", it simply represents an "address").

[iAmMichaelConnor]

I just added a 'defn of done'.

[PhilWindle]

@iAmMichaelConnor Are we ok publishing this data for all contract deployments? I don't really know how we can differentiate between an account contract and a non-account contract.

[iAmMichaelConnor]

Good question. What's the public key for a non-account contract? Is it 0?

Aside: It's tricky. The act of encrypting data for someone only makes sense for EoAs (externally owned accounts, like users, or bots). Encrypting data for a non-account contract address is kind-of pointless, because a non-account smart contract isn't capable of decrypting something (it's incapable of owning a secret that only it knows).
So in Aztec, it seems there's a fundamental difference between an account contract and a non-account contract. Maybe that fundamental difference is just "is the public key equal to 0?". Maybe if the public key of a non-account contract is always 0, the noir code to generate an encrypted log can conditionally not output a log.

[benesjan]

NewReceipient might not quite be the right name. It's simply "new address data", and all address data should be gobbled up into a db. ("Recipient" might not be the correct term. At the point the contract is deployed the data doesn't represent a "recipient", it simply represents an "address").

@iAmMichaelConnor But the only reason of publishing the new address data (we've created a CompleteAddress type exactly for that) is that the given smart contract can receive a note, no?

But anyway, I am ok with calling the event something like NewCompleteAddress or just CompleteAddress.

[iAmMichaelConnor]

@iAmMichaelConnor But the only reason of publishing the new address data (we've created a CompleteAddress type exactly for that) is that the given smart contract can receive a note, no?

But anyway, I am ok with calling the event something like NewCompleteAddress or just CompleteAddress.

Fair point! I'll let you decide :)

[PhilWindle]

@iAmMichaelConnor Our API is pretty unrestrictive as it stands. Ultimately, the public key used in the deployment of any contract (account or otherwise) is whatever the client of aztec.js decides to give it.