A method and system for replaying historical transactions based on smart contracts

Abstract

This invention relates to the field of smart contract testing technology, and proposes a method and system for replaying historical transactions based on smart contracts, comprising the following steps: modeling transaction characteristics based on Ethereum's state changes, and configuring transaction filtering rules based on the transaction characteristics; constructing a world temporary state tree based on Patricia Merck trees and binary search trees; creating a fake block, filtering transactions in the original transaction list based on the transaction filtering rules and adding them to the fake block; backtracking based on the historical states stored in the world temporary state tree, constructing a fake world state tree and adding it to the fake block; Ethereum running the fake block, the fake block performing historical transaction replay to repair the contract, comparing the repaired contract with the original contract, and writing the comparison result to a log.

Description

Technical Field

[0001] This invention relates to the field of smart contract testing technology, and more specifically, to a method and system for replaying historical transactions based on smart contracts. Background Technology

[0002] Smart contracts are programs deployed on a blockchain that determine how transactions occur through a set of rules, enabling automated and distributed transactions. However, because smart contracts carry financial attributes and are immutable after deployment, they become targets for hackers. Therefore, vulnerability prevention methods are needed to ensure the security of smart contracts.

[0003] Existing vulnerability prevention solutions fall into three categories: off-chain vulnerability prevention, on-chain vulnerability prevention, and vulnerability remediation. Off-chain vulnerability prevention employs techniques such as symbolic execution, fuzzing, and pattern matching to construct vulnerability detection methods, aiming to ensure the security of contracts before deployment to the blockchain. On-chain vulnerability prevention focuses on the security of contracts after deployment, by embedding specific vulnerability detection programs into smart contracts or the Ethereum Virtual Machine (EVM). When a specific vulnerability is detected, the transaction is backtracked, thereby ensuring the security of the contract after deployment. Vulnerability remediation uses bytecode rewriting technology to fix smart contracts with vulnerabilities on-chain.

[0004] Vulnerability patching is accompanied by contract testing to prevent patches from breaking the original functionality of the contract. Currently, transaction replay technology is mainly used for contract testing. For example, historical transaction replay is implemented based on EVM state storage instructions (RODLER M, LI W, KARAME GO, et al. EVMPatch: Timely and Automated Patching of Ethereum SmartContracts [C] / / 30th USENIX Security Symposium (USENIX Security 21). 2021:1289-1306.) to detect abnormal changes in patched contracts. However, the implementation of this transaction replay scheme depends on the trampoline mechanism and lacks universality. Hartel et al. proposed historical transaction replay based on Truffle (HARTEL P, STAALDUINEN M. Truffle Tests for Free-Replaying Ethereum Smart Contracts for Transparency [R / OL]. [2019-04-13] http: / / arxiv.org / abs / 1907.09208.). This scheme does not depend on a specific mechanism and has universality. However, because historical states change during transaction replay, it is impossible to accurately replay all transactions. Kim et al. proposed achieving transaction replay by preserving historical states, thus enabling accurate replay of all transactions (KIM Y, JEONG S, JEZEKK, et al. An Off-the-Chain Execution Environment for Scalable Testing and Profiling of Smart Contracts.[C] / / USENIX Annual Technical Conference.2021:565-579.). However, due to the lack of modeling of transaction characteristics, this scheme cannot filter specific types of transactions, thus losing scalability. Furthermore, this scheme does not optimize the storage method of historical states, increasing storage consumption. Summary of the Invention

[0005] To overcome the shortcomings of existing transaction replay methods, such as the inability to filter specific types of transactions, lack of scalability, and high storage consumption, this invention provides a historical transaction replay method and system based on smart contracts.

[0006] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:

[0007] A method for replaying historical transactions based on smart contracts includes the following steps:

[0008] S1. Model transaction characteristics based on Ethereum state changes, and configure transaction filtering rules based on the transaction characteristics;

[0009] S2. Construct a world temporary state tree based on Patricia Merck tree and binary search tree;

[0010] S3. Create a fake block: filter and select transactions in the original transaction list based on the transaction filtering rules and add them to the fake block; backtrack according to the historical states stored in the world temporary state tree, construct a fake world state tree and add it to the fake block;

[0011] S4. Ethereum runs the forged block, which performs historical transaction replay to repair the contract, compares the repaired contract with the original contract, and writes the comparison result to the log.

