Expand description

Generates the zero-knowledge proofs required for a confidential transfer.

A confidential transfer requires a composition of three distinct zero-knowledge proofs to ensure correctness and security. This function orchestrates their generation.

§Protocol Flow and Proof Components

  1. Encrypt Transfer Amount: The transfer amount is split into low (16-bit) and high (32-bit) components. This is done to facilitate efficient decryption, which would otherwise require solving the discrete logarithm problem over the entire 64-bit range. Each component is encrypted as a grouped (twisted) ElGamal ciphertext with decryption handles for the source, destination, and an optional auditor.

  2. Generate Proofs: The sender then generates the following proofs in a specific logical order:

    • Ciphertext Validity Proof (BatchedGroupedCiphertext3HandlesValidityProofData): This proof certifies that the grouped ElGamal ciphertexts for the transfer amount are well-formed (i.e., they are valid encryptions of the low and high bit components under the source, destination, and auditor keys).

    • Range Proof (BatchedRangeProofU128Data): This proof ensures solvency and prevents the creation of tokens. It certifies that:

      1. The sender’s remaining balance is a non-negative 64-bit integer. This is ensures that current_balance >= transfer_amount.
      2. The low and high components of the transfer amount are valid 16-bit and 32-bit integers, respectively.

      A range proof can only be generated from a Pedersen commitment for which the prover knows the opening. However, a sender does not necessarily know the Pedersen opening for the ciphertext associated with the sender’s remaining balance ciphertext. This this necessitates the ciphertext-commitment equality proof below.

    • Ciphertext-Commitment Equality Proof (CiphertextCommitmentEqualityProofData): We require that the sender create a new Pedersen commitment to their known plaintext remaining balance. This equality proof then certifies that the homomorphically computed new_balance_ciphertext and the new Pedersen commitment encrypt/commit to the exact same value.

These three proofs, when verified together, allow the on-chain program to securely process the confidential transfer.

Structs§

TransferProofData
The proof data required for a confidential transfer instruction when the mint is not extended for fees

Functions§

transfer_split_proof_data