I will be presenting a paper on ” Privacy in IoT Blockchains: with Big Data comes Big Responsibility” at the 2019 International Workshop on IoT Big Data and Blockchain (IoTBB’2019) held in conjunction with the IEEE BigData 2019 conference

Date: December 10, 2019
Time: 6:10-6:35 pm
Event: IoTBB'2019 & IEEE Big Data 2019
Venue: The Westin Bonaventure Hotel & Suites, Los Angeles
Location: 404 South Figueroa Street,
Los Angeles, California 90071
USA
Public: Public

Smart Contract Development Issues

Developing and maintaining a smart contract application is difficult compared to traditional software application development and maintenance. Blockchains usually incorporate new functionality through hard forks, that typically are scheduled ahead of time to ensure that all the nodes are running the same version of the blockchain software. Due to the difficulty in upgrade, a smart contract needs to be well tested before deployment.  Smart contracts run on public blockchains that have thousands of blocks created over a period of years. A smart contract may need to be backward compatible and capable of validating earlier transactions or executing other smart contracts deployed through earlier versions of the blockchain [Bosu 2019]. Steep learning curves to get familiar with a smart contract is another challenge for many developers. The codebase of a smart contract project is not only complex but also requires a sound understanding of cryptography, networking, distributed systems as well as project specific protocols. The lack of supporting tools and documentation has been a challenge for many smart contract developers. Many of the supporting tools found in traditional software application environments are yet to be developed for the blockchain context. Moreover, the tools that are currently available are seen by many developers as immature and unreliable [Bosu 2019].

To understand a complicated smart contract domain, developers are looking for good learning materials and tutorials. Even the documentation that they currently have are not user friendly. [Ayman 2019] studied smart contract related discussion on the Stack Overflow forum which caters to many types of software developers and found that questions posted related to smart contract have increased since 2015. The fraction of posts that contain smart contract questions without answers seems unusually high, and it suggests that the user base still has a lot to learn. A significant percentage of smart contract related questions have no answers at all. Very few posts on Stack Overflow discuss security-related topics in smart contracts. Many of the blockchain projects are run by open source communities. Even when functioning well, open source communities provide only limited support. Commercially supported open source communities have a base of commercial entities with business models providing long term support to those communities – but the tradeoff can be undue influence in the development roadmap. Traditional online developer forums do not seem to be generating adequate support, perhaps due to the newness of the technology.

Smart contract platforms need [Harris 2019] to provide three properties: they need to be deterministic, isolated, and terminable. Determinism is required so that the distributed instances achieve the same result in their independent computations. A smart contract can be uploaded by anyone, which introduces a risk since any single contract may (by design or by accident) contain viruses and bugs. If the contract is not isolated, this could impact the entire blockchain ecosystem. Termination is required so that contracts conclude within a reasonable time and so that excess resources are not consumed. There are at least 28 different blockchain platforms [Yusuf 2018]. Beyond bitcoin and Ethereum, [Bartoletti 2017] identified four blockchain platforms supporting smart contracts that had been launched, were publicly accessible, and had a supporting community of developers. More recently, [Rouhani 2019] identified nine blockchains as also supporting smart contracts. The Ethereum and Bitcoin smart contracts seem to have the bulk of the transaction volume, with the bulk of the smart contracts on Ethereum, though statistics on private (permissioned) implementations are often not available. Bitcoin support for smart contracts is often through the use of side chains [Rouhani 2019]. The number and variety of platform supporting smart contracts seems to be increasing, providing an indication of the popularity of the approach, but also a challenge for developers and users of the technology.

Different blockchain platforms support a diverse set of programming languages to develop smart contracts. Some proposals have been made for higher level domain specific languages for smart contracts (e.g., based on specifications, or declarative logic), or to enforce solutions against particular vulnerabilities (e.g., BAMBOO – proposed to enforce a state machine model to resolve the reentrancy problem underlying the DAO hack).  Languages for smart contracts should (1) consider users’ needs as a primary concern; (2) to facilitate safe development by detecting relevant classes of serious bugs at compile time; and (3) as much as possible, be blockchain-agnostic, given the wide variety of different blockchain platforms available [Coblenz 2019]. While there have been many recent proposals for language improvements, in practice, for many developers, the set of smart contract programming languages is constrained by the choice of blockchain platform.

[Bartoletti 2017] identified nine design patterns for smart contracts – token, authorization, oracle, randomness, poll, time constraint, termination (because the blockchain is immutable, there is a need to explicitly end a smart contact that has completed), math, fork check, and about 80% of the smart contracts studied used one or more of these design patterns. Validated design pattern templates of smart contracts increase trust for counterparties. The validation removes the need for costly back-testing and facilitates decentralized business transactions at unprecedented scale [Kaal 2019]. [Knecht 2017] proposes a smart contract deployment and management platform that can execute development tools and code quality tools in a trusted way and uses this to reduce the trust required into the smart contract developer or auditor. [Lu 2019] proposed uniform Blockchain as a service (uBaaS) as a solution to improve the productivity of blockchain application development. Existing BaaS deployment solutions are mostly vendor- locked: they are either bound to a cloud provider or a blockchain platform. In addition to deployment, design and implementation of blockchain-based applications is a hard task requiring deep expertise. The services in uBaaS include deployment as a service, design pattern as a service and auxiliary services.  While well-known and time-tested design patterns can help developers, the packaging and portability of smart contracts is still constrained by the blockchain platform selection.

Testing blockchain software is challenging as the software executes on a distributed and potentially hostile environment that currently cannot be adequately simulated on a development machine. Smart contract developers typically use ‘test-nets’ to experiment with heir code before deploying it to the ‘main-net’.  The test-net simulators that smart contract developers currently have are typically resource-limited, difficult to configure, and are unable to completely simulate a complex and hostile real-world environment. The scale and complexities of test-nets are typically not representative of main-net execution environments. Formal verification techniques have been proposed to secure smart contract projects, developers, however, find current formal specification languages (e.g., TLA+, VDM, and Z-notation) very complex to learn and use. Static analysis and penetration testing tools (e.g. fuzz testing, linting …) have been useful in other application domains for security testing, but those tools do not work well on the smart contract code-base [Bosu 2019]. Testing frameworks, such as the truffle suite, that automatically handle compilation and deployment of contracts and provide means of interacting with them [Patsonakis 2019] are still evolving.

The Interactive Developer Environments (IDEs), designed for the other application domains, seem to lack adequate support for testing and debugging a smart contract codebase. Smart contract developers use an array of tools for various development activities. Some developers maintain that an IDE designed specifically for smart contract development would help them [Bosu 2019]. Smart-contracts are typically written using smart contract-oriented programming language such as Solidity or Vyper and then compiled into bytecode for a specific platform (e.g., Ethereum). Remix, a commonly used IDE for solidity, currently lacks many features such as: error highlighting and line by line debugging, that many smart contract developers need [Bosu 2019]. Before interacting with a smart-contract, a developer might want to verify its security properties by decompiling its byte code but few solutions exist for this [Bosu 2019]. The other tools requested by smart contract developers include UML/design notations for the smart contract domain, containers for deployment, and automated performance analysis tools [Bosu 2019].

Given the current technology maturity of many of the tools that exist, and the variety of blockchain platforms, the environment for smart contract development does not seem very stable. The tool chain and testing frameworks can be expected to improve over time as developers become engaged with the technology. For other professionals (e.g. lawyers, auditors) with interests in verifying the correctness and completeness of smart contracts, the situation may seem even more confusing. Progress may be more tractable by focusing on a smaller set of well-known contracts, and establishing appropriate processes around those first, before attempting to apply them to a broader range of smart contracts. Focusing on particular types of tokens ay enable the development of standardized test suites for the set of transactions supporting those tokens. Standardized test suites would help enable the further development of other token and transaction types.

References

[Ayman 2019] A. Ayman, et al. “Smart Contract Development in Practice: Trends, Issues, and Discussions on Stack Overflow.” arXiv preprint arXiv:1905.08833 (2019).

[Bartoletti 2017] M. Bartoletti & L. Pompianu. “An empirical analysis of smart contracts: platforms, applications, and design patterns.” International conference on financial cryptography and data security. Springer, Cham, 2017.

[Bosu 2019] A. Bosu, et al. “Understanding the motivations, challenges and needs of blockchain software developers: A survey.” Empirical Software Engineering 24.4 (2019): 2636-2673.

[Coblenz 2019] M. Coblenz, et al. “Smarter Smart Contract Development Tools.” Proceedings of 2nd International Workshop on Emerging Trends in Software Engineering for Blockchain (WETSEB). 2019.

[Harris 2019] C. Harris, “The Risks and Challenges of Implementing Ethereum Smart Contracts.”  Int’l Conf. on Blockchain and Cryptocurrency (ICBC). IEEE, 2019.

[Kaal 2019] W. Kaal, “Decentralized Commerce–A Primer on Why Decentralized Reputation Verification Systems Are Needed.” Available at SSRN 3405401 (2019).

[Knecht 2017] M. Knecht, & B. Stiller. “Smartdemap: A smart contract deployment and management platform.” IFIP Int’l Conf. on Autonomous Infrastructure, Management and Security. Springer, Cham, 2017.

[Lu 2019] Q. Lu, et al. “uBaaS: A unified blockchain as a service platform.” Future Generation Computer Systems (2019).

[Patsonakis 2019] C. Patsonakis, et. al., “On the Practicality of Smart Contract PKI.” arXiv preprint arXiv:1902.00878 (2019).

[Rouhani 2019] S. Rouhani, & R. Deters. “Security, Performance, and Applications of Smart Contracts: A Systematic Survey.” IEEE Access 7 (2019): 50759-50779.

[Yusuf 2018] M. Yusuf, “A comprehensive list of blockchain platforms,” 2018.

Smart Contract Life Cycle Operations

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.

Perspectives on Smart Contract Computing

