The world is awash in facts, hype, lies and confusion around blockchain and cryptocurrencies. Everyone from CIOs to retired grandmothers to mafia bosses are trying to understand how this new technology works and how to become a part of it. There is plenty of credible and not-so-credible information on what exactly the technology is and how it is used. According to Gartner, Blockchain was the second most searched term on Gartner.com in 2017, having increased 400% in the previous 12 months.
The purpose of this article is to not cover that ground…again. It is to provide IT practitioners with a real use case for Blockchain in an application other than questionable Initial Coin Offerings. Our assumption at this point is that the reader is an IT professional and understands the difference between Blockchain as a technology and how it enables cryptocurrencies.
There has been significant research by the Fortune 500 on ways to apply the distributed, secure, and immutable capabilities of Blockchain to common business workflows. From our field experience, we see 3 types of non-crypto PoCs that are becoming more common:
Supply Chain Transparency —retailers and/or healthcare systems tracking products all the way back to the source for accountability purposes, for example tracing salmonella back to a specific farm or a hospital tracking spoiled medications
Accelerating Procurement — enterprises shortening the time and cost of the procurement lifecycle by disintermediation of contract and PO approvals
Financial Reconciliation — financial institutions implementing more robust immutable ledgers for reconciliation of enormous transaction batches
We have chosen supply chain transparency to demonstrate practical application of Blockchain and will be using Hyperledger Fabric for our technology stack. Our case study will involve a fictitious hospital called Main Street Hospital and a pharmaceutical manufacturer called Acme Meds.
Ledgers | A Brief Intro
Before really diving into how we can use Fabric to fulfill the goals of our case study, let’s review a few of the conceptual underpinnings. First up is the notion of a ledger. A ledger is an immutable, append-only log of transactions taking place between various parties, and it is the core abstraction at the heart of all blockchains. A Fabric created blockchain is no different. The Fabric network you’ll be creating will encode a ledger of all occurring transactions and the order in which they happen. This ledger will be public to all permissioned parties, and will also be tamper-proof (meaning that no party will have the ability to add, delete or modify ledger entries once they have been recorded). Of course, this ledger will also need to be fault-tolerant.
Fault Tolerance | Consensus
The question of how to make the ledger fault-tolerant requires a brief discussion about consensus, and the protocols that make consensus possible. Storing and modeling the ledger requires little more than a linked list with each transaction having a pointer to the transactions occurring before and after it. But how were all of these transactions appended in the first place? Don’t forget, each one of the involved parties has their own replicated version of the ledger, and somehow, all of the parties must maintain matching versions of the ledger even in the face of potentially thousands of concurrently proposed transactions (all wanting to be *the* next transaction appended to the ledger). Consensus is the answer and it is what allows all honest parties to agree on which transactions to select for addition to the head of the ledger. Consensus also ensures that all honest parties eventually learn about which transactions were selected, and that each selected transaction was actually proposed by one of the involved parties. So for each new transaction added to the ledger a new round of consensus must be performed.
There are many different sorts of consensus protocols that exist. For the sake of brevity, it is instructive to divide them into two classes. Compute intensive consensus protocols like Proof-of-Work and Proof-of-Stake are used in the context of public blockchains where the identities of the participants are not known. However, if the blockchain is private (meaning that the identities of all participants are known and authenticated), less intensive consensus protocols such as practical byzantine fault-tolerant voting or even human signatures can be used. By virtue of Fabric networks being permissioned, higher transaction throughput rates and performance are possible.
So how might these rounds of consensus actually interleave with real world events happening in the context of our supply chain case study?
Stop Sending Us Bad Drugs
Imagine that we are tracking a pharmaceutical shipment from Acme Meds, through a few transportation intermediaries, and ultimately to the Main Street Hospital. Ensuring drug safety for end-users is of critical importance, so shipments of this classification are often subject to stringent constraints with respect to resting temperature, ambient UV exposure, humidity, etc. The past few shipments of pharmaceuticals to the Main Street Hospital have had to be disposed of because some of their transport requirements were violated while in transit. So the hospital decides to leverage the blockchain and requires that Acme Meds and all other parties involved in the manufacture and transport of their pharmaceutical orders maintain a peer presence within their Fabric network.
Main Street Hospital then collaborates with the manufacturers to install their IoT sensors on each shipment. The sensors are wired together to conduct a Byzantine fault-tolerant consensus protocol so as to ensure that the readings can’t be corrupted by malfunctioning or compromised sensors. These readings are taken with some regularity, and with each reading the timestamp, sensors’ readings, and a hash of the prior record are all signed to establish authenticity before posting the record as a transaction to the Fabric network’s ledger. At each handoff of the shipment between transportation intermediaries leading up to the final delivery at the hospital, a change-of-custody certificate is signed along with the timestamp and hash of the prior record before being appended to the Fabric network’s ledger. In this manner the hospital will now be able to know instantaneously when a particular shipment is spoiled, and who had custody of the shipment at that point in time.
Be sure to check back for the next article where we will be standing up an actual Fabric network to support our supply chain scenario!
— Darren Hoch | Partner, Emerging Technologies | Stone Door Group
— Harrison Perl | Architect, Emerging Technologies | Stone Door Group
About the Author
Harrison Perl is a Stone Door Group consultant with expertise in Ansible automation and cloud native solutions. He specializes in working with growth organizations, open source initiatives, and implementing Agile and DevOps methodologies. To speak with more consultants like Harrison, drop us a line at letsdothis@stonedoogroup.com