It’s been a big month for blockchain.
- The Hyperledger consortium released the Fabric platform, a state-of-the-art configurable distributed ledger environment including a policy editor known as Composer.
- The Enterprise Ethereum Alliance was announced, being a network of businesses and Ethereum experts, aiming to define enterprise-grade software (and evidently adopt business speak).
- And IBM launched its new Blockchain as a Service at the Interconnect 2017 conference in Las Vegas, where blockchain was almost the defining theme of the event. A raft of advanced use cases were presented, many of which are now in live pilots around the world. Examples include shipping, insurance, clinical trials, and the food supply chain.
I attended InterConnect and presented my research on Protecting Private Distributed Ledgers, alongside Paul DiMarzio of IBM and Leanne Kemp from Everledger.
Disclosure: IBM paid for my travel and accommodation to attend Interconnect 2017.
Ever since the first generation blockchain was launched, applications far bigger and grander than cryptocurrencies have been proposed, but with scarce attention to whether or not these were good uses of the original infrastructure. I have long been concerned with the gap between what the public blockchain was designed for, and the demands from enterprise applications for third generation blockchains or "Distributed Ledger Technologies" (DLTs). My research into protecting DLTs has concentrated on the qualities businesses really need as this new technology evolves. Do enterprise applications really need “immutability” and massive decentralisation? Are businesses short on something called “trust” that blockchain can deliver? Or are the requirements actually different from what we’ve been led to believe, and if so, what are the implications for security and service delivery? I have found the following:
In more complex private (or permissioned) DLT applications, the interactions between security layers and the underlying consensus algorithm are subtle, and great care is needed to manage side effects. Indeed, security needs to be rethought from the ground up, with key management for encryption and access control matched to often new consensus methods appropriate to the business application.
At InterConnect, IBM announced their Blockchain as a Service, running on the “Bluemix High security business network”. IBM have re-thought security from the ground up. In fact, working in the Hyperledger consortium, they have re-engineered the whole ledger proposition.
And now I see a distinct shift in the expectations of blockchain and the words we will use to describe it.
For starters, third generation DLTs are not necessarily highly distributed. Let's face it, decentralization was always more about politics than security; the blockchain's originators were expressly anti-authoritarian, and many of its proponents still are. But a private ledger does not have to run on thousands of computers to achieve the security objectives. Further, new DLTs certainly won't be public (R3 has been very clear about this too – confidentiality is normal in business but was never a consideration in the Bitcoin world). This leads to a cascade of implications, which IBM and others have followed.
When business requires confidentiality and permissions, there must be centralised administration of user keys and user registration, and that leaves the pure blockchain philosophy in the shade. So now the defining characteristics shift from distributed to concentrated. To maintain a promise of immutability when you don't have thousands of peer-to-peer nodes requires a different security model, with hardware-protected keys, high-grade hosting, high availability, and special attention to insider threats. So IBM's private blockchains private blockchains run on the Hyperledger Fabric, hosted on z System mainframes. They employ cryptographic modules certified to Common Criteria EAL 5-plus and others that are designed to FIPS-140 level 4 (with certification underway). These are the highest levels of security certification available outside the military. Note carefully that this isn't specmanship. With the public blockchain, the security of nodes shouldn't matter because the swarm, in theory, takes care of rogue miners and compromised machines. But the game changes when a ledger is more concentrated than distributed.
Now, high-grade cryptography will become table stakes. In my mind, the really big thing that’s happening here is that Hyperledger and IBM are evolving what blockchain is really for.
The famous properties of the original blockchain – immutability, decentralisation, transparency, freedom and trustlessness – came tightly bundled, expressly for the purpose of running peer-to-peer cryptocurrency. It really was a one dimensional proposition; consensus in particular was all about the one thing that matters in e-cash: the uniqueness of each currency movement, to prevent Double Spend.
But most other business is much more complex than that. If a group of companies comes together around a trade manifest for example, or a clinical trial, where there are multiple time-sensitive inputs coming from different types of participant, then what are they trying to reach consensus about?
The answer acknowledged by Hyperledger is "it depends". So they have broken down the idealistic public blockchain and seen the need for "pluggable policy". Different private blockchains are going to have different rules and will concern themselves with different properties of the shared data. And they will have different sub-sets of users participating in transactions, rather than everyone in the community voting on every single ledger entry (as is the case with Ethereum and Bitcoin).
These are exciting and timely developments. While the first blockchain was inspirational, it’s being superseded now by far more flexible infrastructure to meet more sophisticated objectives. I see us moving away from “ledgers” towards multi-dimensional constructs for planning and tracing complex deals between dynamic consortia, where everyone can be sure they have exactly the same picture of what’s going on.
In another blog to come, I’ll look at the new language and concepts being used in Hyperledger Fabric, for finer grained control over the state of shared critical data, and the new wave of applications.