Smart contracts execute on blockchains or off-chain and store results on the blockchain. The decentralized nature of blockchains is seen by many as an important characteristic of blockchains. [Heo 2003] characterized information systems in multiple dimensions and distinguished decentralized and distributed aspects; where decentralized computing is characterized by a number of isolated processors with highly decentralized processing and low connectivity; distributed computing is characterized by a number of networked processors with highly decentralized processing and high connectivity. More recently, ISO TC 307 has been developing standards on distributed ledger technologies and offers definitions [ISO 2019] to distinguish between distributed and decentralized systems. A distributed system is a system in which components located on networked computers communicate and coordinate their actions by interacting with each other. A decentralized system is a distributed system wherein control is distributed among the persons or organizations participating in the operation of the system; Noting that in a decentralized system, the distribution of control among persons or organizations participating in the system is determined by the system’s design. A Distributed Ledger (DL) is shared across a set of nodes and synchronized between the nodes using a consensus mechanism. A DL is designed to be tamper resistant, append-only and immutable containing confirmed and validated transactions [ISO 2019]. A DL, as the name suggests, is a distributed record of transactions, maintained by consensus among a network of peer to peer nodes (possibly geographically dispersed) [Kuhn 2019]. Smart contracts, then execute in a decentralized manner on the blockchain (or DL) or record their results in the blockchain (or DL), and smart contract transactions could span multiple platforms. The Entity-Relationship diagram below should help disambiguate this terminology.

Smart contracts execute in the context of a decentralized computing model, but the degree of distributed control differs by the design of the underlying blockchains (primarily the consensus mechanism).  Ethereum and bitcoin have a monolithic execution model, where all participating nodes store all the state and execute every computation. This monolithic execution model has significant performance impacts. One group of proposals to improve performance is sharding. Sharding aims to split the state into shards which are distributed among groups of nodes. Performance improves if a transaction is localized entirely within a shard; recompilation problems can arise if the transaction is spread across shards [Chohan 2019]. Another proposed solution is Directed Acyclic Graphs (DAGs), which frames the ledger not as a set of blocks on a chain, but rather as leaves out of multiple branches. A general-purpose decentralized computing platform could be designed with a modular execution-model with secure specialized modules, for building decentralized applications that are currently insecure or impossible to implement with smart contracts [Alp 2019]. The computational environment can thus be seen as a spectrum between computing everything on all the nodes in a blockchain, computing on some of the nodes of a blockchain (with different options on how that subset of computational nodes are selected) , or computing offchain. Executing computational logic (e.g. the EVM) is but one aspect of a computing model. Computation requires also storage and communication aspects. In Ethereum the storage aspects are supported by IPFS and Swarm. Whisper has been proposed for decentalized messaging; but has achieved only limited support in Ethereum deployments. 

As many researchers and practitioners are discussing blockchain, some of them are raising the question about the fundamental difference between blockchain and traditional database [Chowdhury 2018]. There is a striking resemblance with the flow of a transaction in a distributed database; the major difference being the consensus protocol: databases use two-phase commit or Paxos, whereas blockchains use Byzantine tolerant protocols or variants thereof. [Dinh 2018]. The table below summarizes the differences between decentralized blockchains and centralized databases. Centralized databases have significant performance advantages and are often optimized for specific types of data (e.g., relational databases optimized for keyed data in tables ) .

From a distributed computing perspective, a smart contract resembles an object (in an object-oriented programming language). A (smart contract) object encapsulates long-lived state, a constructor to initialize that state, and one or more functions (methods) to manage that state. Smart contracts can call one another’s functions. Smart contracts are run and verified in a distributed fashion in Ethereum; the solidity smart contract semantics, however, suggest that one can think of smart contracts as of sequential programs. Smart contracts’ concurrent executions can span multiple blockchain transactions (within the same block or in multiple blocks) and thereby violate desired safety properties. Accounts using smart contracts in a blockchain are like threads using concurrent objects in shared memory [Sergey 2017].  Reentrancy and recursive calls are examples of complex behavior enabled in smart contracts (and these underlay some well-known and expensive hacks of smart contracts) where solutions exist from concurrent computing; e.g., a monitor (a well-known design pattern in concurrent programming identified in the 1970s). A monitor is an object with a built-in mutex lock, which is acquired automatically when a method is called and released when the method returns. The correctness of a monitor implementation is determined by reasoning about the monitor invariant, an assertion that holds whenever no thread is executing in the monitor. The invariant can be violated while a thread is holding the monitor lock, but it must be restored when the thread releases the lock, either by returning from a method, or by suspending via wait() [Herlihy 2019]. Concurrent programming design patterns can help make identify and resolve many of the concurrency issues with smart contracts.  Smart contracts also seem to fit the object-oriented view point with tokens emerging as more specific smart contracts with some standardized behaviors.  

Service Oriented Computing is another modern software architectural paradigm where define services are software components that can be integrated into more complex distributed applications. Components encapsulate data to be fetched and visualized or integrated and/or application logic to be interacted with. [Daniel 2019] distinguishes the following smart contract types: generic contracts (implementing the application logic), libraries (stateless code meant for reuse), data contracts providing data storage services inside the blockchain), oracles (delivering data services from outside the blockchain). Integrating components requires common behavior patterns e.g. push, pull, or business-protocol based interactions. Ethereum supports transactions ( by users of the blockchain), events (enable a contract to push information to the outside world), calls ( messages to other contracts), and  delegate calls ( invoking libraries). Data in Ethereum transactions and events is encoded using the Application Binary Interface (ABI), which specifies how functions are called and data are formatted. Clients either serialize data in a binary format on their own, or by using a suitable library function. The construct that gets closest to a description of Ethereum smart contracts is the so-called “ABI in JSON” interface description produced by the Solidity compiler [Daniel 2019].  Several challenges remain to fully enable service orientation via smart contracts including search discovery and reuse, cost awareness, performance, interoperability, standardization and composition. A related software paradigm is microservices. Microservices are small and autonomous services deployed independently, with a single and clearly defined purpose. [Tonelli 2019] provides an example of implementing some functionality as a set of smart contract microservices.

The database, object orientation, and service orientation viewpoints provide mainstream academic computer science perspectives on smart contracts; but what perspectives do practitioners actually need when developing smart contracts?  [Bosu 2019] surveyed developers to capture their perspective on developing software for blockchains compared to non-blockchain environments. They noted that data stored in a blockchain is immutable (in other domains, there are several mechanisms to fix errors later by altering data); altering a blockchain ledger is almost impossible. Compared to the most non- blockchain applications that operate on centralized and/or hosted environments, dapps operate on a complex, secured, distributed and decentralized network. Blockchains use public key cryptography and cryptographic hash functions to store and verify transactions; cryptography is difficult to master and very few other domains require similar in-depth knowledge of cryptography as the blockchain domain. Moreover, knowledge of networking and networking security is required when developing for a distributed environment. The decentralized control environment also requires familiarity with consensus mechanisms, and the application itself may require domain specific knowledge (e.g. from finance industry).  The developer requirement of having knowledge about diverse technological areas is a factor constraining software developers of smart contracts.

The smart contract computing context is quite complex, requiring in-depth knowledge of multiple disciplines (cryptography, networking, consensus mechanisms) and domain specific knowledge for the application. Traditional computing perspectives like databases, object orientation, concurrency, service orientation, etc., can provide some structure and alleviate some software development problems, but do not replace the need for application specific domains and in-depth blockchain implementation knowledge regarding cryptography, networking and consensus mechanisms. Much of the challenges comes from the early maturity of the implementations and the wide variety of different proposals. As the market develops, the range of practical alternative blockchains should narrow, tools improve, and the requisite body of knowledge stabilize; indeed these become prerequisites for enabling smart contracts to scale accessibility to a broader range of software developers.  

References

 [Alp 2019] E. Alp, et. al., “Rethinking General-Purpose Decentralized Computing.” Proc. of the Workshop on Hot Topics in Operating Systems. ACM, 2019.

[Bosu 2019] A. Bosu, et al., “Understanding the motivations, challenges and needs of blockchain software developers: A survey.” Empirical Software Engineering 24.4 (2019): 2636-2673.

[Chohan 2019] U. Chohan, “The Limits to Blockchain? Scaling vs. Decentralization.” (2019) SSRN.

[Chowdhury 2018] M. Chowdhury, et al., “Blockchain versus database: a critical analysis.”  17th Int’l Conf. on Trust, Security and Privacy in Computing and Communications/12th Int’l Conf. on Big Data Science and Engineering (TrustCom/BigDataSE). IEEE, 2018.

[Daniel 2019] F. Daniel, & L. Guida, “A service-oriented perspective on blockchain smart contracts.” IEEE Internet Computing 23.1 (2019): 46-53.

[Dinh 2018] T. Dinh, et al., “Untangling blockchain: A data processing view of blockchain systems.” IEEE Trans. on Knowledge and Data Engineering 30.7 (2018): 1366-1385.

[Heo 2003] J. Heo, & I. Han, “Performance measure of information systems (IS) in evolving computing environments: an empirical investigation.” Information & Management 40.4 (2003): 243-256.

[Herlihy 2019] M. Herlihy, “Blockchains from a distributed computing perspective.” Commun. ACM 62.2 (2019): 78-85.

[ISO 2019] ISO/DIS 22739 “Blockchain and distributed ledger technologies — Terminology”

[Sergey 2017] I.Sergey, & A. Hobor. “A concurrent perspective on smart contracts.” Int’l Conf. on Financial Cryptography and Data Security. Springer, Cham, 2017.

[Tonelli 2019] R. Tonelli, et al., “Implementing a microservices system with blockchain smart contracts.” 2019 IEEE Int’l Workshop on Blockchain Oriented Software Engineering (IWBOSE). IEEE, 2019.

Smart Contract Transactions Across Different Platforms

Different blockchains support different characteristics (e.g., throughput, scalability, availability, consistency) that may make them suitable for specific dapps.  [Koens 2019] review identified 12 characteristics to compare Cross Chain Technologies (CCTs), but [Kannageisser 2020]’s review considered 43 characteristics. Blockchain design tradeoffs limits the optimization of different blockchains ensuring that no one design meets all characteristics at the same time. Hence more powerful dapps will need transactions that cross blockchains. [Koens 2019] distinguishes blockchain interoperability in the following categories: (1) Interoperability between two smart contracts within a single blockchain (e.g. between Corda apps, which are smart contracts on a single Corda ledger); (2) Interoperability between blockchain platforms (e.g., between Bitcoin and Ethereum or Corda); (3) Interoperability between a blockchain and legacy systems. (e.g., between Ethereum and a traditional banking payment system).  Cross chain technology (CCT) helps to achieve interoperability by enabling data exchange between blockchain designs or with external systems.

