Immutability in public/private blockchains — Part 1
Immutability is a core value of a blockchain implementation. Before talking about technical details about this matter in public and private blockchains, it may be useful to step back and think about what does it mean and why it’s important.
What does immutability mean?
Being as literal as possible immutability means that something can’t change. Ok, so that was easy, right?. Kind of… We first need to define what it really means that something has changed.
Imagine that now you have a white car. Now you decide that you want a red one. You have at least two options:
- Paint red your current car.
- Sell your current car and buy a red one.
In the former, you can say that your car has changed because the color is an attribute of your car. Since that attribute has changed then you can safely say that your car has changed. In the latter, you can’t really say that your car has changed since you bought another car.
So what’s the point of this?. First, we have to make clear what defines the identity of an object before analyzing its mutability. Taking this idea to an extreme, if the identity of an object is defined as all of its attributes, then changing any of them means that we have another object, thus the original object hasn’t changed.
There’s also a philosophical discussion about how identity can be defined. Of course, it’s not the purpose of this article, but if you’re interested you can take a look at the Ship of Thesus.
TL;DR: Before considering if an object has changed we should first have a clear definition of its identity.
Why immutability is important?
Let’s consider the following situation. You’re a house owner and the country you live in decides that house ownership is going to be defined by a record in a ledger.
Consider the following claim:
I’m a house owner, so there’s a record in the ledger supporting this fact.
Well, that’s not an exactly accurate statement. The following claim would be a correct representation of house ownership in this country:
There’s a record in the ledger, thus I’m a house owner.
Now, that sounds pretty different. Since owning your house has taken a lot of effort, you may start considering asking the following questions:
- What if the ledger is destroyed?
- What if somehow the record corresponding to my house is deleted?
- What if somehow the record is changed and another person owns my house?
- What if the ledger is inaccessible?
Those are some reasonable question to make since houses are very high-value assets. If instead of houses we are talking about candies you don’t mind taking risks about those considerations.
The previous questions analyze different risks the ledger could challenge, in particular, the second question sounds like it should be immutable. The third one isn’t really about immutability but authorization.
Maybe the word immutable starts making some sense now. But wait, real estate business is about transferring ownership, so we have mutation there.
Reality changes, but history doesn’t.
That’s the important point. A new transaction transferring ownership doesn’t change the fact that sometime before I was the owner of that house.
If we take important decisions using information in the ledger we want that information to be immutable; we need to establish causality and hold it permanent. To be even more precise, thinking about time as a dimension and considering that time is a one-way street, we should conclude that history should be immutable.
We still didn’t talk about if the ledger is digital or not. It could be a paper-based ledger, relational database, blockchain, etc; but that’s an implementation detail that doesn’t change by any means the importance of immutability in our example. Immutability is a design decision.
What does immutability mean in the context of blockchains?
As a refresher, remember the following:
- Blockchains are distributed ledgers.
- The distributed part refers to many participating nodes, in particular having a copy of the ledger.
- The blockchain consensus algorithm is responsible for all the nodes to, eventually, converge to the same ledger.
- Blockchains are made of ordered blocks, where each block contains the hash of the previous block (that’s why its called blockchain; blocks are chained with hashes).
- Blockchains are append-only data structures.
Blockchains as ledger implementations are used to model the history of transactions. A transaction happened if it is part of history. As we mentioned earlier, history is immutable therefore blockchains should be immutable too.
The last point of the above list mentions that blockchains are append-only data structures; this is a requisite since every generated block can’t be changed to preserve immutability.
What if we have the same ordered history of transactions but grouped differently in blocks (e.g., we make blocks with twice the size)? We can ask if we have multiple blockchains for the same history. That’s a more subtle discussion since we have two representations of the same history. In the case of Bitcoin, when a block is generated a generation transaction is included by miners which contains a reward, making history different if the same ordered transactions are grouped differently in blocks.
Breaking immutability in blockchains refers to how hard is it to convince the majority of the nodes to alter an existing block. If this could be possible we would have changed history leading to maybe unacceptable consequences.
In part 2, I’ll compare implementation differences in this design goal in two solutions:
- A public blockchain that uses a Proof of Work (PoW) consensus mechanism, for example, Bitcoin.
- A private blockchain, in particular Hyperledger Fabric.
I think the contrast between both is pretty interesting since the core idea of chaining blocks have very different importance in immutability.
