The implications of the smart contract sanctioning by OFAC and how the community is responding.

This article covers the sanctioning of the Tornado Cash contract, some of the biggest risks to the Ethereum network, and the community’s response. Although important, the article does not cover why we need privacy as that’s already covered in many other places.

What happened?

The Office of Foreign asset controls (OFAC) is a branch of the US Treasury focused on applying financial pressure to “threats to the national security, foreign policy or economy of the United​ States”. On August 8th, the US Treasury OFAC sanctioned for the first time in history, not a person or a company, but a piece of autonomous software running on the Ethereum blockchain by placing the Tornado Cash’s contract address on the OFAC sanctions list. The Tornado Cash (TC) contract is an open source, nondiscriminatory privacy tool for anonymizing financial data on the open blockchain. Shortly after this announcement, 75k USDC in the TC contract was frozen, Infura and Alchemy began censoring transactions to TC, the TC Github repository and accounts of contributors were deleted, the TC Discord was taken down, and one of the project’s developers was arrested in the Netherlands.

The Ethereum community has since been puzzled from the ambiguity of putting a piece of code on a sanctions list. What does this mean for a smart contract (non-person) to be sanctioned? Is it illegal to distribute this code? Can the code be shared via t-shirt, book or song? Is it illegal to interact with an address which has interacted with Tornado Cash? What if the address received Tornado Cash withdraw unwillingly? What if the address is a smart contract or a centralized exchange? Any way you draw the line that doesn’t include 70%+ of the industry, there will be a trivial way around it for criminals.

Cascading Sanctions

Already the centralized components of dapps and centralized exchanges are feeling the chilling effect. Uniswap, Aave, DYDX, Balancer and Etherscan front-ends have begun blocking users out of fear of government crackdown (30 years in prison and up to several millions USD in fines). This fear could extend to any infrastructure provider running inside the US (or allied nations) who knowingly or unknowingly facilitate in the violation of sanctions. Because of the unprecedented ambiguity in the sanction’s meaning, it’s hard to know how far down the tech stack this censorship is expected to go. Here’s a list of layers who all help facilitate the transmission of criminal transactions:

• Centralized front-ends
• Protocol developers
• Transaction relayers
• Block producers
• Block validators
• Ethereum developers
• Cloud providers
• Internet service providers
• Internet standards bodies
• Cryptographers
• Computer manufacturers
• …

Based on recent behavior, it seems that the first three are responsible for censoring traffic associated with TC, but it’s unclear where the community is supposed to draw the line. There’s a real risk that enforcement becomes overly aggressive and Ethereum validators in the US become pressured to censor TC transactions. Let’s take a look at how this would play out…

The first type of censorship that a validator can perform is to ignore censored transactions (whatever that means) from the mempool, essentially refusing to include these transactions in blocks they produce. This is a pain for users as they’ll need to wait longer for a non-censoring validator to produce a block, but they will eventually be able to get it through. The second type of censorship is to ignore block signing altogether for blocks that include a censored transaction. This is much more dangerous as a majority percentage of censoring validators can effectively silence and slash the uncensoring minority, and turn Ethereum into a highly regulated chain. Such an outcome is unlikely as it would require a massive amount of coordination across many actors; however it is particularly unsettling because centralized services (exchanges, stablecoins, and oracles) can all be coopted onto the regulated chain by threats from a government. So, what’s a community to do? There are three types of responses in the works from the Ethereum community: legal, technical, and nuclear.

Community Responses

Legal

On the legal side, the goal is to set precedence that both modernizes regulation and disambiguates the rules for everyone. Most of the community is in full support for the use of precise scalpels for cutting out black-hat hackers and bad actors, but OFAC’s current policy is a crude bludgeon, doing more damage to the host than good. Coincenter is a long-time advocate for reasonable regulation and has been trying to give the government better tools for protecting its citizens. They’ve put together a great response demonstrating how the actions of OFAC are likely illegal and unconstitutional; providing a case for those that wish to take the battle to court. Only through a court ruling will we see disambiguation of the existing sanctions law which can finally provide some long overdue assurance for the builders and infrastructure providers in the space.

Technical

