Making Secure Private Transactions On Public Ethereum Blockchain
By: Rachid Moulakhnif
Tags: Ethereum Blockchain, Blockchain Technology, Ethereum, Blockchain, Zksnark

What is NightFall? How does it work? Why is it needed?

All these questions will be answered here, hope you enjoy reading!

You might have heard of NightFall, the new protocol that allows making private token transactions, it employs zero-knowledge proofs to let corporate EY clients build on the Ethereum public chain while retaining privacy, security, reliability, and regulatory compliance.

NightFall is an open source tool designed by EY( one of the biggest consulting companies in the world ) that was released into the public domain in May 2019.

The idea behind NightFall is simple even if the math is hard: instead of showing the actual information, you simply show the mathematical proof that you did something instead. Other parties on the blockchain cannot determine from that who passed what information to whom, but they can use the proof to verify the truthfulness of the statement, this concept is not new indeed a payment blockchain like ZCASH has been around for more than 3 years.

It’s important to note that at the moment NightFall is compatible with ERC-20 and ERC-721 token standards because of the prevalence in the Ethereum Community, in the future, it could indeed support new token standards.

EY releases ZK-SNARKS for Ethereum

What’s the problem that needs to be solved?

At the moment, it’s not possible to make private and secure token transactions in Ethereum because by design it’s a public distributed ledger where everyone can see your transactions, know who you are transacting with and for businesses, it’s a crucial point to hide financial data.

Let’s look at this example:

Don’t be scared if you don’t know Solidity, this function basically takes 2 inputs: the address of the recipient and the amount of the tokens to send.

The problem is that this transfer function requires the recipient, and amount values to be publicly inputted into the calculation.

For a transfer to be considered private we need those inputs to be kept private from the Blockchain, this is a difficult task to achieve because any values used within a calculation must be made public in order for the nodes to agree in the consensus process.

But, how does it work?

Well, I said that by using ZK-SNARKS, it’s possible to hide the address of the recipient and the amount that you wish to send.

The sender also called Prover runs a small computation on their own computer which passes private inputs into the computation and gets a set of public outputs which will be shared with the blockchain which are unreadable encrypted values to the other users of the network meanwhile only the sender and recipient will be able to decrypt those values.

How do we know that the computation was done correctly?

Simply, for these encrypted values to have ‘meaning’ to the other participants of the network the Prover also shows to the blockchain a ‘Proof’ stating that it has correctly done the computation.

Before going to the next paragraph, you should know the difference between Non-fungible token and Fungible tokens.

If you don’t know the difference then I recommend you to read this post:

Getting more in-depth

As you may know, there are different types of token standards like the ERC-20, ERC-721, and ERC — 223 and what they all have in common are a set of standard of functions that an Ethereum token contract has to implement. We will cover the ERC20 and ERC721 implementations.

ERC-721 (non-fungible) tokens

The functions that we are going to talk about are:

Mint: Creates an initial “ token commitment ” which basically creates a private representation of a public ERC-721 token( Note: we don’t achieve privacy in this step yet)

Creates an initial “ ” which basically creates a private representation of a public ERC-721 token( Note: we don’t achieve privacy in this step yet) Transfer: wipes out the sender’s token commitment and generates a new token commitment to represent ownership by the recipient

wipes out the sender’s and generates a new token commitment to represent ownership by the recipient Burn: nullifies a token commitment and lets you receive the underlying public ERC-721 token

Mint

For this example, we will have a scenario where Alice( the sender )and Bob( the recipient ) want to transfer the ownership of an ERC-721 under zero-knowledge which will make the following become private:

All the details of the ERC-721 which is the asset

The identity of the sender of the token (Alice)

The identity of the recipient (Bob)

There are some variables that need to be understood and that will be used in order to have a better understanding:

Z: An ERC-721 commitment; a zero-knowledge commitment representing ownership of some underlying ERC-721 asset

α: A unique representation of some non-fungible asset e.g. a tokenId in ERC-721.

pkA: The public key belonging to Alice.

skA: The secret key belonging to Alice

Warning: this step doesn’t grant privacy yet, minting an ERC-721 commitment requires Alice to send the tokens to a ‘Shield’ contract which holds it as an escrow. This transfer reveals the Ethereum address of the sender and also the property of the token, therefore, everyone will know who the sender is and the asset held by Alice.

In this section, Alice can create an ‘ERC-721 commitment’ within the Shield contract which:

hides an underlying ERC-721 token with tokenId ‘α’; and

hides and binds Alice as the owner of Zα (and hence of α) through an ownership keypair (skZ Alice, pkZ Alice)

Transfer

