Introduction
Privacy limitations in pseudonymous blockchains
With the release of the Bitcoin whitepaper in 2008, Satoshi Nakamoto demonstrated that value could be exchanged without the need of a trusted third party. For example, in the case of Bitcoin, every transaction that is recorded on the Bitcoin blockchain is permanent and publicly visible. Therefore, anyone can look at any transaction included in it. For instance, you could use a block explorer to look at the first transaction recorded on Bitcoin (see here, or in figure 1 below). This transaction happened more than ten years ago between Satoshi Nakamoto (the sender) and Hal Finney (the receiver) [1].
The sender and receiver of a bitcoin transaction are identified by their addresses (in blue in figure 1). Bitcoin and most other public blockchains are said to have weak anonymity (pseudonymity), as addresses do not reveal by themselves the identity of the user [2]. However, there are numerous ways in which you can link an address to the identity of a user (e.g. by looking at the entry or exit points). Thus, Bitcoin and many other cryptocurrencies are like “twitter for your bank account, it is a total privacy void” [3]. Several methods have been proposed to improve the privacy of blockchains. At the moment, the solutions relying on zero-knowledge proof of knowledge are the ones providing the strongest privacy features.
A primer to zero-knowledge proof of knowledge schemes
Since their introduction in the mid-eighties [4], several variations of zero-knowledge techniques came to life (see e.g. zk-SNARK1, zk-STARK2, zk-SHARK3). Only recent use cases allow those concepts to be implemented in practice [4]. Among them, Zcash pioneered the deployment of zk-SNARKs to blockchains. Zcash uses zk-SNARKs and offers the possibility to send either a transparent transaction (using t-addresses) or a shielded transaction (using z-addresses, as seen on fig. 2 below). As the name suggests, with a transparent transaction everything is publicly visible (like in the Bitcoin example discussed above). With a shielded transaction, the sender and receiver, the value exchanged, as well as the memo field of the transaction are encrypted and not publicly visible [5]. Thus, shielded transactions provide stronger privacy features.
1 zero-knowledge Succinct Non-interactive Argument of Knowledge 2 zero-knowledge Scalable Transparent Arguments of Knowledge 3 zero-knowledge Succinct Hybrid Arguments of Knowledge
Limitations of Zero-knowledge proof of knowledge schemes
Unfortunately, the presence of transparent transactions reveals information about shielded ones. For instance, as the total coin supply of Zcash is known as well as all the coins held on transparent addresses (which are said to be part of the transparent pool), you could easily calculate the total amount of coins held on shielded addresses (which are said to be part of the shielded pool4). In addition, even though shielded transactions provide strong privacy features, there is still information (e.g. transaction timing, IP address, etc.) that could be used to deanonymize a user. This in turn erodes the anonymity of others as it diminishes the global anonymity of the shielded pool [7]. The concept is similar to hiding a tree in the forest, the bigger the forest, the better. Therefore, the bigger the shielded pool, and the more frequent the transactions involving it, the bigger your chances of being well hidden. Unfortunately, in practice, not that many people use shielded transactions (as you can see here), which limits the anonymity set.
4 Sapling pool and Sprout pool (for completeness)
What is the Multi-Asset Shielded Pool?
The multi-asset shielded pool (MASP) is an open-source library written in Rust and can be integrated in any blockchain or platform that supports more than one type of asset (although even a single-asset chain could use the MASP). Like Zcash, the MASP allows its users to create shielded transactions if desired and this capacity can be extended to any other asset. Furthermore, as its name suggests, compatible assets can share the same shielded pool (increasing its size and the anonymity for every shielded transaction within this pool).
What is the Multi-Asset Shielded Pool for ?
By adopting the MASP, a blockchain would allow compatible asset types to share the same shielded pool. Every new or additional interaction with the shielded pool will increase the shielded pool’s overall anonymity set. This would provide stronger privacy guarantees to all the assets that are sharing the same pool. Moreover this can be particularly beneficial for assets with a very low trading volume (e.g. an NFT that represents real estate).
For instance, let us assume that a blockchain implements the MASP. From this blockchain, two compatible assets (i.e. using the same smart contract standard) will use the MASP and the same shielded pool to provide shielded transactions. Asset A has numerous users and many transactions per second. Conversely, asset B has few users and a substantially lower trading volume (e.g. 10 transactions a year). If project B has its own shielded pool, it might be possible for an external observer (thanks to transaction timing, etc.) to deanonymize transactions. Inversely, it will be much more difficult to do it for project A (due to the large number of users and transactions). So, project B will benefit from sharing the same shielded pool as project A. Likewise, project A will also benefit from it as it will increase the global anonymity set of the shielded pool.
Therefore, if a blockchain supports the MASP, it would not only provide stronger privacy features for its native currency, but this property could also be extended to any other supported assets created on it.
How does the Multi-Asset Shielded Pool work?
As previously mentioned, the MASP allows compatible asset types (i.e. using the same smart contract standard) to share the same shielded pool. But what determines the compatibility of assets? This will depend on how a blockchain decides to implement the MASP, and in particular, the logic/rules that a shielded pool will use. This set of rules will determine if an asset type can use a particular shielded pool or not. Thus, if the logic used is very broad, it is likely that many different assets could comply with it, and hence use the same shielded pool. Conversely, if the logic used is very restrictive, different asset types (f.i. fungible token, non-fungible token, etc.) might have to use different shielded pools.
Let us illustrate this with the following example. Suppose the MASP is integrated on a blockchain. This blockchain only contains assets following the same standard, namely standard n°1 (e.g. a fungible token standard compatible to the ERC-20 used in Ethereum). A shielded pool is created and some assets will join this pool in order to provide shielded transactions to their users (e.g. asset ABC, asset DEF, asset KLM, and asset HIJ, see fig. 3). The users of those assets can then, if desired, use shielded transactions.
Now, let us suppose that a few months later a new standard comes to life (f.i. a non-fungible token standard, named standard n°2). Let us assume that the blockchain developers did not foresee this case, and implemented the MASP in such a way that the logic used by the shielded pool n°1 prevents assets following standard n°2 to use it. The blockchain developer decided to solve this issue by creating another shielded pool (named shielded pool n°2, see fig. 3) to support assets following standard n°2. Again, as not every asset following standard n°2 might want to provide shielded transactions, only some of them might join this new shielded pool.
Note that if the blockchain developers had implemented the MASP with a more general logic, the same shielded pool might have supported both standards.
Thus, the MASP allows you to create shielded transactions for every asset implemented on a blockchain. Furthermore, compatible assets can share the same shielded pool (thereby increasing the global anonymity set of the shielded pool used). Similar to Zcash, MASP proofs demonstrate that the supply conservation and ownership are preserved even though the sender and receiver, the value exchanged, the memo field of a transaction [5] are never published to the blockchain. And on top of it, the asset used is also encrypted and never published to the blockchain (which is useful when there are multiple assets within the shielded pool used).
Keep in mind that a shielded transaction requires more computations (both on the client side, and also to verify on the blockchain) than a regular transaction. Thus, a shielded transaction will be more expensive (have higher fees) than a regular transaction5. Also note that the strong privacy features provided by shielded transactions are a double-edged sword. As the sender and receiver, the value exchanged as well as the memo field of the transaction are encrypted and not publicly visible, it makes it difficult to monitor the shielded pool. Thus, vulnerabilities could be exploited without being detected (see f.i. this case).
5 Note that the protocol could elect to subsidize shielded transactions to reduce the fees (ultimately subsidizing a larger pool to the benefit of the protocol).
About the MASP project
The MASP is an open-source project developed by Metastate. All MASP-relevant information including this article, the link to the source code, its specification, the audit by Least Authority, and articles on possible future integrations can be found on the MASP’s official website. For more details about the technicalities, please visit this repo. For feedback or questions, please do not hesitate to contact us: team@metastate.dev.
Summary
Several methods have been proposed to improve the privacy of blockchains. At the moment, the solutions relying on zero-knowledge proof of knowledge are the ones providing the strongest privacy features. Zcash pioneered the deployment of zk-SNARKs to blockchains and offers the possibility to send either a transparent transaction or a shielded transaction. Even though shielded transactions provide stronger privacy features than transparent transactions, there is still information that could be used to deanonymize a user. This in turn erodes the anonymity of others as it diminishes the global anonymity of the shielded pool. The bigger the shielded pool, and the more frequent the transactions involving it, the bigger the chances of being well hidden.
The multi-asset shielded pool (MASP) is an open-source library implemented in Rust and developed by Metastate. It can be integrated in any blockchain or platform that supports more than one type of asset (although even a single-asset chain could use the MASP). Like Zcash, the MASP allows its users to create shielded transactions, capacity of which can be extended to every other asset implemented on the blockchain. With the MASP, compatible asset types could share the same shielded pool, thereby increasing its size and the anonymity set for every shielded transaction within this pool. For more information, please visit MASP’s official website.
Acknowledgements
As the MASP is an extension of the Sapling circuit, we would like to thank the authors of the original Zcash Sapling circuit specification, written by Daira Hopwood, Sean Bowe, Taylor Hornby, and Nathan Wilcox. We would also like to thank the Electric Coin Company for their work on Sapling and in particular str4d, the author of the first prototype and the github discussions (see e.g. here and here), which greatly inspired the design of the MASP project. Finally, we would like to thank Least Authority, for their work on the first audit of the MASP.
Written by A. Samartino, blockchain researcher at Metastate.
Metastate has ceased its activities on the 31st of January 2021. The team members have joined a new company and working on a new project. If you're interested in zero-knowledge cryptography and cutting-edge cryptographic protocols engineering positions in Rust, check out the open positions at Heliax.
If you have any feedback or questions on this article, please do not hesitate to contact us: hello@heliax.dev.
References
[1] bitcoinwiki.org. Accessed: 2020-04-22.
[2] What are bitcoin mixers ? Accessed: 2020-04-23.
[3] Satoshi has no clothes: Failures in on-chain privacy by Ian Miers (Devcon4). Accessed: 2020-12-11.
[4] Prof. Eli Ben-Sasson. Accessed: 2020-12-11.
[5] How it works. Accessed: 2020-05-06.
[6] Addresses and value pools in Zcash. Accessed: 2020-05-07.
[7] George Kappos, Haaroon Yousaf, Mary Maller, and Sarah Meiklejohn. An empirical analysis of anonymity in Zcash. August 2018.