Blockchain – The immutable ledger

Immutable comes to us through Middle English from Latin ‘immutabilis’, meaning unable to change.
So in object – orientated and functional programming, an immutable object (unchangeable object) is an object whose state cannot be modified after it is created. This is in contrast to a mutable object, which can be modified after it is created.

So in the context of blockchain, we are looking at the proof that the data has not been altered.
If you recall from the last blog, understanding SHA 256 Hash that the blockchain is connected via a previous hash which it inherits from the previous block – This ensures immutability of the ledger.

A ledger consists simply of data structured by rules. Any time we need a consensus about facts, we use a ledger.
Ledgers have been around since the dawn of some form of written communication.

The first major change to ledgers appeared in the fourteenth century with the invention of double entry bookkeeping.

In the late twentieth century ledgers moved from analog to digital ledgers.

If we look at a practical example, say purchasing a vehicle from a dealer, or private sale for cash where we change the proof of ownership title into our name then register it with the department of motor vehicles – Therefore the title is registered in our name.

Now you have a record of your transaction should the ownership of the vehicle come into question.

But a database still relies on trust; a digitized ledger is only as reliable as the organisation that maintains it (and the individuals they employ). It is this problem that the blockchain solves. The blockchain is a distributed ledger that does not rely on a trusted central authority to maintain and validate the ledger.

So once data is put onto the blockchain it cannot be altered – Even if the data was incorrect to start with, you cannot modify it.

So in the context of trying to hack the block its hash will change, therefore it will no longer match the hash from the previous block. So the hacker will have to change / alter the hash of the next block and so on.

It becomes quite obvious that this is a near to impossible task to then actually alter a document or data set on the block without causing this chain reaction to occur.