A replicated immutable time-stamped database using cryptographic encryption that would facilitate consensus driven collaboration and tracking of transactions and interactions.
Now that might be a bit too technical for a banker. In the last 2-3 weeks quite a few friends in my finance / banking circle have told me there is a lot of hype over the technology, but they are not able to comprehend the logic / method. Let me attempt to explain it in English. Here I will not touch upon the merits, value addition or use cases and will purely try to explain the working.
Consider a small world of 2-3 people owning and transacting in resources / assets. Consider an excel sheet where all the transactions being made are recorded as rows. Each change or transaction is recorded as a new row. This is, of course, traditionally called a ledger. The IT guy upstairs calls it a database. The ledger entries here mentions who gave whom, how much of what, when. In the below illustration Adam gave Eve 40 units of Love at 2.30 pm on 23rd March 2016.
Now, this excel sheet is not maintained in just one location. Identical copies of this excel sheet is maintained in many computers (by different people / companies) and that’s why we call it a replicated database. Although there are multiple copies of the database, each copy is maintained in sync with the other copies and thus there is only one truth, one fact at any given instant.
Anybody who wants to make a transaction can add a new row to this excel sheet to record their transaction. When a contributor adds a row it is time-stamped and he also signs his name against the transaction so that others can verify, he was indeed the actual contributor. One of the columns in the row added is Hash. Hash is cryptographically encrypted stuff that is created using the editor’s signature, Hash of the previous row and transaction details (Content) being added.
Since Hash of one row is dependent on Hash of the previous row every transaction added is dependent on the previous transaction and iteratively on all the previous transactions in the database. Thus we have a chain of transactions.
When a row is added by one person, others who have the excel sheet validate the transaction by checking the Hash and checking that the Editor indeed had previously owned this asset he is giving away to the Taker. They then add this row to their copy of the excel sheet as well, again to maintain one truth. Now this is collaboration.
In case any of the previous transaction is edited then the Hash of that transaction and all the following transactions will change. This is because the content of the transaction is encoded in the Hash and this Hash is encoded in the next Hash and so on. Suppose somebody tries to commit fraud by changing previous transactions in their copy of excel sheet, then he will have to calculate the Hash of all transactions from the changed transaction to the latest transaction.
The copy of the excel sheet with maximum rows that majority of people have will be considered true. This is consensus driven collaboration. By the time the fraudster calculates all the Hashes and tries to convince the majority of people that his copy of the transaction is correct and others are wrong the blockchain would have added another transaction to the list. So the fraudster will have to calculate the hash for this new transaction as well. And by the time he does that another transaction would have happened. So the fraudster will never be able to convince the world that he is right. Thus our excel sheet is immutable – transaction already entered can not be edited.
Suppose we have a lot of participants. Many bilateral transactions are being made simultaneously. Let us now extend the above method for recording one transaction to a ‘set’ of transactions. Then, all these transactions are recorded in a temporary log and after every 2 seconds the transactions that have happened are batch processed, as a block of data. As explained for a row, the Hash of a block of transaction is created and is dependent on the Hash of the previous block, the content of this block and signature of the person who is creating this Hash from the block. Instead of recording the transactions individually in our excel sheet, suppose we record these blocks, then we have a chain of blocks (since each block is dependent on the previous block) or a block-chain or a blockchain.
The person who is creating this Hash for a block as mentioned above is doing a service to the blockchain and he needs to be compensated accordingly. This person is referred to as a Miner. All those who transact will pay a small transaction cost to the Miner for including their transaction in the block he has created. Since there is incentive for creating blocks, thousands of Miners race against each other to create the block as fast as possible.
From a banker’s point of view we are only recording transactions just like in the account statement of a bank account; with the account balance not mentioned anywhere. The balance sheet or an income statement of a participant needs to be derived from transactions records in which the participant was a Editor or a Taker.
The above description is a very simplified manner of explaining the concept behind blockchain. The actual technology may be way more complicated and it can be implemented in innumerable variations.
You may now consider reading the first sentence of this article again.
As stated initially, this is just an attempt to explain.
And attempts, at times, do fail!