Host function support for confidential tokens

[jayz22]

Confidential transfer refer to transactions where the transferred amount and balances are hidden, while the identities of the transacting parties remain visible. It can be realized as a extension on top of a standard token contract.

Representative work include Zether and PGC, both of which rely on a similar suite of cryptographic primitives and protocols.

This discussion proposes a baseline set of host functions to enable efficient on-chain confidential transfers, and discuss their technical merits and tradeoffs. These may not be the only (or even the optimal) set of design choices, but rather as widely used, well-studied building blocks that can be refined over time.

Proposed Functions

• Homomorphic encryption (e.g., ElGamal / Twisted ElGamal in the Ristretto255 group):

  • Encryption: Given a plaintext m and randomness r, compute the ciphertext C and decryption handle (opening) D.
  • Group operations: Point addition, point-scalar multiplication, etc.
  • Helper functions: e.g., multi-scalar multiplication (MSM).

• Hashing

  • SHA512, for Fiat–Shamir style generation of pseudo-random challenges.

• Range Proof verification

  • Efficient range proofs such as Bulletproofs (e.g., the widely used implementation originally by Dalek, now maintained by ZKCrypto).

We have built an initial working token contract prototype (will soon be migrated to stellar/stellar-confidential-token), with all cryptography on the guest side. The contract size is around 138kb, and the cpu instructions is 2 order of magnitude higher than the current network limit. (Tagging contributors @bboston7, @iftachh)

(tracking issue: stellar/rs-soroban-env#1585)

[dmkozh]

I have a few questions regarding the token interface, or rather, whether it's possible to implement it a bit differently given the proposed set of cryptographic function (or whether something is impossible or requires some additional functions).

• Is it necessary to use u64 for the amounts? Token standard uses i128 to represent balances and it would be nice to be able to use it for confidential transfers as well.
• Would it be possible to implement the private transfers in a separate contract? The main use case for that would be SAC. Or does the proposal involve building this functionality into SAC as a part of some new standard (similarly to how SAC implements SEP-41)?
• I can see that source is being authorized in the confidential transfer and similar calls that also require proofs. Is that really necessary? I would imagine proofs contain all the necessary information and it doesn't really matter who performs the transfer as long as they have the proof. But I don't fully understand all the details.

[jayz22]

Ok, so then we don't need additional auth, do we? That's what I've been trying to understand here. It's not the most important detail, but it seems useful to understand how do private operations fit into the overall auth design.

@dmkozh this is correct. The proofs only validates the logic of contract (that would've been trivial to do if the states are unencrypted). It doesn't replace/enhance/change auth in any way.

[dmkozh]

this is correct. The proofs only validates the logic of contract (that would've been trivial to do if the states are unencrypted). It doesn't replace/enhance/change auth in any way.

I'm confused now, what I was saying is that in my understanding require_auth is not necessary. I don't understand if I'm correct or not. Understanding that is important for the wallets (or generally any clients). That doesn't need to necessarily belong to this discussion, but we'll have to flesh this out for the confidential transfer standard itself.

[jayz22]

It's not obvious to me either why confidential transfers need to be coupled with the token and built into the token.

@leighmcculloch The main advantage is to leverage the existing token framework: the admin control, the compliance, the ecosystem adoption and integration etc. 'm not sure building this off of the token trail would still provide the same benefits. I think it’s possible to build it as a separate contract (that offers 1-1 mapping with an existing token) but the integration won’t be as seamless.
(This is the approach Solana has taken, also matches what @MonsieurNicolas has initially envisioned).

And from your response it does seem like we'll need to build the standard into SAC sooner or later (better sooner, because SAC tokens make up for the most of the value on-chain)

@dmkozh Building the confidential transfer into SAC is a logical step, but requires significantly more work.
For a start we need a more well defined standard, as small choices means the exact proof statements being different (e.g. see chunked integer example above). On top of it we need a formal specification and more theoretical work to fully support/bulletproof the design choices (@iftachh has been making progress but it still requires much more work).

As the ecosystem standards are still forming (see e.g. ERC7984), leaving these as cryptographic primitive host functions preserves maximum flexibility, while still driving innovation by allowing custom token adoption (and in turn provide more clarity to push the standardization effort forward). This is also the path @tomerweller (and others) have laid out.

With that said, this prototype is fairly full-fledged. Similar products/prototypes has been built in other chains (Solana, Aptos etc). This version as is, will be feature ready when the host functions become available.

And cryptographic primitives (that the host functions target) are fairly well-known and widely adopted on their own. Any applications can adopt it and build confidential states and range proof it (such as anonymous voting application @tupui has tried before).

These functions will eventually be a necessary step towards enabling confidential transfer at the protocol level (e.g. native confidential token contract similar to SAC).

[tomerweller]

From a host functions perspective it seems like the topic of whether or not we couple confidential transfers within the token contract is less relevant. Maybe we should start a different discussion on that?

Regardless, I support decoupling confidential transfers from the token standard. Some reasons:

• It is very likely that adoption will rely on existing assets
• We want to ensure that trust-minimized tokens without an issuer like XLM and contract managed tokens are supported
• Generally speaking, confidentiality/privacy is a moving target both in terms of tech and in terms of admin controls. Asking issuers to to enshrine and commit to one version might prove problematic down the road

I'm aware that other ecosystems and standards are going for this coupling. I'm not a fan of that approach

[dmkozh]

From a host functions perspective it seems like the topic of whether or not we couple confidential transfers within the token contract is less relevant. Maybe we should start a different discussion on that?

Sure, it's just that the original discussion is coupled with the prototype, which brought up a question regarding the scope of the protocol changes necessary to support confidential transfers. I think the sooner we start discussion on the standards, the better (knowing how much time it usually takes to flesh out the details).

[dmkozh]

Coming back to the host functions specifically, we seem to be pretty opinionated here in terms of which specific primitives are used (say, SHA-512 and e.g. not keccak-512, not to mention much more impactful algorithm choices like homomorphic encryption and ZK-proofs). Can we end up in a situation where ecosystem wants to build something, but we don't support that, so we need to do pretty much same work again (as in the BLS vs BN case)? On the other hand, is there maybe a way to leverage the 'opinionated' approach and come up with higher level, simpler to use functions?

[dmkozh]

Encryption: Given a plaintext m and randomness r, compute the ciphertext C and decryption handle (opening) D.

I've checked the prototype and I don't see this being used, which would make sense as encryption on-chain is pretty meaningless. Is this actually necessary for anything?

I guess I'm generally looking forward to the final list of the proposed functions, but this one in particular really stands out.

[tupui]

I've checked the prototype and I don't see this being used, which would make sense as encryption on-chain is pretty meaningless. Is this actually necessary for anything?

I am dreaming about encrypting on-chain 😅 If you could do that eg straight from your keys that would open a lot of use cases. Eg hiding a seed. Or during a tallying phase deciphering onchain ballots to prove the result (people would have used your public key or else). Otherwise you can do a lot of maths but hiding the first inputs to the system is challenging without encryption. (Or I am missing something big and would be more than happy to be told so 😅)

[dmkozh]

I am dreaming about encrypting on-chain

There is no way to actually encrypt anything on-chain without revealing all the inputs, which makes the encryption meaningless. There probably could be a way around that, but not with the current architecture and definitely not within the scope of this discussion.

[dmkozh]

That said, I might be missing something here as well.

[tupui]

Some rabbit hole definitely https://crypto.stackexchange.com/questions/3260/using-same-keypair-for-diffie-hellman-and-signing but don't want to still the main show with that 😅