Privacy in blockchains has been a concern since the early days of Bitcoin, going as far back as the original Nakamoto paper. The original paper makes very limited claims about privacy: while identities are not explicitly linked to transactions, transactions themselves can be linked to one another. A simple rule of thumb is to assume that if two or more inputs are used in a transaction, they belong to the same user. While not always true, this simple heuristic is surprisingly powerful. Other ways to establish links include user behavior, wallet-induced characteristics and even IP data. While well known in academic and enthusiast cycles, these techniques were not always widely understood, and many (mistakenly) believed that Bitcoin provided a higher level of privacy than what was actually provided.
A simple way to counteract many heuristics is to simply merge transactions: instead of X paying Y and Z, and (in a separate transaction) A paying B and C, a merged transaction has X and A paying Y, Z, B and C. This creates ambiguity with regards to who’s paying whom, and also between different change addresses. Even so, exact sums may still reveal who is doing what: in an extreme example, assume a merged transaction has 2 inputs of value 100 and 10, and 4 outputs of value 80, 20, 7 and 3. In this trivial example, merging accomplishes little.
With a tighter limit on the range of inputs and a high number of users, transaction merging and mixing can be useful. Early solutions involved ad-hoc mixing facilitated by a trusted party, while later constructions such as coinjoin enabled a decentralized and more secure approach. The main downside in such solutions is the need to coordinate with others. This makes transaction creation an involved process and often requires a semi-trusted third party to facilitate coordination. As opposed to early solutions, the coordinator is unable to steal funds.
A newer generation of cryptocurrencies starting with the Cryptonote design used by Monero uses a cryptographic tool to achieve privacy without requiring user to user interaction or a trusted coordinator. The tool, ring signatures, enables a user to sign in a way that does not link back to just themselves but to a set of users, called a ring. As such, a transaction could have originated from any member of the ring. Users do not need to ask permission to add others to a ring, but at the same time are unable to spend others’ funds or double-spend their own. The last property is achieved by adding linkability to ring signatures: signing for the same set of funds more than once will cause a check value to be repeated (i.e., each duplicate signing will be linked to each other) and the transaction to be rejected.
Early designs of ring signatures struggled with efficiency issues: they had signature size directly proportional to the ring size, creating an uncomfortable tension between privacy and efficiency. While eventually more efficient constructions were brought to bear, others explored a more radical option.
Using complex cryptographic protocols built on top of a trusted setup, we are able to produce succinct proofs that some fact is true without the need to reveal details (benefiting both privacy and efficiency at the same time). These so-called “Succinct Non-Interactive Arguments of Knowledge” (SNARKS) are the driving force of Zerocash (implemented as ZCash). While in ring signatures the issuer of each transaction needs to establish a (small) ring of users to hide amongst, Zerocash effectively sets the ring to always be the set of all previous transactions. This maximizes privacy while at the same time the efficiency of SNARKS keeps the size and verification cost of such transactions in check. Furthermore, the design can also keep transaction values confidential, as the computational cost of handling hidden values can be ‘folded’ into the SNARK.
Harmonizing privacy, efficiency, and Proof of Stake
But what about Harmony? Being one of the few blockchains that combine proof of stake with the account model, solutions that were built with Bitcoin in mind require reworking. At the same time, falling back to centralized solutions that condition privacy on trusted parties would be less than ideal.
So then, does Harmony support solutions that are as simple as a small ring signature or as complex as a SNARK-based proof system? The answer (to both questions) is yes. Harmony provides an EVM-compatible smart contract environment that can host a number of privacy solutions such as Tornado Cash, Zether, Möbius and more. Even better, the low fees of Harmony enable developing a wide range of solutions, giving more freedom to developers as well as researchers. At the same time, this does not mean that there is no scope for improvements: ease of use and user education remain important, as is the ability to privately invoke contract execution.
This short article summarizes a recent privacy report conducted by Common Prefix on behalf of Harmony. Feel free to peruse the full report for more information on the topics discussed.