Skip to main content

How Does Private Payment Work?

Manta is all about bringing privacy to the wider blockchain space, and an important part of making privacy practical to use is the construction of simple and powerful privacy primitives. The first and most powerful primitive we are building is Private Payment, more specifcally, a multi-asset decentralized anonymous payment protocol.

How Does It Work?​

We recently posted a tech talk that explains the protocol in some detail:

Tech Talk #1

You can follow along with this video, download the slides, and/or keep reading below to get an overview and some technical details about how Private Payment works.

Currently, the formal specification for Private Payment is still closed source, but stay tuned for its public release in the near future!

Public Ledgers​

Most decentralized systems of digital money use what are called public ledgers to keep track of the flow of money. Public ledgers store the current state of every participant's balances, and whenever someone tries to spend from their account, the blockchain will come to consensus on whether this transaction is valid and updates the state. However, to validate a transaction the public ledger needs to know which sender and receiver are participating, and what amount is being transfered. We would like to find a way to avoid this and preserve the privacy of all parties involved in transactions and keep amounts private as well.

Properties of a Decentralized Anonymous Payment Protocol​

When designing a private ledger, we want the following two properties to hold:

  1. A transaction cannot modify the total supply of an asset. Only the ownership, the exclusive right to spend the asset in the future, can change.
  2. Reading the ledger cannot reveal any information about a transaction or existing user balances

These two properties seem to be at odds with each other since we want to verify that the total supply remains fixed but we must do so without learning what the underlying transaction is!

Fortunately, some new cryptographic protocols can save the day, namely zkSNARKs, zero-knowledge Succinct Non-interactive ARguments of Knowledge. We will see later which role they play in privatizing the payment protocol.

Overview​

We will first describe a simplified version of the protocol, following two imaginary participants Alice and Bob, and we want to find a way to have Alice send an asset to Bob using a private Ledger. We will describe the protocol in the following steps:

  1. Send and Receive
  2. Shared Secrets
  3. Encrypt and Decrypt
  4. Ownership Certificates
  5. Zero-Knowledge Transfer Proof

This discussion is not entirely self-contained but we will attempt to explain cryptographic protocols only as black boxes by their interfaces and security guarantees. Further reading on each of the subjects below is encouraged.

Participants (in detail)​

  • Alice (sender): a participant that already has access to some assets and is guaranteed by the Ledger the ability to spen them.
  • Bob (receiver): a participant that can be uniquely identified by other senders and will be guaranteed the ability to spend received assets in the future.
  • Ledger: represents all public information (the state) and the network of validators (blockchain) which come to consensus on the private transfer of ownership of assets between senders and receivers.

Send and Receive​

For Alice to send her assets to Bob, she communicates with the Ledger as an intermediary. The Ledger operates asynchronously and is distributed across the internet, and so, many computers can access the Ledger and send and receive messages to and from the network. Alice will send a transfer message to the Ledger and if accepted, it will be used to update the state of the Ledger, and the changes are propagated to all of the network. Bob will query the network, asking for new updates to the state. If there is a new Ledger state, he will download it and analyze it to see if he has received any new assets. Here are those two protocols in detail:

Send​

Alice begins by constructing a special number called SKE\textsf{SK}_\textsf{E}, the ephemeral secret key, which she will use to represent this unique transfer. She constructs it by taking Bob's pubic key, PKB\textsf{PK}_\textsf{B}, some public data from the Ledger, and some randomness:

Send Protocol

This is built using a commitment scheme which commits to Ξ›\Lambda (the ledger checkpoint), and PKB\textsf{PK}_\textsf{B} using Ο„\tau as the randomness (A.K.A blinder, or trapdoor):

SKE:=COM(Ξ›βˆ£βˆ£PKB,Ο„)\textsf{SK}_\textsf{E} := \textsf{COM}(\Lambda || \textsf{PK}_\textsf{B}, \tau)

This ephemeral key is only used once. Alice will have to prove later that she constructed SKE\textsf{SK}_\textsf{E} properly, called opening the commitment. The commitment is binding which means that Alice will not be able to change her mind and find another public key or ledger checkpoint to construct the same ephemeral key. The trapdoor Ο„\tau gives us the hiding property which means that even if someone knows Ξ›\Lambda and PKB\textsf{PK}_\textsf{B} they won't be able to predict what SKE\textsf{SK}_\textsf{E} is without knowing Ο„\tau.

Alice now uses the ephemeral key, SKE\textsf{SK}_\textsf{E}, her own secret key SKA\textsf{SK}_\textsf{A}, and the asset that she received from the Ledger earlier, to build a private asset. We will see as we go along how exactly the private asset is built.

Receive​

Once Alice finishes her communication with the Ledger and the Ledger accepts her private asset, it will store that private asset forever, waiting for someone to claim it. Bob wishes to claim it, so he goes to the Ledger and asks for all of the newest private assets since his last query. The Ledger will send them to Bob and he will use his secret key SKB\textsf{SK}_\textsf{B} to scan through the private assets to find the ones he now owns.

