smart contracts and blockchain · 2017. 10. 11. · smart contracts and blockchain abstract this is...

Smart Contracts and Blockchain

Abstract This is a level-set for enterprises assessing smart contracts and possible synergy with blockchain. Blockchain has advanced from being a foundation for Bitcoin to a platform supporting a wide variety of distributed services. This transformation has been driven, in part, by the introduction of smart contract programming methods and techniques. Smart contracts have also advanced dramatically in the past few years and starting to be evaluated by large enterprises. Blockchain-based smart contracts are designed to automate and provide an immutable record for the exchange of a broad spectrum of assets without requiring a third party. Cloud providers such as IBM and Microsoft are investing heavily in this area. Areas such as electronic health records access, insurance claims processing, royalty distribution, securities trade clearing, and supply-chain management have all been touted as potentially benefiting from being built on these Blockchain-as-a-Solution (BaaS) platforms. This report describes smart contracts and highlights some of the current opportunities as well as barriers to be navigated for enterprises considering investments in this area. We’ll examine the current and expected future state for smart contracts and define the steps enterprises can take to be prepared to move into this space. This report provides is an introduction to the concept of smart contracts, describes the synergistic relationship with blockchain, describes a few early enterprise use cases, and explains how smart contracts are intended to operate. We’ll also describe key areas of caution as both the technology and supporting systems are immature and largely unproven at scale. We include a set of specific recommendations as to how organizations can effectively and efficiently move forward with smart contracts and blockchain and be prepared to act quickly when the time is right. Authors: Name: Gary Rowe Name: John Myracle Title: CEO & Principal Consulting Analyst Title: Principal Consulting Analyst [email protected] [email protected]

mailto:[email protected]

mailto:[email protected]

Smart Contracts and Blockchain Gary Rowe and John Myracle

2 © 2017 TechVision Research, all rights reserved www.techvisionresearch.com

Table of Contents

Abstract .................................................................................................................................................................................. 1

Table of Contents ............................................................................................................................................................... 2

Executive Summary & Key Advice ............................................................................................................................. 4

Introduction ......................................................................................................................................................................... 7

Smart Contracts Basics .................................................................................................................................................... 8

Relationship to Current Written Legal Agreements ................................................................................. 10

Smart Contracts and Blockchain ............................................................................................................................. 10

Distributed Ledgers - Bitcoin versus Ethereum and the Hyperledger Fabric .............................. 11

Smart Contracts are Distributed Contracts ................................................................................................... 13

Use Cases ............................................................................................................................................................................. 15

Tracking Packages While In Transit ................................................................................................................. 15

Supply Chain Management .................................................................................................................................... 21

Royalty Distribution ................................................................................................................................................. 23

Smart Contract Use Case Summary ................................................................................................................... 26

Potential Smart Contract Implementations .................................................................................................. 27

Smart Contract Limitations and Roadblocks ..................................................................................................... 28

Limitations .................................................................................................................................................................... 28

Internet, IoT, and Sensory Data Access ...................................................................................................... 29

Cost and Performance ........................................................................................................................................ 30

Native Blockchain Limitations........................................................................................................................ 31

Regulatory Climate ............................................................................................................................................... 31

Protocol Change Management and Hard Forks...................................................................................... 31

Use Case Anomalies and Misconceptions ....................................................................................................... 32

Monitoring of External Events Misconceptions ..................................................................................... 32

Exemplary Use Cases Involving Automatic Payments ........................................................................ 33

Platform Evolution, Maturity, and Potential Benefits ................................................................................... 34

Platform Evolution and Maturity ....................................................................................................................... 34

Legal Remedies ........................................................................................................................................................... 35

Ecosystem Infrastructure Push ........................................................................................................................... 35

............................................................................................................................................................................................. 36

Potential Enterprise Benefits ............................................................................................................................... 36

State of the Industry ...................................................................................................................................................... 37

Findings and Recommendations ............................................................................................................................. 38

Summary Findings .................................................................................................................................................... 39

http://www.techvisionresearch.com/



Recommendations ..................................................................................................................................................... 40

About TechVision ............................................................................................................................................................ 42

About the Authors .......................................................................................................................................................... 43




Executive Summary & Key Advice Smart contracts are simply deterministic programs that are hardcoded and may be immutably stored on the blockchain. The basis for the contract is like most agreements; it starts with an agreement of terms between two or more parties. It varies from most contracts in that if the conditions of the contract are met, the contract can be automatically executed without human intervention. Smart contracts can support complex use cases as they may be configured to call other smart contracts during execution to form a series or string of dependent “if/then” operations. Linking these elements together can support increasingly complex and sophisticated functionality, services, or applications. The participating parties must agree on the arrangement and orchestration of these elements and also agree to accept the outcome when it is automatically executed. This common understanding or “meeting of the minds” is the basis for enforcing and executing the terms of the smart contract. The smart contract agreement is then broken down into specific elements represented by deterministic, conditional logic (if/then statements) programmed to execute as conditions are met. We don’t expect smart contracts to replace today’s written legal agreements or supplant the judicial system. What they will do is to augment and automate the execution and enforcement of a limited subset of these agreements. For example, smart contracts may be well suited for implementing a variable price schedule set forth in a written legal agreement. Consider a set of agreed to prices that vary based on delivery time. A smart contract could be configured to automatically determine the items price, from the price schedule, using an electronically scanned arrival time as input. The smart contract would then automatically exchange funds between the participating parties based on this determination. This functionality would continuously execute and yield repeatable agreed to outcomes without manual intervention. An initial benefit (and barrier) to embracing smart contracts is that an organization needs to specifically define its business rules regarding processes and operations upfront since smart contracts are self-executing and self-enforcing. There is no room for ambiguity once the smart contract is provisioned. Organizations implementing and relying on this programming technology must exercise extreme caution and fully understand all possible input conditions, underlying assumptions, and execution outcomes. To effectively deploy this deterministic programming method requires a clear and common understanding by all parties involved of the mutually shared business terms and definitions. While smart contracts don’t need blockchain, there are several reasons why we are considering pairing these two embryonic technologies. Smart contracts can directly benefit from blockchain security, time stamps, its immutability and verification. Blockchain-based




smart contracts are distributed and replicated which means there should be consistency and transparency across stakeholders involved in a particular deal or application. The combination of storing and leveraging rules based on business logic combined with the distributed nature of blockchain provides a flexible platform for executing contracts. Smart contracts may be configured to operate within a single chain or between multiple chains where outputs are recorded and can’t be changed. Given the automatic execution of a smart contract, the accuracy of the input data is critical. If the input data cannot be trusted the enforceable outcomes lose meaning. If the input data is trustworthy then blockchain characteristics of immutability, verifiable accountability, non-repudiation, consensus, and provenance can be leveraged. The compelling advantage emanating from using blockchain-based smart contract transactions is that they are deterministic and yield enforceable conclusion. You simply set it and forget it. These inherent characteristics allow for smart contracts to replace repetitive manually intensive operations with repeatable expected results in accordance with mutually agreed to pre-established conditions. In short, the idea behind blockchain-based smart contracts is to algorithmically embody an enforceable agreement between random parties in a trusted environment without the need for an intermediary. In reality the enterprise value proposition lies within efficiencies gained through automating operations between known entities in a closely coordinated community. The legal and judicial systems are mostly playing catch up with respect to smart contracts, blockchain technology, and many areas of technology innovation. That said, we are starting to see some progress like the recent groundbreaking Arizona law introduced in March 2017 under House Bill 2417 where, in layman’s terms, records or signatures in electronic form and smart contract terms cannot be denied enforceability. Legislation is still at an early stage as most state and federal laws have yet to inscribe these digital methods. In light of the Arizona adoption it is expected that new laws will emerge to advance and expand the enforcement of digital agreements. Blockchain-based smart contracts exhibit the same native features and qualities found with blockchain database platforms and can add the following features and qualities:

· Automating portions of legal agreements and regulations, · Executing standardized logic in hardcoded protocols and processes, · Generating predictable and repeatable outcomes, and · Securing (i.e. enforcing) participants perform their pre-agreed obligations.

Smart contract technology remains in its infancy. Numerous technological limitations involved with deploying smart contracts remain. Regardless, smart contracts on blockchain




as foundational technologies should be considered as a candidate implementation platform for underpinning future software driven capabilities. Impelled by vast investment sums and stalwart commitments made by premiere technology vendors, blockchain and blockchain-based smart contracts are moving forward and these technologies shouldn’t be ignored by enterprises. The uncertainty lies in the development of a supporting ecosystem and how smart contracts survive contact with the enemy; for example, how disputes are handled.

Given the investment in this space and the overarching potential benefits, we expect blockchain-based smart contracts to be part of the enterprise landscape for the next decade or more. This is due to the potential utility in eliminating or reducing dependencies on antiquated and inefficient processes, preventing fraud, reducing overhead as well as revenue loss due to system downtime. Blockchain-based smart contracts have the potential to drive down costs, increase efficiency and eliminate manual processes. TechVision recommends that enterprises focus on preparing for blockchain, educating key stakeholders, consider early/low risk candidates for early prototypes and develop a smart contract strategy and funding plan.



7 TECHNOLOGY RESEARCH AND CONSULTING www.techvisionresearch.com © 2017 TechVision Research all rights reserved

