Leading on from my previous post, no blockchain topic would be complete without the obligatory explanation of how blockchain works at a high-level.
I say high-level because the intricacies of how things like consensus algorithms work, how they address Byzantine Fault Tolerance (BFT), how nodes ‘speak’ to each other, what the purpose of a nonce is, etc. will come later in my journey.
Ideally, I would like to take the ‘this is how we create something’ approach but that wouldn’t be much of a journey and some of the boring stuff is actually needed to build a foundation we can work on.
So, here we go.
One of the fundamental concepts when talking about blockchain is that of a distributed ledger (more on that later). The terms distributed and decentralised are often used interchangeably and thought to apply to the same thing - I assure you they are not the same.
The difference is probably best described by the image below.
As you can see, centralised is, as the name implies, where a single node controls the entire network. A failure at this node would incapacitate the entire network.
In a decentralised network, there is a greater degree of redundancy and fault tolerance however, faults at critical nodes would cripple substantial parts of the network and, potentially, orphan nodes.
Blockchain’s resilience comes from the underlying implementation of a distributed architecture. In this topology, a node is able to operate as a discrete unit. Each node has it’s own copy of the ledger and is not dependant on any other node(s) on the network. A failure at a node would only affect that node and no other portion of the network.
We now have an abstracted understanding of the topology of the network - great. In this post, I’ve mentioned this thing called a (distributed) ledger. Lets dig into that a little.
Wikipedia says a ledger is “…a permanent summary of all amounts entered in supporting journals which list individual transactions…”
And that’s the same as a blockchain ledger:
Assume we have a deposit of $100 , this is recorded in our ledger and looks like this
We then continue to append more transactions
- A deposit of $125
- A withdrawal of $200; and
- A deposit of $25
Eventually, our ledger look like this
In a blockchain implementation (usually after an amount of time), all these transactions are grouped together into a block and the transactions are ‘hashed’. Think of a hash as a fingerprint that uniquely identifies some data. Any change in the data (no matter how small) will dramatically affect what the hash looks like. So our hash uniquely identifies our block of transaction any may look like this
That hash then becomes an entry in the next block of transactions and this value is taken into account when generating a hash for that block. To understand this better, take a look at the illustration below.
This process continues on with each blocks hash becoming the ‘seed’ for the next block and we end up with something looking like this
We end up with a chain of blocks - hence the term ‘block-chain’.
You may be wondering what the point of this is. Well, lets take a look:
Imagine, if we tried altering a transaction somewhere within our chain
The hash for that block, now, would not match the original hash for that block. Further, because that hash is used as the seed for subsequent blocks, none of the subsequent blocks would be correct.
If a transaction was to be altered, not only would that blocks hash need to be altered but, also, every subsequent block.
Computationally, that’s a very difficult task.
However, that’s not all that lends immutability to a blockchain. Not only would you have to alter every block on that ledger, you would need to alter that ledger on every node in the network.
This is the incorruptible aspect of blockchain and this is what gives us certainty that what we see is really what transpired. Furthermore, the details of these transactions (in a public, unpermissioned, blockchain implementation) are transparent.
We’ve now established what a block is, how they are chained together and why blockchain lends itself to immutability, incorruptibility and resiliency.
We know we can’t alter transactions already committed to the chain but, at this point it would be logical to question the validity of transactions appended to the blockchain. If any node can add transactions, how do we validate and verify that the transactions SHOULD be added to the chain. This is where consensus comes into play and there are a few different ways to reach this consensus. I’ll discuss some of these in my next post.