NEP: Confidential Token Standard

[corollari]

Abstract

This NEP proposes a token standard that enables confidential transactions in which the amounts transacted are hidden.

Motivation

In NEO, all transactions are public, meaning that once an account is linked with an identity all its financials movements are eternally exposed, destroying any expectation of privacy. This conflicts with the requirements of several systems and financial instruments, making it impossible to use the NEO blockchain for certain types of use-cases where privacy , especially forward privacy, is important.

The token system proposed in this NEP alleviates this problem by hiding the amounts of tokens being transacted so that, while it'll still be possible to know when a transaction took place and who were the parties involved in it, it won't be possible to know how many tokens have been sent, making the balances of all the accounts in the system private.

Specification

Overview

This standard is based on an UTXO model for token transactions, in which transaction validity is verified by proving that the sum of all inputs minus all outputs is positive (validity requirement).

What makes this token different from other UTXO-based tokens is the fact that all input and output amounts are encrypted, as well as the sum of these, which is calculated using homomorphic encryption and checked against the validity requirement via a range proof. Also, a range proof needs to be provided for each of the outputs to prove that none of them are negative numbers.

The union of homomorphic encryption with range proofs allows anyone to verify the validity of the transactions without revealing at any point what are the amounts being transacted, therefore achieving confidentiality.

Methods

totalSupply, name, symbol and decimals are inherited from NEP-5.

transfer

public static bool transfer(byte[] proof)

Transfers an amount of tokens from the from account to the to account.

The parameters from and to SHOULD be 20-byte addresses. If not, this method SHOULD throw an exception.

Returns true if the proof verifies the validity requirement and false if it does not.

getTransactions

public static byte[] getTransactions(byte[] account)

Returns all the transactions in which account has taken part of.

The parameter account SHOULD be a 20-byte address. If not, this method SHOULD throw an exception.

Rationale

Explanations of the design decisions as well as the proofs of the privacy guarantees of this system can be found in the AZTEC whitepaper.

Backwards Compatibility

This NEP only introduces a new type of token and therefore does not break compatibility with previous versions.

Acknowledgements

This NEP is based on the AZTEC Protocol, without which it wouldn't be possible.

Implementation

To be done.

[steven1227]

This is a very interesting NEP and quite useful in certain areas. BTW, is there an event specified for this kind of token transfer? For instance:

public static event transfer(byte[] proof)

[corollari]

@steven1227 Great idea! I've just added that event as part of the spec.

[steven1227]

@corollari And for the zero-knowledge proof, why only possible with AZTEC Protocol? It depends on how we build this model. I believe zk-SNARK or some other protocol such as Bulletproofs are also working for this.

[corollari]

@steven1227 I only mentioned AZTEC protocol in the NEP to provide proper attribution for some of the ideas I used, any system that can be used to generate the proofs needed in this NEP could be used. You're right in that it would probably be better to use some other system, such as the ones that you mentioned, instead of the AZTEC protocol because these other systems are better understood, have received better security reviews and have more and better implementations available.

[gsmachado]

@corollari interesting proposal... and I fully support it. 😄
However, it's not yet clear to me how complex the implementation will be (higher complexity, higher the risk). I think an evaluation of other protocols should be done first.

[vncoelho]

@corollari, perhaps we may need the GAS to be anonymous as well, as discussed here neo-project/neo#1271

[roman-khimov]

I propose dropping it as obsolete and unmaintained. We need some active project doing this, otherwise it's an unused (and maybe unusable) abstraction.