Introduction Smart contracts are simply deterministic programs that can be used to build distributed applications across an enterprise, a community, or a marketplace. A smart contract can be thought of as an agent supporting the execution of a transaction (i.e., an asset transfer) between parties. They can be coded to execute on data-driven input to programmatically execute an agreement. Smart contracts have been around for a while, but have been much more in the limelight of late as enterprises (and analysts like TechVision Research) consider the possibility of linking smart contracts with blockchain or similar distributed ledgers. The theory behind smart contracts has been abstracted and conceptualized over the last twenty years. The basic principles have been used for many decades in, of all things, vending machines. Despite the possible overuse of this example, the vending machine workflow does convey the key concepts we are looking to digitize and automate at scale with smart contracts. Operating a vending machine is straightforward from a user perspective. Products and their corresponding prices are prominently displayed which define the terms of the ‘offer’ under which the vendor is willing to do the exchange. The user deposits monies into the vending machine and by selecting the desired product, expresses contract ‘acceptance’ to the stated terms. The contractual ‘consideration’ condition is met when the machine determines the correct amount has been deposited and dispenses the selected product. This completes the reciprocal exchange of value. The three elements of offer, acceptance and consideration express and form a definite contractual arrangement completed between the buyer and seller. What makes this example so useful is that it clearly demonstrates an agreement can be completed between a random buyer and seller without the need for involving a third party as an intermediary. A more technology-driven example is in the securities area. Let’s say an individual wants to sell a stock if the price reaches $100. The manual process would be for that individual to watch the price movements and when it hits $100 to call their broker and say they want to sell their shares. Some of the pre-negotiation would be completed (the account set up and the broker confirming it was their client calling), but the broker would then place the sell

it clearly demonstrates an agreement can be completed between a

random buyer and seller without the need for

involving a third party as an intermediary.




execution order. A simple smart contract would be to place a sell order electronically at $100 and when the stock hits that price point it is executed without further action. This is the model for most proprietary electronic trading platforms today. The complicated part lies in that you have to know that the price point has been reached. One could continually submit the sell order to the exchange, but this would create undue load on the network. This is one of the current limitations being investigated. How do you implement a vetted trusted source to execute the smart contract at the right moment in time when the strike price is met? This report investigates this limitation and like concerns. A principal feature of smart contracts is to reduce risk through non-discriminatory execution (when the conditions are met, the contract is executed), which for some, will lead to greater economic benefits. Why add nascent blockchain technology to the nascent smart contracts discussion? Because there are natural synergies between the two technologies. In fact, some of the blockchain offerings, like Ethereum, are specifically architected to support smart contracts. And using distributed ledgers to support smart, distributed contracts have some real advantages. Smart contracts can directly benefit from blockchain security, time stamps, immutability and verification. Blockchain-based smart contracts are distributed and replicated which means there should be consistency and transparency across stakeholders involved in a particular deal or application. The combination of storing and leveraging rules based on business logic combined with the distributed nature of blockchain provides a flexible platform for executing contracts. With smart contract technology, trust between parties can be established via attribute exchange via a peer-to-peer, distributed, replicated ledger or blockchain. Terms are predetermined and the logic constructs and execution are realized when these embedded terms are met. The net change is that the intermediary functions needed to remove risk in a manual paper process are eliminated in the digital domain.

Smart Contracts Basics Smart contracts are not as new as it may seem given the relatively recent flurry of activity. Nick Szabos actually introduced the concept of smart contracts in his paper published in 1996, but the concepts have really gained traction over the past 3 years. The synergy between blockchain and smart contracts has been a big part of the interest in and development of smart contracts after a long period of hibernation. In this section, we’ll further describe smart contracts, their value and synergy with blockchain. As we’ve said, a smart contract is deterministic program that can automatically execute based on agreed upon terms when pre-defined conditions are met. A smart contract is not by definition a formal contractual agreement, but may be appropriate for implementing




simplistic requirements culled from a comprehensive written agreement. Smart contracts may be configured to trigger other smart contracts both on and off chain. This triggering mechanism allows for more complex requirements to be satisfied and for realizing intra and inter-chain operations.

While smart contracts don’t require blockchain, we will focus primarily on blockchain-supported smart contracts in this report. Blockchain itself is moving from a financial transaction protocol to a broader, all-purpose utility that can better support smart contracts. Advancements in blockchain and supporting applications are helping to extend these services from simply keeping a record of financial transaction entries to automatically implementing terms of multiparty agreements. TechVision believes there will be a wide array of potential applications for blockchain-based smart contracts. These range from insurance claims processing to royalty distribution and supply-chain management, to securities trade clearing, and executing transfer pricing agreements between subsidiaries. Before blockchain was introduced into the mix with smart contracts, these types of use cases were difficult-to-impossible to achieve because each party in an agreement would typically maintain separate databases. A distributed, replicated blockchain-based database provides the infrastructure for smart contracts to auto-execute and all parties validate the outcome instantaneously and without need for a third-party intermediary. Blockchain can be a particularly worthwhile option when frequent transactions occur among a network of parties, and manual or duplicative tasks are performed by counterparties for each transaction. Blockchain acts as a replicated database to provide a secure, single source of truth, and smart contracts automate approvals, calculations, and other transacting activities that are prone to lag and error. The value proposition emanating from blockchain-based smart contracts is that, just like blockchain transactions, they are deterministic and provide a suitable means for replacing simple repetitive operations with repeatable accuracy. Business operations that require significant human contribution to determine outcomes from complex subjective decision-making tasks are not appropriate for replacing with smart contracts. Smart contacts are well suited for those operations where agreed to terms can be conveniently

A distributed, replicated blockchain-

based database provides the

infrastructure for smart contracts to

auto-execute and all parties validate the

outcome instantaneously and without need for a

third-party intermediary.




expressed in explicit digital logic (i.e. IF this condition(s) THEN execute this set of functionality). Moreover, smart contracts are most useful for mechanizing portions of a larger overall multiparty agreement when it can be broken down into unambiguous distinct components. In short, smart contracts may execute in a blockchain environment to bring added functionality beyond the recording of transfers in ownership and establishing ownership authenticity. The idea behind blockchain-based smart contracts is to algorithmically embody an enforceable agreement between unknown parties in a trusted environment without the need for an intermediary.

Relationship to Current Written Legal Agreements Today’s written legal agreements are put in place between parties as a means for establishing trust and where each party is expected to perform the tasks spelled out in the arrangement. Third parties acting as intermediaries, such as lawyers, bankers, and like, are employed to construct and negotiate agreements and ultimately are called upon to assist in enforcing the terms when required. In the situation when one party feels that the terms are not being satisfied a lawyer may bring the disagreement to court in an attempt to gain a judgment for a legally binding remedy. Consider a sales contract formulated to offer real property at an agreed to price. The sales contract consists primarily of a buyer presenting an offer to pay and stipulates any specific terms associated with performing the contract (e.g. a satisfactory inspection of the property). The seller may accept the offer whereby they are agreeing to the stated performance terms and conditions. One or more rounds of subjective negotiations may be required to reach a suitable agreement between the buyer and seller. The arrangement is consummated when compensation such as a payment is made and in turn the real property is transferred (i.e. the legal act of consideration). Simply put intermediaries including lawyers and bankers introduce a level of protection, acting as independent third parties, to promote the exchange of goods and services for business and consumer transactions. The need stems from a fundamental lack of trust between unknown parties and the desire for the exchange to transpire in a predictable and orderly manner. Distributed smart contract technology may provide the means for moving the interparty trust mechanism currently actualized within today’s formal written agreements and various intermediaries to hardcoded programmatic control.

Smart Contracts and Blockchain A smart contract is simply a self-executing contract; a codified agreement, stored at a blockchain address that can execute a set of ordered logic, or rules, in a consistent, predictable, and repeatable manner. The smart component is merely a set of event driven




processes that are triggered when predefined conditions, or agreed to terms, are met. The contract component relates to the practice of algorithmic representation of the steps required for negotiating between two or more parities. In this context the negotiation is a mutual understanding between involved parties to a given expected range of input conditions and the assignment of specific processing with each expected input. Smart contracts are typically described as hardcoded logic establishing agreed to terms between participating parties. Contract performance is the result obtained from executing this coded logic. It is important to recognize that although smart contracts may fulfill part of a legally binding contract this is not always the case. The legal system offers specific remedies when breaches occur during the performance of a legally binding agreement. Smart contracts typically provide a means for mechanizing a specific element within an overall contract rather than enact an entire contract. To this end smart contracts do not necessarily serve as legally recognizable and thus enforceable agreements. The term smart contracts can be troubling. Although volumes have been published regarding realizing legal instruments in digital form don’t get too involved in thinking about the subject terminology. From a legal standpoint all is needed is to appreciate that the execution of this digital logic may be may be interpreted as strictly enforcing hardcoded agreed to terms. In this way liability from breach are minimized since the parties agreed to use the smart contract. The input data employed and computational outcomes resulting from executing a smart contract may provide an evidentiary audit trail and lend sufficient insight to how the particular contract requirement was addressed as recorded in an immutable record on the blockchain. Enforceability is realized through the required writing of all outcomes as records recorded in blocks on the chain. Primarily for the purposes of this research report it is not valuable to delve into whether smart contracts may eventually replace attorneys and dramatically restructure our legal system and courts. Although if interested in pursuing this course of discussion there are numerous articles that examine, from a legal perspective, these implications.

Distributed Ledgers - Bitcoin versus Ethereum and the Hyperledger Fabric Bitcoin and Ethereum are design to cater and solve differing sets of business needs. On comparison Bitcoin’s reliance on managing crypto currency based exchanges provides a more secure platform with a performance advantage. The downside is that Bitcoin is less flexible in terms of the type and kind of functions available for invoking database modifications. These ledgers are primarily directed towards building applications for public use in a non-permissioned chain environment. Bitcoin scripting facilities provide an efficient set of predefined functions. Compared to Ethereum the Bitcoin scripting language appears narrowly bounded in offering only a minimal set of operations. Ethereum differs by basically allowing programmers creating




