📚 Author: Chris Truax Esq.🌟 Technical Prerequisite: Low/Moderate
Thanks for reading the Stanford Blockchain Review! Subscribe to support our work in pioneering a dedicated industry journal for Web3
Introduction
Blockchains and smart contracts have the potential to re-invent many of the ways the world does business. In order to fulfill that potential, blockchains, above all, must be reliable. But as they are currently implemented, smart contracts contain a previously-unrecognized flaw that could cause the collapse or fragmentation of the blockchains on which they reside.
Much as the internet before it, blockchain technology promises a new way of interacting, free of centralized control. Public blockchains, by their very nature, are intended to operate outside of both governmental and private control.
But this is a myth. While blockchains may operate beyond the direct control of the state, the servers that maintain the blockchain – known as nodes – and the people that run them, do not. Both the nodes and the people have physical locations and, as a consequence, are subject to the laws of the countries in which they reside.
We are already seeing some of the consequences of this. For example, many blockchain startups have found themselves running afoul of the U.S. Securities and Exchange Commission for offering what are, under U.S. law, unregistered securities [1]. Cryptocurrencies themselves have been indirectly regulated by national governments through tax laws almost since their invention [2]. And after the recent scandals involving Three Arrows Capital, FTX, Coinbase and Binance, more direct regulation by nation states is just a matter of time.
Smart contracts represent a more insidious threat. While the cryptocurrency space will be regulated going forward, i.e. new regulations will be applied to future transactions, smart contracts create the risk of “retroactive” regulation. In other words, cryptocurrencies can choose to alter future behavior in response to regulations. Blockchains, however, may find smart contracts have irrevocably committed them to future actions even if those actions subsequently become regulated or even forbidden.
Smart Contract Authority Conflicts
One of the hallmarks of a properly-implemented smart contract is that it cannot be unilaterally altered. In fact, unless it is so designed, it cannot even be altered with the consent of the parties. But actions being performed by a smart contract that are perfectly legal today may not be legal tomorrow. A Smart Contract Authority Conflict (SCAC) occurs when a smart contract performs an action that is illegal under the laws of the place where the server running a blockchain node is physically located.
How this might occur is most easily illustrated via a hypothetical. The Swiss Children’s Fund issues a popular series of NFTs that include a smart contract transferring a 10% royalty to the Swiss Children’s Fund whenever one of the NFTs is resold. Two years later, the U.S. Government designates the Swiss Children’s Fund as a terrorist organization [3] and sends notices to the blockchain’s nodes located in the U.S. – and their service providers – informing them of the designation and threatening prosecution if they participate in any further transactions benefitting the Swiss Children’s Fund.
Subsequently, one of these NFTs changes hands and the smart contract executes, transferring 10% of the proceeds to the Swiss Children’s Fund. The transaction is validated by all the blockchain’s nodes, including the ones located in the United States. As a result, the operators of the U.S. nodes are criminally prosecuted for providing material support [4] to a designated terrorist organization [5].
The SCAC Trap
How will blockchain participants avoid this kind of legal liability? First, nodes will begin building in a compliance function [6] that identifies illegal transactions as part of the verification process. Unless you can identify an illegal transaction, you cannot avoid executing it.
Obviously a miner – a node assembling a new block of transactions – cannot execute an illegal smart contract transaction without facing potential legal consequences. Once equipped with a compliance function, however, a miner has a relatively easy and non-disruptive method of avoiding liability. Since miners pick and choose which pending transactions to include in a new block, they can simply choose not to process transactions they have identified as violating any national laws to which the miner is subject. This does not directly affect the blockchain at all because the transaction remains in the pool and can be processed by another miner.
But when a miner does eventually process this transaction, it becomes a source of potentially fatal instability. In our example above, let us say that a Swiss-based node – the Swiss Children’s Fund is not considered a terrorist organization in Switzerland – eventually includes the transaction in a block. But any nodes – more specifically any node operators – based in the United States may face criminal prosecution for assisting in completing the transaction by verifying the block [7]. Depending on how many nodes are located in the United States and the specific consensus protocols in use by the blockchain, this will result in anything from having no effect at all to the blockchain’s effective collapse. In some cases, these transactions may become impossible to execute because the blockchain’s incentive system will prevent miners from selecting it from the pool even if the miner is not prohibited from executing the transaction under its own national laws.
In the case of Ethereum for example, 2/3rds of the total staked Ether must agree on a set of blocks to achieve “finality.” If more than 1/3 of total validators either go off-line or refuse to validate a specific block, the block cannot be finalized. Ethereum addresses this problem by eventually applying a penalty [8] that reduces the Ethereum stake of the nodes that are offline or are refusing to validate until the “uncooperative” nodes hold less that 1/3 of the total staked Ether which then allows the remaining nodes to validate the block and finalize the chain [9].
In our example, if more than 2/3rds of the “voting” power, i.e. the staked Ether, is held by validating nodes outside the U.S., the Swiss Children’s Fund transaction can be validated without the help of U.S.-based validators. If, however, more than 1/3 of the staked Ether is held by validating nodes based in the U.S., the transaction cannot be validated without financially penalizing U.S.-based nodes.
This may only make the legal compliance problem facing the blockchain’s participants worse. To put it another way, in our example, the Ethereum block chain is attempting to coerce U.S.-based participants into participating in an illegal transaction. In addition to creating a disincentive to participating in the blockchain, this may create larger legal problems. Threatening to harm someone financially unless they engage in illegal activity is a violation of multiple state and federal laws. [10]
Avoiding the SCAC Trap
Because they can appear long after the creation of the smart contracts that cause them, SCACs threaten even the most established blockchains. Worse, once a SCAC appears, it may be too late to address the problem. Fortunately, there are anti-SCAC soft-fork protocol changes that blockchains can implement.
One solution is to provide nodes with the option of flagging a problematic transaction and voting “present” when asked to validate a block that contains such a transaction. Voting “present” would incur no penalty and the blockchain would treat the node as having withdrawn from the blockchain for that validation cycle. As a result, the total number of concurring nodes needed to reach consensus would decrease. Once the validation cycle is completed, the nodes voting present would “rejoin” the blockchain and simply accept the current state of the blockchain just as an offline node does when it comes back online.
To maintain reliability and avoid creating a situation where it is easier to validate illegal transactions than legal ones, the blockchain might also create a rule specifying that when a specific transaction is flagged by 51% of the nodes, the transaction is deemed rejected and is removed from the transaction pool.
Left unresolved, a SCAC represents a threat to the stability of any blockchain in which it appears. Blockchain developers need to recognize that, as smart contracts become more widely used, they will create compliance issues for individual blockchain nodes even if the blockchain as a whole can generate sufficient consensus to process a problematic transaction. Blockchains show great promise. But if they are to fulfill that promise, blockchains cannot force participants to choose between maintaining their good standing in the blockchain and complying with local laws.
Thanks for reading the Stanford Blockchain Review! Subscribe to support our work in pioneering a dedicated industry journal for Web3
About the Author
Chris Truax is a California-based attorney with an international practice advising and representing technology startups. Extravagantly overeducated, Chris has degrees from the University of California, Notre Dame, and the University of Cambridge.
References
[1] See e.g. SEC v. Kik Interactive Inc., 492 F. Supp. 3d 169 (S.D.N.Y. 2020) https://casetext.com/case/us-sec-exch-commn-v-kik-interactive-inc
[2] See e.g. Rev. Rul. 2019-24, 2019-44 I.R.B. 1004, I.R.S. Notice 2014-21, 2014-16 I.R.B. 938. https://www.irs.gov/pub/irs-drop/n-23-34.pdf
[3] 8 U.S.C. §1189. https://www.law.cornell.edu/uscode/text/8/1189
[4] “[M]aterial support . . . means any property, tangible or intangible, or service, including . . . financial services” 18 U.S.C. § 2339A(b)(1). https://www.law.cornell.edu/uscode/text/18/2339A
[5] 18 U.S.C. § 2339B. https://www.law.cornell.edu/uscode/text/18/2339B
[6] Such a compliance function might take a variety of forms depending on local regulatory requirements. It might, for example, screen proposed transactions against a list of sanctioned wallet addresses that have been designated by the government with legal jurisdiction over the node.
[7] 18 U.S.C. § 2339B. https://www.law.cornell.edu/uscode/text/18/2339B
[8] Known as the “Inactivity Leak” protocol.
[9] Wakerow, P., Rustagi, S. and Cook, J. (2022) Proof-of-stake rewards and penalties, ethereum.org. Available at https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/rewards-and-penalties (Accessed: March 15, 2023).
[10] See, e.g. 18 U.S.C. § 875(d), 18 U.S.C. § 371. https://www.law.cornell.edu/uscode/text/18/875 https://www.law.cornell.edu/uscode/text/18/371
All Comments