[0012] Furthermore, this invention also proposes a historical transaction replay system based on smart contracts, applying the historical transaction replay method proposed in this invention. This includes:

[0013] The rules management module is used to model transaction characteristics based on Ethereum state changes and configure transaction filtering rules based on the transaction characteristics to filter transactions of target types.

[0014] The information aggregation module is configured with a world temporary state tree built on Patricia Merck tree and binary sort tree, which is used to store Ethereum's temporary and persistent information.

[0015] The transaction replay module is used to repair contracts by creating fake blocks and replaying historical transactions based on the fork mechanism. The repaired contract is then compared with the original contract, and the comparison result is written to the log.

[0016] The forged block is configured with filtering transactions (tx) that filter transactions in the original transaction list based on the transaction filtering rules. filter And a fake world state tree constructed by backtracking based on the historical states stored in the world temporary state tree.

[0017] Compared with existing technologies, the beneficial effects of the technical solution of this invention are as follows: This invention models transaction characteristics and configures transaction filtering rules based on Ethereum state changes for further transaction type filtering, which can effectively enhance the scalability of transaction replay; it constructs a world temporary state tree based on Patricia Merck tree and binary search tree to store Ethereum temporary information, which can effectively optimize storage space; and it achieves local transaction replay based on the fork mechanism by creating fake blocks, which can replay historical transactions without interfering with the main chain and avoid destroying the original functionality of the contract. Attached Figure Description

[0018] Figure 1 This is a flowchart of the smart contract-based historical transaction replay method of the present invention.

[0019] Figure 2 This is a diagram of the architecture of the world's temporary state tree.

[0020] Figure 3 This is a schematic diagram of the historical transaction block tree search process.

[0021] Figure 4 This is a flowchart illustrating the process framework for transaction replay based on a fork mechanism.

[0022] Figure 5 This diagram illustrates the space consumption of the three tools under different numbers of blocks.

[0023] Figure 6 A diagram illustrating the time consumption for replaying transactions for different contract accounts.

[0024] Figure 7 This is an architecture diagram of the smart contract-based historical transaction replay system of the present invention. Detailed Implementation

[0025] The accompanying drawings are for illustrative purposes only and should not be construed as limiting the scope of this patent; it is understandable that some well-known descriptions in the drawings may be omitted in order to better illustrate this embodiment.

[0026] The technical solution of the present invention will be further described below with reference to the accompanying drawings and embodiments.

[0027] Example 1

[0028] This embodiment proposes a method for replaying historical transactions based on smart contracts, such as... Figure 1 The diagram shown is a flowchart of the smart contract-based historical transaction replay method of this embodiment.

[0029] The historical transaction replay method based on smart contracts proposed in this embodiment includes the following steps:

[0030] S1. Model transaction characteristics based on Ethereum state changes, and configure transaction filtering rules based on the transaction characteristics.

[0031] S2. Construct a world temporary state tree based on Patricia Merck tree and binary search tree.

[0032] S3. Create a fake block. Filter and select transactions from the original transaction list based on the transaction filtering rules and add them to the fake block. Backtrack according to the historical states stored in the world temporary state tree, construct a fake world state tree, and add it to the fake block.

[0033] S4. Ethereum runs the forged block, which performs historical transaction replay to repair the contract, compares the repaired contract with the original contract, and writes the comparison result to the log.

[0034] In this embodiment, transaction characteristics are modeled and transaction filtering rules are configured based on Ethereum's state changes for further transaction type filtering, which can effectively enhance the scalability of transaction replay. A world temporary state tree is constructed based on Patricia Merck tree and binary search tree to store Ethereum's temporary information, which can effectively optimize storage space. Local transaction replay based on the fork mechanism is achieved by creating fake blocks, which can replay historical transactions without interfering with the main chain and avoid destroying the original functionality of the contract.

[0035] In an optional embodiment, in step S1, the Ethereum state change process includes:

[0036] Using state transition function Y to drive block B on the blockchain. t Growth into B t+1 The state σ on block t t Updated to σ t+1 And generate a receipt r based on the transaction status;

[0037] When the block's transactions are non-shutdown transactions, the state transition function Υ changes the state σ through the EVM state change function E and the transaction state change function T. t Updated to σ t+1 And generate a successful receipt. s When the block's transactions are halted transactions, the state σ is... t Keep it unchanged and generate a failure receipt r f ;

