Building on Blockchain part two - the anatomy of a Distributed Ledger

29 March 2016
Andrew Elmore

The blockchain we described in Part One of this series is a technical construct - nothing about it limits it to working with distributed ledgers or even financial services as we have placed no constraints on the content.

On the plus side, that means the investment in building the blockchain infrastructure can be recovered across many different business lines and use cases. While a pluggable architecture for consensus algorithms and other constituents makes sense, in practice it is highly likely that only a small set will ever be needed as participants move to adopt common approaches. New mechanisms are far more likely to come from evolution than proprietary fragmentation.

Equally, there is no real advantage of a proprietary implementation of the core technology. The behaviour of the blockchain is defined by contract and hence fixed for all parties. Although no such definitive implementation exists today, the reusability we're seeing between different clients suggests that it is inevitable.

Brand New Chassis, Same Engine

The content of a block and its processing, is a different matter however. Looking across our client-base, no 2 clients store their data in the same structures. If we are to have a single ledger used (and understandable) by all parties, we need to adopt a common structure. That structure *is* domain and use-case dependent and, once an organisation has a blockchain infrastructure in place, populating and processing this content is where the bulk of the adoption effort will be consumed.

We have been here before though - the financial services industry is extremely good at defining standards for inter-party communication (it must be - how else would we have so many of them?). At C24 we expect standards to evolve in the same way for blockchain content - while there will always be pockets of proprietary specs for small groups of counterparties, in the main in order to interact more widely clients will need to adopt the protocols in-use by the rest of their marketplace.  

The Case for Change

None of the technologies in our distributed ledger are new - most have been around for 10s of years. The novel step in Bitcoin was to use  sigificant quantities of compute effort to establish trust in a network, and that aspect isn't even relevant to our financial services distributed ledger. What Bitcoin has done however is to prove how effectively such an approach can work, and in an era of challenger banks and regulatory revolution the potential for efficiencies that blockchain can bring can no longer be ignored.

All of which still leaves us with the historical problems we've had with communication - message formats. For organisations to be able to process the messages in a blockchain they need to be able to understand them. Our need for message standards to ensure interoperability is the same in the new world as it was in the old.

Equally important is managing evolution in blockchain technology. Recent years have seen cryptographic algorithms and hash functions fall out of favour as cryptanalysis has found weaknesses in them. Dramatic increases in computing power have required users to adopt longer keys in order to maintain the same effective level of security. These events will continue to occur and it will become important to close blockchains and start new ones periodically to allow the introduction of new technology and to avoid older, weaker parts of the blockchain being compromised.

It is ultimately however all the things that such distributed ledgers will enable which will deliver the real quantum leap.