smart contracts the flexibility to work with their preferred high-level general purpose programming language. The most common languages include Solidity, LLL, Mutan, and Serpent where all tend to offer a rich set of functionality. The smart contract program is compiled into bytecode (machine code for a virtual machine) for uploading onto the network nodes. The main difference has to do with efficiency and simplicity in constructing the smart contract functionality. Although Bitcoin offers a more primitive set of operations than found in Ethereum this does not prohibit being able to realize capabilities in Bitcoin that can be fielded using Ethereum. The two are positioned to solve different problems. Bitcoin is a smart contract capability built into the blockchain for transferring assets of values such as coins or crypto currency. Bitcoin evaluates the outcome in terms of ensuring that the database entries deleted by a transaction are balanced by the database entries created. If each smart contract transaction balances then the entire distributed ledger is balanced. However, this is all about to change with RSK’s Ginger May 2017 release that brings Ethereum style smart contract facilities and functionalities to the Bitcoin network. RSK’s capability is essentially an off chain, or side chain, powered by Bitcoin for uses to create and run smart contracts. The off-chain design allows for improving transactional performance rates thus providing scalability while continuing to benefit from the highly secure public network. Ethereum is a more generalized environment where modification to a contract’s data must be carried out by the functions embedded in the contract’s code. Executing the embedded functions determines if the transaction should be executed and renders the data modifications for those transactions deemed valid. Ethereum offers greater flexibility over Bitcoin at the cost of performance. The most significant Hyperledger project is IBM’s blockchain platform offering or Hyperledger Fabric that was originated by the Linux Foundation. The platform is directed to providing a modular architecture for developing smart contract blockchain applications and services for businesses. Hyperledger Fabric is a private permissioned blockchain platform that does not rely on Bitcoin’s proof of work consensus mechanism. One particular feature is that the modular architecture supports switchable selection of consensus mechanism, ledger data storage format, and multiple participant access schemes somewhat analogous to plug and play. Managing participant access is of importance when deploying private blockchains to validate each participant’s identity. An influential goal of this project is to allow for a flexible open development approach aimed at bringing forth best practices and influencing the generation and adoption of industry standards. The focus on private chains is to address the need for allowing competitors to form relationships sharing customers and suppliers over a network but not share visibility into their ledger of




transactions. Private chain designs, such as IBM’s, are directed to providing the best platform for building industrial strength enterprise solutions.

Smart Contracts are Distributed Contracts Present definitions for smart contacts vary widely from (1) “code replacing law”, to (2) “agreed to terms for the transfer of ownership of an asset” (on the blockchain), to (3) “execution of code stored on the blockchain”. For consistency and simplicity this research report relies on a definition that cobbles together definitions (2 & 3) while avoiding the scope associated with definition (1). This section introduces TechVision Research’s take on forging such a definition. Distributed contracts are decentralized applications where identical code sets execute across the network on each blockchain node. Smart contracts provide a means for adding a trusted transaction facility, or layer, on top of a distributed ledger. In lieu of parties transacting with each other through a centralized application parties transact between each other on a peer-to-peer basis. Trust that is normally afforded by the single central application or service is now realized through blockchain technology thus removing the dependency/reliance on a third party or central authority. With traditional designs each party desiring to transact must build a sufficiently rich custom interface to interact with the central system. Blockchain relies on a peer-to-peer network where parties may broadcast their transactions to a plurality of nodes adhering to the same protocol. Blockchain smart contracts provide a mechanism to negotiate terms encompassing the purchase where the logic of the agreed to terms, or rules, are set in code. In other words, smart contracts are simply programs (hardcoded terms) that are built on top, or written as code into the blockchain. Once the smart contracts are validated through consensus and stored on the blockchain they cannot be modified. Smart contract code implements rule based algorithms that contain the logic for negotiating and executing predefined terms. The rules basically represent conditional clauses that prescribe “if this (condition)” is met “then do this (execute agreed terms)” commonly referred to as “if-this-then-that (IFTTT) code. The contracts operate by monitoring one or more event triggers, such as date and time of day. After one or more predefined terms are met, or agreed to, the smart contract may invoke a stored process such as charge an agreed to price based on the time a good or service is delivered. Because the stored processes are also stored on the blockchain all parties can trust in the output

Smart contract code implements rule based

algorithms that contain the logic for negotiating

and executing predefined terms. third-

party intermediary.




resulting from each execution. In this way the smart contract may to negotiate the final price for the good or service that depends on the actual delivery time. These digitally embedded hardcoded immutable contracts ensure that all participants in the transaction are aware of the details within the negotiated construct prior to entering into an agreement. In addition, the participants have a concise and exact understanding for the agreed to terms that will automatically be implemented once all the conditions are met. Smart contracts are applicable for use in a wide range of settings. To become an enforceable smart contract, three elements must be present in the coded logic: · An offer – presenting specific terms for performance of an agreement, · An acceptance – agreeing to said terms, and · Consideration - a reciprocal exchange of value between parties. For smart contacts to be effective certain preconditions may need to be met in order to track valuable assets such as automobiles, planes, real estate, and precious stones in a permanent record. For example in the case where an article is made for sale a registry or record needs to be created to capture the items defining characteristics the item and stored on the blockchain. This detailed characterization is needed to ensure authenticity, enable the transfer ownership, and to provide an immutable record of the items ownership history back to the source of origin. Detailed characterizations also facilitate in preventing fraud and other forms of marketplace abuse including mitigating theft and trafficking of stolen articles. Advertisements positioned to offer items for sale may reference said blockchain records to demonstrate authenticity of ownership (i.e. right to sell), previous sales history, and perhaps point to a vetted image reflecting condition and so forth. In this way buyers can be confident that the item description provides an accurate and correct representation. In short smart contracts operate on blockchain data and modify the chains contents. Users submit requests as transactions to trigger functions stored on the blockchain (i.e. smart contracts) where the functions are configured to read input data from the blockchain and to write output data to the blockchain database. To provide more of a pragmatic understanding of the possibilities of blockchain-based smart contracts, we’ll next consider three specific use cases and describe in detail how these scenarios might be carried out leveraging smart contracts and distributed ledgers. This may be a bit technical or detailed for some readers, but we feel it is important to get specific with respect to real-world use cases and the workflows associated with supporting these types of functions with smart contracts.




Use Cases Much like the vending machine example discussed earlier, smart contract logic can automate agreements between consenting parties in a pre-established way with predictable and enforceable outcomes. At the most general level smart contracts can execute functions that query the contents recorded on the chain, test the queried content, and then invoke an operation to construct an outcome, recorded on the chain, based on the results obtained from the test. This sounds complicated, but it is simply checking the status to determine if the smart contract conditions are met and if the agreement should be executed. Many articles and reports have been published that advocate the utility of smart contracts and embrace use case scenarios promoting business models, processes and operations that may benefit from adopting this technology. The goal of this report is to go beyond high-level descriptive scenarios and carefully examine the underlying functional details. Three common exemplary real-world use cases will be described to give the reader a sense for how this might work in the real world. The first case relates to asset tracking and more specifically to tracking packages while in transit. The second use case then considers how this can applied to supply chain management. The third use case relates to protecting intellectual property and copyright protection and more specifically to royalty distribution. We’ll now describe each scenario and how blockchain-based smart contracts can work to address these use cases.

Tracking Packages While In Transit Asset tracking use cases may vary in a wide range of complexity. Packages in transit and inventory control use cases are quite similar in terms of the overall handling, processing and reporting on items. Goods are entered or registered into the system and followed as they move from location to location, or department to department. Operations including transfer of ownership and payment processing may also be involved. Given those similarities, an asset tracking use case for packages while in transit is presented in this section. Although disclosed as a package tracking mechanism, it is understood that with minor modifications this use case is directly applicable to inventory management systems. The package tracking system may also be appropriate for replacing the existing shipping and tracking mechanism found with today’s eBay purchases and their companion PayPal

Ethereum network nodes operate to

distinguish that the transaction contains a

smart contract and automatically creates

its own blockchain address for the

programmatically coded logic.




payments. PayPal currently offers to act in an escrow agent capacity between parties where final payment is not made until the purchased item is received. The following use case assumes use of an Ethereum network as the alternative Bitcoin smart contract transaction data structures are quite different. Within the Ethereum network, smart contracts are loaded by sending a transaction to an address in the network that contains smart contract coded logic. The Ethereum network nodes operate to distinguish that the transaction references a smart contract and automatically creates a unique blockchain address for the specific instance of the programmatically coded logic. On validation the smart contract is broadcast as a template agreement onto the network. This address is made available such that transactions sent to this address invoke a new instance of the coded logic based on the input data received as a trigger. This use case is intended to illustrate a subset of the operations involved in the tracking of a package as it moves from its point of origin to its destination. The use case assumes that a smart contract on blockchain arrangement provides for automating the registering, tracking, and payment on delivery requirements of such a package handling system. Visualize a package in route where at various times while in transit a carrier scans the affixed barcode for purposes of identifying the package and to confirm its present location. Consider an arrangement where the carrier has installed a suite of Internet of Things (IoT) enabled scanning devices deployed at shipping terminals along each of their shipping routes. In this arrangement the IoT scanning devices are configured to capture said package barcodes at the time of arrival and time of departure from these shipping terminals. Scanning at both arrival and departure ensures a smooth transition through their terminal service centers. The is paramount in light of that, for example the United Parcel Services Louisville, KY Worldport facility may sort in excess of 500,000 packages per hour and the entire system processes +30 million packages on an average day. Further the IoT scanning devices are optionally configured to transcribe each captured barcode onto a blockchain-based database system. Each IoT scanning device may append their uniquely assigned device identifier datum, their physical location datum, and like information to the barcode datum. In order to store this series of real-time tracking information the IoT scanning device may be configured to generate a blockchain transaction. Storing the tracking information from these transactions in records on the blockchain transaction renders the purposed content available for use by one or more smart contracts.




