[Received this question on Twitter; posting here for others that may come to the forum with questions like this]
Will Aztec support optional decryption? Can an encrypted state be decrypted, if some conditions are met?
84 Likes
I don’t think this will be supported natively by the protocol, but perhaps @Mike can confirm.
There are probably other tools / protocols that could be used with Aztec that would enable this functionality. @colinnielsen actually built a project at ETH Bogota using Lit protocol (iirc) that conditionally decrypted off-chain data based on an on-chain private transaction on Aztec Connect.
72 Likes
If you can link the tweet think that would be useful as well.
TL;DR:
Not on the protocol level. But on the application level, the developer could build it in such a way.
The state is practically commitments to data and not really an encrypted version. Encryption implies that you can go from plaintext → ciphertext and back again using a key etc. In the aztec design, we are using pedersen commitments for the state. These commitments are perfectly blinding and computationally hiding, meaning that you might find some opening if you try hard enough but you don’t know if it is the same data that was committed to. e.g., QC might figure that A’ and B’ is an opening to C, but it can be different to A and B, so you are not learning much from it (but you might be able to use different openings to spend funds that were not yours 
)
Because of these properties having a nice UX can be quite the hassle as you need to somehow tell the recipient or new owner of a note that they have received the ownership.
To get around this, the user can publish an encrypted version of the note content that can be decrypted by its recipient, sometimes this is called a viewing key. In Aztec Connect, the user was sending this viewing key as part of their transaction to the sequencer and it was broadcasted on-chain as well. The recipient would then be able to read this data from on-chain and try to decrypt each viewing key using his “privacy key”.
In the new system, the application developer can have the function encrypt the note content using whatever mechanism he thinks is good, and emit this encrypted data as an event. The recipient can then decode the data because he got the key. In most cases, this will probably be using a standard implementation of the notes (which don’t support optional decryption), but there might be developers that want to make it optionally decryptable.
73 Likes
Hi @LasseAztec, that was a question of mine shared with @brunny-eth privately on Twitter.
Thanks for the exhaustive answer. Do you see any application that would get any utility in having optional decryption for notes?
68 Likes
I’m curious about your use-case?
76 Likes
I was speaking with a guy doing research for a large web2 payment provider and discussing about using web3 based payment channels. He mentioned that privacy would be a required feature, but also they’d require a way to unmask specific transactions if mandated by a jury for example.
5 Likes
A web2 payment provider could create accounts for users and the user and the payment provider could have a copy of the decryption key.
This would replicate the current privacy guarantees of current web2 payment providers, where a user and the provider can both read transaction history, but it is hidden from the rest of the world.
8 Likes
There isn’t a way to execute this trustlessly with only the Aztec network. There may be a way to build an application that leverages the Aztec network for part of the functionality, but it will almost certainly require additional components to make it fully trustless and failure proof.
3 Likes
I think I follow, but may be missing something.
I don’t think so. The SUA would be a contract that would need to run some computation in a private context (decrypting and re-encrypting). That would have to happen on the SUA owner’s computer. It wouldn’t be able to happen automatically without action by the SUA owner.
3 Likes
Chiming in quickly here.
While you cannot get the contract to re-encrypt when Bob pays Alice, because Bob don’t know the key. I don’t see anything that stops you from making a contract where Alice needs to leak the decryption key in order to claim the funds that Bob paid.
So you make the payment two steps, one where Bob pays, and one where Alice claims + send key to Bob. If not Alice claim within X time, Bob could get the funds back, and if she claims Bob got the key and all is good.
4 Likes
@LasseAztec How does the contract verify that Alice sent the key to Bob?
The key can be shared inside a note inside the contract. So the contract forces Alice to generate a note where the value is the key, and insert the note with Bob as the owner, and have the contract encrypt the preimage of the note using Bobs key and broadcast it. Essentially broadcasting the key encrypted with Bobs such that only he can decrypt it.
A requirement would be that you can ensure that the key she inputs is the decryption key, but you could decrypt the message in a private function to do that etc.
// Executed by Bob
fn bid(amount) {}
// Private function executed by Alice
fn claim_funds(amount, key) {
// Some check to verify that `key` is the correct key
// create note for Bob with `key`
// Send encrypted version of Note to Bob.
}
6 Likes
The state is practically commitments to data and not really an encrypted version. Encryption implies that you can go from plaintext → ciphertext and back again using a key etc. In the aztec design, we are using pedersen commitments for the state. These commitments are perfectly blinding and computationally hiding, meaning that you might find some opening if you try hard enough but you don’t know if it is the same data that was committed to. e.g., QC might figure that A’ and B’ is an opening to C, but it can be different to A and B, so you are not learning much from it (but you might be able to use different openings to spend funds that were not yours )
4 Likes