Deep understanding of Blockchain six: Bitcoin blockchain __ Blockchain

Blockchain Introduction

A blockchain is a data structure that is logically linked from the back to the block that contains the transaction information. It can be stored as flat file, which contains files with no relative relational records, or stored in a simple database. Bitcoin core clients use Google's LEVELDB database to store blockchain metadata. Chunks are sequentially linked from the back to the chain, with each chunk pointing to the previous block. The blockchain is often seen as a vertical stack , the first chunk as the first chunk of the stack, and then each chunk is placed above the other blocks. Using stacks to visualize the notion that chunks are stacked sequentially , we can use terms such as "height" to represent the distance between chunks and the first chunk, and "top" or "top" to represent the most recently added chunks.

A hash value is generated for each block of SHA256 encrypted hash. With this hash value, the corresponding chunks in the blockchain can be identified. At the same time, each chunk can refer to the previous chunk (parent block) through its chunk header's "Parent Block hash value" field. In other words, each chunk header contains its parent chunk hash value. This creates a chain that can be traced back to the first chunk (the Genesis block) by linking each chunk to the hash sequence of the respective parent block.

Although there is only one parent chunk per chunk, you can temporarily have multiple sub-chunks. Each child chunk has the same chunk as its parent chunk, and has the same (parent chunk) hash value in the parent Chunk hash value field. The case of multiple sub-chunks in a chunk is called a "blockchain fork." A blockchain fork is only a temporary state, which occurs only when several different blocks are found almost simultaneously by different miners (see "8.10.1 Blockchain fork"). Eventually, only one chunk becomes part of the blockchain and solves the "Blockchain fork" problem. Although a chunk may have more than one chunk, there is only one parent chunk for each chunk, because only one chunk of the parent Chunk hash field can point to its unique parent block.

Because the chunk header contains a "parent chunk hash value" field, the current chunk's hash value is also affected by the field. If the identity of the parent block changes, the identity of the sub-block changes as well. When there are any changes to the parent block, the hash value of the parent chunk also changes. A change in the hash value of the parent chunk will force the "parent chunk hash value" field of the child block to change, which will result in a change in the hash value of the child chunk. The change of the hash value of the sub-Chunk will also force the "parent chunk hash" field of the sun block to change, and therefore the grandchild chunk hash value is changed, and so on. Once a chunk has many generations, this cascade effect will ensure that the block will not be changed unless all subsequent chunks of the block are forced to be recalculated. It is because such recalculation requires a lot of computational effort, so the existence of a long blockchain can make the history of the blockchain immutable, which is a key feature of bitcoin security.

You can think of the blockchain as a geologic layer in geologic formations or as a sample of glacial cores. The surface may change with the seasons, even before it is blown away by the wind. But the deeper the geology, the more stable the geological layer becomes. Hundreds of feet deep, you will see a rock that has been preserved for millions of years but remains intact. In the blockchain, the last few blocks may be modified due to the recalculation of the blockchain fork. The newest six blocks are like topsoil of several inches deep. However, after these six blocks, the deeper the chunk is in the blockchain, the less likely it is to be changed. After 100 blocks, the blockchain is stable enough to be paid for Coinbase transactions (transactions that contain newly dug bitcoins).  The blockchain after thousands of blocks (one months) will become a definite history and will never change. 7.2 Block Structure

A chunk is a container data structure that is contained in a public ledger (blockchain) that aggregates transaction information. It consists of a chunk header containing metadata and a long list of transactions immediately following the constituent block body. The chunk header is 80 bytes, with an average of at least 250 bytes per transaction, and an average of at least 500 transactions per chunk. Therefore, a complete chunk containing all trades is 1000 times times larger than the chunk head. Table 7-1 describes a block structure.

table 7-1 block structure

size	Field	Description
4 bytes	Chunk size	The chunk size after the field in bytes
80 bytes	Block size	Several fields that make up a chunk header
1-9 (Variable integer)	Trading counter	Number of transactions
Variable-	Transaction	Transaction information recorded in the Block

7.3 Block Head

The block size consists of three blocks of chunk metadata. The first is a set of data that refers to the hash value of the parent chunk, which is used to connect the chunk to the previous chunk in the blockchain. The second set of metadata, namely difficulty, time stamp and nonce, is related to mining competition, see Chapter 8th. The third set of metadata is the Merkle root (a data structure used to effectively summarize all transactions in a chunk). Table 7-2 describes the data structure of the chunk header.

Table 7-2 block head structure

size	Field	Description
4 bytes	Version	Version number for tracking software/protocol updates
32 bytes	Parent Chunk Hash Value	Referencing the hash value of a parent chunk in a chunk chain
32 bytes	Merkle Root	The hash value of the Merkle root of the transaction in this chunk
4 bytes	Time stamp	Approximate time generated by this chunk (Unix timestamp in seconds)
4 bytes	Difficulty target	The difficulty target of the block workload proving algorithm
4 bytes	Nonce	Counters for the workload proof algorithm