We’ll next consider how this is accomplished with blockchain and smart contracts. In one arrangement the transaction generating process may embed the subject tracking information within the Transaction Message Field. The transaction generating process may encrypt the Transaction Message Field using the public key assigned to the self-executing smart contract targeted to consume said information as input. In the situation where the information is destined as input to a plurality of smart contracts a shared key arrangement may be deployed. The transaction generating process may digitally sign the encrypted Transaction Message Field output using the IoT’s own private key. The IoT scanning device may submit this encrypted and signed as a transaction to become validated and stored on the blockchain in an immutable time-stamped record. In practice the private keys are stored securely buy the IoT scanning devices and their public keys are stored on the blockchain. Whereas the smart contracts public key may be stored on the blockchain available to the IoT devices for encrypting the transactions. When the blockchain consensus mechanism validates an IoT device’s submitted transaction for recording data on the chain the transaction record address within the newly written block is sent back to the device where the device is configured to store this address. The devices may append this address within transactions it sends to the smart contracts to point where input data for use by the smart contract is stored. The use of the smart contracts public key during encryption ensures only those smart contracts possessing the matching private key can decrypt and access the Transaction Message Fields contents. Without the private key the sensitive content remains secure and not visible to outside processes or parties that lack authorization to view the subject information. The smart contract may use the IoT device’s public key to validate the signature, or digital hash of the message, to ensure the authenticity of the sending IoT scanning device. Only the IoT device has access to their private key thus only the owning device could have originated the Transaction Message Field content submitted with the transaction. This method of digitally signing provides for tamper, or spoof, resistant intra-operability. As a precondition assume that an originating package tracking blockchain transaction is generated at the package point of origin, such as customer drop off at a customer service receiving center, where initially a service agent enters descriptive package information into the tracking system. This information may include the sender’s and recipient’s contact information, the destination address, the agreed to selling price, and additional payment

The smart contract may use the IoT device’s

public key to validate the signature, or digital hash of the message, to ensure the authenticity

of the sending IoT scanning device.




terms. The agent scans the package to capture a first barcode scan using the local IoT scanning device. The IoT scanning device arrangement may be configured to submit a separate transaction for each element within the descriptive information for example a transaction for storing the payment amount into one record, storing the destination address into another record, and so forth. In this way all of the manually entered descriptive package information can be stored onto blockchain database where the set of records describe all the preconditions associated with the package. Validation of this these originating blockchain transactions may create a set of genesis records for the subject package where the descriptive information is made available for input to subsequent downstream smart contracts. In another embodiment the sender, or seller, may create a “Create-A-Shipment” request by accessing the carrier’s website and entering the requested descriptive package information including the ‘coming-from’ and ‘going-to’ addresses and like information. The carrier may implement a facility for submitting a transaction to the blockchain purposed for recording this information on the chain, for example encapsulating it within a transaction record’s Transaction Message field. The number of transactions submitted and the data content represented within is unimportant to understanding the overall use case and is left as a flexible design detail. Continuing on using the blockchain-based database affords all involved parties participating in the disposition of the package, for example the sender (e.g. a seller), the carrier or shipper (e.g. United Parcel Service), and the recipient (e.g. buyer), visibility into shared facts representing the package present location. The blockchain database maintains concurrent copies of these shared facts, existing in identical form, across geographically dispersed network nodes whereby each party sees the same information independent and regardless of the network node accessed by the parties. In one arrangement a smart contract may be configured to automate the making of a payment from the seller to the buyer triggered on the event where the package is delivered to the buyer’s destination. Each time an IoT scanning device captures the barcode it may be configured to submit a transaction for recording the scan information on the blockchain for audit traceability purposes. In concert each scanning activity the device may also trigger, or activate, the smart contract by sending to its address a transaction that includes the preconditions, in this case the present location, necessary to trigger the smart contract built-in hardcoded functionality. In this arrangement the smart contract may be configured to compare the presently reported location with the destination location. Recall that the predetermined destination address is known as it was recorded on the blockchain as part of the packages set of genesis records. Each scanning event generates a transaction submitted to the smart contracts address on the blockchain. In this case the present location is used as the trigger for invoking the smart contract where the smart contract functionality is configured to:

1. Receive the present address as input from the IoT scanning as a trigger,




2. Query the blockchain for the genesis record containing the destination location, 3. Compare the two records to determine whether they match, 4. If the two records do not match then exit, 5. If the two records match then query the blockchain payment amount genesis record, 6. Transfer this amount from the buyer’s account into the seller account as payment

for the package on delivery then exit. In the previous example a single smart contract was configured to ‘track’ the package and make a ‘payment’ triggered on when the currently scanned and reported location matched the destination address. Envision another embodiment that distills this single smart contract into two smart contracts. A first smart contract may be configured to perform the ‘tracking’ function and a second smart contract may be configured to perform the ‘payment’ function. In this embodiment the transfer payment smart contract adds additional functionality to the above example whereby if the package is not received by a pre-established expiration date the purchase agreement is canceled. In this embodiment the precondition information stored includes an additional blockchain record that stores the expiration date and the payment amount is stored in a separate blockchain record. The present location is used as the trigger for invoking the ‘Tracking’ smart contract where the ‘Tracking’ smart contract functionality, illustrated in Figure 1, is configured to:

1. Receive the present ‘In route’ address from the IoT Barcode Scanner as a “Trigger B”,

2. Read, via “Query A”, the Chain #1 record containing the “Destination Address”, 3. Compare the two records and determine they do not match, 4. Trigger the ‘Payment’ contract on Chain #3 with a transaction input value set to ‘In

route’ then exit, 5. Receive the final ‘Delivered’ address from the IoT Barcode Scanner as a “Trigger C”, 6. Read, via “Query A”, the Chain #1 record containing the “Destination Address”, 7. Compare the two records and determine they are matching, 8. Trigger the ‘Payment’ contract on Chain #3 with a transaction input value set to

‘Delivered’ then exit. Triggering the ‘Payment’ smart contract invokes functionality configured to:

1. Receive either trigger from the ‘Tracking’ smart contract on Chain #2 and read the associated transaction input data value,

2. Query the Chain #1 record containing the “Expiration Date”, 3. Compare the “Expiration Date” to the present date, 4. If the “Expiration Date” is not reached and the if input data value equals ‘In route’

then exit, 5. If the “Expiration Date” is reached and if the input data value equals ‘In route’ then

submit a “Payment Transaction” on Chain #3 and transfer a payment amount equal




to zero from the buyer’s account into the sellers account to reflect the package did not arrive within the agreed to terms and exit, and

6. If the “Expiration Date” is not reached and if the input data value equals ‘Delivered’ then query Chain #1 for the “Payment Amount” record

7. Submit a “Payment Transaction” on Chain #3 and transfer the “Payment Amount” from the buyer’s account into the seller account as payment for the package on delivery to reflect the package arrive within the agreed to terms and exit.

Figure 1: Package Tracking Use Case

In a further embodiment the payment smart contract functionality may be extended to arbitrate the shipping cost for the package that is adjusted and settled based on the actual delivery date. In this way the self-executed smart contracts may dynamically adjust the price of the delivered package contents based on arrival. In this embodiment the smart contract(s) provide the means for moving the adjusted final payment amount, as agreed to, from the buyers account into the sellers account in accordance with a continuously variable payment schedule.

Package

Details

Customer

Service

Agent

ExpDate

Loc A =Dest

Address

AddTerms

PmtAmt

IoTBarcodeScanner

IoTBarcodeScanner

IoTBarcodeScanner

Loc C =‘Delivered’

GenesisScan

Loc B =‘In route’

‘Tracking’Smart

Contract

Query A

Origin

Scan

Trigger B

Trigger C

‘Payment’Smart

Contract

‘In route’ Trigger

‘Delivered’ Trigger

Query Exp Date

Query Pmt Amt

Funds MovedFrom

Buyer toSeller

Block‘N’

Block‘N+2’

Payment

Transaction

Chain

#2

Chain

#1

Chain

#3




The package tracking use case is for illustrative purposes only and not considered the most efficient design. It is important in all designs to minimize the number of blockchain transactions as each query read, write, and smart contract invocation has an operating cost and system performance implication. In summary the buying and selling parties may be anonymous yet in the package tracking use case both can trust that the payment will be made based on their mutually agreed to terms. In this case the package arriving at the destination prior to the expiration date and the agreed to price. The buyer, seller and shipper involved in this exchange of goods can view and trust the carrier’s authentic digitally signed and time-stamped shared facts, or proofs, of location as they are recorded by the IoT scanning devices. This use case disclosed for tracking packages while in transit based on smart contracts potentially provides for an efficient means to replace the current PayPal escrow offering and eliminate the associated incurred fees. This is clearly a challenging early use case involving several geo-location data, IoT integration, anonymous buyers and sellers, automated payments…but should give the reader a sense of what is possible in leveraging existing blockchain and smart contract functionality. Let’s now extend this to supply chain management.

Supply Chain Management Supply chain management is a more complex version of the asset tracking system just reviewed. Supply chain management systems typically address all interoperable collaborative needs for communicating, coordinating, and tracking activities though integrated logistics for procurement, supply, and maintenance throughout a products life cycle. Numerous departments participating from multiple corporate entities may be involved to support the processes and operations behind planning, procurement, engineering, manufacturing, sales, distribution, sourcing and supply channels between customers, suppliers, and service providers. Effective supply chain management systems deliver trusted and reliable inventory information to all parties involved and in general span tracking the build materials, production, shipping/delivery, and maintenance status all related to the products present location.

The benefit gained by use of smart contracts

on blockchain in a supply chain

management setting is the elimination of

reconciliation activities between participating

parties since each operate off of and view a common and shared

database.




