# Privacy Pools: Towards Practical Privacy & Compliance with Smart Contracts By [Arhat](https://paragraph.com/@aplusb) · 2023-09-07 --- Table of Contents ----------------- 1. **Key Ideas**: _fundamental concepts behind Privacy Pools, the use of zkSNARKs, the role of associated sets, the separating equilibrium._ 2. **Deep Dive into Privacy Pools**: _thorough walkthrough of how Privacy Pools work, the user's journey from deposit to withdrawal, how zkSNARKs facilitate the protocol._ 3. **Differences with Existing Solutions**: _contrast with Tornado Cash's evolution in privacy protocols; the unique features of Privacy Pools._ 4. **Associated Sets Explained**: _associated sets, their construction, and their utility._ 5. **Technical Mechanisms**: _arbitrary denominations; special cases-- re-proofing, bilateral direct proofs, and sequential proofs delves into the flexibility of the Privacy Pools._ Overall, I have structured this analysis in a way that progressively introduces you to the overview of Privacy Pools. * * * [Earlier yesterday](https://twitter.com/ameensol/status/1699424914229321966), Vitalik Buterin, Jacob Illum, Matthias Nadler, Fabian Schär, and Ameen Soleimani shared a new privacy paper exploring the concept of [Privacy Pools](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4563364), a novel smart contract-based privacy-enhancing protocol. This [paper](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4563364) proposes a method for achieving greater privacy while enabling regulatory compliance on public blockchains like Ethereum. The key ideas: -------------- * Using zero-knowledge proofs to hide the link between deposits and withdrawals in a privacy protocol like Tornado Cash. This hides a user's transaction graph. * Allowing users to create "associated sets" - sets of deposits they claim their withdrawal could have come from. This preserves privacy within the set. * Users can prove membership in compliant association sets, e.g. excluding known illicit deposits, without revealing exactly which deposit was theirs. * Honest users are incentivized to prove membership in compliant sets, while illicit users cannot. This creates a separating equilibrium. * Association sets can be constructed in various ways, e.g. only including KYC'd users or excluding risky deposits. Different sets can satisfy different regulations. * Users don't reveal their association sets publicly, only a commitment. Sets are published by providers off-chain. * Users can still give direct proofs to counterparties if needed, but this requires trust. * For rapid re-spending, users propagate history to show the ultimate origin is compliant. * Special access or allowlisting creates centralization risks. The voluntary disclosure model is more flexible. In summary, it allows for privacy within compliant association sets, avoids tainting between sets, and incentivizes honest behavior - aiming to balance privacy and regulation. Let's dive deep into detail * * * Privacy Pools are the core mechanism proposed in this paper for achieving privacy while enabling regulatory compliance. ----------------------------------------------------------------------------------------------------------------------- They are a modification of existing privacy protocols (Tornado Cash) that use ZKPs. * The key difference is allowing users to specify an "association set" - a set of deposits they claim their withdrawal could be associated with. * This set can be arbitrarily large or small to balance privacy and compliance. Users prove set membership with a ZKP. * Sets are generated by providers following certain rules, e.g. excluding known illicit deposits. Multiple providers can exist. * By proving membership in a compliant set, users can show regulatory compliance without fully revealing their transactions. Tornado Cash faced regulatory issues because it did not have any built-in way for users to prove the legitimacy of their funds. So, it was essential to find a better equilibrium. Privacy pools aim to show that with careful protocol design, **privacy** and **regulation** can coexist on public blockchains. The proposal tries to steer the conversation in a more constructive direction. ![derived from my understanding of how privacy pools would work after reading the paper](https://storage.googleapis.com/papyrus_images/67b2cdf6830d6e818208bffae227feaa831f441604f7f159f1ad1d24e6757a83.png) derived from my understanding of how privacy pools would work after reading the paper 1. Users make deposits into the privacy pool as normal. Each deposit gets a unique secret/coin ID pair. 2. When making a withdrawal, the user specifies an association set - a set of deposits they claim the withdrawal could be associated with. 3. The user provides a zkSNARK proof showing: 1. Their coin ID is in the overall deposit tree. 2. Their coin ID is also in the association set tree. 4. The association set tree root is public, but the set members are not revealed. 5. Association sets are created by providers based on certain rules, e.g. excluding known illicit deposits. 6. By proving membership in a compliant association set, the user shows regulatory compliance without revealing exactly which deposit was theirs. 7. If needed, users can give direct proofs to counterparties to reveal the specific deposit. But this requires trust. 8. For rapid spending, users propagate history to show the ultimate origin is compliant. 9. Users are incentivized to prove membership in legitimate sets, while illicit users cannot provide this proof. **zkSNARKs for privacy pools** ------------------------------ zkSNARKs (zero-knowledge succinct non-interactive arguments of knowledge) play a crucial role in enabling privacy pools: * They allow users to prove membership in an association set without revealing which specific deposit is theirs. * The zkSNARK proof shows the user's coin ID is in the overall deposit tree and their provided association set tree. * However the actual mapping between coin IDs and deposits stays hidden. This preserves privacy within the association set while still allowing the membership proof to be verified publicly. **The core idea of Privacy Pools is this: instead of merely zero-knowledge-proving that their withdrawal is linked to some previously made deposit, a user proves membership in a more restrictive _association set_.** ![](https://storage.googleapis.com/papyrus_images/7c235f08cdc68c6c713d96c9221a8308fca24567e25922436746a036aca35d8a.png) In Tornado Cash, when making a withdrawal, users submit a zero-knowledge proof that shows: * They are spending a valid coin (deposit) that exists in the system * The coin has not already been spent This proves the withdrawal is linked to some previous deposit, without revealing which specific deposit it is. The core idea in Privacy Pools is to make this more selective and flexible. Instead of proving linkage to the set of all possible previous deposits: * Users specify an association set - a subset of deposits they want to claim the withdrawal is associated with. * They then prove membership in this more restrictive set, not the full set of deposits. For example: * The association set could be "all deposits from users located in India" * Or "all deposits from trusted exchanges" * Or "all deposits except those flagged as risky" By allowing this flexibility, users can selectively disclose some information about the withdrawal's origin while still preserving privacy within the association set. This is more restrictive than just proving linkage to any previous deposit. But it also enables regulatory compliance, avoiding the problem in Tornado Cash, where funds were completely mixed together. _zkSNARKs provides the zero-knowledge property that allows compliance proofs without full disclosure of a user's transactions._ ### **Difference between Tornado Cash & Privacy Pools** Tornado Cash uses a **universal anonymity set**, meaning that all deposits and withdrawals are mixed together in one pool. Privacy Pools uses a **customizable anonymity set**, meaning that users can choose which deposits and withdrawals they want to mix with based on their preferences and needs. ![based on my understanding after going through the paper](https://storage.googleapis.com/papyrus_images/a1e8ab8bb9176346f61ab6932486ab537339955300e890ff1173517257d8ddd5.png) based on my understanding after going through the paper **Now, what exactly are Association Sets?** ------------------------------------------- To understand the importance and use case of association sets, we need to delve deeper into the problems they solve and how they operate. **Problem Statement:** 1\. **Transparency vs. Privacy**: Public blockchains, by design, are transparent. Every transaction is visible to anyone who wishes to see it. This transparency brings trust and security but comes at the cost of **privacy**. 2\. **Regulatory Compliance**: As crypto gains popularity, regulatory authorities worldwide are increasing scrutiny. They want to ensure funds aren't used for illegal activities like money laundering or financing terrorism. This often requires users to prove the legitimacy of their funds. 3\. **Complete Anonymity Issues**: If users were to anonymize their transactions entirely, it would be challenging to establish trust with counterparties or satisfy regulatory requirements. > \-- > > _Imagine a scenario where you need to prove that you've paid your taxes without revealing your exact income. Instead of showing your exact tax return, you present a range (e.g., "$30,000 - $40,000")._ > > _The tax authorities can verify you're in compliance without knowing the exact amount you made._ > > _In this analogy, the range is akin to the association set—it offers proof without complete revelation._ > > \-- **An association set refers to:** * A set of deposits that a user claims their withdrawal could be associated with. * The user proves their withdrawal is associated with some deposit in the set without revealing which one. Some properties of association sets: * Can be arbitrarily large or small, balancing privacy and compliance. * Generated by providers based on specific rules, e.g., excluding known illicit deposits. * User proves membership via zkSNARK without revealing their actual deposit. * Sets aim to satisfy regulatory requirements, e.g., excluding risky deposits. * No need to reveal the entire transaction history, just the association set. * This allows users to prove regulatory compliance at a high level, without fully disclosing all their transactions. Overall, association sets allow a flexible balance between privacy and selective disclosure to show compliance. **There are two main strategies for constructing Associated Sets** ------------------------------------------------------------------ ![Source: Blockchain Privacy and Regulatory Compliance](https://storage.googleapis.com/papyrus_images/5833f9440fa59c2ffec2b1c489e7c7fdef4dfb9552ae3348f7d0dd4fb3024b60.png) Source: Blockchain Privacy and Regulatory Compliance **Inclusion (Membership):** * Identify a specific set of "approved" or "low-risk" deposits. * For example, deposits from verified users or below a certain value threshold. * The association set only includes those approved deposits. * Proving membership shows the funds originate from approved sources. **Exclusion:** * Identify specific high-risk or prohibited deposits. * For example, deposits connected to hacks, theft, or sanctioned entities. * The association set includes all deposits except those excluded ones. * Proving membership shows disconnection from the excluded ones. This aspect of Privacy Pools refers to how users can prove membership in an association set without revealing their specific deposit information using zero-knowledge proofs. **Let me explain in more detail:** * When a user wants to make a withdrawal, they first decide on an association set they want to claim membership in. * This set is represented as a Merkle tree, where each leaf is the hash of a deposit ID. * The user generates a zkSNARK proof that shows:1) Their deposit ID is somewhere in the full tree of all deposits.2) Their deposit ID is also somewhere in the association set tree. * The zkSNARK proof does not reveal WHICH leaf in the association set tree corresponds to their deposit. * It only proves that their deposit is somewhere in the association set tree. * Verifiers can check the proof is valid without learning the user's specific deposit ID. * So the user gets privacy within the set, while verifiers confirm the deposit is somewhere in the set. * The association set size bounds the potential deposit space, providing selective disclosure. zkSNARKs allow users to prove membership without fully revealing their transactions - the essence of how Privacy Pools enables compliance without sacrificing privacy. Privacy Pool protocols are very flexible and can be customized to suit a large variety of use cases by creating specific association sets, such as: ![Derived from the paper, based on my understanding.](https://storage.googleapis.com/papyrus_images/d96fb3c1ec93446ea95c0dc455c8610fe6a0637dc0cef51d120173848654a6c0.png) Derived from the paper, based on my understanding. So, in summary, association sets allow privacy within a compliant group, avoiding full public disclosure. Users pick a set that matches their privacy and compliance needs. ### **In practice, users will not be manually picking and choosing deposits to include in their association set.** ![](https://storage.googleapis.com/papyrus_images/651e61620d9269cbcf0d6ba7c2df0bb57099d730e39d6d82d63543e75efd8b8a.png) It would be infeasible for users to examine all deposits manually and selectively pick which ones to include in their association set. Instead, users will subscribe to ASPs that generate sets programmatically based on specific rules and criteria. For example, an ASP might: * Exclude deposits linked to theft or sanctions to create a "clean" set. * Only include deposits from users who passed KYC checks for a "verified" set. * Build jurisdiction-specific sets that comply with local regulations. The ASP handles all the set construction details on the user's behalf. Users simply choose an ASP they trust and use the set(s) it provides. The ASP becomes an intermediary that abstracts away the set building complexity. This allows users to rely on the ASP's expertise in constructing useful, compliant sets. ![Derived from the research paper: Blockchain Privacy and Regulatory Compliance](https://storage.googleapis.com/papyrus_images/297e469d8e41a62b5a3e68c22a8c5486a9e979b05b0c913b60a12af87ba6d1d5.png) Derived from the research paper: Blockchain Privacy and Regulatory Compliance So, in summary, rather than building association sets manually, users will leverage trusted ASPs that provide pre-generated sets with desirable properties. This simplifies compliance for end users. **The paper further analyzes how Privacy Pools could support arbitrary denominations and some special use cases** ----------------------------------------------------------------------------------------------------------------- ![research paper: Blockchain Privacy and Regulatory Compliance](https://storage.googleapis.com/papyrus_images/4691d8c6433097807ed0ef5ee2c267cfb8ef664ec7fb37c28893048ba969ae0b.png) research paper: Blockchain Privacy and Regulatory Compliance ### **Supporting Arbitrary Denominations:** Arbitrary denominations allow for more flexibility than fixed denominations. Instead of transactions occurring in fixed amounts, users can transact in any amount they desire. Such a system would need mechanisms to handle operations like "splitting" and "merging" of amounts. **Currently, Privacy Pools only supports fixed-denomination coins.** To handle arbitrary amounts, the protocol can adopt a UTXO model like Zcash: * Transactions can have multiple coin ID inputs and outputs. * Values are encrypted, but input/output sums must balance. * Additional proofs are needed to prevent value fabrication. Withdrawals become "partial spends" of deposits. This breaks the link between deposits and withdrawals. To track deposit origins, commitments can propagate through transactions: * Commit to deposit coin ID + random nonce at each step. * Later withdrawals can omit early history that's added to the association set. Merging coins can help prevent linking attacks. Users merge loose change before withdrawing. > _Let me summarize the key points:_ > > _Zcash handles arbitrary amounts using a UTXO model with multiple inputs and outputs per transaction. Values are encrypted but input/output sums must balance._ > > _Withdrawals become "partial spends" of deposits. This breaks the link between specific deposits and withdrawals._ > > _To track deposit origins through partial spends, commitments can propagate through transactions:_ > > * _Each transaction commits to original deposit coin ID + random nonce_ > > * _ZK proof shows commitment matches parent transaction's_ > > * _Withdrawals prove commitment is in their association set_ > > > _Allowing coin merging helps privacy - users can merge loose change before withdrawing to prevent linking based on amounts._ > > _Simply treating withdrawals as outputs and change as inputs (as in Zcash) is problematic - the "source" appears to be the prior change output, rather than the original deposit._ > > _Propagating commitments fixes this by explicitly passing the original deposit ID through partial spend transactions._ > > _Now each withdrawal can prove membership of the actual initial deposit, even through multiple partial spends._ ### Special Cases **Re-proofing**: Privacy Pools protocol allows users to generate new proof against an updated version of the initial association set by keeping their secret information. * If I want to withdraw and publish a membership proof, I can later generate a new proof against an updated association set using my secret withdrawal data. * This gives flexibility if sets change. However, storing secrets long-term has risks. **Bilateral Direct Proofs**: Privacy Pools protocol supports bilateral direct proofs, which allow a user to disclose the precise origin of their withdrawal to another party without revealing the entire set of deposits. * I can selectively disclose my specific deposit to a counterparty by creating a one-member association set. * More advanced option: Zero-knowledge proof of: * Membership in association set, OR * "I am the counterparty", OR * A timestamp showing the proof wasn't created too long ago. * This limits the potential for misuse of the proof. **Sequential Proofs**: Privacy Pools protocol supports sequential proofs by allowing users to generate a new proof against an updated version of the initial association set. * Internal send transactions are added to enable rapid re-spending. * Senders propagate history to recipients to prove ultimate origin is compliant. * Older history can be omitted once it's added to the association set by the ASP. In summary, supporting arbitrary amounts involves additional proofs and commitments. Special cases like re-proofing, bilateral disclosure, and sequential proofs can be enabled by modifying core protocol mechanics. Privacy Pools protocol is a flexible and customizable privacy-enhancing protocol that can support arbitrary denominations and various special cases like re-proofing, bilateral direct proofs, and sequential proofs. By using a Merkle tree to store the deposits and allowing users to generate zero-knowledge proofs, this protocol could create a separating equilibrium between honest and dishonest users while also enabling regulatory compliance without revealing entire transaction histories. Furthermore, the proposal mentions that there are two key incentives that are expected to drive the adoption of Privacy Pools by honest users: ---------------------------------------------------------------------------------------------------------------------------------------------- **The desire for privacy** * Public blockchains reveal all transaction details. This damages user privacy. * Privacy Pools hides transaction graphs and specifics, enhancing privacy. * Users motivated to use it to keep their financial transactions private. **The desire to avoid suspicion** * Illicit activity on transparent blockchains raises suspicion and causes blacklisting issues. * Privacy Pools allow users to prove they aren't associated with illicit funds. * Honest users are incentivized to leverage this to avoid being suspected of wrongdoing or having their funds frozen. * Participation in the system demonstrates you aren't trying to hide illicit activity. The incentives are aligned for mass adoption - both privacy seekers and regulatory compliers benefit from using Privacy Pools. Thoughts -------- So, think of Privacy Pools as the perfect blend of keeping things private while still playing by the rules on public blockchains. (for noobs) It's like they've taken some really smart crypto tech and combined it with practical design to give users an awesome experience. You get to keep your business to yourself and still show that you're on the right side of the law. And as more people jump on the blockchain bandwagon, Privacy Pools is set to play a big role in making sure everything's safe, private, and above board for everyone involved. Cool, right? * * * Sources ------- 1. [Blockchain Privacy and Regulatory Compliance: Towards a Practical Equilibrium](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4563364) * * * Thank you for reading through, and subscribe below for regular post updates. I’d also appreciate it if you shared this with your friends, who would enjoy reading this. You can contact me here: [Twitter](https://www.twitter.com/0xArhat) and [LinkedIn](https://www.linkedin.com/in/arhatbhagwatkar). You can also buy my keys at friend.tech by searching for **0xArhat**. If you find this deep dive analysis useful, please consider donating to **0x1de17b6c736bcd00895655a177535c2a33c6feba** (Arbitrum, Ethereum, Optimism) and/or by minting an NFT for this & other blog posts by me. * * * ### **Previous Research:** 1. [Decoding & Democratizing Web3](https://mirror.xyz/0x1dE17B6c736bcd00895655a177535c2a33C6febA/AujK4hOtAHQLmiqCBh6-iY2HsOfh670vsBzB3XeAwQk) 2. [P2E: A Shift in Gaming Business Models](https://mirror.xyz/0x1dE17B6c736bcd00895655a177535c2a33C6febA/X1i6f_sa9Vb6Z11kNGwgRIslq7tAg_JCqfjj3aVS28I) 3. [Stablecoins: Is there hope?](https://mirror.xyz/0x1dE17B6c736bcd00895655a177535c2a33C6febA/rKAtZH7wSPOegp-jiKXCGMf0CzZEowaOZ1akBfPEySs) 4. [If you don't control your data why do you trust it](https://mirror.xyz/0x1dE17B6c736bcd00895655a177535c2a33C6febA/j4lMQnmDODGfYsS4v46KI6dM3qN6HRkSYsU-AIR6E1g) 5. [Primer on L2 Scaling Solutions](https://mirror.xyz/0x1dE17B6c736bcd00895655a177535c2a33C6febA/rSyR0EmKHJWdgE5_wKNT0d4x9ULdfm88EYS-MzS7k_8) 6. [Understanding User Dynamics in DeFi](https://mirror.xyz/0x1dE17B6c736bcd00895655a177535c2a33C6febA/KhTPNvvmBrCV2yosqudcPlifItxv-mqTzHx_azwzczs) 7. [Intro to Lending and Borrowing Mechanics in DeFi](https://mirror.xyz/0x1dE17B6c736bcd00895655a177535c2a33C6febA/kZObYFJWpHUfu45Y3rGrx0jDjKSNeg-Ug71ULcerdz4) 8. [Part 2: DeFi Deep Dive on COMP, AAVE, and MKR](https://mirror.xyz/0x1dE17B6c736bcd00895655a177535c2a33C6febA/B8cbn_-y_URcfTLvItGnfKvKtnarZF1DoIAH_f48XGQ) 9. [Best Way to Create Value with Data in Web3](https://mirror.xyz/0x1dE17B6c736bcd00895655a177535c2a33C6febA/CFij4cxisbE2ws-IQMTo2lX-O3Jb39bQH2XdZY_JThM) 10. [Building a Decentralized Climate Finance DAO](https://mirror.xyz/0x1dE17B6c736bcd00895655a177535c2a33C6febA/aTfiq5IqoXREjnEl53fuVWpjx8xjepaSr1nfPLB6apE) 11. [Org vs. DAOs: Governance & Growth in Modern Society](https://mirror.xyz/0x1dE17B6c736bcd00895655a177535c2a33C6febA/d_Sv9HkIU1azQHCKxOGXhipGHdFY4gjrO1T4WMjjEB8) 12. [ERC-4337: The Future of Ethereum Token Standards](https://mirror.xyz/0x1dE17B6c736bcd00895655a177535c2a33C6febA/SgpKc2kG9Ak00YkkYm8RSPa1AA0kBIuZZ4Jn-Phdnos) 13. [Identity Without Borders: Decoding My Online Identity](https://mirror.xyz/0x1dE17B6c736bcd00895655a177535c2a33C6febA/kB7baMBlZbB66gVvytwOpZFDFeO5eBwXimHlWP80cXY) 14. [Web3s 3-Wave Model of Evolution of Complex Systems](https://mirror.xyz/0x1dE17B6c736bcd00895655a177535c2a33C6febA/EDFYP-lxubnTyA-M28ngINaIP6aXbbeZUlyW-8dpiGI) 15. [Understanding Tokenomics: Case Study of dYdX](https://mirror.xyz/0x1dE17B6c736bcd00895655a177535c2a33C6febA/-sy16KFD20CiUFwjS_7m1jwN1Z2kSV4MLi1RUFnsyLQ) 16. [DeFi Hacks Unveiled: What We've Learned from Q2](https://mirror.xyz/0x1dE17B6c736bcd00895655a177535c2a33C6febA/5b988KvZHTQuS0f4RVVbOcJJR0pYp8KFzwXd1NzZr_A) 17. [Voting Mechanisms & Incentives for Governance in DAOs](https://mirror.xyz/0x1dE17B6c736bcd00895655a177535c2a33C6febA/TZ8pkWM34ondxe6iu6Q3zHi6Kqg2dPX79396gGy49Ro) 18. [Uniswap’s Fee Switch Dilemma](https://mirror.xyz/0x1dE17B6c736bcd00895655a177535c2a33C6febA/PluLq9Eyjv_DjHXlT-CWaEOJyu0x__exSzBkojAfFoE) 19. [MakerDAO's Endgame: 5 Phases and 14 MIPs](https://mirror.xyz/0x1dE17B6c736bcd00895655a177535c2a33C6febA/32i-7o6MWkHIUhbyNFuBCBJzzfGktCfHf-lTinoNoWA) 20. [Liquid Staking Tokens: Can They Bounce Back?](https://mirror.xyz/0x1dE17B6c736bcd00895655a177535c2a33C6febA/e5WQmp-FvqH13n1n_Pvy0F1N136ji8cQWVniaGjHttY) 21. [Binance Smart Chain: Luban Hard Fork](https://mirror.xyz/0x1dE17B6c736bcd00895655a177535c2a33C6febA/zMkTi2TP1pDZy0s_SRJRJ7zwUBTmIxaQDxL_yz9xefw) 22. [crvUSD: A Stable Alternative?](https://mirror.xyz/0x1dE17B6c736bcd00895655a177535c2a33C6febA/M4nSoN74rRev_vQLnUhNUpoMds6_eipSvzBp_ANFaKI) 23. [friend.tech: Tokenizing Incentives for "friends"](https://mirror.xyz/0x1dE17B6c736bcd00895655a177535c2a33C6febA/y_Eq913CDvBIFn9XAiYBTlzfs7oBwPOeEkZgp9-Y-Dk) 24. [MEV Endgame: Exploring Mempool Privacy Schemes](https://mirror.xyz/0x1dE17B6c736bcd00895655a177535c2a33C6febA/D7OfvJfGGGndCa8aMtqD6NnOPtcUt2zZBsZTjOVkCW8) --- *Originally published on [Arhat](https://paragraph.com/@aplusb/privacy-pools-towards-practical-privacy-compliance-with-smart-contracts)*