Buterin’s latest paper: How does the privacy pool protocol protect user privacy and meet compliance requirements?

原文：《Blockchain Privacy and Regulatory Compliance: Towards a Practical Equilibrium》

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

Compiled by: Odaily Planet Daily Husband How

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

The paper describes a new privacy-enhancing protocol based on smart contracts - privacy pool, discusses its advantages and disadvantages, and shows how it balances honest users and dishonest users. The protocol is designed to use zero-knowledge proofs to verify the legitimacy of user funds without revealing their full transaction history, balancing privacy and regulatory requirements while filtering out funds associated with criminal activity.

Odaily Planet Daily now compiles the essence of the paper as follows.

I. Introduction

Public blockchains are transparent by design. The basic idea is that anyone can choose to verify transactions without having to rely on a centralized third party; 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 standpoint, public datasets own every transaction containing every blockchain address. Whenever someone transfers an asset to another address, or interacts with a smart contract, that transaction will always be visible on the blockchain. This clearly does not comply with privacy requirements.

Example: Alice pays for dinner at a restaurant with a blockchain wallet. The payee now knows Alice's address and can analyze all past and future activity at that address. Likewise, Alice now knows the restaurant's wallet address and can use this information to get other guests' wallet addresses or to check the restaurant's earnings. Or a third party (such as social media) who knows the restaurant and Alice's wallet address can easily deduce Alice's actual residential address and study her past and future transactions.

**The rise of privacy-enhancing protocols is to solve the above problems. 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 are still visible on the blockchain, but the correspondence between specific transfers and transfers is no longer public. **

One of the most well-known privacy-enhancing protocols is Tornado Cash. It successfully solves the above problems and allows users to retain some privacy. However, in addition to legitimate users trying to protect their data, Tornado Cash is also used by a variety of bad actors. Deposit data shows that the hacker group moved funds through this protocol. There is evidence that this privacy-enhancing protocol is also used by North Korean hacking groups, ultimately resulting in the protocol’s smart contract addresses being placed on the list of Specially Designated Nationals and Blocked Persons maintained by the U.S. Office of Foreign Assets Control (OFAC) (often referred to as the SDN list) ).

**The key problem with Tornado Cash is the blurred line between legitimate users and criminal users. **Therefore, Tornado Cash offers a compliance feature that allows users to create a proof of which deposit a given withdrawal came from. While this mechanism does allow people to prove their innocence, it does so at the cost of having to trust a centralized intermediary and creating information asymmetries. Ultimately, the mechanism was used by few users.

This paper discusses an extension of this approach that enables users to publicly attest to information about which deposits their withdrawals may have come from, without losing privacy. **Privacy Pools proposes a general concept: allow proof of membership ("I certify that my withdrawal came from one of these deposits") or proof of exclusion ("I certify that my withdrawal did not come from any of these deposits") . **This article discusses this proposal and explains how it can be used to achieve a balance between honest and dishonest users.

Note that privacy pools provide additional options by extending the user's action set. They can still provide more detailed proof to a specific counterparty if required. In some cases, however, proof of membership or exclusion may be sufficient. Additionally, the option of publicly releasing these certifications offers a number of advantages over bilateral disclosure.

2. Technical background

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

1. Blockchain privacy before ZK-SNARKs

Historically, blockchain proponents have argued that while all transactions are transparent, blockchains can preserve privacy because they provide anonymity.

With the advent of modern clustering and analysis tools, this privacy protection has become insufficient. To improve the privacy of public blockchains, stronger techniques such as token joins and Monero have been introduced. However, these technologies still carry the risk of data leakage. **

Then came the emergence of general-purpose zero-knowledge proof technologies, such as Zcash and Tornado Cash, which can make the anonymity set of each transaction equal to the entire set of all previous transactions. This technique is often called ZK-SNARKs.

2、 ZK-SNARKs

ZK-SNARKs are a technique that allows a prover to prove a certain mathematical claim about public and private data while satisfying two key properties: zero-knowledge and simplicity. **

● Zero-knowledge: No information about private data will be revealed except to prove that said private data conforms to the claims.