Receive Protocol

The secret key that Bob is using for this scanning process must be the one that derived the public key PKB\textsf{PK}_\textsf{B} which Alice used to build the private asset. This key derivation must be irreversible so that no one can discover (in a reasonable amount of time) what SKB\textsf{SK}_\textsf{B} is just from the knowledge of PKB\textsf{PK}_\textsf{B}.

NOTE: Because the Ledger will be around for a long time, Bob can wait as long as he likes to receive the new private assets.

Shared Secrets​

But how will Bob be able to claim is new assets? How will he be able to spend them in the future?

One of the most important cryptographic tools that we can take advantage of here is the shared secret. Essentially, we want to find a way to take some information and wrap it up so that only two people have access to it. Getting someone to share a secret with themselves is easy, they just don't tell anyone. But how do we tell someone else our secrets so that only the two of you ever know what it is?

One of the most common ways to do this is with the Diffie-Hellman Key Exchange protocol. In this protocol, we take an operation that we assume is impossible to reverse (in a reasonable amount of time), let's call it bind\textsf{bind}, and a public constant GG that everyone agrees on. We choose bind\textsf{bind} and GG so that it has the following property:

bind(y,bind(x,G))=bind(x,bind(y,G))\textsf{bind}(y, \textsf{bind}(x, G)) = \textsf{bind}(x, \textsf{bind}(y, G))

Let's call xx and yy secret keys and call X:=bind(x,G)X := \textsf{bind}(x, G) and Y:=bind(y,G)Y := \textsf{bind}(y, G) public keys. Since bind\textsf{bind} is irreversible, we can leave XX and YY out in the open for anyone to see, or even if we want to be discrete we can still send XX or YY to only a particular person, but we don't have to worry that someone can reverse engineer our keys if they get their hands on it.

Because the bind\textsf{bind} function has the property above, we actually have our shared secret:

S:=bind(y,X)=bind(x,Y)S := \textsf{bind}(y, X) = \textsf{bind}(x, Y)

So if you share your public key XX with someone and get their public key YY, then you both can compute the shared secret, SS. In the rest of the protocol, Alice and Bob will share several secrets on their way to performing a successful transfer.

Encrypt and Decrypt​

The first place that Alice and Bob use shared secrets is to share encryption keys. These keys are used to send the asset value that we want to transfer in a secret message from Alice to Bob. This is called the in-band secret distribution.

Encryption​

For Alice to send the asset value to Bob, she uses a hybrid public-key encryption scheme to encrypt the asset. She does this by taking Bob's public key PKB\textsf{PK}_\textsf{B} and the ephemeral secret key for this particular transaction SKE\textsf{SK}_\textsf{E} and performing a Diffie-Hellman Key Exchange (in this case using elliptic curves to define the bind\textsf{bind} function), to compute a shared encryption key KK.

Encryption (Full)

Alice then uses the Blake2s key derivation function to produce another key Kβˆ—K^* which will be the right size for the standard AES-GCM encryption scheme with message authentication. Alice encrypts the asset with Kβˆ—K^* and appends the derived public ephemeral key PKE\textsf{PK}_\textsf{E} to the ciphertext message. This forms part of the private asset that Alice sends to the Ledger.

Decryption​

Bob will then download the new private assets from the Ledger, and to see if any of the new assets are his to spend, he will try to decrypt them by building the same shared secrets Alice used for encryption.

Decryption (Full)

In this case, Bob uses his secret key, SKB\textsf{SK}_\textsf{B}, and the public ephemeral key attached to the private asset, PKE\textsf{PK}_\textsf{E}, to build the Diffie-Hellman shared secret, KK, then using the same Blake2s function to derive Kβˆ—K^*, and then performing AES-GCM decryption. The decryption will check that the message authentication can be reconstructed properly and if the key Kβˆ—K^* was different than the one used to build the message, it will fail, and Bob will know the asset is not his. If the encryption succeeded, then Bob will store the private asset on his local computer to spend later.

Ownership Certificates​

Now we know how Alice can communicate to Bob the amount of value she has sent to him. But still, the Ledger must only accept asset transfers which can provably transfer the future spending power from the sender to the receiver, all the while, preserving the privacy of all parties involved. Just because Alice sends Bob an encrypted asset does not mean she cannot send it again, or send it to someone else. We need a way to keep track of who owns what and be able to take away that power once someone spends an asset.

To satisfy this constraint, Alice will generate two kinds of certificates, UTXOs and void numbers.

A UTXO or Unspent Transation Output, is a certificate for the future spending of one of the receivers of a transaction. It is used in some public ledger protocols in the following way:

  1. Prove that Alice owns one of the current UTXOs
  2. Drop Alice's UTXO from the Ledger
  3. Create a new UTXO for Bob

