Smart Contracts

“Recasting all complex social situations either as neatly defined problems with definite, computable solutions or as transparent and self-evident processes that can be easily optimized—if only the right algorithms are in place!—this quest is likely to have unexpected consequences that could eventually cause more damage than the problems they seek to address.”

– Evgeny Morozov, To Save Everything, Click Here

Smart contracts are a curiously named term that has sparked a great deal of interest due to the confusion of its namesake. Like many blockchain terms, a smart contract is a semantically meaningless term in the larger corpus of discussion, and its usage has been defined to mean a great many different things to a great many people.

Put simply, a smart contract is an app, much like the ones that run on your phone: a piece of computer software that runs code that controls a pool of crypto casino tokens. The aspect that separates this type of software from normal software is that this application is forced to respond to any request by the design of the blockchain platform it runs on. Internal to this software, there are a set of rules written by another human being that describe a process by which users can interact with the casino tokens locked inside it.

The dumbest smart contract would be a metaphorical box in which users can deposit tokens. When they deposit a fixed amount of tokens, N, they get a receipt that remembers how much they put into the box, and when they return with the receipt, they can withdraw N tokens. This example is a simple process to state in English, and an equivalent transcription of this idea can be encoded in a computer program and run in a smart contract.

A contract in Common Law jurisdictions is an interaction between two parties recognized by the law where an offer and an acceptance are established around a shared set of terms. Both the offer and acceptance can take many forms, including actions such as signatures, the production of shared documents, or digital interaction. The contract terms are interpreted in a given governing law, which defines the environment in which the contract’s terms are valid and gives a mechanism to settle disputes. The basis of this system is the interpretation of legal terms in the minds of judges and magistrates, which interpret the law in a historical and situational context.

Smart contracts have absolutely nothing to do with legal contracts.

If there is one takeaway before we delve into the technical details, it is a simple observation that the term is deeply flawed. However, the technology has benefited from convenience in confusion around the name; indeed, smart contracts are a contradiction in terms as they are neither smart nor contracts.

Smart Contracts are not Contracts

To unpack this term, we will refer to two different types of programs colloquially called smart contracts: bitcoin scripts and solidity scripts. Bitcoin scripts are a very simple mechanism for including small units of logic alongside bitcoin transactions. These can be used to orchestrate the flow of transactions according to a minimal set of logical operations. The script itself is interpreted in a simple “computer” called a stack evaluator, a set of simple instructions evaluated left-to-right that can view and manipulate a mutable list of values. Many programming languages such as Python and Ruby are based on stack virtual machines. Bitcoin scripts on the other hand are intentionally minimal for performance reasons and to not overcomplicate the protocol. For instance you can express a simple program that locks a set of bitcoin values until a given time in the future, but you cannot write a calculator or chess engine inside of a bitcoin script. In computer science terms, the bitcoin script is not Turing-complete since it is a language that is not capable of expressing general computation and has no looping operation or means to evaluate terms recursively. Not being Turing-complete drastically restricts the set of possible programs that can be expressed in the language. In practice, bitcoin scripts are not widely used, and there is a class of about five commonly used tasks for which the logic is simple enough. An example bitcoin script for a Pay-to-Public-Key-Hash (P2PKH) transaction looks like the following:

OP_DUP
OP_HASH160
62e907b15cbf27d5425399ebf6f0fb50ebb88f18
OP_EQUALVERIFY
OP_CHECKSIG

The Ethereum network has taken a different approach to its protocol and embedded an entire virtual machine (called the EVM) inside the evaluation of Ether transactions. This method for achieving this executable blockchain logic was outlined in the 2014 ethereum whitepaper. The EVM is a virtual machine that is also stack-based but provides more primitives and operations to manipulate stack data. The ethereum virtual machine serves as a target for higher-level languages (Solidity, Viper, etc.), which take human-readable source code and translate it into a set of machine-readable EVM instructions. These instructions are encoded as numerical codes inside ethereum transactions sent to the public network. The primary language that ethereum contracts are written in is Solidity, a blockchain-specific scripting language most comparable to the standard web scripting language Javascript.

Solidity logic can mediate the exchange of ethereum tokens according to arbitrarily complex logic, including arithmetic, mathematical operations, logical control flow, and manipulation of simple data structures such as associative maps and lists. In a suppositional sense, Solidity is Turing-complete. In practice, however, it has a restriction on its runtime imposed by its runtime. This restriction is known as bounded evaluation, which assigns a specific cost to each operation which incurs an economic cost to the issuer of the transaction known as gas. This gas is capped per transaction and effectively prevents infinite-looping events while evaluating a block of transactions. This restriction prevents the network from being globally stalled while evaluating a transaction’s potentially arbitrarily complex program logic.