● **Simplicity: **Proofs are short and can be verified quickly, even if the proven claims require time-consuming computations.

ZK-SNARKs have received a lot of attention from the blockchain community because of their scalability significance, such as ZK-rollups. For privacy applications, simplicity is not particularly important, but zero-knowledge is essential.

The "statement" of a ZK-SNARKs proof can be thought of as a type of program called a "circuit" that computes the result of a function f(x, w) with public and private inputs, and then proves that for a given public input x , there is a private input w such that the result of f(x, w) is True.

3. Application of ZK-SNARKs in systems such as Zcash and Tornado Cash

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

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

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

● NullifierU = hash(s + 2)

Among them, hash (hash) refers to a password hash function, such as SHA 256. Given s, the token ID and zeroizer can be computed. However, given a set of zeroizers and a public token ID, the pseudo-random behavior of the hash function ensures that you cannot determine which zeroizer is associated with which token ID unless you know the secret s that generated both.

The blockchain tracks all token IDs that have been "created", as well as all zeroizers that have been "spent". Both sets are constantly growing (unless the protocol wants to enforce when tokens must be spent).

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

Given a specific value in a tree and a root hash, you can provide a Merkle branch: "sister values" that are hashed together at every step on the path from that value to the root. This Merkle branch is very useful because it is a small (log 2(N) hashes) piece of data that can be used to prove that any particular value is actually in the tree. The figure below shows an example of a Merkle tree with a height of 4.

When users send coins to others, they provide the following:

● The zerizer U you want to spend

● Token ID L' of the new token desired to be created (recipient is asked to provide this)

● A ZK-SNARK.

ZK-SNARK contains the following private inputs:

● user's secrets

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

It also contains the following public inputs:

● U, the zeroizer of the token being spent

● R, the root hash that the Merkle proof is targeting

ZK-SNARK proves two properties:

● U = hash(s + 2)

● The Merkle branch is valid

In addition to ZK-SNARKs, the protocol checks for the following:

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

● U is not in the set of spent zeroizers

If the transaction is valid, it adds U to the set of spent nilifiers and L' to the list of token IDs. Showing U prevents a single token from being double spent. However, no other information will be disclosed. **The outside world can only see when transactions were sent; they have no way of obtaining a pattern of who sent or received those transactions, and no way of distinguishing a unified source of tokens. **

There are two exceptions to the above pattern: deposits and withdrawals. In a deposit, token IDs can be created without invalidating some previous token. Deposits are not anonymous from a privacy perspective because of the association between a given L and an external event that allows the addition of L (in Tornado Cash, depositing ETH into the system; in Zcash, new mining ZEC) is public.

In other words, **deposits are tied to their past transaction history. **On withdrawals, one Zeroizer will be consumed without adding a new token ID. This may disconnect withdrawals from the corresponding deposits and indirectly from past transaction history. However, withdrawals can be linked to any future transactions that occur after the withdrawal event.

The first version of Tornado Cash had no concept of internal transfers, it only allowed deposits and withdrawals. Later versions, still in the experimental stage, also allowed internal transfers and coins of various denominations, including support for "split" and "merge" operations. We will discuss how to extend the basic privacy coin transfer system and privacy pool to 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 the withdrawal is associated with a previous deposit through zero-knowledge proof, but also prove that it belongs to a more strict association set. **The associated collection can be a subset of all deposits previously made, a collection containing only the user's own deposits, or anything in between. Users specify the set by providing the Merkle root of the associated set as a public input.

As shown in the figure below, for the sake of simplicity, we do not directly prove that the associated set is indeed a subset of the deposits made previously; instead, we only require the user to use the same coin ID as a leaf node to prove two Merkle branches through zero-knowledge:

● Enter the Merkle branch of the root R of the total coin ID set

● Enter the Merkle branch of the provided association set root RA

The intent of this is to put the full set of associations somewhere (could be on-chain). The core concept is: instead of requiring users to specify exactly which deposit their withdrawals came from, or at the other extreme, not provide any other information other than proving there were no double spends, we allow users to provide a set of options from which the funds may have come, And this collection can be as wide or narrow as they wish.

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

3. Practical considerations and use cases

Analyze how privacy-enhancing protocols are used in practice from an application perspective.

1. Use cases of associated collections

To illustrate the value of this program in a law enforcement environment, here is an example:

Suppose we have five users: Alice, Bob, Carl, David, Eve. The first four users are honest, law-abiding but privacy-conscious users, while Eve is a thief. Because the public knows that Eve is a thief through the information that the coins in the address marked "Eve" were stolen. In practice, this often happens: on public blockchains, funds generated due to exploits of DeFi protocol vulnerabilities are tracked and tagged to identify illegal funds flowing into Tornado Cash.

When each of the five users makes a withdrawal, they can choose which associated set to specify. Their association set must include their own deposits, but they are free to choose which of the other addresses to include. The first four users were motivated on the one hand by wanting to protect their privacy to the greatest extent possible. This motivates them to tend to make their association set larger. On the other hand, they want to reduce the chance of their coins being viewed as suspicious by merchants or exchanges. There's an easy way to do this: they don't include Eve in their associated collection. Therefore, for the four of them, the choice is clear: let their association set be {Alice, Bob, Carl, David}.

Of course, Eve also wants to maximize her association set. But she cannot exclude her own deposits, so she is forced to have her associated set equal to the set of all five deposits. The associated collection selection of participants is shown in the figure below.

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

2. Construction of associated collections

The previous section illustrated one possible way to use associated sets in a protocol similar to a privacy pool, and how honest participants can be separated from bad ones. Note that the system does not rely on the altruism of Alice, Bob, Carl, and David; they have clear incentives to justify their separation. Let's now look at the construction of associated collections in more detail. In general, there are two main strategies to generate associative collections. They are described below and visualized in the figure below.

● **Inclusion (or Membership): **Identifies a specific set of deposits that we have strong evidence to consider to be low risk, and builds an associated set that includes only those deposits.

● Exclude: Identify a specific set of deposits that we have strong evidence to consider to be high risk and construct an association set that includes all deposits except those deposits.

In practice, users do not manually select deposits to include in their associated collection. Instead, users will subscribe to intermediaries we call Association Collection Providers (ASPs), which generate association collections with specific properties. **In some cases, ASPs can be built entirely on-chain, requiring no human (or AI) intervention. In other cases, ASPs will generate the associated collection independently and publish the associated collection on-chain or elsewhere.

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

The ability to download the entire association collection is important because it allows users to generate proof of membership locally without revealing any additional information to the ASP, not even the deposits corresponding to their withdrawals.

Here's how ASPs might be built in practice:

● **Delayed addition to exclude bad actors: **Any deposit is automatically added to the associated collection after a fixed amount of time (eg 7 days), but if the system detects that a deposit is associated with known bad behavior (eg large-scale theft or an address on a government-published sanctions list), the deposit will never be added. In practice, this could be achieved through community-curated collections or existing transaction screening service providers that have already performed the work of identifying and tracking deposits associated with bad behavior.

● Single Person Monthly Fee: In order to join the associated collection, the value of the deposit must be below some fixed maximum, and the depositor must prove with zero knowledge that they hold some identity token (e.g. by a government Supported national ID systems or lightweight mechanisms such as social media account verification). Mixed in with an additional parameter representing the current month's scrapper mechanism to ensure that each identity can only submit deposits to the associated collection once per month. The design attempts to implement the spirit of many common AML rules, whereby micropayments below a certain threshold allow for a higher level of privacy. Note that this can be implemented entirely as a smart contract, requiring no manual oversight to maintain ongoing operation.

● **Trusted Community Member Monthly Fee: **Similar to single person monthly fee, but more restrictive: users must prove they are members of a highly trusted community. Highly trusting community members agree to provide privacy to each other.

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

4. Further technical description

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

1. Support any denomination

The simplified privacy protection coin system above only supports coin transfers of the same denomination. Zcash supports arbitrary denominations by using the UTXO model. Each transaction can have multiple inputs (need to publish the zeroizer of each input) and multiple outputs (need to publish the token ID of each output). Each token ID created must be accompanied by a cryptographic denomination value. In addition to proving the validity of the zeroizer, each transaction must be accompanied by additional proof that the sum of the denominations of the coins created does not exceed the sum of the denominations of the coins spent. The figure 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, the design can be restricted to simplify analysis. For example, it is possible to only allow partial withdrawals, allowing a transaction to have one encrypted input and two outputs: an unencrypted output representing the withdrawal, and an encrypted "change" output representing the remaining funds that can be used for future withdrawals.

A natural question is how to extend this design to support privacy pools. Inserting it unchanged into a privacy pool is not ideal because the transaction graph does not match what we intuitively expect: if a user deposits 10 tokens, then spends 1+2+3+4 in four consecutive withdrawals tokens, we want to treat each of these four withdrawals as the source of the original 10 token deposit. But the actual result is shown in the figure 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 analogy. This causes problems in practice because it requires ASP to validate the intermediate deposit and add it to its associated collection.

In order for all four withdrawals in this example to be able to have the original 10 coin deposit as their source, we need to solve two problems:

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

● Allow each partial withdrawal to include a deposit as a member of its associated collection

If we only support partial withdrawals, rather than more complex MIMO transactions, and ensure that each withdrawal has a single defined corresponding "origin deposit", there are multiple ways to do this directly. A natural and scalable approach is to propagate the promise of some information through transactions. For example, we could require transactions to contain a commitment hash (coinID+hash®) with some random value r added to ensure blinding, and require ZK-SNARKs to prove that the commitment in the transaction is the same as its parent transaction. If the parent transaction is itself a withdrawal, the commitment is the same as the original deposit's coin ID, and if the parent transaction is a deposit, the commitment is the same as the original deposit's coin ID. Therefore, every transaction in the chain must contain a commitment to the original deposit coin ID and need to prove that this value is in the associated set provided by the transaction.

To improve privacy against balance aggregation attacks, we can also support coin merging. For example, if I have some coins left over, I can merge them with it on my next deposit. To accommodate this, we can require transactions to commit to a set of coin IDs, and require transactions with multiple inputs to commit to the union of their parents. A withdrawal will contain proof that all of its committed coin IDs are in its associated set.

2. Special circumstances

● Re-certification: Users need secret deposit information to withdraw deposits similar to privacy pool protocols. The same secret information is also used to construct proofs of association set membership. Preserving secret information allows users to generate new proofs to fit different sets or updated associated sets. This gives users greater flexibility, but may also introduce additional risks.

● Bilateral Direct Proof: In some cases, users may be required to disclose the exact source of withdrawals to the other party. Users can create an associated collection containing only their own deposits and generate proofs against that collection. These proofs are usually the exception and only contribute to partial privacy when shared between two parties. However, shared proofs need to establish strong trust assumptions.

● Proof of Sequence: In a fast transaction economy using a system like a privacy pool, the protocol needs to be modified to adapt to this environment. In addition to deposit and withdrawal transaction types, the protocol also needs to support internal send operations to increase efficiency. Additionally, by passing Merkle branches and keys, users can propagate information related to transaction history so that recipients can verify the origin of funds. This ensures that each user has the minimum information they need to have confidence in the funds they receive.

In practice, a coin may have multiple "origins." For example, Bob is a coffee stall owner, he receives 5 tokens from Alice, 4 tokens from Ashley, 7 tokens from Anne, and at the end of the day he needs to pay Carl 15 tokens to pay for dinner. Instead, David may have received 15 tokens from Carl, 25 tokens from Chris, and wants to deposit 30 tokens to Emma (an exchange). In these more complex cases, we follow the same principle: history that has been added to the associated collection long enough ago can be ignored, while newer history needs to be passed on.

Five, more details

A system like a privacy pool could allow users to gain more protection in the privacy of their financial transaction data while maintaining the ability to prove separation from known illegal activity. We expect that honest users will be incentivized to participate in such a scheme through a combination of two factors:

● Desire for Privacy

● Desire to Avoid Arousing Suspicion

1. Social consensus and association collection

If there was complete consensus on whether funds were good or bad, the system would produce a simple separating equilibrium. All users with “good” assets have a strong incentive and ability to prove that they belong to a “good-only” association set. Bad actors, on the other hand, will not be able to provide this proof. They can still deposit "bad" funds into the pool, but it won't do them any good. Everyone can easily determine that funds were withdrawn from a privacy-enhanced protocol and see that withdrawal references an associated collection containing deposits from questionable sources. What's more, "bad" money doesn't taint "good" money. When funds are withdrawn from legitimate deposits, their owners can simply exclude all known "bad" deposits from their associated collection.

Where there is a global consensus, and conclusions about whether funds are considered "good" or "bad" depend on societal views or jurisdictions, sets of associations can vary widely. Suppose there are two jurisdictions with different sets of rules. Subjects in both jurisdictions A and B can use the same privacy-enhancing protocol and choose to issue certifications that meet the requirements of their respective jurisdictions. Both can easily achieve privacy within their own associated collections and exclude withdrawals that do not comply with the requirements of their respective jurisdictions. If desired, a proof of membership can be issued for the intersection of two associated sets, thus reliably proving that the deposit corresponding to its withdrawal complies with the requirements of both jurisdictions.

Therefore, the proposal is very flexible and should be considered as neutral infrastructure. On the one hand, it fights censorship. It allows anyone to join an affiliated collection of their choice and remain private within their own community. On the other hand, outsiders can request certification for a specific set of associations that meet their regulatory requirements. Thus, even if there is a community of bad actors in a privacy-enhancing protocol, they will not be able to conceal the suspicious origin of deposits as long as the information is accurately reflected in the construction of the associated set.

2. Properties of associated collections

Associative collections need to have certain properties to function. Collections need to be accurate so that users can trust that they are using their withdrawn funds safely. Furthermore, the properties of each set should be stable, i.e. less likely to change over time. This reduces the need for revalidation withdrawals on new collections. Finally, to achieve meaningful privacy protection, the association set should be large enough and contain various types of deposits. However, these properties conflict with each other. In general, large and diverse collections may have better privacy properties but may be less accurate and stable, while smaller collections are easier to maintain but provide less privacy.

3. Practical considerations and competition

Regulated entities that accept crypto assets must ensure that the laws and regulations they are subject to allow acceptance of such funds. Today, many of these entities rely on so-called transaction screening tools: software or services that analyze the blockchain to identify potentially suspicious activity, links to illegitimate 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 transferred funds and their transaction history. In this regard, privacy-enhancing protocols can pose challenges. They eliminate the visible link between deposits and withdrawals. Therefore, in the presence of privacy-enhancing protocols, the risk score needs to take the attestation into account and assign a score based on the set of associations.

Tools and services for transaction screening are mainly provided by professional companies with expertise in blockchain analysis and related legal fields. Ideally, these firms (and anyone else) would have access to all membership certificates and their corresponding associated collections to provide accurate risk scores for all transactions. Therefore, we recommend that all proofs be stored on the blockchain or other publicly accessible proof repository. The only exception is a membership certificate of size one shared with a specific counterparty. For obvious reasons, these testimonials should not be made publicly available.

Storing proofs directly on-chain adds additional transaction costs, but reduces coordination efforts, makes competition fairer, and mitigates quasi-monopoly risks that screening tool providers may create due to knowledge of non-public proofs.

The general setup of a privacy pool is very flexible. By creating a specific collection of associations, the protocol can be tailored to various use cases. Here are two examples of these special association collections:

● **A commercial banking federation can create an associated set that contains only deposits from its customers. **This ensures that any withdrawals created with proof of the collection have undergone know-your-customer (KYC) and anti-money laundering (AML) procedures at one of the participating banks, but does not reveal which withdrawal belongs to which customer .

● **In cases where financial intermediaries are required to clearly document the source of funds, they can require users to provide proof against an associated set that only contains user deposits. **This proof will then be exchanged bilaterally with the intermediary, allowing them to track the funds as if the user never used the privacy pool. While this requires users to trust the intermediary not to reveal proof, ideally it enables users to comply with regulations without having to disclose the information to the public.

