Blockchain state data processing method

Abstract

The application provides a blockchain state data processing method, applied to a blockchain node, comprising the following steps: n At the beginning, a state tree S n corresponding to each period e n is created; state data is obtained, the state data comprising: information necessary for the node to process incoming blocks and / or received business events; the state data is stored in the state tree S n according to preset requirements, so that the node can call the state data when processing various businesses; wherein the preset requirements comprise: the state data in each period e n can only be stored in the state tree S n corresponding to the period e n . The technical problem that the retrieval and access efficiency of state data greatly decreases after the blockchain system runs for a period of time in the prior art is solved. The technical effect that the explosive growth of state data is avoided, and the transaction processing efficiency or processing capacity of the blockchain node is reduced.

Description

Technical Field

[0001] This application relates to the field of financial technology (Fintech), and more particularly to a method for processing blockchain state data. Background Technology

[0002] With the development of computer technology, more and more technologies are being applied in the financial field. The traditional financial industry is gradually transforming into financial technology (Fintech), and blockchain technology is no exception. However, due to the security and real-time requirements of the financial industry, higher demands are being placed on the technology.

[0003] Currently, each blockchain node typically uses a tree-like storage structure, or state tree, to store the information necessary for the blockchain node to operate, namely state data. However, as the blockchain system continues to operate, the amount of state data increases, and the state tree becomes larger and larger, which greatly reduces the efficiency of data retrieval and access.

[0004] This refers to the technical problem that exists in existing technologies where the efficiency of retrieving and accessing state data decreases significantly after a blockchain system has been running for a period of time. Summary of the Invention

[0005] This application provides a blockchain state data processing method to solve the technical problem in the prior art where the efficiency of retrieving and accessing state data decreases significantly after the blockchain system has been running for a period of time.

[0006] Firstly, this application provides a blockchain state data processing method applied to a blockchain node, the method comprising:

[0007] In each period e n At the beginning, creation and period e n The corresponding state tree S n ;

[0008] Acquire status data, which includes: period identifiers and information necessary for blockchain nodes to process incoming blocks and / or received business events;

[0009] Based on the period identifier and preset requirements, the state data is stored in the state tree S. n This allows blockchain nodes to access state data when processing various business transactions;

[0010] The preset requirements include: e for each period n The state data generated internally can only be stored in the period e. n The corresponding state tree S n middle.

[0011] In one possible design, the method further includes: at the beginning of each period, if the blockchain node contains the first historical state tree S of the previous period... n-1 Then save and freeze the first historical state tree S. n-1 .

[0012] In one possible design, when the blockchain node is a full node, each period's e is stored in the full node. n The corresponding state tree S n ;

[0013] When a blockchain node is a light node, at least the following should be stored in the light node: state tree S n and the first historical state tree S n-1 And in the current period e n At the beginning, delete the second historical state tree S that does not meet the preset storage requirements. m .

[0014] In one possible design, the preset storage requirements include: a second historical state tree S. m Corresponding historical period e m With the current period e n The time interval is less than the preset interval.

[0015] In one possible design, the lightweight node can store a preset number of consecutive periods e. n All corresponding state trees S n The preset quantity is greater than or equal to 2.

[0016] In one possible design, acquiring state data includes:

[0017] Obtain the blocks sent by the block-producing node and determine the status data based on the blocks;

[0018] Alternatively, obtain the transaction request sent by the user and determine the status data based on the transaction request.

[0019] In one possible design, the address corresponding to the state data includes: a period identifier and an address code. Based on the period identifier and preset requirements, the state data is stored in the state tree S. n Including:

[0020] In the current period e now The corresponding current state tree S now The system checks if a corresponding storage path exists based on the address.

[0021] When a storage path exists, the state data is stored in the current state tree S according to the storage path. now middle;

[0022] If no storage path exists, determine whether the period identifier meets the proof-free requirement;

[0023] If the proof-free requirement is met, then in the current state tree S now Above, create the corresponding storage path based on the address code;

[0024] Store the state data into the current state tree S according to the storage path. now middle.

[0025] In one possible design, determining whether the proof-free requirement is met based on the period identifier includes:

[0026] Determine whether the state tree S0 corresponding to the period identifier is stored in any blockchain node of the blockchain network.

[0027] In one possible design, determining whether a period marker meets the proof-free requirement includes:

[0028] Determine whether the first period e0 is in the current period e now Within the previously preset time range, the first period e0 corresponds to the period identifier.

[0029] Optionally, the time range includes: k periods, where each period is e. n The duration of the duration, k is greater than or equal to 1.

[0030] In one possible design, after determining whether the period marker meets the proof-free requirement, the following is also included:

[0031] If the proof-free requirement is not met, then based on the address, determine whether state data exists in the historical state tree corresponding to each historical period;

[0032] If it does not exist, the first proof information is generated using the preset verification model. When the blockchain node is a block producing node, the first proof information is added to the block corresponding to the state data, and the block is sent to the blockchain network for consensus. The first proof information is used to characterize that the state data is not on any historical state tree.

[0033] And in the current state tree S now Above, a storage path is created based on the address code, and the state data is stored into the current state tree S according to the storage path. now middle.

[0034] In one possible design, based on the address, it is determined whether state data exists in the historical state tree corresponding to each historical period, including:

[0035] On the target history state tree corresponding to each target historical period, the existence of state data is determined according to the address code. The target historical period includes: each historical period starting from the first period e0 corresponding to the period identifier;

[0036] The target historical state tree does not include the state trees of each light node already stored on the light nodes. The light node state tree includes at least the state tree S for the current period. n And the first historical state tree S of the period preceding the current period n-1 .

[0037] Optionally, the target historical period does not include: the current period e now and the current period e now The previous period e now-1 .

[0038] In one possible design, after determining whether state data exists in the target history state tree corresponding to each target historical period based on the address code, the following is also included:

[0039] If it exists, the second proof information is generated using the preset verification model. When the blockchain node is a block producing node, the second proof information is added to the block corresponding to the state data, and the block is sent to the blockchain network for consensus. The second proof information is used to represent that the state data is on the second state tree S1 corresponding to the last modification, and there is no state data on any historical state tree after the last modification period e1. The last modification period corresponds to the second state tree S1.

[0040] And in the current state tree S now Above, a storage path is created based on the address code, and the state data is stored into the current state tree S according to the storage path. now middle.

[0041] In one possible design, state data is stored in a state tree S based on period identifiers and preset requirements. n Following this, it also includes:

[0042] When the state data is in the current period e now When a change occurs, the current state tree S corresponding to the current period. now Update the status data;

[0043] All blockchain nodes on the blockchain network will delete state data from each historical state tree, retaining only the state data in each state tree S. n The hash value of the corresponding storage path.

[0044] In one possible design, in each period e n At the beginning, creation and period en The corresponding state tree S n ,include:

[0045] The previous period e n-1 The corresponding first historical state tree S n-1 After deleting nodes whose access frequency is less than a preset threshold, the state tree S is obtained. n .

[0046] Secondly, this application provides a blockchain state data processing device, comprising:

[0047] Processing module, used in each period e n At the beginning, creation and period e n The corresponding state tree S n ;

[0048] The acquisition module is used to acquire status data, which includes: period identifiers and information necessary for blockchain nodes to process incoming blocks and / or received business events;

[0049] The processing module is also used to store state data into the state tree S according to the period identifier and preset requirements. n This allows blockchain nodes to access state data when processing various business transactions;

[0050] The preset requirements include: e for each period n The state data generated internally can only be stored in the period e. n The corresponding state tree S n middle.

[0051] Thirdly, this application provides an electronic device, comprising:

[0052] Memory, used to store program instructions;

[0053] The processor is configured to invoke and execute program instructions in the memory to perform any of the possible methods for determining item storage information provided in the first aspect.

[0054] Fourthly, this application provides a storage medium in which a computer program is stored, the computer program being used to execute any of the possible blockchain state data processing methods provided in the first aspect.

[0055] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements any of the possible blockchain state data processing methods provided in the first aspect.