From the previous asset tracking use case it can be appreciated how build materials and transportation operations can be accommodated by deploying smart contract on the blockchain using IoT scanning devices to record items as they move about from location to location. In a comparable way smart contracts can be used to track the origin and delivery of materials used in the construction of a product and paid for on receipt. IoT devices can record each step as a product moves from a factory floor to the store shelves and record these movements in an immutable ledger. In this way smart contracts appear to be well suited for providing real-time visibility for every step in a supply chain where the access to and visibility of this information can be tightly controlled. They facilitate granular-level inventory tracking, benefitting supply chain financing, insurance and risk. Such enhanced tracing and verification reduce the risk of theft and fraud. The identities of supply chain participants can be continuously attested to over time, including companies, institutions, individuals, sensors, facilities and products. Smart contracts have direct applicability to managing goods and products as they transit throughout a product supply chain. The blockchain can be used to track certain aspects during the lifecycle of a product beginning with its inception and to the point where it is deemed a completed good or finished product. Smart contracts may be configured to query various records stored on the blockchain, invoke arithmetic operations against the queried records (and like programmatic functionality), and record the outcome in blockchain transaction records. A smart contract may become triggered to self-execute based on reaching a predefined condition, such as an expiration date, from the outcome of another smart contract, or by receiving a transaction requesting execution. Supply chains typically involve managing various aspects of the build process for a product destined for a particular client application where a legal agreement is entered into by the supplier and the client. Generally a written legal document is constructed with definitive language to represent each party’s responsibilities and distinctly calling out explicit performance terms and conditions. The written document may also include a precise characterization of product by stating a set of detailed requirements. This characterization typically includes specifying success criteria in terms of measurable performance parameters. The agreement may call out a plurality of test to be performed at specific milestone marks during the build process as the product travels along the production cycle. The complete set of milestones may be used to establish the terms for determining customer acceptance. More specifically the agreement may set forth the terms regulating when the title is transferred from the supplier to the client. In manufacturing setting, IoT devices may do more than just read barcodes. To ensure quality at all stages of the production cycle consider the deployment of IoT devices at quality inspection points. An acceptance value relating a quality performance measure may be stored on the blockchain and used to by a smart contract in evaluating the test results obtained from an IoT enabled test jig. The test outcomes may be compared against the




acceptance values and milestone payments could be asserted if successful. This arrangement is really no different that the package tracking arrangement. It can be understood how a similar smart contract arrangement could be used to ensure the yield quality of a pharmaceutical or biological drug and like products as they travel through their production cycles. Supply chain management is representative of a more complex asset tracking business model arrangement. The product tracking may start with sourcing the materials need for construction, manufacturing processes and operations during the build process, maintenance while in productive use, and up until it is removed from production and disposed. It is assumed that more complicated arrangements can be appreciated wherein multiple suppliers and clients cooperatively interoperate. The fundamental benefit gained by use of smart contracts on blockchain in a supply chain management setting is the elimination of reconciliation activities between participating parties since each operate off of and view a common and shared database. We’ll next look at a very different scenario in handling the automated distribution of royalties.

Royalty Distribution The use of intellectual property and copyrighted materials are generally subject to paying a royalty fee to the assigned owner of the property. The music industry typically involves numerous rights-holders participating in the collection and distribution of royalty payments. Due to the number of participants and other factors the settlement timelines for artist to receive their compensation may take over a year. The following royalty distribution use case illustrated in Figure 2 is directed towards examining how smart contracts could affect automatic simultaneous parallel payments to the rights-holders, e.g. songwriters, performers, artists, labels/publishers, content distributors, and so forth) and drastically reduce the time required to make such a payment. In this exemplary arrangement it is assumed an artist publishes a creative new work such as a musical composition, or collections of music, and registers their work with the copyright office. The artist stores their published works in encrypted form outside of the blockchain where a Digital Rights Management (DRM) key may be used to unlock the file.




Figure 2: Royalty Distribution Use Case.

The artist may elect to record this registration of intellectual property on the blockchain to demonstrate their exclusive rights for the use and distribution of this work. The blockchain’s native immutable and permanent record characteristics provide for a logical choice since copyrights typically are granted for the duration of the creator’s life plus 50-100 years after they die. Along with ownership rights the artist stores various track details including the price of the song/track as a payment amount, the royalty split amongst parties, the names of the parties involved, and like descriptive information as metadata associated with each song/track. It can be envisioned that metadata may be recorded that relates to situations where the song/track is streamed versus purchased and downloaded. For example, in the streaming case the available for playback use period may also be set. The upload of metadata onto Chain #1 as illustrated in Figure 2 can be accomplished by the artist where the ownership rights form a portion of the song/track ‘persona’ as a vetted and verifiable profile. We’ll now describe what happens when a title is purchased using smart contracts. Consider that a buyer has purchased a song/track for download and perhaps even paid with crypto

Parties

Buyer’sAccount

‘Rightto Use’Smart

Contract

OwnershipRights

RoyaltyPayment

Terms

Chain #1

‘Payment’Smart

Contract

BuyerRequest toDownload

Track

Track Details

Artist

A

C

D

PaymentAmount

F

Funds MovedFrom

Buyer toArtist

B

BuyerRead DRM

Funds MovedFrom

Buyer toPublisher

Funds MovedFrom

Buyer toDistributor

Use

Policy

Key &

Location

Trigger

E

Account

AddressesPMT

% Cost

Track ID

Trigger

Key & URL

P3

P2P1

Chain #2

Chain #3




coins such as through the Bitcoin network. The purchase activity or more specifically the buyer’s request to download the particular work may be used to trigger a ‘Right to Use’ smart contract stored on Chain #2 where a track identifier is submitted in a transaction to the smart contract. The ‘Right to Use’ smart contract may be configured to query the ownership rights record stored on Chain #1 for purposed of obtaining specific use policy at point A and supporting details. These details may include an URL where the actual content is stored and a DRM key for unlocking the content. According to the use policy the ‘Right to Use’ smart contract may write these values to the buyers account at point B. The writing of the URL and DRM key to the chain stored by the buyer’s digital wallet will allow their local media player to locate and render the protected content. The ‘Right to Use’ smart contract may be configured to call, or trigger, and invoke a ‘Payment’ smart contract in an arrangement for distributing royalty payments to each involved party. The calls are realized by the ‘Right to Use’ smart contract submitting transactions to trigger the ‘Payment’ smart contract. Triggering the ‘Payment’ smart contract invokes functionality configured for:

1. Receiving the trigger from the ‘Right to Use’ smart contract, at point C, where the trigger contains the song/track identifier,

2. Querying the blockchain based on the song/track identifier to locate the record(s) containing the name(s) of the parties available to royalty distribution and their account addresses at point D,

3. Querying the blockchain based on the song/track identifier to locate the record(s) containing the royalty distribution terms indicating the payment percentages for each party at point E,

4. Querying the blockchain based on the song/track identifier to locate the record(s) containing the price paid by the buyer for the song/track as a payment amount input for calculating the amount of funds for each party at point F,

5. Calculating each payment, in this case for three participating parties, based on the information received from the previous three queries,

6. Transferring the first calculated amount, illustrated at point P1, from the buyer’s account into the artist’s account as their royalty payment share,

7. Transferring the second calculated amount, illustrated at point P2, from the buyer’s account into the publisher’s account as their royalty payment share, and

8. Transferring the third calculated amount, illustrated at point P3, from the buyer’s account into the distributor’s account as their royalty payment share, and exit.

According to this illustrative arrangement a first smart contract controls access to the content and a second smart contract immediately distributes royalty payments. The first smart contract may provide for controlling the physical content distribution using URL’s as indexes to the stored location and for managing digital access through the distribution of DRM content protection keys. The location and access information are both secured in records on the blockchain and thus inherent all the benefits afforded by use of this




technology. The artist, and other parties, is now paid directly in near real time just after the sale is made. The multiple ‘Payment’ smart contract queries are for illustrative purposes only. In reality design trade-off would be made between ease of modifying the track details metadata, for example a price increase, how the metadata may be employed by other smart contracts, and cost and performance impacts resulting from multiple queries. In summary, this use case provides the means for an artist to publicly list their ownership rights on the blockchain where the artist establishes the price for their content, licensing arrangements, and set other related purchase, distribution and use terms. Song/track delivery is managed by smart contracts. In short, this smart contract enabled royalty distribution use case affords the following operations and processing without the need for an intermediary:

· Store published works in a decentralized blockchain library including books, music, and like works in a global publicly available registry,

· Search and find owner of a registered work · Sell works directly from artist to consumer, or from ‘iTunes’ or other such facility, · Make payment, · Obtain a license or right to use work, · Receive content via download or stream work (e.g. track), · Receive DRM key, · Render content via a media player, and · Distribute royalty payments.

Smart contracts on blockchain have the ability to remove the current intermediary infrastructure and establish a direct relationship infrastructure between the artist the consumer(s) of their material. Currently content distributors do not provide the artist visibility into any purchase details. Artists remain totally reliant on the intermediaries acting between the purchaser and the receipt of their royalty payment that occur infrequently and are error prone. Not privy to the underlying details regarding how royalty payments are neither calculated nor available to the real data that describes how their works are consumed (e.g. number of downloads and streams). Rarely do they have access to the intricate and complex distribution of funds between all of the intermediate parties. With the advent of on-line distribution platforms such as iTunes and YouTube their dependence has increased. These visibility concerns may be mitigated or eliminated altogether by incorporating smart contract and blockchain technology in accordance with the above use case. This could also, of course apply to software, publications or other types of Internet-accessible content.

Smart Contract Use Case Summary There are a number of business models that can directly benefit from deploying the trust




infused smart contracts on blockchain platform over current design methods. The smart contracts on blockchain platform encapsulate business rules regarding processes and operations into self-executing transactions. These self-executing transactions are placed into effect within a deterministic ecosystem where new entries, or records, are formulated from present records inherited from deterministic transactions. From this the outcome, or record, generated from each self-executed transaction acquires the characteristics derived from the input or source data. In view of smart contracts only receive input from existing blockchain records they generate outcomes that exhibit like characteristics including:

· Immutability – tamperproof trusted records through encryption, · Verifiable accountability – proof of existence through time stamped records, · Non-repudiation- authenticity through digitally signed transaction, · Consensus – mutual agreement that transactions are valid, and · Provenance – know origin and historical lineage.

The previously described use cases highlight how smart contracts may be linked together where a first contract formulates a transaction and submits this transaction to the second smart contracts address. The second contract is triggered by this transaction and consumes the information conveyed in the transaction to instruct its native functionality. By linking and cross linking a large array of smart contracts together, operating on vetted immutable data, in this way provides a mechanism for automating increasing degrees of complexity all regulated by an agreed to set of terms. This type of linking has the potential to someday, perhaps within five years, to automate significant portions and complement the execution of complex traditional written contractual agreements.

