By Deborah Dobson posted 11-08-2016 08:51


After years of hype, accomplishments and setbacks, a rare glimpse of order may be taking shape in the distributed ledger landscape

By: Josias N. Dewey & Deborah Dobson

Distributed ledger technology (or simply, blockchain) has the potential to alter virtually every industry, including the legal profession.  Yet, only a small minority of people are familiar with the technology, and even fewer truly understand the science and principles behind it.  In fact, quantum mechanics may be better understood than blockchain.  There are, however, valid reasons why more people understand “spooky entanglement” than “Byzantine fault tolerance”.  While quantum mechanics has been the subject of methodical scientific study for decades, blockchain represents a nascent technology whose science and application are only now coming into focus.  The study and application of blockchain, like quantum mechanics, involves complicated mathematical theory, which in the case of blockchain, also includes asymmetric cryptography.  Blockchain research and its application in the field, however, extend well beyond mathematics and cryptography to also encompass microeconomics, game theory and other issues normally within the study of jurisprudence.  This post is not a primer on blockchain. There exist plenty of well written and easy to understand resources to provide the reader with a solid foundation of knowledge.  If this is your first adventure into the world of Blockchain, you might consider the series of Bloomberg BNA articles on blockchain and the law that can be found on this page.  If you are interested in a deeper dive into the intersection of law and blockchain, this Thomson Reuters publication is a great resource.  In addition, you can find articles on blockchain here.

Instead, this post highlights several themes regarding the state of blockchain as 2016 comes to a close.  That said, this post is not a “year in review” report.  Rather, several recent events have occurred, which when taken together, point to some rarely seen consolidation and clarity in the blockchain space—even if only temporarily.  This should be a welcomed development for any provider of technology to the legal profession who comes in contact with blockchain.  In order to help put the remainder of this post in context, let’s quickly consider the three key ingredients that make a blockchain.  The first key ingredient is a blockchain’s peer-to-peer, distributed network.  Rather than there existing one or more centralized servers, participants of a blockchain (sometimes called nodes) establish direct connections with other participants, who in turn, have their own separate connections with other participants.  This distributed structure continues throughout the entire network—which has the effect of producing a network resistant to failure or censorship.  The second key ingredient is a ledger.  The purpose of the distributed network is to maintain this ledger, which consists of a collection of state variables (i.e., it keeps track of stuff).  For example, a ledger can record cryptocurrency transactions, as in the case of Bitcoin, or even more complicated data structures that can be constructed with a Turing-complete programming language, as in the case of Ethereum.  The third key ingredient is the ability of all the participants or nodes to reach consensus on the state of the ledger without any need to trust any other participant.  There are several types of consensus algorithms or mechanisms, such as proof-of-work, proof-of-stake and others that rely on Byzantine fault tolerance (BFT) or similar calculations.  Unfortunately for those responsible for designing real world blockchains, there isn’t just one recipe for how to combine these ingredients

The nearly endless cookbook of blockchain recipes is particularly challenging for anyone servicing the legal industry because neither lawyers nor the IT personnel within most law firms have any experience with blockchains.  During the last several months, however, some themes have emerged that should provide a modicum of relief.  More recently, R3, a consortium that includes over 70 member banks, announced it would be open sourcing its Corda platform under the umbrella of the Hyperledger project, which is in turn a part of the Linux Foundation.  In addition, the Iroha project, a mobile friendly protocol, was added to the Hyperledger effort.  As a result, the open source Hyperledger project now includes four blockchain protocols under active development (albeit, all in the incubation phase).  These protocols include Fabric (maintained primarily by IBM and Digital Asset Holdings, and being the closest to leaving the incubation phase and achieving version 1.0 status), Sawtooth Lake (maintained primarily by Intel), Corda (again, contributed by R3) and Iroha.  You can find a summary of each of them here

Many of Hyperledger’s codebases are purposefully modular in design, such that the consensus algorithm is separate from the business logic of the ledger.  This design philosophy gives a developer the ability to utilize those components best suited for the current program requirements and replace those that are not adequate.  Based on the Hyperledger Fabric codebase, IBM has also implemented a cloud solution known as IBM Blockchain on Bluemix.  This blockchain as a Service (BaaS) allows developers to prototype blockchain solutions for any industry, including the legal profession, all within a virtual environment and without the need for any expensive infrastructure.  We suspect that most providers of technology solutions to law firms will find themselves working collaboratively with law firms to build blockchains for law firm clients rather than law firms themselves—at least initially.  This combination of modularity and a virtual, cloud-based development environment makes prototyping a blockchain with detailed program requirements exponentially more possible than just six months ago.  For example, imagine a law firm approaches you for a proposal to help assist it with a client project involving a distributed ledger for the supply chain of coffee beans that includes a tokenized version of a merchant letter of credit capable of virtual “presentment” after a GPS-enabled Internet of Things (IoT) device confirms the location of deliveries at port.  Today, this project can be approached with a much more conventional development strategy.  

