Table of contents
1. Three types of trees in Ethereum
2. The difference between state tree, transaction tree and receipt tree
3. The purpose of transaction tree and receipt tree
1. Purpose of Transaction Tree and Receipt Tree
2. How to implement complex query operations
3. The purpose of Bloom Filter in Ethereum
4. The operation process of Ethereum
1. Three types of trees in Ethereum
In Ethereum, there are three tree-based data structures — state trees , transaction trees , and receipt trees . All transactions will form a Merkle tree, called a transaction tree, which is similar to the Merkle tree in the Bitcoin system. In addition, a receipt tree is added to Ethereum. After each transaction is executed, a receipt will be formed to record its relevant information. The nodes on the transaction tree and the receipt tree are in one-to-one correspondence. The purpose of adding this receipt tree is to facilitate quick query execution results (mainly because the execution process of Ethereum's smart contract is more complicated).
From the data structure point of view, the transaction tree and the receipt tree are both MPT . Unlike the Bitcoin system, the transaction tree in the Bitcoin system is an ordinary Merkle tree organized by all transactions in the block . MPT is also a Merkle Patricia tree , which is different from the Bitcoin system. For convenience, the three trees in Ethereum all use the same data structure, so that the code is relatively unified and easy to manage . Of course, one advantage of using MPT is that it supports search operations , which can be searched from top to bottom through the tree. . In the state tree, the key value to be searched is the address of the account. For the transaction tree and the receipt tree, the key value to be searched is the serial number of the transaction in the published block. As far as its sorting is concerned, the order of the transaction is It is determined by the node that issued the block.
2. The difference between state tree, transaction tree and receipt tree
(1) The transaction tree and the receipt tree only organize the transactions in the currently released block. The state tree needs to include the status of all accounts in the system, regardless of whether these accounts have anything to do with the transactions of the current block. relation.
(2) In terms of data structure, the state trees of multiple blocks share nodes (when a new block is released, only the nodes whose state has changed in the block need to create a new branch, and other nodes use the original nodes on the state tree), in contrast, the transaction tree and receipt tree of each block are independent and will not share nodes (transactions published by one block and another block are also considered independent of).
3. The purpose of transaction tree and receipt tree
1. Purpose of Transaction Tree and Receipt Tree
Provide Merkle Proof . In the Bitcoin system, the transaction tree can prove that a certain transaction is packaged into a certain block, that is, provide such a Merkle Proof to the light node. The receipt tree is also similar, and can provide Merkle Proof to prove the result of a certain transaction. In addition, Ethereum also supports some more complex query operations. Relevant transactions (one method is to scan all blocks generated in the past ten days to see which transactions are related to smart contracts, but this method has several disadvantages: ① Higher complexity , yes Linear; ②There must be enough storage to save the elements of the entire set; ③Actually , the light node does not have a transaction list, only one block header information, so there is no way to scan all the transaction lists to find the one that meets this query condition Transactions), and similar queries to find all events that match a certain type in the past ten days (for example, all crowdfunding events or all new coin issuance events), these require a more efficient method.
2. How to implement complex query operations
Bloom Filter is introduced in Ethereum . This data structure can support a more efficient search for whether an element is in a relatively large collection . For example, there is a collection with many elements in it. Now I want to know a specific element Is it in this collection. Bloom Filter calculates a very compact summary (such as a 128-bit vector) for this collection containing many elements. For example, there is a set (a,b,c), to calculate the digest, below it is an initial vector of all zeros, there is a hash function H, and each element in the element is hashed and mapped to the vector table , change the element at this position from 0 to 1, as shown in Figure 3-1 below. All the elements in the set are processed in this way, and the resulting vector is a summary of the original set, which is much smaller than the original set.
The usefulness of the summary : Suppose there is an element d, and you want to know whether this d is in a certain set, but the set itself may not be preserved, you can use this hash function H to get the hash value of d, for example, after taking the hash After the value is mapped to a position of 0 in the vector, it means that the element must not be in the set, as shown in Figure 3-2; if the hash value is obtained, it is mapped to a position of 1 in the vector , it does not mean that the element is in the set, it may indeed be an element in the set, d=a, or d is not in the set, but there is a hash collision, which happens to be mapped to the same position as an element in the set , so use Bloom Filter to pay attention, there may be false positives, but false negatives may not appear, that is, false positives may occur, but false negatives may not occur. That is, if the element belongs to the set, it must be judged that the element belongs to the set; if the element does not belong to the set, it may also be judged that the element belongs to the set.
There are various variants of Bloom Filter. In order to solve such hash collisions, sometimes a set of hash functions is used instead of a single hash function to map an element with proof to a vector through each hash function a position in . In general, not all hash functions have hash collisions. The limitation of Bloom Filter is that it does not support delete operation. For example, if a is deleted, do you want to change the corresponding vector 1? If it is changed to 0, there may be another element in the set that is also mapped to this position (hash collision is possible), so a simple Bloom Filter is not Supports delete operations. To support the delete operation, you need to change the value in the vector into a counter to record how many elements are mapped to the position, and you also need to consider whether the counter will overflow. In this way, the data structure is much more complicated, which is contrary to the original intention of designing Bloom Filter, so in general, Bloom Filter does not support deletion operations.
3. The purpose of Bloom Filter in Ethereum
After each transaction is executed, a receipt containing Bloom Filter will be formed. Bloom Filter is used to record the type, address and other information of the transaction. There is also a general Bloom Filter in the block header of the released block, which is the union of a Bloom Filter of all transactions in this block . For example, if you want to find the transactions related to smart contracts that occurred in the past ten days, you can find out which block headers and bloom filters have the required transaction types. If not, this block is not what we want. If so, Then look for the Bloom Filters in the receipt tree corresponding to the transactions contained in the block (for each receipt’s bloom filter) to see which one is there, or there may be none, because it may be false positive. If so, find the corresponding transaction and confirm it directly. The advantage is that the structure of the Bloom Filter can quickly filter out a large number of irrelevant blocks . There are only a lot of blocks. If you look at the Bloom Filter of the block header, you will know that there must be no us. The desired transaction, and then the remaining few candidate blocks, and then look carefully. For example, light nodes only have block header information, and many blocks can be filtered out according to the block header. The remaining blocks may be the ones you want, and you can ask the full node for further information.
4. The operation process of Ethereum
The root hash values of these three trees are all included in the block header. The running process of Ethereum can be regarded as a transaction-driven state machine (Transaction-driven State Machine). The state of this state machine is the state of all accounts, that is, the state The content contained in the tree, the transaction refers to the transaction contained in each release block, and the execution of these transactions will drive the system to move from the current state to the next state. The Bitcoin system can also be considered as a transaction-driven state machine . The state in Bitcoin is UTXO (those outputs that have not been spent). Every time a new block is released, some outputs will be used from UTXO, and it will Add some new output, and the published block will drive the system from the current state to the next state. Moreover, these two state machines have a common feature, that is, the state transition must be deterministic. For a given current state, the transactions contained in a given set of blocks can be deterministically transferred to the next state. . Because all full nodes and all miners must perform the same state transition, the state transition must be deterministic.