Discussing the transactions and their cryptography leads us to problem of ordering: how can we be sure what type of order there is between transactions and how to keep transactions in the same order no matter what users do in the blockchain? These are questions that need answering before we can proceed in discussing immutability of blocks and controlling forking chains. There is the first hint: blockchains are about chains of transaction data, linked together. The following simplification of transaction data (see Figure 5.2) is based on Zheng et al. (2016, 2018), Bashir (2018) and Drescher (2017).
Figure 5.2. Blockchains’ simplified structure with three blocks of data (and their transactions).
Description: The blockchain’s structure is comprised of block header, references to transactions, time stamp, and transactions themselves. All the blocks are connected with the previous block through a reference in the block header.
Each transaction is stored in a block, either by itself or, in e.g., case of a bitcoin, with other transaction done during a 10-minute interval. To have the blocks form a chain, we need not only the transaction data itself, but some sort of ordering which prevails against attempted changes. We need a reference to block’s content (an address inside the blockchain network) as well as a reference to its place in the chain (another address in the same network). By combining both content (block) and place (place in the chain) we can be sure that the correct transaction data is in the correct location. The best way to do this is to use cryptographic hash values for both the content and the location. An example of how a resulting transaction data could look like is given in Figure 5.2.
As can be seen in the simplified Figure 5.2, each of the blocks in a blockchain can be found by going from the top to bottom with the help of the reference number to the previous block, until the correct block is found (from Ref. B to Ref. A etc.). The (possibly multiple) transaction data can then be found by the help of the block header. Each exact transaction is given by decrypting the content with the account number (aka. public key) of the transaction made.
The depicted in Figure 5.2 the maintains hash reference to three distinct Merkle trees whose roots are labeled M19, Maz and M_AZ, respectively (for mathematics of Merkle trees, see Chapter 3). These roots can further be used to find the actual transactions. It should be noted that these references refer to hash values of the transactions, the same way as the references to Merkle trees refer to trees’ hash values.
The Figure 5.2 is simplified and many things in the final blockchain data structure have been left out. However, this is the starting point for learning the data structure, and it is accurate enough. Although the Figure 5.2 has its limitations, we can say that this type of structure could be stored on your computer when using a blockchain, withholding
Next, we discuss how to make these (yet incomplete) blockchain data structures immutable, preserving their usefulness in validating all the transactions ever done in a blockchain network. But first we discuss the present law concerning blockchains in different countries around the globe.