Tag: cryptocurrency

If you are a bank, it must be very difficult it to work out what your strategy on the blockchain is. On the one hand, banks and accounting firms and analysts are saying that the blockchain is going to disrupt everything, but on the other hand it’s not entirely clear what any of these commentators actually mean. Here’s an example. A big story in Forbes on the investments in Chain.com is headlined “Bitcoin’s Shared Ledger Technology” and then goes on to point out that the company in question is not using Bitcoin’s shared ledger technology:

Rather than using the public Bitcoin blockchain, it uses what is called a permissioned ledger

[From Bitcoin’s Shared Ledger Technology: Money’s New Operating System – Forbes]

The implementation here is a blockchain, but it’s not the blockchan (which most people take to mean the public Bitcoin blockchain). Here’s another example from last week. A cover story from Bloomberg Markets, featuring Digital Asset Holding’s Blythe Masters, one of the most important women in finance. The cover story says that “the blockchain” will disrupt everything but in the article Blythe refers to private blockchains (i.e., again not “the blockchain”) and then the article points out that her company bought Hyperledger, which uses a different kind of consensus method to create shared private ledgers.

It might be more accurate, I suppose, to rewrite the headline to say that “replicated decentralised shared ledger technology has the potential to revolutionise some parts of the finance industry and one part might be clearing and settlement because they are hopelessly inefficient” but I can see this is not as catchy. But let’s take on board that it is correct. It then leads us to pose a rather obvious question:

If clunky old procedures haven’t been replaced by computers by now, why would they be replaced by blockchain computers in the near future?

[From Blockchain for Banks Probably Can’t Hurt – Bloomberg View]

This is a very good question and it wasn’t really answered in those articles, so I thought that I would mull it over in a coffee break to see if I could come up with an answer that makes sense to me and has some consistency. The place I began was the not immediately obvious world of multi-application operating systems for smart cards. I remember that many years ago I was talking to one of our clients in the financial services world and I was observing that despite the existence of multi-application smart card platforms such as Javacard it was extremely rare to find schemes in place where applications from more than one issuer were side-by-side on the same card (as was the original dream of the smart card world). I asked our client why they had chosen to go down the multi-application route even though all of the applications were going to come from the same financial services institution. There were two parts to the answer. First, by using something like Javacard rather than a proprietary operating system they hope to reduce their development costs. Second, by using something like Javawcard they hoped to stop applications from interfering with each other, reading each other’s data or worse still messing up each other’s data. They weren’t worried about dedicated teams of crack Eastern European hackers wrecking the code, they were worried about their own development teams.

This imperfect analogy I think provides a window into the thinking implied in the Bloomberg article. Yes, it is perfectly reasonable to observe that all of the financial institutions working together could have simply put some money into a pot and built a big database that they could all connect to. However the history of such enterprises is littered with huge failures and fraught with large-scale risk. In the decentralised alternative, each institution can build applications that use its copy of the ledger to do whatever they want, safe in the knowledge that whatever they do won’t subvert what other institutions (or indeed other departments within their own institution) want to do with their copy of the ledger.

You can take this argument even further: why use a private ledger? Well, even if the ledger is wholly private it might still add resilience and transparency and some kind of standardisation that make it appealing in the round. Instead of putting all of the eggs in one basket, a more innovative and experimental environment is created where different companies and departments can work together in a safe way. Of course there will need to be some agreement on the language for ledger entries and so forth but I’m sure in these modern times it ought to be possible to create some sort of XML dictionary that can be inspected, expanded and exploited effectively.

All of this, of course, doesn’t answer the question as to why you would want to use a blockchain even if you decide you do want to use a shared ledger. That’s a much more difficult question to answer and while it’s not really the topic of this post (I will return to it soon, however), I think it is fair to observe that modern cryptography and modern computing might come together to deliver shared ledgers using protocols far more efficient for some contexts (and I suspect that securities settlement might be one of them) than the permissionless proof-of-work block chain that was designed to support the very specific use case of a censorship-resistant value transfer system.