Potential Smart Contract Implementations There is a wide range of use cases that will benefit from implementing smart contract designs. TechVision believes that these are potential opportunities for further exploration, but as described in our high-level uses cases there is a lot of work to be done before codifying and automatically executing smart contracts. Without thorough consideration and specification of the intricate underlying details involved with each candidate application citing a high-level laundry list seems fruitless. In order to appreciate the utility of smart contracts on blockchain each use case must be approached in detail in concert with the two cases illustrated in this report. Absent of this analysis the listing of potential applications may lead to misinterpretations and missed expectations. In order to ascertain the suitability of this technology for augmenting current business operations and process TechVision strongly suggests following such a detailed approach. First document your business model in terms of use cases and second determine of these operations and processes can be distilled into “If This Then Do This” logical conditional comparisons. Combining the output from these steps with the native characteristics found with decentralized distributed technologies will yield whether these methods are appropriate. We’ll highlight some of the areas of caution




enterprises should assess when considering leveraging smart contracts.

Smart Contract Limitations and Roadblocks TechVision Research suggests the single and most significant limitation present with

consideration of smart contracts today buying into the exaggerated and overstated expectations

created by the wave of excitement associated with both blockchain and smart contracts. The

expectations setting for exemplary business problems, processes, and operations where the

application of this technology holds promise is unfortunate. We advise our clients not to buy into

this hype until you have developed your own detailed understanding and diligent marketplace

vetting. The technology is highly complex, embryonic and faces cultural and regulatory hurdles.

The second source of confusion arises from reports

suggesting that the technology is unproven and

thus unreliable. TechVision Research suggests that

the underlying technology is sound although very

early in production use terms. Problems may arise

from deploying inadequately designed, configured

and tested applications. It is paramount for

programmers to be aware of and consider all

possible outcomes that may result from executing

their code in a distributed, decentralized,

concurrent and replicated environment.

This report section is not intended to be exhaustive. It is directed towards examining the current

state of the industry and to indicate where the industry is headed.

Limitations In general smart contract technology experiences the same limitations found with blockchain technology including:

· Constrained Performance – it takes 6-10 minutes to build a block of verified transactions using a public, permissionless blockchain

· Chain continuity – to modify and update the underlying design protocols a hard fork in the chain is required

· Finite scale – where current transactional throughput is bounded at about 10 transactions per second

Some of the characteristics that require careful examination when considering the use of smart contacts for mechanizing business operations and processes include but are not limited to:

· Unintended results from logic errors and bugs within the code producing immutable records

The technology is highly complex, embryonic and

faces cultural and

regulatory hurdles.




· Private encryption keys remain vulnerable yet underpin the trust of the entire ecosystem

· Liability implications

The biggest risk to successfully implementing smart contract based enterprise solutions arise from not sufficiently anticipating all possible input data values submitted by transactions where an unexpected outcome results from an unanticipated input. The most significant limitation lies in not being able to translate subjective intent embedded in written agreements into code and ensuring a comprehensive mapping between the written agreement and the code.

Internet, IoT, and Sensory Data Access

Currently, technical differences between how the Internet operates and how blockchain-based smart contracts operate limit their ability to interact. Blockchain’s are designed to be completely deterministic. Consider the situation where a node gets interrupted or goes off-line. To restart the node, it begins with its last stored verified block and recreates all of the missing blocks by validating the missing blocks using the mining nonces generated from other nodes on the network during block validation. In this way, the restarted node may catch up and reach the correct state of all the other network nodes. Simply put, the deterministic characteristic of the blockchain is the fundamental element that allows for nodes to reach a consensus. The Internet is non-deterministic and is always changing state as time elapses. Attempting to rebuild network transactions at a later instance will generate a differing outcome. Thus a consensus of the transactions would not be reached. The implication is that smart contracts cannot source, or rely, on data values directly obtained from the Internet. In order to remain deterministic, the data input values must be obtained from a transaction outcome recorded on the blockchain. In this way the chain holds all of the information necessary to verify itself. The integration of the nondeterministic Internet with deterministic blockchain platform is well known and current efforts are attempting to make them interoperate. One such effort is Microsoft’s Project Bletchley endeavor to advance the separation of the movement of data from the logic or processing of that data. Project Bletchley introduces a new blockchain facility called Cryptlets as a means for secure communications between the

most significant limitation lies in not

being able to translate subjective intent

embedded in written agreements into code

and ensuring a comprehensive mapping

between the written agreement and the

code.




Microsoft Azure fabric and customer technologies, e.g. legacy systems) to facilitate transaction execution. This fabric component is crucial for actualizing interoperability by providing additional information as need to execute a contract or transaction on the blockchain. Project Bletchley postures a three-tier layered architecture for use by businesses in consortium and private chains. The architecture comprises a data layer, business layer and presentation layer. TechVision Research will continue to monitor the progress advanced by this report and provide further research reports as necessary.

Cost and Performance

The execution cost for each smart contract operation is directly dependent on the number and type of resources required to complete the transaction. In the Ethereum network the cost to execute an agreed to set of terms is determined by a number of factors and parameters including but not limited to the:

• Total number of nodes comprising the network wherein each node must execute and verify identical sets of code,

• Aggregate of smart contracts called where a plurality of contracts may be involved (e.g. linked together),

• Number of the functions called within each contract, • Function complexity (e.g. verifying a digital signature is more expensive that an

arithmetic operation), and • Desired execution priority by the network miners where the faster the desired

execution time, or priority, equates to a greater cost. Continuing on with Ethereum, Ether is a form of payment to cover the cost of execution (e.g. initial and subsequent transactions, CPU, bandwidth, and so forth) or “crypto fuel” used by network clients desiring to execute a contract or set of contracts such as found within a decentralized application (DApp). Typically, the amount of Ether is estimated prior to execution and is sent along with the execution request. In the situation where insufficient Ether is available or is consumed prior to completion an ‘out of Ether’ exception condition is triggered where all database content modifications are returned to their original state. In this situation the contract does not finish yet the fuel is spent. The major factor that determines the overall execution performance is determined by the slowest node on the network. Since all nodes must agree on the generated outcome, or reach a consensus, the operation(s) cannot conclude until the slowest node finishes. Operational performance is also regulated by how efficiently the contract was coded, latency in the network, and like influences.




Native Blockchain Limitations

Although transparency is touted as one of the basic advantages of blockchain technology, close attention must be given to what asset transfer information or outcome is desirable to be recorded in pubic distributed ledgers as a result of executing a smart contract. This is paramount to ensure that sensitive corporate intelligence is not made readily available to outside competitors. Even private blockchains are subject to providing insight into transactions deemed sensitive. For example, consider a consortium of financial institutions establishing a hybrid permissioned blockchain network where two parties conduct a transaction. Once the asset transfer is recorded on the blockchain, it may become immediately visible to all participating institutions. IBM’s Hyperledger Fabric approach for mitigating this issue requires businesses to deploy private chains. Network stability may become a concern where latency varies sufficiently to delay message (i.e. transactions) delivery or complete interruption resulting in invalidating transactions by affected network nodes. Similarly, transactions may become invalid when the data in transit becomes corrupted. Lastly private keys that are not sufficiently secured may become compromised allowing for adversaries to gain account control. Regulatory Climate

Government regulations such as compliance regulations in the finance sector are truly complex and quite rigid. Typically hardcoded into today’s banking legacy applications as found in audit reporting facilities. Enormous investments have been made over time to instantiate these needs into the business operations application platforms. The volume and complexity brought about by these controls may become prohibitive when contemplating mechanization on a new technology such as smart contracts. Smart contracts may be well suited for addressing finely distilled portions of these regulations where the complexities can be resolved into very simple expressions (i.e. recall If this Then this type of logic expressions previously disclosed). Taken as a whole there is no simple solution and thus the scope and cost of such a project remains hard to predict. Moving business procedures and processes that support current operations potentially involves too many assumptions to be made at this point given the current ecosystem sophistication and lack of best practices. To that end it becomes a stretch to believe that a financial institution would make this leap of faith without further evolution and standardization of the existing smart contract and blockchain architectures.

Protocol Change Management and Hard Forks

The evolution of blockchain facilities and features is governed and regulated by the community stakeholders involved in operating the network such as miners that operate the Bitcoin and Ethereum networks. As these communities continue to grow so does the




difficulty in gaining consensus on implementing new or changes to existing agreed to rules of conduct prescribing the operation of the network. Rule changes typically result in a splitting of the network where a new group of participants form a governing body and agrees to operate a new blockchain according to a new or modified set of rules. It remains too early to ascertain the true impact of these splits of forks in the blockchain. A particular hard fork that stands out occurred on the Ethereum network in October 2016 as a result of a defect in a decentralized application allowing ether to be stolen. The network operators agreed to change the underlying protocol to facilitate the recovery. Clients that failed to update to the upcoming fork remained synced to an incompatible chain using the old protocol and left unable to interact with the post fork system. This is significant because in-effect when the operators decide to rewrite the contents recorded in the chain the immutable nature of the chain was lost which is contrarian to the original blockchain premise. To this date, there are two versions of truth in Ethereum.

Use Case Anomalies and Misconceptions The following use cases are presented to illustrate certain current technical limitations currently found in using smart contracts.

Monitoring of External Events Misconceptions

The desire often exists to incorporate the monitoring of a changing value or measure from an external service for triggering one or more terms within a smart contract. A commonly proposed example involves weather reporting. The proposed smart contract is configured to ‘sample’ the current weather conditions from an external local source and trigger events based on the information gathered. Each network node is assumed capable of separately pinging the weather source for current conditions. Although blockchain nodes do not implement this ‘pinging’ capability the use case continues to be promulgated. Even if the pinging capability was available, or realized through some programmatic mechanism, this use case may become problematic where each node may receive differing values from their request. The differences may arise from: · Differences in latency within the communication network, · Varying response time due to the load on the reporting server, · Changes in value between the arrival times of each received request · Interruptions in service or maintenance downtime, and · (Like) influences causing the nodes to not receive identical responses.