4. Design choices and alternatives

Very flexible setup based on association collections, zk proofs and voluntary disclosures. While this is useful in ensuring that the proposal can be adapted to different jurisdictions, great caution should be exercised regarding specific design choices. In particular, there are two potential adjustments that we oppose. We believe they have problems with trust requirements and may create quasi-monopolistic market structures. Below we briefly describe and discuss these alternatives:

● Centralized access: Law enforcement agencies, crypto risk scoring providers, or similar actors can gain access to view links between user transactions while maintaining privacy from others.

● **System-wide whitelisting: **Privacy systems can place restrictions on the types of users who can deposit coins to their pools, requiring them to provide additional proof or requiring deposits to wait for a period of time during which centralized The risk scoring system can reject deposits.

The two methods are similar in that they grant privileges to specific entities. This raises complex governance questions: Who has access to this information? Who has the power to manage permissions? A private company does not seem like a good option, as any privilege would likely create an oligopolistic market structure, with a few companies having access to the data that would provide these services, while others would not be able to compete.

Likewise, there are many governance and political issues to face when empowering public institutions, especially in an international setting. Even if an institution is 100% trustworthy so far, will not abuse its power to pursue a political agenda, and is not dependent on other entities that might compel it to abuse its power, this situation is a manifestation of stasis. Organizations, members, countries, and political structures within organizations change over time. There may be external pressure, and the existence of these privileges may create additional incentives to disrupt and gain influence over the organization's governance systems.

Additionally, attacks inside or outside the organization, or errors on behalf of a centralized entity, can have far-reaching consequences. We believe the creation of such centralized points of failure should be prevented.

Having said that, we acknowledge that different transaction sizes and situations may require different combinations of proofs. For example, for large transactions, many users may end up providing basic proof of exclusion on-chain and providing more detailed information about the source of funds to their counterparties.

5. Direction of in-depth research

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

First, everyone needs to realize that the privacy achieved through these protocols depends on many different factors. An attacker may be able to associate withdrawals with specific deposits based on an insufficiently large association set, poor root selection, and user error.

In addition, choices made by other users may adversely affect your own privacy. In extreme cases, everyone else in the pool would publish a proof of membership of size one, revealing a direct link between their deposits and withdrawals. Obviously, this would implicitly reveal the link between the only remaining deposit and withdrawal transactions. In a more subtle example, constraints from various proofs of membership can be used to extract information and potentially correlate deposits and withdrawals with high probability. Once these attested information is combined with transaction metadata, the privacy properties of the protocol may be compromised.

Finally, a malicious ASP could choose to compile the proposed association set in a way that allows them to maximize the extraction of information or increase perceived anonymity by adding deposits where corresponding withdrawals are known. All these issues require further research to evaluate the privacy properties provided. In a similar vein, it would be interesting to further investigate the properties of separating equilibria, modeling how good and bad players behave under certain assumptions and how public proof of the former affects the privacy of the latter.

Legal experts can further research specific disclosure requirements. The scenarios presented in this paper are flexible, and insights from legal experts can help tailor the agreement 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 in conflict. This paper proposes that this is not necessarily the case if a privacy-enhancing protocol enables users to prove certain properties of their source of funds. For example, it is assumed that users can prove that their funds are not linked to deposits from known illicit sources, or that the funds are part of a specific collection of deposits, without revealing any further information.

Such a setup can produce a separating equilibrium where honest users are strongly incentivized to prove that they belong to some compliant associative set and maintain privacy within that set. On the contrary, for dishonest users, they cannot provide such proof. This enables honest users to disassociate themselves from third-party deposits they disagree with, or prevent them from using their funds in a compliant environment. We believe that the proposal is very flexible and can be adjusted according to potential various regulatory requirements.

This article should be viewed as a contribution to the potential future coexistence of financial privacy and regulation. We hope to stimulate discussion and steer the conversation in a more positive, constructive direction. Collaboration between practitioners, academics from various disciplines, policymakers and regulators will be required to expand and revise this proposal; the ultimate goal is to create privacy-enhancing infrastructure that can be used in regulated environments.