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.
No comments:
Post a Comment