[0056] This application provides a blockchain state data processing method, which processes blockchain state data at each period en At the beginning, creation and period e n The corresponding state tree S n Acquire state data, which includes: period identifiers and information necessary for blockchain nodes to process incoming blocks and / or received business events; store the state data in the state tree S according to the period identifiers and preset requirements. n This is to facilitate blockchain nodes accessing state data when processing various business transactions; the preset requirements include: each period e n The state data generated internally can only be stored in the period e. n The corresponding state tree S n This technology addresses the technical problem of a significant decrease in the efficiency of retrieving and accessing state data after a blockchain system has been running for a period of time. It effectively prevents the explosive growth of state data from causing a decline in the transaction processing efficiency or capacity of blockchain nodes. Attached Figure Description

[0057] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0058] Figure 1 A schematic diagram of a state tree structure provided in this application;

[0059] Figure 2 This is a schematic diagram illustrating an application scenario of a blockchain state data processing method provided in an embodiment of this application.

[0060] Figure 3 A flowchart illustrating a blockchain state data processing method provided in this application;

[0061] Figure 4 A flowchart illustrating another blockchain state data processing method provided for the implementation of this application;

[0062] Figure 5 A schematic diagram of the structure of a blockchain state data processing device provided in an embodiment of this application;

[0063] Figure 6 This is a schematic diagram of the structure of an electronic device provided in this application.

[0064] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0065] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort, including but not limited to combinations of multiple embodiments, are within the scope of protection of this application.

[0066] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0067] The following is an explanation of the technical terms used in this application:

[0068] (1) States and state trees in blockchain:

[0069] Generally, nodes in a blockchain network will save some data on their local storage devices after running in the network for a period of time. This data can be divided into two main categories based on its time attributes: historical data (referred to as "history") and current data (referred to as "state").

[0070] State: refers to the information that nodes in a blockchain system must hold or store in order to process newly incoming blocks and / or events. State is relative to history.

[0071] History is descriptive information about past events. Once history is saved, it can be used to review or replay past events, and it can also be archived and managed.

[0072] In blockchain systems applied to the financial sector, the states include:

[0073] 1. Account balance and / or non-balance information, such as nonce;

[0074] 2. The code corresponding to the smart contract;

[0075] 3. The data that needs to be stored for smart contracts;

[0076] 4. The relevant data required for consensus among nodes is called consensus data, such as the hash value, quantity, and proof-of-stake of recently generated blocks.

[0077] As time goes on, and as new users join the blockchain network, creating new accounts and new smart contracts, and calling functions within those smart contracts, this data (i.e., the specific form that carries the "state") will continue to grow.

[0078] In existing technologies, most blockchain systems use binary (i.e., with two leaf nodes) or hexagonal (i.e., with six leaf nodes) Pascal-Merkel trees (a type of state tree) to maintain and manage state data, which are generally stored in the form of key-value pairs, such as (key, value).

[0079] Pascal-Merkel tree: It is a trie with a root node, intermediate nodes and leaf nodes. Each node has a unique "key". Based on the "key" of the state data, the storage location corresponding to the "key" can be found in the state tree, and then the "value" of the state data is stored in the storage slot of the storage location.

[0080] For example, an account, such as 0x001d3f1ef827, can have countless state data. To put these state data into the state tree, its hash value, i.e., the result of hash(0x001d3f1ef827), can be used as the "key" to find the intermediate node in the state tree (i.e., the "key" represents the address of the intermediate node or the path used to find the intermediate node). Thus, all the state data of this account is stored under the subtree of this intermediate node.

[0081] Walker trees are essentially a type of trie, storing and retrieving state data in a similar way to Pascal-Merkel trees. However, Walker trees are wider; that is, the number of child nodes (n1) of a node in a Walker tree is much larger than the number of child nodes (n2) of a node in a Pascal-Merkel tree (i.e., n1 >> n2). Therefore, for a fixed-length key address, the depth of a Walker tree (i.e., the total number of tree levels) is much smaller than that of a Pascal-Merkel tree. Due to its smaller depth, adding and modifying nodes is simpler in Walker trees. More importantly, for proving the existence of nodes (i.e., verifying data), Walker trees use Walker proofs, which are simpler than the Merkle proofs used in Pascal-Merkel trees.

[0082] The Walker proof uses multinomial commitments (a type of vector commitment) to prove that a node is one of many children of its parent. Since the value of a parent node in a Walker tree is determined by the values ​​of all its children, it's equivalent to proving only the relationship between a node's value and its parent's value, unlike the Merkel proof which requires providing the values ​​of all sibling nodes to verify this relationship. Therefore, the Walker proof is much smaller and more efficient.

[0083] (2) Full nodes, light nodes, and validator nodes:

[0084] Different blockchain systems have different node roles, which can be broadly divided into: full nodes, light nodes, and validator nodes.

[0085] A full node is a node that stores all the data in the blockchain. It stores complete "state" data and all "historical" data (some consortium blockchains discard state data from historical blocks, such as FISCO BCOS).

[0086] Light nodes are nodes that only store a subset of frequently used state data. This makes light nodes more memory-efficient than weighted nodes, while still being able to handle most user transactions and block packaging. It's important to note that the functionality of light nodes may differ across different blockchain systems.

[0087] Validator nodes are nodes in a consensus system that only participate in verifying the correctness of blocks but do not have the ability to package blocks. Similarly, the amount of state that validator nodes need to store to verify the correctness of blocks varies across different blockchain systems.

[0088] It's also important to note that a full node includes: the body of various blocks (a block can be divided into a header and a body), transaction lists, and other related information. A full node stores a complete blockchain network locally, on which any query, transaction verification, and broadcasting can be performed. The existence of full nodes makes the decentralization of the blockchain possible and also makes the blockchain network more secure. It should be noted that full nodes generally need to remain online at all times.

[0089] Unlike full nodes, light nodes do not need to store all transaction content. They only need to store the header of each block and transaction details related to the node itself in the form of a state tree, and use the verification method (also known as "proof") corresponding to the state tree to determine whether a transaction is in the current blockchain transaction list. Unlike full nodes, light nodes do not need to stay online at all times.

[0090] Epoch: Represents the time elapsed for a fixed number of blocks (e.g., 10,000 blocks). The "state" (i.e., state data) created or modified within this epoch e will automatically become an expired "state" in the next epoch e+1.

[0091] The inventors of this application have discovered that in existing blockchain systems, each blockchain node typically uses a tree-like storage structure, i.e., a state tree, to store the information necessary for the operation of the blockchain node, i.e., state data. However, as the blockchain system continues to operate, the amount of state data increases, and the state tree becomes larger and larger, which greatly reduces the efficiency of data retrieval and access.

[0092] To solve the above problems, one approach is to use a "two-tree scheme" for managing "states": expired states form an expired state tree, and non-expired current states form an active state tree.

[0093] In the active state tree, the state storage slot on the leaf node corresponding to each account (including smart contracts) starts timing as soon as it is created. If the state data in the state storage slot is modified within a preset time, the timing is reset. Conversely, if the state data of the account is not modified after a preset time, the state data is placed on the expired state tree.

[0094] Full nodes need to store both trees, while other nodes, such as light nodes, only store the active state tree. If a user wants to access the expired state of an account or revive the expired state of an account, they must provide proof (i.e., verification data) of the account's corresponding state in the expired state tree.

[0095] However, the inventors of this application have discovered that the above approach still causes the following technical problems:

[0096] 1. If the node that packages the block is not a full node, an account will be removed from the active state tree after it expires. When other users create accounts with the same address (equivalent to creating accounts with the same name), it will prevent the restoration of the original account's state. Alternatively, if the original account owner cannot provide proof (i.e., verification data), the entire account information will be reconstructed, which may even lead to conflicts with historical data.

[0097] 2. Most current blockchains use a hexagonal Pascal-Merkel tree as the state tree, with state proofs reaching a maximum of 4MB. This results in a block being unable to accommodate several transactions containing state proofs, i.e., accessing transactions with expired states, or causing blocks to be too large, thus affecting the speed of consensus.

