Blockchain: should we all play?

I’m attending Open Source Summit 2017* this week in L.A., and went to an interesting “fireside chat” on blockchain moderated by Brian Behlendforf of Hyperledger, with Jairo*** of Wipro and Siva Kannan of Gem.  It was a good discussion – fairly basic in terms of the technical side, and some discussion of identity in blockchain – but there was one particular part of the session that I found interesting and which I thought was worth some further thought.  As in my previous post on this topic, I’m going to conflate blockchain with Distributed Ledger Technologies (DLTs) for simplicity.

Siva presented three questions to ask when considering whether a process is a good candidate for moving to the blockchain.  There’s far too much bandwagon-jumping around blockchain: people assume that all processes should be blockchained.  I was therefore very pleased to see this come up as a topic.  I think it’s important to spend some time looking at when it makes sense to use blockchains, and when it’s not.  To paraphrase Siva’s points:

1. is the process time-consuming?
2. is the process multi-partite, made up of multiple steps?
3. is there a trust problem within the process?

I liked these as a starting point, and I was glad that there was a good conversation around what a trust problem might mean.  I’m not quite sure it went far enough, but there was time pressure, and it wasn’t the main thrust of the conversation.  Let’s spend a time looking at why I think the points above are helpful as tests, and then I’m going to add another.

Is the process time-consuming?

The examples that were presented were two of the classic ones used when we’re talking about blockchain: inter-bank transfer reconciliation and healthcare payments.  In both cases, there are multiple parties involved, and the time it takes for completion seems completely insane for those of us used to automated processes: in the order of days.  This is largely because the processes are run by central authorities when, from the point of view of the process itself, the transactions are actually between specific parties, and don’t need to be executed by those authorities, as long as everybody trusts that the transactions have been performed fairly.  More about the trust part below.

Is the process multi-partite?

If the process is simple, and requires a single step or transaction, there’s very little point in applying blockchain technologies to it.  The general expectation for multi-partite processes is that they involve multiple parties, as well as multiple parts.  If there are only a few steps in a transaction, or very few parties involved, then there are probably easier technological solutions for it.  Don’t increase the technical complexity of a process just because you’ve got a cool technology that you can throw at it******.

Is there a trust problem within the process?

Above, I used the phrase “as long as everybody trusts that the transactions have been performed fairly”******.  There are three interesting words in this phrase*******: “everybody”, “trusts” and “fairly”.  I’m going to go through them one by one:

• everybody: this might imply full transparency of all transactions to all actors in the system, but we don’t need to assume that – that’s part of the point of permissioned blockchains.  It may be that only the actors involved in the particular process can see the details, whereas all other actors are happy that they have been completed correctly.  In fact, we don’t even need to assume that the actors involved can see all the details: secure multi-party computation means that only restricted amounts of information need to be exposed********.
• trusts: I’ve posted on the topic of trust before, and this usage is a little less tight than I’d usually like.  However, the main point is to ensure sufficient belief that the process meets expectations to be able to accept it.
• fair: as anyone with children knows, this is a loaded word.  In this context, I mean “according to the rules agreed by the parties involved – which may include parties not included in the transaction, such as a regulatory body – and encoded into the process”.

This point about encoding rules into a process is a really, really major one, to which I intend to return at a later date, but for now let’s assume (somewhat naively, admittedly) that this is doable and risk-free.

One more rule: is there benefit to all the stakeholders?

This was a rule that I suggested, and which caused some discussion.  It seems to me that there are some processes where a move to a blockchain may benefit certain parties, but not others.  For example, the amount of additional work required by a small supplier of parts to a large automotive manufacturer might be such that there’s no obvious benefit to the supplier, however much benefit is manifestly applicable to the manufacturer.  At least one of the panellists was strongly of the view that there will always be benefit to all parties, but I’m not convinced that the impact of implementation will always outweight such benefit.

Conclusion: blockchain is cool, but…

… it’s not a perfect fit for every process.  Organisations – and collections of organisations – should always carefully consider how good a fit blockchain or DLT may be before jumping to a decision which may be more costly and less effective than they might expect from the hype.

---

*was “LinuxCon and ContainerCon”**.

**was “LinuxCon”.

***he has a surname, but I didn’t capture it in my notes****.

****yes, I write notes!

*****this is sometime referred to as the “hammer problem” (if all you’ve got is a hammer, then everything looks like a nail)

******actually, I didn’t: I missed out the second “as”, and so had to correct it in the first appearance of the phrase.

*******in the context of this post.  They’re all interesting in the own way, I know.

********this may sound like magic.  Given my grasp of the mathematics involved, I have to admit that it might as well be*********.

*********thank you Arthur C. Clarke.