Initial Publication Date: 21 December 2018

Abstract

Blockchain is one of the more heavily-hyped technologies to emerge in decades; right up there with Artificial Intelligence. The good news is that this high level of attention has resulted in massive investment and rapid growth in this space; the bad news is that it has also resulted in confusion and unrealistic expectations. But what does this mean for large enterprises? How much should be invested in these nascent technologies? When will it be ready for production use at scale? How should an organization prepare for a future wave of blockchain-enabled applications? These are the types of questions we’ll look to answer, or at least address, in this report.

TechVision believes that blockchain technology shows real potential as a core enabling technology, in particular when transactions leave the corporate boundaries. Today, significant wait time, processing power and manual efforts are required to verify, post and reconcile transactions and blockchain has characteristics that can streamline business processes and eliminate chokepoints in a secure and auditable way.

This report focuses on describing what blockchain is and what it isn’t, the various blockchain categories, key vendor offerings, notable industry initiatives and a series of recommendations for our enterprise clients.  In short, we’ll provide a level-set to help our clients develop strategies around and determine appropriate investment levels in blockchain and related technologies.

Authors:

Gary Zimmerman Principal Consulting Analyst [email protected]

Gary Rowe CEO, Principal Consulting Analyst [email protected]

 

Executive Summary

The goal of this report is to provide information and insights to help our clients develop a blockchain strategy. Developing a strategy in the blockchain area can be a challenge because, on one hand there is tremendous disruptive potential, but on the other hand we are very early in the evolution of both the technology and the supporting ecosystems. We’ll start with, an assessment of the current state of blockchain and where we see it evolving over the next few years. We’ll also define emerging patterns as enterprises move from early experimentation to developing scalable services that can stand up to the rigors of business. And we’ll conclude by making some pragmatic recommendations and provide our perspective on how and when enterprises should invest in this technology and new business models.

We’ll start with the premise that blockchain is immature; promising, but immature. Blockchain or distributed ledger technology (DLT) has been touted as the next disruptive force, with an impact at the level of the World Wide Web (Web). The Web created an Internet of information and blockchain has the potential to create an Internet of value exchange. While we believe that there is tremendous potential (as do many technology and industry experts), it is wise to take a more balanced and pragmatic view. This is the foundation of this report.

Many of the developments over the past three years have accelerated the path towards real-world enterprise use cases. We have gone from raw concepts to code, consortiums and POCs in that short period of time. For example, the following efforts represents the pace of activities in this space:

• Ethereum, the first multipurpose blockchain launched in July 2015
• Hyperledger, the first general enterprise consortium announced in February 2016
• R3Corda, the first purpose built financial blockchain was open-sourced in November 2016
• Enterprise Ethereum Alliance, created to establish standards and interoperability across the Ethereum network began in March 2017
• Sovrin, built to support self-sovereign identity on the blockchain launched its network in July 2017
• Amazon Managed Blockchain and Quantum Ledger were announced in November 2018
• Microsoft announced a partnership with MasterCard to provide distributed, blockchain-enabled identity services in December 2018.

Thousands of startups and cryptocurrencies have entered and exited the market since Bitcoin first launched ten years ago. The market is starting to settle down, but do not expect a robust technology stack for a few more years as the surviving platforms mature and standards are defined and adopted. We have a multitude of options today and those options will become more narrowly defined over the next 2-3 years. This is why we advise our clients to experiment and become better educated but keep your options open and your architecture flexible over the next few years.

Initially, developers started building full stack solutions using the Bitcoin model, where the application, network, and protocol are delivered as an integrated package for a single purpose. The early model of developing a full stack for every use case has introduced complexity and silos of proprietary solutions that inhibits wide-spread adoption as a business solution.

The market began to realize that in order to gain widespread adoption, the blockchain needed to be developed as an infrastructure separate and distinct from the applications that use it. That has shifted investment focus to the infrastructure layers of the solution set. There has also been a rapid proliferation of consortiums that are focused on creating the standardized and stable infrastructure necessary to run business applications. Organizations should initially focus on understanding the basics of the blockchain infrastructure at the protocol, network and even funding levels. This is a “safe” starting point to build a flexible foundation for future blockchain use-cases. A brief description of each category follows, and more detailed explanations are covered within the body of the report:

• Protocol – Every blockchain has a unique set of program code that is executed on the individual network nodes. That code defines the proper transaction data type/structure, cryptography for proving ownership and maintaining security, the blockchain data structure for ordering transaction data, the validation routines and consensus algorithm for confirming the changes, and the network logic for message passing and node connection. These protocols are generally developed by an individual organization and then contributed as open source to a foundation or consortium that assumes responsibility for governance, standards, and interoperability going forward.
• Network – A blockchain is typically managed by a peer-to-peer network that adheres to a common protocol for both inter-node communication and the validation of new blocks. Once recorded, the data in any given block cannot be altered retroactively without alteration of all subsequent blocks, which requires consensus of the network majority. The network nodes maintain the database, and for some implementations, generate the funding (mining) that funds the operation.
• Funding – Includes a variety of mechanisms to fund the development and operation of the network. This includes in-kind contribution of funding by network members or the development of “utility” tokens that can be used within the network to accomplish a business task.

For example, networks like Corda, Hyperledger Fabric, Ethereum, Ripple, and Sovrin have emerged to complement the early Bitcoin Blockchain network. These infrastructure platforms/ecosystems are being supported by enterprises as they build their early blockchain applications.

For enterprises, business value is realized at the application layer, but to achieve this there needs to be a dependable and stable infrastructure. Enterprises are also engaging with blockchain in a low friction manner by experimenting with Blockchain as a Service (BaaS) platforms to insulate the development of applications from the turmoil in the infrastructure. IBM, Amazon, HP, Microsoft, Oracle and several other vendors offer BaaS platforms.

Some of the early one-off blockchain-based experiments we wrote about in our reports over the past few years are evolving into consistent patterns. These patterns help to frame the types of blockchain implementations and expected outcomes that your organization requires. By mapping your requirements against these patterns can help you make the right architectural and early vendor choices. Some of the emerging patterns to consider in the development of your blockchain strategy and early use cases are:

• Consensus patterns –A major difference between public and permissioned blockchain networks is in the area of trust. Having little or no knowledge as to the participants or verifiers in a network requires additional work to validate transactions. In a “trust-less” environment, every node has to verify every transaction and every block. Permissioned networks operate on the basis of “trust but verify” and as such, use a lighter-weight consensus mechanism. These lighter weight mechanisms can often operate faster while still providing strong security given that the participants are known. We describe the differences between these consensus patterns later in this report.
  • Network patterns – When Bitcoin Blockchain first entered the picture, there was only one network model; anyone can see the transaction activity posted to the blockchain (open) and anyone can set up a network node and compete for the right to update the blockchain (permissionless). Since that time, other network models have become available, mostly in response to enterprise requirements. Those patterns are closed systems (private or consortia-based access) and permissioned update (where only prequalified and trusted nodes can update the chain) patterns.
  • Use patterns – While use cases initially appeared unique, it became clear over time that they can be generalized and grouped into similar solution sets. We have initially identified the following patterns:
    • Tokenization, including asset ownership tracking and provenance, chain of custody, and fractional ownership uses
    • Identity, self-sovereign or decentralized identity uses
    • Supply chain
    • Financial settlement
    • Reconciliation between legal entities within a global enterprise

As you are developing your enterprise blockchain strategy, consider how these patterns support your current and future state objectives. For instance, if you are developing a supply-chain solution between trusted trading partners (i.e. bound by legal contracts and proven relationships) you might choose a more closed blockchain model and a lighter weight consensus protocol to speed throughput. However, if your solution requires interaction with initially unknown entities or uses transitory relationships, an open network with a more robust consensus mechanism may be more suitable.

We have also noted that early efforts were focused more on the capabilities of the technology rather than the underlying need for a solution. Enterprises that are looking to accomplish one or more of the following objectives may be candidates for using blockchain-based solutions:

• Reduce the need for an assumption of trust between stakeholders – trust is inherent in the data itself because all transactions are bound by the validity rules and confirmed through the consensus algorithm.
• Build a secure value transfer system – data contained within the ledger and the network is encrypted and hashed in ways that protect the integrity of the data.
• Streamline business processes across multiple entities – the need for independent transaction validation and reconciliation is eliminated because every stakeholder is using the ledger as the source of truth.
• Increase record transparency and ease of auditability – All transactions for a given asset are captured from the point the asset is first added to the ledger (tokenized). The transactions cannot be modified once written and ownership of that asset (or fractions thereof) can be tied to a unique identity.

This report further describes the current state of blockchain as an infrastructure technology, the emerging patterns that are useful to enterprises and ends with food-for-thought and recommendations to consider as you develop your approach to this promising technology.

Blockchain basics

We’ll start with a brief summary of basic blockchain concepts and categories as a foundation for building an enterprise blockchain strategy and considering application early use cases. There is a lot of information and mis-information about blockchain and we want to start here with a simple foundation.

What is a blockchain?

