Privacy without proceeds of crime
The recent paper Blockchain Privacy and Regulatory Compliance: Towards a Practical Equilibrium written by Vitalik Buterin, Jacob Illum, Matthias Nadler, Fabian Schär and Ameen Soleimani is a valuable contribution to the discussion about privacy on a public blockchain with safeguards to ensure that the proceeds of crime cannot flow through the mechanisms.
I explored this topic in a blog post Appropriate transparency vs privacy? in the wake of the OFAC sanctioning of Tornado Cash. At the heart of the issue was the ability of hacker groups to launder the proceeds of crime through the protocol to obfuscate the origin of funds. The reaction was understandable, namely, close the protocol and chase those involved in the name of stamping out money laundering. There were innocent people caught up, those with a legitimate need to preserve their privacy. I made the point that full transparency comes with a total loss of privacy with the example of buying a newspaper enabling the shopkeeper to link my address with my identity. The shopkeeper knowing my address can see my entire financial history and equally I can also look at the shopkeepers transaction history, find their best customers etc. This is also a point made in the paper on privacy giving an example of Alice goes to a restaurant and uses her blockchain wallet to pay for dinner with the same observations.
I take a more nuanced approach by asking how we balance privacy and transparency. Before we introduce a standard, there should be a discussion about what do we need to make transparent and what needs to be private? Is it acceptable to have transparency on incomes, and privacy on how that income is spent or saved/invested? Or is there a strong case for complete privacy? We have sort of privacy in the incumbent systems although we are not entirely sure who has our data and how much they know about us.
The Blockchain Privacy and Regulatory Compliance paper introduces the idea of using Zero Knowledge Proofs as a mechanism to create accountability with inclusion and exclusion lists. In an earlier blog post I explored Trusted Circles and Verifiable Credentials in Tgrade as a way of decentralising identity, in ensuring that the verified credentials are a legitimate way to create a Trusted Circle (or permissioned group).
Let’s consider a Trusted Circle, that implemented SSID was the foundation of a regulatory compliant group. The mechanisms enabling transfers can be managed in a private way using smart contracts permissioned to the group to ensure privacy. The voting participants of a Trusted Circle, who are the people that created the Trusted Circle, do not know the identities of the addresses of the participants as this is protected by SSID, thus do not have superpowers that could be abused.
How can this be put in place?
Tgrade has layers of safeguards through the implementation of Proof of Stake, the Trusted Circle mechanisms are part of the Tgrade protocol and are self-sovereign. The freedom to implement a Trusted Circle allows the necessary customisation free from centralised control at the protocol level.
The implementation of the SSID and verified credentials is decided by the creators of a Trusted Circle. There is also the flexibility of implementing multiple Trusted Circles around various jurisdictions as not all laws are the same.
The smart contract that contains the privacy or mixing functionality can be implemented across all Trusted Circles as required. Importantly the permissioning is done at a Trusted Circle level, so that participants in one Trusted Circle can freely transact, privately, with each other.
The people or organisations create their own rules and terms of use around Trusted Circles which is important, especially around managing the origin of funds. What mechanisms need to be in place to balance privacy and ensure that the proceeds of crime cannot find their way into the Trusted Circle? The organisation may require a holding address and a time gap between depositing and being able to use the funds in a Trusted Circle, or have similar procedures for the withdrawl of funds.
Why is this not implemented in Tgrade?
Tgrade is a level one blockchain with robust layers to ensure decentralisation along with the governance framework for Trusted Circles.
The design of Trusted Circles was that they are self-sovereign and as such it was envisaged that people, organisations, and companies would build innovative applications on the infrastructure provided.
A group of interested participants, could (or should!) get together to implement a privacy group powered by SSID, Trusted Circles and smart contracts. The result would be a secure, private and compliant application running on Tgrade.