To achieve consensus the blockchain system can

only succeed when every node reaches an identical state.




In each of these situations the network nodes operate on non-deterministic values that cause the transactions to fail because consensus could not be reached. To achieve consensus the blockchain system can only succeed when every node reaches an identical state. The differences in received responses will cause two or more nodes to disagree about the validity of the transactions within the next newly block being formed. In this situation the transaction will be deemed invalid and be omitted from inclusion into the next block. A similar problem may arise when a use case describes a smart contract arrangement for making calls to an Application Programming Interface (API) in order to invoke processing external to the blockchain network. For example, when computing a smart contract that includes a function for calling a microservice email messaging service API, configured to send an email message when triggered, every node will perform the identical call. This becomes problematic where the API ends up receiving potentially thousands of identical calls where only one is need to accomplish the desired messaging. In this way, blockchain smart contract technology is limited to use of deterministic data only and may not support the retrieval, or pull, of data from external sources or systems. The system is reliant on identical data values during execution that must be pushed to and recorded on the blockchain. Workarounds are available for mitigating both of these limitations. For example, the ‘Smart Oracles’ have been suggested as a method for resolving the external system dilemma. Smart Oracles, acting as a trusted party, may be configured to create one or more transactions where the required external data is written onto the blockchain. The smart contract function will be pointed to this address to obtain the externally generated data value. In this way, each node will operate using an identical copy of this data stored within their local blockchain database and thus be able to reach consensus. In lieu of incorporating API calls within the smart contract a trusted service may be arranged to monitor the blockchain’s state and invoke external procedures based on observed results. For example, the smart contract may execute and complete a particular transaction. The monitoring system may continually observe the various transactions posted in the distributed ledger. The monitoring system may be configured to invoke an API call based on “reading” a specific transaction outcome stored on the blockchain. The major limitation arises where both workarounds require an external trusted party to interface the blockchain system to external systems. In this researcher’s opinion, for public chains, this method reintroduces a centralized trusted intermediary into the overall solution. The technique may be appropriate for private chains.

Exemplary Use Cases Involving Automatic Payments




A number of smart contract use cases for automatic insurance policy premium payments have been contemplated and published. Basically, at preset periodic time intervals a smart contract is configured to transfer funds from an individual’s crypto currency account into the institutions crypto currency account. The smart contract is able to enforce and guarantee timely payments since both accounts reside on the blockchain. In essence this is a blockchain database operation that occurs at an agreed to instance in time. This database operation may become problematic in the situation where the individual has exhausted all of their crypto currency funds. Similarly, smart contracts are not suitable for making other type of automatic payments such as for home, car, plane or boat loan payments for the same reasoning. In order to work the payee would have to establish an escrow account under the control of the lender. The lender would need to constantly monitor the remaining escrow balance to ensure sufficient funds are available to meet the next and subsequent payment obligations and maintain control over its replenishment. A comparable problem arises in distributing funds associated with financial vehicles such as annuities, investment interest payments resulting from bond coupons and stock dividends and so forth. In each case the funds would need to remain under the control of the instruments smart contract. Today’s investment vehicles cannot be realized if the funds currently used to support such investments must be held in an escrow account where they cannot be repurposed to generate investment income. This problem does not arise in use cases involving buyers and sellers when situations arise where the buyer does not have sufficient funds for payment. In these insufficient funds situations the agreement fails due to the lack of payment and the ownership of the product or asset under consideration is not transferred.

TechVision Research clients can expect access to regular updates on the latest developments with respect to the limitations cited in this report as there is significant investment and momentum towards addressing these issues.

Platform Evolution, Maturity, and Potential Benefits The biggest challenge facing the smart contract development community is figuring out how a deterministic platform affording trust can interoperate within a stateless nondeterministic environment - aka the Internet connectivity platform.

Platform Evolution and Maturity The smart contract’s market-space continues to experience what amounts to almost

state of Arizona passed groundbreaking

blockchain and smart contract law in March

2017




boundless resource investments. From large banking consortiums under FinTech initiatives to premier technology suppliers (e.g. Microsoft, IBM, and many others) the list of players is exhaustive. The net effect is that the supporting ecosystem is evolving at a rapid pace. Although there remain significant limitations, it is expected that the cooperative push will continue and resolve today’s constraints. For example, new proof-of-work based consensus engines have recently been developed and are directed towards improving transactional performance and improve overall network stability. For example, the Jaekwon Tindermint consensus engine is currently a commercially fielded blockchain platform trialed by several companies and Daniel Larimer’s Graphene consensus engine currently being trialed by Bitshare and Steem.

Legal Remedies Vast bodies of common law encapsulate legal agreements formed between two or more parties providing substantive definitions and legislative guidance directed to enforcing these agreements. Over the last 25 years this body of law has expanded to address digitally embodied agreements. Although smart contracts are not yet officially inscribed, existing law will advance and expand the framework directed to enforcing and performing this new body of agreements accordingly. To wit the state of Arizona passed groundbreaking blockchain and smart contract law in March 2017 under House Bill 2417 where, in layman’s terms, records or signatures in electronic form cannot be denied enforceability. The implications are that smart contract terms administered through blockchain technology fall under the definition of electronic form as they are digitally signed. Moreover the statute in general defines blockchain technology as a distributed, decentralized, shared and replicated ledger and more specifically defines a smart contract being an “… event driven program, with state, that runs on a distributed, decentralized, shared and replicated ledger that can take custody over and instruct transfer of assets on that ledger ...”. In short, the recording of smart contract execution in immutable blockchain records may provide a supportive audit trail to establish whether the terms of a legal agreement were met.

Ecosystem Infrastructure Push The key to blockchain and smart contracts is the evolution of a supporting ecosystem and the velocity is rapidly accelerating. For example, Microsoft continues to augment their Azure fabric positioned as a public cloud based computing platform with attention focused to building the necessary foundation for smart contracts and blockchain-based applications. In recent months Microsoft has pushed forward by introduced new integral components to further their ‘Enterprise Smart Contracts’ offering. Recognizing identity management and cryptographic key distribution being central to realizing enterprise strength distributed




smart contract based applications Microsoft has fielded Azure Key Vault and Azure Active Directory components to their Blockchain-as-a-Service offering. Azure Active Directory provides the necessary authorization framework for controlling access to data and resources where Key management facilities are supported under Azure Key Vault. These infrastructure advancements and those yet to come, further ease complexities found in deploying smart contract and expedite the total development cycle. Last year Microsoft unveiled Project Bletchley promoting a layered software design approach for building industrial strength distributed and decentralized blockchain applications. Prior to this approach smart contract data and logic were combined. This led to performance, scalability and stability issues. Akin to the evolution of the ISO 7 layer stack for implementing networking protocols for the Internet, Project Bletchley is helping to advance the separation of the movement of data from the logic or processing of that data. Project Bletchley introduces a new blockchain facility called Cryptlets as a means for secure communications between the Azure fabric and customer technologies to facilitate transaction execution. This fabric component is crucial for actualizing interoperability by providing additional information as need to execute a contract or transaction on the blockchain. IBM, Ethereum, the Hyperledger Foundation, the R3 consortium and many others are also building ecosystems to support the evolving blockchain movement. These efforts and similar ones to follow will help lead the way to formulating standards and scalable, providing production-level services for enterprises and consumers.

Potential Enterprise Benefits Blockchain-based smart contract applications potentially could offer a number of benefits including: · Reduce execution times, · Improved recording accuracy, · Lower security risks such as manipulation

from tampering, · Involve fewer intermediaries, · Lower total cost of operations, and · Introduce new business or operational

models. Mechanizing existing repetitive manual tasks through the use of software-coded applications involving smart contracts may decrease the overall end-to-end execution time associated with a wide variety of today’s business processes.

Automating manual tasks not only may

improve execution times but automated

transactions have the potential to improve

data quality by eliminating errors often

found with manual processes




Automating manual tasks not only may improve execution times but automated transactions have the potential to improve data quality by eliminating errors often found with manual processes. Distributed consensus based data storage operations may afford the opportunity to mitigate the security risks associated with outside data manipulation and like negative exposures influences found in today’s centralized designs. Smart contracts may reduce or completely eliminate the need for reliance on third-party intermediaries that provide “trust” services such as found via escrow between counterparties. The inherent distributed and decentralized architecture provided through use of smart contract implementations administers the needed trust mechanism accommodated within the network arrangement itself. New and updated business processes augmented with the application of smart contract technology configured to reduce or replace the need for manual intervention holds the potential to reduce the total incurred operating costs. Likewise, the elimination or reduction in reliance on third-party intermediaries may subsequently eliminate or reduce the fees paid to utilize these third party services. Smart contract implementations may provide for lowering operating costs and a means for ensuring that the transactions are reliably performed as agreed upon, may afford new avenues for conducting businesses potentially ranging from peer-to-peer excess capacity trading from renewable energy sources such as photovoltaic’s to automating access to homes, vehicles and storage units without the need for a physical key to be present.

State of the Industry A number of technical and legal challenges are barriers limiting the widespread adoption of smart contract and blockchain platforms. The challenges include cost, consensus processing times, and transaction processing scale. The legal challenges involve attaining enforceable digitally executed agreements by their incorporation into existing legal and regulatory statues at the federal and state level. Data stored on public, consortium, and private distributed ledgers remain exposed to certain security and privacy risks while smart contracts are still subject to hacking. These risks are well known by the industry and currently being investigated and resolved. TechVision characterizes the present rate of advancement in smart contracts and blockchain technology as being far more rapid than that experienced with the development of the Internet. Think back to how quickly CSMA/CD became Ethernet and how once TCP/IP became adopted HTTP followed. Blockchain has evolved from transferring ownership of crypto currency to multilevel tiered architectures, such as Microsoft’s




