Blockchain is Not One Thing
In my role at Hashed Health, I have spent a great deal of time answering the question, “What is Blockchain?” My answer has, of course, evolved over the past 3 years of working with enterprises in the healthcare industry. As a means of introducing this series on distributed ledger technology, I thought it helpful to return to this subtly complex question.
The question appears simple on its face, seemingly asking for a technical description of a new piece of network stack. But, the origins of this technology, its initial uses, as well as the fever-pitched hype cycle shift the question. Instead of a technical description, all to often we get an ideological, often polemical, of what blockchain is and ought to be.
Blockchain’s almost mythical origins with a mysterious, pseudonymous creator is just the starting point. Cryptocurrency can rightly be described as a movement with various political and social points of view. The clash of these points of view can be witnessed in the vociferous debates that have preceding cryptocurrency forks, with attending claims of purity or faithfulness to the vision of Satoshi or to the true ideal of Ethereum. As an historian in an earlier career, I see eerie similarities, whether it’s riots sparked by truly obscure points of theology or the entire history of Western theology as a debate over who is the most correct and authentic interpreter of Paul. And just like religious movements, blockchain has its own efforts to establish orthodoxy, naming as heretical the very idea of “enterprise” or “permissioned” blockchains.
But if we hope to bring practical clarity to enterprise decision-makers, we need to set aside ideology and find a more useful framework for discussion.
When is a thing a thing?
When trying to classify something, we often fall back on notions of essence. We seek to identify the essential trait that makes a thing a thing and not something else. This essentialism is at the heart of the ideological approach to understanding blockchain. Its seems a natural approach; it worked for Linneaus after all.
But there is a better approach for our purpose here. Rather to try to identify a single defining characteristic (necessary and sufficient trait or even a sine qua non), we should approach blockchain as a family of related technologies. And like all families, there are resemblances. Formally known as polythetic classification, a class whose members share a range of traits without any particular subset being essential or determinative.
Blockchain and Distributed Ledger Technology (DLT), a phrase specifically coined to side-step purity debates, should be explored in its varieties, similarities and differences. While these terms have largely become synonymous in the enterprise context, there are clear delineations in architectural approaches taken by different blockchain/DLT technologies that demand greater examination. The task is descriptive and not definitive, to document variations and explore the impact they have on how these technologies can be used in business settings. Put more simply, blockchain is not one thing.
A Family Portrait
By 2019, there are a dizzying array of blockchain protocols, platforms and frameworks for all purposes and uses. The resemblance of these technologies is that they are all distributed systems which utilize cryptography facilitate trusted multi-party interaction. There are now so many “proofs-of-______” that I've frankly lost count. Rather than attempt to catalog them like some modern digital naturalist, I want to talk about two broad branches of the blockchain and DLT family.
This broad dichotomy is useful for many reasons. Its helpful in bringing into sharper focus topics which are vital to enterprise adoption of these technologies, namely privacy, scale and operating models. It is also find a good fit between technical architecture and the problem types that can best be addressed. Unfortunately, this later goal is all too rare. Our industry is rife with “shoe-horning” any and all business problems into a single technical paradigm. I’ve often encountered skepticism of blockchain as technology ins search of a problem. I think that is an apt description of the shoe-horn approach and not the range of technologies itself. A tonic to that skepticism is that we can map a range of solution design patterns to the technology that offers the best fit.
I want to briefly explore fully replicated ledgers in contrast to what I call reciprocal ledgers. Of course, no article on blockchain would be complete without the required node image, the mainstay of blockchain startup logos. But the graphic here is helpful in drawing the main distinction between these branches of the family tree.
Blockchains and DLT’s are broadly characterized by networks of “nodes,” independent servers which provide storage of the “ledger” and a protocol for communicating changes to that ledger. The distinction between a fully replicated ledger and a reciprocal ledger system deals with just what these nodes are doing and what they record.
Satoshi’s blockchain, and the legion of similar followers, are all fully replicated ledgers. That is, the node network broadcasts and spreads transactions across the network and ledger updates are fully replicated by each and every node (eventually). This feature trades off privacy for the ability for anyone to verify the state of the ledger and the validity of any individual transaction. This transparency is key to the decentralized models that are also part of the design. In concert, they help achieve the design goals of an open, peer-to-peer, censorship-resistant, tamper-proof, trustless transactional system.
In the context of a permissioned blockchain network (one in which the identity of nodes are known and participation is subject to some form of authority), the original trade-off in the fully replicated ledger model makes less sense as the problem space has significantly shifted. I am not arguing that there cannot be other rationales, as will be explored in other pieces. Rather, its just that the core rationale fails to apply.
By contrast, reciprocal ledgers are a rare thing, with fewer examples to point to. However, they are distinct in an important way. These systems do not share the ledger across the network. Nodes still primarily serve the same function, as ledger storage and as a communication point in the network. However, the ledgers they store are specific only to the transactions committed by the node’s owner. Transactions are reciprocally recorded on the ledgers only of the parties themselves. No other copy of that transaction exists, nor does any other node receive any traffic from those transactions. The concept of a global ledger is an abstraction, an amalgamation of all the transaction that have ever crossed the network. Here, the central trade-off is anonymity (in a practical sense, pseudonymity) for both privacy and scalability. Despite the lack of global transparency, cryptography can be brought to bear to guarantee validity at the individual transaction/asset level. The end result is a design that achieves trusted, private, yet interoperable transactional systems.
A Path Forward
Climbing always requires and edge, a handhold. I've carved out here a very simple distinction but which I believe can be climbed to explore more and deeper characteristics of these new systems, from the enterprise context. Privacy, scalability, network governance, modeling languages are all topics I look to explore.