In 2014, Apple and Google began encrypting mobile storage such that they no longer had backdoor access. This broke the status quo and upset government agencies, however so far this technical architecture has held up in court. Today, Ethereum validating clients will both build (compile) and produce (sign) a block, implying they’d have the ability* to check each transaction prior to signing it. We can provide block producers with the ability to sign blocks without knowing the contents that they contain by separating the block builder from the block proposer (aka Proposer Builder Separation - PBS). With PBS, the block proposer would simply sign the block header and only discover the block contents later. This does move the censorship problem to the block builders; however these entities can more easily operate outside OFAC controlled nations. If encrypted mobile storage has already set similar precedence, then this intentionally-oblivious architecture may hold up in court. It is important to introduce this into Ethereum sooner than later, as it sets PBS as the status quo and prevents censors from getting too comfortable with the existing design.

*How technically feasible is it for a validator to censor transactions in a highly adversarial environment? It may not actually be possible as Moody Salem has pointed out in this thread. By censoring transactions to certain contracts/individuals, it opens the censoring validator open to a griefing attack. A valid transaction can be constructed in such a way to force censoring validators to miss blocks due to how long it takes to figure out if the transaction should be censored or not. However, this type of counterattack doesn’t work for all types of censorship as a validator can still “freeze” an Ethereum account by ignoring all transactions that originate from that address.

Another possible technical solution is to do nothing at the base layer and rely upon rollups to fight the censorship fight for the community. With ZKRollups, the Mainnet rollup contract is given a proof of valid state transition but doesn’t need to know the individual transactions that occurred in the rollup. This provides plausible deniability for Mainnet block producers as they cannot peek inside the contents of the rollup state change. Unfortunately, this pushes the problem to rollups which many as of today are not fully decentralized in block production, making them vulnerable to regulation.

Nuclear

Finally, there is the negative-sum, nuclear option which is least ideal for all players involved called social slashing. In the case of provable censorship by block producers, the Ethereum community can come together and create either a softfork (UASF) or hardfork to manually slash the stake from offending parties. A softfork would cause the community to consider the minority chain to be official and rely upon the built-in slashing mechanism to bleed out the censoring validators. A hardfork would do the same, but additionally be able to instantly slash the stake to censoring validators and remove them from the validating pool. This is extremely difficult to coordinate as it’s a mechanism intentionally not baked into the base protocol; however it acts as a catch-all for malicious behavior that goes against the ethos of the community. This is not desirable from the community’s perspective as it can divide the network into competing subchains and penalize well-intentioned actors that are unwillingly subject to regulation. Lefteris Karapetsas and Eric[a] Wall posed the question of whether the Ethereum community would be ready to slash a majority of validators in the case of censorship. Similar to nuclear weapons, this type of threat from the community must be perceived as real to deter an attack, even if it would ideally never be used. The community needs to demonstrate unity and willingness to use this option for defense. In response to the thread, Brian Armstrong has signaled that he’d rather shut down Coinbase’s staking service than be forced to censor blocks. While this is optimistic, we must continue working on the problem as the censorship threat, although unlikely, still looms over the community. It’s often the business interests of corporations that have the power to steer court and political outcomes and the nuclear solution leverages this pressure directly.

Going forward

This OFAC sanction has energized the community to take previously theoretical censorship threats and the need for decentralization seriously. This sanctioning act may backfire and lead to new precedence that disambiguates the role of decentralized protocols providing better privacy and thoughtful regulation that encourages growth in the industry OR we may be faced with cascading regulation that diminishes Americans’ access to open, permissionless finance… the outcome is still undecided.

Action items

• Donate to Coincenter.eth or the Electronic Frontier Foundation.
• Evaluate the censorship risk in your own portfolio ($RAI > $USDC, Ledger > Coinbase).
• For developers:
  • Make it easier for users to run/access decentralize apps (example).
  • The flashbots relayer is currently centralized and has committed to censoring transactions. Build an alternative relayer that validators can use.
  • Build apps on Aztec or Starknet or help them become more decentralized.
• Follow and RT these people to keep up with the latest on these fronts: @ameensol, @ercwl, @koeppelmann, @lefterisjp, @micahzoltu, @valkenburgh, @zac_aztec @zooko