Industry experts have used the terms Bitcoin, blockchain, cybercurrency, and distributed ledger technology almost interchangeably and that has caused a lot of confusion in the market. So, let’s begin by clarifying the terms, which we’ll describe in greater detail later on in the report. Bitcoin is a particular type of cryptocurrency and as the early innovator they helped to define many of these terms that continue to be used throughout the industry.  But Bitcoin has now been joined by hundreds of other cryptocurrencies.  A cryptocurrency is a token that is created and tracked through the recording of various transactions in a distributed ledger.  We go into depth on distributed ledgers in this report, but in short, a distributed ledger is a database that is created and maintained over a set of network nodes that are not under a single entity’s control. Blockchain is a specific type of distributed ledger technology.  For the remainder of this report we will use the term blockchain as representative of general distributed ledger technology as it is the most mature and adopted form of distributed ledger as of this writing.

Blockchain is simply a secure, shared database. In its purest form, everyone connected to a blockchain network has access to the same set of information. Think of blockchain as a permanent, replicated, distributed, yet secure ledger where all parties have access to the same information. Much like an accounting ledger, blockchain is a platform for recording transactions, but it intrinsically makes this shared data available. For more background information on blockchain, TechVision has produced a foundational report titled “Blockchain 101 – An Enterprise Level Set” that explains the basic concepts of the technology and supporting infrastructure.

Blockchain technology is often described as the backbone for a transaction layer for the Internet; a foundation for the Internet of Value. But that vision and foundation is very early in the adoption cycle and there is so much to be discovered – and there is no guarantee that blockchain will ever fully realize this goal. It is hard to imagine that it can ever live up to the hype. For example

More than 80,000 projects claiming to utilize blockchain technology have launched worldwide since Bitcoin’s underlying technology became the hottest buzzword in business. Of those projects, only a mere eight percent are still active, and the average lifespan of any given project is roughly 1.22 years.  – The China Academy of Information and Communications Technology (CAICT)

In a recent study, CAICT found that 98% of blockchain projects have failed. While that seems alarming for an enterprise project team, it is not so odd for the startup world. Many of those failures were start-ups focused on new versions of Cryptocurrency and initial coin offerings (ICO). Some were out-and-out frauds and others were experiments that didn’t deliver the value envisioned. As blockchain exploded from its cryptocurrency roots, it quickly took on new life, as proponents rushed to figure out what else it was good for. That’s drawn criticism that blockchain is a “technology in search of a problem.” The reality is that most of the underlying technology stack is immature and untested. Blockchain is a startup, but one that is well funded with a great engineering team.

For example, today’s blockchain infrastructure is currently comprised of public blockchains, enterprise blockchains and hybrid models that, for example, build on public blockchain infrastructure or provide technology for permissioned networks. In this context, it is important to note that, while a public blockchain has already produced a real-world application of the technology in Bitcoin, the other two approaches, while they may have a few recently minted production instances, are still being tested and it may take years of research and refinement until we see broader market adoption and production solutions.

Five key components of a blockchain

Blockchain has a multitude of moving parts that, if not understood and properly architected, can be barriers to enterprise adoption. We’ll now look at five critical elements of blockchain that, when combined, provide tremendous promise for individuals and enterprises. For starters, blockchain is a technically complex system based on math, algorithms, and encryption. There aren’t many IT professionals that understand the environment let alone are comfortable with it.  Yet, these complexities are what make the technology powerful. Every blockchain or distributed ledger has these basic attributes:

1. Cryptography – The use of a variety of cryptographic techniques including cryptographic one-way hash functions, Merkle trees and public key infrastructure (private-public key pairs) to support confidentiality, non-repudiation, time stamps and management of private keys.
2. P2P Network – A network that supports discovery and data sharing in a peer-to-peer fashion to facilitate redundancy, provide user controls, mitigate risk (data isn’t in a single place) and eliminate central points of failure.
3. Consensus mechanism – An algorithm that determines the ordering and commitment of transactions in an adversarial environment (i.e., assuming not every participant is honest). Consensus needs to be achieved before writing a transaction on the blockchain.
4. Ledger – A complete list of transactions bundled together in cryptographically linked blocks or graphs available throughout the network.
5. Validity rules – Common set of rules of the network (i.e., what transactions are considered valid, how the ledger gets updated, what conditions are required for execution, etc.)

The above components, when combined, provide a strong set of distributed capabilities that are difficult to achieve using most current architectures and frameworks.

Why use a blockchain?

This is a fundamental question every enterprise should ask. There are microservices, distributed databases, peer-to-peer applications, and collaboration technologies that may be able to solve similar problems today. While use cases will be evaluated on a case-by-case basis, there are core design principles associated with blockchain that might warrant additional consideration. Enterprises that are looking to accomplish one or more of the following objectives may be candidates for using blockchain-based solutions:

• Reduce the need for an assumption of trust between stakeholders – trust is inherent in the data itself because all transactions are bound by the validity rules and confirmed through the consensus algorithm.
• Build a secure value transfer system – data contained within the ledger and the network is encrypted and hashed in ways that protect the integrity of the data.
• Streamline business processes across multiple entities – the need for independent transaction validation and reconciliation is eliminated because every stakeholder is using the ledger as the source of truth.
• Increase record transparency and ease of auditability – All transactions for a given asset are captured from the point the asset is first added to the ledger (tokenized). The transactions cannot be modified once written and ownership of that asset (or fractions thereof) can be tied to a unique identity.

Inherent blockchain characteristics

Blockchains can help achieve the above objectives given their innate set of characteristics including:

Immutability – No participant can modify a transaction after it has been recorded on the ledger. If an error occurs, a new transaction must be used to reverse the error. At that point, both transactions will be visible on the ledger. The first transaction, considered an error, will always be visible once it is recorded.

Resiliency – One of the core aspects of a blockchain is that it is a distributed ledger, meaning that the database is maintained and held by all nodes in the network. No central authority holds or updates the ledger, rather each node independently constructs its own record by processing every block (group of transactions), deciding if it is valid, then voting via the consensus mechanism on their conclusions. Once a change in the record is agreed, each node updates its own ledger. The key here is that there are many places where a transaction is recorded so, if for some reason a node goes down or is attacked, there are others that keep the data accurate and available.

Consensus – For a transaction to be accepted and recorded on the blockchain, all the participants must agree to follow the same rules. This is consensus. If a transaction violates one of the rules the network agreed on, the transaction will be considered invalid. The consensus allows each participant to trust the network, because they know each transaction will follow rules they ratified when the network launched.

Finality – In a blockchain network, there is only one source of truth. There is only one ledger for the whole network. To know who owns what, or to study a particular transaction, there is only one place to go.

Security – By the fact that the data stored in the blockchain is shared among many computers hence eliminating the central point, this lessens the risk that data can be compromised. Additionally, blockchain uses the encryption technology to secure data. Blocks are secured through hashing and the transactions are secured through the use of PKI (private and public keys).

Provenance – Participants know where the assets came from and how its ownership has changed over time. Each asset’s (whatever it is, tangible, intangible, digital) provenance must be traceable.

Blockchain Enabled Technologies: Smart Contracts and Zero Knowledge Proofs

Blockchain can effectively support other related technologies and business models. Two areas that fall into this context are smart contracts and zero knowledge proofs; both can exist without distributed ledgers, but we believe that they can be more effective by leveraging blockchain functionality. We’ll now take a brief look at each of these areas:

Smart Contracts

As we described in detail in the TechVision Research report “Smart Contracts and Blockchain”, a smart contract is simply computer code running on top of a blockchain containing a set of rules under which the parties to that smart contract agree to interact with each other. If and when the pre-defined rules are met, the agreement is automatically enforced. Smart contract code facilitates, verifies, and enforces the negotiation or performance of an agreement or transaction. It is the simplest form of decentralized automation.

It is a mechanism involving digital assets and two or more parties, where some or all of the parties deposit assets into the smart contract and the assets automatically get redistributed among those parties according to a formula based on certain data, which is not known at the time of contract initiation.

The potential of smart contracts is clear given the following strengths:

Accuracy – All of the terms and conditions are recorded explicitly within the contract. Like all programs, the inputs, process steps, and outputs are defined and tested for accuracy before execution.

Minimal disputes – The terms and conditions of a smart contract are visible and are accessible to all the parties, which minimizes dispute.

Speed – As these contracts are software code, the speed of executing transactions is much quicker as compared to real-world transactions, where triggers, validation, recording, and reconciliation between the parties happen independently and often with manual intervention.

Auditability – Smart Contracts record the essential details in every transaction, meaning that your details that are recorded in the contract and get stored permanently.

Trust – Smart Contract is bound by the same inherent characteristics as any blockchain transaction. When invoked, it executes as recorded without bias or manipulation.

But blockchain supported smart contracts are not a panacea; they have some challenges to considered in architecting solutions including:

Correctability – As a blockchain element, smart contracts can benefit from the immutability of the blockchain. While this immutability is a benefit in security and auditability, it can add risk and expense if changes are needed. Smart contracts are developed by humans and humans make mistakes. Even the slightest error in code can turn out to be expensive and time-consuming to correct once the smart contract is deployed and executing.