[0098] 3. Existing technologies cannot fundamentally solve the problem of explosive growth in state. Many practices of public chains cannot be directly applied to consortium chains, especially consortium chains without token mechanisms. Existing state tree structures are difficult to combine with advanced cryptography to improve the efficiency of state data management and proof.

[0099] To solve the aforementioned technical problems, this application adopts another inventive concept:

[0100] The fundamental logic of state data management has been changed. It no longer simply distinguishes between expired and active state trees. Instead, a new state tree is created for each node within each preset time unit (period). This state tree only stores state data that occurred within the current period, or state data that has changed within the current period. State data from previous or future periods are not stored in the current state tree. In other words, each period has a corresponding state tree. The state tree of a future period cannot be accessed in the current period, and accessing the state tree of a past period requires proof of the node's existence.

[0101] Furthermore, to ensure that state data is correctly stored in the state tree at the correct time, a time prefix needs to be added to the original address. This prevents users from recreating the exact same address. If a user wants to create an address from a historical time period, proof must be provided for the node to verify that the address has never appeared before. Users also cannot create addresses from future times, thus ensuring that address conflicts are avoided and expanding the availability of the address space.

[0102] Furthermore, the organizational structure of the state tree can be modified by adopting a Volker tree, fundamentally replacing the existing Pascal-Merkel tree, without altering the original storage and retrieval logic. Proofs can be made using accumulators, with a proof size of only about 800KB, making it more suitable for maintaining and managing state data in the blockchain. This feature allows the existence of validator nodes that do not need to store any state data, enabling mobile devices to perform verification—meaning mobile devices can become validator nodes—further decentralizing the blockchain system.

[0103] Specifically, the inventors of this application have redefined the processing logic for state data in the blockchain:

[0104] (1) New address structure and state tree structure:

[0105] Figure 1 This is a schematic diagram of a state tree structure provided in this application. Figure 1 As shown, each period has its own independent state tree, so the state contains a perpetually growing tree S0, S1, S2, S3..., where each S... iThis represents the state tree for the i-th period. Therefore, no additional field is needed to indicate whether a state is expired; only the states in the current period's state tree are non-expired. Finally, the root 10 of each state tree forms a total state root 100, which is recorded in the header of each block. Any change in any state tree will change the total state root 100. Optionally, the state tree type includes a Walker tree.

[0106] It should be noted that a blockchain system must have at least one full node that stores the entire historical state tree. The number of full nodes can be determined by the blockchain participants. Other nodes decide to store certain historical state trees based on the actual situation. However, it is important to note that although not all state trees are stored, the root nodes of all state trees must be stored, and each blockchain node must store at least the state tree of the previous period and the state tree of the current period.

[0107] For an account used for transactions within a blockchain node, this account includes: contract accounts and externally owned accounts (EOAs). For example, in Ethereum, a contract account is an account used for transactions through smart contracts and controlled by the smart contract's code. Only contract accounts have code, which stores the codeHash (the hash value of the account's Ethereum Virtual Machine code). This field is immutable after generation, meaning the smart contract code itself is unchangeable. An external account, on the other hand, is an account created by human users of the Ethereum network. It is associated with a public-private key pair and is derived from the last 20 bytes of a secondary hash of the public key.

[0108] This application defines a new account address, which can be represented as a tuple (e, s), where e is the period identifier of the period to which the address belongs, represented by 4 bytes, and s is the original address, i.e., the 20-byte address encoding commonly used in current blockchains. Therefore, the new account address is represented in binary as [e:s], which is the concatenation of the period identifier and the address encoding.

[0109] (2) State tree access and modification rules:

[0110] epoch e in the current period:

[0111] 1. Only the current state tree S e It can be modified.

[0112] 2. The state tree for historical periods is frozen. Any transaction wishing to access the historical state tree must carry a proof demonstrating the position of the desired state within the state tree at a specific historical period. This proof could include a Walker proof of the state's position, containing the old state data value. This is necessary to access the historical state tree. Since all blockchain nodes store the state tree S from the previous period... e-1 If the user needs to access the state tree S e-1 In the blockchain, state data is stored in the state tree, and blockchain nodes help users provide proof of that state tree. Most of the hot data resides in this state tree, thus satisfying the vast majority of users. However, if a user's transaction wants to access S... e-1 The previous tree had to find a full node to provide access proof.

[0113] 3. The state tree for future periods can be built in advance, but it can only be modified after the future period becomes the current period. In other words, the state tree for the future period has not yet been created. Upon reaching a new period, the node immediately activates or creates a new state tree. The state tree corresponding to this future period can be a blank state tree, or it can be accompanied by tree nodes that store some frequently accessed state data.

[0114] (3) Account access and modification rules:

[0115] Account (e, s) can be accessed at any epoch f > e, and its data is always stored at a fixed position hash(e, s) in the state tree. If the storage of account (e, s) is modified in the current epoch f, since the historical state tree cannot be modified, a corresponding storage slot will be created at the hash(e, s) position in the current epoch state tree Sf.

[0116] Specific modification rules:

[0117] 1. If account (e, s) is created and modified in epoch e, then directly in tree S e Create and modify the corresponding location;

[0118] 2. If account (e, s) is created or modified in epoch e+1, then directly in tree S e+1 Create and modify the corresponding location;

[0119] 3. If account (e, s) is created in epoch f (f > e+1), and in tree S f and S f-1 If the corresponding position has not yet been created, proof is required: the account (e, s) is in these trees S. e S e+1 S f-2 None of the corresponding positions appeared;

[0120] 4. If the account (e, s) is modified in epoch f (f > e + 1) and the corresponding position has not been created on the trees Sf and Sf-1, assuming that the account (e, s) was last modified in epoch e′ (e ≤ e′ < f), then it is necessary to provide proof that the account (e, s) appears at the corresponding position in the state tree S e′ at the corresponding position, and in these trees S e′+1 , S e′+2. .. S f-2 it does not appear at the corresponding positions;

[0121] 5. If the account (e, s) is modified in epoch f (f > e) and the corresponding position has been created on the tree S f , directly modify it.

[0122] (4) Historical state tree pruning:

[0123] Since this application stores the state trees of different periods of the blockchain separately, if "state" deduplication is not done, it will bring a large storage overhead to the blockchain nodes, especially full nodes.

[0124] This application adopts the method of historical state tree pruning: if the "state" (i.e., the state data in this article) of a certain account changes in the current period, then the state tree in the current period will save the latest "state" of this account. Therefore, all nodes can delete the old state of this account from each historical state tree, and only retain the node hash values at the corresponding positions in the state tree.

[0125] (5) Generation method of proof:

[0126] When a user needs to prove that a certain account exists in a certain historical state tree or does not exist in a certain historical state tree, this invention uses a cryptographic accumulator to make a membership proof and a non-membership proof respectively.

[0127] As Figure 1 shown, the depth of the state tree 100 corresponding to each period is 4, and the breadth is 4 bytes, that is, the maximum number of child nodes in each layer is 256, which is represented in hexadecimal as 00~ff. Assuming that the key corresponding to a certain account in the state tree is 0x3a4b5c, in the state tree, the keys corresponding to this account are the node serial numbers 3a, 4b, and 5c in each layer respectively, and these serial numbers also constitute a unique path for the corresponding account information to be stored in the state tree. Therefore, when a user needs to prove that this account exists in this state tree, the system needs to prove the path of the key corresponding to this account, that is, make a membership proof for the node serial number in each layer of the path.

[0128] Taking the above keys as an example, it is necessary to prove that: node 3a is in the set of existing child nodes of the root node; node 4b is in the set of existing child nodes of 3a; and node 5c is in the set of existing child nodes of 4b. The set of existing child nodes represents all the keys of stored state data with these child nodes as intermediate paths. The blockchain node or blockchain system maintains the set of existing child nodes for each level of the state tree. Therefore, for any state tree, the second level has 1 set of existing child nodes, and the third level has at most 256 sets of existing child nodes.

[0129] Specifically, taking the proof that node 3a is in the set of existing child nodes of the root node as an example, we use a cryptographic accumulator to make a membership proof for 3a. Let M represent the accumulator vector of the set of existing child nodes, where M records the prime number uniquely corresponding to the node index, and let x... 3a Let represent the prime number corresponding to node 3a, and A represent the value of the accumulator, which is the product of all prime numbers in M. 3a Membership proof The simplified calculation logic can be expressed by formula (1):

[0130]

[0131] The corresponding verification logic can be expressed by formula (2):

[0132]

[0133] Where g represents the generator of the domain used by the system.

[0134] To prove that another node, suppose 3b, is not in this set of child nodes, let y represent the prime number corresponding to node 3b. The proof of y's non-membership is u. y The simplified calculation logic can be expressed by formula (3):

[0135]

[0136] The corresponding verification logic can be represented by formula (4):

[0137]

[0138] Here, Bezout is the theorem, and a and b are two coefficients obtained from Bezout's theorem.

[0139] Membership proofs for nodes 4b are obtained sequentially. Membership proof of node 5c Together, they constitute proof that the account exists in this state tree. If two accounts involved in a transaction need to provide proof, they can be proven together at each level. For example, if the second account passes through node 3c at the first level, and the corresponding prime number is z, then only x*z membership proof is needed, without having to provide separate membership proofs.

[0140] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0141] Figure 2 This is a schematic diagram illustrating an application scenario of a blockchain state data processing method provided in an embodiment of this application. For example... Figure 2 As shown, user 20 sends a transaction request to any blockchain node 21 in the blockchain network or blockchain system. Blockchain node 21 executes the transaction corresponding to the transaction request, causing changes to various state data of the user's account used for the transaction. The blockchain node 21 that receives user 20's transaction request is also called a block-producing node. It packages the transaction into a block and sends it to the blockchain network for other blockchain nodes 21 to reach a consensus. In the block-producing node, after the transaction is executed, the generated state data is stored in the state tree corresponding to the current period in the node. Other blockchain nodes 21 that receive the block also update the state data in their local state trees using the same state data processing method.

[0142] The status data processing method provided in this application is described in detail below:

[0143] Figure 3 This is a flowchart illustrating a blockchain state data processing method provided in an embodiment of this application. Figure 3 As shown, the specific steps of this blockchain state data processing method include:

[0144] S301, in each period e n At the beginning, creation and period e n The corresponding state tree S n .

[0145] In this step, in each period e n Initially, the blockchain nodes create a new state tree S according to a preset state tree template. n Meanwhile, the historical state tree, i.e. the historical state tree of periods before the current period, will be frozen. The historical state tree can be accessed and queried, but new state data cannot be stored in the historical state tree.

[0146] Optionally, in this embodiment, the state tree type is a Walker tree.

[0147] In one possible design, at the beginning of each period, if the blockchain node contains the first historical state tree S of the previous period... n-1 Then save and freeze the first historical state tree S. n-1 .

[0148] That is, in each period e n At the beginning, for the period that just ended, e n-1 The corresponding state tree S n-1 Instead of deleting it directly, it is frozen but still stored in the blockchain node.

[0149] In another possible design, the blockchain nodes in the entire blockchain network can be divided into two categories: full nodes and light nodes.

[0150] When a blockchain node is a full node, each period's e is stored in the full node. n The corresponding state tree S n ;

[0151] When a blockchain node is a light node, at least the following should be stored in the light node: state tree S n and the first historical state tree S n-1 And in the current period e n At the beginning, delete the second historical state tree S that does not meet the preset storage requirements. m .

[0152] In one possible design, the preset storage requirements include: a second historical state tree S. m Corresponding historical period e m With the current period e n The time interval is less than the preset interval.

[0153] For example, when the preset interval is 2, the light node only stores the state tree of the current period and the previous period. If the light node wants to access the historical state tree of other periods, it needs to make an access request to the full node, and the full node will then perform the access query on the corresponding historical state tree.

[0154] Of course, light nodes can also store state trees for more historical periods. For example, when the preset interval is 3-6, a light node can store state trees for 3-5 consecutive periods.

[0155] It should be noted that light nodes can also be historical state trees of non-continuous periods, such as storing the state trees of the current period, the previous historical period, and the previous three historical periods.

[0156] The principle for saving can be set as follows: if the creation and / or modification volume of state data in a historical period is greater than a preset threshold, or if the transaction volume in a historical period is greater than a preset threshold, it proves that the state data in that historical period is likely to be used. In this case, the state tree corresponding to that historical period is kept in the blockchain node until the access popularity of the corresponding state data is lower than the preset popularity threshold, at which point the historical state tree is deleted.

[0157] Of course, those skilled in the art can also set the number of light nodes that store the state tree and the storage rules according to the actual situation, but at least it must be ensured that the light nodes include at least: the current state tree S. n The state tree S from the previous period n-1 That is, a light node can store a preset number of consecutive periods e. n All corresponding state trees S n The preset quantity is greater than or equal to 2.

[0158] In one possible design, in this step, the previous period e n-1 The corresponding first historical state tree S n-1 After deleting nodes whose access frequency is less than a preset threshold, the current period e is obtained. n State tree S n .

[0159] S302, Obtain status data.

[0160] In this step, the status data includes: period identifiers and information necessary for the blockchain node to process incoming blocks and / or received business events.

[0161] This step can be divided into two cases:

[0162] In the first case, when a blockchain node is the one that receives user transaction requests, it needs to package the transactions into blocks and publish them to the blockchain network for consensus due to the blockchain's consensus mechanism. Therefore, this blockchain node is also called a block-producing node.

[0163] At this point, the status data is obtained, including: obtaining the transaction request sent by the user, and determining the status data based on the transaction request.

[0164] The second approach involves obtaining state data when the blockchain node is not the node receiving user transaction requests, but rather the node executing consensus within the blockchain network. This includes obtaining the blocks sent by the block-producing node and determining the state data based on the blocks.

[0165] In this embodiment, the address corresponding to the status data includes: a period identifier and an address code.

[0166] S303. Store the status data into the status tree S according to the period identifier and the preset requirements n so that the blockchain nodes can call the status data when processing various services.

[0167] In this step, the preset requirements include: the status data generated within each period e n can only be stored into the status tree S n corresponding to the period e. n

[0168] Specifically, it can be divided into five cases:

[0169] 1. If the account (e, s) is created and modified in the period e, then directly create and modify it at the corresponding position in the tree S e ;

[0170] 2. If the account (e, s) is created or modified in the period e + 1, then directly create and modify it at the corresponding position in the tree S e+1 ;

[0171] 3. If the account (e, s) is created in the period f (f > e + 1), and the corresponding position has not been created on the trees S f and S f-1 , then it is necessary to provide proof that the account (e, s) does not appear at the corresponding positions in these trees S e , S e+1 ,..., S f-2 ;

[0172] 4. If the account (e, s) is modified in the period f (f > e + 1), and the corresponding position has not been created on the trees Sf and Sf - 1, assuming that the account (e, s) was last modified in the period e′ (e ≤ e′ < f), then it is necessary to provide proof that the account (e, s) appears at the corresponding position in the status tree S e′ , and does not appear at the corresponding positions in these trees S e′+1 , S e ′ + 2... S f-2 ;

[0173] 5. If the account (e, s) is modified in the period f (f > e), and the corresponding position has been created on the tree S f , directly modify it.

[0174] In a possible design, the blockchain status data processing method further includes:

[0175] When the status data changes in the current period e now , update the status data on the current status tree S now corresponding to the current period;​

[0176] All blockchain nodes on the blockchain network will delete the state data from each historical state tree, retaining only the state data in each state tree S. n The hash value of the corresponding storage path.

[0177] Since this application stores the state tree of the blockchain at different times separately, if the "state" is not deduplicated, it will bring a lot of storage overhead to the blockchain nodes, especially full nodes.

