Noting changes in the blockchain (part II). How to legit change data?

In the previous part, I dealt with two ways of detecting changes in the blockchain. Namely the change in the reference in the Merkle Root and the replacement of one transaction by another. In this second part, I will discuss two other ways to detect changes in the blockchain. Finally, I will discuss how data can be correctly changed in the blockchain.
In this article, I will discuss changing the entire Merkle tree, including the Merkle root. Then I will discuss the situation where not only the whole Merkle tree is changed, but also the hash reference that refers to a block (header) (for example, block 2 refers to block 1).

The 'root' of the manipulated Merkle tree (R12) is part of a block header (block header 1). Changing the Merkle root also changes the cryptographic hash value of Block Header 1, invalidating the hash reference that refers to it (B1). The hash reference B1 (in block header 2) providing the connection or serves as a link from Block header 2 to Block header 1 becomes invalid if the change is detected. As a result, the whole data structure of the blockchain becomes invalid.
In other words, changing the Merkle root will invalidate the block (block header) 1), but it will also invalidate the hash reference that refers to block header 1 (B1 in block header 2). See below:

If the hash reference (B1) to the manipulated block header (Block header 1) is changed, the following happens: starting with hash reference B1, all hash references pointing to the manipulated data are consistent and valid because they are adapted to the manipulation carried out. However, the manipulated hash reference B1 is part of block header 2 and therefore its cryptographic hash value changes, also invalidating hash reference B2, which referred to the original version of the hash reference B1. As a result, the whole structure of the blockchain is also invalid.
In other words, if the hash reference (B1) referring to the previous block header (Block header 1) is changed, it will invalidate the whole block 1. This is because the hash references are no longer correct. In addition, it also invalidates the next hash reference (B2) that refers to block header 2 because the hash reference B1 that refers to block header 1 (included in block header 2) is invalid. See below:

As noted in the previous contribution (Part I), all connections between the 'blocks' in the blockchain are interconnected. If a change is detected somewhere in the blockchain, it will invalidate the entire blockchain data structure. The hashing technique can ensure that every change in the blockchain is detected and can be acted upon by the nodes in the blockchain system.
How, then, can data be changed in an orderly fashion? Is this possible? The answer is yes. In the blockchain technique, data in the blockchain data structure can be changed without invalidating the entire data structure. See below:

If a node wants to change or update some details of transaction 2, the node must then update the whole set of hash references: R2, R12, B1 and B2. This means that all hash references beginning with the one directly referring to the manipulated data (transaction 2) and ending with the hash reference referring to the most recent block header (B2), as well as all hash references in between, must be modified and updated to reflect the changes to their previous hash reference. This is a rather complex task. And it is deliberately a complex process. All this work is necessary to keep the whole data structure of blockchain consistent and maintain its integrity. Any other attempt to modify or manipulate data that is part of the blockchain data structure will result in invalid hash references, which in turn will invalidate the whole data structure.
If somebody wants to manipulate the blockchain, they have to adjust each hash reference throughout the blockchain. If only 3 blocks are present, this can still be done. If there are thousands of blocks, it is practically impossible to do so.
Does the blockchain differentiate between changes that take place with or without intention? The data structure of the blockchain uses an all-or-nothing approach when it comes to changing the data: either one changes the entire data structure completely from the point that causes the change, or one leaves it all unchanged. All other semi or partial changes will leave the whole blockchain data structure in an inconsistent state, which will be detected easily and quickly. This is due to the characteristics of hash references. The data structure of the blockchain does not distinguish between intended or unintended changes.
Actually, there are no intended or unintended changes in the blockchain. These terms refer to the motives or the person who triggered the change. However, the data structure of the blockchain does not detect either the motives or the person causing an inconsistency in the blockchain. The blockchain only values the correctness and consistency of all hash references. If one of them (a hash reference) is invalid, the entire data structure is invalid, regardless of who or what caused the change or why it was made. This is all irrelevant.

Conclusion

In this contribution, I have looked at two other ways to make changes in the blockchain. Firstly, changing the whole Merkle tree, including the Merkle root. Secondly, the situation where not only the whole Merkle tree is changed, but also the hash reference that refers to a block (header). In all these situations, the blockchain data structure is disturbed. The hash references are no longer correct. As a result, the entire blockchain data structure is invalid. Finally, I discussed how the blockchain can be changed without invalidating the blockchain data structure. In theory, this is possible, but in practice very hard to achieve.

I published this article previously on my LinkedIn page. This article was written on October 29 2020. This article was updated on September 26, 2021.