There are a number of use cases for transactions operating between blockchains. [Buterin 2016] identified Portable assets (tokens), Payment-versus-payment or payment-versus-delivery, Cross-chain oracles, Asset encumbrance and General cross-chain contracts. More recently [Kannengeisser 2020] identified four use cases for cross chain technology: asset transfers, asset exchanges, cross-chain oracles, and cross-chain smart contracts. In asset transfers, assets are moved from one distributed ledger to another. Asset exchanges (a special form of asset transfer), allow users to spend assets of one blockchain in return of assets from another distributed ledger (e.g., trading of cryptocurrencies or other assets). Rather than moving assets, cross-chain oracles, in contrast, provide information from one distributed ledger to another. Cross-chain smart contracts describe the ability to trigger the execution of a smart contract on another distributed ledger, which can increase the level of automation. The literature identifies other use cases, but [Kannengeisser 2016] argues these are combinations of the previously presented use cases (e.g., sharding can be assigned to the cross-chain oracle use case).  The table below summarizes these use cases.  Assets are distinguished from other data because they represent some notion of value e.g. a token.  Asset transfers and exchanges may imply some notion of token portability as desirable- recall that tokens have some common behaviors not just a data type, and token portability would require those behaviors to be executable in the context of both blockchains.  

[Buterin 2016] Identifies  three main design patterns for blockchain interoperation: notary schemes, where a  (trusted) party or a group of parties agree to carry out an action on chain B when some event on chain A takes place; Sidechains/relays, systems inside of one blockchain that can validate and read events and/or state in other blockchains); Hash-locking (setting up operations on chain A and chain B that have the same trigger, usually the revelation of the preimage of a particular hash). [ISO 2019] provides some consideration of information transfer between blockchains, but only considers cross chain and side chain transactions. [Kannegeisser 2020]’s structured review identified three distinct patterns: manual asset exchange (MAE), notary schemes, and relays, as well as a fourth, hybrid pattern, which includes the three distinct patterns. [Kannegeisser 2020] considered hash locking to be applicable in all of the identified patterns.

Blockchains have been around for about 10 years, but it has been the emphasis on smart contracts over the last 5 years that has raised increased the interest in alternative crosschain arrangements to support a broader range of applications beyond cryptocurrency trading. In this environment, the academic literature is reacting to new commercial and open source development activities and trying to balance that with more traditional academic studies. [Koens], for example, discusses the cosmos and polkadot interoperability solutions that they felt were commonly deployed. [Kannengeisser 2020] focused more on published literature but in a structured review process its not easy to capture information sources not in academic literature.  Despite the importance of CCTs to a number of proposed applications for smart contracts, they remain a potential weak spot in the trust chain and may have other performance issues. Consensus protocols on one blockchain already limit computational throughput for smart contracts.