[0178] This application uses a historical state tree pruning method: if the "state" of an account (i.e., the state data in this article) changes in the current period, the current state tree will save the latest "state" of the account. Therefore, all nodes can delete the old state of the account from each historical state tree and only retain the node hash value at the corresponding position in the state tree.

[0179] This application provides a blockchain state data processing method, which processes blockchain state data at each period e n At the beginning, creation and period e n The corresponding state tree S n Acquire state data, which includes: period identifiers and information necessary for blockchain nodes to process incoming blocks and / or received business events; store the state data in the state tree S according to the period identifiers and preset requirements. n This is to facilitate blockchain nodes accessing state data when processing various business transactions; the preset requirements include: each period e n The state data generated internally can only be stored in the period e. n The corresponding state tree S n This technology addresses the technical problem of a significant decrease in the efficiency of retrieving and accessing state data after a blockchain system has been running for a period of time. It effectively prevents the explosive growth of state data from causing a decline in the transaction processing efficiency or capacity of blockchain nodes.

[0180] Figure 4 A flowchart illustrating another blockchain state data processing method provided for the implementation of this application. (See attached diagram.) Figure 4 As shown, the specific steps of this blockchain state data processing method include:

[0181] S401, in each period e n At the beginning, creation and period e n The corresponding state tree S n .

[0182] S402, Obtain status data.

[0183] For the specific terms and explanations of the principles in steps S401 to S402, please refer to S301 to S302, which will not be repeated here.

[0184] S403, in the current period e now The corresponding current state tree S now The system checks if a corresponding storage path exists based on the address.

[0185] In this step, the storage path includes: State Tree S n The nodes and storage slots are on the system. The nodes include intermediate nodes and leaf nodes, and the storage slots are set on the leaf nodes.

[0186] If a storage path exists, proceed to step S404; if no storage path exists, proceed to step S405.

[0187] Specifically, if, if it has not yet been created

[0188] S404. Store the state data into the current state tree S according to the storage path. now middle.

[0189] In this step, in the current state tree S now Storage slots have already been created (e.g.) Figure 1 As shown in the figure, you only need to update the status data in the storage slot.

[0190] S405. Determine whether the period marker meets the requirements for exemption from proof.

[0191] In this step, if the condition is met, proceed to step S406; otherwise, proceed to step S407.

[0192] In the current state tree S now If no storage slots corresponding to the state data have been created yet, then it is necessary to create each intermediate node and leaf node, create storage slots on the leaf nodes, and then store the state data in the storage slots.

[0193] However, the actual situation is more complicated. Since this application establishes a state tree for each period, state data such as transaction accounts may have been stored in previous state trees. Therefore, it is necessary to determine whether it is in the historical state tree.

[0194] In one possible design, determining whether the proof-free requirement is met based on the period identifier includes:

[0195] Determine whether the state tree S0 corresponding to the period identifier is stored in any blockchain node of the blockchain network.

[0196] In this embodiment, determining whether the proof-free requirement is met based on the period identifier includes:

[0197] Determine whether the state tree S0 corresponding to the period identifier is stored in any blockchain node of the blockchain network.

[0198] In this embodiment, the blockchain network includes at least two types of blockchain nodes: full nodes and light nodes. Full nodes store the state tree corresponding to all periods, but light nodes only retain a portion of the state tree. However, light nodes store at least the current state tree and the historical state tree of the previous period.

[0199] Therefore, the essence of the proof-free requirement is: if the period corresponding to the period identifier in the address of the state data can be found in all the periods corresponding to all the state trees stored in the light node, then the storage path, i.e., each intermediate node, leaf node and storage slot, can be directly created on the current state tree according to the address, and then the state data can be stored in the storage slot.

[0200] For example, a light node stores: the current period e now In the previous period e now-1 The first three periods e now-3 and the first five periods e now-5 These four periods correspond to state trees. If the period identifier of the state tree corresponds to any of these four periods, then the blockchain nodes do not need to calculate the proof according to the proof algorithm, such as the Volker proof. (For details on the proof method, please refer to "Proof Generation Methods" above.)

[0201] In one possible design, determining whether a period marker meets the proof-free requirement includes:

[0202] Determine whether the first period e0 is in the current period e now Within the previously preset time range, the first period e0 corresponds to the period identifier.

[0203] Optionally, the time range includes: k periods, where each period is e. n The duration of the duration, k is greater than or equal to 1.

[0204] For example, when the light node stores the current period e now and the previous period e now-1 When using the corresponding state tree, the preset time range is one cycle, i.e., the first two periods e. now-2 We will not set a preset time range.

[0205] This corresponds to the description in S303:

[0206] 1. If account (e, s) is created and modified during period e, then directly in tree S e Create and modify the corresponding location;

[0207] 2. If account (e, s) is created or modified in period e+1, then directly in tree S e+1 Create and modify the corresponding location.

[0208] 5. If account (e, s) is modified in period f (f > e), and in tree S f The corresponding position has already been created; you can modify it directly.

[0209] S406, In the current state tree S now Above, create the corresponding storage path based on the address code.

[0210] In this step, if the proof-free requirement is met, the storage path, i.e., each intermediate node, leaf node and storage slot, is directly created on the current state tree according to the address. Then, step S404 is executed to store the state data into the storage slot.

[0211] S407. Based on the address, determine whether state data exists in the historical state tree corresponding to each historical period.

[0212] If the condition does not exist in this step, proceed to step S408; if the condition does exist, proceed to step S409.

[0213] Specifically, when the proof-free requirement is not met, the scope of the historical state tree needs to be further expanded. It's important to note that light nodes do not store the state tree for all periods. Therefore, for light nodes, this step involves sending a proof request to the full node, which then searches its stored historical state tree to see if the corresponding state data is stored.

[0214] In this embodiment, this step specifically includes:

[0215] On the target history state tree corresponding to each target historical period, the existence of state data is determined according to the address code. The target historical period includes: each historical period starting from the first period e0 corresponding to the period identifier;

[0216] The target historical state tree does not include the state trees of each light node already stored on the light nodes. The light node state tree includes at least the state tree S for the current period. n And the first historical state tree S of the period preceding the current period n-1 .

[0217] Optionally, the target historical period does not include: the current period e now and the current period e now The previous period e now-1 .

[0218] S408. Generate the first proof information using a preset verification model.

[0219] In this step, when the blockchain node is a block-producing node, the first proof information needs to be added to the block corresponding to the state data, and the block is sent to the blockchain network for consensus. The first proof information is used to represent that the state data is not on each historical state tree. Then, execute step S406.

[0220] That is, corresponding to what is described in S303:

[0221] 3. If the account (e, s) is created in epoch f (f > e + 1), and the corresponding positions on trees S f and S f-1 have not been created yet, then it is necessary to provide proof that the account (e, s) does not appear at the corresponding positions on these trees S e , S e+1 ,..., S f-2 .

[0222] It should be noted that only when the first proof information is generated can a storage path be created on the current state tree. Otherwise, it is impossible to store state information in the current state tree. Specifically, during implementation, a check on the first proof information will be set. Without the first proof information, the next storage operation cannot be carried out.

[0223] It should also be noted that the generation method of the first proof information in this step includes the Merkle proof or the "proof generation method" described above.

[0224] S409. Generate the second proof information using a preset verification model.

[0225] In this step, when the blockchain node is a block-producing node, the second proof information is added to the block corresponding to the state data, and the block is sent to the blockchain network for consensus. The second proof information is used to represent that the state data is on the second state tree S1 corresponding to the last modification, and the state data does not exist on each historical state tree after the last modification epoch e1. The last modification epoch corresponds to the second state tree S1. Then, execute step S406.

[0226] That is, corresponding to what is described in S303:

[0227] 4. If the account (e, s) is modified in epoch f (f > e + 1), and the corresponding positions on trees Sf and Sf - 1 have not been created yet, assuming that the account (e, s) was last modified in epoch e′ (e ≤ e′ < f), then it is necessary to provide proof that the account (e, s) appears at the corresponding position on state tree S e′ , and on these trees S e′+1 , Se′+2 ...S f-2 None of the corresponding positions appeared.

