Figuring out Blockchain's most useful applications

Blockchain is often discussed as if it is one single technology. But it is really a combination of several distinct features – decentralisation, distribution, cryptography, and automation – which are combined in different ways by different platforms. Some of these features may have benefits, while others may be unnecessary or even unhelpful – depending on the specific application. In this post, I consider whether and how these features may have different potential applications in financial services. Blockchain will only be truly useful in settings where one of more of these features solves a problem that existing technologies cannot.

It’s been over 10 years since Bitcoin first introduced blockchain technology to the world. Since then, the hype around its potential to transform everything (from tracking cargo, to combating the illicit diamond trade, to customs checks, and even a new religion) has followed the many peaks and troughs of bitcoin’s price. It has often been argued that the greater disruptive potential lies in blockchain technology, rather than Bitcoin or the many other crypto-assets which have followed in its wake. But a decade on, most of the activity around blockchain technology still appears to be about exploring its potential, rather than concrete examples of its deployment.

What does ‘blockchain’ really mean?

A blockchain is a type of distributed ledger which enables an agreed record of transactions (or other data) to be maintained and replicated across multiple participants, without the need for any central authority operating the system. The term blockchain refers to a specific process and data structure for recording and updating a ledger, by cryptographically linking a chain of ‘blocks‘ of transactions. The technology was first introduced with the invention of Bitcoin in 2008; this was ground-breaking as it demonstrated an entirely new way of thinking about the structures that underpin financial services, which had previously been based around trusted centralised intermediaries.

However, the Bitcoin blockchain was not designed as a general-purpose technology, but for just one specific application – peer-to-peer electronic cash (although there’s a separate discussion to be had around how well it really achieves this). By adapting this technology for a range of purposes, a whole industry has emerged developing platforms inspired by some of the core features of the Bitcoin blockchain, but adapting these to suit different scenarios.

Most of these platforms don’t include all of the same features of the original Bitcoin blockchain, and many don’t follow the same process of chaining blocks. But they generally all involve some degree of distribution – leading to the use of the broader term distributed ledger technology (DLT).

There’s no single type of DLT

DLT is not one single technology. It has become an umbrella term for a wide range of things. A reference to the use of DLT could mean a public platform like Ethereum, or something more like R3’s Corda platform which has been developed specifically for financial services, or Hyperledger Fabric, or Ripple’s RippleNet, or any number of other DLT platforms that have emerged over the past few years. Each of these takes a different approach, and as a result may be more or less suited to any particular application.

Most DLT platforms generally include some degree of four common features:

Decentralisation of control – who is directly involved in the process of maintaining and updating the ledger? In some systems this includes anyone, with all participants free to play an equal part in validating transactions and maintaining a ledger. In other systems, participants need to be ‘permissioned’ by a gatekeeper in order to participate. But the distinction is also more nuanced than just permissioned vs permissionless systems. There are some significant variations among permissioned systems – some allow all verified participants to participate equally, while others may include a specific subset of participants who have the right and responsibility to perform specific processes – eg validating transactions, or ordering blocks. In some cases certain key functions may even be performed under the control of a single, central entity.

Distribution of data – how is data shared and accessed? The original platforms involved copies of an identical ledger being stored by every participant. Whereas, in the interests of privacy, many DLT platforms being developed for financial services will involve each participant only storing data relating to their own transactions, meaning that no-one has a complete view of all transaction details.

The use of cryptography– including public-key cryptography for the signing of transactions to verify that someone submitting a transaction is entitled to do so. A range of cryptographic techniques are also sometimes used in consensus processes, for the chaining of blocks, and to hide data that needs to be kept private.

Automation – the creation of so-called ‘smart contracts‘ which can be used to automatically execute terms of an agreement, and initiate related transactions, without the need for any human intervention.

Each of these features has their own benefits and challenges, making them more or less suited to different scenarios. For example, many of the efficiency and scalability challenges which come from computationally-intensive mining processes, are only really applicable if you choose a fully decentralised and permissionless approach. Many DLT proposals in financial services do not follow this approach, and so don’t encounter these specific challenges.

Figure 1. Potential uses, benefits and challenges of blockchain features

What are the potential applications of DLT?

DLT platforms vary in the way they implement these features. Simply saying that a project is using DLT (or blockchain) doesn’t give much insight into what approach is really being used. It is usually necessary to dig a little deeper into the design choices, and to consider when each of these features might be useful.

There will be many scenarios where decentralisation is not needed at all, for example where there is a natural central party, or a small group of trusted parties. But, decentralisation may also be beneficial (or even necessary) in other situations, for example where there is no existing central party, a lack of trust in existing intermediaries, or where there is an ‘adversarial environment‘. This is more likely in scenarios that cross boundaries (national boundaries, or boundaries between industries) or for applications which are providing a shared utility. One promising area is cross border payments where there is often no single trusted central party, and where existing solutions can be slow and costly. Or trade finance where the flows of goods and funds are separated by time, space and jurisdiction; DLT could provide a unified record which is quick and easy to verify, and encourage standardisation.

Distribution of data can enable every participant to refer to the same record (a single version of the truth), and could have benefits in simplifying complex reconciliation processes. But full data distribution, where all participants maintain their own identical copies of the same ledger, is unlikely to be desirable in many financial services applications, given the obvious data privacy and security challenges this presents.

In domestic financial services, where trusted intermediaries often already exist, much of the potential benefit of DLT could come from the use of cryptography and the automation of smart contracts. Many of the DLT platforms being developed for financial services therefore limit the amount of decentralisation and distribution, leading to platforms that are relatively centralised, but which still benefit from automation and the use of cryptography. Automation (eg via smart contracts) could enable the creation of ‘smart’ securities, where settlement and payment of funds is automated, reducing the need for certain back and middle office functions; but it’s not obvious there’s any need for decentralisation and distribution in this scenario.

Of course, technology alone (DLT or otherwise) will not automatically remove all the existing frictions in any process; many of these frictions will go beyond a question of technology.

Uncoupling the features of DLT

So, do all of these features need to come as a package? Combining some of the features of DLT will be necessary in some scenarios (eg if you’re seeking high-levels of resilience, you may need to decentralise control and distribute data, to avoid single points of failure). But if you want the automation benefits of smart contracts, do you really need to decentralise control, or distribute data, at all? Why not just deploy smart contract functionality on a centralised ledger?

Where the features of decentralisation and distribution are not needed, a natural avenue for future developments may be centralised systems (ie systems that are controlled and governed by a single entity), which make use of smart contract functionality, or the immutability features of cryptography, while removing the need for decentralisation or distribution. If there is no decentralisation or distribution, this is probably no longer a ‘DLT’ in the strict sense of the term, but could still lead to significant efficiency benefits for a number of applications in financial services – DLT may simply be the catalyst in producing these benefits.

Alternatively, finding scenarios where the decentralisation or distribution features are truly beneficial will be key to whether the technology will eventually live up to some of its original, more transformative, potential. Otherwise it risks remaining as a solution in search of a problem.