Autonomy is relevant in many different activities; and has recently received a lot of attention in the context of autonomous mobility of cyber-physical devices. A broad range of mobile physical devices are being developed for a variety of different geographic environments (Land, Sea, Air). These devices have various capabilities of internal controls often described with a ‘Levels of Autonomy’ taxonomy. Autonomous mobility is largely concerned with the problems of navigation and avoidance of various hazards. In many cases, these autonomous mobile devices are proposed as potential replacements for human operated vehicles which creates some uncertainty regarding potential liability arrangements when devices have no human operator. The levels of autonomy proposed for autonomous mobility might provide some insight for levels of autonomy in other contexts e.g., DAOs.
Levels of Land Mobile Device Autonomy
Automobile-specific regulations and more general tort liabilities have established a body of law where the driver is in control of the vehicle, but this is challenged by automation culminating in autonomous vehicles [Gasser 2013]. In their more recent review of autonomous vehicles, [Taeihagh 2019] categorized technological risks and reviewed potential regulatory or legislative responses in US and Europe; where the US has been introducing legislations to address autonomous vehicle issues related to privacy and cybersecurity; While the UK and Germany, in particular, have enacted laws to address liability issues; other countries mostly acknowledge these issues, but have yet to implement specific strategies. Autonomous vehicles are expected to displace manually controlled vehicles in various applications becoming an increasingly significant portion of the vehicular traffic on public roads over time. [SAE2018] Defines 6 levels of automation:
Level 0 – No Driver Automation – May provided momentary controls (e.g. ,emergency intervention).
Level 1 – Driver Assistance – Sustained, specific performance of a subtask
Level 2 – Partial Driving Automation – sustained specific execution with the expectation that the driver is actively supervising the operation.
Level 3 – Conditional Driving Automation – sustained, specific performance with the expectation that the user is ready to respond to requests to intervene as well as to performance failures
Level 4 – High Driving Automation – Sustained, specific performance without the expectation that the user will respond to a request to intervene
Level 5 – Full Driving Automation – Sustained an unconditional performance without any expectation of a user responding to a request for intervention
Autonomous vehicles on off-road applications add another layer of complexity for route planning, steeper slopes, hazard recognition, etc. [Elhannouny 2019]. The levels of autonomy for land mobile autonomous systems in this the taxonomy are sequenced as decreasing levels of human supervision.
Levels of Sea Mobile Device Autonomy
Maritime autonomous systems pose many additional challenges to their designers as the environment is more hostile and the device may be more remote than land mobile autonomous systems etc. Without a well-defined safety standards and efficient risk allocation, it is hard to assign liability and define insurance or compensation schemes leaving unmanned surface ships potentially subject to a variety of different liability regimes [Ferriera 2018]. Unmanned maritime systems have been in operation for more than 20 years [Lantz 2016] and more frequent interactions between manned and unmanned systems are expected in future. The International maritime Organization [IMO 2019] recently initiated a regulatory scoping review of the conventions applicable to Maritime Autonomous Surface Ships. The Norwegian Forum for Autonomous Ships [NFAS 2017] proposed a four-level classification of autonomy:
Decision Support – Crew continuously in command of vessel
Automatic – pre-programmed sequence requesting human intervention when unexpected events occur or when sequence completes
Constrained Autonomous – fully automatic in most situations but human operators continuously available when requested by the system
Fully Autonomous – no human crew or remote operators.
As with land-based mobility autonomy, the levels of this taxonomy for sea mobile autonomous systems are defined and sequenced as decreasing levels of actions by human operators.
Levels of Air Mobile Device Autonomy
The air environment adds an additional degree of freedom (vertical) for navigation, and introduces different navigation hazards (e.g. birds, weather) compared to land or sea environments. Human operated air mobile devices have in the past been relatively large, expensive and heavily regulated. Smaller lower cost drones have enabled more consumer applications. In the US, the FAA has jurisdiction over drones for non-recreational use [FAA 2016], though an increasing number of states [NACDL 2019] are also promulgating regulations in this area. Potential liabilities include not just damages to the device, but also liabilities from collisions with fixed infrastructure, personal injuries, trespass, etc.
[Clough 2002] proposed a 10-level classification of autonomous control levels:
Level 0 – remotely piloted vehicle
Level 1 – execute preplanned mission
Level 2 – Pre-loaded alternative plans
Level 3 – Limited Response to Real Time Faults/ Events
More recently, [Huang 2005] proposed autonomy levels for unmanned systems along three dimensions: Mission complexity, Human Independence and Environmental difficulty. The levels of this autonomous air mobility taxonomy are defined and sequenced as increasing complexity of the scenario and its implied computational task.
Consolidated views of mobility autonomy levels
[Vagia 2019] reviewed levels of automation across different transportation modes and proposed a common faceted taxonomy based on facets of human-automation interface, environmental complexity, system complexity and societal acceptance. [Mostafa 2019] points out that the level of autonomy may be dynamically adjustable, given some situational awareness. In their literature review of levels of automation, [Vagia 2016] noted that some authors refered to “autonomy” and “automation” interchangeably, and proposed an 8-level taxonomy for levels of automation:
Level 1 – Manual control
Level 2 – decision Proposal
Level 3 – human Selection of decision
Level 4 – computer selects decision with human approval
Level 5 – computer executes selected decision and informs the human
Level 6 – computer executes selected decision and informs the human only if asked
Level 7 – computer executes selected decision and informs the human only if it decides to
Level 8 – autonomous control informs operators only if out of specification error conditions occur.
This consolidated view of an autonomous mobility taxonomy is defined and structured as in terms of the decision role taken by the computer system.
Taxonomies provide a means to classify instances, but the intended uses of the categorization limit the value it provides. For example, the [SAE 2018] classification may be useful in setting consumer expectations, and the developers of the other taxonomies proposed no doubt had other purposes in mind during their creation. One consideration is whether the proposed categorizations are useful in terms of the intended benefits from implementing some form of autonomy. [Araguz 2019] identified the need for (or benefits from) autonomy from the literature as improving performance in systems with high uncertainties; ameliorating responsiveness, flexibility and adaptability in dynamic contexts; and ultimately handling complexity (especially in large-scale systems), and in the aerospace field as a means to improve reliability and tolerance to failures. Defining a level of autonomy taxonomy based on the amount of operator control required, or the complexity of the scenario/ computational tasks arguably speaks toward those dimensions of intended benefits.
Presenting levels of autonomy as a numbered sequence of levels implies not just a classification taxonomy, but some quantification of an autonomy continuum, rather than a set of discrete and non-contiguous classification buckets. Most of these taxonomy proposals also leave full autonomy as a speculative category awaiting future technology advancements (e.g., in Artificial Intelligence) and do not provide existence proofs that meet the category definition. While to some autonomy may imply some degree of implementation complexity, the converse is not always true; increasing levels of complexity do not necessarily lead to autonomy. Constructing an autonomy taxonomy based on the decision roles taken by the computing systems is more interesting because it focusses on the actions of the system itself rather than external factors (e.g., scenario complexity, other actors). The decision roles themselves, however, are discrete categories, rather than a linear scale; and are independent of the importance of the decisions being made.
[Myhre 2019] reviewed autonomy classifications for land and maritime environments and proposed that a system is considered autonomous if it can legally accept accountability for an operation thereby assuming the accountability that was previously held by either a human operator or another autonomous system; thus classifying systems as autonomous or not. With non-autonomous systems, liability generally lies with the operator; with autonomous systems, liability generally shifts back to the designer. The scope of accountability or liability in the event of some loss is often described by a monetary value. Insurance contracts are often used to protect against potential liabilities up to some specified monetary level. Monetary values have the advantage of providing a simple linear scale. A system that can accept a $1M liability is thus arguably more autonomous than one that could only accept a $1,000 liability.
References
[Araguz 2019] C. Araguz, et al. “A Design-Oriented Characterization Framework for Decentralized, Distributed, Autonomous Systems: The Nano-Satellite Swarm Case.” International Symposium on Circuits and Systems (ISCAS). IEEE, 2019.
[Clough 2002] B. Clough, “Metrics, schmetrics! How the heck do you determine a UAV’s autonomy anyway.” AIR FORCE RESEARCH LAB WRIGHT-PATTERSON AFB OH, 2002.
[Elhannouny 2019] E. Elhannouny, & D. Longman. Off-Road Vehicles Research Workshop: Summary Report. No. ANL-18/45. Argonne National Lab.(ANL), Argonne, IL (United States), 2019.
[FAA 2016] FAA “Operation and Certification of Small Unmanned Aircraft Systems”, 81 Fed. Reg. 42064, 42065-42066 (rule in effect 28 June 2016); 14 C.F.R. Part 107.
[Huang 2015] H. Huang, et al. “A framework for autonomy levels for unmanned systems (ALFUS).” Proceedings of the AUVSI’s Unmanned Systems North America (2005): 849-863.
[IMO 2019] IMO Legal Committee, 106thSession,27-29 March 2019.
[SAE 2018] SAE, “Surface Vehicle Recommended Practice: Taxonomy and Definitions for Terms related to riving Automation Systems for On-Road Motor Vehicles” (Revised ) June 2018
[Taeihagh 2019] A. Taeihagh, & H. Lim. “Governing autonomous vehicles: emerging responses for safety, liability, privacy, cybersecurity, and industry risks.” Transport reviews 39.1 (2019): 103-128.
[Vagia 2016] M. Vagia, et.al., “A literature review on the levels of automation during the years. What are the different taxonomies that have been proposed?.” Applied ergonomics 53 (2016): 190-202.
[Vagia 2019] M. Vagia, & O. Rødseth. “A taxonomy for autonomous vehicles for different transportation modes.” Journal of Physics: Conference Series. Vol. 1357. No. 1. IOP Publishing, 2019.
A Decentralized Autonomous Organization (DAO), (Sometimes also referred to a Decentralized Autonomous Corporation (e.g. [Kypriotaki 2015])) is a type of smart contract executing as an autonomous organizational entity in the context of a blockchain. Note that the “smart” in smart contract does not require or imply the use of AI (though it is also not prohibited), it refers to automation in the design and execution of legally enforceable contracts. DAOs were originally envisioned as a pseudo-legal organization run by an assemblage of human and robot participants [Vitalik 2013a], [Vitalik 2013b], [Vitalik 2013c]. More recently [Wang 2019] proposed a definition of a DAO as a blockchain-powered organization that can run on its own without any central authority or management hierarchy, and a five-layer architecture reference model. The legal status of DAOs is continuing to evolve. In the absence of specific enabling legislation, There have been proposals that DAOs be considered a trust administrator [Jentzsch 2015] , or a form of (implied) partnership [Zetsche 2018], or be construed as falling within existing LLC enabling statues [Bayern 2014], or requiring new enabling legislation for Cryptocorporations [Nielsen 2018]. Meanwhile, some states (e.g., Vermont [Vermont 2018]) have created enabling legislation recognizing blockchain based LLCs.
DAOs have been proposed in a number of different applications. [Zichichi 2019] proposed a DAO for crowdfunding applications. [Mylrea 2019] proposed a blockchain entity similar to a DAO in the context of energy markets. [Miscione 2019] reviewed blockchain as an organizational technology in the context of both markets and public registries. [Calcaterra 2019] proposed a DAO for underwriting insurance. [Diallo 2018] proposed DAO applications in e-government. DAOs are built on top of blockchain smart contracts. The scope of smart contracts can include off-chain computations, and a wide variety of token types and cyberphysical devices (see e.g., [Wright 2019]). Smart contracts can be used in the execution of a broad array of contracts.
An organization needs to be able to adapt to changes in its environment. Such adaptation in a software entity requires configuration control, mechanisms to clean up old versions etc. This is complicated in the case of blockchains where the software code may be stored as part of the “immutable” block. A key decision point in such adaptations lies in the selections of adaptation to support. In the context of decentralized systems, this is complicated because of multiple parties interacting in a decentralized fashion. This decision process in the evolution of a DAO is generally described in the literature as the governance mechanism for the DAO. Some blockchain architectures (e.g., Tezos) support governance mechanisms inherently, others would require the governance to be build into a higher layer dapp – in this case a DAO. The need for such governance became widely recognized in the aftermath of an early DAO implementation. [Jantzsch 2015] implemented[1] a DAO as smart contracts on Ethereum. After the reentrancy exploit in 2016 of a coding flaw resulted in considerable financial loss, the flaw was resolved through a hard fork [Mehar 2019]. [Avital 2019] identified three classes of governance mechanisms: control, coordination, and realignment, and compared governance practices in centralized and decentralized organizations; arguing that interpretations of governance mechanisms in near-autonomous or stigmergic (indirectly coordinated) forms of a decentralized organization require a theoretical taxonomy emphasizing process over structure. [Notra 2015] proposed a governance as a service model for collaborating DAOs. Governance mechanisms are an ongoing challenge for blockchains, not just DAOs, but DAOs as a legal entity require additional consideration of who is legally authorized to make such upgrades.
The notion of a DAO as a new paradigm for organizational
design has sparked the imagination of some commentators (e.g. [Hsieh 2018],
[Wooley 2016], [Koletsi 2019]), but the underlying performance and capacity of
many current blockchain protocols remain technical impediments to that vision. There
have been some performance improvements; for example, [Barinov 2019] introduced
a Proof of Stake DAO improving performance of consensus mechanisms over prior
Proof of Work blockchains. There are a variety of platforms [Clincy 2019] for implementing
blockchains, smart contracts, and thus DAOs. Some claim [Hsieh 2018] that
bitcoin itself is a form of DAO. DAOs
could be implemented in permissionless blockchains or permissioned blockchains
[Wang 2019]. The most (in)famous example was implemented on Ethereum [Dupont
2017]. [Alimoglu 2017] proposed an organization design for DAOs featuring a
crypto currency funding mechanism, a decision mechanism based on voting and released[2] an
Ethereum/ Solidity implementation under a GNU GPL v3.0 license. DigixDAO[3] aims
to be a self-organizing community on the Ethereum blockchain that actively
involves its token holders in decision making and shaping the direction of the
asset tokenization business. Members of the Ethereum community have pooled
funds together to distribute grants effectively through a DAO structure (MolochDAO[4]
[Soleimani 2019]). OpenLaw[5] provides
a support mechanism for formation of various legal entity types for DAOs. DAOstack[6] is
building an open source software stack for implementing DAOs. DatabrokerDAO [7]appears
to be launching a DAO based data service. MakerDAO supports transactions in
collateralized debt positions.
While some (e.g., [Lopucki 2018]) have questioned the wisdom of aligning software entities with legal entities, DAOs seem to be in various stages of implementation and operation with some color of law enabling legal recognition. Some (e.g., [Field 2020]) are predicting significant commercial DAO progress in 2020. While example DAOs have been in operation for more that 5 years now, consensus on the required functionality for DAOs is still emerging. While the decentralized nature of DAOs is perhaps unfamiliar to some, it, and the notion of a virtual entity like a corporation are widely understood. The notion of autonomy in this context could use some further elaboration, and perhaps even categorization or quantification. DAOs by definition include some notion of autonomy, but what is required for a smart contract to rise to the level of a DAO is not exactly clear. Autonomy implies some aspect of free-will and self-determination, but it is not clear that truly independent decision making is expected in the DAO applications so far. The objectives for DAO applications above seem to be in the nature of an entity that can be trusted to perform in some expected manner. The smart contracts underlying a DAO employ logical programming to execute their contractual objectives; that logical basis provides an explanation of behavior even when unexpected (e.g. due to some reentrancy flaw); and behavior explanations are often unavailable in artificial intelligence applications (e.g., those based on machine learning). Legal recognition as an entity implies not only a capacity for independent action, but also some duties (e.g. duties to responding to other legal processes, obligations toward others (e.g., shareholders, employees)). Other virtual entities (e.g., corporations) rely on designated humans to perform these functions. The argument for implementing a DAO is to minimize the human role in favor of automation. Corporations also provide a feature of limited liability. Many of the DAO applications are manipulating digital assets of considerable value and so considerations of liability if those valuable digital assets were to be lost, damaged or degraded. Where the DAO extends smart contract to cyber-physical assets or other tokenized assets the potential liabilities may become important considerations. So how much autonomy is then required for a DAO to be a DAO?
References
[Alimoglu 2017] A.
Alimoğlu, & C. Özturan. “Design of a Smart Contract Based Autonomous
Organization for Sustainable Software.” 13th Int’l Conf. on
e-Science. IEEE, 2017.
[Calcaterra 2019]
C. Calcaterra, et.al., “Decentralized Underwriting.” Available
at SSRN 3396542(2019).
[Clincy 2019] V. Clincy,
& H. Shahriar. “Blockchain Development Platform Comparison.” 43rd
Ann. Computer Software and Applications Conference (COMPSAC). Vol. 1. IEEE,
2019.
[Diallo 2018] N. Diallo,
et al. “eGov-DAO: A better government using blockchain based decentralized
autonomous organization.” 2018 International Conference on
eDemocracy & eGovernment (ICEDEG). IEEE, 2018.
[DuPont 2017] Q. DuPont,
“Experiments in algorithmic governance: A history and ethnography of “The
DAO,” a failed decentralized autonomous organization.” Bitcoin and
Beyond (Open Access). Routledge, 2017. 157-177.
[Hsieh 2018] Y. Hsieh,
et. al. ,”Bitcoin and the rise of decentralized autonomous organizations.” J.
of Organization Design7.1 (2018): 14.
[Jentzsch 2015] C.
Jentzsch, “Decentralized autonomous organization to manage a
trust.” White Paper (2015)
[Kypriotaki 2015]
K. Kypriotaki, et.al., “From bitcoin to decentralized autonomous
corporations.” International conference on enterprise information
systems. 2015.
[Koletsi 2019] M.
Koletsi, “Radical technologies: Blockchain as an organizational
movement.” Homo Virtualis 2.1 (2019): 25-33.
[Lopucki 2018] L.
Lopucki, “Algorithmic Entities”, Washington U. Law Rev., vol 95, no 4, pp
887-953, 2018
[Mehar 2019] M. Mehar,
et al. “Understanding a revolutionary and flawed grand experiment in
blockchain: the DAO attack.” J. of Cases on Inf. Tech. (JCIT) 21.1
(2019): 19-32.
[Miscione 2019]
G. Miscione, “Blockchain as organizational technology.” University
of Zurich, Department of Informatics IFI Colloquium, Zurich, Switzerland, 28th
February 2019. University College Dublin, 2019.
[Mylrea 2019] M. Mylrea,
“Distributed Autonomous Energy Organizations: Next-Generation Blockchain
Applications for Energy Infrastructure.” Artificial Intelligence
for the Internet of Everything. Academic Press, 2019. 217-239.
[Nielsen 2018] T.
Nielsen, “Cryptocorporations: A Proposal for Legitimizing Decentralized
Autonomous Organizations.” Utah Law Review, Forthcoming (2018).
[Norta 2015] A. Norta,
et. al., “Conflict-resolution lifecycles for governed decentralized
autonomous organization collaboration.” Proc. 2nd International
Conference on Electronic Governance and Open Society: Challenges in Eurasia.
ACM, 2015.
[Wang 2019] S. Wang,
et al. “Decentralized Autonomous Organizations: Concept, Model, and
Applications.” IEEE Transactions on Computational Social Systems 6.5
(2019): 870-878.
[Woolley 2016] S.Woolley,&
P.Howard. “Automation, algorithms, and politics| political communication,
computational propaganda, and autonomous agents Introduction.” Int’l
J. of Communication 10 (2016): 9.
[Wright 2019] S.
Wright, “Privacy in IoT Blockchains: with Big Data comes Big Responsibility”, Int’l
Workshop on IoT Big Data and Blockchain (IoTBB’2019) in conjunction with IEEE
Big Data (2019)
[Zetsche 2018] D.Zetsche,
et.al., “The distributed Liability of distributed ledgers” U. Ill. L.Rev. 2018.
[Zichichi 2019]
M. Zichichi, et al. “LikeStarter: a Smart-contract based Social DAO for
Crowdfunding.” arXiv preprint arXiv:1905.05560 (2019).
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.
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
Design patterns have been proposed as a method to improve the consistent application of proven solutions across designs. Privacy in operational IoT blockchains today is mostly an attestation from the operator of the service based on IoT. Privacy testing in operational systems an opportunity for further improvement. Privacy risks, threat model and requirements are continuing to evolve and IoT systems will need to evolve with them. [Alqassam 2014]. Privacy threats need to be managed throughout the operational life cycle of the IoT blockchain including changing sensors, upgrading software, etc. Privacy patterns can help maintain consistency across these disruptions; though testing and attestations will also have a role to play.
Privacy patterns for
IoT Blockchain Design
Developers often use the vocabulary of data security to approach privacy challenges, and software architectural patterns frame privacy solutions that are used throughout the development process [Hadar 2018]. There are over 100 IoT design patterns in the literature, but very little explicit identification of IoT design pattern reuse [Washizaki 2019]. As a “step” toward solving security and privacy concerns, [Bloom 2018] identified common input-output (I/O) design patterns that exist in Industrial IoT applications, but these design patterns don’t address the full scope of privacy threats, nor the blockchain aspects. [Xu 2018] collects blockchain design patterns, but these mainly identify privacy as an area for further improvement. [Wirth 2018] provides an initial blockchain and smart contracts architectural blueprint claiming GDPR compliance. [Pape 2018] considers privacy patterns in the IoT architecture, assuming a three-layer service delivery model based on fog computing, and does not consider blockchain aspects, nor an explicit data controller role. The privacy patterns [Pape 2018] identified included: personal data store, data isolation at different entities, decoupling content and location visibility, added noise measurement obfuscation, aggregation of data, data aggregation gateways, and single point of contact. A more comprehensive list of privacy patterns, though not targeted at IoT, is online at https://privacypatterns.org/patterns/. Privacy patterns abstract away from the detailed solution of specific PETs. At best, privacy design patterns align with specific privacy threat models, and the suite of patterns covers the full scope of privacy threats. Privacy design patterns can provide a useful common abstraction for communication between the designers and operators of IoT blockchain during its design and operational lifecycle.
Privacy Testing
Modern software development practices like devops, CI/CD,
etc. have an emphasis on the availability of system tests to ensure key use
cases remain valid during development. Some methodologies (e.g. Design for
Testability) go further and require the development of tests before the development
of the code. It would be helpful if
privacy design patterns had industry consensus methods to verify correct
implementation and operation.
Testing in the context of distributed architectures like IoT and blockchains adds additional complexity. [Pontes 2018] formalizes the notion of a pattern-based IoT testing method for systematizing and automating the testing of IoT ecosystems. It consists of a set of test strategies for recurring behaviors of the IoT system, which can be defined as IoT test patterns. Unfortunately, these did not address the scope of privacy concerns. Similarly, the blockchain literature has few examples of automated test suites (see e.g., [Gao 2019]). Neither of these test patterns is specific to privacy. [Muntes-Molero 2019] proposes an approach towards continuous monitoring for privacy risk control in trustworthy IoT systems. The assumption of trustworthy systems requires additional justification. Blockchains can be designed to achieve secure consensus results despite running on untrusted nodes in a peer-peer network. With little in the literature beyond penetration testing (e.g., [Probst 2012]), testing of assertions that privacy threats have been resolved seems an area for further research.
Given the scope of privacy concerns, privacy testing is unlikely to be accomplished by a single test. While many traditional notions of privacy focus on disclosure, recent regulatory initiatives have created new requirements for user controls. While those controls may be implemented with manual procedures in the short term, IoT blockchain architectures can be expected to evolve to provide automated support for these features, and that will need to be tested. An IoT blockchain may be assembled from different components, and will likely evolve over its operational life as new components are added, software updated, etc. Privacy testing will need to apply both at the component level and cumulatively across the larger architecture, and during run time operations.
Privacy Attestation
Some [Wirth 2018], [Bansal 2008] have noted that trademarks and certification seals may be useful for consumers to identify and trust products and services that provide privacy assertions (e.g., conformance to privacy regulations such as the GDPR). Certification schemes usually require independent verification/ testing to assure the quality of certified goods/services. While privacy testing regimes are still in early stages of development, attestations by entities operating services based on IoT blockchains may provide some interim assurance. This may require similar assurances and indemnification through the component supply chain.
The scope of the attestations that consumers may require to protect their privacy and build trust needs further consideration. Solove’s taxonomy is now incomplete as it does not include the more recent regulatory initiatives like GDPR that mandate some degree of control of the data by the data subject. Traditional data access controls (Create/Read/Update/Delete) are helpful, but more nuanced controls may be required to constrain privacy threats from information processing and secondary uses. GDPR takes a step in this direction by identifying the data controller role and imposing privacy-related obligations on data controllers. IoT blockchain architectures could support a limited set of more nuanced operations on private data through SMC. The SMC code could be open-sourced and inspectable to provide assurances of correct operation. Moving the computing algorithms to the data like this may reduce the amount of attestation required to build trust.
Privacy is an ongoing operational concern, not just a design-time objective. The IoT blockchain architecture, though, it will need adequate capabilities to be designed in so that operators of services based on them will be able to make adequate assurances to their customers, and perhaps their regulators as well. While attestations may provide assurances in the short term, ultimately adequate privacy testing regimes will be required to demonstrate the integrity of the solutions.
[Bloom 2018] G. Bloom, et al. “Design patterns
for the industrial Internet of Things.” 2018 14th IEEE
International Workshop on Factory Communication Systems (WFCS). IEEE, 2018.
[Gao 2019] J. Gao, et al., “Towards automated
testing of blockchain-based decentralized applications.” Proc. of
the 27th Int’l Conf. on Program Comprehension. IEEE, 2019.
[Hadar 2018] I. Hadar, et al. “Privacy by
designers: software developers’ privacy mindset.” Empirical
Software Engineering 23.1 (2018): 259-289.
[Pontes 2018] P. Pontes, et. al., “Test
patterns for IoT.” Proceedings of the 9th ACM SIGSOFT
International Workshop on Automating TEST Case Design, Selection, and Evaluation.
ACM, 2018.
More concise privacy threat models are emerging as awareness grows that privacy concepts expect beyond the scope of traditional security threat models. The Data Controller role has received more interest after GDPR but rarely appears in IoT blockchain architectures. To resolve human privacy concerns requires establishing trust in both the IoT systems and in the entities operating them. Legal innovations (e.g., BBLLCs) enable the possibility of new entities that may help manage privacy threats. Technology innovations (e.g., SMC) enable new privacy patterns by changing the data flow requirements to bring the computation to the data, rather than the reverse.
Privacy Threat Models
Developers often use the vocabulary of data security to approach privacy challenges, and this vocabulary limits their perceptions of privacy mainly to third-party threats coming from outside of the organization [Hadar 2018]. Security by design has achieved wider adoption through the use of methodologies based around threat modeling to build common design patterns around data flows in system architectures. [Deng 2011] applies this approach to privacy threat modelling, distinguishing between hard privacy (based on data minimization) and soft privacy (based on trust in the operations of some external data controller), and identifying a number of privacy properties (unlinkability, anonymity, pseudonymity, plausible deniability, undetectability / unobservability, confidentiality, content awareness, policy and consent compliance). [Muntes-Molero 2019] provides a mapping of the connection between security threat models (STRIDE) and Privacy threat models (LINDDUN).
[Feng 2018] identifies blockchain privacy requirements as only either (1) identity privacy or (2) transaction privacy, and also identifies several attacks for deanonymization of identities in blockchain systems are known including: network analysis, address clustering, transaction fingerprinting, Denial of Service attacks against anonymizing networks, Sybil attacks against the P2P network reputation system. Transaction privacy can also be threatened by transaction pattern exposure through, for example, transaction graph analysis. Identity preservation methods mixing services (which obfuscate transaction relationships with other traffic), ring signatures (which obfuscate the real signer amongst a group of signatories), and non-interactive zero-knowledge proofs (which prove a given statement without leaking additional information). Transaction privacy-preserving mechanisms identified include non-interactive zero-knowledge proofs, and homomorphic cryptosystems (which preserve arithmetic operations carried out on ciphertexts).
The privacy threat models, and traditional IoT architectures, generally assume a data flow pattern where data moves and aggregates for centralized analysis by some other party. IoT blockchains supporting SMC offer a potential alternative architecture of moving the computation rather than the data – exposing only the result of the computation rather than the original private data. This would enable the computations to be trusted rather than some other party. This would also limit the secondary use threat to privacy from Solove’s taxonomy when the data is transferred directly, which otherwise does not seem to be addressed effectively in the privacy principles, or threat models.
Data Controller Entities and business models
Ownership provides a legal basis for data controllers to exercise control over “their” data. In the context of cross border data flows, [Unctad 2019] considered four data ownership policies as options for capturing value for data: personal data markets, data trusts (between members of a group, or digital platform), collective data ownership (nationalization as a public resource), and digital data commons (placing data in the public domain). Assertions of collective ownership or digital commons likely require changes in public policy. While individuals could theoretically build their own IoT systems to control their own data, this is not a scalable approach for IoT deployments as not everyone has the skills, capital or motivation, and the lack of uniformity in approach would reduce the aggregate value. If the data collected has commercial value, then some entity is likely to be claiming ownership of that data. For most IoT architectures this entity is not the humans that may be subjects of IoT surveillance. Many existing IoT architectures require people to trade otherwise private data about themselves for access to some monitoring service. The role of a data controller was identified in [OECD 1980] and reinforced with the GDPR; data controllers have not typically been an element in IoT architectures. A data controller may typically be a data owner, but this is not required – it could be operating under some contract or other license arrangements.
Hence humans subject to surveillance by services based on IoT architectures must trust the entity operating those services for any privacy assurances. For commercial entities operating a service based on IoT, there most likely is terms and conditions (T&C) agreement between the IoT operator and the user. Ideally, this would include some attestations or promises regarding the user’s privacy (e.g. not to resell the data to others for secondary uses). It is difficult for the user to detect violations of such privacy attestations. Other data controllers may collect IoT data implicating privacy without T&C agreements in place. Regulations, such as GDPR, may still apply in such cases. In the event of a change of control at the entity operating the IoT service (e.g., a bankruptcy), the data within its control could be repurposed without notice to the user.
Blockchain technology offers a new entity for consideration as the data controller: an IOT blockchain could be structured as a DAO and incorporated as a BBLLC [Vermont 2018]. In this case, the user would have to trust the BBLLC (and its developers) rather than a commercial platform operator. The BBLLC replaces the human with a computational machine as the data controller. The data controls could be implemented with smart contracts. The smart contracts could be publicly inspectable to build trust in the logic. Several blockchains and smart contracts are already inspectable as open source. The BBLLC could also have preplanned smart contracts for the data to be returned or destroyed in the event of foreseeable disruptions of the BBLLC (e.g., forking, dissolution). While blockchains and smart contracts hold a lot of promise, current implementations do not exhibit all these features, and it may take some time for a consensus to emerge on the detailed scope of the features required in IoT blockchains to support the full scope of privacy threats.
If you are looking for a book that provides a detailed overview of the legal implications of blockchain technology and smart contracts, then “Blockchains, Smart Contracts, and the Law” is the perfect choice for you. This book is written clearly and concisely, making it easy to understand even for those who are new to the topic.
Legal principles and regulations are generally concerned with the technology-independent classification of events. Privacy principles have been proposed as a step beyond legal classifications of privacy violations, but these still remain difficult for many IoT blockchain developers to apply. Privacy Impact Assessments (PIAs) have also been proposed to expose privacy issues, but these have not been widely adopted.
Privacy Principles and Frameworks for IoT Blockchains
Principles have been proposed as implementation and operation guidance on privacy. The OECD guidelines [OECD 1980], are perhaps the most widely known privacy principles. These eight principles, intended for nations to apply to trans-border data flows, are: (1) collection limitation principle, (2) data quality principle, (3) purpose specification principle, (4) use limitation principle, (5) security safeguards principle, (6) openness principle, (7) individual participation principle, and (8) accountability principle. More recently the GDPR has endorsed Privacy by Design (PbD). PbD [Cavoukian 2010] builds on seven foundational principles: (1) proactive not reactive; (2) privacy as the default; (3) privacy embedded in the design; (4) full functionality- positive-sum, not zero-sum; (5) end-to-end life cycle protection; (6) visibility and transparency; (7) respect for user privacy. While OECD principles apply in the context of nations managing data flows, PbD principles are intended in the context of IT systems; as such these two sets of principles are complementary.
While the privacy principles are helpful in moving beyond classifying privacy violations they are not necessarily easily applicable to specific architectural contexts (e.g. IoT blockchains), or software development methodologies [Omoronyia 2019], [Perera 2019], and further refinement may be required for practical adoption. Principles present too abstract a framework to inform design; and are often applied after many critical design decisions have been made in defining the business opportunity. [Edwards 2016]. Both the OECD principles and the Policy by design principles provide a step forward from Solove’s privacy threat taxonomy to provide guidance to the developers and operators of information systems. There is no simple mapping between the privacy threat taxonomy and the privacy policies to validate their completeness. The privacy threat taxonomy provides a static view, classifying events after they have happened, while the policies are intended to be more proactive and preventative, applying to ongoing operations and data flows.
There is a lack of comprehensive, widely adopted frameworks to address privacy issues for IoT applications [Thorburn 2019] (for example, [Panagiotou 2018] only considers some cryptography aspects, [Cha 2018] focused only on informed consent). For privacy engineering, the availability and usage of standards, analysis methodologies, and software tools are relatively weaker than for safety and security, reflecting the fact that privacy engineering is an emerging concern for practitioners [Shan 2019]. If detailed technical standards existed, they could provide a framework for IoT Blockchain developers to work from. [ISO 2009] defines information security in terms of preservation of confidentiality, integrity, and availability of information, but notes that other properties, such as authenticity, accountability, non-repudiation, and reliability can also be involved, but other principles like privacy and non-repudiation don’t fit cleanly into this famous triad. [ISO 2011] added a privacy framework, [ISO 2014] added a code of practice for handling Personally Identifiable Information, [ISO 2017] added guidelines for privacy impact assessments and [ISO 2019] provided guidelines and requirements for privacy information management. While providing some guidance, these ISO standards are neither complete nor customized for an IoT blockchain architectural context. There are a number of more specific IoT standards [Miloslavskaya 2019], but they do not address privacy in detail. [NIST 2019] starts to separate IoT privacy concerns from other security concerns; but, does not provide detailed guidance. Blockchain standards, today, seem to be evolving in open source (see e.g., Ethereum RFCs) at the level of APIs, but do not provide a larger view of the privacy impacts. ISO TC/307 is still developing formal specifications on blockchain technologies. While more comprehensive standards may exist in the future, the standards available at present do not provide a comprehensive framework for privacy in IoT blockchains.
IoT Blockchain is by its nature a distributed architecture; this implies that privacy threats can attack multiple points (in motion and at rest) within the architecture. Understanding the data flows, becomes a prerequisite to analyzing privacy across the IoT blockchain architecture. Recall the OECD principles were developed in the context of data flows between nations; data flows in IoT blockchains, however, are not technically restricted by national borders. Data flows for business processes are often modelled to capture stakeholder collaboration in business processes supported by technology/ automation. [Pullonen 2019] proposed Privacy Enhanced Business Process Modelling Notation (PE-BPMN) to capture the use of PETs along the flow of private information. Such notations may be helpful in discussing the end-end privacy management processes of IoT blockchain architectures.
Identifying privacy Impacts
When analyzing IoT privacy requirements, it can be challenging to identify what information should be protected, when it should be protected, and to whom access should be granted.
IoT consists of diverse technologies and the integration of these technologies can lead to unknown risks. Not all the data collected by IoT architectures is necessarily implicated by privacy concerns; data related to legal entities (e.g. data about people and their possessions), however, may be implicated. For example, IoT sensor data from personal fitness devices, or personal vehicles may be used to infer a person’s location which they may wish to keep private. [Ni 2017] identifies four categories of privacy relevant IoT data: (1) identity, (2) usage, (3) location, and (4) other miscellaneous data (e.g., user preferences, sensor data). It is not only the data collected by IoT architectures that may be problematic for privacy; privacy threats may arise from the linkages [Madaan 2018] between IoT data streams (ie. the information processing aggregation privacy threats in Solove’s taxonomy).
PIAs have been proposed for information systems generally (see e.g., [ISO 2017]. If required, these are typically developed manually at an early[1] stage of the project to scope and shape the development of the solution architecture. Conducting a PIA remains a complicated and bewildering task, mainly due to the lack of detailed, practical guidance on how to carry out such an assessment. The available guidance is mainly at the level of legal, policy, or academic proposals [Vemou 2018] rather than targeted for software developers of other technologists designing and implementing IoT blockchain systems. Even for the ISO standard in PIAs, there are proposals (e.g., [Vemou 2019] for extensions to make the PIA process more tractable for practitioners, but these are still not specialized for the IoT Blockchain context. There are not many published examples of PIAs for IoT architectures in the literature. The EU at one stage had required the development of PIAs for RFID applications [EU 2011]. [Pribadi 2017] provides an example PIA for a smart health care services IoT.
Developers of IoT blockchains need more detailed guidance on how to apply privacy principles in their context. Privacy frameworks and standards are emerging, but still incomplete. PIAs are not guidance for IoT blockchain developers, rather these are created by the IoT blockchain developers for external audiences to understand the scope of privacy threats, and the mitigations supported within their architectures. While not trivial to implement, PIAs may be actionable by IoT blockchain developers to provide more insight for regulators, and the operators and users of services built on IoT blockchains, about potential exposures to privacy threats.
If you are looking for a book that provides a detailed overview of the legal implications of blockchain technology and smart contracts, then “Blockchains, Smart Contracts, and the Law” is the perfect choice for you. This book is written clearly and concisely, making it easy to understand even for those who are new to the topic.
References
[Cavoukian 2010] A.Cavoukian, “Privacy by design: the definitive workshop. A foreword by Ann Cavoukian, Ph. D.” Identity in the Information Society 3.2 (2010): 247-251.
[Madaan 2018] N. Madaan, et.al., “Data integration in IoT ecosystem: Information linkage as a privacy threat.” Computer law & security review 34.1 (2018): 125-133.
[Miloslavskaya 2019] N. Miloslavskaya, et al. “Standardization Issues for the Internet of Things.” World Conference on Information Systems and Technologies. Springer, Cham, 2019.
[Pribadi 2017] I. Pribadi, et. al., “Regulatory recommendations for IoT smart-health care services by using privacy impact assessment (PIA).” 2017 15th Int’l Conf. on Quality in Research (QiR): International Symposium on Electrical and Computer Engineering. IEEE, 2017
[Pullonen 2019] P. Pullonen, et. al., “Privacy-enhanced BPMN: enabling data privacy analysis in business processes models.” Software & Systems Modeling (2019): 1-30.