[0038] The EVM state change function E is described by the instruction information ins;

[0039] Then, based on the state changes in Ethereum, the transaction characteristics are modeled to obtain the transaction characteristic tx = (B, ins, σ, r); where B is the block, σ is the state, and r = {r s ,r f}

[0040] Further optionally, transaction filtering rules are configured based on the transaction features, wherein the transaction features tx are connected by operators to define the transaction filtering rules.

[0041] The operators include relational operators and / or logical operators.

[0042] As an example, relational operators include greater than, less than, equal to, and not equal to; logical operators include AND, OR, and NOT.

[0043] In an optional embodiment, in step S2, a world temporary state tree is constructed based on a Patricia Merkle tree and a binary sort tree, including the following steps:

[0044] Construct a first-order tree based on the Patricia Merkle tree as the world account tree A tmp , construct a second-order tree based on the binary sort tree as the historical transaction block tree H tmp , the world account tree A tmp and the historical transaction block tree H tmp are combined to construct the world temporary state tree σ tmp .

[0045] As an exemplary illustration, as Figure 2 shown, it is the architecture diagram of the world temporary state tree of this embodiment. Among them, in the world account tree A <00, the account address is used as the key, and the root hash value in the historical transaction block tree H tmp is used as the value; in the historical transaction block tree H tmp , the block number is used as the key, and the status data of the accounts under the corresponding block is used as the value. The status data of the accounts under the corresponding block includes associated accounts, blockHash, ins, nonce, balance, storageRoot, codeHash, etc.

[0046] Further, in an optional embodiment, the world temporary state tree σ tmp is also used to determine the starting state and the ending state of the current block currBlock to provide temporary information. The specific steps include: <>

[0047] Initialize the right adjacent block nextBlock to null, and initialize the target block number target to the block number of the current block currBlock.num + 1;

[0048] Depth-first traverse the node node until the node node traverses to a null node, that is, node ≠ null;

[0049] During the depth-first traversal process, judge the value of the node block number node.num:

[0050] If node.num > target, assign the node node to the right adjacent block nextBlock, and assign the node node to its left node node.left;

[0051] If node.num < target, assign the node node to its right node node.right;

[0052] ​If node.num = target, then assign the right neighboring block nextBlock to node and return the right neighboring block nextBlock;

[0053] After the depth-first traversal is completed, return to the right nearest block, nextBlock;

[0054] Based on the current block currBlock and its right neighboring block nextBlock, obtained through depth-first traversal, from the world temporary state tree σ tmp The start and end states of the current block currBlock are obtained as temporary information.

[0055] As an example, such as Figure 3 The diagram shown illustrates the historical transaction block tree search process. The historical transaction block tree H... tmp The block tree H consists of blocks with block numbers <10,20,30,34,47,44,80>. The initial node is 34. The next block (nextBlock) is the right neighbor of the current block currBlock (10). In this embodiment, the historical transaction block tree H is traversed in a depth-first manner starting from node. tmp The traversal path is 34>20>10>20, and the block number corresponding to the right neighboring block nextBlock is 20. This gives us the termination status of the current block currBlock.

[0056] Further, optionally, the world state tree is also used to obtain persistent information about Ethereum by injecting detection code into the Ethereum database.

[0057] The persistent information in Ethereum refers to information stored in the Ethereum database, which can be directly obtained through database indexes.

[0058] Furthermore, in an optional embodiment, step S3 specifically includes the following steps:

[0059] S310. Based on the transaction filtering rules, locate the transaction block that needs to be replayed, i.e., the original block B. ori Copy the original block B to its location. ori Content, constructing a forged block B fake This can cause a fork.

[0060] Among them, forged block B fake With the original block B ori They share a common parent block B pre This leads to a branching.

[0061] S320. Construct rules based on transaction features (B, ns,,) and operators to filter transactions and obtain transaction tx.rule ={tx i | rule ( i )} and related party transactions tx rel ; among which tx i This represents the i-th transaction, where i ∈ {0, 1, ..., n}, and n is the total number of transactions; the function satisfy rule Indicates when a transaction is made (tx) i Returns true if the rule is met, otherwise returns false; retrieves transaction tx. rule Related party transactions tx rel The intersection of the filtering transactions tx filter (i.e., tx) filter =tx rule ∩tx rel And add it to the forged block.

