You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What remains in the zk token proof program is the ciphertext validity (and batched ciphertext validity) proof, which certifies that a variant of ElGamal ciphertext is well-formed.
The issue is that the ciphertext validity proof that is needed for the confidential transfer instruction is not a validity proof on the standard ElGamal ciphertext, which is an encryption of a message under a single ElGamal public key. Instead, the validity proof is on a "grouped" variant of ElGamal ciphertext where the message is encrypted under multiple ElGamal public keys at once.
We can add VerifyCiphertextValidity and VerifyBatchedCiphertextValidityProof in the proof program, but this may be confused as certifying validity on a regular ElGamal ciphertext. A more suitable name for these two proofs would be VerifyGroupedCiphertextValidity and VerifyBatchedGroupedCiphertextValidity.
We can go ahead and rename the implementation in #31816 as VerifyGroupedCiphertextValidity and VerifyBatchedGroupedCiphertextValidity, but a cleaner way would be to actually create a GroupedElGamalCiphertext type in the encryption module and define these proof instructions with respect to the GroupedElGamalCiphertext type.
Defining GroupedElGamalCiphertext would also help in simplifying/cleaning up the VerifyTransfer and VerifyTransferWithFee instruction data as the TransferAmountEncryption and FeeEncryption types can be defined with respect to GroupedElGamalCiphertext type.
Problem
What remains in the zk token proof program is the ciphertext validity (and batched ciphertext validity) proof, which certifies that a variant of ElGamal ciphertext is well-formed.
The issue is that the ciphertext validity proof that is needed for the confidential transfer instruction is not a validity proof on the standard ElGamal ciphertext, which is an encryption of a message under a single ElGamal public key. Instead, the validity proof is on a "grouped" variant of ElGamal ciphertext where the message is encrypted under multiple ElGamal public keys at once.
We can add
VerifyCiphertextValidity
andVerifyBatchedCiphertextValidityProof
in the proof program, but this may be confused as certifying validity on a regular ElGamal ciphertext. A more suitable name for these two proofs would beVerifyGroupedCiphertextValidity
andVerifyBatchedGroupedCiphertextValidity
.We can go ahead and rename the implementation in #31816 as
VerifyGroupedCiphertextValidity
andVerifyBatchedGroupedCiphertextValidity
, but a cleaner way would be to actually create aGroupedElGamalCiphertext
type in the encryption module and define these proof instructions with respect to theGroupedElGamalCiphertext
type.Defining
GroupedElGamalCiphertext
would also help in simplifying/cleaning up theVerifyTransfer
andVerifyTransferWithFee
instruction data as theTransferAmountEncryption
andFeeEncryption
types can be defined with respect toGroupedElGamalCiphertext
type.Proposed Solution
GroupedElGamalCiphertext
type ([zk-token-sdk] AddGroupedElGamalCiphertext
type #31849)VerifyGroupedCiphertext2HandlesValidity
andVerifyBatchedGroupedCiphertext2HandlesValidity
proof instructions #31816 toVerifyGroupedCiphertextValidity
andVerifyBatchedGroupedCiphertextValidity
instructionsTransferAmountEncryption
andFeeEncryption
types as simple wrappers around the typeGroupedElGamalCiphertext
The text was updated successfully, but these errors were encountered: