feat: stablecoin draft specification

[CjS77]

This Request for Comment (RFC) describes a possible manifestation of a privacy-preserving stablecoin on the Tari Digital Assets Network (DAN).

The stablecoin design broadly follows that of Tether and Circle's ERC-20 stabecoin, with the exception that amounts and transacting parties are confidential.

The latest draft represents a more fully-fledged design for a privacy-enabled stablecoin and one that approaches feasibility.

It is still likely insecure in places and there are still a few holes to plug in some of the operations, but the broad brushstrokes are certainly there.

The specification given here focuses on a surveillance-enabled stablecoin (i.e. CBDC) model.

The specification is presented neutrally as pure technology and should not be construed as an endorsement of centralised surveillance. In fact, the author abhors surveillance of individuals' sovereign wealth, but since this is actually the more difficult case to implement in a zero-knowledge manner, it is fairly straightforward to modify the specification to implement a free (as in speech) stablecoin (i.e. digital cash) model. Some hints are given at the end on how one might actually achieve this.

There are also some tweaks that could allow/deny the central issuer to arbitrarily seize funds from accounts. Obviously a free model would disallow this feature.

[AaronFeickert]

The structured hash preimage proof required to define masks seems problematic; it could be done using a generic circuit-based proving system, but likely complex. However, I had another idea that wouldn't require this.

An account is instantiated using a public key (chosen by the user) and signed by the issuer to indicate its approval, and initially with an empty commitment. When a sender wishes to transfer funds to a recipient, it does the following:

• generates a random commitment to the transfer amount, along with a range proof on this commitment
• generates a second random commitment to the transfer amount, along with a proof of equality to the first transfer commitment value
• encrypts the transfer value and second commitment's mask to the recipient using a non-interactive ephemeral Diffie-Hellman exchange against the recipient's public key
• produces a range proof that the difference between the sender's balance commitment and the first transfer commitment is non-negative
• produces a verifiable ElGamal encryption of the sender's updated balance to the issuer's public key, coupled with a proof that this value matches the sender's updated balance commitment
• encrypts the sender's updated balance commitment opening using its own private key using an AEAD
• signs the transfer data

This approach can still use the nonce-based approach of the original design to keep state order.

After performing suitable validation checks, the sender's account information is updated by validators.

When claiming the transfer, the recipient does the following:

• decrypts the transfer commitment value and mask
• generates a random commitment to the transfer value, along with a proof of equality to the original transfer commitment
• encrypts its updated balance commitment value and mask using its own private key using an AEAD
• produces a verifiable ElGamal encryption of its updated balance to the issuer's public key, coupled with a proof that this value matches its updated balance commitment
• signs the transfer data

Validators can then perform suitable checks, after which the recipient account is updated.

This design allows the issuer to view any account's balance simply by performing ElGamal decryption (and using brute force on the value, as in the original design). It also makes it easy for a user to recover their current balance by decrypting the balance commitment opening.

Note that a transfer involves three separate commitments to the transfer value. Only the sender knows the mask to one, the sender and recipient know the mask to another (via encryption), and only the recipient knows the mask to the third. This allows validators to assert that the value deducted from the sender's account matches the value added to the recipient's account, but ensures that only an account holder (whether sender or recipient) controls the mask used to update its balance commitment.

[CjS77]

Great suggestions, esp ElGamal encryption idea. I was looking for something like this but I wasn't aware of how to do the proof of equality.

[AaronFeickert]

I'm writing all this up more formally, including details on the required proofs.

[AaronFeickert]

Here are some work-in-progress design notes. I've tried to unify the handling of checks, as well as minimize the changes required for transfers involving the issuer to ensure the issuer's balance and check values are public and verifiable.