Blockchain 101 or "How to ride the Blockchain bike"

Every time I see a "Blockchain 101" inevitably, it mentions Bitcoin. Personally, I think that's like telling you what a spoke on a wheel is rather than telling you how to ride the bike. I figured I'd write the "How to ride a bike" version of "Blockchain 101". BTW: I'm going to try to not mention the *B* word again here, so, let's go...

The Big Concept

At its heart Blockchain is the concept that a number of parties have an interest in assets - let's say a car. Those parties can alter those assets (buy the car, sell the car, be the insurer for the car). When the assets change e.g. the car gets sold the parties all have to agree that the asset was changed and by whom and what changed. That "agreeing" bit is called "consensus" - a very important thing in the Blockchain world. It's this, "consensus algorithm", (and there are more than one) that make Blockchain standout from being just a database, as such.

Blockchain Participants

If everyone who had an interest in the asset, kept a unique version of what they think has happened to the asset, and when that event happened then, that's the blockchain - it's a storage mechanism for data that requires multiple parties to be involved to maintain integrity! (In fact, *they* recommend at least three parties are required to maintain a consensus.)

Consensus

Blockchain is sometimes called a "shared" or "distributed" ledger. What people mean by this, along with a few other things, is that individual participants have a view on a copy of the same ledger (data). In order to achieve consensus (and this is the bit that the techies love to talk about but I'll keep it high level ;-) there are algorithms that make sure that each ledger agrees with the other ledgers. This stops rogue ledgers coming and claiming that something happened when it didn't. This is achieved by the other ledgers disagreeing with the rogue ledger and they block out the rogue ledger and its rogue entries.

I almost hate to say it - but that's the basis of all the fuss - easy isn't it ;-) Okay, so there is obviously some hard stuff...

Security

As with any system there are security measures in place. You can't just let anyone say that they own the car - or else you'd have chaos ! Therefore blockchain uses the usual TLS certificate methods to ensure that people who alter car statuses are allowed to. In order to do this you need some certificate management in place - and a blockchain provider may provide that management i.e. give out the usual certificates, allocate different users different roles e.g. changing car status, view car status, sell cars, buy cars etc.

Not all blockchains (think ledger) are secured - but the commercial ones will almost certainly be.

Consensus algorithms

I mentioned earlier that there are different algorithms for holders of the ledger to achieve consensus. There is a reason for this... You may have read about "certain crypto currencies" (phew, almost said the "B" word !) and all about how it takes huge amounts of power to "mine" coins. That's not a good thing when you want to use the blockchains in a more generic environment. So, there are a number of algorithms that allow different qualities of service. Which one is chosen for the chain will depend on the main issue that is being resolved and there are, potentially, compromises. The sorts of qualities of service considered include speed of transactions, number of participants required to achieve security etc.

Multiple Chains

One thing to be clear on is that there will be many blockchains. For instance, you may have one for tracking the parts that make up a vehicle and you may have one for the complete vehicle itself. This is going to produce a world of blockchains and, side-by-side, contributors to the blockchains. For instance, the person who makes parts for the car will have access to the "car parts" blockchain and may even be able to track their individual part being contributed to the actual instance of the car. However, the "car" blockchain may just discuss complete cars and not have, as part of its data, the individual parts of the car. Of course, in an ideal world the two chains would either be just the one chain or two chains. One chain would make it very easy to tell exactly where each part of your car came from. Two chains would would require linking together, one chain to track the complete car and one for the supply chain that made up the car. These options should not affect how you, as the owner of the car, interact with the blockchain; but it will affect the underlying integration challenges for the implementors of the services that are telling you about your car.

Shadow Chains

Shadow chains is a term that you may see discussed quite a lot and is worth mentioning here. Shadow chains are where there is already a system in place but a blockchain is created which uses the same data. This may be with a view to moving the current system completely to the blockchain or in order to create a chain to work on a new part of the business which will use that current system. 

Integration with the chain

That brings us nicely to the subject of how to work with blockchains. Working with blockchains requires the usual "integration" skills to be in-place... getting data into the blockchain (telling the chain that the car dealer has just sold the car) and getting data back out of the blockchain (asking "who owns the car") or responding to events in the blockchain (an insurance company being told that the car has just been sold).

These are all problems that have been solved before in the integration space and you will need to solve them again, except this time your project will be working with a piece of a blockchain instead of, say, a partners database.

Hyperledger, Ethereum et al...

There are a number of projects out there that implement the concepts that I've just discussed and call themselves blockchain implementors. However, the one that is, so far, leading the pack (hmm, probably) is the "hyperledger" project. This project is currently looking like the next linux. It's got the backing of IBM and Intel. However, that's no guarantee - this is a waiting game - but few people want to wait at the moment. So, many people are implementing projects with these and you're going to see quite a few other technologies attempting to be the next linux for distributed ledger.

In Summary

I've shown how Blockchain works in principle and the advantages of that principle. I've also discussed how this new technology relies on good integration skills to make it real. From my perspective there are a number of players out there trying to implement the technology but, at this point, I'm banking on IBM sponsored Blockchain "Hyperledger" to become the de facto standard - but, we'll all have to wait and see on that one !