What is the merkle trees of the Merkel tree? Reprinted articles in Ether square

Original: https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/
Author: Vitalik Buterin

Meckerschau (Merkle trees) is the basic component of the block chain. Theoretically speaking, though, the block chain without the Merkel tree is certainly possible, and you can do it simply by creating a huge chunk header (block header) that directly contains each transaction, but there is no doubt that this will bring scalability challenges, and in the long run, it may end up with only the most powerful computers, Before you can run these block chains that don't need to be trusted. It is because of the Merkel tree that the etheric square node can be built to run on all computers, notebooks, smartphones, and even those that are produced by slock.it. So how do Meckerschau work, and what value can they offer, now and in the future. First of all, let's start with some basic knowledge. The Merkel tree, in general, is a way of hashing large aggregated data "blocks" (chunk), which relies on dividing the data blocks into smaller units (bucket) of data blocks, each bucket block containing only a few data "blocks", Each bucket unit data block is then hashed again, repeating the same process until the remaining hash count is only 1: the root hash.
The most common and simplest form of the Merkel tree is the Hi Jinche Meckerschau (binary mekle), where a bucket unit's block of data always contains two contiguous blocks or hashes, which are described as follows:


So, what's the advantage of this strange hashing algorithm? Why not just string these data blocks into a single chunk, using a regular hash algorithm. The answer is that it allows a neat mechanism that we call the Merkel proofs (Merkle proofs):


A Merkel certificate contains a block of data, the root hash of the Merkel tree, and a "branch" that contains all the hashes along the block to the root path. It is thought that this proof can verify the process of hashing, at least for the branch. The application is also very simple: suppose there is a large database, and the entire contents of the database are stored in the Merkel tree, and the root of the Merkel tree is open and trustworthy (for example, it is digitally signed by enough believers, or it has a lot of work to prove). So, if a user wants to do a key lookup in the database (for example: "Please tell me the location at 85273"), then he can ask Merkel for proof and receive a correct proof that he received the value that is actually the database in the 85,273-bit specific root. It allows a mechanism to validate a small amount of data, such as a hash, or to validate a large database (which can be extended to infinity).

Merkel proof of bitcoin system
The original application of the Merkel evidence was the bitcoin system (Bitcoin), which was described and created by the Ben Cong (Satoshi Nakamoto) in 2009. The Bitcoin block chain uses the Merkel certificate to store the transaction in each block:


The advantage of this is that the concept of "simplified payment Verification" (SPV) as described in Ben Cong: Instead of downloading every transaction and every chunk, a "light client" (light client) can download only the chunk header of the chain, with only five items per block and a block size of 80 bytes:
Hash value of upper block size time stamp mining difficulty value workload proof random number (Nonce) contains the root hash of the Merkel tree in the block transaction
If a light client wants to determine the status of a transaction, it can simply require a Merkel certificate to show a particular transaction in the Merkel tree, whose root is the block header on the main chain (main chain, the fork chain).
It will let us go very far, but Bitcoin's light customers do have its limitations. A particular limitation is that although they can prove to contain transactions, they cannot prove any current status (e.g., the holding of digital assets, name registration, status of financial contracts, etc.). How many bitcoin you have now. A bit-currency light client can use a protocol that involves querying multiple nodes and believes that at least one node will notify you about any particular transaction expense in your address, which allows you to implement more applications. But for other, more complex applications, these are far from enough. The exact nature of the impact of a transaction can depend on several previous deals, which themselves rely on a more precise transaction, so eventually you can verify every transaction on the chain. In order to solve this problem, the concept of the Angela Tree of the etheric square will go further.

The Merkel certificate of the ether square
Each of the block heads of the etheric square, not only contains a Merkel tree, but contains three Merkel trees, corresponding to three different objects:
Transaction (transactions) receipt (receipts, basically, it is a data bar showing the impact of each transaction) status (state)


