Skip to content
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

NEP: Confidential Token Standard #106

Open
wants to merge 2 commits into
base: master
from

Conversation

@corollari
Copy link
Contributor

corollari commented Nov 8, 2019

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 comment has been minimized.

Copy link

steven1227 commented Dec 25, 2019

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

This comment has been minimized.

Copy link
Contributor Author

corollari commented Dec 27, 2019

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

@steven1227

This comment has been minimized.

Copy link

steven1227 commented Dec 28, 2019

@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

This comment has been minimized.

Copy link
Contributor Author

corollari commented Dec 29, 2019

@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

This comment has been minimized.

Copy link

gsmachado commented Jan 2, 2020

@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

This comment has been minimized.

Copy link
Member

vncoelho commented Jan 3, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants
You can’t perform that action at this time.