Last week, IBM announced an expansion of its blockchain capabilities to fully support secure networks for whatever uses its customers find for the blockchain technology. Key features include support on IBM Cloud for developers, management of the environment aimed at rapid deployment via IBM Bluemix, and enhancements to the Linux Foundation open-source HyperLedger Project code for those seeking to implement blockchain use cases at least partly outside the IBM software/services umbrella. My initial take is that IBM is laying a solid foundation for blockchain use. More important, I find that it is likely that, with help like this, customers of blockchain technology may well find that it delivers real value-add in limited but nevertheless concrete ways. That is, blockchain implementations with foundations such as IBM’s can deliver much less than what its most enthusiastic proponents would claim, but can provide it more reliably and immediately than, say, data lakes at this stage in its lifecycle.
It Begins With the Blockchain Technology
At present, the word “blockchain” is surrounded by clouds of hype and techie jargon that make its nature unusually difficult to understand. However, reading between the lines, it appears that blockchain technology has two key new approaches:
1. A “blockchain” data unit that lends itself flexibly to use in medium-scale applications involving many-to-many business-to-business processes, such as “smart contract” management or business-to-business asset exchange involving “clearing” and the like.
2. A fully-replicated distributed database that allows each participant a full view of the “state” of the “blockchain” data and automates some of the security involved, e.g., the ability to block a single “bad actor” from altering the data by requiring “consensus” among all copies of the replicated data as to the validity of a new transaction.More specifically, a typical “blockchain” implementation creates a string of data together with the transactions on it, each part of the string being a “block” containing a transaction and the resulting data, and each block containing a “hash” of the previous block, in effect a backward pointer to the transaction/data block previous in time/sequence to this one. Thus, each blockchain contains its own readily accessible “audit trail”, copied to every node and hence every user.
On the networking side, as noted, the distributed database uses pure peer-to-peer networking with no central manager or “master record”. Thus, more or less, according to the description in Wikipedia, if one transaction comes in on one node saying the resulting block should be as follows and another disagrees, all nodes need to look at what all the other nodes are saying (step 1) and determine what the “consensus” is (step 2). They can then all independently create a new block, because they will all come to the same conclusion. The result is that if one “bad actor” comes in and tries to corrupt the data, the consensus will reject that attempt every time it happens, no matter what the alias of the bad actor or how many times the bad actor tries, or even if the bad actor keeps switching the node of access.
The limitations of blockchain technology also come from these two new approaches. For one thing, the “blockchain” data unit’s use of a “chain” approach to data access means that the database is simply not as scalable in most if not all cases. There is a reason that most databases optimize direct access to each data unit: the time taken to go backwards through the whole chain as a series of “reads” is much greater than the time for going directly to the data unit at the end of the chain. IBM clearly signals this limitation on scalability by noting its ability to scale to “thousands of users” – laughably small for a consumer application, but quite appropriate for many business-to-business applications.
On the networking side, the requirement of “consensus” can significantly slow the process of committing a transaction – after all, one of the participants may not be responsive at one time or another. Therefore, blockchain technology is less appropriate where the fastest possible transaction performance is needed, and more appropriate in automating existing approaches such as “clearing” (netting out transactions between businesses and then having each participant pay/receive the differences), which can take up to 3 days in some banking apps.
What Users May Wish to Watch Out For
As noted above, blockchain technology can deliver real benefits, particularly in security, speed-to-perform, and flexibility/ease of implementation and upgrade, for business-to-business many-to-many applications – but it probably will require extra care in implementation. One area that I believe users should consider carefully is the long-term scalability of the blockchain technology. It should be possible to get around the limitations of a blockchain data unit by writing to a “blockchain” veneer that looks like a blockchain but acts like a regular database (in fact, this is what a relational database does at the storage level). However, this means that the implementation must use such a veneer religiously, and avoid third-party code that “hard-codes” blockchain access.
A second implementation detail that I recommend is pre-defining the blockchain technology’s links to existing systems. In many cases blockchain data will need to be kept in sync with parallel updates going on in IT’s existing databases. It’s not too early to begin to think how you’re going to do that. Moreover, the blockchain approach is not a security cure-all, and therefore requires careful integration with existing security systems.
A third implementation “key decision” is whether to use some version of Bitcoin in implementing a blockchain solution. I would recommend against this. First, digital currencies modeled after Bitcoin have been shown in the real world to be vulnerable to “gaming the system”; in economic terms, unlike a good paper currency, it does not serve as a good “store of value”. Second, Bitcoin has scaled beyond the “thousands of users” consensus needed for the business-to-business apps discussed here – but, in order to do so, it is now using a very significant part of the resources of the World Wide Web. If you use Bitcoin, you must connect to that very large Bitcoin implementation, which will mean that your network performance may well be adversely impacted by constant demands for consensus from the Internet.
A Different Viewpoint
Interestingly, Steve Wilson of Constellation Research has recently come out with a strongly worded argument against business use of blockchain technology, with two key arguments: (1) It actually adds nothing to corporate security; and (2) It does nothing that the business’ existing database can’t do.
While I find myself in agreement with many of his technical viewpoints, I find that he overstates the effectiveness in the use case I have described above of present corporate security and of existing business databases. Over the years, such functions as contract management and “episode management” in health care have been relatively ill-served by being lumped in with the rest of corporate security and implemented typically in relational databases. The blockchain model is more like an “accounting ledger”, and the ability to use such a model in business-to-business interactions as well as for security inside and outside each participating business is a key long-term source of usefulness for today’s businesses. To put it another way, the trend in business is away from the “one size fits all” database and towards “databases for specific purposes” that can add additional “domain” security and “ease of development”.
All in all, as long as businesses are savvy about implementation, there does appear to be an important use case for blockchain technology. In which case, support like IBM’s is right on the mark.