Transactions requiring consensus across multiple blockchains will likely suffer further performance degradations.  From the perspective of blockchain as a database, transactions on that database should be “atomic” i.e., they either completely succeed or roll back to the prior state with no change made. For transactions across blockchains the mechanisms of both blockchains assuring atomicity have to be satisfied (see e.g., [Herlihy 2018]). While traditional databases commonly provide mechanisms for atomicity, the distributed nature of blockchains also creates other challenges for transactions around determinism and idempotency (see e.g., [Demir 2019]. Single point interconnection mechanisms avoid these issues, created others as the single points must be trusted and may be susceptible to failure. Blockchain consensus mechanism are deterministic in the sense that honest nodes achieve the same results from all nodes, but if the distributed nodes obtain inconsistent off-chain data (e.g., due to a time varying source read at different times) this inconsistent data can cause the consensus mechanism to fail because all the honest nodes will no longer reach the same result. Transactions are idempotent if repeatedly invoking the same transaction does not change the result. With the distributed nodes of a blockchain all generating output transactions to impact external systems, those external systems need to react in an idempotent manner to avoid inadvertently repeating a transaction. Note that this applies to external systems that are not blockchains as well. This may be problematic for legacy systems that were not designed to accommodate multiple attempts to invoke the same transaction. This is also problematic for cross-chain smart contracts that invoke control of cyber-physical systems where a single controller paradigm is common. This is not to suggest that such problems are insoluble, but rather there is some tradeoff in computing resources required (e.g., additional state, communication etc.), and the design patterns for such solutions may not be ones that many software developers are familiar with.

References

[Buterin 2016] V. Buterin, “ Chain Interoperability”, Sept 9th 2016

[Demir 2019] M. Demir, et al. “Security Smells in Smart Contracts.”  19th Int’l Conf. on Software Quality, Reliability and Security Companion (QRS-C). IEEE, 2019.

[Herlihy 2018] M. Herlihy,”Atomic cross-chain swaps.” Proceedings of the 2018 ACM Symposium on Principles of Distributed Computing. ACM, 2018.

[ISO 2019] ISO/TR 23455:2019(en), “Blockchain and distributed ledger technologies — Overview of and interactions between smart contracts in blockchain and distributed ledger technology systems”

[Kannengeisser 2020] N. Kannengießer, et. al. ,”Bridges Between Islands: Cross-Chain Technology for Distributed Ledger Technology.” 53rd Hawaii International Conference on System Sciences. Vol. 2020. 2020.

[Koens 2019] T. Koens, & E. Poll. “Assessing interoperability solutions for distributed ledgers.” Pervasive and Mobile Computing 59 (2019): 101079.

Asset Administration by Smart Contracts

Buterin’s white paper [Buterin 2014] described smart contracts as “systems which automatically move digital assets according to arbitrary pre-specified rules”.  [ISO 2019] defined an “asset” anything that has value to a stakeholder and a “digital asset” as one that that exists only in digital form or which is the digital representation of another asset. Similarly, a “Token” digital asset as representing a collection of entitlements. The tokenization of assets refers to the process of issuing a blockchain token (specifically, a security token) that digitally represents a real tradable asset—in many ways similar to the traditional process of securitization [Deloitte 2018]. A security token could thus represent an ownership share in a company, real estate, or other financial asset. These security tokens can then be traded on a secondary market. A security token is also capable of having the token-holder’s rights embedded directly onto the token, and immutably recorded on blockchain.

Recall that smart contracts started as an enhancement providing a programmable virtual machine in the context of blockchains, and the initial applications of blockchains were cryptocurrencies. Cryptocurrencies have been recognized as commodities for the purpose of regulations on derivatives like options and futures. High-value smart contracts on cryptocurrency derivatives require substantial legal protection and often utilize standardized legal documentation provided by the International Swaps and Derivatives Association (ISDA). Smart contracts managing cryptocurrency derivatives aim to automate many aspects of the provisions of the ISDA legal documentation [Clack 2019]. There have been a number of efforts to extend blockchains and smart contracts beyond cryptocurrency applications to manage other types of assets. Initially these were custom dApps, but as interest in smart contracts for specific types of assets grew, then a corresponding interest developed in having common token representations for particular types of asset, enabling broader interoperability, and reducing custom legal and development risks and costs. Rather than having specialized blockchains for supply chain provenance and other for smart derivatives contracts, different tokens representing those asset classes can be managed by a smart contract independently of the underlying blockchain technology.

Not all tokens are intrinsically valuable, many derive their value by reference from some underlying asset. [Bartoletti 2017] classifies smart contracts by application domain as financial, notary (leveraging the immutability of the blockchain to memorialize some data), games (of skill or chance), wallet (managing accounts, sometimes with multiple owners), library (for general purpose operations e.g. math and string transformations) and unclassified (The financial and notary categories had the most contracts.). The notary smart contracts enabled the smart contracts to manage non cryptocurrency assets. [Alharby 2018] classified smart contract literature using a keyword technique into: security, privacy, software engineering, application (e.g. IoT), performance & scalability and other smart contract related topics.  The application domains were identified as: Internet of Thing (IoT), cloud computing, financial, data (e.g., data sharing, data management, data indexing, data integrity check, data provenance), healthcare, access control & authentication and other applications. [Rouhani 2019] categorized decentralized applications in seven main groups include healthcare, IoT, identity management, record keeping, supply chain, BPM, and voting. However, the blockchain-based applications are not limited to these groups. Keywords and application identification, provide a view of the breadth of applications, but these are not exclusive or finite categories – new applications or keywords  can always be developed extending those lists. Token based music platforms have been proposed [Mouloud 2019]. Networked digital sharing economy services enable the effective and efficient sharing of vehicles, housing, and everyday objects utilizes a blockchain ledger and smart contracting technologies to improve peer trust and limit the number of required intermediaries, respectively [Fedosov 2018]. The tokenization of sustainable infrastructure can address some of the fundamental challenges in the financing of the asset class, such as lack of liquidity, high transactions costs and limited transparency [Uzoski 2019]. Tokens can also be useful from a privacy perspective. Tokenization, the process of converting a piece of data into a random string of characters known as a token, can be used to protect sensitive data by substituting non-sensitive data. The token serves merely as a reference to the original data; but does not determine those original data values. The advantage of tokens, from a privacy perspective, is that there is no mathematical relationship to the real data that they represent. The real data values cannot be obtained through reversal [Morrow 2019]. If the costs of tokenizing and marketing new asset classes are lower than costs of traditional securities offerings, then this can enable securitization of new asset classes. The ability to subdivide the some types of tokens may enable wider markets through reduced minimum bid sizes.

In 2004, early proposals were made for XML data type definitions to capture electronic contracts [Krishna 2004]. In 2015, the Ethereum developer community adopted ERC-20 (which specifies a common interface for fungible tokens that are divisible and not distinguishable) to ensure interoperability [Vogelsteller 2015]. While the initial token applications may have been for cryptocurrencies, blockchains (especially ethereum) are being applied in a lot of other domains, and so assets administered by the smart contracts are being stretched beyond their original purpose to enable new applications. Studies of trading patterns would need to distinguish whether those tokens were all being used to represent the same kind of asset to be able to make valid inferences about a particular market for that asset. Stretching beyond the fungible cryptocurrencies to enable popular new blockchain applications like tracking supply chain provenance requires a a different kind to token, a non-fungible token. Non-fungible tokens (NFTs) are a new type of unique and indivisible blockchain-based tokens introduced in late 2017 [Regner 2019]. The Ethereum community in 2018 adopted ERC-721 which extends the common interface for tokens by additional functions to ensure that tokens based on it are distinctly non-fungible and thus unique. [Entriken 2018].

In 2018, [FINMA 2018] identified 3 classes of tokens – payment tokens, asset tokens and utility tokens. A utility token as intended to provide access digitally to an application or service, by means of a blockchain-based infrastructure. This may include the ability to exchange the token for the service.

Token functions – payment {Utility, asset, yield}
Token features – stake rewards sole medium of exchange
Token distribution – Initial drops and reservations for miners and service providers

In 2019, [Hong 2019] proposed a non-fungible token structure for use in hyperledger, and [Cai 2019] proposed universal token structure for use in token based blockchain technology. Also in 2019,  an industry group, the Token Taxonomy Initiative, proposed a Token Taxonomy Framework [TTI 2019] in an effort to model existing and define new business models based on it. TTI defines a token as a representation of some shared value that is either intrinsically digital or a digital receipt or title for some material item or property and distinguishes that from a wallet which is a repository of tokens attributed to an owner in one or more accounts. TTI classifies tokens based on five characteristics they possess: token type (fungible or not), token unit (fractional, whole, singleton), value type (intrinsic or reference), representation type (common or unique), and template type (Single or hybrid). The base token types are augmented with behaviors and properties captured in a syntax (the token formula). Particular token formulae would be suitable for different business model applications – e.g. loyalty tokens, supply chain SKU tokens, securitized real property tokens, etc.   This Token Taxonomy Framework subsumes the functions, features and distribution aspects of the FINMA token model, enabling those regulatory perspectives as well as other properties of particular value in enabling different token-based business models.

The immutable, public Ethereum blockchain enables study of the trading patterns in ERC-20 tokens, revealing trading networks that display strong power-law properties (coinciding with current network theory expectations) [Soumin 2018]. Even though the entire network of token transfers has been claimed to follow a power-law in its degree distribution, many individual token networks do not: they are frequently dominated by a single hub and spoke pattern. When considering initial token recipients and path distances to exchanges, a large part of the activity is directed towards these central instances, but many owners never transfer their tokens at all [Victor 2019]. There is strong evidence of a positive relationship between the price of ether and price of the blockchain tokens. Token function does impact token price, over a time period that spans both boom and bust. The designed connection can be effective; linking a project that has a value, with a token that has a price, specifically in the absence of a legal connection or claim [Lo 2019]. From these preliminary studies, tokens seem to exhibit some of the trading properties of regular securities. Many of these initial tokens have no or untested legal connections to the underlying assets. While consistent behavior in boom and bust is important for an investment, from a legal perspective, the predictability of outcomes for asset recovery during more stressful events (e.g. bankruptcy) may be more important.

A point of concern is understanding how tokens representing value will remain linked to the real asset that they represent. For example, imagine if you own tokens representing a small fraction of a set of gold coins at a bank, and some coins are stolen. Or the reverse – who owns the gold coins if the account keys are lost or the token destroyed? Being able to rationally predict what happens to your token and to the other token owners is crucially important, since the value of tokens becomes greatly undermined if they cannot be proven to be linked to real-world assets [Deloitte 2018]. In these types of cases, off chain enforcement action is required. A typical legal tool for representing such interests in real assets would be recording security interests and liens in real property under the UCC.  One approach would be to update the lien recordings for the new owner after each transaction. There are at least two difficulties with this approach. First, the smart contract of today may not be able to interact with manual off-chain legal recordation processes for security interests. Secondly, if the purpose of tokenizing the asset was to increase liquidity, frequent transactions may result in a high volume of updates overloading off-chain manual recordation processes. Another approach would be to use some centralized custody agent (similar to physical custody) and have them hold the lien in the public records as a trustee (perhaps keeping account records reflecting updates from transactions on a blockchain). If the smart contract was a legal entity (e.g., a Vermont style BBLLC), then the BBLLC could be the entity with the security interest in the public records directly. However – the smart contract would need to be able to respond to legal actions on the lien; and may incur other obligations when acting as the custodian (e.g., reporting, insurance, licenses, etc.). The asset custodian as a traditional entity vs the BBLLC dApp provides alternatives for consideration. Traditional asset custodians provide an identifiable party from whom reparations can be sought in the event of asset loss or degradation. Asset custodians are commonly held to a fiduciary standard of care. A BBLLC approach emphasizes a digital distributed trust model; BBLLC’s, however, may be challenged with off-chain enforcement actions and physical custody operations (e.g., physical asset audits). BBLLC custodians may require insurance to protect asset owners in the event of asset losses/degradation.   

If ownership of an asset, such as a building, is split among thousands of people, there is little incentive for owners to bear the costs associated with that asset, such as maintenance and ensuring rent is collected [Deloitte 2018]. One can certainly imagine a smart contract detecting that rent has not been credit to an account, but what then can be done in terms of off-chain enforcement? While IoT blockchains can enable significant cyberphysical functionality, typical landlord capabilities of self-help and legal dispossessory actions would seem technically difficult or socially problematic. Some classes of contracts requiring off-chain enforcement actions may not be a good fit for complete implementation by dApp smart contracts at this stage; and may still require human physical agents or other legal entities for some actions.

Because the transaction of tokens is completed with smart contracts, certain parts of the exchange process are automated. For some classes of transactions, this automation can reduce the administrative burden involved in buying and selling, with fewer intermediaries needed, leading to not only faster deal execution, but also lower transaction fees [Deloitte 2018]. Elimination of intermediaries sounds financially efficient; eliminating all intermediaries, however, may not be wise for some classes of assets. An intermediate entity may be useful as a liability shield for remote owners. Consider a tokenized mobile asset (e.g., a drone or terrestrial vehicle) owned and operated via a smart contract, which injures another or their property; most remote owners would insist on some limited liability entity or insurance. While smart contract operated vehicles may not be computationally feasible in the short term, even immobile asset classes like real estate can result in liabilities for the owner (e.g., premises slip and fall).  The point being that for some set of physical asset classes, the existence of at least one intermediate entity for the purpose of liability shielding may be desirable.    

By tokenizing financial assets—especially private securities or typically illiquid assets—these tokens can be then be traded on a secondary market of the issuer’s choice, enabling greater portfolio diversification, and capital investment in otherwise illiquid assets. Tokenization could open up investment in assets to a much wider audience through reduced minimum investment amounts and periods. Tokens can be highly divisible, meaning investors can purchase tokens that represent incredibly small percentages of the underlying assets. If each order is cheaper and easier to process, it will open the way for a significant reduction of minimum investment amounts [Deloitte 2018]. Token markets to date have often been via exempt ICOs that are restricted to accredited investors, minimizing regulatory filings, etc. Investment minimums are unlikely a major driver for accredited investors, though enabling investment in diverse, but otherwise illiquid asset classes may be of interest for portfolio diversification. Enabling liquidity for mass market investors would require security token investments to meet the necessary higher regulatory standards for filings and disclosures to bring those investments to the larger public markets.

Smart contracts offer efficient process automation for trading and other transactions based on tokenized assets. While this can provide market efficiencies, not all asset classes are ready for tokenization without further consideration. Smart contracts may also need to take on additional behaviors to reflect the increased importance of their role in administering assets. Standardizing token formats and behaviors for different asset classes and business models should lead to improved interoperability, wider adoption, and more meaningful dialogs with regulators, investors and entrepreneurs.

References

[Alharby 2018] M. Alharby, et. al., “Blockchain-based smart contracts: A systematic mapping study of academic research (2018).” Proc. Int’l Conf. on Cloud Computing, Big Data and Blockchain. 2018.

[Bartoletti 2017] M. Bartoletti & L. Pompianu. “An empirical analysis of smart contracts: platforms, applications, and design patterns.” International conference on financial cryptography and data security. Springer, Cham, 2017.

[Buterin 2014] V. Buterin, “A next-generation smart contract and decentralized application platform.” white paper 3 (2014): 37.

[Cai 2019] T.Cai, et al. “Analysis of Blockchain System With Token-Based Bookkeeping Method.” IEEE Access 7 (2019): 50823-50832.

[Clack 2019] C. Clack, & C. McGonagle. “Smart Derivatives Contracts: the ISDA Master Agreement and the automation of payments and deliveries.” arXiv preprint arXiv:1904.01461 (2019).

[Deloitte 2018] Deloitte, “The tokenization of assets is disrupting the financial industry. Are you ready?  “ (2018)

[Entriken 2018] W. Entriken, et.al.,  ERC 721 Non-Fungible Token Standard (2018)

[Fedosov 2018] A. Fedosov, et. al., “Sharing physical objects using smart contracts.” Proceedings of the 20th Int’l Conference on Human-Computer Interaction with Mobile Devices and Services Adjunct. ACM, 2018.

[FINMA 2018] FINMA Guidelines for enquiries regarding the regulatory framework for initial coin offerings (ICOs), Report, Swiss Financial Market Supervisory Authority.

[Hong 2019] S. Hong, et. al., “Design of Extensible Non-Fungible Token Model in Hyperledger Fabric.” Proc. of the 3rd Workshop on Scalable and Resilient Infrastructures for Distributed Ledgers. ACM, 2019.

[ISO 2019] ISO, “Blockchain and distributed ledger technologies — Terminology”, ISO/DIS 22739:2019

[Krishna 2004] P. Krishna, et.al., “An EREC framework for e-contract modeling, enactment and monitoring.” Data & Knowledge Engineering51.1 (2004): 31-58.

[Lo 2019] Y. Lo, et. al., “Assets on the Blockchain: An Empirical Study of Tokenomics.” Available at SSRN 3309686 (2019).

[Migliorini 2019] S. Migliorini, et. al., “The Rise of Enforceable Business Processes from the Hashes of Blockchain-Based Smart Contracts.” Enterprise, Business-Process and Information Systems Modeling. Springer, Cham, 2019. 130-138.

[Morrow 2019] M. Morrow, & M. Zarrebini. “Blockchain and the Tokenization of the Individual: Societal Implications.” Future Internet 11.10 (2019): 220.

[Mouloud 2019] K. Mouloud, “Blockchain in the Music Industry: A Study of Token Based Music Platforms” S. Diss. Aalborg University, 2019.

[Soumin 2018] S. Somin, et. al., “Network analysis of erc20 tokens trading on ethereum blockchain.” International Conference on Complex Systems. Springer, Cham, 2018.

[Regner 2019] F. Regner, et.al., “NFTs in Practice: Non-Fungible Tokens as Core Component of a Blockchain-based Event Ticketing Application.” (2019).

[TTI 2019] Token Taxonomy Initiative“Token Taxonomy Framework Overview”, Nov 2019

[Uzoski 2019] Uzsoki, David. “Tokenization of Infrastructure.” (2019).

[Victor 2019] F. Victor, & B. Lüders, “Measuring Ethereum-based ERC20 token networks.” International Conference on Financial Cryptography and Data Security. Springer, Cham, 2019.

[Vogelsteller 2015] F.Vogelsteller & V. Buterin,  ERC-20 Token Standard (2015)

Defining and Scoping Smart Contracts

Much of the excitement in recent blockchain literature has been concerned with the potential for “smart contracts” executing autonomously on a blockchain, while (immutably) preserving transaction records. The first use of the “smart contract” term is generally credited to Szabo [Szabo 1997], [Szabo 2002]. [Gisler 2000] proposed requirements for electronic contracts to support legal aspects. Automated execution of electronic contracts predates blockchains and Nakamoto’s Bitcoin paper [Nakamoto 2008]. Automated trading systems were being discussed in the early 1990’s (see e.g., [Domowitz 1990]). Enterprise Resource Planning systems were being extended to detect actual and imminent contractual violations in the early 2000’s (see e.g., [Xu 2003]). XML proposals were made for capturing electronic contracts [Krishna 2004]. [Grigg 2004]’s Ricardian contracts proposal added parameters and prose beyond the code. A markup language for facilitating translating contracts from a human-oriented form into an executable representation for monitoring was developed by [Governatori 2005]. The availability of the solidity programming language in Ethereum [Buterin 2014] created additional momentum with a significant uptick in smart contract related publications starting in 2014 [Macrinici 2018].

The “smart contract” term, originally coined to refer to the general automation of legal contracts, seen a resurgence of interest due to the advent of blockchain technology. Given the variety of systems proposed and the complexity of the technologies underlying smart contracts it is difficult to evaluate many claims concerning their actual capabilities and real potential to change the commercial and legal landscape [Mik 2017]. Generally, smart contracts are computer protocols that implement the terms of a negotiated contract in a self-executing manner [Cieplak 2017]. Recently, the term is popularly used to refer to low-level code scripts running on a blockchain platform [Bartoletti 2017]. [van der Laan 2019] refers to smart contracts as applications that are deployed and executed on a blockchain’s decentralised infrastructure. [Rouhani 2019] considers the smart contract to be a programmable transaction that can perform a sophisticated task, execute automatically, and store on the blockchain. For [Di Angelo 2019a], smart contracts on a blockchain are programs running in a distributed, transparent, and trustless environment. Smart contracts for [Macrinici 2018], are essentially containers of code that encode and mirror the real-world contractual agreements in the cyber realm. Smart contracts are software programs featuring both traditional applications and distributed data storage on blockchains; acting as autonomous agents in critical decentralized applications according to [Praitheeshan 2019]. While the possibilities are endless, this does not help us decide whether a particular thing is or is not a smart contract.

More formally, [ISO 2019] recently defined a smart contract as a computer program stored in a distributed ledger system wherein the outcome of any execution of the program is recorded on the distributed ledger; noting, however, that a smart contract might represent terms in a contract in law and create a legally enforceable obligation under the legislation of an applicable jurisdiction. Some assets manageable by smart contracts (e.g., bitcoin) have been deemed commodities for regulatory purposes. Cryptocurrencies as blockchain applications also fit within this definition of a smart contract [Geirgat 2018]. A regulator [CFTC 2018] issued guidance on smart contracts describing them as fundamentally a set of computer functions, but also noted that they may incorporate elements of a binding (i.e., legally enforceable) contract. The International Swaps and Derivatives Association (ISDA) defines [Clack 2019] a smart contract as an automatable and enforceable agreement; automatable by computer, although some parts may require human input and control; enforceable either by legal enforcement of rights and obligations or via tamper-proof execution of computer code. Blockchain technology provides a platform for the decentralized execution of smart contracts. The class of programs executing in a decentralized manner and storing results in a blockchain includes smart contracts; not all such blockchain decentralized applications (dapps), however, are required to have any association with a contract; nor are autonomous programs executing legal contracts required to be decentralized. For the purposes of most technology-focused discussions, it would be less confusing to refer to dapps rather than smart contracts unless the dapp is envisaged as fulfilling some specific contractual function.

As computer code, a smart contract executes in the context of a particular virtual machine supported by a particular blockchain. Smart contracts can invoke other smart contracts executing in the same or other blockchains. Not all data sources for the smart contract are natively found in the environment of a single blockchain. A smart contract is an agreement that is automatically executed when certain conditions are met [Fournier 2019]. “Oracles” provide a mechanism for off-chain data to be made available for the smart contract executing in the blockchain. Many early smart contracts have been focused on financial applications. Off-chain financial data inputs to a smart contract might be prices of assets, or confirmation of trades from other blockchains, e.g. in an exchange between bitcoin and some other cryptocurrency. Hence, we can conclude that a smart contract executing in one particular blockchain environment may have input/output operations on its own blockchain or on an arbitrary number of other blockchains.

A key feature of smart contacts is the autonomous algorithmic execution based on a mapping of certain detectable states of nature to corresponding contractual actions [Bakos 2019]. With the advent of IoT blockchains, a broad range of cyber-physical data from sensors can become an input to smart contracts. To release their potential, it is necessary to connect the contracts with the outside world, such that they can understand and use information from other infrastructures [Guarnizo 2019]. Beyond financial applications, blockchains are also being proposed to control devices in the physical world [Lee 2019]. This implies that blockchain smart contracts could be used to control not just digital assets, but also physical devices.  A smart contract is not required by its definition to have physical I/O. hence smart contracts may have [0..n] inputs or outputs in the physical world.

All blockchains have performance limitations due to the computational and communication overheads of such decentralized systems. A blockchain execution environment, may not be the most suitable for all classes of workloads. The time for deployment and computation (including consensus) in blockchains may be significantly larger than in (non-blockchain) off-chain systems. Some blockchains also have an explicit cost for transactions (and computations) on chain (e.g., Ethereum gas). Computations on blockchains are reportedly cost two orders of magnitude more than regular cloud computing [Rimba 2017]. This has resulted in architecture proposals (e.g. [Eberhardt 2017], [Gudgeon 2019]) where the smart contract computation is moved off-chain and only the result is recorded in some transaction on the blockchain. Building on cloud computing concepts, Blockchain as a Service (BaaS) has been proposed to improve the productivity of application development, including support for smart contract design services [Lu 2019]; such an approach architecturally separates the smart contract from the underlying blockchain. In the typical case, the smart contract executes in the virtual machine of one blockchain. A “smart contract” executing entirely off-chain might be better referred to as an electronic contract; in general, such electronic contracts could execute in an arbitrary number of off-chain devices. A smart contract developed and deployed through blockchain as a service may be deployed and executed across an arbitrary number of blockchains.

Number of blockchains as I/O 1..n
Number of cyber-physical devices as I/O 0..n
Number of on blockchains where executing 0..n
Number of off-chain nodes where executing 0..n

Automation of trading functions and contractual obligations has been discussed in the literature for more than 20 years. The availability of blockchains with cryptographic transaction signatures and robust, immutable, decentralized transaction databases has given the topic additional impetus. General-purpose programming languages operating over blockchains have expanded the potential applications for blockchains. Flexibility can be helpful but also generates complexity in operation and administration. Not all dapps are smart contracts; code to automate and enforce an agreement does not always require an underlying blockchain. Smart contracts are not just algorithms, they can, and increasingly are, connected into our cyber-physical reality. Other computing systems have had such capabilities generating physical effects for some time. With smart contracts, these systems now have added contractual legal effects as well. 

References

[Bakos 2019] Y. Bakos, & H. Halaburda. “When Do Smart Contracts and IoT Improve Efficiency? Automated Execution vs. Increased Information.” Automated Execution vs. Increased Information (May 26, 2019). NYU Stern School of Business (2019).

[Bartoletti 2017] M. Bartoletti & L. Pompianu. “An empirical analysis of smart contracts: platforms, applications, and design patterns.” International conference on financial cryptography and data security. Springer, Cham, 2017.

[Buterin 2014] V. Buterin, “A next-generation smart contract and decentralized application platform.” white paper 3 (2014): 37.

[CFTC 2018] LabCFTC, “A Primer on Smart Contracts”, November 208.

[Cieplak 2017] J. Cieplak, & S. Leefatt. “Smart Contracts: A Smart Way to Automate Performance.” Geo. L. Tech. Rev. 1 (2017): 414-418.

[Clack 2019] C. Clack, & C. McGonagle. “Smart Derivatives Contracts: the ISDA Master Agreement and the automation of payments and deliveries.” arXiv preprint arXiv:1904.01461 (2019).

[DiAngelo 2019a] M. Di Angelo & G. Salzer. “Mayflies, Breeders, and Busy Bees in Ethereum: Smart Contracts Over Time.” Third ACM Workshop on Blockchains, Cryptocurrencies and Contracts (BCC’19). ACM Press, 2019.

[Domowitz 1990] I. Domowitz, “The mechanics of automated trade execution systems.” Journal of Financial Intermediation 1.2 (1990): 167-194.

[Eberhardt 2017] J. Eberhardt, & S. Tai. “On or off the blockchain? Insights on off-chaining computation and data.” European Conference on Service-Oriented and Cloud Computing. Springer, Cham, 2017.

[Fournier 2019] F. Fournier, & I. Skarbovsky. “Enriching Smart Contracts with Temporal Aspects.” International Conference on Blockchain. Springer, Cham, 2019.

[Geiregat 2018] S. Geiregat, “Cryptocurrencies are (smart) contracts.” Computer law & security review 34.5 (2018): 1144-1149.

[Gisler 2000] M. Gisler, et. al., “Legal Aspects of Electronic Contracts.” ISDO. 2000.

[Governatori 2005] G. Governatori,”Representing business contracts in RuleML.” International Journal of Cooperative Information Systems 14.02n03 (2005): 181-216.

[Grigg 2004] I. Grigg, “The ricardian contract.” Proc. First Int’l Workshop on Electronic Contracting, IEEE, 2004.

[Guarnizo 2019] J. Guarnizo, & P. Szalachowski. “PDFS: practical data feed service for smart contracts.” European Symposium on Research in Computer Security. Springer, Cham, 2019.

[Gudgeon 2019] L. Gudgeon, et al. “SoK: Off The Chain Transactions.” IACR Cryptology ePrint Archive 2019 (2019): 360.

[ISO 2019] ISO, “Blockchain and distributed ledger technologies — Terminology”, ISO/DIS 22739:2019

[Krishna 2004] P. Krishna, et.al., “An EREC framework for e-contract modeling, enactment and monitoring.” Data & Knowledge Engineering51.1 (2004): 31-58.

[Lee 2019] J. Lee, et. al., “A blockchain enabled Cyber-Physical System architecture for Industry 4.0 manufacturing systems.” Manufacturing Letters 20 (2019): 34-39.

[Lu 2019] Q. Lu, et al. “uBaaS: A unified blockchain as a service platform.” Future Generation Computer Systems (2019).

[Macrinici 2018] D. Macrinici, et. al., “Smart contract applications within blockchain technology: A systematic mapping study.” Telematics and Informatics 35.8 (2018): 2337-2354.

[Mik 2017] E. Mik, “Smart contracts: terminology, technical limitations and real world complexity.” Law, Innovation and Technology, 9.2 (2017): 269-300.

[Nakamoto 2008] S. Nakamoto,  “Bitcoin: A peer-to-peer electronic cash system.” (2008).

[Praitheeshan 2019] P. Praitheeshan, et al. “Security analysis methods on Ethereum smart contract vulnerabilities: A survey.” arXiv preprint arXiv:1908.08605 (2019).

[Rimba 2017] P. Rimba, et al. “Comparing blockchain and cloud services for business process execution.” 2017 IEEE International Conference on Software Architecture (ICSA). IEEE, 2017.

[Rouhani 2019] S. Rouhani, & R. Deters. “Security, Performance, and Applications of Smart Contracts: A Systematic Survey.” IEEE Access 7 (2019): 50759-50779.

[Szabo 1997] N. Szabo, The Idea of Smart Contracts, Nick Szabo’s Papers and Concise Tutorials   (1997)

[Szabo 2002] N. Szabo, “A Formal Language for Analyzing Contracts”, Nick Szabo’s Papers and Concise Tutorials   (2002)

[van der Laan 2019] B. van der Laan, et. al., “MUSCLE: authenticated external data retrieval from multiple sources for smart contracts.” Proc. of the 34th ACM/SIGAPP Symposium on Applied Computing. ACM, 2019.

[Xu 2003] L. Xu & M. Jeusfeld. “Pro-active monitoring of electronic contracts.” Int’l Conference on Advanced Information Systems Engineering. Springer, Berlin, Heidelberg, 2003.

Cryptocurrencies as Commodities: A Primer

Bitcoins can be considered an asset or speculative investment rather than a currency [Yermack 2013]. The tradability of Bitcoin units on specialized trading platforms has made practical for investment professionals. The launch of Bitcoin-linked funds by global investment banks increased the accessibility to the Bitcoin market. Importantly, the launch of futures contracts based on Bitcoin prices in late 2017 enhanced the legitimacy of Bitcoin as an investment and moved it into the mainstream of the financial world. Gold, and to a lesser extent, commodities, in general, act as effective diversifiers against the downside risk in equity markets (for both advanced and emerging economies). Investors purchase bullion with gold futures and exchange-traded funds, and are thus exposed to the price variation in gold, and a hedge against stock price volatility. The oil market is one of the most volatile commodity markets.  In a derivatives marketplace, individuals and businesses everywhere are able to lock in a future price by putting it into a binding contract. These products are called futures and options – contractual agreements to buy or sell an amount of something at a fixed price at a future date. When people and companies come to futures exchanges to buy and sell commodities and financial products, what they’re really trying to do is remove risk from their business or make money as an investor when prices fluctuate. An investment asset which provides not just diversification, but also a safe haven during stress periods is particularly valuable in construction of an investment portfolio.  Various market indices are used to benchmark commodity trades. The S&P Goldman Sachs Commodity Index (GSCI), is a world production-weighted index including 24 exchange-traded futures contract commodities from five sectors -energy products, industrial metals, agricultural products, agricultural and livestock products, and precious metals. This is a widely tracked benchmark commodity index and the most liquid commodity futures index and can play the role of a diversifier asset. It can also be used as a measure of general price movement and inflation in the world economy. Bitcoins were the first virtual currency and consequently much of the regulatory discussions have been framed in terms of bitcoin, though other blockchain applications may have quite different characteristics and uses. In the following section the terminology related to futures, options and swaps is reviewed. The US regulatory framework for commodities is then briefly summarized, and recognized roles in commodity markets noted. The current US regulatory framework for commodities recognizes virtual currencies as a commodity, enabling the issuance of futures and options on these currencies. Some of the effects of this as a financial asset are then considered. This article concludes with some recent controversies arising from this regulatory treatment of crypto currencies as commodities.

Futures, Options & Swaps Terminology

Clearing: The procedure through which a Clearing House becomes the buyer to each seller of a futures contract and the seller to each buyer. The Clearing House assumes the responsibility of ensuring that each buyer and seller performs on each contract. Futures exchanges process millions of trades each day. With so many orders coming at once, you need a lot of checkpoints to make sure everything goes smoothly.

Clearing firm: A company that works directly through an exchange’s Clearing House to execute trades on behalf of futures market participants.  clearing firms check the financial strength of both parties to the trade, whether they’re a big institution or an individual trader. They also provide access to trading platforms, where the buyer and seller agree on the price, quantity, and maturity of the contract. Then, when the contract is cleared by matching these offsetting (one buy, one sell) positions together, the Clearing House guarantees that both buyer and seller get paid. This offsetting or “netting” process takes risk out of the financial system as a whole.

Clearing House: The division of a futures exchange that confirms, clears and settles all trades through an exchange. Clearing Houses act as a neutral counterparty for every single trade that crosses a futures exchange, assuming responsibility for ensuring buyer and seller performance on each contract.

Commodity: Any product approved and designated for trading or clearing in accordance with the rules of an exchange. Also: may refer to a physical commodity.

Counterparty: The individual or company (i.e., the buyer or seller) on the opposite side of any trade.

Delivery: The changing of ownership or control of a commodity once a futures contract date expires.

Derivative: A financial instrument, such as a futures or options contract, whose value is based upon a physical commodity or other financial instruments.

Exchange: A central marketplace with established rules and regulations where buyers and sellers meet to trade futures and options contracts.

Financial Future: A future contract whose value is based upon financial instruments such as a stock index, interest rates or foreign currency exchange rates. Generally, three types of financial futures – foreign currency market, interest rate market, equity index market.

Future: A standardized contract for the purchase and sale of financial instruments or physical commodities on a futures exchange for future delivery.

Futures Exchange: A central marketplace where buyers and sellers come together to trade futures and options contracts.

Hedge: To buy or sell a futures contract in order to lock in the price of the underlying commodity at a later date.

Option: A contract that gives the bearer the right, but not the obligation, to buy or sell a futures contract at a specified price within a specified time period.

Over-The-Counter Derivative: Futures and options contracts with terms that do not necessarily adhere to those of a standardized futures contract.

Over-The-Counter Trading: Trades that take place outside of a formal futures exchange. OTC derivatives let traders go beyond standardized futures products and customize the terms of the contracts they trade. Usually, the traders work through a network of dealers who negotiate these agreements on a one-to-one basis. Though it offers greater freedom and potentially lower trading costs, OTC trading may leave both parties at risk for counterparty default if they are not using the services of a clearing house.

Self-Regulatory Organization: (SRO) Futures exchanges and regulatory entities that set rules and regulations and have internal functions that perform complex checks and balances to adhere to the principles they set.

Settlement: The delivery of cash or commodities in exchange for payment, as specified by the terms of the underlying contract.

US Regulatory Framework for Commodities

The Commodity Exchange Act (1936) (CEA) provides for Federal regulation of all commodities and futures trading activities. It requires all futures and commodity options to be traded on organized exchanges. The CFTC was created by the Act and its powers substantially revised in the Commodity Futures Trading Commission Act (1974) which expanded the scope beyond listed agricultural products. The mission of the U.S. Commodity Futures Trading Commission is to promote the integrity, resilience, and vibrancy of the U.S. derivatives markets through sound regulation. A trillion-dollar market for interest rate and currency swaps emerged in the 1980s. These transactions were similar to forward delivery futures contracts for agricultural commodities. The Futures Trading Practices Act (1992) gave the CFTC the power to exempt some transactions from the requirement for exchange trading. The Commodity Futures Modernization Act (CFMA) [ CMFA 2000] modernized regulations for over the counter (OTC) transactions between “sophisticated parties” so these would not be regulated as “commodities” under CEA or “securities” under federal securities laws. The definition of “commodity” in the CEA is broad. It can mean a physical commodity, such as an agricultural product (e.g., wheat, cotton) or natural resource (e.g., gold, oil). It can mean a currency or interest rate. The CEA definition of “commodity” also includes “all services, rights, and interests . . . in which contracts for future delivery are presently or in the future dealt in.” Beyond instances of fraud or manipulation, the CFTC generally does not oversee “spot” or cash market exchanges and transactions involving virtual currencies that do not utilize margin, leverage, or financing. The CFTC looks beyond form and considers the actual substance and purpose of an activity when applying the federal commodities laws and CFTC regulations

The CFTC’s Advisory Committees were created to provide input and make recommendations to the Commission on a variety of regulatory and market issues that affect the integrity and competitiveness of U.S. markets. The committees facilitate communication between the Commission and U.S. futures markets, trading firms, market participants, and end-users. The committees currently include: 

LabCFTC is the focal point for the CFTC’s efforts to promote responsible FinTech innovation and fair competition for the benefit of the American public. LabCFTC is designed to make the CFTC more accessible to FinTech innovators. It serves as a platform to inform the Commission’s understanding of new technologies. Further, LabCFTC is an information source for the Commission and the CFTC staff on responsible innovation that may influence policy development. There are two major components of LabCFTC- Guidepoint and CFTC 2.0

GuidePoint accepts a wide range of inquiries ranging from specific registration or compliance requirements to broader questions about the CFTC’s regulatory framework – e.g., how it may accommodate new systems, business models, or services made possible through responsible FinTech innovation. Within the CFTC, inquiries may be referred to the appropriate groups and subject matter experts with the aim to ensure that any response is both accurate and tailored to the entity’s circumstances.

CFTC 2.0 is intended to provide the agency opportunities to engage with new technologies to discover ideas and technologies that have the potential to improve the effectiveness and efficiency of the agency in carrying out its day-to-day activities.

The CFTC has published a number of documents as guidance on Cryptocurrencies:

The CFTC first found that Bitcoin and other virtual currencies are properly defined as commodities in 2015. In the Matter of: Coinflip, Inc., d/b/a Derivabit, and Francisco Riordan, CFTC Docket No. 15-29 (Section 1a(9) of the Act defines “commodity” to include, among other things, “all services, rights, and interests in which contracts for future delivery are presently or in the future dealt in.” 7 U.S.C. § 1a(9). The definition of a “commodity” is broad. See, e.g., Board of Trade of City of Chicago v. SEC, 677 F. 2d 1137, 1142 (7th Cir. 1982)). Bitcoin and other virtual currencies are encompassed in the definition and properly defined as commodities. CFTC authority to regulate virtual currency as a commodity was affirmed in CFTC v. McDonnell  (2018). The CFTC has a number of other causes of action it can pursue, e.g., Price manipulation of a virtual currency traded in interstate commerce; pre-arranged or wash trading in an exchange-traded virtual currency swap or futures contract; certain schemes involving virtual currency marketed to retail customers, such as off-exchange financed commodity transactions with persons who fail to register with the CFTC. CFTC has had several successful prosecutions for ponzi schemes in the context of virtual currency (e.g., CFTC v Dean ,CFTC vs My Big Coin Pay Inc.) and for  future exchanges not registered with the CFTC as a SEF or DCM  (e.g., In re BXFNA Inc. d/b/a Bitfinex, Dkt. No. 16-19 ).

The National Futures Association (NFA) is the industrywide, self-regulatory organization for the U.S. derivatives industry. Designated by the CFTC as a registered futures association, NFA strives to safeguard the integrity of the derivatives markets, protect investors and ensure their members meet their regulatory responsibilities. NFA’s formal designation as a “registered futures association” was granted by the CFTC on September 22, 1981. NFA began its regulatory operations in 1982. CFTC regulations also require, with few exceptions, CFTC registered firms to be NFA Members. The CFTC has delegated registration responsibility to NFA. The NFA requires additional reporting on virtual currency transactions:

Internationally, the International Swaps and Derivatives Association (ISDA) has a similar role to NFA; reducing counterparty credit risk, increasing transparency, and improving the industry’s operational infrastructure in support of its primary goals; to build robust, stable financial markets and a strong financial regulatory framework. While not specifically focussed on cryptocurrencies, ISDA has published a number of documents related to smart contracts.

Recognized Roles in Commodity Markets

NFA Commodity Pool Operator (CPO) A commodity pool operator (CPO) is an individual or organization that operates a commodity pool and solicits funds for that commodity pool. A commodity pool is an enterprise in which funds contributed by a number of persons are combined for the purpose of trading futures contracts or options on futures, retail off-exchange forex contracts, or swaps, or to invest in another commodity pool.

NFA Commodity Trading Adviser (CTA) A commodity trading advisor (CTA) is an individual or organization that, for compensation or profit, advises others, directly or indirectly, as to the value of or the advisability of buying or selling futures contracts, options on futures, retail off-exchange forex contracts or swaps. Indirect advice includes exercising trading authority over a customer’s account or giving advice through written publications or other media.

On-exchange trading is the trading of commodities and contracts that are listed on an exchange. Off-exchange trading, also known as over-the-counter (OTC) trading, is the trading of commodities, contracts or other financial instruments that are not listed on-exchange. Off-exchange trading can occur electronically or over the phone. Some foreign currency (forex) contracts are traded off-exchange.

Designated Contract Market (DCM) – an exchange that may list for trading futures or option contracts based on all types of commodities and that may allow access to their facilities by all types of traders, including retail customers. Some DCMs have been operating for many years as traditional futures exchanges, while others are new markets that were only recently designated as contract markets by the CFTC. CFTC staff perform regular reviews of each DCM’s ongoing compliance with the required core principles called Rule Enforcement Reviews.  CFTC maintains a List of DCMs.

Derivatives Clearing Organization (DCO) – an entity that enables each party to an agreement, contract, or transaction to substitute, through novation or otherwise, the credit of the DCO for the credit of the parties; arranges or provides, on a multilateral basis, for the settlement or netting of obligations; or otherwise provides clearing services or arrangements that mutualize or transfer credit risk among participants. A DCO that seeks to provide clearing services with respect to futures contracts, options on futures contracts, or swaps must register with the CFTC before it can begin providing such services. The CFTC maintains a List of DCOs.

Futures Commission Merchant (FCM) – an intermediary that solicits or accepts orders for futures or options contracts traded on or subject to the rules of an exchange; and in or in connection with such solicitation or acceptance of orders, accepts money, securities, or property (or extends credit in lieu thereof) to margin, guarantee, or secure any trades or contracts that result or may result.

Introducing Broker (IB) – an intermediary that solicits or accepts orders for futures or options contracts traded on or subject to the rules of an exchange; and does not accept any money, securities, or property (or extend credit in lieu thereof) to margin, guarantee, or secure any trades or contracts that result or may result.

Swap Execution Facilities – Section 733 of the Dodd-Frank Wall Street Reform and Consumer Protection Act (“Dodd-Frank Act”) adopts new Section 5h of the Commodity Exchange Act (“CEA”), which provides that no person may operate a facility for the trading or processing of swaps unless the facility is registered as a swap execution facility (“SEF”) or as a designated contract market (“DCM”). The CFTC maintains a List of SEFs.

Effects of Cryptocurrency Commoditization

Several organizations (e.g., Cantor Exchange, CBOE Futures Exchange (CFE), Chicago Mercantile Exchange (CME). LedgerX, Nadex, TeraExchange) had registered with the CFTC as exchanges for Bitcoin Futures, Options or swaps. The Chicago Board Options Exchange (CBOE) has announced that it is dropping any new bitcoin futures contracts (XBT). This may have been due to low trading volumes. Bitcoin futures (BTC) are still live at CME. You can hedge Bitcoin exposure or harness its performance with a futures product. Based on the growing interest in cryptocurrencies and a strong demand for more tools to manage bitcoin exposure, CME Group plans to launch options on Bitcoin futures (BTC) in early 2020. The CME settles its contracts against an index called BRR (Bitcoin reference rate) which is an average of spot prices quoted on different exchanges. CME created a Bitcoin Reference Rate (BRR) and CME Bitcoin Real-Time Index (BRTI) as a standardized reference rate and spot price index, respectively, with independent oversight to accelerating the professionalization of bitcoin trading. CME has been generating BRR and BRTI rates since November 2016 with several bitcoin exchanges and trading platforms providing pricing data, including Bitstamp, Coinbase, itBit, Kraken, and Gemini. (See CME’s Bitcoin Reference Rate Analysis). Note that trading in Bitcoin futures doesn’t imply trading in Bitcoin itself. Bitcoin Futures Quotes are available online from the CME.

While the commodity markets for crude oil and gold are characterized by considerable short-run supply-side uncertainty (e.g., political events, surprise discoveries, and technological developments).  Uncertainty of this type does not exist on the supply-side of Bitcoin. Thus, the observed price fluctuations of Bitcoin can be interpreted as demand shocks. [Ali 2014)] asserted that “digital currencies have meaning only to the extent that participants agree that they have meaning.” A change in this “meaning” due to changes in demand is not different from a demand shock in the crude oil market. Empirical analysis reveals that Bitcoin price dynamics are particularly influenced by extreme price movements. This influence is found to be larger than in the markets for crude oil and gold. Among the explanations for this is certainly the immaturity of the market [Gronwald 2019]. Cryptocurrencies have taken a further step in the direction of commodities with the emergence of cold storage [Geman 2019]. Cold storage means generating and storing the crypto coins’ private keys in an offline environment in order to avoid the online vulnerability to hacking. The most popular cold storage options are:

a) A paper wallet containing a pair of private/public keys printed on a piece of paper, with keys generated offline securely;

b) A hardware wallet is an electronic device, but the most robust cold storage choice for cryptos. The three popular options offered on the market are Ledger Nano, Trezor and Keepkey;

c) A USB drive can also be a cold wallet, easy to obtain but with the risk that anyone having access to the USB can access the crypto

Call options give buyers the possibility of getting a financial exposure to Bitcoin prices while puts provide the classical protection to those owning the cryptocurrency. Bitcoin futures were launched by the Chicago Board of Options Exchange and the Chicago Mercantile Exchange group on December 18th, 2017. The total market capitalization of all cryptocurrencies was 828 billion dollars in January 2018 (just after two Exchanges launched futures), 200 billion in August 2018 and 272 billion in September 2019. Note that the fraction of bitcoin in the total market capitalization was 86% in January 2017, went to 34% in January 2018 and back to 68% in September 2019. Futures trading drove up the price of Bitcoin immediately after the announcement day. This reaction started to decrease noticeably following the launch of the futures contracts. Such an outcome seems in line with the trading behavior that typically accompanies the launch of futures markets for an asset. [Bouoiyou 2019]. CME Futures are subject to significant regulatory oversight by the (CFTC), and are protected from counterparty risk by the Clearing House of the Exchange. This is a desirable feature since more than 36 cryptocurrency trading venues had closed by the end of December 2018. Moreover, they partly allow avoiding the fragmentation that sometimes prevailed in the Bitcoin spot market: during periods of high volatility, prices observed for Bitcoins on different platforms over identical time periods could diverge by more than 10%. Storability and convenience yield enables the derivation of a (valuable) spot-forward relationship. Applying the traditional options pricing mechanism of the Black-Scholes Model in this setting provides bounds on option prices [Geman 2019].