Hyperledger cryptlet fabric, where nondeterministic legacy systems and Internet connectivity are becoming interoperable with deterministic smart contracts and blockchain platforms. The true potential opportunity for replacing current legacy systems and centralized technology with smart contracts on the blockchain is still to be seen. Today’s investments are sizeable which directly reflects the complexities involved in trying to distill down today’s agreements into a series of linked intra-operable self-executing programmatic code sets. It is an enormous undertaking in light of needing to be seamlessly integrated with today’s automated platforms. The commitment and desire to gain efficiencies over today’s automation strategies is apparent given the continuing investments being made in smart contract and blockchain platform development and business model use case realization. Simply put smart contracts and blockchain are going to happen and emerge as the preferred implementation for a vast range of services.

Findings and Recommendations Smart contracts are simply deterministic programs that can be executed based on the terms of an agreement where the outcomes are enforced by endorsed digital logic. Smart contracts can benefit from blockchain security, time-stamps and transaction verification without requiring an intermediary. This represents tremendous disruptive opportunities as well as some major challenges. TechVision is optimistic about the future value of smart contracts for the enterprise, but the key word is future—it is not here now for general production use, but it has the potential to grow rapidly and have a disruptive impact. There is a tremendous flurry of activity and high expectations, and we suggest our clients make sure they are prepared to take advantage of the opportunities as they emerge. Smart contracts can and should leverage blockchain, in particular where there are external parties involved. The distinctive benefit lies in that smart contracts inherit all of the native characteristics found with distributed ledger technology including immutability, trustless, disintermediation, security, accuracy and reliability. Consolidating these benefits, and more specifically trust, into a computational platform provides an evolutionary means for mechanizing and automating portions of today’s paper based agreements.

benefit lies in that smart contracts inherit

all of the native characteristics found

with distributed ledger technology including

immutability, trustless, disintermediation,

security, accuracy and reliability




Despite the technical, cultural and legal limitations associated with smart contracts, there is a massive future opportunity for our enterprise clients to better automate and govern external relationships. Driven by vast investment sums and stalwart commitments made by premiere technology platform innovators blockchain and blockchain-based smart contracts are going to happen. The present uncertainty lies with what the final ecosystem will look like and behave in concert with how rapidly technology leader’s solutions reach widespread adoption leading to the formulation of de facto industry standards.

Summary Findings Smart contract transactions permanently recorded on blockchain-based verifiable records keeping ledger systems will enable new applications to be deployed free from tampering and protected from change where the outcomes cannot be modified, deleted nor revised. Building contractual terms into digital logic where the results are stored transparently in an open distributed replicated ledger allows for every step in agreed to terms to be captured in a digitally signed record available for inspection by all participating parties. Moreover, each party or the node they interact with, stores concurrent copies of the same digitally coded agreed to terms. So, let’s net out what this means for the enterprise. Today’s paper agreements are put in place between parties as a means for establishing trust where each party is expected to perform the tasks spelled out in the agreement. Lawyers, acting as intermediaries, are employed to construct and negotiate the agreement and ultimately are called upon to enforce the terms when required. With smart contract technology trust between parties is established through the peer-to-peer networked replicated and concurrent version ledger. Negotiation is predetermined by the logic constructs and execution is realized when the embedded terms are met thus automating

With smart contract technology trust

between parties is established through the peer-to-peer networked

replicated and concurrent version

ledger.

The technology, as demonstrated by

Bitcoin, Ethereum, Hyperledger and others is sufficiently secure to allow parties to enter

into an agreement and in some situations

without revealing their identity.




enforcement. The net change is that the intermediary function is moved from a manual paper process to the digital domain. This is what we define as digital transformation and smart contracts have the potential to raise the bar on the scope of what this term encompasses. Smart contracts and the blockchain database are often referred to as being disruptive technologies positioned to replace today’s business models with faster, cheaper and better solutions. TechVision Research views this technology as providing a basic underlying transactional database platform where security is a primary component integrated at the record level. The technology, as demonstrated by Bitcoin, Ethereum, Hyperledger and others is sufficiently secure to allow parties to enter into an agreement and, in some situations, without revealing their identity. It is from establishing trust through programmatic means is the true value proposition and radical difference that allows the technologies to offer a new way of envisioning business models and the applications that support them. TechVision Research believes that this technology will be deployed as industrial strength solutions over the next two to five years in areas such as: · Royalty distribution and like automated asset transfers (e.g. music, video and

publications), · Asset tracking (e.g. products within a supply chain and transportation), · Provenance and history (e.g. personal records from birth and title search), · Pay as you go instruments (e.g. variable insurance calculations based on usage), and · Exchanges in excess capacity (e.g. trading

surplus photovoltaic energy). TechVision Research believes that institutional changes are more than ten years away in areas such as: · Replacing SWIFT in banking and like

foundational systems, · Complete end-to-end supply chain and

customer relationship management systems, and

· Electronic medical records (e.g. tracking and access).

Recommendations We’ll start by looking at steps most organizations can take today to be prepared for the advent of blockchain-based smart contract applications and infrastructure services.

Within the next five to ten years these

foundational technologies will

become paramount and fundamental to

remaining competitive.




Organizations can move forward today and over the next year or so by taking the first step in recognizing this technology is worth pursuing now. It will take time and effort to understand what is being offered and how to incorporate into serving current and new product and service offerings. Within the next five to ten years these foundational technologies will become paramount and fundamental to remaining competitive. This is due to their inherent utility in eliminating or reducing dependencies on antiquated and inefficient processes, preventing fraud, reducing overhead and revenue loss due to system downtime. Begin your pursuit by getting your legal team on board, educated and involved now. Any new system feature deployed to augment and facilitate written legal agreements through self-executing code and enforcing the outcome will need to be endorsed, vetted and ultimately negotiated by in-house legal counsel or outside representation. Your legal team will be responsible for understanding the complete set of potential outcomes that may occur from the execution of each smart contract. Now is a good time to begin to form a “Coded Contract Review Board” to define and establish what will be required to gain approval before a smart contract may be placed in productive use. From the technical side of the organization appoint an internal sponsor and promote their role in the organization. The sponsor evangelizes the opportunity associated with smart contracts and blockchain and is responsible for ensuring support from the executive team. The higher in the organization and greater credibility this leader has the better, but someone needs to drive this, and be provided the tools, team, and funding necessary to gain traction. Perform a detailed examination of your current business model(s) supporting processing and operational needs and identify all areas of risk and exposure by focusing on real problems and limitations. These areas may include exposure to internal and external fraudulent tampering, error prone inefficient processes, and losses due to unavailable or poorly performing systems. Document detailed and exhaustive use cases for new and upcoming opportunities. Consider if these use cases benefit from the deployment on a private, consortium or a public blockchain ecosystem or better satisfied by the application of a different technology. Compare and evaluate competitive technology offerings, such as message driven programming found in micro-services, for transforming your business. Consider smart contracts as a complementary technology to micro-services based solutions. Estimate the potentials for total cost of ownership savings by hard coding contractually agreed to terms set in current and planned written agreements. Talk to your partners about their beliefs and identify common paths towards future business approaches, dependencies and need for tighter integration of services such as found in supply chain management and like partnership arrangements. Lastly monitor the premier platform offerings from Ethereum, Microsoft, IBM, Amazon and




others as they evolve and be cognizant of best practices as they become known, especially those that lend themselves into becoming de facto standards. The development of ecosystems at scale by these leading vendors, combined with the emergence of the next generation of innovation from a mix of large and small organizations will provide the foundation for enterprise-ready smart contract platforms.

About TechVision

World-class research requires world-class consulting analysts and our team is just that. Gaining value from research also means having access to research. All TechVision Research licenses are enterprise licenses; this means everyone that needs access to content can have it. We know major technology initiatives involve many different skill sets across an organization and limiting content to a few can compromise the effectiveness of the team and the success of the initiative. Our research leverages our team’s in-depth knowledge as well as their real-world consulting experience. We combine great analyst skills with real world client experiences to provide a deep and balanced perspective. TechVision Consulting builds off our research with specific projects to help organizations better understand, architect, select, build, and deploy infrastructure technologies. Our well-rounded experience and strong analytical skills help us separate the hype from the reality. This provides organizations with a deeper understanding of the full scope of vendor capabilities, product life cycles, and a basis for making more informed decisions. We also support vendors when they carry out a product and strategy review and assessment, a requirement analysis, a target market assessment, a technology trend analysis, a go-to-market plan assessment, or a gap analysis. TechVision Updates will provide regular updates on the latest developments with respect to the issues addressed in this report.




About the Authors

Gary Rowe is a seasoned technology analyst, consultant, advisor, executive and entrepreneur. Mr. Rowe helped architect, build and sell two companies and has been on the forefront the standardization and business application of core infrastructure technologies over the past 35 years. Core areas of focus include

identity and access management, blockchain, Internet of Things, cloud computing, security/risk management, privacy, innovation, new IT/business models and organizational strategies. He was President of Burton Group from 1999 to 2010, the leading technology infrastructure research and consulting firm. Mr. Rowe grew Burton to over $30+ million in revenue on a self-funded basis, sold Burton to Gartner in 2010 and supported the acquisition as Burton President at Gartner.

John Myracle is a technical specialist/architect with a broad technology and diverse business background. Mr. Myracle combines knowledge of intellectual property with product conceptualization development and delivery. Experience includes communicating business, financial, and technical objectives between legal, sales, marketing, and development teams for banking, communications,

optical transport network management, security, mobile, and medical device applications. Patent experience includes drafting 150+ applications and IP portfolio monetization. Mr. Myracle is a seasoned system/solution architect, product manager, and senior consultant with 35+ years’ experience at Booz-Allen & Hamilton, IBM, and Southwestern Bell Corporation. Core focus areas range from cloud computing and IoT to European Union GDPR compliance and smart contracts on blockchain.


smart contracts and blockchain · 2017. 10. 11. · smart contracts and blockchain abstract this is...

Documents