As mentioned above the MINT function doesn’t grant privacy yet, in order to transfer the ownership of the tokenId under zero-knowledge only with subsequent transfers will the whereabouts of α and the owner of α be hidden.

In this section, Alice is able to send the ERC-721 private token commitment created to Bob, the computer will run a small computation ensuring that Alice’s proof and public inputs represent her commitment.

Once Alice has been verified then Alice will be able to transfer the ownership of a token commitment via the newly proposed commitment.

Once Bob has received the token commitment, he will be able to send the tokens to numerous parties(using zero-knowledge under the hood) if he wants to or he can Burn the tokens and redeem them in the public chain.

Burn

Now that Bob has successfully received the token commitment from Alice he is now able to transfer the asset α between parties within the Shield contract indefinitely. Any third-party observers would not be able to infer ”who sent what to whom”.

If you remember the original tokens are held in escrow by the Shield contract while Bob only has the private token commitment, so how does Bob get the original ERC-721 token?

If Bob wishes to get his public ERC721 token represented by α from escrow, then he will need to effectively ‘reveal’ the contents of his token commitment in order to convince the Shield contract that he is indeed entitled to withdraw α from escrow.

Note: when a token commitment gets burned, Bob will reveal information that previously was private namely the tokenId and the sender( Alice ) as he will receive the ERC-721 tokens in the public chain.

ERC20 (fungible) Tokens

The process is similar to the one used for the ERC-721 private transfers explained above.

The functions are the same as the ones used for NFTs( ERC-721 tokens ) but there are some relevant changes:

mint: Creates an initial “ token commitment ” which basically creates a private representation of a public ERC-20 token( Note: we don’t achieve privacy in this step yet).

Creates an initial “ ” which basically creates a private representation of a public ERC-20 token( Note: we don’t achieve privacy in this step yet). Transfer: wipes out the sender’s token commitment and generates a new token commitment to represent ownership by the recipient.

wipes out the sender’s and generates a new token commitment to represent ownership by the recipient. Burn: nullifies a token commitment and lets you receive the underlying public ERC-20 token.

In the next example I will be using this variable to simplify things:

f: is the ERC-20 token that will be transacted privately using the shield contract

Mint

For this example, we will have a scenario where Alice( the sender )and Bob( the recipient ) want to transfer the ownership of an ERC-20 token under zero-knowledge which will make the following become private:

The value that Alice wants to send

The identity of the sender of the token (Alice)

The identity of the recipient (Bob)

Warning: this step doesn’t grant privacy yet, minting an ERC-20 commitment requires Alice to send the tokens to a ‘Shield’ contract which holds it as an escrow. This transfer reveals the Ethereum address of the sender and also the value of the tokens sent, therefore, everyone will know who the sender is and the asset held by Alice.

In this section, Alice can create an ‘ERC-721 commitment’ within the Shield contract which:

hides an underlying value f, denominated in the currency of a particular ERC-20 contract

hides and binds Alice as the owner of f through an ownership keypair (skZ Alice, pkZ Alice).

Transfer

Assuming that Alice wants to transfer a value f to Bob under zero-knowledge, she must ensure that she has minted enough private token commitments which represent a value of at least f.

Note: for a transfer of fungible commitments, NightFall requires 2 input commitments and 2 output commitments because:

Having just one output would mean the sender would have to own a set of commitments which sum to exactly the amount required by the recipient (no more, no less). This is impractical for most use cases.

Having only one output increases the risk than an observer gathers information from the analysis of the transaction

Burn

Now that Bob has successfully received the token commitment from Alice which represents a value of f (denominated in the currency of a particular ERC-20 token).

While the token commitment exists within the Shield contract, this contract holds an equivalent of value f public ERC-20 tokens locked up in escrow.

If Bob wishes to get his public ERC721 token represented by α from escrow, then he will need to effectively ‘reveal’ the contents of his token commitment in order to convince the Shield contract that he is indeed entitled to withdraw α from escrow.

Suppose Bob wants to release a value f of ERC-20 tokens from escrow. Then he will need to effectively ‘reveal’ the contents of his token commitment to convince the Shield contract that he is entitled to withdraw f from escrow.

Note: that by burning a token commitment, Bob is revealing information which was previously private; namely, the value f.

I didn’t dive deep into the math as the concept under the hood requires a good understanding of math, Merkle roots, ZK-SNARKS, and the deep explanation can be found in the Whitepaper published by EY which has a brilliant explanation.

do your research

If you’ve found this post helpful, please leave a Clap( this would be much appreciated ) and start following as I will publish more useful and interesting content in the future.

Hope you are smarter and you learned new things!

See you soon!