Blockchain

Enough about Bitcoin and Ethereum. Let's get on to the importance of the underlying elegant technology that really turned out to be the most important part of Bitcoin for the financial institutions. The complexities involved with designing a self-governing, transparent, decentralized distributed network cannot be overstated. The basis of the Bitcoin platform is a technology called blockchain. The blockchain turned out to be the golden goose of the Bitcoin platform. Blockchain is a new innovative technology that will change how financial institutions transact business in the financial services system.

So here are five key points:

1. Distributed ledger technology is more than Bitcoin. So when you hear the words blockchain or distributed ledger, don't just automatically think about Bitcoin. There are a lot of other use cases for this distributed technology other than a cryptocurrency.
2. A shared distributed ledger is a linked set of duplicated transaction records. For the accountants who are reading this, it is like double ledger entries on steroids. Imagine a thousand ledger entries and a thousand notaries for each transactions.
3. All transactions on a distributed ledger are independently verified by the participants on the network and then stored on in ledger individually.
4. The value to financial institutions is the ability to remove the middle players by taking advantage of the decentralized nature of the platform.
5. Removing the middlemen will increase efficiency and security.

As if all of those qualities weren't enough, the blockchain introduced another revolutionary technology called a smart contract. The smart contract is the natural outcome of a decentralized network. When two entities transact business via the traditional centralized network method, the middle man takes care of contracts. Since there isn't a middleman to provide contracts to protect each side, a smart contract allows this to be done programmatically without human intervention. The smart contract has the ability to execute programs on behalf of the specific entities on the network based on contract terms. Once these nodes come together on consensus on the execution, then the results of the execution can be written to the distributed ledger and are immutable. A great example would be selling a digital asset like a book or music in a digital form. You agree to purchase a digital asset for a specific price, and the seller agrees to provide the content. In this case, to make it easier to understand, let's make it a subscription to content that is delivered monthly. In the smart contract, there is a provision that says if new digital episodes of the digital asset are not delivered by 1 p.m. on the first of every month, you get a refund. One day the subscription content is delivered at 1:01, the smart contract is triggered, and without any human intervention, your money is refunded.

So why do we care about all of this? Well, first of all, let's look at what's happening in the world. We've seen massive amounts of money poured into the blockchain/distributed ledger area in the past two years specifically by the large banks around the world. In September 2015, a group of large banks got together to try to use the blockchain concept to solve various common problems. The group formed R3 to leverage the distributed ledger and create a next generation financial services platform that would provide solutions to these common problems. The group now consists of 80 global financial institutions and through their collaborative efforts developed a financial services ledger platform called Corda. Corda was designed to allow participants to transact business with the need for a centralized switch or authority. The Corda application was also designed to allow others to build applications on top of it (called Cordapps). So if all of these large banks see this opportunity and are willing to invest large sums of money, then there must be something there, right? We agree, where there is smoke there is often fire.

Another popular distributed ledger project, built around the Linux Foundation, is the Hyperledger Project.

So with all this hype and all the things going on, what does that mean? Well, first, let's talk about the first thing. Distributed ledger is not Bitcoin. So we're not creating a new way for everybody to transfer Bitcoin back and forth between banks. As I said before, it's the elegant underlying technology that enables Bitcoin. So if Bitcoin was an application, distributed ledger would be the operating system. It's also known as shared ledger, distributed ledger, or blockchain.

So let me walk you through a theoretical transaction (see Figure 6.1). Financial Institution A wants to deliver money to Financial Institution B. Now, please understand that this is not the best use case for a distributed ledger. However, it's one that's easy for people to understand. So we'll use it as our straw man for our first experience in the distributed ledger platform.

