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.

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

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

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

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

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

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

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

References

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

References

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

References

[Alqassam 2014] I.Alqassem, et.al., “A taxonomy of security and privacy requirements for the Internet of Things (IoT).” 2014 IEEE International Conference on Industrial Engineering and Engineering Management. IEEE, 2014.

[Deng 2011] M. Deng, et al. “A privacy threat analysis framework: supporting the elicitation and fulfillment of privacy requirements.” Requirements Engineering 16.1 (2011): 3-32.

[Feng 2018] Feng, Qi, et al. “A survey on privacy protection in blockchain system.” Journal of Network and Computer Applications (2018).

[Hadar 2018] I. Hadar, et al. “Privacy by designers: software developers’ privacy mindset.” Empirical Software Engineering 23.1 (2018): 259-289.

[Muntes-Molero 2019] V. Muntés-Mulero, et al. “Model-driven Evidence-based Privacy Risk Control in Trustworthy Smart IoT Systems.” (2019).

[OECD 1980] OECD, “Guidelines governing the protection of privacy and transborder flows of personal data” Annex to the recommendation of the council 23^rd Sept.1980

[UNCTAD 2019]       UNCTAD, “Digital Economy Report 2019: Value Creation and capture: implications for developing countries” Sept. 2019.

[Vermont 2018] Vermont S.269 (Act 205) 2018 §4171-74