Security Think Tank: Blockchain is not for everyone, so look carefully before you leap

With any technology, how it is best used, or if indeed it is the best technology to use, depends on the particular problem of use case we are trying to solve. 

In its most basic form, blockchain is a mechanism for recording and protecting the integrity of transactions or events. Events are formed into blocks of event data and a hash is created on each new block of data, including the hash of the previous block. 

In this way, the cryptographic hash of a block is dependent on the transactions recorded in all previous blocks, so any change in any event ever can be detected. This is then turned into what we normally think of as a blockchain by having many parties take part in the system, each writing their own version of the blockchain and using a consensus protocol to ensure all the writers agree on the hashes created for each block. 

It is this that turns a simple local integrity mechanism into a distributed ledger, adding resilience by having many independent copies and the ability for multiple mutually untrusting parties to have confidence in the data recorded. 

The blockchains used for most cryptocurrencies are typically publicly accessible, so anyone can be a “writer”, maintaining their version of the blockchain, and anybody can be a “reader”, able to view and verify the transactions.

In some cases, for example to maintain a record of transactions across multiple sites of the same organisation, it may be necessary to limit access to those who can read and/or write the blockchain. This then becomes a permissioned blockchain.

Blockchain is therefore appropriate where:

• Transactions or events need to be recorded and their integrity maintained.
• Where the information is written by multiple parties, or the record needs to be replicated (for resilience, for example).
• Where there is no trusted third party acceptable to all the writers.

If not all the writers are known, then you would need a permissionless blockchain. If the data needs to be publicly verified, then a public permissioned blockchain is required, and if not, a private permissioned blockchain. If these cases are not satisfied – for example, a trusted third party can be agreed – then blockchain is probably not a suitable solution.

The classic use case for blockchain is, of course, cryptocurrencies, which are typically permissionless. Other potential use cases are supply chain management to record the transfer of components between entities in the supply chain or to enable demand chain management, and for smart contracts, where there may be multiple parties to the contract, for example as is now being used for book publishing. These examples would typically be privately permissioned.

Cryptocurrencies are one of the few use cases that can only practically be implemented using blockchain, because of the need for a public readable system run by mutually untrusting parties. Also, permissionless blockchains can offer anonymity, which is more difficult with centrally managed systems. 

In many other cases, there will be a trade-off between using blockchain or more traditional technologies. In deciding whether or not to use blockchain, two things to consider are infrastructure cost and speed of transactions. 

The integrity in blockchain is provided by using multiple nodes and the use of consensus protocols to record the transactions and create the signed blocks that are recorded in the chain. Bitcoin has more than a million nodes and tens, if not hundreds of thousands of miners, probably making a measurable contribution to global warming. 

Even in a small system, there needs to be a relatively large number of blockchain nodes to prevent collaboration between writers to subvert the blockchain, or failures of equipment corrupting the data. Total infrastructure costs are therefore likely to be more than for a conventional central or cloud-based database holding data signed using a traditional infrastructure. 

The latency in writing the blocks, and the number of transactions that can be recorded, are generally governed by the consensus protocols. These need to ensure that all, or at least a specified majority, of those signing the blocks of transactions agree on the signatures.

Again taking blockchain, the protocol currently allows 10 minutes for agreement of a hash used to sign a block. There is therefore a delay of between 10 and 20 minutes from the time of the transaction to the transaction being agreed. There are other consensus protocols, but they will all impact on latency and capacity.

Although every use case is not suitable for blockchain, some can only realistically be implemented using it, and those others that are best suited to a blockchain implementation can easily be implemented using one of the many companies offering blockchain hardware and software components. 

However, a careful assessment of the problem and possible solution should be undertaken before going down the blockchain route, and the potential drawbacks taken into account.