Feature Proposal: Confidential Permanent-Delegate Extension

[abcalphabet]

Proposed feature

Token-2022 adds the token-extension of confidential transfers. For normal token transfers Token-2022 further adds the permanent-delegate extension, which allows granting a signer the authority to move tokens from any token account belonging to a mint at will. This functionality is however not present for confidential balances.

Adding an authority with "root-access" should also be possible for the confidential balances of a mint.

Why is this needed

The use of confidential balances lends itself especially well for the tokenization of assets in a more regulated environment. At Iron we’re using Token Extensions to issue tokenized bank deposits, which comes with a wide range of possible regulatory and business processes to consider. Within this context it can be necessary to not just freeze accounts of holders, but also to move tokens to different token accounts or burn them. For this a permanent delegate able to move confidential balances is needed.

Proposed solution

A confidential-permanent-delegate extension, which adds an authority with the ability to move tokens in the confidential balance of any token account from the mint.

There is one main problem to adding this logic, which is that to move funds in a confidential balance the balance encryption keys (ElGamalKeypair & AeKey) are required to generate the relevant zk-proofs. So in order for the permanent delegate to be able to move funds, these secret keys have to be shared with the holder of the authority.

The proposed solution to the secret sharing issue is to by default set the approved flag on the confidential balance to false if the confidential-permanent-delegate is activated on a mint. The normal Approve instruction would then also be disabled and the approving of accounts could only be done via an ApproveAccount instruction processed within the new extension.

This approval would have to be signed by the permanent delegate and only go through if a proof of knowledge of the encryption keys is provided alongside it. For this process the extension would add the public key of an asymmetric encryption key-pair to the mint's data, which would be used to encrypt the ElGamalKeypair & AeKey and post them to chain where the permanent delegate could then read them.

On mints with the confidential-permanent-delegate enabled, the token account creation flow would then be as follows:

1. When a new token account is initiated, the initiator uses the mint's asymmetric encryption public key to encrypt the ElGamalKeypair & AeKey and post them to chain
2. The permanent delegate reads the account data and uses the asymmetric encryption private key to decrypt the posted encryption keys and then uses those to generate the relevant proofs
3. The permanent delegate submits an ApproveAccount instruction which evaluates the generated proofs, compares the provided keys to those in the token account and approves the token account if everything is in order
4. The account is approved and ready for usage

[samkim-crypto]

Great! Thanks for a great write-up. I agree that this is also well-motivated.

One thing to note is that there is no mechanism to enforce that a single AeKey is used consistently throughout the lifetime of an account. The AeKey is only used to facilitate decryption by the owner since ElGamal decryption could be quite slow. So in one transfer, a user could use one AeKey and in the next transaction, a different AeKey could be used. However, once the delegate authority have access to the AeKey, it will use it to make transfers, so there is not really a motivation for the user to use a different AeKey.

This extension will actually be a lot simpler to implement than confidential mint/burn since there are no zero-knowledge proofs involved. We just require that the account extension holds the encryption of the ElGamalKeypair and AeKey under the authority's encryption public key. Once the authority decrypts the keypair and verifies that is valid, it can approve the account by including a VerifyPubkeyValidity (proof-of-knowledge) instruction in the same transaction. There is no mechanism to prove knowledge of AeKey, but since AeKey is not used to generate zero-knowledge proofs, this should be fine.