Some commodities provide diversification benefits while others may not be useful for portfolio diversification.  Bitcoin adds portfolio diversification benefits above and beyond other commodities. The correlation between bitcoin and other assets is exceptionally low and the inclusion of bitcoin dramatically improves the risk-adjusted returns of the portfolios. Bitcoin’s inclusion in optimal portfolios leads to a better risk-return ratio. Bitcoin can play an important role in enhancing the efficiency of an investor’s portfolio. These findings are robust to expanding and rolling estimation windows, transaction costs, the 2018 downturn in Bitcoin, different values of risk aversion, alternative indices, as well as to alternative portfolio construction techniques and to simulated data and when short selling is permitted, although the analysis is still based on the historical mean asset returns as return forecasts and the historical return variances and covariances [Platanakis 2019]. Historical returns, however, can be poor estimates of future returns, especially given Bitcoin prices’ large volatility. The inclusion of Bitcoin (BTC) in oil, gold, and equity portfolios substantially reduced the portfolio risk. BTC and gold markets have respectively negative and weak conditional correlations with oil. The correlation between S&P GSCI and BTC as well as gold is close to zero. [Al-Yahyaee 2019]. The Dollar is a better alternative to hedge oil implied volatility (OVX) than Bitcoin. Bitcoin outperforms gold and commodity in hedging OVX. Bitcoin is a better hedge to demand-side oil shocks in comparison to the Dollar. Bitcoin hedges the demand-side shocks better that supply-side shocks [Das 2019]. This does not necessarily mean that Bitcoin is a superior asset over others to hedge oil-related uncertainties. The hedging capacity of different assets is conditional upon the nature of commodity risks and market situation. A single asset cannot hedge downside risks in different economic situations and market states.  Investors may prefer different investment instruments to hedge downside risks in different economic situations and market states.