Like IBM, Microsoft has also invested heavily in their own BaaS as part of their Azure cloud platform.   Microsoft has taken a multi-pronged approach to its BaaS solution, by allowing developers to spin up virtual, permissioned Ethereum networks in a matter of minutes.  So for those projects where a privately maintained Ethereum network is optimal, you can be prototyping in a virtual network in minutes.  Alternatively, developers can utilize a new set of blockchain tools being developed by Microsoft under the name “Project Bletchley”.  Project Bletchley introduces the concept of Cryptlets, which are essentially trusted containers in which code can be executed “off-chain”.  In other words, code is executed in a container and the values returned from the container after execution of such code determine which, if any, of the state variables maintained by the ledger must be changed.  The use of trusted containers for code execution is similar to how Hyperledger Fabric uses Docker containers to execute “chain code” (its equivalent to Ethereum’s smart contracts) as the mechanism for changing the values of state variables on the ledger. 

So two significant trends affecting blockchain developers (including decentralized application developers) are (1) the development of powerful cloud based solutions and resources (which is mirroring that seen in enterprise infrastructure more generally), and (2) the use of secured containers within which code is executed separate and apart from the ledger of state variables, which is in contrast to the Ethereum virtual machine (EVM) model where the EVM and state ledger are very much integrated.  There are several advantages to the container approach, including having the flexibility to write code for execution in the container in one of several programming languages, and architecting systems in which each node does not need to execute every snippet of code or smart contract delivered to the blockchain.  In fairness to Google Cloud and AWS, both of those cloud services support working with blockchain development in the cloud, but in our opinion IBM and Microsoft have shown a greater commitment of resources and focus on blockchain development.  It’s worth noting that some of those resources include the integration of artificial intelligence systems, like Watson, with blockchain technology.  The potential for AI systems to oversee the entire set of data constituting all of the transactions implementing the business logic found on a blockchain could be a game changer.  Such technology could serve numerous purposes, including preventing financial asset bubbles and similar financial imbalances.

Another recent development was the open sourcing of Chain’s Core protocol, which like Ethereum, operates using a virtual machine (the Chain Virtual Machine) that runs a native code known as Ivy.  While the authors have not yet had an opportunity to develop anything with Chain’s Core code base, the protocol’s white paper describes a very robust system capable of interoperability between different asset ledgers that can be created by various participants within the network.  Given Chain’s successful partnerships with established payment processors, we are confident that Chain Core may make sense for certain projects. 

Without intending any disrespect to the many other protocols and solutions under active development (e.g., Multicoin, Factom and various side chains) for most developers asked to provide services to a law firm or to collaborate with a law firm on a client project, the development of a prototype can now follow as much clearer set of considerations and options.  This is a gross oversimplification, but a sample work flow of considerations could be as follows: (A) if the primary program requirement the creation of a cryptocurrency or similar store of value (e.g., a central bank token), then consider the mainstays of the industry, such as Ripple, Bitcoin or using Ethereum to create tokens, (B) if the primary purpose to maintain a more complicated set of state variables in a public environment or very wide group of people, then consider the public Ethereum network, or in the case of a more limited universe of participants, a permissioned system built with Microsoft’s BaaS, or (C) if the primary purpose is to create a permissioned ledger dealing with complicated systems and business logic (especially where disclosure of transaction information must be hidden from some participants), then explore Hyperledger and prototyping on IBM’s BaaS, or if specifically tailoring products for financial institutions also check out Chain’s Core.

For those of us who are faced with the responsibility of building, or even advising on, blockchain systems, the landscape still remains complex, but even if for just a few brief moments, a tad bit of the fog has lifted.  We look forward to re-visiting the landscape in a few months to see whether increasing clarity continues or a deep fog returns.  Until then, good luck and remember that your work is helping change the legal industry and many of its clients for the better.