So, if Financial Institution A would like to send money to Financial Institution B and they're both connected to a theoretical distributed ledger platform, then they would reach out and put their transaction in an encrypted block. Now, this block actually would be encrypted using Financial Institution B's public key so that they're the only ones that can open it. Once encrypted, the digital box will be sent into the distributed ledger network via their node. What's interesting about the distributed ledger is that it's not like the telephone game. It's not something where you send it to one node and then that node tells another node and that node tells another node and that node tells another node. You can think of it more as like a person standing in the middle of the stadium, with everyone else dead quiet, shouting out facts and everyone hears the same fact at the same time. Once everyone hears that fact, now they can go through and validate the transaction separately. The distributed ledger creates a “single source of truth” for each transaction on the ledger that is immutable. Let's take a moment to discuss what validation and consensus look like. If you've ever been driving down a highway and you've seen a weigh station, you've seen an example of what this technology does. So when a truck pulls into a weigh station, the truck is weighed and the weight is recorded. A little bit further down the road, the truck pulls into another weigh station. If the truck weighs less, the regulating department knows something has changed. The states use this information to enforce tax and safety laws. The important aspect of this is that the people who are weighing the trucks don't need to know what's inside the truck or even who is driving the truck; they don't open up the truck and go through all the boxes. All they need to know is what it previously weighed and what it now weighs to enforce compliance. They use the weight to determine whether or not that truck is in compliance with the laws of the state. This is a similar concept with the transactions. The transactions themselves are actually hashed, and the hash is really just a digital description of the block, not the block itself. Once that digital description has been determined it is then transmitted to all of the nodes, each of the nodes run a calculation using this hash and compare it to the block to determine that the transaction has not been modified.

It's important to note that nodes don't know who the transaction parties are or anything about the transaction. This important feature of a decentralized network allows parties to conduct business without knowing anything about each other (which is why it is so popular with criminals, as mentioned before). Once everybody does the calculation and comes to consensus, then it can it be added to the ledger in the order it was received. A distributed ledger operates just like a real ledger, which means that transactions are input in the order they were executed, and if there is an error, it must be reversed out, not deleted. The ledger is considered to be an immutable source of transactions. When the transaction or block is stored, the destination financial institution will be alerted to the block, and because it was encrypted with the financial institution's public key, it can only be opened by the FI. If the block contained a transaction to pay off a mortgage for $2 million, the FI can be very sure that it is going to get that money because the distributed ledger has stored a record of the transaction that is irrefutable by the sender.

If we were to do this today via traditional means, say a wire, there will be some sort of centralized service, in this case the Fed, that would provide centralized services between the two organizations. One of the most important services that they would provide is to authenticate the remote institution. They would also indemnify the sending institution because it is taking responsibility for the authentication portion of the transaction. The most important part of any financial transaction is properly authenticating both sides of the transaction. FI A needs to know for sure that FI B is who it is sending money to. Without an authentication method, someone could impersonate the receiving FI and walk away with millions of dollars. In the decentralized network, authentication is done directly between two entities using a certificate authority. In this case, the authentication was handled with a public/private key pair. FI A was comfortable that the block could only be opened by FI B because the network authority that provided FI B's public key can be trusted. Another service a centralized network provides is normalization. In many transactions, FI A may be on a completely different kind of technology and platform than FI B. In order to transact business, the institutions must have a common language to speak between them. This service is usually facilitated by the central authority.

The third thing that a centralized service provides is funds protection through insurance. So, if for some reason FI B never got its million dollars, then the centralized provider would be responsible for recovering these funds. In a decentralized network, there is no mediator between transacting entities. The transaction is protected by the distributed network, as it can be stored on hundreds or thousands of different financial institution nodes that would provide proof of transmission for this transaction. The cooperative aspect of the technology is a game changer.

When a transaction has been sent to the ledger, each node validates the transaction and stores it in on its local ledger. Each ledger item is tied to the previous ledger item via hash. In this way, the distributed ledger acts just like a traditional ledger in that it stores the transactions in transactional order based on time and execution. Another important note is that a block is not limited to just one transaction, the block could contain a thousand different transactions or it can contain one transaction; it's whatever someone decides to put in their encrypted block and send.

Finally—and this is important—the entities that need the transaction information are identified through cryptography. And as will be discussed in Part IV, one of the people in your neighborhood that you're going to have to start looking at is a cryptologist. Cryptography is going to be the future and the distributed ledger is a very real reason that an FI might need a cryptographer in the future.

Now why is this valuable? Why does anybody care about using this distributed ledger? Well the first thing is, is that you have guaranteed availability of the stored data because if you think about, it's not just being put on one system. It's being stored on hundreds and hundreds of systems. Moreover, you can run applications (smart contracts) on all of these systems and you can be guaranteed an extremely high uptime due to the high level of redundancy on the network. You can also be guaranteed the extremely high uptime going very far into the future. The resilience of the network is directly related to the number of nodes that participate. The Achilles' heel of the platform is that if you knock out more than half the nodes, then the ledger cannot be trusted.

