The original idea of blockchain defended total openness of the its transactions. This would enable any member of the network to verify every transaction and police the community. But privacy is about more than just ethical behaviour, and there are valid reasons to keep your secrets even if you have done nothing wrong. For this reason, there is a need for privacy in crypto-currencies. But how can we keep the security of decentralized networks and still have privacy in blockchains?
The Bitcoin Ideal
The blockchain ideal states that money-transactions should be public, but in reality real-world users prefer their history to be private. How can we have privacy in blockchains, and have both their security and the privacy users desire?
Bitcoin, the original blockchain, gave us more than the idea and the technology of crypto-currency. It set also the properties we should expect from a digital money-replacement: it should be anonymous, decentralized, fast, cheap and … public. By the last I mean that everyone should be able to see the history of transactions of an account, to enforce a kind of mob-surveillance in which every user ultimately polices what other users do. But do we really want this?
Bitcoin has attracted a very diverse group of people, among whom some early proponents had hopes the current money system would collapse and Bitcoin would emerge as a fairer alternative. But this is, in the end, a quite dystopian view, that would bring with it profound social changes and farther reaching consequences than we can imagine.
Not everyone engaged and excited with the technological achievements of Bitcoin shares the view that the original ideal is pure good, though, and people have an instinctive aversion to their financial history being exposed in public. Stories of bitcoin millionaires being harassed for their money and having suddenly to take on personal security measures don’t help either.
Do we really want public transactions?
The publicness of transactions was built in as a way to give security to the blockchain. This is how every member of the network can verify transactions are legitimate and prevent fraudsters from creating false money, or stealing funds from other accounts. So, in a sense, this thy transaction list shalt be public commandment may not be a fundamental choice at all, but rather a technological solution that could be politically argued for. This opened the way for several blockchains to carve their niche away from bitcoin by precisely offering private transactions, that is, offering security without requiring transparency in exchange.
There are several technologies being explored at the moment, including ring–signatures (Monero), Mimblewimble (Grin, Beam), Bulletproofs and, most recently, an Ethereum smart contract that enables confidentiality (Zether). But the one I have been studying more intensely is, as you’ll know if you’ve been reading my blog, Zero-Knowledge SNARKs.
Zero-Knowledge Proofs
The notion of Zero-Knowledge proof is not at all obvious, and it can be quite surprising that we can actually do them. I have given an introduction to the concept here, so let me just give a brief primer in this section. A Zero-Knowledge Proof is a mathematical construction that enables a Prover (let’s call her Peggy) to demonstrate to a verifier (Victor) that she knows a secret without ever revealing that secret.
For example, Peggy knows the combination to the office’s safe, but she wants to convince Victor of that fact without outright revealing the secret. A Zero-Knowledge Proof enables Peggy to demonstrate that knowledge in such a way that Victor does not learn anything (not even a single bit) about the secret.
What can we prove in Zero Knowledge?
There has to be something about the secret that is publicly verifiable, that is, some property Victor would know the secret has but that does not say anything about what it is. In the case of the safe, that would be simply that the key can actually open the safe: simply seeing Peggy open the safe would convince Victor of Peggy’s knowledge. This would have to be engineered in such way that Victor would not be able to see Peggy entering the key, what keys she pressed nor how many of them.
The above scenario is just an example of why you might want to prove something in Zero-Knowledge, but it is very low-tech. In the blockchain reality, we need to make proofs about digital objects and concepts. We can’t just prove anything in Zero-Knowledge, there is a well-defined class of statements that are amenable to these techniques. In formal terms, these are all the languages that belong in the NP class of decision problems in Computational Complexity. Zero Knowledge is enough for one post, I will cover NP problems in another one later.
Private Blockchain From Zero Knowledge Proofs
Now comes the interesting part. We can use Zero Knowledge Proofs to hide vital information from a smart contract. Smart contracts in Ethereum are very public: everything that goes in and comes out of the smart contract, indeed every step of the computation, can be seen by anyone. But depending on our use case, maybe we don’t always need to reveal everything. Privacy is easier to explain for blockchains that are essentially ledgers, made up of several accounts with a balance of something. This covers bitcoin, of course, but also ZCash and Ripple for example. Other use cases include property ledgers or possibly blockchains holding gaming data: characters and their possessions.
In such blockchains, a transaction will mostly be a transfer of ownership of some amount of a token (be it a unique object or a currency amount) from one account to another. There is an obvious rule that must be satisfied: the total balance of the system must remain constant or decrease by a predictable amount, if fees, taxes or commissions are charged and not kept in the system. This balance evolves by states, and the invariant property is that two consecutive states must be the same or differ by a certain well-known amount.
Moreover, we don’t need to recompute the balance by summarizing the whole system at each moment: we only need to prove that the changes in the accounts involved in a transaction cancel out, which is much more efficient. Our invariant, then, is computed over the total balance of these accounts.
A Toy Example
For example, if we want to keep secret the balance of all accounts and the amount sent in each transaction, we can store in the blockchain a pair containing the account and the hash of the account’s balance. In each transaction between two accounts, we instead send to the blockchain the new states of both accounts, which means their new hashes, together with a Zero Knowledge proof that the difference between the accounts’ balances in both states is symmetric. Formally,
---------------------
Variable definitions:
---------------------
s0[A] --> initial balance of account A s1[A] --> final balance of account A s0[B] --> initial balance of account B s1[B] --> final balance of account B ------------
Proof parts: ------------
Public input: hA0 = hash(s0[A]) hA1 = hash(s1[A]) hB0 = hash(s0[B]) hB1 = hash(s1[B]) Secret Witness: wA0 = s0[A] wA1 = s1[A] wB0 = s0[B] wB1 = s1[B] Verification --- check all of these are true: hash(wA0) == hA0 hash(wA1) == hA1 hash(wB0) == hB0 hash(wB1) == hB1 wA0 + wB0 == wA1 + wB1
If you want to see a real world implementation, check ZCash. They support private transactions that give more guarantees than this simple scheme, and require more machinery. The above is merely a toy example, to explain how Zero Knowledge could be used, but is not compatible with the ZCash model.
What ZK-SNARKs Give Us In Practice
If you look carefully at the above discussion, I didn’t make use of the word Snark. All I talked about was Zero-Knowledge Proofs. You may be wondering how ZK-SNARKs fit in this picture and why we use them and not just any form of Zero Knowledge Proof.
Non-Interactivity
There are a few things. First of all, although a bit obvious by now, a ZK SNARK is a form of Zero Knowledge Proof. What makes them ideal is that they are non-interactive proofs. This means that Peggy and Victor don’t need to interact in a dialogue for the protocol to work.
We lose something by this. We can no longer guarantee the freshness of the proof, that is, the Victor can not be sure the proof was created just at the moment of verification, nor can he be truly sure it was created by Peggy. In fact, it might have been given by the creator to another party who transferred it yet a further few hops along before reaching Victor. He can only be sure that the original proof creator knew the secret, but should not assume the same about any relay.
On the other hand, this gives us the freedom that anyone can check such a proof without having to set a new interaction. Therefore, it is possible for every party in a network to verify a transaction and thereby achieve decentralization by trust in numbers. We do not depend on a single authority to verify correctness.
Succinctness
The other important property of ZK-SNARKs is that they are succinct. The proof and the verification key are both small, which makes verification fast and therefore possible to be carried out on chain. This enables smart contracts to efficiently make use of ZK-SNARKs to verify the correctness of transactions on secret data, although in general proofs will have to be constructed off-chain for a number of reasons: need for true randomness, size of proving key and the possible complexity of encoding the witness.
ZK-SNARKs are an amazing technology that can give privacy to blockchains. I hope this post has helped you understand how they can do that. If you like what I write, don’t forget to hit the like button below and share this post in your networks. You may subscribe to my blog to get mail updates whenever I write something new. Let me know your thoughts, I will be happy to read them and answer back.
Have a good day, happy coding or researching. See you next time.