By implementing the multi-asset shielded pool, Anoma allows all assets to share the same shielded pool. This is beneficial for every user of a shielded pool as it increases the potential number of transactions, which in turn increases the anonymity set for every of its users. This allows all assets within a shielded pool to have the same privacy guarantees (regardless of their respective volume).
Anoma is a sovereign, proof-of-stake blockchain that enables private, asset-agnostic bartering among multiple parties. One of Anoma’s goals is to ease private payments using arbitrary assets , i.e. enabling anything to be used as private, digital cash.
Currently, the solutions relying on zero-knowledge proofs are the ones providing the strongest privacy features. Among them, Zcash pioneered the deployment of zk-SNARKs (a particular type of zero-knowledge proof) to blockchains. Zcash offers the possibility to send either a transparent transaction (using t-addresses) or a shielded transaction (using z-addresses). As the name suggests, with a transparent transaction, everything is publicly visible. Conversely, 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 . Using a zero-knowledge approach guarantees considerable privacy protection for on-chain data via cryptographic means1.
As the degree of privacy of a shielded pool depends on the number of participants and the number of transactions, the best solution is to gather as many assets and users as possible in the same shielded pool. This creates a network effect, as every additional user increases the potential number of transactions, which in turn increases the anonymity set for every user. 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 assets and more frequent the transactions, the bigger your chances of being well-hidden.
That is why the multi-asset shielded pool (MASP) is deployed as a validity predicate on Anoma. The MASP is an extension of the Sapling circuit (used in Zcash). Thus, it allows users to create shielded transactions with strong privacy guarantees. Furthermore, its novel features allow all asset types to share the same shielded pool, thereby increasing the size and the anonymity set of every shielded transaction within the shielded pool. The MASP is an open-source library written in Rust, and has been introduced in this article. Additionally, it has a dedicated website.
What does the MASP enable in Anoma?
Let us have a look at the following examples.
Shielded transfers in Anoma
Suppose that Alice and Bob are discussing Anoma, and Alice proposes to send a token to Bob later that afternoon. Knowing Bob's passion for privacy, Alice tells him that she will send him a token using the biggest shielded pool2 in Anoma. Eve, who overheard the discussion, would like to learn more about this particular transaction and decides to observe the biggest shielded pool. As proposed, Alice sends a shielded transfer to Bob3. By doing so, the sender and receiver, the value exchanged, as well as the memo field of a transaction will be encrypted and not publicly visible (similar to Zcash ). On top of that, the asset used is also encrypted and not published to the blockchain. As there are numerous transactions, Alice’s transaction will look indistinguishable from any other transaction. Thus, Eve will not be able to know which one could have been sent by Alice as well as the type of asset used (included in the set of assets of this shielded pool).
MASP validity predicate
Anoma introduces a unique concept to determine the validity of a state transition referred to as validity predicate (learn more by reading this article). The MASP is incorporated as a validity predicate to allow seamless interoperability with Anoma’s standard validity predicate interface. To gain a better understanding, let us revisit the previous example.
In the above example, Alice’s transaction will trigger the validity predicate of the MASP. External observers will be able to know that someone interacted with the MASP as this transaction will appear in Anoma’s ledger4. However, the update of its state (sender, recipient, amount, asset.) will be encrypted and not appear on Anoma’s ledger. Only Alice and Bob will know the details of this transaction (sender, recipient, amount and asset used).
The seamless interoperability of the MASP allows users to use the MASP capabilities as part of a transaction which could also do other things. For instance, in the same transaction, Alice could include a transfer to Bob (using the MASP) as well as a publicly viewable transfer to Charlie. Another use case could be for Alice to modify her validity predicate to execute a transparent transfer contingent on a shielded one (using zero-knowledge proofs).
Shielded transfers in Anoma using low volume assets
As seen above, the asset used could be any asset included in the shielded pool. For instance, this could include Anoma’s native asset XAN, but it could also include non-native assets like BTC, ETH, DOT, etc. This can be particularly beneficial for assets used on a blockchain that do not provide strong privacy features and/or are low volume assets (e.g. only a few transfers) like in the example provided below.
Suppose that Alice wants to thank Bob by sending him a brand new token (e.g. CryptoCat) in the afternoon. As this token is brand new, it is rarely transferred, and we will assume that its native blockchain (the CryptoCat blockchain) does not provide strong privacy features. Knowing Bob's passion for privacy, Alice cannot directly send him this token. As it is seldomly transferred (1-2 transactions a day), an external observer might automatically know which transaction was sent by Alice. For instance, if there is only one transfer in the afternoon, Eve (who eavesdropped on the conversation) will have no difficulty in deanonymizing this transaction.
In order to satisfy Bob’s requirement of privacy, Alice will transfer this token to Bob using Anoma. By transferring it to Anoma and including it in the shielded pool that already contains other assets, Alice’s transaction will be beneficial for all the users of this shielded pool (as the global anonymity set of the shielded pool will increase). Assuming that Alice will transfer her CryptoCat token to Bob in the afternoon, Eve will now not be able to deanonymize this transfer between Alice and Bob (as seen below).
As seen in the example above, any asset created on Anoma or transferred from another blockchain can benefit from Anoma’s enhanced privacy features. This is particularly beneficial for assets with a low volume and/or assets that cannot guarantee strong privacy features. Moreover, this is also beneficial to other users of Anoma’s shielded pool (as the more assets and transactions in it, the more it increases its collective privacy benefit).
The original version of the MASP is an extension of the Sapling circuit . It relies on zk-SNARKs with the Groth16 proving system. As the MASP is an evolving project, research is being conducted to upgrade it using PLONK (i.e. Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge), and plookup (i.e. simplified polynomial protocol for lookup tables). This will allow:
- An enhancement of the trusted setup. With the previous version of the MASP, any change in the protocol will result in having to create a new trusted setup. Using PLONK will allow all circuits used in Anoma to share the same trusted setup. Ultimately, the need for a trusted setup might also be removed (by using Halo or another technique).
- Some parts of the circuit to be enhanced (more efficient computation time) by using plookup, this includes:
- creating lookup gates for hash functions
- using a lookup table to do a lot of binary operations in a single constraint.
- speed up the Blake2 hash function contingent on this hash function still being used.
- Recursion: MASP proofs are used to assess the validity of a transaction, but could be used to prove much more. For instance, you could group together a cluster of them and use a single proof that proves they are correct. This way, you end up with a single proof that proves that this particular cluster is correct.
Thus, by using PLONK/plookup, the MASP in Anoma will be as a whole more efficient, faster, and simpler to use.
The multi-asset shielded pool (MASP) relies on zero-knowledge proofs (which currently provide the strongest privacy features) and allow all assets to share the same shielded pool, thereby increasing the size and anonymity set of every shielded transaction within a particular shielded pool. Native Anoma tokens as well as non-native Anoma tokens (e.g. Bitcoin, Ethereum, etc.) can benefit from these enhanced privacy features. By implementing the MASP, Anoma works towards its vision of facilitating private payments using arbitrary assets.
 Anoma whitepaper
 How it works, accessed: 2021-05-07.
- Note that users might still be vulnerable to non-cryptographic attacks (i.e. transaction timing, IP addresses, etc., which might contribute to deanonymizing them).↩
- Anyone can create a shielded pool on Anoma. The set of rules/logic used by a shielded pool will determine if an asset can join it or not. Hence, if the logic of a particular shielded pool is very general, it is likely that it will allow a broad number of assets to adhere to it. Inversely, if the rules are particularly restrictive, only a few assets might be able to comply with it and join the shielded pool (e.g. a user might want for belligerent reasons to create a very restrictive shielded pool only for his token or a stable coin issuer could want to have the viewing key for every transaction in the shielded pool) . The more general the rules and logic, the more assets that can join a shielded pool, which results in more transactions and a bigger global anonymity set.↩
- Note that before sending the asset to Bob, Alice needs to know Bob's shielded address.↩
- The same situation happens when you transfer an asset outside the MASP. It is somehow similar to the situation in Zcash when you transfer ZEC from a t-address to a z-address (and vice versa).↩