Configurable Privacy Case Study: Partitioned Privacy Pools
By: Ben Fisch
In wake of the US Treasury department sanctioning Tornado Cash (TC), people (including myself) have resurfaced the idea that users of privacy protocols like TC can use zero-knowledge proofs to demonstrate that their withdrawals are not transactions from sanctioned entities. The goal is to provide an alternative way to implement sanctions without entirely banning privacy protocols like TC or requiring an institution to have full transparency. This idea has been floating around for some time in the blockchain community, and has recently reentered the spotlight (e.g., here and here at minute 35). In fact, a similar application of zero knowledge proofs was discussed as early as 2013 in the context of TOR. Here’s my take on this idea, some practical challenges, and potential solutions. This post does not express any opinion on sanctions, but rather a proposal for how Treasury could achieve their same stated goal in a less invasive way. While applicable to risk management more broadly, this post focusses on the SDN List example for sake of concreteness.
What is the SDN list? The Specially Designated Nationals List of the US Treasury’s Office of Foreign Assets Control (OFAC) contains sanctioned entities, their operating companies, bank accounts, or cryptocurrency addresses, with which anyone subject to US law is prohibited from transacting.
How dynamic is the SDN list? Couldn’t an illicit actor evade sanctions by simply moving funds to a new freshly generated cryptocurrency address? Entities and persons with sufficient ties to the U.S. jurisdiction are expected to take reasonable measures to avoid transacting with, or providing goods or services to, sanctioned entities, even if it is a related bank account, entity, property, or cryptocurrency address that does not explicitly appear on the SDN List. Since blockchains are public ledgers, it is easy to see the movement of funds from an SDN address to a new one in real time and thus compliant institutions (e.g., exchanges) can easily block these as well. It is more difficult to trace the origin of funds after several hops, but several blockchain analytics companies offer this more complex risk analysis via software-as-a-service to institutions.
How does TC work (approximately, at a high level)? TC can be used to move funds from one public Ethereum address to another while hiding the link. Specifically, it hides the links between deposits into and withdrawals from the TC pool. Depositing a certain amount into the TC pool creates an on-chain digital receipt, and the depositor retains a secret key needed to use this receipt later. A user withdraws a certain amount from the pool by presenting a zero-knowledge proof that it knows the secret key of an unused receipt for this exact amount, and a keyed hash of the receipt called a “nullifier”, which still hides the receipt but prevents it from being used twice.
Why might TC impact SDN compliance? According to Treasury’s press release, TC “facilitates anonymous transactions by obfuscating their origin, destination, and counterparties, with no attempt to determine their origin.” An institution can see that an Ethereum address received funds withdrawn from TC, but it could not easily tell if those funds were originally deposited into TC from a sanctioned address, or a high-risk address that traces to a sanctioned address upstream. As a result, in practice, many institutions began labeling everything coming from TC as higher risk, even before OFAC officially designated the TC pool address. At risk of stating the obvious, while TC may be seen by compliant institutions as creating provenance risk, it provides little incremental benefit to risky actors who cash out at non-compliant exchanges that are not screening in the first place.
How can selective disclosure help? Just as withdrawals from TC require zero knowledge proofs about the deposit receipt to which they are uniquely linked, a diligent institution can require a prospective customer with funds withdrawn from TC to disclose more information about this deposit receipt, such as non-membership on the SDN list or even a risk score upper bound of the origin address. This can be done via a zero-knowledge proof if there is a published list of risk scores for all addresses that ever deposited into TC. Chainalysis and TRM Labs both already provide on-chain oracles for the wallet addresses that have been published on the SDN List. For maximum efficacy, the present proposal requires the more complex risk analysis of related (e.g., co-spending) addresses to be published on-chain as well.
Should this disclosure be on-chain? In the case that a customer holds funds labeled as high-risk because they trace to an upstream TC withdrawal that the customer is not responsible for, they may be unable to prove an upper bound on the risk score. Automating the risk score disclosure of TC withdrawals through a designated smart contract that verifies the proofs helps avoid this situation. Users have an incentive to automatically disclose that their withdrawn assets have low risk as it positively impacts the liquidity of these withdrawn assets.
How will this disclosure impact privacy? Put simply, it partitions the anonymity set of withdrawals into high-risk and low-risk association with the SDN. There is some dependency of privacy on behavioral conventions. Users who prove their withdrawals are low-risk are clearly anonymous among the set of other users who do the same, but even if there is only one user who opts into revealing their risk level they are not necessarily revealing their identity (unless it is already known who this one person is). This becomes problematic for privacy if, for example, there are multiple risk scoring conventions or even multiple SDN lists that are each correlated with a particular group of users (e.g., a jurisdiction). In this case, a user’s decision of which SDN list to reference in their proof reveals their association with a particular user group. This is perhaps the greatest pragmatic challenge of this proposal.
Would this corner the illicit actors into a smaller anonymity set? Not necessarily, but I argue that it does not matter for SDN compliance. If there is a universal SDN list and risk scoring convention, and all but a small fraction of users in the low-risk category with respect to this list opt into disclosing their risk level, then indeed the users in the high-risk category will be squeezed into one anonymity set. However, consider a scenario in which there are two SDN lists A and B and half the users elect to prove non-association with A while the other half use B. Any actor who is only included on list A can still prove non-membership on list B and thus belongs to an anonymity set comprising half of all users. However, they would still be unable to pass compliance screening at an exchange that requires non-association with list A. What matters in practice is not the theoretical size of the anonymity set but the fact that institutions can set their own screening requirements, and this in turn will drive what users elect to selectively disclose.
Could illicit actors move funds quickly to evade this? Someone might quickly move funds from an SDN-listed address A to a fresh address B, deposit into a TC pool, and immediately withdraw to address C before the oracle has time to assign high risk to B, enabling them to prove a low-risk score for C. There are two potential solutions. The first is to simply regard all fresh addresses as high-risk until otherwise assigned. Put another way, if a deposit source address has not yet received a risk score from the on-chain oracle then the user withdrawing will be unable to produce a zero-knowledge proof of any score, and thus the withdrawal would be de facto labeled as high-risk. Alternatively, the zero-knowledge proof of a low-risk score verified by the smart contract could also prove that the referenced deposit receipt is at least some sufficiently large number of blocks old. This has minimal impact on anonymity and usability. For maximum privacy, due to the deanonymizing capabilities of pattern analysis, a user should anyhow wait a randomly distributed amount of time before withdrawing from the pool.
In summary, this approach would enable users withdrawing from TC to preserve liquidity by facilitating downstream compliance screening, while otherwise remaining anonymous within the pool of other transactions that have low-risk association with the SDN List. The zero-knowledge scoring also maintains the ability of end points to conduct risk management. It is just as effective in stopping sanctioned wallet addresses, but without the same collateral impact on licit users as a blanket sanction on everything that engages the TC smart contracts.
Espresso Systems, which launched a product called CAPE (Configurable Asset Privacy for Ethereum) earlier this year, is creating an ecosystem for blockchain applications with flexible privacy. Whether you are a developer, VASP, regulatory agency, analytics service, or general user of blockchain privacy tools, please get in touch if you are interested in learning more about how we can meet the needs of both privacy and risk management or exploring collaboration. Follow us on Twitter or join us on Discord for more.