[0062] S330. Obtain historical states from the world temporary state tree and backtrack, then fix the code C. rep Inject Repair Contract S Crep , obtain the fake world state tree σ fake and the forged world state tree σ fake Add to the forged block.

[0063] This embodiment uses a fork mechanism to replay historical transactions without interfering with the main chain, thus avoiding damage to the original functions of the main chain.

[0064] Alternatively, in this embodiment, the consistency between the receipts of the repair contract and the original contract is compared, and the comparison results are written to the log.

[0065] Optionally, in step S330, when obtaining historical states from the world temporary state tree and performing backtracking, only the repair contract S is backtracked. Crep Associated account SC rep The historical status of the transaction and the execution of related transactions. rel .

[0066] In this embodiment, only the contract S is backtracked for repair. Crep Associated account SC rep The historical status of the transaction and the execution of related transactions. rel This can effectively speed up playback and reduce playback time.

[0067] Optionally, step S3 may further include the following steps:

[0068] S301. Traverse all transactions in all blocks, and configure the account addresses representing the source (from) and destination (to) in the transaction metadata to be explicitly directly related accounts SC. ex.

[0069] S302. Traverse the contract account execution stack and configure the account invoked by the instruction CALL or DELEGATECALL as the implicitly directly associated account SC. im .

[0070] S303, retrieve the explicit directly associated account SC ex The implicitly directly associated account SC im The union of the direct related accounts SC dir And store it in the world temporary state tree σ tmp middle.

[0071] S304. Initialize the associated account table `accountList` collection for the search account `account`, removing duplicate elements; initialize the exploration queue `q` and start searching for the direct associated account `account` `SC`. dir Let q be the initial value of the queue.

[0072] S305. Based on the exploration queue q, explore directly related accounts with breadth until the queue is empty, i.e., len(q)>0; in each exploration, determine the head account of the exploration queue q and find its directly related accounts, and obtain the set of directly related accounts relations←getDirectRealitions(q.pop(),block); then traverse each account relation in the set of directly related accounts relations, and add elements that do not exist in the related account table accountList to the exploration queue q and the related account table accountList.

[0073] S306. Obtain all associated accounts SC of the searched account through the associated accountList table. rep Iterate through all transactions and find those transactions whose metadata indicates the source or destination and includes the associated account SC. rep The transaction yields related transaction tx rel .

[0074] like Figure 4 The diagram shown is a flowchart of the transaction replay process based on the fork mechanism in this embodiment.

[0075] In this embodiment, transaction replay speed is optimized by linking accounts, and to further accelerate replay speed, only contract S is backtracked for repair. Crep By linking the historical status of accounts, the time spent on replay can be reduced.

[0076] Example 2

[0077] This embodiment uses the historical transaction replay method proposed in Embodiment 1 for further explanation.

[0078] This embodiment uses the historical transaction replay method proposed in Embodiment 1 to form the tool SCTester, and compares it with similar tools Kim and the full storage solution implementation tool Full Node.

[0079] like Figure 5 The diagram illustrates the space consumption of the three tools under different block counts. The space consumption of the three tools increases with the number of blocks, and the difference in space consumption gradually widens. When the number of blocks is 1 million, FullNode consumes 1281MB, Kim consumes 1007MB, and SCTester consumes 789MB. Compared to FullNode and Kim, SCTester, which uses the historical transaction replay method of this invention, reduces storage space by 38.42% and 21.63% respectively, thus demonstrating good performance in terms of space consumption.

[0080] like Figure 6 The diagram illustrates the time consumption for transaction replay across different contract accounts. Specifically, SCTester, using the historical transaction replay method of this invention, executes only related transactions. Compared to Full Node and Kim, SCTester reduces time consumption by an average of 86.6% and 70.5%, respectively. Therefore, in contract account-based transaction replay scenarios, SCTester offers lower time consumption.

[0081] Example 3

[0082] This embodiment proposes a historical transaction replay system based on smart contracts, applying the historical transaction replay method proposed in Embodiment 1. For example... Figure 7 The diagram shown is an architecture diagram of the historical transaction replay system in this embodiment.

[0083] The historical transaction replay system based on smart contracts proposed in this embodiment includes:

[0084] The rules management module is used to model transaction characteristics based on Ethereum state changes and configure transaction filtering rules based on the transaction characteristics to filter transactions of target types.

[0085] The information aggregation module is configured with a world temporary state tree built on Patricia Merck trees and binary search trees, which is used to store Ethereum's temporary and persistent information.

[0086] The transaction replay module is used to repair contracts by creating fake blocks and replaying historical transactions based on the fork mechanism. The repaired contract is then compared with the original contract, and the comparison result is written to the log.

[0087] The forged block is configured with filtering transactions (tx) that filter transactions in the original transaction list based on the transaction filtering rules. filter And a fake world state tree constructed by backtracking based on the historical states stored in the world temporary state tree.

[0088] In one specific implementation, the information aggregation module acquires information and transaction data from each Ethereum block and stores it using a world temporary state tree constructed based on Patricia Merck trees and binary search trees. The information aggregation module transmits the acquired transaction feature information to the rule management module, which models the transaction features based on Ethereum's state changes and configures transaction filtering rules based on these features to filter transactions of target types. The filtering results are then sent to the transaction replay module. Simultaneously, the information aggregation module transmits Ethereum's historical state, block information, and transaction information to the transaction replay module.

[0089] The transaction replay module generates a fork by constructing a fake block to avoid interfering with the main chain. At the same time, it filters and selects transactions in the original transaction list based on the transaction filtering rules and adds them to the fake block. It also backtracks according to the historical state stored in the world temporary state tree, constructs a fake world state tree and adds it to the fake block, thus realizing the configuration of the fake block.

[0090] Finally, the forged block is run through Ethereum, where the forged block performs historical transaction replay to repair the contract, and the repaired contract is compared with the original contract, with the comparison result written to the log.

[0091] It is understood that the system in this embodiment corresponds to the method in Embodiment 1 above, and the options in Embodiment 1 above are also applicable to this embodiment, so they will not be described again here.

[0092] Obviously, the above embodiments of the present invention are merely examples for clearly illustrating the present invention, and are not intended to limit the implementation of the present invention. Those skilled in the art will recognize that other variations or modifications can be made based on the above description. It is neither necessary nor possible to exhaustively describe all embodiments here. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the claims of the present invention.

Claims

1. A method for replaying historical transactions based on a smart contract, characterized in that, include: S1. Model transaction characteristics based on Ethereum state changes, and configure transaction filtering rules based on the transaction characteristics; S2. Construct a first-order tree as the world account tree based on the Patricia Merkle tree. A tmp A second-order tree is constructed based on a binary search tree as the historical transaction block tree. H tmp The world account tree A tmp and the historical transaction block tree H tmp The world temporary state tree is obtained by combining and constructing. ; wherein, the world account tree A tmp Using the account address as the key, and the historical transaction block tree as the reference... H tmp The root hash value in the historical transaction block tree is the value; H tmp The block number is used as the key, and the status data of the account under the corresponding block is used as the value. S3. Create a fake block: filter transactions in the original transaction list based on the transaction filtering rules and add them to the fake block; backtrack according to the historical states stored in the world temporary state tree, construct a fake world state tree and add it to the fake block, including: S310. Based on the transaction filtering rules, locate the transaction block that needs to be replayed, i.e., the original block. B ori Copy the original block to the specified location. B ori Content, constructing a fake block B fake ; S320, based on transaction characteristics Construction rules with operators rule By filtering transactions, we can obtain transactions. and related transactions tx rel ;in Indicates the first i One transaction, , n The total number of transactions; function Indicates when a transaction tx i Satisfy the rules rule Returns true if the transaction is true, otherwise returns false; retrieve transaction. tx rule Related party transactions tx rel The intersection of the filtering transactions tx filter And added to the forged block; wherein, transaction characteristics In Represents a block on the blockchain. For state, For receipt, This is instruction information; S330. Obtain historical states from the world temporary state tree and backtrack to fix the code. C rep Inject Repair Contract S Crep Obtain a fake world state tree and the forged world state tree Add to the forged block; S4. Ethereum runs the forged block, which performs historical transaction replay to repair the contract, compares the repaired contract with the original contract, and writes the comparison result to the log.

