http://www.btckan.com/news/topic/14827
Meckerschau (Merkle trees) is a fundamental part of the blockchain. While it is theoretically possible to have a blockchain without a Merkel tree, you can do so by creating a huge chunk header (block header) that directly contains each transaction, but this will undoubtedly lead to scalability challenges that, in the long run, may end up with only the most powerful computers, To run these no-trusted blockchain. Thanks to the Merkel tree, ethereum nodes are built to run on all computers, laptops, smartphones, and even IoT devices 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 a bit of basic knowledge. The Merkel tree, in general, is a way of hashing large aggregates of data "chunks" (chunk), which relies on splitting the data "blocks" into smaller units (buckets) of data blocks, each of which contains only a few data "blocks", The data block of each bucket unit is then hashed again, repeating the same process until the remaining number of hashes becomes only 1: the root hash (root hashing).
The most common and simplest form of the Merkel tree is the Hi Jinche Meckerschau (binary mekle tree), where the data block of a bucket unit always contains two contiguous blocks or hashes, which are described as follows:
So what are the benefits of this strange hashing algorithm? Why not simply string these chunks of data into a single chunk, using a regular hashing algorithm. The answer is that it allows for a neat mechanism that we call the Merkel proof (Merkle proofs):
A Merkel certificate contains a data block, the root hash of the Merkel tree, and a "branch" that contains all the hashes along the block to the root path. It has been argued that this proof can validate the hash process, at least for the branch. The application is also 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 public and credible (for example, it is digitally signed by enough multiple trusted parties, or it has a lot of proof of work). So, if a user wants to do a key-value lookup in the database (for example, "Please tell me where the object is in 85273"), then he can ask the Merkel certificate and receive a correct proof that the value he received is actually a specific root of the database in the 85,273-bit position. It allows a mechanism to validate a small amount of data, such as a hash, or to validate a large database (which may extend to infinity).
The Merkel certificate of the Bitcoin system
The original application of the Merkel evidence is the bitcoin system (Bitcoin), which was described and created by Nakamoto (Satoshi Nakamoto) in 2009. The Bitcoin blockchain uses the Merkel certificate in order to store the transaction in each chunk:
The benefit of this is the concept of "simplified payment Verification" (SPV) described in Nakamoto: instead of downloading every trade and every chunk, a "light client" can download only the chunk header of the chain, with only five items in each chunk and a block size of 80 bytes:
The hash of the upper block. Time stamp mining difficulty value work proof random number (nonce) the root hash of the Merkel tree that contains the chunk transaction
If a light client wants to determine the status of a trade, it can simply ask for a Merkel certificate that shows a particular transaction in the Merkel tree whose root is the chunk header on the main chain (main chain, non-fork chain).
It will take us a long way, but Bitcoin's light customers do have their limitations. A special limitation is that although they can prove the included transactions, they cannot prove any current status (e.g., holding of digital assets, name registration, status of financial contracts, etc.). How many bitcoins do you have now? A bitcoin 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, and this 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 deal (precise nature) can depend on the previous transactions, which in itself depend on the more previous trades, so you can eventually verify every trade on the chain. To solve this problem, the concept of the Merkel tree in Ethereum will be further.
The Merkel proof of ethereum
Each chunk of Ethereum's head is not just a Merkel tree, but contains three Merkel trees, each of which corresponds to three objects:
Transaction (transactions) receipt (receipts, basically, it is the data bar that shows the impact of each trade) status (state)
This makes it possible to have a very advanced Light client protocol, which allows light clients to easily perform and verify the following types of query answers:
Is this transaction included in a specific chunk? Tell me this address. In the last 30 days, all instances of the X type event (for example, a crowdfunding contract has completed its goal) are currently in my account balance. Whether this account exists. Pretend to run the deal in this contract, what its output will be.
The first is handled by the transaction tree, and the third and fourth are handled by the state tree, and the second is handled by the receipt tree (receipt tree). It is fairly straightforward to calculate the first four query tasks. The server simply finds the object, gets the Merkel branch, and replies to the light client through the branch.
The fifth query task is also handled by the state tree, but it is more complex to calculate. Here, we need to build the proof that we call the Merkel state transition (Merkle-transition proof). Essentially, the proof is that "if you run trade T on the root s state tree, the result state tree will be the root s ', log is L, and the output is O" ("Output" as a concept that exists in Ethereum because each transaction is a function call, which is theoretically not necessary).
To infer this proof, the server creates a fake chunk locally, sets the state to S, and pretends to be a light client, requesting the transaction. In other words, if the process of requesting the 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 specific contract, that light client will issue a query against it. The server correctly "responds" to all of its queries, but the server also keeps track of all the data it sends back. The server then sends the synthetic data to the client. The client will perform the same steps, but will use the proof provided by its database. If the result is the same as the server requires, the client accepts the certificate.
Patricia (Patricia Trees)
As we mentioned earlier, one of the simplest Meckerschau is the Hi Jinche Merkel tree. However, the Merkel tree used by ethereum is more complex and we call it "Merkel Patricia" (Merkle Patricia Tree), which is 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 only discuss the basic argument.
Binary Meckerschau It is a very good data structure for verifying the information in the "manifest" format, which is essentially a series of contiguous blocks of data. For the trading tree, they are also good, because once the tree has been established, it doesn't matter how much time it takes to edit the tree, and once the tree is established, it will always be there.
The situation is more complicated for the state tree. The state tree in Ethereum basically contains a key-value mapping in which the key is the address with 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 state 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 the transaction history, The state tree needs to be updated frequently: The nonce of the account balance and the account is often notconsistent, and more importantly, the new account is frequently inserted, and the stored key (key) is often inserted and deleted. With this data structure design, we can quickly calculate the new root (tree root) after an insert, update edit, or delete operation, without having to recalculate the entire tree. In addition, it has two gray-good secondary features:
The depth of the tree is limited, even if it is considered that the attacker would deliberately make some trades, 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 a tree depends only on the data, and not on the order in which it is updated. Updating in a different order, or even re-calculating the tree from scratch, 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 the value of a "path" that is stored in encoded form to the record tree. Each node will have 16 children (children), so the path is determined by hexadecimal encoding: for example, the dog's key is encoded as 6 4 6 15 6 7, so you will start from this root, descend to the sixth son, then to the fourth, and so on until you reach the end. In practice, there are additional optimizations when trees are scarce, and we make the process more efficient, but this is the basic principle.
Original: https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/
Author: Vitalik Buterin
Compile: Free and easy hi
Zebian: Carefree and happy
Manuscripts (translated): Babbitt information
