[zk-token-sdk] Proposal to use application agnostic names for instructions and modules

[samkim-crypto]

Problem

Currently, the zk-token-sdk and zk-token-proof program use module and instruction names that are unnecessarily specific to the token extension confidential transfer application. However, the tools in these modules can be used more generally for a wider set of cryptographic and zk applications.

Proposed Solution

Carry out the following module name changes:

• zk-token-sdk --> zk-sdk ([zk-sdk] Create zk-sdk crate #988)
• zk_token_proof_* --> zk_elgamal_proof_* (e.g. zk_token_proof_program --> zk_elgamal_proof_program) ([zk-sdk] Add the program module #1188)
• zk_token_elgamal --> pod ([zk-sdk] Add pod module #1169)

Carry out the following changes in the zk-token-proof instructions:

• VerifyZeroBalance --> rename to VerifyZeroCiphertext ([zk-sdk] Add error types and zero ciphertext instruction #1453)
• VerifyFeeSigma --> rename to VerifyPercentageWithCap ([zk-sdk] Add equality, pubkey validity, and percentage-with-cap instruction data #1467)
• VerifyWithdraw --> remove instruction (instruction not added to zk-sdk)
• VerifyTransfer --> remove instruction (instruction not added to zk-sdk)
• VerifyTransferWithFee --> remove instruction (instruction not added to zk-sdk)
  In place of the removed instructions above, applications can alternatively use combination of validity, equality, and range proof instructions with proof context.

In the sigma module, carry out the following naming changes:

• fee_sigma_proof --> percentage_with_cap_proof ([zk-sdk] Change FeeSigmaProof to PercentageWithCapProof #1084)
• zero_balance_proof --> zero_ciphertext_proof ([zk-sdk] Change ZeroBalanceProof to ZeroCiphertextProof #1085)

Alternative Considered

Ideally, it would be much cleaner and nicer to create a separate RangeProof program and a SigmaProof program. The RangeProof program can be a native program that replaces the ZkTokenProof program and the SigmaProof program would be a standard bpf program that makes use of the curve25519 syscalls. Then the RangeProof program will be much simpler and lighter than the current ZkTokenProof program and since the SigmaProof program is a bpf program, the instruction names and description can be adapted specifically for the token-extensions application. However, the SigmaProof program would require additional syscalls for doing the Scalar arithmetic and adding these would greatly delay the activation date for token-extension confidential transfers.

If we do add the Scalar arithmetic syscalls, then it could also be possible to implement RangeProof and SigmaProof programs as SBF programs. This would be a really nice solution for Fierdancer since the zk proofs are not implemented in the validator client code anymore. However, similar to above, going through the process of implementing and activating the Scalar arithmetic syscalls would greatly delay the activation date for token-extension confidential transfers. Also, it is unclear how expensive implementing the range proof verification would be even with runtime support for scalar operations.

Finally, we can consider creating two native programs, the RangeProof and SigmaProof programs. However, this would be creating two native programs that may be outdated by runtime v2. The entire process for adding the native SigmaProof program will also set back the activation date for token-extension confidential transfers greatly as well.

All things considered, it seems like the best route forward right now is to simply carry out the renaming as specified above to make the program be more application-agnostic (i.e. independent of the token-extensions confidential transfers).