Decentralized Code Vs Censorship
A Tornado Cash Case Study
Editors note: originally published in the November 2024 BTCTKVR Magazine: Privacy Edition—bitcoin-takeover.com
Launched in 2019 by a team of developers led by Roman Semenov & Roman Storm, Tornado Cash is an Ethereum-based privacy tool for anonymizing on-chain wallet transfers through zero-knowledge proofs. The depositor generates a zk-SNARK secret, consisting of a commitment and a proof, at the browser level and sends the commitment with their deposit to a Tornado Cash pool. Each pool is a unique smart contract designed to accept deposits of a uniform currency and denomination. The depositor can then track the number of deposits in the pool (the anonymity set) along with the number of deposits made since their initial deposit and, once a suitable level of anonymity is reached, request a withdrawal to a new wallet by supplying the previously generated proof.
As an additional layer of privacy, users can request withdrawals through a third-party relayer. Relayers help users withdraw directly to a fresh wallet without having to potentially compromise anonymity by funding the wallet for contract gas fees. Relayers charge a small, agreed upon fee for their services and deduct the expense directly from the user’s withdrawal.
To facilitate relayer services and provide user experience benefits, developers created a layer of proxy contracts maintained by a community DAO. All transactions made via the official UI pass through the proxy to their appropriate pools. However, users can choose to bypass the proxy and interact with Tornado Cash pools directly using their own or a third-party UI.
A Brief Outline of Events
Following a special zk-SNARK Trusted Setup Ceremony audited by the NCC Group, Tornado Cash was made fully trustless on May 20th, 2020. The Trusted Setup Ceremony involved setting the operator address for all pool instances to the null address (0x000…), making the core contract pools for Tornado Cash unmodifiable. In a Medium article published after the ceremony, a Tornado Cash contributor wrote, “From now on, Tornado.cash is largely living by the precepts that code is law. The Tornado.cash smart contracts are running on Ethereum and the community has the decision on whether or not to use our tools” [1].
On August 8th, 2022, the U.S. Office of Foreign Assets Control (OFAC) sanctioned Tornado Cash as a virtual currency mixer, alleging ties to the North Korean Lazarus hacking group [2]. Forewarning the decision, OFAC had previously sanctioned Bitcoin mixer Blender.io on the grounds of similar ties to North Korea. In the Blender.io statement, OFAC promised it was “committed to exposing components of the virtual currency ecosystem, like Blender, that are critical to the obfuscation of the trail of stolen proceeds from illicit cyber activity” [3].
Conventional entities, including traditional mixers such as Blender.io, invite little confusion as to who or what is being sanctioned. But Tornado Cash represents autonomous code, and the interconnected nature of blockchain infrastructure prevents straightforward interpretation. Under the ambiguous language of the OFAC sanction, potentially every Ethereum user, node operator, and block validator could be held liable for propagating Tornado Cash.
The months following proved to be a trial-by-fire for claims of uncensorability made by Tornado Cash, Ethereum, and blockchain technology broadly. As a case study, Tornado Cash can help developers think through the design problems and tradeoffs that censorship-resistant building requires—especially privacy building, which, above others, can be expected to attract the scrutinizing eye of censoring forces.
What Tornado Cash Did Right
At the protocol level, censorship happens when a design feature or bug is exploited to prevent users from interacting with the protocol (design failure), or when the protocol is “captured” through a governance or hardware take-over (decentralization failure). Protocols that are built to effectively mitigate these failures are said to be permissionless and decentralized respectively, and their resilience to censorship attacks can be evaluated on the basis of these two axioms.
Following are permissionless design decisions made by the Tornado Cash developers that helped the protocol survive OFAC censorship pressures:
- Locked, autonomous core contracts
By locking the core pool contracts, the developers ensured the primary functionality of Tornado Cash could not be compromised. This critical foresight is the principal reason Tornado Cash is still operating today despite the failure of several second-layer functions.
- Decentralized file storage frontend hosting
The official Tornado Cash UI was hosted on IPFS: a decentralized peer-to-peer file sharing protocol. Content uploaded to IPFS cannot be edited and is given a unique hash code that identifies its location on the IPFS network. While the original domain, Tornado.cash, was revoked by the domain registrar and is no longer accessible, users could still access the official UI frontend via the IPFS hash.
- Limited upgradeability through proxy contracts
By limiting upgradeable features of Tornado Cash to a second layer proxy, Tornado Cash avoided the trap of favoring decentralized governance over permissionless design while also providing an avenue for DAO efforts to continue improving and maintaining the protocol.
Decentralization is accomplished by distributing influence over product vulnerabilities as maximally as possible. Effective decentralized design decisions made by the Tornado Cash developers include:
- Limited DAO bound by a coded constitution
DAOs in practice have notoriously underdelivered on their theoretical promises. Coded constitutions, like Tornado Cash had, force rules, such as on-chain voting and a monetary lock-up requirement for submitted proposals, to be followed programmatically. Amidst a contracting environment of DAO participation, these limiting features prevented Tornado Cash contract changes from being exercised by a minority coalition of compromised voters.
- Vesting control of frontend UI assets in a DAO
Maintaining the UI required centralized security of Tornado.cash and the Ethereum native tornadocash.eth. The DAO was charged with securing current registration on both these domains and protecting their redirect destinations. While Tornado.cash did not withstand censorship, tornadocash.eth proved to be an invaluable asset for providing users trusted access to a reliable UI amidst a minefield of scams. Maintaining the integrity of tornadocash.eth despite a rapid drop-off of DAO participation is a notable success of the DAO as a decentralization effort.
What Went Wrong
Despite best efforts, the government sanctions tested both the strength of the protocol’s permissionless design and the resilience of its decentralization efforts in a variety of ways:
- Censorship by domain name and hosting providers
Least surprising, frontends prove to be a critical failure point in censorship-resistant building. While still accessible via IPFS, the official UI could not be called via traditional web browsers within hours of the sanction announcement.
- Loss of human capital
The Tornado Cash DAO all but dematerialized as longtime developers fled in the face of legal threat. In one instance, a multisig wallet holding tornadocash.eth along with DAO treasury funds was briefly in peril as elected multisig stewards scrambled to sever ties. (By August 14th the governance contract was in full control and no assets were lost.)
- Loss of DAO communication / collaboration channels
If the loss of core contributors wasn’t enough, critical DAO collaboration channels including the DAO forum, Discord server, and Github were all swiftly taken offline. Committed contributors worked without financial incentive on Telegram and, later, an Element server to keep the project alive; a testament to their commitment, but not the financial participation incentives of the DAO, which proved entirely unreliable and a brutal flaw in censorship-resistant building.
- Ethereum network censorship
An RPC endpoint is required for the browser-based Tornado Cash UI to interact with on-chain content. By default, the UI employed two popular Ethereum RPCs: Infura and Alchemy. Both censored calls from Tornado Cash following the sanction. Finding alternative RPCs that supported Tornado Cash became increasingly difficult as censorship pressures spread.
An even greater threat: Ethereum edged dangerously close to ecosystem-wide censorship of Tornado Cash due to the functional design of its block approval process, which relies on block builders, relayers, and validators to choose the transactions that are finalized in a new block and, by extension, the transactions that are not. In November 2022, block censorship reached its highest point when a record 78% of Ethereum blocks were reported to be OFAC compliant [4].
- Censorship by dependent third parties including The Graph
To build a cryptographic withdrawal, Tornado Cash requires the assembly of a Merkle tree of all previous contract transactions. The tree is generated at the UI level and provides part of the zero-knowledge proof contract pools require to tie a withdrawal to a deposit. For building efficiency, Tornado Cash relied on a cache of indexed transactions from another supposedly decentralized protocol: The Graph. By mid-September, it became apparent that The Graph was censoring Tornado Cash indexing. This move that broke the UI and halted withdrawals for weeks while independent developers rebuilt the UI without the dependency.
Takeaways for Future Developers
Tornado Cash serves as a valuable case study for developers who prioritize privacy preservation and censorship-resistant code. While not perfect in every way, it is worth noting that Tornado Cash is still a working, privacy-preserving protocol on Ethereum despite massive, social and legal pressure. This is a testament to the foresight of the original developers and those who, despite potentially devastating legal and reputational risk, contributed to updates that ensured its survival through a wave of dependency failures.
Various lessons can be taken from the trials of Tornado Cash. Here are three:
First, decentralized governance cannot replace the security offered by permissionless design. The failures of the Tornado Cash DAO and the near-failure of the entire Ethereum protocol illustrate that social pressures will challenge decentralized models in ways that permissionless code is immune to.
Second, frontend user interfaces remain a significant vulnerability in censorship-resistant design. Builders should use all the options available to them, including browser-accessible decentralized file storage protocols such as IPFS and decentralized identity alternatives to DNS. However, further research and development in this crucial area is urgently needed.
Finally, contrary to typical thinking, freedom of choice is not always conducive to censorship-resistant building. In the case of Ethereum, providing block builders the option to pick and choose which transactions end up in final blocks implies a responsibility for the transactions chosen. A scenario where block builders cannot choose the transactions that make it into final blocks would remove the layer culpability social censorship requires.
Privacy is a human right says the Tornado Cash slogan [5]. For all who agree, happy building!
Figure 1 Tornado Cash v3 Contract Flow
Sources:
1. “Tornado.cash Is Finally Trustless!,” Available at: https://tornado-cash.medium.com/tornado-cash-is-finally-trustless-a6e119c1d1c2
2. “U.S. Treasury Sanctions Notorious Virtual Currency Mixer Tornado Cash.” Available at: https://home.treasury.gov/news/press-releases/jy0916
3. “U.S. Treasury Issues First-Ever Sanctions on a Virtual Currency Mixer, Targets DPRK Cyber Threats,” Available at: https://home.treasury.gov/news/press-releases/jy0768
4. MEV Watch, Available at: https://www.mevwatch.info/
5. Current Tornado Cash protocol information available at: https://tornadocash.social/