In this Chapter, we will discuss how to add new transactions to an existing blockchain’s data structure, how to guarantee immutability of a blockchain’s data, how the information is forwarded in a peer-to-peer network and how the nodes are automated (see e.g. Drescher 2017 and Bashir 2018).
Figure 6.1. New transactions to be added into the blockchain.
Description: Similar data structure as in the previous Chapter, only now the other block is unformulated, with a number of transactions waiting to be added.
In Chapter 5 we gave an overview of how the transaction data is created to a blockchain. Adding new transactions follows the same data structure, but of course the structure gets bigger when new transactions are being added. In order to add new transactions (see Figure 6.1), the blockchain performs the following things (Drescher 2017, 124, modified; see also Bashir 2018, 24):
Figure 6.2. Adding the missing parts to the blockchain to accommodate new transactions (see also Chapter 5).
Description: The block header, references to data, a timestamp and a new block head are added to accommodate the new transactions.
The immutability of a blockchain and its transaction data is based on the hash references. This goes for all the different parts of the data structure. If we try to change transaction data (Transaction A in Figure 6.2 for example), the cryptographic hash value changes and there will be an error in the Merkle tree’s pointer to the data, and therefore it becomes broken. If also the Merkle tree (MA) is changed then the hash reference pointing to the Merkle tree in total is broken. If we displace an original transaction (Transaction A) in a Merkle tree with a totally new one, then the Merkle tree’s pointer (MA) to the transaction is invalid, exactly in the same way as when transaction is only manipulated. If we modify the whole Merkle root (M_AZ for example), then this will change the hash reference of the block header (Block header A) and therefore invalidate it for the hash reference pointer (Ref. A). If we try to also change the hash reference pointer (Ref. A), then the hash reference to the Block header (Block header B) will have to be changed and it will not be correctly referenced to by the head of the transaction data (Ref. B).
This is how the blockchain is immutable: all the changes in different parts of the already saved data will be noted and when the blockchain is checked for changes by multiple users, most of the users will accept only the changes that are valid by the blockchain rules. Only way to change the data is to change the whole structure which is very hard with a long blockchain. This goes for both intended and unintended changes. This is important as the blockchain should collect all the transaction data truthfully no matter what the users’ actions and intended or unintended changes to the structure are. Therefore, blockchain data is said to be immutable.
Video 7. Short video going into a bit deeper how the actual Merkle trees are formed.
Description: A 2.5-minute video on the structure of actual Merkle trees.
The immutability is enforced not only by hash references described above, but also by making sure that to change anything on the blockchain, one must replace a huge part of the existing blockchain, and by making sure that replacing even the smallest amount of information is computationally costly. How is computationally costly replacing done? The main factor are the hash puzzles, which must be solved for each block header in order to manipulate them. To change something in the blockchain, all the hash puzzles for each block header after the block changed are to be solved. As this takes considerable amount of computing time, it discourages manipulating the blockchain for anyone’s own advantage. (For more information on hash puzzles, see: https://steemit.com/bitcoin/@cryptovest/bitcoin-and-blockchain-what-math-puzzle-do-miners-actually-solve)
A list for the procedures in creating a new block to a blockchain can be given (according to Drescher 2017, modified; see also Bashir 2018, 132-133):
As we can see from the list, the immutability of the blockchain is dependent on the computational cost of the blockchain’s hash puzzles. If the difficulty of the hash puzzles is too low, one can with proper computational power manipulate the whole blockchain. If the difficulty is too high, adding new transaction data might become too slow. In a real world blockchains, the computation time is defined dynamically to adjust for different computational powers that users have. This makes sure new blocks can be added enough for all the new transactions, while making it very costly for manipulating the whole blockchain.