Vitalik Buterin’s latest paper How Privacy Pool Protocol Protects User Privacy and Meets Regulatory Requirements.

Vitalik Buterin's paper on Privacy Pool Protocol Protecting User Privacy and Meeting Regulatory Requirements.

Creating an associated collection is one of the requirements.

Original Title: “Blockchain Privacy and Regulatory Compliance: Towards a Practical Equilibrium”

Authors: Vitalik Buterin, Jacob Illum, Matthias Nadler, Fabian Schar and Ameen Soleimani

Today, Vitalik Buterin and others jointly wrote a research paper on privacy protocols, titled “Blockchain Privacy and Regulatory Compliance: Towards a Practical Equilibrium”.

• Consensys Strategic Director Decentralized Infura to be launched by the end of this year
• Data Interpretation Performance Comparison between GMX V1 and V2
• The Gospel of DeFi? Synthetix plans to launch the Synthetix V3 protocol in the fourth quarter.

The paper introduces a new privacy-enhancing protocol based on smart contracts called “privacy pool”, discusses its advantages and disadvantages, and demonstrates how it balances the needs of honest and dishonest users. This protocol aims to use zero-knowledge proofs to verify the legitimacy of users’ funds without revealing their complete transaction history, thus balancing privacy and regulatory requirements while filtering out funds related to criminal activities.

Odaily Star Daily has compiled the essence of the paper as follows.

1. Introduction

Public blockchains are designed to be transparent. The basic idea is that anyone can choose to verify transactions without relying on centralized third parties. By reducing dependencies, it provides a neutral foundation for various applications, including but not limited to finance and self-sovereign identity.

However, from a privacy perspective, public datasets contain every transaction of each blockchain address. Whenever assets are transferred to another address or interact with smart contracts, the transaction will be permanently visible on the blockchain. This obviously does not meet privacy requirements.

For example, Alice pays for dinner at a restaurant using a blockchain wallet. The recipient now knows Alice’s address and can analyze all past and future activities associated with that address. Similarly, Alice now knows the restaurant’s wallet address and can use this information to obtain other customers’ wallet addresses or view the restaurant’s income. Or a third party (such as social media) knows the restaurant and Alice’s wallet addresses, making it easy to deduce Alice’s actual residence address and study her past and future transactions.

The rise of privacy-enhancing protocols aims to address the above issues. It allows users to deposit funds into the protocol using one address and withdraw funds from the protocol at a later point in time using another address. All deposits and withdrawals can still be seen on the blockchain, but the specific correlation between incoming and outgoing transactions is no longer public.

One of the most well-known privacy-enhancing protocols is Tornado Cash. It has successfully addressed the above issues, allowing users to retain some privacy. However, besides legitimate users trying to protect their data, Tornado Cash has also been used by various malicious actors. Evidence shows that hacker organizations have transferred funds through this protocol. There is also evidence that North Korean hacker groups have used this privacy-enhancing protocol, leading to the smart contract address of the protocol being included in the Special Designated Nationals and Blocked Persons List (commonly known as the SDN list) maintained by the U.S. Office of Foreign Assets Control (OFAC).

The key issue with Tornado Cash is the ambiguity between legitimate and criminal users. Therefore, Tornado Cash provides a compliance feature that allows users to create evidence to prove which deposit a given withdrawal came from. While this mechanism does allow people to prove their innocence, the cost is having to trust a centralized intermediary and creating information asymmetry. Ultimately, this mechanism is hardly used by users.

This article discusses an extension to this approach that allows users to publicly prove information about their withdrawals possibly coming from certain deposits, without compromising privacy. The concept of Privacy Pools introduces the idea of membership proofs (“I can prove my withdrawal came from one of these deposits”) or exclusion proofs (“I can prove my withdrawal did not come from any of these deposits”). This article discusses this proposal and explains how it can achieve a balance between honest and dishonest users.

Note that Privacy Pools provide additional options by expanding the set of actions users can take. If needed, they can still provide more detailed proofs to specific transaction partners. However, in certain cases, membership or exclusion proofs may already be sufficient. Furthermore, the choice to publicly disclose these proofs has many advantages over bilateral disclosure.

II. Technical Background

In this section, we provide a brief technical overview and discuss the technical construction and general principles of protocols like Privacy Pools.

1. Blockchain Privacy Before ZK-SNARKs

Historically, supporters of blockchain believed that despite all transactions being transparent, blockchain could protect privacy because they provided anonymity.

With the emergence of modern clustering and analysis tools, this privacy protection has become insufficient. To enhance the privacy of public blockchains, more powerful technologies like token joins and Monero were introduced. However, these technologies still carry the risk of data leakage.

Subsequently, general-purpose zero-knowledge proof technologies like Zcash and Tornado Cash emerged, which could make the anonymity set of each transaction equal to the entire set of previous transactions. This technology is commonly referred to as ZK-SNARKs.

2. ZK-SNARKs

ZK-SNARKs are a technology that allows a prover to prove a mathematical statement about public and private data, while satisfying two key properties: zero knowledge and succinctness.

● Zero Knowledge: No information about the private data is revealed other than the fact that the private data satisfies the statement being proven.

● Succinctness: The proof is short and can be quickly verified, even if the statement being proven requires time-consuming computation.

ZK-SNARKs have gained significant attention in the blockchain community because of their importance in scalability, such as ZK-rollups. For privacy applications, succinctness is not particularly important, but zero knowledge is essential.

The “statement” of a ZK-SNARK proof can be seen as a program type called a “circuit” that computes the result of the function f(x, w) using public inputs and private inputs, and then proves that for a given public input x, there exists a private input w such that the result of f(x, w) is True.

3. Applications of ZK-SNARKs in systems like Zcash and Tornado Cash

There are some minor differences between different versions of Zcash and systems inspired by it, such as Tornado Cash. However, they rely on similar underlying logic. This section describes a simplified version that roughly corresponds to how these protocols work.

Tokens are composed of a secret s held by their owners. Two values can be derived from s:

● Public token ID L = hash(s + 1)

● Nullifier U = hash(s + 2)

Here, hash refers to a cryptographic hash function, such as SHA 256. Given s, the token ID and nullifier can be computed. However, given a set of nullifiers and public token IDs, the pseudorandom behavior of the hash function ensures that you cannot determine which nullifier is associated with which token ID unless you know the secret s that generated both.

The blockchain keeps track of all token IDs that have been “created” and all nullifiers that have been “spent”. Both sets are constantly growing (unless the protocol mandates when tokens must be spent).

The set of token IDs is stored in a data structure called a Merkle tree: if the tree contains N items, each adjacent pair of items is hashed (resulting in ⌈ N/2 ⌉ hashes), and these adjacent hashes are hashed again (resulting in ⌈ N/4 ⌉ hashes), and so on, until the entire data is committed to a single “root hash”.

Given a specific value in the tree and the root hash, a Merkle branch can be provided: the “sister values” that were hashed together at each step on the path from that value to the root. This Merkle branch is useful because it is a small (log 2(N) hashes) data fragment that can be used to prove that a specific value actually exists in the tree. The image below shows an example of a Merkle tree with a height of 4.

When users send coins to others, they provide:

● The nullifier U they want to spend

● The token ID L’ of the new token they want to create (the recipient is asked to provide this)

● A ZK-SNARK proof

The ZK-SNARK proof contains the following private inputs:

● The user’s secret s

● A Merkle branch in the token ID tree that proves the token ID L = hash(s + 1) of the token was actually created at some point in the past

It also contains the following public inputs:

● U, the nullifier of the token being spent

● R, the root hash that the Merkle proof is being targeted against

ZK-SNARK proves two properties:

● U = hash(s + 2)

● The Merkle branch is valid

In addition to ZK-SNARK, the protocol also checks the following:

● R is the current or historical root hash of the token ID tree

● U is not in the spent nullifier set

If the transaction is valid, it adds U to the spent nullifier set and adds L’ to the token ID list. This prevents a single token from being spent repeatedly. However, no other information is revealed. The external world can only see when a transaction is sent; they cannot obtain patterns about who sends or receives these transactions, nor can they distinguish the unified source of tokens.

There are two exceptions to the above pattern: deposits and withdrawals. In a deposit, a token ID can be created without invalidating a previous token. From a privacy protection perspective, deposits are not anonymous because the association between a given L and the external event that allows adding L (in Tornado Cash, depositing ETH into the system; in Zcash, newly mined ZEC) is public.

In other words, deposits are associated with their past transaction history. In a withdrawal, a nullifier is consumed without adding a new token ID. This may sever the connection between the withdrawal and the corresponding deposit, and indirectly sever the connection to the past transaction history. However, a withdrawal can be associated with any future transactions that occur after the withdrawal event.

The first version of Tornado Cash does not have the concept of internal transfers; it only allows deposits and withdrawals. Later versions, which are still experimental, also allow internal transfers and support various denominations of coins, including support for “splitting” and “merging” operations. We will discuss how to extend the basic privacy-protecting coin transfer system and privacy pool to scenarios with arbitrary denominations in later chapters.

4. ZK-SNARKs in Privacy Pool

The core idea of the privacy pool is that users not only prove that a withdrawal is associated with a previous deposit through zero-knowledge proofs, but also prove that it belongs to a stricter set of associations. The association set can be a subset of all previous deposits made, only containing the user’s own deposits, or any set in between. Users specify the association set by providing the Merkle root of the set as a public input.

As shown in the following figure, for simplicity, we do not directly prove that the association set is indeed a subset of previous deposits made; instead, we require users to use the same coin ID as the leaf node and prove two Merkle branches through zero-knowledge proofs:

● The Merkle branch to the root R of the total coin ID set

● The Merkle branch to the provided association set root RA

The intention of doing this is to place the complete association set somewhere (which can be on-chain). The core concept is: instead of requiring users to accurately specify which deposit their withdrawal is from, or on the other extreme, providing no information other than proving no double spending, we allow users to provide a set of options that could be the source of funds, and this set can be as wide or narrow as they wish.

We encourage the formation of an ecosystem that makes it easier for users to specify a set of associations that align with their preferences. The rest of this article will only describe the infrastructure based on this simple core mechanism and its consequences.

III. Practical Considerations and Use Cases

An analysis of how privacy-enhancing protocols are used in practice.

1. Use Cases of Association Sets

To illustrate the value of this scheme in a law enforcement context, consider the following example:

Suppose we have five users: Alice, Bob, Carl, David, and Eve. The first four users are honest and law-abiding users who value privacy, while Eve is a thief. Because the coins associated with the address labeled “Eve” have been stolen, it is known that Eve is the thief. In practice, this situation often occurs: on the public blockchain, funds generated from exploiting vulnerabilities in DeFi protocols are traced and marked, thus identifying illegal funds flowing into Tornado Cash.

When each of these five users makes a withdrawal, they can choose to specify an association set. Their association set must include their own deposits, but they are free to include deposits from other addresses as well. The motivation for the first four users is twofold: on one hand, they want to protect their privacy to the greatest extent possible. This leads them to prefer larger association sets. On the other hand, they want to minimize the chance of their coins being perceived as suspicious by merchants or exchanges. There is a simple way to achieve this: they do not include Eve in their association sets. Therefore, for the four of them, the choice is clear: they make their association set {Alice, Bob, Carl, David}.

Of course, Eve also wants to maximize the size of her association set. But she cannot exclude her own deposit, so she is forced to make her association set equal to the set of all five deposits. The association set choices of the participants are shown in the following figure.

Although Eve herself does not provide any information, through a simple process of elimination, we can draw a clear inference: the fifth withdrawal can only come from Eve.

2. Construction of Association Sets

The previous section illustrated one possible way to use association sets in a protocol similar to a privacy pool and how honest participants can separate themselves from malicious participants. Note that the system does not rely on the altruism of Alice, Bob, Carl, and David; they have clear incentives to prove their separation. Now let’s take a closer look at the construction of association sets. In general, there are two main strategies for generating association sets. They are described below and visualized in the diagram below.

● Inclusion (or membership): Identify a specific set of deposits that we have concrete evidence to believe are low risk and construct an association set that only includes these deposits.

● Exclusion: Identify a specific set of deposits that we have concrete evidence to believe are high risk and construct an association set that includes all deposits except these.

In practice, users do not manually select the deposits to be included in their associated sets. Instead, users subscribe to intermediaries called Associated Set Providers (ASPs), who generate associated sets with specific attributes. In some cases, ASPs can be fully built on-chain without any human (or AI) intervention. In other cases, ASPs independently generate associated sets and publish them on-chain or elsewhere.

We strongly recommend publishing the Merkle root of the associated set on-chain at the very least; this eliminates the ability for malicious ASPs to perform certain types of attacks on users (e.g., providing different associated sets to different users in an attempt to de-anonymize them). The entire set should be provided via an API or ideally through a low-cost decentralized storage system (such as IPFS).

The ability to download the entire associated set is important because it allows users to locally generate proofs of membership without revealing any additional information to the ASP, or even revealing the deposits corresponding to their withdrawals.

Below are possible ways ASPs could be constructed in practice:

● Delayed addition, excluding bad actors: Any deposit will automatically be added to the associated set after a fixed period of time (e.g., 7 days), but will never be added if the system detects any association with known bad behavior (e.g., large-scale theft or addresses on government-published sanction lists). In practice, this can be achieved through community-curated sets or existing transaction screening service providers that have already performed identification and tracking of deposits related to bad behavior.

● Individual monthly fee: To join the associated set, the value of the deposit must be below a fixed maximum, and the depositor must prove possession of certain identity tokens using zero-knowledge proofs (e.g., government-backed national identity card systems or lightweight mechanisms like social media account verification). A discard symbol mechanism, represented by an additional parameter mixed together, is used to ensure each identity can only submit deposits to the associated set once per month. This design aims to enforce the spirit of many common anti-money laundering rules, where small payments below a certain threshold allow for higher levels of privacy. Note that this can be fully implemented as a smart contract without the need for manual supervision to maintain ongoing operation.

● Trusted community members monthly fee: Similar to the individual monthly fee, but with stricter restrictions: users must prove themselves as highly trusted members of a community. Highly trusted community members agree to provide privacy to each other.

● AI-based real-time scoring: An AI ASP system can provide risk scores for each deposit in real-time, and the system outputs an associated set containing deposits with risk scores below a certain threshold. Potentially, the ASP can output multiple sets corresponding to multiple risk score thresholds.

IV. Further Technical Explanation

In this section, we will analyze how the proposal supports arbitrary denominations and discuss special cases such as re-proving, bilateral direct proofs, and sequential proofs.

1. Support for Arbitrary Denominations

The simplified privacy coin system mentioned above only supports transfers of coins with the same denomination. Zcash supports arbitrary denominations by using the UTXO model. Each transaction can have multiple inputs (which require publishing a commitment for each input) and multiple outputs (which require publishing a token ID for each output). Each created token ID must be accompanied by an encrypted denomination value. In addition to proving the validity of commitments, each transaction must also include additional proofs that demonstrate the sum of the denominations of the created coins does not exceed the sum of the denominations of the spent coins. The diagram below illustrates this additional proof.

This design can be extended to support deposits and withdrawals by treating deposits as (unencrypted) inputs and withdrawals as (unencrypted) outputs. Additionally, for simplicity of analysis, certain restrictions can be imposed. For example, partial withdrawals can be allowed, resulting in a transaction with one encrypted input and two outputs: one unencrypted output representing the withdrawal, and one encrypted “change” output representing the remaining funds for future withdrawals.

A natural question is how to extend this design to support privacy pools. Simply inserting it into a privacy pool as is would not be ideal, as the transaction graph would be inconsistent with our intuitive expectations: if a user deposits 10 tokens and then spends 1 + 2 + 3 + 4 tokens in four consecutive withdrawals, we would expect all four withdrawals to be considered as originating from the original deposit of 10 tokens. However, the actual result is shown in the diagram below: the source of the first withdrawal is the deposit of 10 tokens, and then the source of the second withdrawal is the change output of 9 tokens created by the first withdrawal, and so on. This would cause problems in practice, as it would require ASPs to validate intermediate deposits and add them to their associated sets.

In order for the original deposit of 10 coins to be considered as the source for all four withdrawals in this example, we need to solve two problems:

● Ensure that each partial withdrawal is not publicly linked to other withdrawals

● Allow each partial withdrawal to be a member of the associated set of the deposit

If we only support partial withdrawals and not more complex multi-input multi-output transactions, and ensure that each withdrawal has a single defined corresponding “original deposit”, there are several ways to directly achieve this. One natural and scalable approach is to include a commitment to some information in the transaction. For example, we can require the transaction to include a commitment hash(coinID+hash®), where a random value r is added for blinding purposes, and require a ZK-SNARK proof that the commitment in the transaction is the same as the parent transaction. If the parent transaction is a withdrawal, then the commitment is the same as the original deposit’s coin ID, and if the parent transaction is a deposit, then the commitment is the same as the initial deposit’s coin ID. Thus, every transaction in the chain must include a commitment to the original deposit’s coin ID and provide proof that this value is in the associated set provided by the transaction.

In order to improve the privacy of resisting total balance attacks, we can also support coin merging. For example, if I have some coins left, I can merge them with the next deposit. To accommodate this situation, we can require the transaction pair to commit to a set of coin IDs and require the transaction with multiple inputs to commit to the union of its parent transactions. A withdrawal will include proof that all committed coin IDs belong to its associated set.

2. Special Cases

● Reproving: Users need secret deposit information to extract deposits similar to privacy pool protocols. The same secret information is also used to construct proofs of association set membership. Keeping the secret information allows users to generate new proofs to accommodate different sets or updated association sets. This gives users greater flexibility but may also bring additional risks.

● Bilateral Direct Proofs: In certain cases, users may need to disclose the exact source of a withdrawal to another party. Users can create an association set that only includes their own deposits and generate proofs against that set. These proofs are usually exceptional cases and contribute to partial privacy only when shared between parties. However, sharing proofs requires strong trust assumptions.

● Sequential Proofs: In a fast transaction economy that uses a privacy pool system, the protocol needs to be modified to accommodate this environment. In addition to deposit and withdrawal transaction types, the protocol also needs to support internal send operations to improve efficiency. Furthermore, by passing Merkle branches and keys, users can propagate information related to transaction history for the recipient to verify the source of funds. This ensures that each user receives the minimum information necessary to have confidence in the received funds.

In practice, a token may have multiple “sources”. For example, Bob is a coffee stall owner who receives 5 tokens from Alice, 4 tokens from Ashley, and 7 tokens from Anne, and at the end of the day, he needs to pay Carl 15 tokens for dinner. In contrast, David may receive 15 tokens from Carl, 25 tokens from Chris, and want to deposit 30 tokens to Emma (an exchange). In these more complex cases, we follow the same principle: historical data that has been added to the association set early enough can be ignored, while newer data needs to be continued to be passed on.

5. More Details

A system similar to a privacy pool can allow users to gain more protection in terms of the privacy of their financial transaction data while maintaining the ability to separate proofs from known illicit activities. We expect that honest users will be incentivized to participate in this scheme by a combination of two factors:

● Desire for privacy

● Desire to avoid suspicion

1. Social Consensus and Association Set

If there is complete consensus in judging the quality of funds, the system will produce a simple separation balance. All users who possess “good” assets have a strong incentive and ability to prove that they belong to a “good only” associated set. On the other hand, bad actors will be unable to provide this proof. They can still deposit “bad” funds into the pool, but it will not benefit them in any way. Everyone can easily determine that the funds are extracted from a privacy-enhancing protocol and see that the withdrawal refers to an associated set that includes deposits from suspicious sources. More importantly, “bad” funds will not contaminate “good” funds. When funds are withdrawn from legitimate deposits, their owners can simply exclude all known “bad” deposits from their associated set.