An asset is labeled a strong safe-haven if there is evidence of predictability from a stock index to that asset in the low quantiles of both the stock and the asset returns, and the sign of this predictability is negative. This ensures that extreme negative stock returns are followed by future positive returns in the (safe-haven) asset, i.e. the movement of the (safe-haven) asset in the opposite direction of that of the stock index ensures that the losses occurring in stock investments are counterbalanced. In contrast, an asset is labeled a weak safe-haven if there is no evidence of predictability from a stock index to that asset in the low quantiles of both the stock and the asset returns [Shahzad 2019]. Bitcoin, gold, and commodities have a similarity in their weak safe-haven properties for the world stock market index, which is not the case for the developed, emerging, US, and Chinese stock markets. In fact, gold is the only weak safe-haven asset in developed stock markets, whereas both gold and commodities play that role in emerging stock markets. Interestingly, Bitcoin shares with commodities the weak safe-haven property in China, whereas commodities are the only weak safe-haven asset in the US [Shahzad 2019a]. While futures on virtual currencies have facilitated trading in this asset class, regulatory ambiguity on the treatment of the underlying assets also impedes its viability as a safe haven.

      With cryptocurrencies becoming more connected and more prominent within the system, the nature of information spillovers changes over time. The role of energy commodities, in contrast, is dependent on their price dynamics. Cryptocurrencies are integrated within broadly-defined commodity markets. From a theoretical point of view, different information channels and factors may play a role in forming a connection between the cryptocurrency market and the commodity markets. One correlated-information channel through which connections occur is via the price-discovery process. A second is the risk premium channel, through which a shock in one market may adversely affect the willingness of market participants to hold risk in any market. Industry-specific development may provide additional information linkages (e.g. A blockchain platform has been established to facilitate trade in crude oil between commodity firms). Potential linkages between energy and Bitcoin markets have been based on the rationale that energy, in the form of electricity, is the main cost of Bitcoin production (i.e., for mining). Commodities enjoy a strong network structure that is also intertwined with financial assets. Increasing connectedness [Ji 2019] between commodity and cryptocurrency markets weakens the attractiveness of portfolio diversification across these markets:

  • energy and agricultural commodities are the driving forces of the whole commodity system.
  • cryptocurrencies are not detached from the system and are more connected to the global commodity markets than are metals (including gold).
  • cryptocurrencies are not strongly affected by energy commodities, which goes against the basic idea that electricity prices form an important part of cryptocurrency production costs.
  • cryptocurrencies become more connected to and more important within the overall commodity network over time.
  • energy commodities become less important over time as they are evidently connected to the price dynamics of crude oil as a representative commodity.
  • the portfolio management role of cryptocurrencies as diversifiers is not necessarily as strong as is commonly believed, at least during times of general asset appreciation.

