Last week I was at the excellent Insurtech Rising conference in London, where I heard the definite article in “the blockchain” way too often.

You can say “the web” because it makes sense - but not “the blockchain”. Blockchain is a technology, like XML. There are many different kinds of blockchains.

Count ‘em…

There are blockchains that track assets, such as Bitcoin. These require proof-of-work and a consensus protocol to prevent tampering because - surprise, surprise - they’re public and can be updated by anyone.

There are private - or permissioned - blockchains. Perhaps these will soon include the Combined Audit Trail (CAT), newly-required of financial institutions by US regulators.

Then there are hybrid blockchains for specific applications - such as tracking the provenance of branded goods and commodities, such as diamonds. With these, a permissioned and a public blockchain are linked for a purpose-built cloud or enterprise application.

Some blockchains allow you to store programming code in them for execution by all the nodes that help maintain that chain.

This is called code-on-chain, and it can be very handy for enabling specific custom functionality for use within smart contracts - very much like stored procedures do for SQL databases.

But just as SQL stored procedures are a tool useful for specific aspects of database-oriented applications, so code-on-chain is a tool useful for specific aspects of smart contracts. In neither case are they the whole solution - they are too low-level and technology-specific.

Diamonds are an insurer’s best friend

Take the world of insurance, for example.

A diamond tracking business, say, wants to take out a smart insurance policy to protect its assets. A one-time, per-policy electronic document is drawn up, modelled, agreed and digitally signed by the diamond trackers and their insurance company.

It’s a contract because, private or otherwise, it’s a unique document expressing the benefits and obligation of each contracting party. It’s smart because it automatically executes the terms of the document by itself.

Each of these contracts is, as my teenage daughter might say, a special snowflake. Every one is unique. You might reasonably store this kind of contract on a blockchain.

A special snowflake

Once signed, that smart policy is automatically deployed in a place that is itself specified as part of the contract. For example, a cloud datacenter from a whitelisted provider in a specific jurisdiction.

As the contract is notified of claims, endorsements and other policy-related events, it performs all the business operations required to integrate external systems and settle payments, using fiat or digital currency.

Amongst other things, the policy might need to reference several different blockchains in the process:

  1. A hybrid blockchain combining, say, Eris and Bitcoin, to track the provenance of the diamonds.
  2. The public Bitcoin blockchain for digital cash settlements.
  3. A permissioned blockchain which tamper-proofs transaction workflows as events occur under the contract.
  4. Other blockchains relating to downstream smart contracts between the insurer and, say, its reinsurers.

But the parties to a smart contract have other needs too - including embedding blocks of legal clauses, reporting, analytics, facing off to legacy systems, integrating cloud and enterprise systems, achieving permission-based visibility of events and state. It’s a long list.

So to understand smart contracts and make them really work for us, we need to disambiguate them from the many technologies they may use - including blockchain - to achieve their desirable effect.

Image via 20th Century Fox.