There are disparate views in the literature regarding the life cycles of contracts compared with smart contracts. [Gisler 2000] identified four phases of the legal contracting process – Information (contract conception), Intention (contract preparation), agreement (contract negotiation), settlement (contract fulfillment). The smart contract life cycle in [Sillaber 2017]’s view consists of four different phases: Creation, freezing, execution, and finalization. [ISO 2019] also considered the smart contract lifecycle, but in terms of three phases: creation, operation and termination. Note that the operation phase also included consideration of modifying smart contracts in public blockchains systems, the update and rollback mechanisms supported by the blockchain and migration mechanisms defined by smart contracts. As the more recent definition, and the result of a group consensus, let us adopt the ISO life cycle structure. Gisler’s information, intention and agreement phases would map to the smart contract creation phase of ISO; the settlement phase then being the smart contract operation. Similarly, Sillaber’s creation and freezing phases map to the smart contract creation phase of ISO; the execution phase to smart contract operation; and the finalization phase to smart contract termination.
Blockchain, or, more generally, distributed ledger, technologies are rising in popularity because of smart contracts. Not all dapps will qualify as smart contracts, and not all smart contracts will be legally recognizable under contract law [Guadamuz 2019] but some portion will be. A great deal of attention is given to the practice of development, i.e. programming, of smart contracts; [AlKahlil 2019] argues that more attention should be given to the needs of lawyers as the traditional developers of contracts. Commercial contracts are sometimes ruefully described as “documents written by lawyers, for lawyers,” artifacts of a negotiated exchange wrapped tightly in pages of clauses intended to insulate the agreement against litigation attacks [Barton 2019]. It is not intuitively obvious that all of the contractual terms for some set of contracts can be implemented in smart contract logic (i.e., many contractual terms require some aspect of performance by external actors in the physical world); but for some subset of contracts, smart contract can implement the necessary terms to provide value in automating the transaction execution. In the following sections we consider typical smart contract life cycle operations, and whether legal roles are necessary in those phases.
The discussion is largely based on Ethereum as the most prevalent smart contract platform. Ethereum distinguishes between externally owned accounts (often called users), and smart contract accounts. For any account, its data is stored at its address. Contracts additionally have bytecode stored at their respective addresses. This code is executed only when receiving a call; ie the smart contract reacts as a server (in a client server architecture) responding to requests from other clients. Transactions are signed data packages sent from users to other users (or smart contracts); and recorded on the blockchain. Messages are data packages sent from smart contracts to other smart contracts or users and are reflected in the execution trace and potential permanent data changes.
Smart contract creation
Business lawyers add value by structuring the agreement during its creation [Gilson 1984]. Sometimes this may be achieved through non-price related terms such as warranties and indemnifications [Jastrzebski 2019]. Some of these terms may be difficult to execute directly in the smart contract, as they often rely on performance by other actors in the physical world. For the subset of contractual terms implementable by smart contracts, lawyers may still need to add value for their clients by reviewing contract proposals prior to agreement and negotiating alternative transaction structures. Negotiation on deal structuring likely happens prior to developing the smart contract code, as any changes negotiated would then need to be modified, essentially requiring a new smart contract to be created. Implementation of existing industry standardized contracts as (parametrized) smart contracts reduces the need for contract negotiation, leaving only the contract review aspect. A business lawyer might review a standardized contract prior to its initial use (or upon its revision), and then develop business guidelines on acceptable parameter ranges given other business policies, regulatory constraints etc.
Smart contract code development typically starts with an existing contract as the objective. Code development and testing occur prior to deployment on the blockchain. Modern software development approaches tend to be incremental; stressing development of verifiable functionality first with later optimization on non-functional characteristics like performance. While devops approaches may be applicable in a blockchain context; continuous integration/ continuous deployment (CI/CD) approaches may be more challenging due to the nature of the blockchain. For a smart contract to exist on the blockchain, it needs to be created by another address via the deployment (constructor) code, which is executed once by the EVM. A smart contract can be created by either a user or by another smart contract [DiAngelo 2019]. Contracts become deployed as part of Ethereum’s global state by wrapping their initialization code in a transaction, signing it and broadcasting it to the network. The state and the code of smart contracts are publicly accessible, enabling inspections and audits [Patsonakis 2019]. Developers typically implement their smart contracts with the Solidity language, then build the source code using the Solidity compiler (solc) to generate the EVM bytecode. A typical EVM bytecode is composed of three parts: creation code, runtime code and swarm code. Swarm code is not served for execution purpose. Solc uses the metadata of a contract, including compiler version, source code and the located block number, to calculate the so-called Swarm hash, which can be used to query on Swarm (a decentralized storage system) to prove the consistency between the contract in swarm storage and the contract being deployed. As a result, re-deploying a smart contract would result in a different swarm code, even with the same creation code and runtime code [He 2019]. The swarm hash can provide an indication of version changes, but does not provide indications of the scope of the change similar to other versioning systems (e.g., semver.org)
In practice, how a lawyer could review a smart contract implementation for these aspects is problematic unless they have also developed skills in the appropriate smart contract platform, programming language, etc. traditional legal skills are helpful in distinguishing subtle ambiguities in the conceptual agreement capturing the contract, but new skills would be required to validate the subtleties of smart contract implementations. Several implementations of distributed ledgers have been proposed, and different languages for the development of smart contracts have been suggested. [AlKahlil 2019] proposed a list of requirements for a human and machine-readable contract authoring language, friendly to lawyers, serving as a common (and a specification) language, for programmers, and the parties to a contract.
Operational Aspects of Smart Contracts
The costs of computing on the blockchain are non-trivial – estimated at two orders of magnitude greater than cloud computing, and in some cases the blockchain design requires transaction fees. Transaction fees, which compensate miners for their work in validating transactions, are a function of their byte size and the complexity of the code they invoke (if any). Ethereum employs a flat cost model, i.e., each transaction byte and EVM operation costs some predefined amount of gas. Transactions specify a gas price, which converts ether to gas and influences the incentive of miners to include it in their next block. The higher the gas price, the higher its real monetary cost and priority to be mined [Patsonakis 2019]. Transaction costs provide incentives for smart contract designers to be efficient and minimize the operational costs of their smart contracts. There is a tradeoff between cost efficiency for a particular smart contract vs the development and reuse of standardized code libraries of other smart contracts on the blockchain. Cost awareness in the code also implies a complication at code design time by requiring this cost awareness. Cloud computing in contrast also charges for the execution, but this decision is made at run time, and typically out of band to the code being executed.
In light of potentially devastating financial consequences from smart contracts, several regulatory bodies have identified a need to audit smart contracts for security and correctness guarantees [Zhou 2018]. Auditors need to be able to establish the existence, valuation and ownership of assets managed by a smart contract [Pimentel 2019]. Where the blockchain is public and software inspectable, software inspecting the blockchain is limited to the digital asset; it does not reach to any underlying physical assets. Standardized tokens may facilitate such inspections, but it remains to be seen if they are sufficient for audit and other purposes. While smart contracts could be designed to monitor the results of other smart contracts for conformance to some set of rules, it is not clear that such monitoring contracts would cover the full scope of applicable compliance, financial reporting, and other regulations. In addition, common operational performance metrics like service liveness, availability etc. remain to be standardized in the context of blockchain systems (e.g. is the existence of a smart contract in the block sufficient to determine availability of the service it offers?). Lawyers may be engaged in settlement operations (e.g. a residential real estate closing), though most of the work they perform is the document review and preparation prior to the settlement meeting event. A smart contract could automate the asset transfers on a closing statement, but this still requires the prior document review and preparation by competent professionals. In the case of smart contracts, the equivalent review and preparation is likely to be focused on the creation and inspection of the securitized tokens to assure their fitness for purpose.
Mechanisms to upgrade an existing deployed smart contract are not obvious. Barring some disruptive hard fork of the blockchain, smart contract code is immutably recorded in the distributed ledgers. Hence, design patterns using smart contract registries or delegatecall() constructs have emerged to upgrade contracts; these patterns, however, introduce problems [Harz 2018]. It is difficult, but not impossible, to provide for a smart upgrade mechanism. [McCloskey 2019] provides an example method for upgrading a smart contract system on Ethereum.
The blockchains underlying the smart contracts also need to be able to upgrade. Hard forks are not unknown, even in relatively mature blockchains. In 2017 (almost 10 years after its introduction), Bitcoin upgraded to implement “segregated witness” (“SegWit”). Some data in transactions was moved from one portion of the block to another in a way that effectively increased the number of transactions that could fit in each block. The blockchain before SegWit and the blockchain after had different semantics. It takes human actions to upgrade blockchains and Bitcoin’s users collectively acted to modify Bitcoin’s semantics in ways that would invalidate some transactions. A critical mass of miners announced their support for SegWit, and then on the agreed-upon date started enforcing the new rules; everyone else went along for the ride [Grimmelman 2019]. Governance of blockchain upgrades varies across the different blockchain implementations. Tezos is a self-amending crypto-ledger. The protocol that validates blocks and implements the consensus algorithm can amend itself. Concretely a new protocol is downloaded from the network, compiled and how-swapped to replace the current one. In order to amend itself, Tezos uses an on-chain voting system where users of the blockchain participate to propose, select, adopt or reject new amendments. [Allombert 2019]. Support for contract code upgrades and explicit reference to dispute resolution procedures can be supported in permissioned blockchains like CORDA [Brown 2016]. Blockchain hard forks are a potentially disruptive aspect of the operational environment that should be considered in the design of smart contracts.
Hard forks can impact the value of assets held in the distributed ledgers, and the operation of smart contracts deployed on the blockchain. Human action is required to implement hard forks, typically by programmers developing the blockchain code or operating the miners. Owners of assets impacted by a blockchain fork may seek redress from those initiating the fork [Walch 2019]. In such cases, these developers may also need legal services. The development of standardized behaviors for upgrades in both smart contracts and blockchains may help reduce such liability risks during the operating phase of the smart contract life cycle.
Termination of smart contract
Smart contracts are supposed to be self-executing and terminate on completion. Ethereum’s Solidity language for smart contracts provides a function for that purpose. A Turing complete language provides no intrinsic guarantees that a program will terminate. There are three primary methods [Harris 2019] to guarantee termination in smart contract programs (i) Turing Incompleteness: To avoid entering an endless loop, a Turing Incomplete blockchain (e.g. Bitcoin) will have limited functionality and may be incapable of making jumps and loops;(ii) Steps and Fee Meters: A smart contract can keep track of the number “steps” it has taken and then terminate once a step count has been reached, or with a fee meter, smart contracts are executed with a pre-paid amount put into a reserve. Every instruction execution requires a specified fee. The contract is subsequently terminated if the fee spent exceeds the pre-paid allocated amount; (iii) Timers: Here a pre-determined timer is maintained; if the contract execution exceeds the time limit then it is externally aborted. Ethereum uses the fee meter approach for termination, requiring “gas” (a fee) to deploy and execute smart contracts. Once the gas used exceeds the pre-paid allocated amount, the contract is terminated.
As a result of both technical and human factors, contractual disputes can still occur, even in automated settings. Abnormal contract terminations are typical triggers for the contracting parties to engage their lawyers to review their options. Abnormal smart contract terminations may be due to a mistake of fact (e.g. the smart contract reacts to reports of some external event that are incorrect) or mistakes in operation (e.g., the smart contract fails to terminate, or terminates early). Reliance on detecting anomalous transactions is too late – the transaction has already been recorded on the blockchain; and standard methods to reverse transactions on blockchains do not exist. Termination of a legal contact and termination of a smart contract may not perfectly coincide in time. Consider a legal contract to transfer some physical asset to a new owner through a smart contract. The “tokenization” of the asset must occur prior to the termination of the smart contract. The smart contract likely concludes on the transfer of the token. The recipient may have additional steps to gain control of the physical asset given the token representing it. Such “detokenization” may take some time, and possibly interaction with a third party custodian of the physical asset.
References
[AlKahlil 2019] F. Al Khalil, et al. “Trust in smart contracts is a process, as well.” International Conference on Financial Cryptography and Data Security. Springer, Cham, 2017.
[Allombert 2019] V. Allombert, et. al., “Introduction to the Tezos Blockchain.” arXiv preprint arXiv:1909.08458 (2019).
[Barton 2019] T. Barton, et al. “Successful Contracts: Integrating Design and Technology.” Legal Tech, Smart Contracts and Blockchain. Springer, Singapore, 2019. 63-91.
[Brown 2016] R. Brown, et. al., “Corda: an introduction.” R3 CEV, August 1 (2016): 15.
[DiAngelo 2019] M. Di Angelo, & G. Salzer. “Collateral Use of Deployment Code for Smart Contracts in Ethereum.” 2019 10th IFIP International Conference on New Technologies, Mobility and Security (NTMS). IEEE, 2019.
[Gisler 2000] M. Gisler, et. al., “Legal Aspects of Electronic Contracts.” ISDO. 2000.
[Gilson 1984] R. Gilson, “Value creation by business lawyers: legal skills and asset pricing.” Yale LJ 94 (1984): 239.
[Grimmelman 2019] J. Grimmelmann, “All Smart Contracts Are Ambiguous.” Penn Journal of Law and Innovation (Forthcoming) (2019).
[Guadamuz 2019] A. Guadamuz, “All watched over by machines of loving grace: A critical look at smart contracts.” Computer Law & Security Review (2019): 105338.
[Harz 2018] D. Harz, & W. Knottenbelt. “Towards safer smart contracts: A survey of languages and verification methods.” arXiv preprint arXiv:1809.09805 (2018).
[He 2019] N. He, et. al., “Characterizing Code Clones in the Ethereum Smart Contract Ecosystem.” arXiv preprint arXiv:1905.00272 (2019).
[ISO 2019] ISO/TC307 “Blockchain and distributed ledger technologies — Overview of and interactions between smart contracts in blockchain and distributed ledger technology systems,” ISO/TR 23455:2019
[Jastrzebski 2019] J. Jastrzębski, “Value Creation in Negotiations of Contractual Warranties and Indemnifications.” European Company and Financial Law Review 16.3 (2019): 273-309.
[McCloskey 2019] S. McCloskey, et. al. “Innovation Ecosystem Built on the Blockchain. Token Ticker-MTX Updated February 28, 2019.“
[Patsonakis 2019] C. Patsonakis, et. al., “On the Practicality of Smart Contract PKI.” arXiv preprint arXiv:1902.00878 (2019).
[Pimentel 2019] E. Pimentel, et. al., “Systemizing the Challenges of Auditing Blockchain-Based Assets.” Available at SSRN 3359985(2019).
[Rimba 2018] P. Rimba, et. al., “Quantifying the Cost of Distrust: Comparing Blockchain and Cloud Services for Business Process Execution.” Information Systems Frontiers (2018): 1-19.
[Sillaber 2017] C. Sillaber, & B. Waltl. “Life cycle of smart contracts in blockchain ecosystems.” Datenschutz und Datensicherheit-DuD 41.8 (2017): 497-500
[Walch 2019] Walch, Angela. “In Code (Rs) We Trust: Software Developers as Fiduciaries in Public Blockchains.” (2019). SSRN abstract 3203198
[Zou 2018] Y. Zhou, et al. “Erays: reverse engineering ethereum’s opaque smart contracts.” 27th {USENIX} Security Symposium ({USENIX} Security 18). 2018.