This makes a very advanced light client protocol possible, allowing light clients to easily and verify the following types of query answers:
Is the transaction included in a particular block? Tell me this address. In the last 30 days, all instances of X-type events have been issued (e.g., a public-funded contract has completed its goal) what is the current balance of my account? Whether this account exists. Pretend to run the deal in this contract and what its output will be.
The first is handled by the trading tree (transaction); The third and fourth species are handled by the state tree, and the second by the receipt tree (receipt). The first four query tasks are fairly straightforward to calculate. The server simply finds the object, acquires the Merkel branch, and responds to the light client by branching.
The fifth query task is also handled by the state tree, but it can be calculated in a more complex way. Here, we need to build a proof of what we call the Merkel state transition (Merkle states transition proof). In essence, the proof is that "if you run a trade T on the state tree of the root s, the resulting state tree will be the root for s ', log l, Output o ' (" Output "as a concept that exists in the ether square, because each transaction is a function call, it is not theoretically necessary).
To infer this proof, the server creates a fake block locally, sets the state to S, and pretends to be a light client and requests the transaction. In other words, if the process of requesting this transaction requires the client to determine the balance of an account, the light client will issue a balance question. If this light client needs to check for a specific item stored in a particular contract, the light client will issue this to the query. The server will correctly "respond" to all its queries, but the server will also track all the data it sends back. The server then sends the consolidated data to the client. The client will do the same step, but will use the proofs provided by its database. If the result is the same as that required by the server, the client will accept the certificate.



Patricia (Patricia trees)
As we mentioned earlier, the simplest kind of Meckerschau is the Hi Jinche Merkel tree. However, the Merkel tree used in the ether is more complex, which we call "Merkel Patricia" (Merkle Patricia), as mentioned in our documentation. This article does not elaborate on its concept. If you want to know, you can find the answer in this and this article, in this article, I will just discuss the basic argument.
Binary Meckerschau is a very good data structure for validating the information in the "manifest" format, which is essentially a series of contiguous blocks of data. They are also good for trading trees, because once the tree has been built, it doesn't matter how much time it takes to edit the tree, once it is established, it will always be there.
For the state tree, the situation is more complicated. The state tree in the etheric square basically contains a key value mapping, where the key is the address and various values, including the statement of the account, the balance, the random number, the code, and the storage of each account (where the store itself is a tree). For example, the founding status of the modern Test network (the Morden Testnet) is as follows:

{"0000000000000000000000000000000000000001": {"balance": "1"}, "0000000000000000000000000000000000000002": {" Balance ":" 1 "}," 0000000000000000000000000000000000000003 ": {" balance ":" 1 "}," 0000000000000000000000000000000000000004 ": {" balance ":" 1 "}," 102e61f5d8f9bc71d0ad4a084df4e65e05ce0e1c ": {" balance ': ' 1606938044258990275541962092341162602522202993782792835301376 '}} However, unlike transaction history, The state tree needs to be updated regularly: account balances and random numbers of accounts nonce often accounts, and more importantly, new accounts are frequently inserted, and stored keys (key) are often inserted and deleted. With such a data structure, we can quickly calculate a new root (tree root) after inserting, updating, or deleting an operation, without having to recalculate the entire trees. In addition, it has two very good secondary features:
The depth of the tree is limited, even if it is considered that the attacker would deliberately make some transactions, making the tree as deep as possible. Otherwise, an attacker could perform a denial-of-service attack (DOS attack) by manipulating the depth of the tree, making the update extremely slow. The root of the tree depends only on the data, regardless of the update order. Updating in a different order, or even computing the tree from the beginning, does not change the root.
And Patricia, to put it simply, perhaps the closest explanation is that we can implement all of these features at the same time. The simplest explanation for how it works is a value that is stored in encoded form into the "path" of the record tree. Each node will have 16 children (children), so the path is determined by hexadecimal encoding: for example, the key of a dog (dog) is encoded as 6 4 6 15 6 7, so you start with this root, drop to sixth, then fourth, and so on, until you reach the end point. In practice, there are some additional optimizations when trees are scarce, and we make the process more efficient, but this is the basic principle.