Good Faith – In US contract law, the implied “covenant of good faith and fair dealing” is a general presumption that the parties to a contract will deal with each other honestly, fairly, and in good faith, so as to not destroy the right of the other party or parties to receive the benefits of the contract. But, with Smart Contracts, it is difficult to ensure that the terms are met in accordance with what was implied, especially when dealing with tokenized real assets.

For example, let’s say you use cryptocurrency to buy a fractional share of an office building.  A smart contract can confirm that you have the right amount of currency and that the seller has enough shares available for purchase before executing the contract, but the contract code cannot guarantee those shares represent a real building. In the non-digital world, if you discover this type of fraud, you can take the case to the court to enforce the good faith covenants, but with smart contracts, the options are less clear at present.

Handling vague terms and conditions – Real-world contracts often include vague terms and conditions that require judgment and are not binary. For instance, “Force Majeure” states that parties are not liable for things outside human control. A smart contract is an efficient way to execute transactions where the parties, the assets, and the terms are definitive and instantiated in the network, but when it has to rely on information or terms that are subject to interpretation and reside outside of the network, smart contracts may not be the best choice.

Dispute Settlement – With smart contracts, the code and its results are immutable.  That means any version of the code executes as invoked and transfers value permanently. To fix a bug, a new version of the code is instantiated and transactions going forward are executed under that version.  Old transactions validated under the old code remain valid. This gives rise to one of the enterprise requirements, safeguards, we note in the next section.

When looking to deploy smart contracts as part of your blockchain strategy, make sure you have the right people engaged so that you can take advantage of its strengths and mitigate its disadvantages. You will require:

• People that know how to properly architect, code and test these contracts,
• Involved parties that need to initially agree that the terms and conditions meet the transaction objectives, and
• Legal experts that ensure the digital contract is legal and enforceable.

Zero-Knowledge Proofs

Zero-Knowledge Proofs (ZKP) enable the transfer of assets across a distributed, peer-to-peer blockchain network with complete privacy. In regular blockchain transactions, when an asset is sent from one party to another, the details of that transaction are visible to every other party in the network. By contrast, in a zero-knowledge transaction, the others only know that a valid transaction has taken place, but nothing about the sender, recipient, asset class and quantity.

New developments such as ZKP are working to solve the enterprise requirements for confidentiality and inefficiency issues on a public blockchain. Zero-Knowledge Proofs will be of significant benefit to organizations struggling to achieve GDPR compliance. ZKP can also mitigate risk by maintaining less Personally Identifiable Information (PII) that could be compromised the event of a breech. But the technology is new and brings its own set of problems, such as the computationally intensive nature of proof establishment and the complex and resource intensive “trusted setup” required to establish cryptographic keys need for the transactions.

Beyond the challenges in implementing the technology, there are other issues to consider including:

• The relative newness of the concept lacking production-level use cases at scale. We understand security techniques like TLS and PKI because they have been used and proven repeatedly in business. This is not yet the case for ZKP.
• It’s not clear that a ZKP proof of a transaction meets audit or regulatory standards due to lack of transparency. This, of course, depends on the use case and its requirements; the ability to prove you are of legal age to drink is different than your ability to prove a financial transaction isn’t part of a money laundering scheme.

When looking at the use of ZKP, enterprises need to weigh the security and privacy advantages of ZKP against the disadvantages and liabilities it may create.

Each of these new capabilities will require extensive infrastructure testing and the development of a support structure (testing, release planning, secure code review procedures, certification, etc.) before these are production “hardened” for all enterprises to use with full confidence.  ZKP will also be dependent on the development of ecosystems to provide secure key management and support for reconciling the claims to be validated.

Enterprise Requirements

When looking at the core capabilities blockchain offers, there are gaps that need to be addressed before blockchain is adopted as a mainstream technology by enterprises. They are:

Performance – Blockchain systems for the enterprise need to be capable of having a high throughput in terms of number of transactions per second (TPS). There needs to be substantial improvement over Bitcoin and Ethereum (currently can only process approximately 7 – 30 TPS at most depending on chain) before being viable for most production use cases.

Speed – Transactions need to be confirmed and validated in a short time window (preferably milliseconds), compared to Bitcoin and Ethereum, where transactions can take on average 10 minutes and 12 seconds, respectively, to confirm and eventually settle.

Scalability – System needs to be able to scale immediately as more nodes join the network (latency issues), more transactions are performed (increasing processing power and memory usage required), and the transaction history grows (increasing storage requirements).

Governance – Enterprises need a pre-defined, codified decision-making process involving known, vetted participants to provide a greater level of trust and accountability than is available via public blockchains where a social contract exists, and rule changes are achieved through consensus among pseudononymous users (miners).

Privacy/confidentiality – Transactions or transaction data needs to have stronger privacy when required by the specific use case; in public blockchains, all transactions are visible to every participant by design.

Compliance – Participants need to comply with applicable regulatory requirements and the legal framework that they are subject to. This also applies to the network itself and the transactions that take place in the system. This can be a challenge in that many legal frameworks haven’t caught up with peer-to-peer technologies.

Safeguards – Need to manually intervene in case an unexpected issue happens (e.g., critical bug). Moreover, there needs to be a means to prevent anonymous actors with sufficient financial power to initiate a 51% attack against a public blockchain network and reverse transaction history.

Hyperledger, R3, the Enterprise Ethereum Alliance are examples of consortia that have been formed to address these enterprise requirements and accelerate adoption. Moving from some of these early POCs to enterprise-level production environments that are compliant, scalable and secure is a major chasm to be crossed before blockchain can live up to its tremendous potential. We’ll now look at how these consortiums are addressing these and other challenges.

Consortia

Enterprise Ethereum Alliance

The Enterprise Ethereum Alliance (EEA) seeks to augment Ethereum, enabling it to serve as an enterprise-grade technology, with research and development focused on privacy, confidentiality, scalability, and security. EEA will also investigate hybrid architectures that span both permissioned and public Ethereum networks.

EEA collectively develops industry standards and facilitates open source collaboration with its member base and is open to any members of the Ethereum community who wish to participate. This collaborative framework will enable the mass adoption at a depth and breadth otherwise unachievable in individual corporate silos and provide insight to the future of scalability, privacy and confidentiality of the public Ethereum permissionless network.

The Hyperledger Project (HLP)

Hyperledger is an open source collaborative effort created to advance cross-industry blockchain technologies. It is a global collaboration, hosted by The Linux Foundation, including leaders in finance, banking, IoT, supply chain, manufacturing and technology. This is the fastest growing project in the history of the Linux Foundation.

The mission of HLP is to:

• Create an enterprise grade, open source distributed ledger framework and code base, upon which users can build and run robust, industry-specific applications, platforms and hardware systems to support business transactions.
• Create an open source, technical community to benefit the ecosystem of HLP solution providers and users, focused on blockchain and shared ledger use cases that will work across a variety of industry solutions;
• Promote participation of leading members of the ecosystem, including developers, service and solution providers and end users; and
• Host the infrastructure for HLP, establishing a neutral home for community infrastructure, meetings, events and collaborative discussions and providing structure around the business and technical governance of HLP.

R3

R3 is an enterprise software firm which focuses on distributed database technology. It leads a consortium of over 200 members, such as financial institutions, banks, trade associations and fintech companies. The main aim of R3’s consortium is to develop Corda – an open-source distributed ledger platform, designed to work within finance to operate complex transactions and restrict access to transaction data. Corda has also garnered the interest of healthcare institutions, the insurance industry, and governments. Although R3 was inspired by blockchain, Corda is not designed to be a traditional blockchain platform. Corda does not have its own cryptocurrency, can only share data with the required participants and offers interoperable applications for finance and commerce (called CorDapps). Corda is gradually being implemented into the financial industry, being used for the transactions of Credit Suisse and IGN, while continuing to gather more and more partners for R3.

R3 recently announced Corda Enterprise, a commercial version of its open source platform for enterprise usage. Enterprise is meant to be controlled by the enterprise itself and acts as the glue between internal operations and the Corda distributed ledger.

Open versus closed blockchains

There are different categories of blockchains/distributed ledgers. The Bitcoin Blockchain is an open, publicly accessible, permissionless network. This means that anyone can participate in both accessing the network and verifying transactions. This model doesn’t work for high value applications in banking for example and led to implementations of distributed ledgers that limited access to trusted parties for either accessing or providing validation of transactions before committing them to the immutable ledger.

To various types of distributed ledgers address several of the issues and enterprise requirements described earlier such as speed, governance, compliance, and safeguards. This has resulted in most of the consortia having adopted a permissioned form of a network where the validating nodes are known and approved.  The differences between the various blockchain networks are outlined in the table below.

			Read	Write	Commit	Example
Blockchain Types	Open	Public permissionless	Open to anyone	Anyone	Anyone	Bitcoin, Ethereum
		Public permissioned	Open to anyone	Authorized participants	All or a subset of authorized participants	Ripple, Sovrin
	Closed	Consortium permissioned	Restricted to an authorized set of participants	Authorized participants	All or a subset of authorized participants	Corda, Hyperledger Fabric
		Private permissioned	Fully private or restricted to a limited set of nodes	Network operator only	Network Operator only	Multichain, Stack (Blockstack)