pragma solidity >=0.4.22 <0.8.0;

contract OwnedToken {
    TokenCreator creator;
    address owner;
    bytes32 name;

    constructor(bytes32 _name) {
        owner = msg.sender;
        creator = TokenCreator(msg.sender);
        name = _name;
    }

    function changeName(bytes32 newName) public {
        if (msg.sender == address(creator))
            name = newName;
    }

    function transfer(address newOwner) public {
        if (creator.isTokenTransferOK(owner, newOwner))
            owner = newOwner;
    }
}

Solidity falls out of a previous tradition of open-source programming tools that have taken a move fast and break things approach to development philosophy, prioritizing time to develop over theoretical concerns of semantics, correctness, or best practices of language design. Solidity was meant to appeal to the entry-level Javascript developer base, which uses coding practices such as copying and pasting from code aggregator sites like Stack Overflow. As a result, Solidity code generally has a very high defect count and has resulted in a constant stream of high-profile security incidents directly related to coding errors. Some studies have put the defect count at 100 per 1000 lines.

A cottage industry has arisen around trying to prevent security flaws related to the coding errors in smart contracts. These companies have taken two approaches: a technical one in the form of a process known as software verification and a heuristic one in which third-party independent contractors audit code to attest to the integrity of the contract’s logic before it goes live. The formal verification approach builds on a branch of computer science known as formal methods which attempts to model the behavior of programs by reducing them down to a mathematical description of the values computed by individual components.

The primary issue arises when the transcription of ideas into a computer program becomes more complicated. It then becomes challenging to confirm whether the programmer’s code matches the intent. A specialized branch of software engineering is concerned with just this problem, known as software verification. Unfortunately, most of the general solutions required to do this process, in the general case, are open problems or reduce down to equivalent open problems in mathematics and theoretical computer science.

Moreover, smart contracts introduce a whole other dimension of complexity to the problem by forcing developers not only to verify the internal consistency and coherence of their software logic but also to model any and all exogenous financial events and market dynamics surrounding the price of the casino tokens used in the software. This hostile execution environment turns a pure computer science question into a composite question of both finance and software and expands the surface area of the problem drastically. At some point in the future, our theoretical models may be able to tackle such problems, but likely not for long time as these problems are of a truly staggering complexity.

The degree of engineering required to prove the correctness properties of these contracts’ logic is expensive, and the return on investment for that level of engineering would do little to mitigate the risks when the underlying platform itself is unable to be changed. However, it is much easier in practice to deceptively market a project as “having formal verification” or “having a code audit,”’ as there is very little due diligence done on these projects in the first place. In practice, both audits and formal verification approach has thus mainly been performative and yielded little success in preventing catastrophes in live contracts.

Meanwhile, the reality is that today smart contracts are an unimaginably horrible idea and it is a genuinely horrifying proposition to base a financial system on these structures. Smart contracts synthesize brittle, unverifiable, and corruptible software with irreversible transactions to achieve a result that fails in the most violent way possible when the wind blows even slightly the wrong way. They further lack a key component that most software engineering deployed in the wild requires, a human-in-the-loop to correct errors in the case of extreme unforeseen events such as fraud and software failure.

Thus the very design of smart contracts and blockchain-based assets is entirely antithetical to good engineering practices. The idea of smart contracts is rooted in libertarian paranoia concerning censorship resisters and ignoring externalities instead of a concern for mitigating public harm.

The most catastrophic smart contract was undoubtedly the DAO hack. The DAO was an experimental, decentralized autonomous organization that loosely resembled a venture fund. Exampled simply, it is a program that would allow users to invest and vote on proposals for projects to which the autonomous logic of the contract would issue funds as a hypothetical “investment.” It was a loose attempt at building what would amount to an investment fund on the blockchain. The underlying contract itself was deployed and went live, consuming around $50 million at the then exchange rate with Ether cryptocurrency. The contract contained a fundamental software bug that allowed an individual hacker to drain DAO accounts into their accounts and acquire the entirety of the community’s marked investment. This hack represented a non-trivial amount of the total Ether in circulation across the network and was a major public relations disaster for the network. The community controversially decided to drastically roll back the entire network to a previous state to revert the hacker’s withdrawal of funds and restore the contract to regular operation. (Securities, Commission, and others 2017)

