[confidential-transfer] Add confidential burn proof generation and extraction

[samkim-crypto]

Problem

There are no proof generation and verification logic for the new confidential mint and burn extension (#6879).

Summary of Changes

Added the proof generation and verification (context extraction) logic for the confidential mint and burn logic. There is already a community PR (#6881) that adds the extension on the program side. This PR just adds the confidential mint and burn zkp logic in the new confidential transfer submodules.

The description of the zkp can be found in #6879, but we basically need the following components:

• The confidential burn zkp is essentially the same as that of a confidential transfer. We need the following components:
  • The ciphertext-commitment equality proof for the newly updated spendable balance in the source account exactly like in a confidential transfer.
  • The ciphertext validity proof to prove the well-formedness of the ciphertext that encrypts the burn amount. Unlike a confidential transfer, we encrypt w.r.t. source, auditor, and supply authority public keys.
  • The range proof to prove the remaining balance at the source is a positive 64-bit number and that the burn amount is a 16 and 32-bit number.
• The confidential mint zkp is the same as that of confidential burn, but since we don't need to worry about the remaining balance at the source, we remove the ciphertext-commitment equality proof.

[joncinque]

Just a couple of tiny things and a question about how minting should work, but since I think you've explained the answer to me before, I'll approve to not stop this.

[joncinque]

Sorry if this is a silly question, because I think you've described it before, but I don't remember the answer.

The mint proof looks like it just adds whatever ciphertext is provided, as long as it's well-formed. Is there a check on the resulting amount in the token account at some point? What happens if you mint u64::MAX on a loop into someone's account?

[samkim-crypto]

Yeah this is actually a good question. There could be two issues here. One is that the destination account ciphertext could be non-decryptable because the underlying encrypted value grows too large. This is not an issue because the mint amount is restricted to 48-bits (by range proof) and gets added to the pending balance instead of the available balance. There is a pending balance credit counter (https://github.com/solana-labs/solana-program-library/blob/master/token/program-2022/src/extension/confidential_transfer/mod.rs#L105) to limit this amount and the receiver can always do ApplyPendingBalance to flush this out.

The second issue is that the global supply itself can surpass 2^64. If each mint amount is 2^48 max, then after 2^16 ~ 65k mints, the total supply can surpass 2^64. The ElGamal ciphertexts (and Pedersen commitments) can store up to 256-bit amounts, so the supply can technically go up to this amount (it will never be able to surpass this number because you need to mint 2^208 times, which is practically impossible). I did not add it, but if we do not want the supply to surpass 2^64, then we can add an extra range-proof in the mint proof certifying that the supply ciphertext is always a 64-bit number. What do you think?

[joncinque]

Hm, that's a tough one. SPL Token mints are normally limited to a max supply of 2^64, so my inclination is to force the same thing here. Otherwise, people can get in strange situations where they try to deserialize their balance as a u64 and get unexpected values. If it were a totally new protocol, we could avoid the constraint totally and go with 2^256, but I worry about downstream issues. Unless there's a compelling reason for the supply to go up to 2^256, I think we'll need that extra range proof.

Pull request has been modified.

[samkim-crypto]

I have added ciphertext-commitment equality proof and an extra range proof to the confidential mint proof data. When the supply authority creates a confidential mint instruction, it must add the mint amount to the supply in the mint and prove that this value is a 64-bit number. Since the encrypted randomness that pertains to the supply ElGamal ciphertext is not necessarily known by the supply authority, it must provide an extra commitment to the new supply and generate range proof with respect to this commitment. The ciphertext-commitment equality proof certifies that this commitment holds the same value as the new supply ciphertext.

[joncinque]

Looks great, thanks!

Pull request has been modified.