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).
[Rouhani 2019] S. Rouhani, & R. Deters.
“Security, Performance, and Applications of Smart Contracts: A Systematic
Survey.” IEEE Access 7 (2019): 50759-50779.
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.
[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).
[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.
[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
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.
[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.
[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.
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.
[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”
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.
[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).
[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.
[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.
[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.
[Victor 2019] F. Victor, & B. Lüders,
“Measuring Ethereum-based ERC20 token networks.” International
Conference on Financial Cryptography and Data Security. Springer, Cham,
2019.
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.
[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.
[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.
[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.
[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.
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
GuidePointaccepts 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).
[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.
[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