2. The historical transaction replay method according to claim 1, characterized in that, In step S1, the Ethereum state changes include: Using state transition function Driving the first on the blockchain t Block No. grow into , will the t The state of block number Updated to And generate a receipt based on the transaction status. ; Specifically, when the block's transactions are non-shutdown transactions, the state transition function... EVM state change function E With transaction state change function T Make state Updated to and generate a success receipt. When the block's transactions are halted transactions, the status is as follows: Keep it unchanged and generate a failure receipt. ; via instruction information Describe the EVM state change function E ; Then, transaction characteristics are modeled based on Ethereum's state changes to obtain transaction features. ;in, For blocks, The state is...

3. The historical transaction replay method according to claim 2, characterized in that, In step S1, configuring transaction filtering rules based on the transaction features includes: connecting the transaction features using operators. To define transaction screening rules; the operators include relational operators and / or logical operators.

4. The historical transaction replay method according to claim 1, characterized in that, The World Temporary State Tree It is also used to determine the current block. currBlock The start and end states are provided to offer temporary information; where: Initialize the right neighboring block nextBlock for null and initialize the target block number. target The block number of the current block. ; Depth-first traversal of nodes node until the node node Traverse to an empty node; During the depth-first traversal, the node block number is determined. Value: like Then the node node Assign to the right neighboring block nextBlock and nodes node Assign the value to its left node node.left ; like Then the node node Assign the value to its right node node.right ; like Then the right adjacent block nextBlock Assigned value node and return to the right neighboring block. nextBlock ; After the depth-first traversal is completed, return to the right nearest block. nextBlock ; Based on the current block after depth-first traversal currBlock and the right adjacent block nextBlock From the world temporary state tree Get the current block currBlock The initial and final states are used as temporary information.

5. The historical transaction replay method according to claim 1, characterized in that, In step S330, when obtaining historical states from the world temporary state tree and performing backtracking, only the contract repair is backtracked. S Crep Associated accounts SC rep The historical status of the transaction and the execution of related transactions. tx rel .

6. The historical transaction replay method according to claim 5, characterized in that, Step S3 also includes the following steps: S301. Traverse all transactions in all blocks and configure the account addresses representing the source and destination in the transaction metadata to be explicitly directly related accounts. SC ex ; S302. Traverse the contract account execution stack and configure the account invoked by the instruction CALL or DELEGATECALL as an implicitly directly associated account. SC im ; S303, retrieve the explicitly directly associated account. SC ex The implicitly directly associated account SC im The union of the directly related accounts SC dir And store it in the world temporary state tree; S304, Initialize account search account Related Accounts Table accountList Set, remove duplicate elements; initialize the exploration queue. q and by searching for accounts account Directly associated accounts SC dir For queue q The initial value; S305, Based on Exploration Queue q Breadth-first search of directly associated accounts continues until the queue is empty. In each exploration, determine the exploration queue. q Find the team leader's account and its directly associated accounts to obtain the set of directly associated accounts. Next, traverse the set of directly associated accounts. Each account in This will not exist in the associated account table. accountList Add elements to the exploration queue q and related account table accountList ; S306, via associated account table accountList Get Account Search account All associated accounts SC rep Iterate through all transactions and find those transactions whose metadata indicates the source or destination and includes associated accounts. SC rep Transactions that result in related party transactions tx rel .

7. The historical transaction replay method according to any one of claims 1 to 6, characterized in that, The S2 step also includes: obtaining persistent Ethereum information by injecting detection code into the Ethereum database, that is, information stored in the Ethereum database, which can be obtained directly through the database index.

8. A historical transaction replay system based on smart contracts, employing the historical transaction replay method described in any one of claims 1 to 7, characterized in that, include: The rules management module is used to model transaction characteristics based on Ethereum state changes and configure transaction filtering rules based on the transaction characteristics to filter transactions of target types. The information aggregation module is configured with a world temporary state tree built on Patricia Merck tree and binary sort tree, which is used to store Ethereum's temporary and persistent information. The transaction replay module is used to repair contracts by creating fake blocks and replaying historical transactions based on the fork mechanism. The repaired contract is then compared with the original contract, and the comparison result is written to the log. The forged block is configured with filtering transactions that filter transactions in the original transaction list based on the transaction filtering rules. tx filter And a fake world state tree constructed by backtracking based on the historical states stored in the world temporary state tree.

Images