Among the programming language ecosystem, there is a niche subset of languages known as functional languages, which are notable for their applications in high-assurance software applications, ones where the correctness of code can be proven in more cases. A sizable number of practitioners in the functional programming ecosystem have spent efforts looking at the problem of smart contract languages. Many proposals and prototypes have been made that would make theoretical guarantees of correctness beyond the current state of affairs. However, none of these projects have gained any traction or born fruit, as the fundamental problem of retrofitting these tools onto existing runtimes and training existing practitioners in unfamiliar tools within their profession. Hard computer science problems just get in the way of easy money.

The grandiose promise of smart contracts was for applications that build decentralized internet applications called dApps. These dApps would behave like existing web and mobile applications but counter interface with the blockchain for persistence and consume or transmit cryptocurrency as part of their operations. There are endless proposals for ideas like decentralized clones of existing services such as Airbnb, Uber, LinkedIn, and nearly every other commercially successful web application. The implicit assumption of these proposals is that a decentralized application would allow the applications to be superior due to being run “by the people,” independent of corporate governance, and free of privacy and data collection problems. Much of the smart contract narrative is built around phony populism and the ill-defined idea that there is an upcoming third iteration of the internet (a Web 3.0) that will interact with smart contracts to provide a new generation of applications. In practice, none of that has manifested in any usable form, and the fundamental data throughput limitations of blockchain data read and write actions make that vision impossible.

Most live smart contracts instead fall into a limited set of categories: gambling, tumblers, NFTs, decentralized exchanges, and crowd sales. The vast majority of code running on the public ethereum network falls into one of these categories, with a standard set of open-source scripts driving the bulk of the contract logic that is evaluated on the network. However, there is a wide variety of bespoke scripts associated with different ICO companies and high-risk gambling products that are bespoke logic and act independently of existing community standards and practices.

The most common script is an ERC20 token, a contract that allows users to issue custom token crowd sales on top of the ethereum blockchain. These tokens were a custom registry that mapped holdings of addresses to their balances of the custom token. By transacting with the contract (i.e., offering party), users could exchange their ethereum tokens to “buy into” the custom tokens offered at a specific value. The total supply of these tokens in any one of these contracts was a custom fixed amount, and by interacting with the ERC20 contract, the buyers’ tokens were instantly liquid and could be exchanged with other users according to the rules of the contract. This is the standard mechanism that drove the ICO bubble and related speculation, and this token sale contract is overwhelmingly the most common use case for smart contracts. Quite commonly, these ERC20 tokens were tied to a SAFT (Simple Agreement for Tokens), a legal contract in US law that mapped owners in the token registry to the purchasers of those securities inside the US legal system. This SAFT agreement was structurally similar to a SAFE (Simple Agreement for Equity), which companies in the US typically use for early startup fundraising to offer equity to venture capitalists and early investors.

Tumblers–such as tornado.cash–are another application of smart contracts which allow users who have engaged in darknet transactions to clean their money by exchanging their dirty tokens with clean tokens through a set of random swaps which preserve the value but obscure the provenance. These tumblers use several evasion techniques such as random transactions, time-delayed transactions, and swaps with other chains with private transactions to return the clean money back to the client. In traditional financial services, this would be called a criminal activity known as money laundering. Traditional money custodians and money transmitters are typically required to maintain audit logs and prevent this form of activity as part of their licenses and regulatory oversight.

Another class of projects is the digital collectibles and digital pets genre. One of the most popular is CryptoKitties: a game in which users can buy, sell, and breed cartoon kittens. The sale of digital cats was responsible for 6.2% of all ethereum traffic in 2018. The number of transactions on this one application represented a significant fraction of all contract logic and drastically congested the global network when many individuals began trading digital cats.

Gambling products overwhelmingly dominate the remaining set of contracts. Aside from illegal securities offerings, gambling is the primary domain for blockchain apps. This script allows participants to gamble their tokens in games of chance against other blockchain users. There are a variety of so-called dApps (distributed applications) which offer lotteries and games in which users stake ethereum tokens, and the game makers offer opportunities to play in exchange for transaction fees. Some of these games are classical Ponzi schemes in which players pay into a pool of tokens, and early investors are paid out from the increasing pool of subsequent investors (Pinna et al. 2019; Hartel, Homoliak, and Reijsbergen 2019).

