Tornado.cash and the Future of On Chain Privacy

(originally posted on Substack)

August 8th, 2022, the Office of Foreign Asset Control (“OFAC”) updated the Specially Designated Nationals (“SDN“) List to include a series of Ethereum addresses associated with the Tornado Cash protocol.

August 10th, 2022, a Tornado.cash developer was arrested in Armsterdam and was announced by Netherland’s Fiscal Information and Investigation Service (FIOD).

Shortly after the OFAC announcement, Tornado.cash developer Roman Semenov tweeted that his Github repo as well as Tornado.cash’s github repos was taken down by Microsoft. Subsequently, Tornado.cash as well as the sanctioned addresses was rejected by DeFi protocols like Aave, dydx, RPC providers like Infura, stable coin issuers like Circle.

What is Tornado.cash and How does Tornado.cash work?

Tornado.cash is a mixer for ETH and ERC20 tokens. It allows users to deposit ETH/ERC20 into the mixer and withdraw the same amount of token in the future. Below is how it works:

Deposit: A user can deposit a fixed nomination of tokens (to make it simple, 0.1 ETH in the diagram, Tornado.cash has 1ETH, 10 ETH, and 1,000 ETH tier as well), and gets a unique secret for the deposit (a.k.a. secrete note). Upon the deposit, 0.1 ETH is transferred from the user’s account to Tornado.cash’s contract on Ethereum.

Withdraw: A user withdraws 0.1 ETH from Tornado.cash contract to a new address by feeding the tornado.cash dApp with her secret note. Under the hood, tornado.cash dApp generates the zero-knowledge-proof using the secret note to prove the validity of the deposit. Tornado.cash’s contract then verifies the zero-knowledge-proof on chain. Due the the verifiability of the zero-knowledge-proof, a double spending or malicious withdraw can never happen. Due to the zero-knowledge property of zero-knowledge-proof, as long as the user withdraw to a new address, linkage between the deposit and withdraw account is shielded by the Tornado.cash contract mixer pool and the zero-knowledge-proof.

Who are using Tornado.cash?

There is a perceived stereotype to regard Tornado.cash as “hacker’s money laundering” tool. I would argue this stereotype mostly comes from the biased media coverage: when hacker are using Tornado.cash for washing the hacked assets, it appears in the news; when totally legal and well justified usage of Tornado.cash, it never appears in the news! Let’s look at Chainanalysis’s breakdown of Tornado.cash’s usage (source):

Roughly 10.5% of Tornado.cash’s usage are stolen funds, the majority of the tornado.cash usage is on DeFi, CEX transferring funds, avoid Sanctions, etc. In fact, since the Tornado.cash sanction news break out, many users expressed why they are using Tornado.cash. For example, Vitalik expressed that he has been using Tornado.cash to do anonymous donate:

The Future of On Chain Privacy

The entire web3 revolution meaningless without privacy. It is really hard to argue how web3 en-power each individual’s sovereignty without privacy and how web3 escape the surveillance capitalism future without privacy.

Direction 1: Build better product for casual users, not just hackers

It is almost impossible to absolutely prevent bad actors in a permission-less system. However, we should build better product for casual users but not just hackers. I would like to quote @dankrad’s tweet here:

Two product features that Tornado.cash’s design that are not exactly friendly for casual users are:

• Until Tornado.cash Nova, users have to use fixed nomination (0.1 ETH, 1ETH, 10 ETH, 100 ETH), which creates significant UX friction.

• Tornado.cash requires huge gas fee in L1. A tornado.cash deposit is about 1m gas on Ethereum. So 0.05 ETH at 50 GWEI, 0.1 ETH at 100 GWEI. The scale of the gas fee is not exactly friendly to the casual users.

Luckily, both 1 and 2 have a good technical solutions. Protocols like ZCash/Tornado.cash Nova/MantaPay doesn’t require fixed nomination. And the gas fee issue will also be much mitigated via deploying privacy solution on L2 or even building privacy specific L2 like ZKOPRU.

Direction 2: More Privacy Killer Applications

Use cases of privacy is Web3 are well beyond wrapping tokens to privacy tokens. In fact, from a user point of view, the fact that the she need to wrap the public tokens to private to gain privacy and need to unwrap them back to public to get usage is a bad UX. A normal user should just use the private tokens “as is“, and using it in many different Web3 applications.

(Privacy use cases, credit: Brandon Gomes)

In fact, in many applications, privacy is a necessity rather than just good to have. For example:

DeFi: Financial privacy is one of the high-value use cases. Many users avoids using DeFi because of the fully transparent transaction history. In addition, private DeFi could potentially mitigate the MEV (entirely avoiding MEV is still a hard research problem).

NFT: Using NFT as PFP is one of biggest privacy leakage (directly leaking the link of pseudo-anonymous public address and user’s identity). Private NFT/ seal bid NFT auction/ zero-knowledge-proof based attestation can make the NFT ownership more private without losing any utilities.

DAO tooling: As the future of human organization, privacy is much needed in many aspects of DAO tooling, for example, private voting is needed to avoid high tension and voter retaliation, private payroll system is needed to keep a healthy organization, private message board is needed for internal anonymous feedback. The list of private DAO tooling need is endless.

Interactive on chain game: If a game needs to be settled on-chain, each player needs to hide her state in general, otherwise there will be a huge MEV problem of the game. If we would like to build an open metaverse on chain, privacy is a must rather than optional (see Geometry Research’s mental poker framework).

Direction 3: Opt-in Configurable Asset Policy and Zero-Knowledge-Proof based Compliance

As the web3 world moving forward, we also need to build better tooling to enable the crypto asset issuer can define various asset policy, including compliance. One possible direction is to use zero-knowledge-proof to solve the tension between the compliance and user’s sovereign privacy.

However, the build a sensible asset policy, the web3 assets issuers and the regulators need to work together to build sensible and implementable asset policies.

Example: Espresso system's CAPE design.

It goes without saying, the future of web3 privacy requires the combination of all these directions above.