I know what you're thinking. You're thinking, “Hey, John, I cannot have my organization's secure and private data on some dudes laptop that is located in his basement running Bitcoin.” To overcome this concern, we have to understand the difference between a permissionless open blockchain and a permissioned private blockchain. At the core, whether it is permissioned or permissionless, the blockchain will operate the same as both are just different implementations of the same distributed ledger technology. A permissioned private distributed ledger or a private blockchain is a collection of nodes where all of the participating parties are vetted and certified before being allowed to participate in the network. An ATM network is a great analogy for a permissioned network. One can't just go out and put an ATM up without getting the proper permission and licensing. This approach is similar to how a permissioned distributed ledger is governed. Like any other network, there will have to be rules just like there are rules with ATMs. These rules, however, could be enforced by smart contracts. The smart contracts could determine if proper care is being taken when handling the private keys for the nodes, much in the same way issuers and processors are audited to determine if keys for an ATM are being handled correctly.

Permissioned Networks

Now we're going to see public permissioned networks. The first one is actually called Sovrin. It's been included in Hyperledger Project Indy, which we'll get to later. But R3, for example, is creating a private blockchain software called Corda. The credit union industry—and I'm proud to say, I was part of the genesis of this organization—has created something called CULedger, which is a private permissioned ledger that will only serve credit unions and their partners. In a private permissioned network, governance will be the most important concept, and it will be enforced by computer algorithms and real-world contracts that represent reputational risk, should they be broken.

Let's contrast the governance approach to a permissioned ledger with how rules are enforced in a permissionless network like Bitcoin or Etheruem. Why do people follow the Bitcoin and Ethereum rules? The answer is one of the many great points of a decentralized trustless network is that the network can perform self-validation by using the consensus mechanism of the millions of nodes connected to it, to validate that the software that is running on each node, and the ledger that is stored, is the correct version, and hasn't been modified in anyway. The risk is reduced because the computing power it would take to change just one node or even just one entry on a ledger doesn't exist yet. Even if one managed to magically change a transaction on a node, that person would still need to perform that same magic on more than half the networks, which is a daunting task, considering that the Bitcoin network consists of over 3.5 million nodes. Another reason that Bitcoin is resistant to hacking is because breaking it would be counterproductive to the entities that use it. In short, Bitcoin is protected because its users don't want to kill the goose that lays the golden bitcoins.

A new category of distributed ledger has emerged in the last year called a public permissioned network. In a public permissioned network there is a mixture of both algorithmic and human governance, which means contractual agreements that are also enforced by code.

Diversity is another important aspect of a distributed ledger network. A common belief is that if one were to attack the Bitcoin network and succeed at compromising a single node, they would have access to everything. But first, you have to understand how the data are actually encrypted. It's not one big encrypted block of data (see lessons learned from Mt. Gox in the previous paragraphs). It's a whole bunch of little encrypted blocks of data. Imagine that the data were on a piece of paper and you shredded it and you took each little shred and you put it in a safe, and then you took each safe and you gave them each a unique combination. For good measure, you took those safes and you distributed them to all of the nodes on the network, and then on top of that you created a bunch of empty safes, that looked exactly like the safes with the shards of information in them, also with unique combinations and distributed them among all of the nodes. This method of encrypting and storing the data makes it very difficult to find all of the data and put them back together. Breaking into a single node isn't going to take down the whole network, nor will it provide you access to all of the information on that node. A major function of the decentralized network is to track all of the elements of the data and make sure that it is distributed in a secure fashion.

A distributed network's security greatly benefits from the amount of diversity in its nodes. What I mean by that is that if every node had the same firewalls, networks, and ran on the exact same machines, the value of the targets to a hacker would go up greatly because the effort needed to get into all of the nodes, which is a necessity if you are going to infiltrate a distributed ledger, is greatly diminished by the lack of diversity. A hacker could defeat one computer operating system and use the same technique to compromise all of the other nodes and have access to everything. Because so many people are running their nodes in different environments with different firewalls, load balancers, IDS detectors, and different operating systems, it creates a diversity that helps to protect the network by making it a lower-value target due to the level of effort it would take to defeat so many different node configurations.

The data are actually encrypted using the most and current encryption standards. In this case, most of the data have been encrypted by elliptical Curve technology, which is more secure than Secure Socket Layers (the technology commonly used to secure websites) and, as I mentioned, it's broken up and spread across many nodes. The actual data are also backed up between all the different nodes and the transaction data are encrypted by the sender directly for the receiver. So you may be sitting around thinking, “Wow, this sounds like a giant database. This sounds great. I'm going to store all my data in it.” But that's not exactly what it's for.