Blockchain development topics (real blockchain definition)

' Blockchain enthusiasts (qq:53016353)

A real 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 true blockchain metadata. Chunks are sequentially linked from the back to the chain, with each chunk pointing to the previous block. The real 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, you can identify the corresponding chunks in the real blockchain. 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 real 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 "true blockchain fork." A true 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 true Blockchain fork"). In the end, only one chunk becomes part of the real blockchain and solves the "real 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 real blockchain can make the true blockchain history immutable, which is a key feature of bitcoin security.
You can think of a real 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 a real blockchain, the last few blocks may be modified due to a recalculation of the true 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 real blockchain, the less likely it is to be changed. After 100 blocks, the real blockchain is stable enough to be paid for Coinbase transactions (transactions that contain newly dug bitcoins). After thousands of blocks (one months) the real blockchain 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 (a real 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 byte chunk size The chunk size in bytes after the field
80-byte chunk header several fields that make up a chunk header
1-9 (variable integer) Number of trade counter trades
Trading information for variable transactions in chunks
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 real 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-byte version version number for tracking software/protocol updates
32-byte parent chunk hash value refers to the hash value of the parent chunk in the true chunk chain
32 bytes Merkle Root hash of merkle roots traded in this chunk
4 bytes Timestamp The approximate time generated by the chunk (the UNIX timestamp is accurate to the second)
4-byte difficulty target the difficulty target of the block workload proving algorithm
4-byte Nonce counter for 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 persistent storage device of a node as part of a real chunk chain. 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 real 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 then stored on top of the first chunk in the real blockchain is "high" from the previous block, 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 real blockchain. This situation is discussed in detail in the section "8.10.1 True Blockchain forks." Block height is not part of the chunk data structure, it is not stored in chunks. When a node receives chunks from a bitcoin network, it dynamically identifies the location (block height) of the chunk in the real blockchain. 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 one location in the block.
7.5 Genesis Block
The first chunk in the real blockchain was created in 2009 and is called the Genesis block. It is a common ancestor of all the chunks in the real blockchain, which means that you can go back from any chunk, follow the chain, and eventually reach the Genesis block.
Because the Genesis block is programmed into the Bitcoin client software, each node starts with a real 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 a real blockchain, creating a secure, authentic root of the blockchain.
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:
$ bitcoindgetblock 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f{"hash": " 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f "," confirmations ": 308321," size ": 285," height ": 0 , "version": 1, "Merkleroot": "4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b", "TX": ["4a5e1e4baa b89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b "]," 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 real blockchain from the creation block. As new chunks are generated, the local copy of the real 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 real 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 true 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": "00000000000000027e7ba6fe7bad39faf3b5a83daed765f05f7d1b71a163224 9 "," Merkleroot ":" 5e049f4030e0ab2debb92378f53c0a6e09548aea083f3ab25e1d94ea1155e29d "," Time ": 1388185038," Difficul Ty ": 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. So this chunk is the sub-block of the last chunk in the chain, so the existing real blockchain is expanded. The node adds new chunks to the end of the chain, making the true 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 Block is connected as a chain by referencing the hash value of the chunk header of the parent chunk
7.7 Merkle Tree
Each chunk in the real 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.
In Figure 7-5, a node can prove that there is a trade k in a chunk by generating a merkle path with only 4 32-byte hash length (total 128 bytes). The path has 4 hashes (shown in Figure 7-5 in blue) HL, HIJ, Hmnop, and HABCDEFGH. The authentication path generated by these 4 hashes, and then by calculating the additional four pairs of hashes hkl, HIJKL, Hijklmnop, and Merkle tree roots (labeled by dashed lines in the diagram), any node can prove that HK (shown by green callout) is included in the Merkle root.


Figure 7-5 A Merkle path used to justify a data element contained in a tree
The code in example 7-1 borrows some of the auxiliary programs in the Libbitcoin library, demonstrating the process of creating the entire Merkle tree from the leaf node Hashits root.
Example 7-1 constructing a merkle tree
#include bc::hash_digest create_merkle (bc::hash_digest_list& merkle) {//Stop if hash list is empty.    if ( Merkle.empty ())        return Bc::null_hash;    else if (merkle.size () = = 1)        return merkle[0];    //While there are more than 1 hashes in the list, keep looping ...    while (merkle.size () > 1) &nbs P   {       //If number of hashes is odd, duplicate last hash in the list.       & Nbsp;if (Merkle.size ()% 2! = 0)            merkle.push_back (Merkle.back ());        //List size is now even.        assert (merkle.size ()% 2 = = 0);        //New hash list.        bc::hash_digest_list New_merkle;        //Loop through hashes 2 at a time.        for (Auto it = Merkle.begin (); It! = Merkle.end (); it + = 2)         {           //Join both current hashes together (concatenate).           &NBSP;BC::d ata_chunk concat_data (bc::hash_size * 2);            auto concat = Bc::make_serializer (Concat_data.begin ());            concat.write_hash (*it);            concat.write_hash (* (it + 1));            assert (concat.iterator () = = Concat_data.end ());            //Hash both of the hashes.            bc::hash_digest new_root = Bc::bitcoin_hash (Concat_data);            //ADD this to the new list.            new_merkle.push_back (new_root);                    }        //This is the new list.        merkle = nEw_merkle;        //DEBUG output-------------------------------------       std::cout &lt ;< "Current Merkle hash list:" << Std::endl;        for (const auto& hash:merkle)            std::cout << "<< Bc::encode_hex (hash) << Std::endl;        std::cout << Std::endl;        //--------------------------------------------------   }    //Finally We end up with a single item.    return Merkle[0]; }int Main () {   //Replace these hashes with ones from a block to reproduce the same Merkle root.   &NBSP;B C::hash_digest_list tx_hashes{       {          &NBSP;BC::d ecode_hash ("000 0000000000000000000000000000000000000000000000000000000000000 "),           &NBSP;BC::d Ecode _hash ("0000000000000000000000000000000000000000000000000000000000000011 "),           &NBSP;BC::d Ecode_hash (" 0000000000000000000000000000000000000000000000000000000000000022 "),        }    };    const Bc::hash_digest merkle_root = Create_merkle (tx_hashes);    std::cout << "Result:" << bc::encode_hex (merkle_root) << Std::endl;    return 0;}
Example 7-2 shows the result of compiling and running the above code.
Example 7-2 compiling and running construction Merkle tree code
$ # Compile The merkle.cpp code$ g++-o merkle merkle.cpp $ (pkg-config--cflags--libs libbitcoin) $ # Run the Merkle exec utable$./merklecurrent Merkle Hash List : 32650049A0418E4380DB0AF81788635D8B65424D397170B8499CDC28C4D2700630861DB96905C8DC8B99398CA1CD5BD5B84AC3264A4E1B3E65AFA1BC Ee7540c4current Merkle Hash List:d47780c084bad3830bcdaf6eace035e4c6cbf646d103795d22104fb105014ba3result: D47780c084bad3830bcdaf6eace035e4c6cbf646d103795d22104fb105014ba3
The efficiency of the merkle tree becomes more pronounced as the transaction size increases. Table 7-3 shows the amount of data needed to convert to a Merkle path in order to prove that a transaction exists in the chunk.
Table 7-3 Efficiency of Merkle Tree
Approximate size path size (hash quantity) path size (bytes) for the number of transactions block
16 Trades 4KB 4 Hashes 128 bytes
512 Trades 128KB 9 hashes 288 bytes
2048 Trades 512KB 11 hashes 352 bytes
65,535 Trades 16MB 16 hashes 512 bytes
Depending on the table, when the chunk size is sharply increased from 16 trades (4KB) to 65,535 trades (16MB), the length of the Merkle path to prove the existence of the transaction grows extremely slow, from 128 bytes to 512 bytes only. With the Merkle tree, a node can download only the chunk header (80 bytes/chunk) and then, by backtracking a small merkle path from a full node, can certify the existence of a transaction without having to store or transmit a large number of true blockchain content, which may have several G sizes. This node, which does not need to maintain a complete real blockchain, is also known as a simple payment verification (SPV) node, and it does not need to download the entire chunk and verify the existence of the transaction through the Merkle path.
7.8 Merkle tree and simple payment verification (SPV)
Merkle trees are widely used by SPV nodes. SPV node does not save all transactions will not download the entire block, just save the chunk header. They use either the authentication path or the Merkle path to verify that the transaction exists in the chunk without having to download all the transactions in the chunk.
For example, a SPV node wants to know the payment of a Bitcoin address in its wallet, which establishes a bloom filter on the communication link between nodes, restricting only transactions that contain the destination Bitcoin address. When the node detects that a transaction complies with the Bloom filter, it sends the chunk in the form of a merkle chunk message. The Merkle chunk message contains the block header and a merkle path that connects the target transaction to the Merkle root. The SPV node can use this path to find the block associated with the transaction, and then verify that the transaction is in the corresponding block. The SPV node also uses chunk headers to correlate chunks and blocks in the real blockchain. These two associations, trading with chunks, chunks and real blockchain, prove that transactions exist in real blockchain. In short, the SPV node receives less than 1KB of data on the block size and Merkle path of the area, and its data volume is 1000 times times less than a full chunk (currently about 1MB).