Fundamentals of the secure transaction processing protocol
We mentioned previously that cryptography is one of the core building blocks of a blockchain solution. The fundamental security of the Bitcoin blockchain is the elegant cryptographical linkage of all major components of the ledger. Specifically, transactions are linked to each other, mainly through the Merkle tree. A Merkle tree is based on the concept of a tree data structure, where every leaf node has a hash calculated of its data and where every non-leaf node has a hash of all its underlying children.
This method provides us with a way to ensure the integrity of the data, but also provides privacy characteristics by allowing us to remove a leaf that is deemed private but leave the hash, thereby preserving the integrity of the tree. The Merkle tree has its roots incorporated into the block header. The block header includes a reference to the block headers that precede it, as shown in the following diagram:
Figure 1.3: Block headers with references to the preceding block headers
That cryptographically enforced interconnectivity fosters the stability and security of distributed ledgers. At any point, if a link between any of the components is broken, it leaves those exposed to malicious attacks.
Transactions are also cryptographically connected to the rest of the blockchain structure mainly through the Merkle tree. Once a transaction is modified within a block, with all other parts remaining stable, the link between all transactions of the block and its header is broken.
The new resulting Merkle tree root does not match the one already in the block header, hence providing no connectivity to the rest of the blockchain. If we proceed to change the Merkle tree root in the block's header, we will, in turn, break the chain of headers and thus the security model of the blockchain itself.
Therefore, if we only change the contents of a block, the rest of the blockchain components remain stable and secure, especially as the block headers provide the connecting links by including a hash of the previous block header in the header of the next block.
Figure 1.4: Anatomy of a block