Blockchain - Part 1: Concepts

Vikas Mujumdar, March 20, 2020

Blockchain as a technology is in a very strange position. Everyone believes it will provide them with an effective solution for some business problem, but very few are sure of which one and how.

The way we are looking at Blockchain reminds me of the old Indian parable of the Blind Men and an Elephant. It is a story of a group of blind men who have never come across an elephant before and each of them touches a different part of the elephant and imagines that's what the elephant is.

Credits: Original image by MoteOo from Pixabay modified by me to include the text.

The point is, Blockchain is understood or imagined to be different things by different people. Which is not a bad thing, in fact it makes Blockchain quite a versatile technology. The problem arises when the misinterpretation leads to its use in the wrong way or when it leads to it being dismissed as irrelevant.

This is going to be a 3-part article. In the first part, I will explain the idea behind Blockchain, without getting into any detail of its design or use cases. In the second part, I will go a bit deeper into its design, and explain a bit about how a Blockchain is implemented. And in the third part, I will share one use case in the space of smart logistics that actually combines IoT technology and the use of Blockchain to implement Smart Contracts (what that is you will know in Part 2).

To start with a conceptual understanding of what Blockchain is, let's go back to what we know about databases. I think we will all agree that data is what drives applications, and this data is stored in what we know as a database. Generally, there is only one database for an application and changes to the database are managed by a single entity who owns it. You don't typically maintain multiple copies and update each one of them every time the data is changed, or you don't read from any one of them randomly. In a system used by multiple entities transacting with each, this works fine if all entities trust the database owner to maintain the data for all of them.

For example, let's take the case of an airline reservation system. While multiple travel agents may issue tickets to passengers for a flight, the airline is the only entity that maintains records of all the tickets. The travel agents trust that when a passenger goes to catch the flight, his or her reservation will be honoured. Also, the travel agents trust that the airline will calculate the correct commissions on the tickets they have sold and pay the travel agents what they are due.

But take the more complex case of banks. Each bank maintains its own database of customers and their accounts. The bank also maintains all the data related to transactions between accounts within the bank. But when there is a transaction that involves two accounts, each from a different bank, who will ensure both bank databases have been updated correctly, with a debit in one and a credit in the other for the exact same amount? In today's banking ecosystem, every country has an authorised central entity, broadly referred to as a central bank, that ensures banks on both sides of a transaction update their systems consistently and correctly. If there is a dispute, the central entity is called upon to resolve the dispute based on its data records.

Credits: Icons made by Freepik from Flaticon

Now, imagine a technical solution that created a connected network of all the bank databases and then ensured that any transaction initiated by one bank was immediately broadcast to and needed to be approved by every other bank before it was recorded? And then all other banks that needed to update their own records did so, again only after getting an approval from all the banks in the network?

This approach will result in a peer-to-peer validation of each transaction, rather than a centralised validation.

Credits: Icons made by Freepik from Flaticon

Of course, the information that would be shared would be limited to what they all needed to know to trust that the other party or parties were living up to their side of the deal. All banks that are a part of a transaction would know that the balances were updated correctly by the other banks, but maybe not what the other banks charged their customers for the service provided. Now add a feature where the transaction is made immutable – such that once an entity updates a transaction record after seeking and receiving approval from all other entities, that transaction record can never be changed.

This de-centralised and peer-to-peer validation, coupled with immutability and security is broadly referred to as Distributed Ledger Technology (DLT).

A ledger is a record keeping system in which a bank or any entity that engages in financial transactions maintains transaction records. The term was in use long before computers and ledgers were large books in which transaction entries were hand-written. Today, ledgers are databases stored on computers and maintained using some software application.

With the Distributed Ledger Technology solution, each bank will maintain a ledger, but before an entry is made, a request will be circulated to all other banks in the network. Only if all the banks approve the entry (and they will update their own ledgers as well if required), can the requesting bank make its entry. Now, the ledgers of every bank in the network are always synchronised and disputes are unlikely to arise since all banks have already given their consent before any entries were made.

So what is Blockchain?

This solution using DLT for managing transactions between multiple parties is conceptualised as a chain of blocks, where each block holds one or more transactions (with all required transaction and block information) and is connected to its immediately previous block in time. This concept got the technology its name.

Credits: Icons made by Freepik from Flaticon

Solutions around what we simply refer to as Blockchain are actually a combination of the block and chain design and the distributed ledger design.

Since we started with a comparison to databases, can all thus not be achieved with traditional databases and some application software? The answer is yes, it probably can. But Blockchain software is specifically designed for this type of de-centralised applications and many of the requirements of storage, consensus and immutability are already baked in, making it much easier to build and deploy.

In part 2, I will go a bit into the design principles behind a Blockchain implementation.