Controversies from the Commoditization of Cryptocurrencies

            [Kogan 2019] argues that the holding in CFTC vs McDonnell is overly broad. Many virtual currencies are designed for drastically different purposes, with distinct technological protocols. The term “virtual currency” encompasses many different, independently developed applications of distributed ledger technology. Need to distinguish between virtual currencies, cryptocurrencies, tokens, digital currencies – the court used a virtual currency definition as simply a digital representation of value that exists solely online, has no government legal tender status and can be traded as a medium of exchange, a unit of account or a store of value. The agency’s regulatory authority under CEA should not include services and tokens that cannot underlay DCM transactions, but the court decision would appear to grant that authority. For example, smart contracts running on a blockchain would appear to fall within the court’s definition. The CFTC has not directly addressed how liability for Commodity Exchange Act (CEA) violations involving blockchain or distributed ledger technology should be allocated among the various parties involved in the distributed ledger network, such as the network itself, persons running consensus nodes, developers building applications on the platform, and businesses and end-users using such applications [Mathews 2019].

CFTC regulation requires that any new contract not be readily susceptible to manipulation, but a careful review of the record indicates that bitcoin futures are susceptible to manipulation because the bitcoin spot market can be manipulated. In reviewing the contracts leading up to their self-certification, [Reiners 2019] argues that the CFTC ignored underlying dynamics in the bitcoin spot market and chose to exclusively focus on the ability of the contracts themselves to be manipulated; doubting that a futures contract can be resistant to manipulation when the asset underlying the contract is readily manipulated. The price of bitcoin varies depending on the exchange it trades on, and some exchanges have very low volume, so CME carefully constructed a reference rate for their futures contracts that could not be manipulated. The Securities and Exchange Commission (“SEC”), in contrast, took a different approach when reviewing a proposal for a bitcoin exchange-traded product and concluded that manipulation in the bitcoin spot market precluded any kind of exchange-traded product tied to bitcoin. The CFTC has very little jurisdiction over the cash market— the trading of Bitcoin or other crypto-assets that are not securities for cash (or other crypto-assets that are not securities). That’s where most of the trading of Bitcoin and other cryptocurrencies takes place today. The agency can pursue cases of fraud and manipulation in the cash market. It can also bring actions pertaining to retail leveraged trades where there is a failure to deliver the commodity—that has been the basis for some enforcement actions. as a general matter, it cannot set oversight standards for the cash market in crypto-assets as it does with derivatives on those crypto-assets. The cash market for crypto-assets—which is where most of the trading takes place today—does not have well-developed standards. This is a problem for oversight generally and for the quality of crypto derivatives: if the underlying cash market is susceptible to (or characterized by) fraud and manipulation, then what confidence can one have in the derivatives?  [Massad 2019]. Blockchain technologies and cryptocurrencies in particular, are variously treated as commodities, securities, property by different governmental agencies [Goforth 2019]. The list of governmental agencies impacted by cryptocurrency concerns goes beyond the CFTC to include the SEC, FBI, Treasury, IRS etc. Resolving the regulatory ambiguity and jurisdictional boundaries seems likely to take some time.

References

[Al-Yahyaee 2019] K. Al-Yahyaee, et al. “Volatility forecasting, downside risk, and diversification benefits of Bitcoin and oil and international commodity markets: A comparative analysis with yellow metal.” The North American Journal of Economics and Finance 49 (2019): 104-120.

[Ali 2014] R. Ali, et. al., “The economics of digital currencies.” Bank of England Quarterly Bulletin (2014): Q3.

[Bouoiyour 2019] J. Bouoiyour, & R. Selmi. “How do futures contracts affect Bitcoin prices?.” (2019).

[CEA 1936] Public Law 74-675, 74th Congress, H. R. 6772: Commodity Exchange Act

[Das 2019] D. Das, et. al., “Does Bitcoin hedge crude oil implied volatility and structural shocks? A comparison with gold, commodity and the US Dollar.” Finance Research Letters(2019): 101335.

[Geman 2019] H. Geman, & H. Price. “Bitcoin Futures and Option Markets: Searching for Completeness.” Available at SSRN 3457167 (2019).

[Goforth 2019] C. Goforth, “US Law: Crypto Is Money, Property, A Commodity, And A Security, All At The Same Time.” Journal of Financial Transformation 49 (2019): 102-109.

[Gronwald 2019] M. Gronwald, “Is Bitcoin a Commodity? On price jumps, demand shocks, and certainty of supply.” Journal of International Money and Finance 97 (2019): 86-92.

[Ji 2019] Q. Ji, et al. “Information interdependence among energy, cryptocurrency and major commodity markets.” Energy Economics 81 (2019): 1042-1055.

[Kogan 2019] Kogan, Allen. “Not All Virtual Currencies Are Created Equal: Regulatory Guidance in the Aftermath of CFTC v. McDonnell.” Am. U. Bus. L. Rev. 8 (2019): 199.

[Lucking 2019] D. Lucking, & V. Aravind. “Cryptocurrency as a Commodity: The CFTC’s Regulatory Framework.” Global Legal Insights (2019).

[Massad 2019] T. Massad,  “It’s Time to Strengthen the Regulation of Crypto-Assets.” Economic Studies at Brookings (2019).

[Mathews 2019] N. Mathews, &  J. Robison. “Smart contracts that violate the Commodity Exchange Act: which parties are liable?.” Journal of Investment Compliance (2019).

[Platanakis 2019] E. Platanakis, & A. Urquhart. “Should investors include bitcoin in their portfolios? A portfolio theory approach.” The British Accounting Review (2019): 100837.

[Reiners 2019] Reiners, Lee. “Bitcoin Futures: From Self-Certification to Systemic Risk.” NC Banking Inst. 23 (2019): 61.

[Shahzad 2019] Shahzad, Syed Jawad Hussain, et al. “Is Bitcoin a better safe-haven investment than gold and commodities?.” International Review of Financial Analysis 63 (2019): 322-330.

[Shahzad 2019a] Shahzad, Syed Jawad Hussain, et al. “Safe haven, hedge and diversification for G7 stock markets: Gold versus bitcoin.” Economic Modelling (2019).

[Yermack 2013] D. Yermack, “Is Bitcoin a real currency? An economic appraisal [nber Working Paper no. 19747].” Available online at: National Bureau of Economic Research