The transactions should be recorded as described in the earlier Chapters, but how to maintain a transaction history that is exactly the same at all nodes of the peer-to-peer network? This is paramount, as all the transactions should be recorded only once, with available assets being used on that time. If available assets can be used twice, let us say both in different parts of the network, then the problem of double spending is a clear threat to trustworthiness of the blockchain (see Bashir 2018). This Section is based on Drescher (2017) and Bashir (2018).
Even though there are only two possible automated activities in the blockchain (see “the rhythm” in the previous Chapter) this does not mean that all the activities would take place with the same information. Therefore, the information on transaction history should be distributed effectively across the network as there is a need for unambiguous transaction history.
Adding new blocks is computationally expensive because of the hash puzzle needed. Therefore, manipulating transaction history is a time-consuming process. There is a criterion called the longest chain criterion (or “longest branch scheme”, Zheng et al. 2018), which is based on the idea that the longest chain is usually the hardest to manipulate and should be the correct version of the transaction history. However, in the case of chains that are equally long the voting scheme is needed.
Blockchain as a technology solves the problem of histories of identical length by a consensus voting. The level of consensus needed varies between different blockchain applications, but usually the level needed is over half of the nodes in the network. Therefore, if less than half of the network believes a transaction valid, it can still be discarded as invalid while another branch of the blockchain becomes the valid one. It should also be noted that vote does not need any coordination, but it is an automated part of the blockchain network.
When dealing with a real-world blockchain, the resulting branches, which are discarded and then continued, make a “blockchain” look more like a “blocktree” (or “blockcactus”, as in Drescher 2017). The different branches of the tree represent conflicting versions of the transaction history. Based on longest chain criterion and voting scheme, all nodes can agree on an identical transaction history.
Another criterion which is also in use, is the strongest chain criterion (https://cryptoservices.github.io/blockchain/consensus/2019/05/21/bitcoin-length-weight-confusion.html) for choosing the correct transaction history. There are different levels of difficulty that can be given to hash puzzles, which depend on the computational force that is employed in the given blockchain. Usually, this difficulty level can vary even inside the same blockchain, which is why the difficulty level is said to vary dynamically. The strongest chain criterion (or “heaviest chain rule”, Bashir 2018, 215) takes into consideration not the length of the chain but the difficulty of reproducing it considering the difficulty of the hash puzzles employed in the given chain. That is why blockchains that use dynamic difficulty for hash puzzles usually use strongest chain criterion.
For the blockchains’ tree-like branches, there are some consequences for deleting transactions that do not belong to the validated chain. There are orphan blocks, which are cut out of the transaction history, effectively rendering the transactions stored in them invalid. If work has been done on validating these blocks, it is disregarded. Ownership changes given by the orphaned blocks that are not taken into account, however, are given another chance to be taken into account in the next blocks that are formed in the blockchain. This should make one weary of deciding on the last blocks added, as they can be discarded in the case of another chain becomes the dominating one. The further down you look in the blockchain transaction history, the more probable it becomes that the transactions are correct. This is called eventual consistency of a blockchain.
The way transaction history is formed and validated makes it very hard for a malicious attack on the transaction history, as this would mean solving the hash puzzles faster than the rest of the blockchain together. In a real-world blockchain, there have been some attempts to create an alternate transaction history with a group of computers, some of which have been hacked to perform the attempt. However, to this day, very few of the attempts have been reported successful. The same goes for voting schema for the branches of identical length: there are considerable financial benefits involved in manipulating a given voting scheme and attempts to this end have been made. However, very few of these have succeeded, which gives a clear indication of the robustness of blockchains’ transaction history.