[0228] Similarly, it should be noted that a storage path can only be created on the current state tree after the second proof information has been generated; otherwise, state information cannot be stored in the current state tree. In other words, the implementation will include a check for the second proof information; without it, the next storage operation cannot proceed.

[0229] The second proof information in this step can be generated in the following ways: either the Walker proof or the "proof generation method" described above.

[0230] S410, When the state data is in the current period e now When a change occurs, the current state tree S corresponding to the current period. now Update the status data.

[0231] In this step, if the account corresponding to the status data has multiple transactions within the same period, the status data will be updated directly in the storage slot of the current status tree.

[0232] This corresponds to the description in S303:

[0233] 1. If account (e, s) is created and modified during period e, then directly in tree S e Create and modify the corresponding location;

[0234] 2. If account (e, s) is created or modified in period e+1, then directly in tree S e+1 Create and modify the corresponding location.

[0235] 5. If account (e, s) is modified in period f (f > e), and in tree S f The corresponding position has already been created; you can modify it directly.

[0236] S411. Delete the state data from each historical state tree, retaining only the state data in each state tree S. n The hash value of the corresponding storage path.

[0237] Since this application stores the state tree of the blockchain at different times separately, if the "state" is not deduplicated, it will bring a lot of storage overhead to the blockchain nodes, especially full nodes.

[0238] This application uses a historical state tree pruning method: if the "state" of an account (i.e., the state data in this article) changes in the current period, the current state tree will save the latest "state" of the account. Therefore, all nodes can delete the old state of the account from each historical state tree and only retain the node hash value at the corresponding position in the state tree.

[0239] This application provides a blockchain state data processing method, which processes blockchain state data at each period e n At the beginning, creation and period e n The corresponding state tree S n Acquire state data, which includes: period identifiers and information necessary for blockchain nodes to process incoming blocks and / or received business events; store the state data in the state tree S according to the period identifiers and preset requirements. n This is to facilitate blockchain nodes accessing state data when processing various business transactions; the preset requirements include: each period e n The state data generated internally can only be stored in the period e. n The corresponding state tree S n This technology addresses the technical problem of a significant decrease in the efficiency of retrieving and accessing state data after a blockchain system has been running for a period of time. It effectively prevents the explosive growth of state data from causing a decline in the transaction processing efficiency or capacity of blockchain nodes.

[0240] To facilitate understanding of the methods provided in the two embodiments above, an example is given below from the perspective of time progression, involving three periods: period 0, period 1, and period 2. It should be noted that period 0 and period 1 are two adjacent periods, but period 1 and period 2 are not necessarily adjacent.

[0241] After the blockchain system is initialized, all nodes in the blockchain system create a first state tree S0 corresponding to the current period T0.

[0242] 1. When time reaches period 0, that is, when the current period is period 0:

[0243] At the start of period 0, all nodes create their own first state tree S0, which is the current state tree for the current period.

[0244] Any user-end node in the blockchain network receives a transaction initiated by a user and creates a corresponding smart contract for that transaction.

[0245] The block-producing node then receives and executes the transaction. The block-producing node generates a contract address for the smart contract, which includes a period prefix and an address code. The period prefix corresponds to the current period.

[0246] Then, the block-producing node follows the pre-defined first rule for accessing and modifying accounts (i.e., 1. if account (e, s) is created and modified in period e, then directly in tree S). e The smart contract's storage address on the first state tree S0 is determined by creating and modifying corresponding locations and the contract address. This involves creating child nodes and corresponding storage slots on several intermediate nodes in the first state tree S0. It's important to note that these intermediate nodes are all included in the address encoding of the storage address. Because each intermediate node corresponds to at least one child node in the state tree, they are also called parent nodes. Furthermore, all child nodes corresponding to a parent node can be placed in a child node set to facilitate retrieval and access within the state tree.

[0247] Next, the block-producing node saves the smart contract data in the storage slot.

[0248] Then, the block-producing node updates the accumulator vector and accumulator value corresponding to each set of child nodes. The parent node corresponding to the set of child nodes is contained in the storage address. The storage address includes at least one parent node, which is an intermediate node on the state tree.

[0249] Then, the block-producing node packages the transactions into a block and publishes the block to the blockchain network.

[0250] After receiving the block, other nodes on the blockchain network execute the transaction. They also need to create child nodes and storage slots at the corresponding positions on their own first state tree S0 according to the first preset requirements, store the smart contract data in the corresponding storage slots, and update the accumulator vector and accumulator value corresponding to each child node set.

[0251] At any time within period 0, if any user interacts with the aforementioned smart contract through a transaction initiated by the user-end node, the block-producing node corresponding to this transaction will directly modify the data in the corresponding storage slot on the first state tree S0. At the same time, after the block of this transaction is published to the blockchain network by the block-producing node for consensus, all other nodes will also perform the same operation as the block node, that is, modify the data in the corresponding storage slot on the first state tree S0 of each node.

[0252] For example: at the beginning of period 0, that is, after the blockchain system has completed initialization, all nodes create the first state tree S0 respectively;

[0253] (1) Zhang San sends a transaction to create a smart contract C1, and Li Si sends a transaction to create a smart contract C2.

[0254] (2) After receiving the transaction, the block-producing node executes the transaction, generating an address (0, 0xabcdef) for smart contract C1 and an address (0, 0x123456) for smart contract C2. According to account access and modification rule 1 (i.e.: 1. If account (e, s) is created and modified in period e, then directly in tree S... e (Creating and modifying at the corresponding positions), the block-producing node creates child nodes and storage slots at the positions corresponding to 0x3a4b5c and 0x6d7e8f in the first state tree S0, saves the smart contract data in the corresponding storage slots, and updates the accumulator vector and accumulator value of the child node set containing 3a, 4b, 5c, 6d, 7e, and 8f in the first state tree S0.

[0255] It should be noted that the algorithm for generating the address here can be a hash algorithm, i.e., hash(0,0xabcdef)=0x3a4b5c, hash(0,0x123456)=0x6d7e8f.

[0256] (3) The block-producing node packages the transaction into a block. After receiving the block, other nodes execute the transaction, create child nodes and storage slots at positions 0x3a4b5c and 0x6d7e8f in their respective state trees S0, save the smart contract data in the corresponding storage slots, and update the accumulator vector and accumulator value of the child node set where 3a, 4b, 5c, 6d, 7e, and 8f are located in the state tree S0.

[0257] (4) During this period, any user can send a transaction to interact with smart contracts C1 or C2 and directly modify the data in the storage slot corresponding to position 0x3a4b5c or 0x6d7e8f in the first state tree S0. The same operation is performed after transactions in other synchronized blocks.

[0258] II. When time reaches period 1, that is, when period 1 is the current period:

[0259] Entering the new era, all nodes create a new blank state tree S1 and save the state tree S0.

[0260] (1) Any user sends a transaction and interacts with the smart contract C1 at address (0, 0xabcdef);

[0261] (2) After receiving the transaction, the block-producing node executes the transaction (regardless of whether the block-producing node is a full node or a light node). It finds that there is no state data with key 0x3a4b5c in state tree S1, and then searches in state tree S0 and finds state data with key 0x3a4b5c.

[0262] (3) The block-producing node constructs a proof for this transaction. The proof key 0x3a4b5c exists in the state tree S0. This proof and the transaction are bound together and packaged into a block.

[0263] (4) The block-producing node operates according to account access and modification rule 2 (i.e., 2. If account (e, s) is created or modified in period e+1, then it is directly added to tree S). e+1 (Create and modify the corresponding positions), create a child node and storage slot at position 0x3a4b5c in state tree S1, store the state data after the transaction is executed in this position, and update the accumulator vector and accumulator value of the child node set where 3a, 4b, and 5c are located in state tree S1.

[0264] (5) Other nodes execute transactions and verify proofs after receiving the block. If incorrect, reject the entire block; if correct, also according to account access and modification rule 2 (i.e., 2. If account (e, s) was created or modified in period e+1, then directly in tree S). e+1 (Create and modify the corresponding positions), create child nodes and storage slots at positions 0x3a4b5c in their respective state trees S1, save the new state data in the corresponding storage slots, and update the accumulator vector and accumulator value of the child node set where 3a, 4b, and 5c are located in state tree S1.

[0265] (6) Subsequently, during this period, any user sends a transaction to interact with the smart contract C1. The block-producing node, according to account access and modification rule 2, directly modifies the data at position 0x3a4b5c in the state tree S1 and the corresponding storage slot. The same operation is performed after transactions in other synchronized blocks.

[0266] III. When time reaches period 2, that is, when period 2 is the current period:

[0267] Entering the new phase, all nodes create a new blank state tree S2 and save the state tree S1. Full nodes continue to save the state tree S0, while light nodes discard the state tree S0.

[0268] 1. Any user sends a transaction and interacts with smart contract C1 at address (0, 0xabcdef). All nodes process the transaction in the same way as in period 1.

[0269] 2. Any user sends a transaction and interacts with the smart contract C2 at address (0, 0x123456):

[0270] 1) If the block-producing node is a full node, it finds no state data with key 0x6d7e8f in state tree S2, then searches in the historical state tree and finds state data with key 0x6d7e8f in S0. The full node then generates a proof for this transaction. This proves that key 0x6d7e8f exists in state tree S0 but not in state tree S1. This proof is then bundled with the transaction and packaged into a block. According to account access and modification rule 4, a child node and storage slot are created at position 0x6d7e8f in state tree S2. The state data after the transaction execution is stored at this position. The accumulator vector and accumulator value of the child node set containing 6d, 7e, and 8f in state tree S2 are updated. The operations for other nodes are similar to step 5 in period 1.

