When we think of blockchain, we usually think — Bitcoin. But Bitcoin is just a concept on top of something called blockchain. Blockchain is the name of the underlying technology which allows for the implementation of many different use cases that can rely on blockchain properties.
For the purpose of this article, let us adopt Bitcoin as our model implementation of blockchain.
This article presents a straightforward analogy easy to follow by software developers. The reason it is quite handy for us is simply because we use it on the daily basis — or at least we should. To get to the point, the said blockchain analogy is git.
Or is it just an analogy?
When you look into the mechanics of the blockchain technology and git implementation, the similarities are staggering. Clearly, Satoshi Nakamoto had his inspirations! Remember, git is about 4 years older than Satoshi’s white paper.
Admittedly, publications on how to cryptographically secure a chain of blocks appeared even earlier (described in 1991 by Stuart Haber and W. Scott Stornetta; 1992, Bayer, Haber and Stornetta — according to Wikipedia), but those where just theoretical guidelines of how to make a chain of blocks immune to changes.
Let us look at the core part of the blockchain definition from Wikipedia:
A blockchain is a decentralised, distributed and public digital ledger that is used to record transactions across many computers so that the record cannot be altered retroactively without the alteration of all subsequent blocks and the consensus of the network.
Does it remind you of something you all have on your computers? What else is git if not a decentralised and distributed ledger (all of your team mates have your repository’s clone on their computers)? Definition does say that the ledger should be public. Git usually requires some kind of authentication mechanism, but a basic git network protocol has absolutely no authentication whatsoever! So it is by definition a public ledger, with an option of an additional security layer.
Blockchain is about recording data
Blockchain’s core responsibility is to keep a record of blocks in a way that it resists modification. This is possible due to the fact that the blocks are linked using cryptography. Blocks act as containers for abstractly defined “transactions”. A transaction can be anything — it can be a record of currency transfers, or any other kind of data. This data can be materialised as current state of files in working directory. This is what git holds — a chain of blocks (commits) of multiple transactions (current files’ state).
It’s worth noting, that git does not keep the changes (diffs) between two states as it is widely believed by regular git users. It does however keep the current “state of the system” (state of the working directory) in each of the commits.
Democratic network of nodes
As far as decentralisation goes, similarly to Bitcoin blockchain network, all git repository clones work in a democratised manner. Either one of repository clones (nodes in a blockchain network) has equal rights and is privileged to propose new changes to the blockchain. Those nodes are able to exchange information between each other. While the Bitcoin blockchain implements a stateful peer-to-peer two-way communication, with git this process is simplified to manual pushing and pulling. Either way, those git nodes exchange information between each other in order to determine what the blockchain really looks like. Git nodes will work together on obtaining common consensus — just like Bitcoin nodes do. The way they do it is just slightly different.
Immutability of data
Blockchain governs the transactions it holds by the very characteristics of how blocks are related to one another. Git creates new blocks (commits) in very same way all cryptocurrencies do — by hashing block contents together with meta data and hash of the previous block, making the blockchain immutable and impossible to counterfeit.
This prevents Bitcoin transactions from being forged. If a single block or transaction from the past was changed, the whole blockchain would have to be rewritten from that point in time. The very same thing happens with Bitcoin. Whenever you want to change a block (commit) from history, you would have to recreate all the subsequent blocks after it. This operation generally boils down to a git mechanism called rebase. Even though it is possible with git, this operation is discouraged whenever it considers commits already pushed to remote (shared with network nodes). This of course aims at avoiding situations of rewriting the history of the repository cloned by other users. As with git it is all about users’ good will and mutual trust, Bitcoin relies on Proof of Work algorithm to mitigate trust issues.
Both blockchains (git as well as Bitcoin) offer a possibility for the conflict to emerge. Both technologies address this issue in its own way. While Bitcoin will simply pick up the longest chain, git will resolve all the conflicts during the merge process.
One major difference between the git and Bitcoin blockchain would be the impossibility of permanent Bitcoin blockchain branching (excluding so called hard forks). With Bitcoin, all history of transactions has to be linear, which together with Proof of Work algorithm governs the blockchain and prevents from double spending. Git, however, offers a possibility of branching out with a new chain of blocks (commits), and then merging different branches into one change set. Although it is not possible with Bitcoin, similar concepts have been introduced in the case of some other cryptocurrencies.
Wrapping things up, from my point of view, understanding how git works under the hood clears up a lot of questions around what blockchain is. It really is an implementation of the blockchain mechanics described by Satoshi Nakamoto in his white paper (with few differences). It also means that new ideas emerge from already existing ones in the process of constant adoption and improvement. We are the witnesses as well as makers of the digital evolution.