-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Confidential mint-burn extension #6881
base: master
Are you sure you want to change the base?
Confidential mint-burn extension #6881
Conversation
@abcalphabet, there has been some work on refactoring the zk logic in the |
Also, is it okay if you split the PR into
|
Hey @samkim-crypto, will rebase your changes and use that logic. Splitting it into two PRs also makes sense, will get on that as well. |
@samkim-crypto two questions: Splitting the PRsThe tests in Auditability of instructionsI think I forgot to mention this on the issue discussing the feature: Currently the auditor ciphertexts are only included in the context state accounts which makes using them in practice somewhat complicated since in order to continuously monitor transactions one needs to watch transactions on the token, get the ciphertext pubkey from the instruction, fetch all transactions on the ciphertext pubkey, find the proof instruction and extract the auditor ciphertext from there. This PR includes the auditor ciphertexts in the instruction itself so that token transactions (just mints and burns atm really) can be continuously audited by simply streaming transactions involving the specific token mint. Does this make sense to you? If it does make sense I guess putting that logic in a seperate issue / PR adding this across the board (including in the normal |
Oh yes, that is completely fine with me. Sorry for the confusion. Let's just isolate the program logic changes.
Yes that is a good point. I think it makes sense to split that logic into a separate issue / PR so that we can add it to the rest of the extensions as well like you suggested (it seems that it would just be the confidential transfer instruction). Currently, the instructions should contain the addresses of the context/record accounts (https://github.com/solana-labs/solana-program-library/blob/master/token/program-2022/src/extension/confidential_transfer/instruction.rs#L272-L277), so I think one can monitor transactions on the token, look up the associated proof accounts (probably just the equality proof account), and then extract the auditor ciphertext from there. I wonder if logging can also help here. Every time a confidential transfer, mint, or burn instructions are executed, the program logs ( |
@samkim-crypto Another question regarding the proof generation logic you added: When generating the mint proofs there is an assumption that the mint would have a On the issue we had discussed just using a Do you have any ideas on how to properly do this? Or am I just missing something obvious |
Yes that is a good point. I forgot to point this out, but the mint should have a decryptable balance As you suggested though, the decryptable balance cannot always encrypt the correct balance in practice. The important point here is that the an ElGamal ciphertext is hard to decrypt when the encrypted value is large, but it is homomorphic, so it can still be decrypted relatively easily with the help of the decryptable ciphertext. Let's denote the current ElGamal ciphertext encrypting the supply as
The point here is that in step 4, |
Yup, makes perfect sense. Thanks for the explanation! |
@samkim-crypto changed everything to use the new proof logic. Seperate PR with just the token program changes here: #7319 |
Co-authored-by: samkim-crypto <[email protected]>
…ction.rs Co-authored-by: samkim-crypto <[email protected]>
WIP implementation for the feature proposed in #6879
How to run
Start up a local validator with the bpf compiled from this branch and the zk-token-sdk enabled on it.
Build the cli on the branch and run the following
Implementation notes
This PR uses the proofs used for the transfers, obviously only proofs for two Ciphertexts (After some discussion on the corresponding github issue, this has been resolvedmint_to / burn_from
andauditor
) are necessary, so there's some inefficiency there as the transfer proofs create a third one on top of that. (Ab)Using these transfer proofs does however mean that the logic can work on it's own without additional changes to thesolana-zk-token-sdk
.