[0271] 2) If the block-producing node is a light node and finds that there is no state data with key 0x6d7e8f in state trees S2 and S1, it requests proof of the state data from the full node. The full node's processing is the same as in the previous step. After receiving the proof, the block-producing node verifies and executes the transaction, and subsequent operations are the same as those of the full node in the previous step.

[0272] Subsequently, during this period, any user sending a transaction interacts with the smart contract C2. The block-producing node, based on account access and modification rule 5, directly modifies the data at position 0x3a4b5c in the state tree S1 and the corresponding storage slot. The same operation is performed after transactions in other synchronized blocks.

[0273] 3. Wang Wu sends a transaction using an address (0, 0x456789):

[0274] 1) If the block-producing node is a full node, and it finds no state data with key 0xa1b2c3 in state tree S2 (assuming hash(0, 0x456789) = 0xa1b2c3), and then searches the historical state tree but still cannot find state data with key 0xa1b2c3, the full node generates a proof for this transaction. This proves that the key 0xa1b2c3 does not exist in state trees S0 and S1, and then packages this proof and the transaction together into a block. According to account access and modification rule 3, a child node and storage slot are created at position 0xa1b2c3 in state tree S2, and the state data after the transaction execution is stored at this position. The accumulator vector and accumulator value of the child node sets containing a1, b2, and c3 in state tree S2 are updated. The operations on other nodes are similar to step 5 in period 1.

[0275] 2) If the block-producing node is a light node and finds that there is no state data with key 0xa1b2c3 in state trees S2 and S1, it requests proof of the state data from the full node. The full node's processing is the same as in the previous step. After receiving the proof, the block-producing node verifies and executes the transaction, and subsequent operations are the same as those of the full node in the previous step.

[0276] Subsequently, during this period, Wang Wu used this address to send transactions. Based on account access and modification rule 5, the block-producing node directly modified the data at position 0xa1b2c3 in state tree S2 and the corresponding storage slot. Other synchronized blocks performed the same operation after their transactions.

[0277] The blockchain state data processing method provided in this application effectively and permanently solves the storage pressure on all nodes caused by the explosive growth of blockchain state, without affecting the user experience. The original smart contract programming method remains unchanged; only the underlying virtual machine makes corresponding changes when modifying account states. It introduces a validator role that does not require storing the blockchain state, allowing more people to participate in block and transaction verification and increasing the security of the blockchain system. The existence of lightweight nodes makes transaction processing and block production more efficient because computational resources are not wasted on modifying a massive state tree. Full nodes can also use strategies to store expired states that have not been accessed for a long time on disk and retrieve them when needed.

[0278] Figure 5 This is a schematic diagram of a blockchain state data processing device provided in an embodiment of this application. The blockchain state data processing device 500 can be implemented through software, hardware, or a combination of both.

[0279] like Figure 5 As shown, the blockchain state data processing device 500 includes:

[0280] Processing module 502, used in each period e n At the beginning, creation and period e n The corresponding state tree S n ;

[0281] The acquisition module 501 is used to acquire status data, which includes: period identifiers and information necessary for blockchain nodes to process incoming blocks and / or received business events;

[0282] Processing module 502 is also used to store state data into state tree S according to the period identifier and preset requirements. n This allows blockchain nodes to access state data when processing various business transactions;

[0283] The preset requirements include: e for each period n The state data generated internally can only be stored in the period e. n The corresponding state tree S n middle.

[0284] In one possible design, processing module 502 is further configured to, at the beginning of each period, if the blockchain node contains the first historical state tree S of the previous period,n-1 Then save and freeze the first historical state tree S. n-1 .

[0285] In one possible design, when the blockchain node is a full node, each period's e is stored in the full node. n The corresponding state tree S n ;

[0286] When a blockchain node is a light node, at least the following should be stored in the light node: state tree S n and the first historical state tree S n-1 And in the current period e n At the beginning, delete the second historical state tree S that does not meet the preset storage requirements. m .

[0287] In one possible design, the preset storage requirements include: a second historical state tree S. m Corresponding historical period e m With the current period e n The time interval is less than the preset interval.

[0288] In one possible design, the lightweight node can store a preset number of consecutive periods e. n All corresponding state trees S n The preset quantity is greater than or equal to 2.

[0289] In one possible design, module 501 is used for:

[0290] Obtain the blocks sent by the block-producing node and determine the status data based on the blocks;

[0291] Alternatively, obtain the transaction request sent by the user and determine the status data based on the transaction request.

[0292] In one possible design, the address corresponding to the status data includes: a period identifier and an address code. Correspondingly, the processing module 502 is used for:

[0293] In the current period e now The corresponding current state tree S now The system checks if a corresponding storage path exists based on the address.

[0294] When a storage path exists, the state data is stored in the current state tree S according to the storage path. now middle;

[0295] If no storage path exists, determine whether the period identifier meets the proof-free requirement;

[0296] If the proof-free requirement is met, then in the current state tree S nowAbove, create the corresponding storage path based on the address code;

[0297] Store the state data into the current state tree S according to the storage path. now middle.

[0298] In one possible design, processing module 502 is used for:

[0299] Determine whether the state tree S0 corresponding to the period identifier is stored in any blockchain node of the blockchain network.

[0300] In one possible design, processing module 502 is used for:

[0301] Determine whether the first period e0 is in the current period e now Within the previously preset time range, the first period e0 corresponds to the period identifier.

[0302] Optionally, the time range includes: k periods, where each period is e. n The duration of the duration, k is greater than or equal to 1.

[0303] In one possible design, processing module 502 is also used for:

[0304] If the proof-free requirement is not met, then based on the address, determine whether state data exists in the historical state tree corresponding to each historical period;

[0305] If it does not exist, the first proof information is generated using the preset verification model. When the blockchain node is a block producing node, the first proof information is added to the block corresponding to the state data, and the block is sent to the blockchain network for consensus. The first proof information is used to characterize that the state data is not on any historical state tree.

[0306] And in the current state tree S now Above, a storage path is created based on the address code, and the state data is stored into the current state tree S according to the storage path. now middle.

[0307] In one possible design, processing module 502 is used for:

[0308] On the target history state tree corresponding to each target historical period, the existence of state data is determined according to the address code. The target historical period includes: each historical period starting from the first period e0 corresponding to the period identifier;