Table 1 – Blockchain types

The table also includes a private chain option for completeness but is not the focus of the consortia addressing enterprise concerns. We’ll now dig deeper into the types of consensus patterns and the applicability of each.

Consensus patterns

A major difference between public and permissioned blockchain networks is in the area of trust. Having little or no knowledge as to the participants or verifiers in a network requires additional work to validate transactions. In a “trust-less” environment, every node has to verify every transaction and every block.  Permissioned networks operate on the basis of “trust but verify” and as such, use a lighter-weight consensus mechanism as we describe below.   These lighter weight mechanisms can often operate faster while still providing strong security given that the participants are known.

Consensus may be implemented in different ways such as lottery-based algorithms including Proof of Elapsed Time (PoET) and Proof of Work (PoW) or through the use of voting-based methods including Redundant Byzantine Fault Tolerance (RBFT), Crash Fault Tolerance (CFT) and Raft.  Proof of Work is used within the Bitcoin ecosystem and is very compute intensive which leads to delays in completing transactions.

Each of these approaches target different network requirements and fault tolerance models.

The lottery-based algorithms are advantageous in that they can scale to a large number of nodes since the winner of the lottery proposes a block and transmits it to the rest of the network for validation. On the other hand, these algorithms may lead to forking when two “winners” propose a block. Each fork must be resolved, which results in a longer time to finality.

The voting-based algorithms are advantageous in that they provide low-latency finality. When a majority of nodes validates a transaction or block, consensus exists, and finality occurs. Because voting-based algorithms typically require nodes to transfer messages to each of the other nodes on the network, the more nodes that exist on the network, the more time it takes to reach consensus. This results in a trade-off between scalability and speed.

As shown in the table below, permissioned blockchains prefer voting-based consensus and it has a drastic impact on performance, both throughput and latency.

	Name	Type	Throughput	Latency	Consensus
Enterprise Blockchains	Hyperledger Fabric	Permissioned DLT	3.5k -110k TPS	<1 second	CFT or BFT
	R3 Corda	DLT	15-1700 TPS	Not published	BFT or Raft
	Hedera Hashgraph	DLT – Directed Acyclic Graph (DAG)	50k+ TPS	<10 seconds	Asynchronous BFT (Gossip)
Public Blockchains	Bitcoin	Bitcoin Blockchain	7-10 TPS	10 minutes	PoW
	Ethereum	Ethereum Blockchain	15-20 TPS	2-6 minutes	PoW
	Ripple	XRP Ledger	1000-2000 TPS	2-5 seconds	BFT

Table 2 – Comparison of major blockchain performance

Major Blockchains

While there are thousands of blockchain startups, enterprises should be looking at the more stable networks to gain experience with the applicability of and use cases for blockchain. It may be hard to determine this on fragile blockchain ecosystems. The blockchains highlighted in this section have a tested infrastructure, have a base of enterprises and/or individuals on their networks and are providing operational support, investments resulting in products and services being built on top of their respective platforms.

Bitcoin

The original blockchain was developed to support the Bitcoin cryptocurrency. The central problem in electronic cash of any kind is Double Spend. Because pure electronic money is just data, nothing stops a currency holder from trying to spend it twice. Blockchain solves the Double Spend problem without a digital reserve fund or any central authority. This was a great use case for blockchain in general as it is a very difficult problem to solve.

The Bitcoin Blockchain monitors and verifies Bitcoin transactions by calling upon a decentralized network of volunteer-run nodes to, in effect, vote on the order in which transactions occur. The network’s algorithm ensures that each transaction is unique.

One of the Bitcoin blockchain’s most innovative aspects is how it incentivizes nodes to participate in the intensive consensus-building process by randomly rewarding one node with a fixed bounty every time it wins the right to settle and commit a new block to the chain. This accumulation of Bitcoin in exchange for participation is called “mining” and is how new currency is added to the total system up to the Bitcoin limit.

Bitcoin is implemented with a simple scripting language that is tuned to program the conditions of the release of the underlying asset (most often a Bitcoin). While it suits the simple transaction, it limits the utility for more complex relationships. This limitation is an area of focus for Ethereum, the next distributed ledger infrastructure we’ll describe.

Ethereum

Ethereum is a public, open-source and block chain oriented distributed computing protocol that features smart contracts (scripting) functionality. The protocol has provided a decentralized virtual machine called the Ethereum Virtual Machine (EVM), which carried out Turning-complete[1] scripts by using a global network of public nodes and the token called ether, also referred to as gas. Gas is used for preventing the spam on networks and allocating the resources in proportion to the incentive provided by the request. Ethereum is shared software that is used by all; however, is considered tamperproof. Ethereum is also used as a protocol for decentralized applications, smart contracts and decentralized autonomous organizations. As sophisticated as it is, Ethereum is implemented as a public blockchain.

Ripple Consensus Network

The Ripple Transaction Protocol (RTXP), issued in 2012, has been developed upon an open-source distributed consensus ledger, Internet protocol, and native currency termed as XRP (ripples). It was developed as a purpose-built open blockchain to facilitate global payments. Ripple enables fast, safe and almost free global financial transactions of any scale without any chargeback. The protocol is being embraced in support of tokens presenting cryptocurrency, fiat currency, commodity and any other value units like mobile minutes, frequent flier miles etc. Ripple is the third-biggest cryptocurrency in terms of market capitalization, after Bitcoin and Ether.

Hyperledger

Though technically not a single unique blockchain, Hyperledger is the open source blockchain platform, began in 2015 by the Linux Foundation, in an effort to support the blockchain-based distributed ledgers. They describe themselves as “…an open source collaborative effort created to advance cross-industry blockchain technologies”. It is a global collaboration, hosted by The Linux Foundation, including leaders in finance, banking, Internet of Things, supply chains, manufacturing and technology”.

The various Hyperledger projects focus on ledgers developed to support international business transactions, with the objective of improving performance and reliability aspects of today’s established blockchains. The overall project emphasizes collaborative efforts for defining open standards and protocols. Hyperledger features a modular framework backed by various components, including a range of blockchains having their own storage and consensus models, and the services for access control, contracts and identity.  These components can be flexibly applied by any business network looking to solve a common business problem. Hyperledger supports permissioned ledgers that can be public or private.

R3’s Corda

Corda by the organization called R3 is the distributed ledger protocol for recording, supervising and synchronizing financial agreements among regulated financial institutions. The goal is to capture the advantages of blockchain systems while eliminating the design choices that are unsuitable for banking scenarios. Corda’s design came up as a result of heavy analysis and prototyping with team members that are primarily banks and insurance companies. It is now an open sourced protocol to help gain broader support. Corda is a consortium ledger purpose-built for the financial industry.

We have also included two newer entries in this list due given some of their unique capabilities and early enterprise engagement and support.

Sovrin

Kim Cameron, Chief Architect of Identity for Microsoft, has said, “The Internet was created without an identity layer.” What he meant was that the Internet’s addressing system is based on identifying physical endpoints (machines) on a network. People are not endpoints on a network. Therefore, the Internet has no way to uniquely identify people nor tie their personally identifiable information (PII) to that identity. Sovrin is a blockchain system specifically designed to solve these problems.

Sovrin is an open-source decentralized identity network built on permissioned DLT. Sovrin is public, but only trusted institutions, called stewards – which could be banks, universities, governments, etc. – can run nodes that take part in consensus protocols: thus, the ledger is permissioned. The non-profit Sovrin Foundation ensures the proper governance of the stewards and their respect of a legal agreement called the Sovrin Trust Framework. Sovrin provides the code-base to the Hyperledger Indy project. Sovrin and other blockchain-based identity networks are covered in depth in our TechVision’s upcoming “Blockchain Identity” report.

Hedera Hashgraph

The Hedera Hashgraph Platform is a new entrant in the DLT space. It provides a new type of distributed consensus mechanism; a way for people who don’t know or trust each other to securely collaborate and transact online without the need for a trusted intermediary. The platform promises high performance and low latency but is just now being tested.

Hedera describes their focus as addressing the five fundamental obstacles to mainstream market adoption of public ledger technology: Performance, Security, Stability, Governance, and Regulatory Compliance. The Hedera platform and governance council’s stated focus is transparency, open innovation with platform stability, tools to enable opt-in KYC and AML, and global, cross-industry expertise to provide governance and decision making for a globally distributed network and cryptocurrency.

Decentralization

There has been a lot of discussion over many decades as to the advantages of decentralization. In the era of more and more centralized control and surveillance as well as increasingly powerful privacy regulations, these discussions are accelerating. Essentially, blockchain is a decentralized database with some unique capabilities. So, the first question an enterprise should ask is if you need a decentralized database solution.

We’ll first look at the advantages of traditional, centralized databases. Vitalik Buterin, the creator of Ethereum gave a nice presentation on how much faster and cheaper database writes and storage are when you don’t have to decentralized things. Here are the highlights:

Processing capacity is available at Amazon EC2 for $0.04 per hour. The Ethereum world computer[2] is $13.4 per 200 milliseconds. Ethereum is over 1,000,000x more expensive.

A 250GB solid state drive is $79.99. Storage on the Ethereum world computer is $84,000,000 for 250GB. Again, over 1,000,000x more expensive.

If a centralized database can work within your environment, it will most likely be a very good choice.  But it isn’t the only choice as there are some strong benefits to decentralized and distributed databases. You should look at a distributed, decentralized database architecture if:

• The data is going to rapidly and geometrically scale. The processing power required will begin to span multiple servers and that creates a need for some kind of partitioning.
• There are security concerns in that the centralized database is a single point of failure. Distributed database architecture improves availability and can mitigate some risks.
• Your organization is running into performance problems. Splitting a big table into small “tablets” can improve read throughput.
• Data distributed by location will improve performance for local users or is required by local regulation. Keeping data local is increasingly being required by current and pending privacy regulations.

The following figure looks at the types of distributed architectures that organizations may consider to in support of use cases that benefit from decentralization.

Figure 1 – Distributed database architecture

Distributed databases are a type of database that doesn’t have a central ‘master database’ that unilaterally decides on updating its state. The distributed model replicates data across multiple nodes (and devices) that collaborate to maintain a consistent view of the database state. These systems are designed to provide fault tolerance, i.e., ensuring that the system continues to work in case some nodes fail and become unresponsive. This only works if all nodes are honest as they are all cooperating and freely sharing data with each other based on mutual trust. This means that distributed databases are generally operated by a single entity that maintains strict access control to the network, which operates in a trusted environment.

Distributed ‘ledgers’ are a subset of distributed databases that use a different assumption about the relationship between nodes. Their design is based on an adversarial threat model that mitigates the presence of malicious (i.e., dishonest) nodes in the network. They are designed to be Byzantine fault-tolerant, meaning that the database should be able to synchronize and run even if a certain number of nodes are acting maliciously. This is in contrast with traditional distributed databases that operate in a trusted environment. Individual nodes on a distributed ledger do not trust their peers by default and thus need to be able to; a) independently verify and validate transactions that update the database state, and b) independently recreate the transaction data log (i.e., the entire transaction history).

Blockchains can be thought of as a special subset of distributed ledgers that share the same adversarial threat model but have additional characteristics that set them apart. Blockchains need to make use of a special, append-only data structure that is composed of transactions batched into blocks, which are cryptographically linked to each other to form a sequential, tamper-evident chain that determines the ordering of transactions in the system. In a blockchain system, all transactions are broadcast to every node and the nodes compete for the right to assemble and write the next block to the chain.

The final distinction is a permission model. Enterprises may not be comfortable letting pseudonomynous organizations or individuals introduce change to a database of record. Blockchains can be built that require permission to read the information on the blockchain, that limit the parties who can transact on the blockchain and that set who can serve the network by writing new blocks into the chain. A subset of blockchains have been introduced to restrict various levels of read and write authority to ensure enhanced performance and integrity.

Blockchain architecture

Thus far we’ve described some blockchain basics, looked some early consortiums and blockchain platforms that may provide a starting point for enterprises to investigate. We’ll now look a bit deeper into the blockchain architecture to give you a sense for how these pieces fit together and how blockchain really works. Figure 2 outlines the overall architecture of a blockchain system at the application, network and protocol layers.

Figure 2 – Blockchain architecture

PROTOCOL LAYER

The protocol layer includes the core software that constitutes the backbone of a distributed ledger system and can be thought of as the infrastructure upon which networks and applications are built. The protocol layer itself does not deliver any value without a network. Examples of core protocols include the Chain Protocol, Multichain, Corda, and the Hyperledger project suite.

Compare this with an iOS or Android. It is useful stuff and enables everything above it. From a business point of view, much like iOS and Android, it is extremely difficult to monetize on its own. That’s why most of the protocols are open-source so that volunteer contributors distribute the costs for protocol development and maintenance.

NETWORK LAYER

The network layer consists of the actual P2P network that brings a distributed ledger to life by connecting participants. The network can be built either using a standard core protocol, such as Chain Core, or using a combination of modular core building blocks (e.g., through Hyperledger). When people talk about a specific distributed ledger solution that is running in production, they usually mean a particular network. Networks can be industry-specific, use case-specific, or enterprise-specific. It is also possible to imagine the emergence of geographical networks that establish themselves in a particular country or region. The NASDAQ Linq blockchain network built on top of Chain Core constitutes an example of a running network.

Controlling the gates to this network is a valuable position. In the world of mobile, this could be seen as something like the iTunes App store or Play Store. The network nodes sit in the middle and make the calls as to who can read the data, who can create the data, and how they pay for it.

APPLICATION LAYER

The application layer constitutes the primary user interface for DLT. It is built on top of distributed ledger networks and provides products and services. For example, Citi Treasury and Trade Solutions announced in 2017 a new integrated payment solution that enables straight through payment processing and automates reconciliation by using a distributed ledger to record and transmit payment instructions. CitiConnect® for Blockchain, which is integrated into Citi’s existing payments capabilities and utilizes the Linq blockchain network. A financial institution can take advantage of the speed and auditability of blockchain by simply interfacing with Citi’s payment capabilities without the need for in-depth understanding of the underlying blockchain technology.

The application layer is sometimes referred to as the business logic layer. This is where a blockchain system generates real value. Some systems have purpose-built the three layers as a single system (Bitcoin), while other systems are more flexible (Ethereum, Hyperledger, etc.). Applications built in these systems can do a wide range of business functions on top of a blockchain. As the architecture matures, most users will only focus on the application layer and won’t even notice or care that they are on a blockchain (much as we enjoy using a mobile app, ignoring that we play the iOS version or that we access it through the iTunes App store).

Roles in Blockchain Development

Building blockchain-based applications and services can be thought of as a consisting of multiple roles. From an enterprise perspective the optimal scenario is to focus on the application development or, even better leverage cloud-based SaaS services that take advantage of distributed ledgers. The following breaks out some of the key development roles.

Figure 3 – Development roles

Core infrastructure providers should develop all the core software building blocks that are necessary for a network to be deployed (P2P network, data structure, consensus mechanism, functionality, etc.). They can be further divided into firms providing protocol development and companies focusing on distributed ledger network development: the former build the formal specification of the core protocol layer, whereas the latter build the actual distributed ledger networks for customers using existing protocols and frameworks. The major difference is that network developers are more akin to ‘development shops’ that use the existing architecture (i.e., the frameworks and protocols developed by protocol developers) that best fit the specific business case their customers are interested in. In many cases, they are specializing in a limited number of core protocols, and build either modular development environments with a suite of DLT toolsets, or directly develop custom networks for customers based on the core DLT frameworks that they support.

Application developers are entities that generally specialize in a handful of different protocol implementations. They primarily build applications for customers on top of distributed ledger networks. In some cases, the application can be ledger-agnostic and connect to multiple networks if required by the business case. Over time the fact that these applications are being built on distributed ledgers should be somewhat irrelevant, but at the current nascent stage there generally needs to be significant knowledge of the underlying technology.

Network Patterns

There are three likely network patterns for blockchains to handle permissions in the financial services area and in support of other high-value assets. These patterns are horizontal models, vertical models and third-party models. We’ll briefly describe each of these.

First is the ‘horizontal model’; this is where a number of powerful institutions (let’s say banks) are creating a network they own and manage to optimize and gain efficiencies for their own activities. Any party wanting to use this network will have to be on-boarded by this group or their agents. SWIFT, and many clearing houses were originally built on some pre-blockchain form of this model. R3 Corda is an example of this network pattern.

The second pattern is a ‘vertical model’; this could be characterized by a single institution with sufficient authority mandating that all business or participants within their sphere of influence will use a specific blockchain protocol and a specific network. The Walmart / IBM Food Trust Solution is an example of this pattern. Walmart has mandated that its food suppliers join the system by 2019 and suppliers will comply or stop supplying Walmart.

The third option that we see is ‘third party model’. A specialist service provider emerges that owns its own network and onboards all others: users (FS institutions, regulators), application providers, etc. This is best evidenced by the emerging blockchain as a service (BaaS) model. IBM, Microsoft and Amazon, for example, provide BasS offerings. We’ll describe this pattern in further in the next section.

Blockchain as a Service

An area that is rapidly growing in the blockchain space is the blockchain as a service offering. Much of the knowledge of the workings of the underlying blockchain/distributed ledger technology is hidden from the enterprise IT team who is then free to concentrate on the application layer to add value. This is consistent with where most software is going and will be a major method many enterprises will use to experiment with and ultimately deploy blockchain-enabled applications. The major cloud providers are all offering services at this level and we’ll provide a high-level overview of the few of the leading early offerings.

Azure Blockchain