In this way, the current set of UTXOs represents all of the users which have some amount of assets and how much they all own. For Alice to spend her asset, she needs to present a certificate CMA\textsf{CM}_\textsf{A} which represents that Alice was a receiver in a past transaction. She will need to prove that the Ledger has seen this UTXO before.

Ownership Certificates

To transfer the asset to Bob, Alice generates a new UTXO, called CMB\textsf{CM}_\textsf{B}, on Bob's behalf. Alice will also need to revoke her old UTXO somehow. She does this by generating a void number, VNA\textsf{VN}_\textsf{A}, which is tied to her CMA\textsf{CM}_\textsf{A} in such a way that:

  1. The same CMA\textsf{CM}_\textsf{A} will always generate the same VNA\textsf{VN}_\textsf{A}.
  2. Different CM\textsf{CM} generate different VN\textsf{VN}.
  3. No one can tell which CMA\textsf{CM}_\textsf{A} the VNA\textsf{VN}_\textsf{A} belongs to.
  4. Only Alice can construct VNA\textsf{VN}_\textsf{A}.

Let's see how CM\textsf{CM} and VN\textsf{VN} are constructed.

Receiver Certificates​

In order for Alice to create CMB\textsf{CM}_\textsf{B} on Bob's behalf, she computes another shared secret, called TB\textsf{T}_\textsf{B}, the trapdoor, to the UTXO commitment CMB\textsf{CM}_\textsf{B}.

Receiver UTXO

The commitment consists of the asset amount that Alice wants to transfer and the shared trapdoor. The trapdoor is the random part of the commitment that ensures the hiding property. The binding property of the commitment ensures that Alice can't put some fake information into the commitment and then Bob ends up with some assets he can't spend.

Sender Certificates​

For Alice to generate her void number certificate, she takes the trapdoor, TA\textsf{T}_\textsf{A} that was used to build her CMA\textsf{CM}_\textsf{A}, and commits to her secret key SKA\textsf{SK}_\textsf{A}.

Sender UTXO and Void Number

The void number VNA\textsf{VN}_\textsf{A} is tied to the commitment because it uses the same trapdoor, and only Alice can perform this computation because SKA\textsf{SK}_\textsf{A} is only known to her.

In order to prove that her UTXO is already on the Ledger, Alice can create a Merkle-Proof, Ο€A\pi_\textsf{A}, attesting to this fact.

Zero-Knowledge Transfer Proof​

But Alice has done all of these computations in secret, involving a lot of secret information which would compromise her account if she shared with anyone. How can the Ledger trust that she did this computation fairly?

Alice can take advantage of zkSNARKs, zero-knowledge Succinct Non-interactive Arguments of Knowledge to do the computation entirely on her own machine. zkSNARKs work like this:

  1. Alice and the Ledger agree in public on some algorithm to check (ex: some computer program to execute or the protocol above). They agree on which variables in the algorithm are secret and which are public.
  2. Alice performs the computation of that algorithm on her own machine with her own chosen secret input and public input.
  3. Using the output of the computation, Alice builds a proof Ο€\pi that the computation was done correctly (because of succinctness, this is a very small file compared to the size of the algorithm)
  4. Alice sends Ο€\pi to the Ledger and it can check quickly if the computation that produced this file was in-fact the agreed-upon algorithm in which case he accepts or rejects.

ZKP Details

Alice can use zkSNARKs to compute all the different objects in the Private Payment Protocol above. When she does this, she gains the following privacy guarantees:

  1. Private Sender: Because CMA\textsf{CM}_\textsf{A} and Ο€A\pi_\textsf{A} are secret, the Ledger won't know which UTXO belongs to Alice, just that it is in fact one of the ones stored on the Ledger.
  2. Private Receiver: Because the construction of SKE\textsf{SK}_\textsf{E} is secret, no one knows that it comes from PKB\textsf{PK}_\textsf{B}.
  3. Private Asset: Because SKE\textsf{SK}_\textsf{E}, PKB\textsf{PK}_\textsf{B}, and the asset amount are secret, no one can decrypt the encrypted asset except Bob.

So we have successfully built a Private Payment Protocol!

Generalized N-to-M Transfer Protocol​

In general, we need more than just a 1-to-1 transfer to be able to have usable money. For example, if Alice sends Bob five units and he wants to send Carol three units, he cannot use a 1-to-1 because he can't subdivide his assets. To do this, we generalize the above protocol to an NN-to-MM protocol.

Generalized Protocol

We can repeat the construction for each individual sender and receiver and so Bob can send his asset to Carol by sending three units to her and sending two back to himself. Because the entire protocol is private, no one except Bob knows that he has done this.

There's More​

There are some more details that you have to get right to build a real Private Payment scheme, like private wallets, fee proxies, and more. Right now these ideas are still brewing, but there's some cool stuff coming soon, so stay tuned!