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:
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!
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:
- 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.
- 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.
We will first describe a simplified version of the protocol, following two imaginary participants
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:
- Send and Receive
- Shared Secrets
- Encrypt and Decrypt
- Ownership Certificates
- 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
Ledgerthe 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
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:
Alice begins by constructing a special number called , the ephemeral secret key, which she will use to represent this unique transfer. She constructs it by taking
Bob's pubic key, , some public data from the
Ledger, and some randomness:
This is built using a commitment scheme which commits to (the ledger checkpoint), and using as the randomness (A.K.A blinder, or trapdoor):
This ephemeral key is only used once.
Alice will have to prove later that she constructed 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 gives us the hiding property which means that even if someone knows and they won't be able to predict what is without knowing .
Alice now uses the ephemeral key, , her own secret key , 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.
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 to scan through the private assets to find the ones he now owns.
The secret key that
Bob is using for this scanning process must be the one that derived the public key 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 is just from the knowledge of .
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.
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 , and a public constant that everyone agrees on. We choose and so that it has the following property:
Let's call and secret keys and call and public keys. Since is irreversible, we can leave and out in the open for anyone to see, or even if we want to be discrete we can still send or 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 function has the property above, we actually have our shared secret:
So if you share your public key with someone and get their public key , then you both can compute the shared secret, . In the rest of the protocol,
Bob will share several secrets on their way to performing a successful transfer.
Encrypt and Decrypt
The first place that
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
Bob. This is called the in-band secret distribution.
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 and the ephemeral secret key for this particular transaction and performing a Diffie-Hellman Key Exchange (in this case using elliptic curves to define the function), to compute a shared encryption key .
Alice then uses the Blake2s key derivation function to produce another key which will be the right size for the standard AES-GCM encryption scheme with message authentication.
Alice encrypts the asset with and appends the derived public ephemeral key to the ciphertext message. This forms part of the private asset that
Alice sends to the
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.
In this case,
Bob uses his secret key, , and the public ephemeral key attached to the private asset, , to build the Diffie-Hellman shared secret, , then using the same Blake2s function to derive , and then performing AES-GCM decryption. The decryption will check that the message authentication can be reconstructed properly and if the key 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.
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
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:
- Prove that
Aliceowns one of the current UTXOs
Alice's UTXO from the
- Create a new UTXO for
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 which represents that
Alice was a receiver in a past transaction. She will need to prove that the
Ledger has seen this UTXO before.
To transfer the asset to
Alice generates a new UTXO, called , on
Alice will also need to revoke her old UTXO somehow. She does this by generating a void number, , which is tied to her in such a way that:
- The same will always generate the same .
- Different generate different .
- No one can tell which the belongs to.
Alicecan construct .
Let's see how and are constructed.
In order for
Alice to create on
Bob's behalf, she computes another shared secret, called , the trapdoor, to the UTXO commitment .
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.
Alice to generate her void number certificate, she takes the trapdoor, that was used to build her , and commits to her secret key .
The void number is tied to the commitment because it uses the same trapdoor, and only
Alice can perform this computation because is only known to her.
In order to prove that her UTXO is already on the
Alice can create a Merkle-Proof, , attesting to this fact.
Zero-Knowledge Transfer Proof
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:
Ledgeragree 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.
Aliceperforms the computation of that algorithm on her own machine with her own chosen secret input and public input.
- Using the output of the computation,
Alicebuilds a proof that the computation was done correctly (because of succinctness, this is a very small file compared to the size of the algorithm)
Alicesends to the
Ledgerand 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.
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:
- Private Sender: Because and are secret, the
Ledgerwon't know which UTXO belongs to
Alice, just that it is in fact one of the ones stored on the
- Private Receiver: Because the construction of is secret, no one knows that it comes from .
- Private Asset: Because , , and the asset amount are secret, no one can decrypt the encrypted asset except
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
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 -to- 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 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!