Azure Blockchain Workbench is a collection of Azure services and capabilities designed to support the creation and deployment of blockchain applications. Azure Blockchain Workbench supports the sharing of business processes and data within and between organizations. It provides the basic infrastructure for building blockchain applications with specific tools for mapping business logic and supporting smart contracts. It also makes it easier to create blockchain applications by integrating several Azure services and capabilities to help automate common development tasks. This is a relatively low friction way to begin to engage with blockchain for Azure shops.

Blockchain on AWS

Amazon describes their blockchain technology as being used to solve two types of customer needs which we think is generally applicable to cloud-based blockchain services. The first case is for multiple parties working with a centralized, trusted authority to maintain a complete and verifiable transaction record. An example is a retail customer maintaining via DLT a transparent and verifiable history of information related to the movement of a product through its supply chain. In the other case, multiple parties transact without the need for a centralized, trusted authority. An example is a consortium of banks and export houses looking to perform cross-boundary transfer of assets (e.g. letter-of-credits) amongst each other, without a centralized authority acting as a liaison.

AWS provides a cloud-based distributed ledger database they describe as high-performance, immutable, and cryptographically verifiable. This can provide simple auditability and provides a blockchain platform to build on readily available to enterprise AWS clients. The AWS blockchain service supports the set-up, deployment and management of blockchain networks.

IBM Blockchain platform

The IBM Blockchain Platform provides a managed, full stack Blockchain as a Service (BaaS) offering delivered on the IBM Cloud, on-premises, and third—party clouds, such as Amazon Web Services (AWS).

The IBM Blockchain Platform provides a straight-forward user interface to relatively quickly set-up and manage networks, channels, and chain code (smart contracts). The IBM Blockchain Platform new member invitations, the creation of channels, customize governance policies, and the management of identity credentials. IBM leverages the Hyperledger Fabric they also contribute to and state that the support the principles of finality, trust, and privacy.

Emerging Use Patterns

While the press is consumed with the more speculative nature of blockchains; the cryptocurrency markets, initial coin offerings and the frequent announcement of new billion-dollar platforms, enterprises are progressing with use patterns that take advantage of the maturing underlying infrastructure to improve business model efficiency and reduce process friction.  In this section we describe a few of the emerging patterns.

Tokenization

Tokenization is the process of converting rights to an asset into a digital token on a blockchain. These tokens are referred to as security tokens to differentiate them from utility tokens which are digital tokens of cryptocurrency that are issued in order to fund development of the blockchain infrastructure and that can be later used to purchase a good or services offered by the issuer of the cryptocurrency. There is great interest by financial intermediaries and technologists around the world in figuring out how to move real-world assets onto blockchains to gain the advantages of Bitcoin while keeping the characteristics of the asset. Tokenization generally follows one of three patterns – intangible, fungible, and non-fungible assets.

Intangibles represent ideas or concepts, rather than physical goods, and so they more readily lend themselves to intangible markets – be they traditional paper markets or blockchain markets. You’re probably familiar with most of the big intangibles. Copyrights, patents, brand recognition, and goodwill are prime examples.

The next layer of innovation arrives with fungible goods. A good is fungible when it can be exchanged for another identical good of equal value. The most familiar fungible goods are commodities such as gold, oil, water, etc.

Finally, tokenization enables real-world, non-fungible goods to be parceled out into digital “shares,” which can then be bought, sold, or traded in a full or limited fashion with the public. The two most compelling use cases offered so far concern art and real estate.

We’ll now take a look at some of the pros and cons of using blockchain in support of these categories of blockchain tokenization. While blockchain is very early in its rapid evolution, there are basic strengths and challenges that are offered by moving to distributed ledger-based services.

Pros	·      Programmable Security Support: This is a major area of opportunity as the blockchain can support the recording of specific rights included in the securities, such as dividends, voting rights, and interest. They can then be programmed into the security itself and be fully automated (for example, monthly dividends). This programmability can also be taken a step further to support features such as governance, compliance, and KYC procedures. We are early in exploring these opportunities, but they are compelling. ·      Ownership and transferability: Because of the underlying blockchain technology, tokenized securities ownership can be immutably and irrefutably stored on a decentralized ledger. This also allows for the virtually-instant transfer of securities between different owners at a much lower cost basis. ·      Interoperability: The technology supports securities being traded cross-exchange and against other crypto assets, even other tokenized securities ·      Increased liquidity: Advantages include faster trading on secondary markets, potentially lower liquidity premiums for early investors, which should ultimately result in great market efficiency (especially given the ease of transferability of security ownership). ·      24/7/365 trading: Blockchains generally aren’t subject to downtime, and the trade of digital assets is always live. ·      Lower costs: Cost of issuance, registry, exchange, underwriting, clearance, settlement, reporting, and compliance can all be dramatically reduced through the automation of these processes. ·      Fractionalization: Large investments such as real estate or even expensive stocks can be fractionalized, allowing for co-investing in large assets ·      Strong increase in the addressable investor pool: Given the ease of transferability and borderless nature of blockchain technology, tokenized securities can open otherwise inaccessible investment opportunities to people globally.  Moreover, the previously mentioned fractionalization, low capital investors can invest in a near infinitely broader range of assets. ·      Transparency: By using a decentralized ledger instead of using opaque third parties, all transactions of a security are visible mitigating the risk of manipulation and corruption.
Cons	·      Potential lack of market liquidity: When a security token platform suffers from low tradability, it means there are fewer transactions per block and/or fewer blocks are created. This, in turn, discourages network operators who are looking for a return on the inputs invested, i.e. IT resources and personnel. Fewer participants mean a lower hash rate. A lower hash rate reduces the security of a token, which in turn lowers the token’s tradability still further – and thus its value. A vicious cycle emerges as a product of this illiquidity. Equity markets manage this illiquidity threat through a market maker model, where the market maker is obliged to hold a certain number of orders open in its order book throughout core-trading hours. This assures the market that if one decides it is time to exit a position entered, there will be an open opposite position at near-market price.  Because of its bias towards decentralization, the market maker model is missing from blockchain implementations. ·      Potential Redundancy: When there is a statutory need for a third-party, off-chain validation of the transaction (such as with private equities or with real estate, cars, boats, planes, etc.). While ownership can be attested through the blockchain, asset transfer can only happen off-chain. The blockchain is then redundant because its main functions are already performed by the third-party validation off-chain. ·      Too Early: Security tokens are fairly new, and the business and regulatory models are still evolving.
Early efforts	·      Polymath ·      Swarm ·      Tokeny ·      Open Finance Network ·      TrustToken

Decentralized Identity

One of the curious constructions on the Internet is the term identity provider. A person doesn’t need anyone to provide him/her with an identity, of course. Everyone has an innate identity by virtue of being human. Rather, so-called identity providers, or IDPs, provide an identifier, a means of recording attributes important to that provider, and some method of proving a person is who they say they are – usually a password.

This is not surprising since online identity has traditionally been viewed through the lens of an organization and its needs, not the individual and his or her needs. Identity systems are created to administer identifiers and attributes within a specific domain. The result: people end up with hundreds of online personas at hundreds of organizations. Each of these administrative identity systems is proprietary and owned by the organization that provides it; an individual doesn’t have an online identity that’s independent of the multitude of systems they are connected to. If a person gets a new address, or an updated credit card number they must deal with each of these systems one at a time in whatever manner they require. It is a system that is fundamentally broken.

And because these identity providers (enterprises themselves or trusted third-parties) hold and manage these central identity systems, they are ripe for cyber-attack and bear the responsibility for managing legally mandated consent. One of the digital tokens that is peaking interest among enterprises is digital identity. More specifically, decentralized or self-sovereign identity. These emerging, blockchain-supported ecosystems promise to secure, individual control of their identity and claims they want to declare. This is being covered in depth in a TechVision Report that will be available shortly.

Self-sovereign identity works great in real life, where individuals carry paper or plastic credentials (something physical), but it’s been much harder to duplicate this in current implementations of digital identity. Several vendors are building these decentralized or self-sovereign identity systems based on blockchain including Microsoft, IBM and several early stage companies. There is an interesting early self-sovereign identity ecosystem and governance model from the Sovrin Foundation and a notable partnership announced in December of 2018 to address decentralized identity from Microsoft and MasterCard. As part of the Microsoft/MasterCard announcement, Ajay Bhalla president, cyber and intelligence solutions at Mastercard stated “Today’s digital identity landscape is patchy, inconsistent and what works in one country often won’t work in another. We have an opportunity to establish a system that puts people first, giving them control of their identity data and where it is used”.

Figure 4 – Verifiable claim example courtesy Phil Windley, Chairman of the Sovrin Foundation

Self-sovereign identity is the concept that people and businesses can store and control their own digital identity data and provide it efficiently to those who need to validate it, without relying on a central repository of identity data.  It’s a digital way of doing what we do today with bits of paper.  We’ll briefly list a few of the pros and cons of blockchain-based decentralized identity as follows:

Pros	·      Elimination of identity data and password management responsibility ·      Reducing the need for centralized databases for identity data ·      Cost reductions in service delivery and support due to stale personal data ·      GDPR and Privacy by Design compliant ·      KYC/AML assurance and portability ·      Limit risk by not storing unnecessary Personally Identifiable Information (PII) ·      Support for Bring your own Identity (BYOI) ·      Expect this to be well received by consumers; a competitive advantage
Cons	·      Loss of efficiency of storing attributes vs. requesting verified claims (Complete reliance on the blockchain as a universal Identity Provider) ·      Data rights conflict (mutually “owned” data) derived data (study cohorts based on summarized / anonymized individual data. ·      The current “free” internet business model, data sales and data brokers depend on free use of personal data attributes. ·      Oracles and correlation unreliability (data originated outside of the chain is only as good as the source)
Early efforts	·      Microsoft ·      Hyperledger Indy ·      Sovrin ·      Sho-card ·      Blockstack ·      Civic ·      IBM Blockchain Trusted Identity™ ·      Decentralized Identity Foundation (DIF)

These efforts will be described in greater detail in our report on decentralized/blockchain-enabled identity to be released within a month of this publication. We do believe that a very important blockchain pattern will be in support of decentralized identity services. Next, we’ll look at another key area of potential blockchain synergy; managing, securing and supporting auditable supply chains.

Supply chain

The ability of blockchain to provide an undisputed, commonly shared, secure and time-stamped record of products moving through complex supply chains is one of the most discussed nonfinancial use cases for the technology. In general, the supply chain and logistics industries face less regulatory hurdles than many other industries experimenting with blockchain solutions. The combination of the relatively straightforward benefits of reducing time and money spent on disputes, improving efficiency, freeing up working capital and enhancing consumer confidence, the supply chain and logistics industries may be amongst the first to realize the true benefits of blockchain.

Pros	·      Automating the purchase process: Blockchain and automated contracts (smart contracts) can provide a foundation for automation. Once the conditions agreed upon by the users are met, these smart contracts automatically execute their terms– service payment, shipment authorization, etc. ·      Improving transaction flow: Validation times for transactions between providers and clients (contracts, signatures, orders, payments, etc.) are drastically reduced. Result: virtually real-time management of flows and relationships with business partners. ·      Securing the supply chain: Attributing a tag to each product recorded in a blockchain enables you to secure your supply chain automatically. Include attributes such as origin, place of storage, authenticity, property certificates, records… all the necessary information in a single ledger. ·      Ensuring integral traceability: Blockchains ensure the traceability of flows and goods by recording all transactions made by users. These records are immutable and provide tamper-proof evidence that guarantees the information integrity. ·      Proactive fraud detection: Blockchains can help you detect fraud by identifying problems from the very start of the transaction (inconsistencies with validation, suspicious identity of a party, etc.). In the event of product recovery, an alert is instantly sent. ·      Streamlining internal documents: The validity of information shared among partners prevents the creation of multiple versions of a document. Each party involved in the transaction thus has access to the same data.
Cons	·      Not everyone benefits from transparency: This is shown in the illustration below, markups exist at every handoff and transactions on the blockchain are visible to anyone with access, including competitors that supply components and services within the chain.  Care needs to be taken to properly isolate visibility. Figure 5 – The making of a Weekender bag. ·      Big players defining the platform can create a governance issue: Walmart can dictate that its suppliers use its blockchain solution because they have nearly monopolistic market power.  Maersk, the world’s largest shipper cannot because other shipping firms are not willing to let Maersk dictate the rules. ·      Supply chains are hard to build and easy to disrupt: Manufacturers and retailers have trimmed their supply chains to save money and engineered them within an inch of their lives to deliver just-in-time performance. This has made supply chains wonderfully efficient, yet woefully vulnerable.  When supply chains break down, customers don’t get products, companies lose revenue, brands are sullied, and the company goes into a hole. Injecting a disruptive technology into a running supply chain needs to be planned carefully.
Early efforts	·      IBM Watson Supply Chain ·      Walmart / IBM Food Trust Solution ·      Blockchain in Transport Alliance ·      Waltonchain ·      Provenance ·      Everledger

Financial settlement

Currently, banks transact with each other by creating agreements, as one would when purchasing an item from a store. A common example would be a bank agreeing to purchase a specific amount of stock for a specific cash price from another. This process, often cumbersome and slow, takes up to several days and incurs the risk that one party may default or renege on the agreement. This period of time, known as settlement, is such an issue that an Oliver Wyman report identified it as costing the financial industry anywhere from $65-$80 billion a year.

Blockchain projects have the potential to reduce, and possibly eliminate, settlement times due to their digital nature, ensuring the timely and secure processing of these operations. Other uses for bank-backed blockchain projects would include secured global currency exchange rate speeds and increased transaction security, among other benefits, eventually allowing for an overhaul of the banking industry, replacing traditional back-office clearinghouses and other outdated mediums that exist between asset sellers and buyers.

Pros	·      Cost reduction: Potential to dramatically reduce the cost of cross-border transaction fees. This will also have major institutional and political implications for un-banked populations in unstable economies. ·      Identity management for the financial sector: One of the most compelling use cases for blockchain and an area of active investment. Know your customer (KYC) requirements are becoming more stringent as regulators combat money laundering and other illegal financial activities, and blockchain’s underlying protocols support more robust identity management by both consumers and the financial institutions they participate in. ·      Smart contracts enabled by blockchain technology will streamline the settlement and titling processes for financial transactions that involve the exchange of goods and services.
Cons	·      Because of its incremental unplanned design, the large value B2B financial system is one of the most expensive and fragile ecosystems. Blockchain offers the potential for streamlining the system and eliminating the middlemen. Unfortunately, in this system is built upon the assumption of middleman. Large entities act as clearinghouses for high value transactions and as translators required by the age and inconsistencies of the thousands of interconnected financial systems. These institutions provide value for a system that relies on mapping multiple identifiers and nonstandard data elements, and reconciling differences manually when they do not match up. ·      Financial market infrastructures (FMIs) and utilities (FMUs) are the central entities that perform this data transformation and reconciliation. These organizations were installed by financial institutions to solve the problems that have developed over the decades of international finance. ·      To enable manual reconciliation, there are significant time lags measured in days between when transactions are entered into, when they are validated and when value is transferred. It is not clear how the business model will be impacted when this time lag leaves the overall system. ·      Regulators must adapt to a new business model where the role of FMIs and FMUs is changed (or eliminated) ·      Finally, technology is only part of the solution. It’s “a big ask” for banks to integrate blockchains into their existing IT systems. “You are not just installing a piece of software. They need to build operational knowledge and know-how,” adding that “it has security implications”
Early efforts	·      Ripple ·      R3 Corda ·      IBM Blockchain WorldWire ·      Citiconnect for Blockchain

Reconciliation

Global enterprises face a number of challenges that arise due to missing information, transaction mismatch and fragmented communication among the various entities and processes doing the reconciliation. When public entities are under quarterly pressure to publish their financial results under strict timelines, they choose to carry forward any remaining unreconciled items to the next period. Over time, this can accumulate to cause a material mismatch in the participating entities. The accounting errors, duplication of transaction entries, and adjustments due to cancellation of transactions can further complicate the reconciliation process. Key aspects of this blockchain enabled reconciliation follow:

• Limited counterparty visibility: Geographically dispersed group entities use varied and isolated accounting systems, which impairs enterprise-level visibility into each entity’s ledger accounts and transaction details.
• Non-standard accounting: More often than not, group entities use different accounting and general ledger systems. Moreover, since many multinational corporations are the result of takeovers, mergers, and acquisitions, such system-level differences have become even more pronounced. In addition, various legacy accounting systems and multiple charts of accounts are likely to be in operation. It is a challenge to make these varied systems talk to each other for a common accounting and reporting exercise.
• Technology: Not all organizations currently use technology systems for inter-entity reconciliations. They may have processes that are either manual or semi-manual, which are error-prone and time-consuming. As a result, ensuring accuracy and timeliness of inter-entity reconciliation becomes a challenge.
• High volume of transactions: The larger the group, the more the propensity of internal transactions. It is a challenge to capture these complex, multidimensional, voluminous transactions, and reconcile them within stipulated timeframes.

The following are the pros and cons of leveraging blockchain for reconciliation:

Pros	·      Common, real-time, intra-company distributed ledgers within a group can eliminate mismatches, and reduce the non-value adding tasks in intra-company reconciliation and reporting ·      Distributed ledger software offers APIs for integration with branch-level finance systems ·      Can be integrated with the branch finance systems or maintained as standalone applications, depending on the volume of intra-company transactions ·      Blockchain/DLT is useful for keeping provenance and lineage of data, and for building trust among participants. ·      Its decentralized and distributed nature makes it secure against a single point of failure which impairs central databases storing intercompany transactions. ·      It also has the capability of smart contracts, i.e. encoding business and control logic to enable automatic verification and processing.
Cons	·      Blockchains replicate data between nodes. If some of your data needs to remain onshore in specific jurisdictions (e.g. client data in Singapore) then you will need to find a solution that fits. It’s relatively straightforward concept, it just needs to be thought through when implementing these solutions. An approach could be, for example, to house client data onshore in a regular database, and keep transaction data on an internal blockchain. ·      Blockchains are visible to all parties.  If there is a need to screen certain transactions from view for privacy or regulatory purposes, this needs to be explicitly addressed. ·      Regulators need to accept a blockchain ledger as the system of record across the entire enterprise. ·      Auditors need to move from auditing the transactions to auditing the blockchain. If the transactions are certified and recorded based on validation rules, consensus mechanisms, and smart contracts, auditors need to make sure those constructs meet accepted accounting standards for the applicable regulatory environments.
Early efforts	Because these efforts are internal, the solution tends to be a private blockchain rather than a full commercial offering.  The following are examples of blockchain technology that can be deployed within an enterprise. ·      AWS QDLT ·      Multichain ·      Stack (Blockstack)

Recommendations

We’ll look to wrap this report up by assessing where blockchain really is today and provide some advice and guidelines for building and enterprise blockchain strategy and program.

Current state observations and key considerations

Blockchain can have substantial impact on enterprises for the foreseeable future and, while early in its lifecycle, our enterprise clients should seek to understand blockchain and relevant patterns, evaluate it and consider it a foundational element for appropriate future-state architectures. Most of the investment and efforts to date have been in developing the infrastructure (protocols and networks). The most mature networks and protocols are deployed as public/permissionless blockchain implementations (Bitcoin main net and Ethereum).

Consortiums and platforms are working to develop an enterprise grade version of blockchain. Specifically implementing consortium and private chain implementations. They are trying to overcome the gaps public chains present. However, the network effect is most powerful when there are more participants and by their very nature, permissioned or private chains are limiting.

Education is also critical; some of which you will get from reports like this from TechVision as well as workshops, white papers, early tests and POCs. TechVision also conducts workshops and consulting to help our clients develop appropriate blockchain strategies and tactical steps to take in executing on these strategies.

New developments such as Zero Knowledge Proofs are working to solve confidentiality, privacy/compliance and inefficiency issues on a public blockchain. But the technology is new and brings its own set of problems, such as the complex and resource intensive “trusted setup” process required to establish a proof.

There is a major mind-set change required to understand how native (utility) assets differ from the tokenized assets we are introducing with blockchain. Enterprises and regulators need to address the relationship between a tangible asset and its digital representation. For example, how does change of ownership work for a building that has been offered for fractional investment on a blockchain.  Each regulatory environment needs to set rules for this and other situations where the digital world differs from the real world…and there will be many of these scenarios as we move to tokenization and digital representation.

Enterprises should be thinking about the architecture stack and where it makes sense to engage and to what level. If you want to influence the system, a good first step may be to join a consortium. If you just want to develop on top of a system, you may want to join an existing network or think about BaaS. These are all ways to begin to engage without extending too many valuable resources. The opportunity is immense, but remember we are very early in the game.

Organizations should also keep an eye on fragmentation and interoperability; different ledger systems have different protocols, consensus, and validation rules that may not play nicely together. Enterprises should choose wisely and architect for flexibility that allows for operations independently on different systems.

Finally, keep in mind that Blockchain is like a startup; immature, promising, and subject to pivots. Investments in the technology should be looked at as experiments where finding use cases that don’t work are just as valuable as ones that do. Start slowly, learn, test, iterate and be ready to move forward at a faster pace when the opportunities arise.

Strategy Recommendations and Next Steps

In this report, we have reviewed the current state of blockchain, its architecture, and use patterns.  As you develop your strategy, make sure you answer these questions.

1. What business problem do you want to solve with blockchain?

In its simplest form, in any business, employees are trying to get a job done and in doing so, increase revenue and profits.

Business decisions on disruptive technologies such as blockchain shouldn’t be based on technical novelty; there needs to be real business benefit. Legacy systems and processes are already providing a certain level of business benefit and disrupting those existing capabilities across internal and external organizations needs a compelling reason to switch. In the startup world, the rule of thumb is a 10X improvement is compelling, otherwise it is a struggle to get the customer to change. We’ve described several areas of improvement that can be achieved using blockchain, but you will have to assess this against your current and future business needs. This is, of course, the starting point.

For example, an area of substantive potential business benefits we see is in the financial settlements area. Currently it generally takes 2-3 days (4,320 minutes) to reach final confirmation on a global transaction due to various organizational handoffs and manual reconciliation. Bitcoin blockchain confirms transactions in 10 minutes and other blockchains are even faster. Speeding up transaction settlement and freeing up corresponding reserves is a compelling business benefit to fund an experimentation with blockchain.

Before you think about how to deploy blockchain technology to solve a problem, you need to find a problem worth solving. Also, you’ll need to pay attention to the network effect.  Blockchain is a network solution and if only a portion of your supply chain / trading partners participate it may be difficult to see the benefits.

Even though you might have seen many successful cases with business models like yours, there is no guarantee that blockchain technology will work for you in the same way. Even if you have a clear understanding of what blockchain offers, you need to make sure that the technology maps to your unique business processes and needs.

Review the objectives outlined below. If you have business use cases that require this type of functionality (preferably more than one of these capabilities), you may want to consider/investigate blockchain as part of your future state solution.

• Reduce the need for an assumption of trust between stakeholders
• Build a secure value transfer system
• Streamline business processes across multiple entities
• Increase record transparency and ease of auditability

2. Are you ready to involve third parties when it comes to sharing control over your network?

Currently, blockchain provides stakeholders with a high level of security as the data kept within the system is safe from theft or violation, but it is being shared to some level outside of your organization. It is this decentralized capability, the sharing of responsibility that makes blockchain so desirable to business owners who choose this technology to transform their organizations, but must also be addressed from a legal, privacy and regulatory perspective.

If the nature of your business demands that you retain full control over your network, then blockchain, may not be the best solution for your organization. Blockchain technology supposes the establishment of a coordinated community for all the parties involved, allowing them to run ‘nodes’ which hold a copy of the database, creating a peer-to-peer network and if this is counter to your business needs, it won’t be the right choice.

A blockchain ecosystem with just one member is useless as it is only effective when your connections have signed on to it. If you intend to adopt blockchain, you need to be prepared for other writers to generate transactions that will modify the database.

3. Do you understand blockchain’s weak points?

Blockchain is not a cure-all when it comes to problems regarding the security of your transactions; there are limits to what it can achieve. Generally PII should not be placed in a public ledger. There can be challenges in integrating blockchain into your established organizational processes and operations. As blockchain requires a large network of users and a grid of nodes, you need to be prepared to migrate your infrastructure to next-generation platforms and allocate a budget for new software and tools. Years may pass before you put new business processes in place.

Blockchain transactions are slower than centralized database transactions, as blockchain needs to check three additional parameters:

• Signature verification to provide security in a peer-to-peer fashion. Such verification is complex and time-consuming.
• Consensus mechanisms to ensure that nodes in the network reach unity.
• The general computation in all nodes, as transactions must be processed independently by every node in the blockchain network. For comparison, centralized database transactions are processed just once or twice.

Blockchains are still maturing and most of the effort has been to build out the infrastructure of the blockchain systems. They have not been subjected to the extensive burn-in periods that older technologies (internet protocols, RDMS, etc.) have. Errors and unanticipated consequences may pop up and your organization needs to understand that some risk is being taken in these areas.

4. Finally, do you have all the resources you need?

In addition to everything we have already mentioned, it’s vital that you are blockchain literate; comprehensive blockchain knowledge and skills are critical for a successful adoption. Whether you retrain your current staff or hire external experts, your business will need employees that know blockchain inside and out; while it has the power to revolutionize your transactions, it is as diverse and complex as it is exciting. Remember this is a disruptive approach in terms of the technology (math, algorithms, and cryptology) and the business models (decentralized, token-based) that are generally not the traditional IT skillsets. This is especially true in these early days when application tools and support structures are still developing.

Remember we are early in the blockchain journey. Good luck and feel free to contact TechVision if you would like a dialogue or have questions about this or any other topic we cover.

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 access to content. 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 in areas such as product and strategy reviews and assessments, requirement analysis, target market assessment, technology trend analysis, go-to-market plan assessment, and gap analysis.

TechVision Updates will provide regular updates on the latest developments with respect to the issues addressed in this report.

About the Authors

His experience at Neustar, Respect Network, and Sovrin allows him to provide a broad perspective on a variety of subjects including self-sovereign identity, blockchain, enterprise data management, and the data brokerage industry.  His experience both enterprise and startup product development give him a unique perspective on innovation.

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, AI, 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.

[1] Turing complete means “able to answer computable problem given enough time and space”. Most modern programming languages are Turing complete because they implement all the features required to run programs like addition, multiplication, if-then-else conditions, return statements, ways to store/retrieve/erase data, etc. Before Ethereum, blockchain did not have all of these capabilities in its scripting language and was limited in its ability to solve complex problems.

[2] Ethereum’s combination of features allow it to provide users smart contracts and decentralized applications, otherwise known as DApps. Ethereum’s vision is to implement a globally decentralized, un-ownable, digital computer for executing peer-to-peer contracts. Put more simply, Ethereum is a world computer that can’t be shut down.