One of the major problems facing Bitcoin at present is that addresses aren’t anonymous. They are rather “pseudonymous”, which means that although the linkage between an address and its owner isn’t necessarily known, all payments made to and from a given address are listed in the public domain and are easily trackable. Bitcoin analytics software employs sophisticated heuristics that in many cases allow for the owners of addresses to be identified.
This lack of anonymity poses an existential threat to Bitcoin in the long run. One of Bitcoin’s core values is censorship resistance. If it’s possible for financial institutions to easily track users by pseudonymous addresses, it will be possible to censor users by blacklisting a set of known addresses. Even more dangerously, Bitcoin could fail to serve everyday privacy needs. Existing forms of transactions such as cash, credit cards, or wire transfers don’t broadcast transactions to the world at broad and are arguably more private than Bitcoin on the whole.
Some infrastructure does exist to improve this state of affairs. Notably, Bitcoin mixers such as CoinJoin allow for users to mix funds among a set of known addresses. The limitation of mixers is that they don’t provide total security; they mix funds among a known set of participants (at most something like a 100 participants). Also, even using a mixer can put an address under scrutiny, so it may well be more dangerous to use a mixer than not on average.
There are a number of projects attempting to build cryptocurrencies with improved privacy, but ZCash is one of the most intriguing. The origins of the ZCash project grew out of an earlier academic paper called Zerocash. The core idea behind this paper is to use a type of zero-knowledge proof (the “zk-SNARK”) to prove that a particular signature signs for a valid piece of money (a UTXO to use the Bitcoin terminology). Anonymity results because the zero-knowledge proof does not allow a third party to distinguish this coin from all other coins currently recorded on the public ledger. For efficiency, the set of current coins is stored as a Merkle tree. Each coin consists of a serial number and a zk-Proof proving that the given coin is a leaf node in the ledger Merkle tree. This scheme has the limitation though that serial numbers are fixed and can be tracked over time. In order to overcome this limitation, the recipient of a payment has to immediately mint a new coin which is under her direct control. These anonymous coins are themselves backed by an existing crypto currency like Bitcoin, so the Zerocash protocol constitutes an anonymous “sidechain” of a sort as opposed to a fully independent blockchain.
The full Zerocash scheme avoids the need to immediately re-mint coins for privacy by the introduction of a “pour” operation. This operation works more-or-less like a Bitcoin transaction, which takes in existing UTXOs and produces new UTXOs , but with the addition of a zk-SNARK that proves that the pour was well formulated. This essentially “cuts” the chain between the new coins and the original coins, which allows for anonymity to be restored. The “pour transaction” that is appended onto the ledger is essentially the zk-SNARK plus some metadata, none of which reveals the values of the coins involved in the transaction nor the owners. However, it’s important to note that the zk-SNARK can be rather sizeable, so considerable engineering effort has been needed to reduce the size of the zk-SNARKs to the point where the ledger doesn’t become unbearably large. Much of the technical substance of the Zerocash paper is targeted at making sure the zk-SNARK stays size-limited. The system produced in the paper requires a few minutes to generate a new zk-SNARK proof and a few milliseconds to verify it. Some additional technical transformations are also needed to render the overall system secure on top of this base scheme. The Zerocash paper performs some heavy-duty experimental analysis by running a 1000 node test-network on 200 AWS machines (each running 5 copies of modified bitcoind) to verify that the overhead introduced by the protocol is tolerable.
The zk-SNARK system introduced in this paper notably requires a one-time trusted setup. More recent works introduce zk-SNARKs which no longer have this trusted setup scheme, but these systems have not yet matured to the point where they can be deployed in production systems. zk-SNARK based systems with trusted setup even still have considerable maturing to undergo. The ZCash team recently discovered a critical bug in their zk-SNARK system that would have allowed for counterfeiting of new coins. In general, creating a bug-free currency based on zero-knowledge systems appears considerably challenging even today.