[0309] The target historical state tree does not include the state trees of each light node already stored on the light nodes. The light node state tree includes at least the state tree S for the current period. n And the first historical state tree S of the period preceding the current periodn-1 .

[0310] Optionally, the target historical period does not include: the current period e now and the current period e now The previous period e now-1 .

[0311] In one possible design, processing module 502 is also used for:

[0312] If it exists, the second proof information is generated using the preset verification model. When the blockchain node is a block producing node, the second proof information is added to the block corresponding to the state data, and the block is sent to the blockchain network for consensus. The second proof information is used to represent that the state data is on the second state tree S1 corresponding to the last modification, and there is no state data on any historical state tree after the last modification period e1. The last modification period corresponds to the second state tree S1.

[0313] And in the current state tree S now Above, a storage path is created based on the address code, and the state data is stored into the current state tree S according to the storage path. now middle.

[0314] In one possible design, processing module 502 is also used for:

[0315] When the state data is in the current period e now When a change occurs, the current state tree S corresponding to the current period. now Update the status data;

[0316] All blockchain nodes on the blockchain network will delete state data from each historical state tree, retaining only the state data in each state tree S. n The hash value of the corresponding storage path.

[0317] In one possible design, processing module 502 is used for:

[0318] The previous period e n-1 The corresponding first historical state tree S n-1 After deleting nodes whose access frequency is less than a preset threshold, the state tree S is obtained. n .

[0319] It is worth noting that, Figure 5 The apparatus provided in the illustrated embodiments can execute the methods provided in any of the above method embodiments. Their specific implementation principles, technical features, explanations of technical terms, and technical effects are similar and will not be repeated here.

[0320] Figure 6This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6 As shown, the electronic device 600 may include at least one processor 601 and a memory 602. Figure 6 The example shown is an electronic device using a processor.

[0321] The memory 602 is used to store programs. Specifically, the program may include program code, which includes computer operation instructions.

[0322] The memory 602 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0323] The processor 601 is used to execute computer execution instructions stored in the memory 602 to implement the methods described in the above embodiments.

[0324] The processor 601 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0325] Optionally, the memory 602 can be either standalone or integrated with the processor 601. When the memory 602 is a device independent of the processor 601, the electronic device 600 may further include:

[0326] Bus 603 is used to connect the processor 601 and the memory 602. The bus can be an industry standard architecture (ISA) bus, a peripheral component (PCI) bus, or an extended industry standard architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc., but this does not mean there is only one bus or one type of bus.

[0327] Optionally, in a specific implementation, if the memory 602 and the processor 601 are integrated on a single chip, the memory 602 and the processor 601 can communicate through an internal interface.

[0328] This application also provides a computer-readable storage medium, which may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a disk, or an optical disk. Specifically, the computer-readable storage medium stores program instructions, which are used in the methods described in the above-mentioned method embodiments.

[0329] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the methods described in the above-described method embodiments.

[0330] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0331] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for processing blockchain state data, characterized in that, Applied to blockchain nodes, the method includes: At each epoch e n At the start, a state tree S n corresponding to the epoch e n is created; The system obtains a block sent by the block-producing node and determines the status data based on the block; or, it obtains a transaction request sent by a user and determines the status data based on the transaction request. The status data includes: a period identifier and information necessary for the blockchain node to process the incoming block and / or received business events; the address corresponding to the status data includes: the period identifier and the address code. In the current period e now The corresponding current state tree S now In the above, it is judged whether there is a corresponding storage path according to the address; when said storage path is present, storing said state data into said current state tree S according to said storage path now ; If the storage path does not exist, determine whether the period identifier meets the proof-free requirement; If the attestation requirement is satisfied, then in the current state tree S now The storage path corresponding to the address code is created according to the address code. According to the storage path and preset requirements, the state data is stored in the current state tree S. now This allows the blockchain nodes to access the state data when processing various business transactions; wherein, the preset requirements include: for each period e n The state data generated within can only be stored in the period e. n The corresponding state tree S n middle; When the state data is in the current period e now When a change occurs, the current state tree S corresponding to the current period... now Update the status data above; All blockchain nodes on the blockchain network will delete the state data from each historical state tree, retaining only the state data in each state tree S. n The hash value of the corresponding storage path.

2. The blockchain state data processing method according to claim 1, characterized in that, Also includes: At the beginning of each period, if the blockchain node contains the first historical state tree S of the previous period... n-1 Then save and freeze the first historical state tree S. n-1 .

3. The blockchain state data processing method according to claim 2, characterized in that, When the blockchain node is a full node, each period e is stored in the full node. n The corresponding state tree S n ; When the blockchain node is a light node, at least the state tree S is stored in the light node. n and the first historical state tree S n-1 And in the current period e n At the beginning, delete the second historical state tree S that does not meet the preset storage requirements. m .

4. The blockchain state data processing method according to claim 3, characterized in that, The preset storage requirements include: the second historical state tree S m Corresponding historical period e m With the current period e n The time interval is less than the preset interval.

5. The blockchain state data processing method according to claim 3, characterized in that, The light node can store a preset number of consecutive periods e. n All the corresponding state trees S n The preset quantity is greater than or equal to 2.

6. The blockchain state data processing method according to claim 1, characterized in that, The determination of whether the period identifier meets the proof-free requirement includes: Determine whether the state tree S0 corresponding to the period identifier is stored in any of the blockchain nodes in the blockchain network.

7. The blockchain state data processing method according to claim 1, characterized in that, The determination of whether the period identifier meets the proof-free requirement includes: Determine whether the first period e0 is in the current period e now Within the previously preset time range, the first period e0 corresponds to the period identifier.

8. The blockchain state data processing method according to claim 7, characterized in that, The time range includes k periods, where each period is e. n The duration of the duration, wherein k is greater than or equal to 1.

9. The blockchain state data processing method according to claim 1, characterized in that, After determining whether the period identifier meets the proof-free requirement, the method further includes: If the proof-free requirement is not met, then based on the address, determine whether the state data exists in the historical state tree corresponding to each historical period; If it does not exist, the first proof information is generated using a preset verification model. When the blockchain node is a block-producing node, the first proof information is added to the block corresponding to the state data, and the block is sent to the blockchain network for consensus. The first proof information is used to characterize that the state data is not on any of the historical state trees. And in the current state tree S now The storage path is created based on the address encoding, and the state data is stored in the current state tree S according to the storage path. now middle.

10. The blockchain state data processing method according to claim 9, characterized in that, The step of determining whether the state data exists in the historical state tree corresponding to each historical period based on the address includes: On the target history state tree corresponding to each target historical period, it is determined whether the state data exists based on the address code. The target historical period includes each of the historical periods starting from the first period e0 corresponding to the period identifier. The target historical state tree does not include the state trees of each light node already stored on the light nodes, and the light node state tree includes at least the state tree S of the current period. n And the first historical state tree S of the period preceding the current period n-1 .

11. The blockchain state data processing method according to claim 10, characterized in that, The target historical period does not include: the current period e now and the current period e now The previous period e now-1 .

12. The blockchain state data processing method according to claim 10, characterized in that, After determining whether the state data exists in the target history state tree corresponding to each target historical period based on the address code, the method further includes: If it exists, the second proof information is generated using the preset verification model. When the blockchain node is the block-producing node, the second proof information is added to the block corresponding to the state data, and the block is sent to the blockchain network for consensus. The second proof information is used to characterize that the state data is on the second state tree S1 corresponding to the last modification, and the state data does not exist on any of the historical state trees after the last modification period e1. The last modification period corresponds to the second state tree S1. And in the current state tree S now The storage path is created based on the address encoding, and the state data is stored in the current state tree S according to the storage path. now middle.

13. The blockchain state data processing method according to claim 1, characterized in that, In each period e n At the beginning, create a period e. n The corresponding state tree S n ,include: The previous period e n-1 The corresponding first historical state tree S n-1 In the process, after deleting nodes whose access frequency is less than a preset threshold, the state tree S is obtained. n .

Images