Nonce, difficulty targets and timestamps will be used for the mining process, and more details will be discussed in the 8th chapter. 7.4 Chunk identifier: block hash and chunk height

The chunk Master identifier is its cryptographic hash value, a digital fingerprint obtained by hashing the chunk header two times with the SHA256 algorithm. The resulting 32-byte hash value is called a chunk hash, but a more accurate name is the block hash value because only the chunk header is used for the calculation. For example: 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f is the chunk hash of the first bitcoin chunk. A chunk hash can uniquely and unambiguously identify a chunk, and any node can obtain the chunk hash independently by simply hashing the chunk header.

Note that the chunk hash is not actually contained in the data structure of the chunk, whether the chunk is being transmitted over the network, or if it is stored on a node's persistent storage device as part of the blockchain. Instead, the chunk hash is computed by each node when the chunk is received from the network. The hash value of a chunk may be stored in a separate database table as part of the chunk metadata for easy indexing and faster retrieval of chunks from disk.

The second way to identify chunks is through the block's position in the blockchain, which is "block height". The first chunk has a block height of 0, and the chunk referenced by the previous hash value 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f is the same chunk. As a result, chunks can be identified in two ways: chunk hash or block height. Each chunk that is subsequently stored on the first chunk is "high" from the previous block in the blockchain, as if the box were stacked on top of the other boxes one after another. The block height of January 1, 2014 is approximately 278,000, indicating that 278,000 blocks have been stacked on top of the first block created in January 2009.

Unlike chunk hashes, Block heights are not unique identifiers. Although a single block will always have a definite, fixed block height, but the reverse is not true, a block height does not always identify a single block. Two or more blocks may have the same block height and compete for the same position in the blockchain. This situation is discussed in detail in the section "8.10.1 Blockchain fork". Block height is not part of the chunk data structure, it is not stored in chunks. When a node receives a chunk from a bitcoin network, it dynamically identifies the chunk's location in the blockchain (block height). Block heights can also be stored as metadata in an indexed database table for quick retrieval.

The chunk hash of a chunk can always uniquely identify a specific chunk. A block also always has a specific block height. However, a particular block height does not always uniquely identify a particular chunk.  More specifically, two or more chunks may compete for a location in the blockchain. 7.5 Genesis Block

The first chunk in the blockchain was created in 2009 and is called the Genesis block. It is the common ancestor of all the chunks in the blockchain, which means that you can go back from any chunk and follow the chain, and eventually you will reach the Genesis block.

Because the Genesis block is programmed into the Bitcoin client software, each node starts with a blockchain that contains at least one chunk, which ensures that the creation block will not be changed. Each node "knows" the hash value of the Genesis block, the structure, the time it was created, and a transaction inside it. As a result, each node takes the chunk as the first chunk of the blockchain, thus constructing a secure, trusted root of the block chain.

In Chainparams.cpp you can see that the Genesis block is programmed into the bitcoin core client.

The hash value of the Genesis block is:

0000000000 
19d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

You can search for this chunk hash in any chunk browsing site, such as Blockchain.info, and you'll find a page that describes the chunk content with a link containing this hash value:

https://blockchain.info/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

https://blockexplorer.com/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

Use the Bitcoin core client on the command line:

$ bitcoind getblock 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
{
 "hash": " 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f ",
 " confirmations ": 308321,
 " size ": 285,
 "height": 0,
 "version": 1,
 "Merkleroot": " 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b ",
 " TX ": [" 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b "],
 " Time ": 1231006505,
 " Nonce " : 2083236893,
 "bits": "1d00ffff",
 "difficulty": 1.00000000,
 "Nextblockhash": " 00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048 "
}

The Genesis block contains a hidden message. The input to its Coinbase transaction contains the phrase "The Times 03/jan/2009 Chancellor on brink of second bailout forbanks." This sentence is the front page headline of the Times day, quoting this sentence, both as a description of the time of the block, but also as a half-jokingly reminding people of the importance of an independent monetary system, while telling people with the development of Bitcoin, an unprecedented world monetary revolution will occur.  The message was embedded in the creation block by the creator of Bitcoin. 7.6 Block Connections

The full bitcoin node holds a local copy of the blockchain from the creation block. As new chunks are generated, the local copy of the blockchain is continually updated to extend the chain. When a node receives an incoming chunk from the network, it validates the chunks and then links to the existing blockchain. To establish a connection, a node examines the incoming chunk header and looks for the "parent chunk hash" of the chunk.

Let's assume, for example, that a node has 277,314 chunks in the local copy of the blockchain. The node knows the last chunk is No. 277, 314 chunks, and the chunk header hash for this chunk is: 00000000000000027e7ba6fe7bad39faf3b5a83daed765f05f7d1b71a1632249.

The bitcoin node then receives a new chunk from the network, which is described as follows:

{
 "size": 43560,
 "version": 2,

 "Previousblockhash": " 00000000000000027e7ba6fe7bad39faf3b5a83daed765f05f7d1b71a1632249 ",
 " Merkleroot ":" 5e049f4030e0ab2debb92378f53c0a6e09548aea083f3ab25e1d94ea1155e29d ",
 " Time ": 1388185038,
 " difficulty " : 1180923195.25802612,
 "nonce": 4215469401,
 "TX": [" 257e7497fb8bc68421eb2c7b699dbab234831600e7352f0d9e6522c7cf3f6c77 ",
 #[...many more transactions omitted ...]
 "05cfd38f6ae6aa83674cc99e4d75a1458c165b7ab84725eda41d018a09176634"
 ]
}

For this new chunk, the node finds the hash value of the parent chunk that contains it in the "parent chunk hash value" field. This is the hash value known to the node, which is the hash of the No. 277314 Chunk. Therefore, this chunk is the sub-block of the last chunk in the chain, so the existing blockchain can be expanded. The node adds new chunks to the end of the chain, making the blockchain grow to a new height of 277,315. Figure 7-1 shows a chain that connects three chunks through the parent chunk hash value field.

Figure 7-1 The block is connected in the form of a chain by referencing the hash value of the chunk header of the parent block 7.7 Merkle Tree

Each chunk in the blockchain contains all the transactions that are generated in that chunk and is represented in the Merkle tree.

Merkle Tree is a hash binary tree, which is a data structure used to quickly summarize and verify large data integrity. This binary tree contains a cryptographic hash value. The term "tree" is often used in computer science to describe a data structure with branching, but trees are often inverted, "roots" at the top of the graph and "leaves" in the lower part of the graph, and you will see the corresponding examples in subsequent chapters.

In the Bitcoin network, the Merkle tree is used to sum up all trades in a block, generating a digital fingerprint of the entire set of transactions, and providing an efficient way to check whether a chunk exists for a transaction. Generating a complete Merkle tree requires a recursive hash of the hash node pair and inserts the newly generated hash node into the Merkle tree until only one hash node is left, which is the root of the Merkle tree. The SHA256 algorithm was used two times in the Merkle tree of Bitcoin, so its cryptographic hashing algorithm is also known as double-sha256.

When n data elements are encrypted and inserted into the Merkle tree, you can calculate 2*LOG2 (n) times to check if any of the data elements are in the tree, which makes the data structure very efficient.

The Merkle tree is built from the bottom up. In the following example, we start with a, B, C, D four of the Merkle tree leaves trading, as shown in Figure 7-2. At the beginning, all transactions are not stored in the Merkle tree, but the data is hashed first, and then the hash value is stored to the corresponding leaf node. These leaf nodes are ha, HB, HC, and HD, respectively:

h~a~ = SHA256 (SHA256 (Deal A))

By concatenating the hash value of the adjacent leaf node and then hashing it, the leaf node is then summed up as the parent node. For example, in order to create a parent node Hab, the two 32-byte hash values of child node A and child node B are concatenated into 64-byte strings. The string is then hash two times to produce a hash value for the parent node:

h~ab~=sha256 (SHA256 (h~a~ + h~b~))

Continue similar operations until only one node at the top is left, that is, the Merkle root. The resulting 32-byte hash value is stored in the chunk header, which sums up all the data for four transactions.

Figure 7-2 Compute nodes in the Merkle tree

Because the Merkle tree is a two-fork tree, it requires an even number of leaf nodes. If only an odd number of transactions need to be summed up, then the last trade will be copied to form an even number of leaf nodes, this even number of leaf nodes of the tree is also known as the Balance tree. As shown in Figure 7-3, the C-node is copied a copy.

Figure 7-3 Copying a data node so that the number of data nodes in the entire tree is even

The method of constructing a merkle tree from four trades also applies to constructing merkle trees from any number of trades. In Bitcoin, there are hundreds of thousands of transactions in a single chunk that are very common, and these transactions are summed up in the same way, producing a mere 32 bytes of data as the Merkle root. In Figure 7-4, you will see a tree formed from 16 trades. It is important to note that although the root in the figure looks larger than all the leaf nodes, in fact they are all 32 bytes in the same size. Regardless of whether there is a transaction in the block or 100,000 trades, the Merkle root always summarizes all trades into 32 bytes.

Figure 7-4 A Merkle tree that contains many data elements

To prove that a particular transaction exists in a chunk, a node simply computes a log2 (N) 32-byte hash value, forming an authentication path or Merkle path from a specific transaction to the root of the tree. As the number of transactions increases sharply, such calculations are extremely important, as the logarithm of the number of transactions with a base of 2 is much slower than the increase in the number of trades. This allows the Bitcoin node to efficiently produce a path of 10 or 12 hashes (320-384 bytes) to prove the existence of a transaction in thousands of transactions in a chunk of large byte size.