In the case of global consensus and where the conclusion about whether funds are considered “good” or “bad” depends on social views or jurisdictional conclusions, there may be significant differences in the associated sets. Suppose there are two jurisdictions with different sets of rules. Entities under jurisdictions A and B can both use the same privacy-enhancing protocol and choose to issue proofs that satisfy their respective jurisdictional requirements. Both can easily achieve privacy within their own associated sets and exclude withdrawals that do not comply with their respective jurisdictional requirements. If necessary, proof of membership can be issued for the intersection of the two associated sets, reliably demonstrating that the deposits corresponding to their withdrawals meet the requirements of both jurisdictions.

Therefore, this proposal is highly flexible and should be seen as neutral infrastructure. On the one hand, it resists censorship. It allows anyone to join their chosen associated set and maintain privacy within their own community. On the other hand, external parties can request proof for specific associated sets that comply with their regulatory requirements. Thus, even in a community with a bad actor in the privacy-enhancing protocol, as long as the information accurately reflects the construction of the associated set, they will be unable to conceal the suspicious origin of the deposits.

2. Attributes of associated sets

The associated sets need to have certain attributes in order to be effective. The sets need to be accurate so that users can trust that they can safely use the funds after withdrawal. In addition, the attributes of each set should be stable, meaning that they are less likely to change over time. This reduces the need to re-validate withdrawals for new sets. Finally, in order to achieve meaningful privacy protection, associated sets should be large enough and contain various types of deposits. However, these characteristics conflict with each other. Generally, larger and more diverse sets may have better privacy attributes, but they may be less accurate and stable, while smaller sets are easier to maintain but offer less privacy.

3. Practical considerations and competition

Regulated entities that accept cryptocurrencies must ensure that the laws and regulations they are subject to allow them to accept such funds. Today, many of these entities rely on so-called transaction screening tools: software or services that analyze the blockchain to identify potential suspicious activities, connections to illegal addresses, or other non-compliant transactions. Screening tools often express the risk associated with each transaction through a risk score. This score is based on the destination of the funds and their transaction history. In this regard, privacy-enhancing protocols may present challenges. They eliminate the visible link between deposits and withdrawals. Therefore, in the presence of privacy-enhancing protocols, risk scores need to consider proofs and allocate scores based on associated sets.

The tools and services for transaction screening are mainly provided by professional companies that have expertise in blockchain analysis and related legal fields. Ideally, these companies (as well as anyone else) should have access to all membership proofs and their corresponding associated collections in order to provide accurate risk scoring for all transactions. Therefore, we recommend that all proofs be stored in a blockchain or other publicly accessible proof repository. The only exception is membership proofs shared with specific counterparties, which should not be publicly available for obvious reasons.

Storing proofs directly on the chain would incur additional transaction costs, but it would reduce coordination efforts, make competition fairer, and mitigate the potential quasi-monopoly risks that screening tool providers may pose by having knowledge of non-public proofs.

The general settings of privacy pools are highly flexible. By creating specific associated collections, the protocol can be customized for various use cases. Here are two examples of these special associated collections:

● A commercial bank consortium can create an associated collection that only includes its customers’ deposits. This can ensure that any proof created for withdrawals from this collection has undergone Know Your Customer (KYC) and Anti-Money Laundering (AML) procedures at one of the participating banks, without revealing which withdrawal belongs to which customer.

● In cases where financial intermediaries need explicit records of the source of funds, they can request users to provide proofs for an associated collection that only includes the users’ deposits. This proof can then be exchanged bilaterally with the intermediary, allowing them to trace the funds as if the user had never used the privacy pool. While this requires users to trust the intermediary not to disclose the proofs, ideally it enables users to comply with regulations without having to disclose information to the public.

4. Design Choices and Alternative Approaches

The settings based on associated collections, zk-proofs, and voluntary disclosures are highly flexible. While this is useful for ensuring that the proposal can accommodate different jurisdictions, specific design choices should be made with caution. In particular, there are two potential adjustments that we oppose as they raise trust requirements and may lead to a quasi-monopolistic market structure. Below, we briefly describe and discuss these alternative approaches:

● Centralized access: Law enforcement agencies, cryptographic risk scoring providers, or similar participants can be granted permission to view the links between user transactions while keeping others’ privacy intact.

● System-wide whitelisting: The privacy system can restrict the types of users who can deposit coins into its pool, requiring them to provide additional proof or requiring deposits to wait for a period of time during which a centralized risk scoring system can reject the deposit.

These two approaches are similar in that they grant specific entities privileges. This would raise complex governance issues: Who can access this information? Who has the power to manage permissions? Private companies do not seem like a good choice as any privileges could create an oligopolistic market structure where a few companies have access to the data necessary to provide these services while others cannot compete.

Similarly, when granting power to public institutions, there will be many governance and political issues, especially in an international environment. Even if an institution is 100% trustworthy, does not abuse power for political agendas, and does not rely on other entities that may force it to abuse power, this situation is a manifestation of a static state. Over time, organizations, members, countries, and political structures within organizations will change. There may be external pressures, and the existence of these privileges may create additional incentives to disrupt and gain influence over the organization’s governance system.

In addition, attacks from within or outside the organization, or errors made by centralized entities, can have far-reaching consequences. We believe that the creation of such centralized points of failure should be prevented.

Having said that, we recognize that different transaction sizes and circumstances may require different combinations of proofs. For example, for large transactions, many users may eventually provide basic exclusion proofs on the chain and provide more detailed information about the source of funds to their counterparts.

5. Directions for Further Research

While this paper provides an overview of how zkSNARK-based privacy-enhancing protocols can be used in regulated environments, there are several aspects that deserve further research.

First, it is important to be aware that the privacy obtained through these protocols depends on many different factors. Attackers may be able to associate withdrawals with specific deposits based on insufficiently large correlation sets, improper root selection, and user errors.

In addition, the choices made by other users can have adverse effects on your own privacy. In extreme cases, all other participants in the pool may publish a membership proof of size one, revealing direct links between their deposits and withdrawals. Obviously, this implicitly reveals links between the remaining unique deposit and withdrawal transactions. In a more subtle example, constraints from various membership proofs can be used to extract information and potentially correlate deposits and withdrawals with a high probability. Once this information from the proofs is combined with transaction metadata, the privacy properties of the protocol may be compromised.

Lastly, malicious ASPs can choose to compile the proposed correlation set in a way that allows them to extract the most information or increase perceived anonymity by adding deposits that correspond to known withdrawals. All of these issues need further research to evaluate the privacy properties provided. In a similar vein, it would be interesting to further research the separation of balance properties, modeling the behavior of good and bad actors under specific assumptions, and how the public proofs from the former affect the privacy of the latter.

Legal experts can further study specific disclosure requirements. The scheme proposed in this paper is highly flexible, and insights from legal experts can help tailor the protocol and the ecosystem built around it to ensure compliance in various legal jurisdictions.

6. Conclusion

In many cases, privacy and compliance are considered to be conflicting. This article proposes that if privacy-enhancing protocols allow users to prove certain attributes of their fund sources, this may not necessarily be the case. For example, suppose users can prove that their funds are not associated with known illegal deposits or prove that these funds are part of a specific deposit collection without revealing any further information.

Such a setup can create a separation equilibrium, where honest users are strongly incentivized to prove that they belong to a compliant associated collection and maintain privacy within that collection. Conversely, dishonest users are unable to provide such proof. This allows honest users to disassociate themselves from third-party deposits they disagree with or prevent them from using funds in a compliant environment. We believe that this proposal is highly flexible and can be adjusted according to various potential regulatory requirements.

This article should be seen as a contribution to the potential coexistence of financial privacy and regulation in the future. We hope to facilitate discussions and steer the conversation towards a more positive and constructive direction. Collaboration between practitioners, scholars from various disciplines, decision-makers, and regulatory bodies will be required to expand and modify this proposal; its ultimate goal is to create privacy-enhancing infrastructure that can be used in a regulated environment.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!