The ICO bubble marked a significant increase in the interest in smart contracts arising from outlandish claims of how cryptocurrency ventures would disintermediate and decentralize everything from the legal profession and electricity grid to food supply chains. In reality, we have seen none of these visions manifest, and the technology is primitive, architecturally dubious, and lacking in any clear applications of benefit to the economy at large. The ecosystem of dApps is a veritable wasteland of dead projects, with none having more than a few hundred active users at best.

Smart Contracts are not Smart

The very design of a smart contract is to run on an unregulated network which prevents it from interfacing with external systems in any meaningful fashion. This confusion around the namesake of smart contracts has been exploited by many parties to sell products and services.

The fundamental limitation of smart contracts is best exemplified by a technical limitation referred to as the oracle problem. In blockchain systems, there is a data boundary between data stored on-chain, referring to data stored natively on the blockchain database such as transactions, wallet address, and smart contract state. Data that is off-chain colloquially means anything not within the blockchain database, such as the public internet, data stored in traditional databases, and data feeds for news events or financial markets. The efficacy of many applications of smart contracts was predicated upon the ability to query events that would occur outside the blockchain network, which would be either self-reported or attested to by an authoritative source.

Smart contracts claim to not trust external central authorities, but they cannot function without them. Thus the idea is doomed by its own philosophy.

This problem poses a fundamental contradiction in the theoretical value proposition of decentralized dApps; if their operation was run on a decentralized platform, but the core mechanism for operation depended on a central authority, this resulted in a system that is functionally equivalent to an existing centrally operated application. Stated another way, if a blockchain financial product depends on the weather or value of the S&P 500, the smart contract would have to extend its trust boundary to the included National Weather Service or a Bloomberg for its operation to function. At this point the entire setup provides a service that is no better or different than running the same program on a centralized server. This is not only a problem, but an inherent contradiction. The oracle problem for smart contracts is metaphorically like creating a safebox with six sides, but while five walls are made out of steel and the sixth is made out of tissue paper. The vulnerability undermines the entire principle of the construction. (Doctorow n.d.)

Within the domain of permissioned blockchains, the terminology has been co-opted to refer to an existing set of tools that would traditionally be called process automation. In 2018 so-called enterprise “smart contracts” were the buzzword du jour for consultants to sell enterprise projects. These so-called enterprise smart contracts had very little to do with their counterparts in public blockchains and were existing programming tools such as Javascript, Java, and Python rebranded or packaged in a way that would supposedly impart the “value of the blockchain” through undefined and indeterminate means. Indeed one of the popular enterprise blockchain platforms, IBM Hyperledger, provides a rather expansive definition of smart contracts (“Hyperledger Fabric Documentation” 2017):

A smart contract can describe an almost infinite array of business use cases relating to immutability of data in multi-organizational decision making. The job of a smart contract developer is to take an existing business process that might govern financial prices or delivery conditions, and express it as a smart contract in a programming language such as JavaScript, Go, or Java. The legal and technical skills required to convert centuries of legal language into programming language is increasingly practiced by smart contract auditors.

While the public blockchain company Dfinity (Livni and Sorkin 2021) claims to creating a technological singularity of infinite possibilities:

We aim to create a “blockchain singularity” in which every system and service is rebuilt and reimagined using smart contracts and runs entirely from infinite public blockchain without need for traditional IT.

Both these meaningless paragraphs are the embodiment of the blockchain meme. It is an extension of the terminology to include “infinite use cases” through a meaningless slurry of buzzwords. Smart contracts simply are not useful for any real-world applications. To the extent that they are used on blockchain networks, smart contracts strictly inferior services or are part of gambling or money laundering operations that are forced to use this flawed system because it is the only platform that allows for illicit financing, arbitrage securities regulation, or avoids law enforcement.

The insane software assumptions of smart contracts can only give rise to a digital wild west that effectively turns all possible decentralized applications into an all-ports-open honeypot for hackers to exploit and manifests the terrible idea that smart contracts are just a form of self-service bug bounty. These assumptions give rise to an absurd level of platform risk that could never provide financial services to the general public given the level of fraud and risk management required to interact with it.

Transaction reversal and fraud mitigation through due process and the courts(Walch 2019) are essential for all financial services. Nevertheless, adding this capacity to a permissionless system would undermine the very decentralized premise on which it was built, and therein lies an irreconcilable contradiction.

Append-only public data structures, permissionless consensus algorithms, and smart contracts are all technically exciting ideas; however, combining all three is a nightmare(Clements 2021) that could never be a foundation for a financial system or for handling personal user data. The technology is not fit for purpose and cannot be fixed. To put it simply, smart contracts are a profoundly dumb idea.