In my earlier post, we framed blockchain as a linked list of nodes, with each node having a unique hash and storing the key of the previous node as well as a copy of the entire chain.
Let’s assume that each node or block now represents a game. Each block holds the score, the date the game took place, and a hash key. Each node also holds the hash key for the previous node, i.e., the previous game. If we have four games, we would have Game 1 <— Game 2 <— Game 3 <— Game 4. That is our blockchain that stores the game results.
If someone wants to change the score for Game 2 now falsely, they can only do so by adding a new node, Game 2a (remember that in this special linked list, only insert operations are supported). Game 2a will also have a hash that is unique in the chain (different from the true node, Game 2).
The “false” node Game 2a will hold the key for Game 1, but Game 3 contains the key for Game 2 instead of Game 2a. So now we need to create Game 3a and then Game 4a. As more blocks are added to the blockchain, this becomes very difficult, making the chain more immune to any false changes.
Also, since each block has a copy of the chain, there is no single point of data loss; unlike a central repository, if any one block fails, data can be recovered from other blocks.
Finally, in a typical blockchain implementation, adding to the chain (like adding a false block) requires multiple other blocks to approve that change - this would be hard to achieve if different owners owned the blocks.
These characteristics make it hard for the blockchain to change or be corrupted. Thus, we can now define our blockchain as a technology that provides an immutable record of a group (or “chain”) of blocks (that store data) owned by different users (persons or organizations) without the need to rely on an external authority to validate the authenticity and integrity of the data.
Comments