WO2023093041A1 - 区块链状态数据处理方法 - Google Patents

区块链状态数据处理方法 Download PDF

Info

Publication number
WO2023093041A1
WO2023093041A1 PCT/CN2022/102159 CN2022102159W WO2023093041A1 WO 2023093041 A1 WO2023093041 A1 WO 2023093041A1 CN 2022102159 W CN2022102159 W CN 2022102159W WO 2023093041 A1 WO2023093041 A1 WO 2023093041A1
Authority
WO
WIPO (PCT)
Prior art keywords
period
state
state data
tree
node
Prior art date
Application number
PCT/CN2022/102159
Other languages
English (en)
French (fr)
Inventor
冼祥斌
周禄
张开翔
范瑞彬
Original Assignee
深圳前海微众银行股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 深圳前海微众银行股份有限公司 filed Critical 深圳前海微众银行股份有限公司
Publication of WO2023093041A1 publication Critical patent/WO2023093041A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Definitions

  • This application relates to the field of financial technology (Fintech), in particular to a method for processing blockchain state data.
  • each blockchain node generally uses a tree-like storage structure, that is, a state tree, to store the information necessary for the operation of the blockchain node, that is, state data.
  • a state tree the information necessary for the operation of the blockchain node.
  • state data is getting more and more The more there are, the larger the state tree is, which greatly reduces the efficiency of data retrieval and access.
  • the present application provides a blockchain state data processing method to solve the technical problem in the prior art that the efficiency of state data retrieval and access drops significantly after the blockchain system has been running for a period of time.
  • the application provides a method for processing blockchain state data, which is applied to blockchain nodes, and the method includes:
  • Obtain state data which includes: period identification and information necessary for blockchain nodes to process incoming blocks and/or received business events;
  • the state data is stored in the state tree Sn, so that the blockchain nodes can call the state data when processing various businesses;
  • the preset requirements include: the state data generated in each period en can only be stored in the state tree Sn corresponding to the period en.
  • the method also includes: at the beginning of each period, if the first historical state tree Sn-1 of the previous period exists in the blockchain node, saving and freezing the first historical state tree Sn -1.
  • the state tree Sn corresponding to each period en is saved in the full node;
  • the blockchain node When the blockchain node is a light node, at least save the state tree Sn and the first historical state tree Sn-1 in the light node, and delete the second history that does not meet the preset storage requirements when the current period en starts State tree Sm.
  • the preset storage requirement includes: the time interval between the historical period em corresponding to the second historical state tree Sm and the current period en is smaller than the preset interval.
  • all state trees Sn corresponding to a preset number of consecutive periods en can be saved in the light node, and the preset number is greater than or equal to 2.
  • state data is obtained, including:
  • the address corresponding to the state data includes: period identification and address code, and according to the period identification and preset requirements, the state data is stored in the state tree Sn, including:
  • judging whether the period identification meets the certification-free requirements includes:
  • the time range includes: k periods, the period is the duration of each period en, and k is greater than or equal to 1.
  • the preset verification model uses the preset verification model to generate the first certification information, and when the blockchain node is a block node, add the first certification information to the block corresponding to the state data, and send the block to the block Consensus is carried out in the block chain network, and the first proof information is used to represent that the state data is not in each historical state tree;
  • the target historical period includes: each historical period starting from the first period e0 corresponding to the period identifier;
  • the target historical state tree does not include each light node state tree already stored on the light node, and the light node state tree at least includes: the state tree Sn of the current period and the first historical state tree Sn-1 of a period before the current period.
  • the target historical period does not include: the current period enow and the previous period enow-1 of the current period enow.
  • the target historical state tree corresponding to each target historical period after judging whether there is state data according to the address code, it also includes:
  • the second certification information is used to represent: the state data is on the second state tree S1 corresponding to the last modification time, and there is no state data on each historical state tree after the last modification period e1 , the last modification period corresponds to the second state tree S1;
  • All blockchain nodes on the blockchain network delete the state data from each historical state tree, and only retain the hash value of the corresponding storage path of the state data in each state tree Sn.
  • a state tree Sn corresponding to period en is created, including:
  • the state tree Sn is obtained after deleting the nodes whose access frequency is less than the preset threshold in the first historical state tree Sn-1 corresponding to en-1 in the previous period.
  • the present application provides a block chain state data processing device, including:
  • a processing module configured to create a state tree Sn corresponding to the period en at the beginning of each period en;
  • the obtaining module is used to obtain status data, and the status data includes: period identification and information necessary for blockchain nodes to process incoming blocks and/or received business events;
  • the processing module is also used to store the state data in the state tree Sn according to the period identification and preset requirements, so that the blockchain nodes can call the state data when processing various services;
  • the preset requirements include: the state data generated in each period en can only be stored in the state tree Sn corresponding to the period en.
  • the present application provides an electronic device, including:
  • the processor is configured to invoke and execute the program instructions in the memory, and execute any possible method for determining item storage information provided in the first aspect.
  • the present application provides a storage medium, in which a computer program is stored in the readable storage medium, and the computer program is used to execute any possible blockchain state data processing method provided in the first aspect.
  • the present application also provides a computer program product, including a computer program.
  • a computer program product including a computer program.
  • the computer program is executed by a processor, any possible blockchain state data processing method provided in the first aspect is implemented.
  • This application provides a blockchain state data processing method, by creating a state tree Sn corresponding to the period en at the beginning of each period en; obtaining state data, the state data includes: period identification and blockchain nodes are Information necessary to process incoming blocks and/or received business events; store state data in state tree Sn according to period identification and preset requirements, so that blockchain nodes can call when processing various businesses State data; wherein, the preset requirements include: the state data generated in each period en can only be stored in the state tree Sn corresponding to the period en.
  • Fig. 1 is a schematic structural diagram of a state tree provided by the present application.
  • FIG. 2 is a schematic diagram of an application scenario of a blockchain state data processing method provided by an embodiment of the present application
  • FIG. 3 is a schematic flow diagram of a blockchain state data processing method provided by the present application.
  • Fig. 4 is a schematic flow diagram of another block chain state data processing method provided by the implementation of the present application.
  • FIG. 5 is a schematic structural diagram of a block chain state data processing device provided by an embodiment of the present application.
  • FIG. 6 is a schematic structural diagram of an electronic device provided by the present application.
  • nodes in the blockchain network will save some data on the local storage device after running in the network for a period of time. These data can be divided into two categories according to their time attributes: historical data (referred to as “history” for short) ) and current data (referred to as “state”).
  • State Refers to the information that nodes of a blockchain system must hold or store in order to be able to process new incoming blocks and/or events. State is relative to history.
  • History It is the descriptive information of events that have occurred in the past. After the history is saved, it can be used to review or replay the events that have occurred, and it can also archive and manage the history.
  • the state includes:
  • the relevant data required for consensus between each node is the consensus data, such as the hash value, quantity, proof of rights and other consensus data of several recently generated blocks.
  • Paschal-Merkle tree It is a dictionary tree with a root node, intermediate nodes and leaf nodes. Each node has a unique "key”. According to the "key" of the state data, it can be in the state tree Find the storage location corresponding to this "key”, and then store the "value” in the state data in the storage slot of this storage location.
  • an account such as 0x001d3f1ef827
  • the intermediate node in that is, the "key” represents the address of the intermediate node or the path used to find the intermediate node), so all the state data of this account are stored under the subtree of this intermediate node.
  • Volker tree It is essentially a dictionary tree, and its storage and retrieval of state data is similar to that of the Pashall-Merkel tree, but the Volcker tree is wider, that is, the number of child nodes of a node in the Volker tree n 1 is much larger than the number of child nodes n 2 of a node in the Paschal-Merkel tree (that is, n 1 >>n 2 ), so for a fixed-length key address, the depth of the Walker tree (that is, the tree The total number of layers in layers) is much smaller than the Paschal-Merkel tree. Due to the small depth, the operation of adding and modifying nodes in the Walker tree is simpler. More importantly, for the proof of the existence of nodes (that is, the verification data), the Volcker tree adopts the Volcker proof, which is smaller than the Merkle proof of the Paschal-Merkel tree.
  • Walker proof It is to prove that a node is one of the many child nodes of its parent node by adopting polynomial commitment (a kind of vector commitment). Since the value of the parent node in the Walker tree is determined by the values of all child nodes, it is equivalent to only proving the relationship between the value of a node and the value of its parent node, without providing all The value of the sibling node can verify the relationship between the node and the parent node. So the Walker proof is very small and more efficient to verify.
  • Full node refers to the node that saves all the data of the blockchain. It saves complete “state” data and all “historical” data (some consortium chains discard state data in historical blocks such as FISCO BCOS).
  • Light node refers to a node that only saves some commonly used state data. This makes the light node more able to save memory space than the weight node, and at the same time, it can process most of the user's transactions and package blocks. It should be noted that in different blockchain systems, the functions of light nodes are not necessarily the same.
  • Verifier node refers to a node that only participates in verifying the correctness of blocks in the consensus system, but does not have the ability to pack blocks. Also in different blockchain systems, in order for the verifier node to verify the correctness of the block, the size of the state that needs to be stored is also different.
  • the full node includes: the body part of various blocks (that is, the body, a block can be divided into two parts: Header and Body), transaction list and other related information.
  • the full node saves a complete blockchain network locally, on which any query, transaction verification and broadcast can be performed. Because of the existence of the full node, the decentralization of the blockchain becomes possible, and at the same time makes the district Blockchain networks are more secure. It should be noted that generally all nodes need to remain online all the time.
  • the difference between a light node and a full node is that it does not need to save all transaction content. It only needs to save the Header of each block and the transaction details related to the node itself in the form of a state tree, and through the state tree corresponding The verification method (also called "proof") to determine whether the transaction is in the current blockchain transaction list. Unlike full nodes, light nodes do not need to stay online all the time.
  • Period epoch Indicates the time elapsed by a fixed number of blocks (such as 10,000 blocks).
  • the "state” that is, state data
  • the "state” created or modified in this period e will automatically become expired in the next period e+1 status".
  • each blockchain node will use a tree-like storage structure, that is, a state tree, to store the information necessary for the operation of the blockchain node, that is, state data, but With the continuous operation of the blockchain system, there are more and more state data, and the state tree is getting bigger and bigger, which greatly reduces the efficiency of data retrieval and access.
  • a state tree a tree-like storage structure
  • the state storage slot on the leaf node corresponding to each account starts timing after it is created, and restarts the timing if the state data in the state storage slot is modified within the preset time, On the contrary, if the status data of the account has not been modified after a preset period of time, the status data will be placed on the expired status tree.
  • Full nodes need to store these two trees, and other nodes, such as light nodes, only store active state trees. If the user wants to access the expired state of an account or revive the expired state of an account, he must provide the proof (that is, verification data) that the corresponding state of the account is on the expired state tree.
  • the organizational structure of the state tree can also be changed, that is, the Volker tree is used to fundamentally replace the existing Paschal-Merkel tree, but the original storage and retrieval logic will not be changed, and the accumulator can be combined
  • the size of the proof is only about 800KB, which is more suitable for the maintenance and management of state data in the blockchain.
  • the inventor of the present application resets the processing logic for state data in the blockchain:
  • FIG. 1 is a schematic structural diagram of a state tree provided by the present application.
  • each period has an independent state tree, so the state contains a list of ever-growing trees S 0 , S 1 , S 2 , S 3 ..., each S i represents the i-th period state tree. Therefore, no additional field is required to indicate whether the state is expired, and only the state on the state tree of the current period is the non-expired state.
  • the root 10 of each state tree forms a total state root 100. This total state root 100 is recorded in the header of each block. If any state tree changes, the total state root 100 will also change.
  • the type of the state tree includes a Walker tree.
  • the account For an account used for transaction business in a blockchain node, the account includes: contract accounts (contract accounts) and external accounts (Externally Owned Account, EOA).
  • contract accounts contracts
  • EOA External Account
  • a contract account is an account that conducts transactions through a smart contract and is controlled by the code of the smart contract. Only contract accounts have codes, which store codeHash (the hash value of the account’s Ethereum virtual machine code). This field cannot be modified after it is generated, which means that the smart contract code cannot be modified.
  • codeHash the hash value of the account
  • external accounts are accounts created by human users of the Ethereum network. It is associated with a public-private key pair, and it is derived from the last 20 bytes of the result of the double hash of the public key.
  • This application defines a new account address, which can be expressed as a tuple (e, s), e is the period identifier of the period to which the address belongs, expressed in 4 bytes, s is the original address, that is, the current blockchain generally The address encoding of the 20 bytes used. Therefore, the new account address is represented as [e:s] in binary, that is, the period identifier and the address code are byte-spliced.
  • the state tree in the historical period will be frozen, and all transactions that want to access the historical state tree must carry a certificate to prove the position of the state to be accessed in the state tree of a certain historical period, for example: Walker proof of the state position , the old state data values are included in the Volcker proof, so that the historical state tree can be accessed.
  • Walker proof of the state position the old state data values are included in the Volcker proof, so that the historical state tree can be accessed.
  • all blockchain nodes store the state tree S e-1 of the previous period, if the user needs to access the state data in the state tree S e-1 , the blockchain node will help the user provide proof of the state tree , and most of the hot data is in this state tree, so it can satisfy most users. But if the user's transaction wants to access the tree before Se -1 , it must find a full node to provide access proof.
  • the state tree of the future period can be established in advance, but it can only be modified after the future period becomes the current period, or it can be said that the state tree of the future period has not been created yet. After reaching a new period, the node immediately enables or creates a new state tree.
  • the state tree corresponding to this future period can be a blank state tree, or it can be attached with a tree node that stores some frequently accessed state data.
  • the account (e, s) can be accessed in any period of f>e, and its data is always stored in the fixed position hash(e, s) of the state tree. If in the current period epoch f, the storage of the account (e, s) is Modification, since the historical state tree cannot be modified, a corresponding storage slot will be created at the hash(e, s) position of the state tree Sf in the current period.
  • account (e, s) is created in epoch f (f>e+1), and the corresponding position on the tree S f and S f-1 has not been created, then a proof needs to be provided: account (e, s) None of the corresponding positions of these trees S e , S e+1 , ..., S f-2 appear;
  • This application adopts the method of historical state tree pruning: if the "state" of an account (that is, the state data in this paper) changes in the current period, the state tree of the current period will save the latest "state” of the account, so all The node 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.
  • the present invention adopts a cryptographic accumulator to make membership certification and non-member certification respectively.
  • the state tree 100 corresponding to each period has a depth of 4 and a breadth of 4 bytes, that is, the maximum number of child nodes in each layer is 256, expressed in hexadecimal as 00-ff.
  • the corresponding key of an account in the state tree is 0x3a4b5c.
  • the corresponding keys of the account are respectively numbered 3a, 4b and 5c at each layer of nodes. These numbers also constitute a corresponding account information stored in Unique path in the state tree. Therefore, when the user needs to prove that the account exists in the state tree, the system needs to prove the path of the key corresponding to the account, that is, make a membership certificate for the node number of each layer in the path.
  • node 3a is in the existing child node set of the root node; node 4b is in the existing child node set of 3a; 5c is in the existing child node set of 4b.
  • the existing sub-node set expresses the keys of all stored state data with these sub-nodes as the intermediate path, and the blockchain node or blockchain system maintains the existing sub-node set of each layer of the state tree, so for For any state tree, the second layer has 1 existing child node set, and the third layer has at most 256 existing child node sets.
  • g represents the generator of the domain used by the system.
  • Bezout is Bezout's theorem
  • a and b are two coefficients obtained according to Bezout's theorem.
  • FIG. 2 is a schematic diagram of an application scenario of a method for processing blockchain state data provided by an embodiment of the present application.
  • a user 20 sends a transaction request to any blockchain node 21 in the blockchain network or blockchain system, and the blockchain node 21 executes the transaction corresponding to the transaction request, so that the user corresponds to The status data of the account used for the transaction has changed, and the blockchain node 21 that receives the transaction request from the user 20 is also called a block node, which packages the transaction into a block and sends it to the blockchain network for other Blockchain nodes 21 perform consensus.
  • the generated state data is correspondingly stored in the state tree corresponding to the current period in the node, and other blockchain nodes 21 that receive the block also use the same state data processing
  • the method updates the status data on the local status tree of the respective blockchain nodes 21.
  • FIG. 3 is a schematic flowchart of a method for processing blockchain state data provided by an embodiment of the present application. As shown in Figure 3, the specific steps of the blockchain state data processing method include:
  • the blockchain node creates a new state tree S n according to the preset state tree template.
  • the historical state tree is the historical state tree of the period before the current period It will be frozen, and the historical state tree can be accessed and queried, but new state data cannot be stored in the historical state tree.
  • the type of the state tree is a Walker tree.
  • the first historical state tree S n-1 of the previous period exists in the blockchain node, the first historical state tree S n-1 is saved and frozen.
  • blockchain nodes in the entire blockchain network can be divided into two categories: full nodes and light nodes.
  • the blockchain node is a light node, save at least: the state tree S n and the first historical state tree S n-1 in the light node, and delete the ones that do not meet the preset storage requirements at the beginning of the current period e n Second historical state tree S m .
  • the preset storage requirement includes: the time interval between the historical period e m corresponding to the second historical state tree S m and the current period e n is smaller than the preset interval.
  • the light node when the preset interval is 2, the light node only stores the state tree of the current period and the previous period, and 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 , the full node conducts an access query on the corresponding historical state tree.
  • light nodes can also store state trees of more historical periods. For example, when the preset interval is 3-6, light nodes can store state trees of 3-5 consecutive periods.
  • the light node can also be a historical state tree of a discontinuous period, for example: save the current period, the previous 1 historical period, the previous 3 historical periods, and the state tree of these three periods.
  • the principle of preservation can be set as follows: if the creation and/or modification of state data in this historical period is greater than the preset threshold, or the transaction volume in this historical period is greater than the preset threshold, it proves that the state data in this historical period has a higher probability will be used, the state tree corresponding to the historical period will be kept in the blockchain node, and the historical state tree will not be deleted until the access heat of the corresponding state data is lower than the preset heat threshold.
  • those skilled in the art can also set the number and storage rules of the light nodes to save state trees according to the actual situation, but at least ensure that the light nodes at least include: the current state tree S n and the state tree S n-1 of the previous period. That is, all state trees S n corresponding to a preset number of consecutive periods e n can be saved in the light node, and the preset number is greater than or equal to 2.
  • this step after deleting the nodes whose access frequency is less than the preset threshold in the first historical state tree S n-1 corresponding to the previous period e n-1 , the current period e n is obtained State tree S n .
  • the status data includes: period identification and information necessary for the blockchain node to process incoming blocks and/or received business events.
  • This step can be divided into two situations:
  • Blockchain nodes are also called block producers.
  • acquiring status data includes: acquiring a transaction request sent by a user, and determining status data according to the transaction request.
  • the second type when the blockchain node is not the node that receives the user's transaction request, but the node that implements the consensus in the blockchain network, obtains the state data, including: obtaining the block sent by the block producing node, and determining according to the block status data.
  • the address corresponding to the state data includes: a period identifier and an address code.
  • the preset requirements include: the state data generated in each period e n can only be stored in the state tree S n corresponding to the period e n .
  • the blockchain state data processing method also includes:
  • All the blockchain nodes on the blockchain network delete the state data from each historical state tree, and only keep the hash value of the corresponding storage path of the state data in each state tree S n .
  • This application adopts the method of historical state tree pruning: if the "state" of an account (that is, the state data in this paper) changes in the current period, the state tree of the current period will save the latest "state” of the account, so all The node 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.
  • the embodiment of the present application provides a blockchain state data processing method, by creating a state tree S n corresponding to the period en at the beginning of each period en; obtaining state data, the state data includes: period identification and Information necessary for blockchain nodes to process incoming blocks and/or received business events; store state data in state tree S n according to period identification and preset requirements, so that blockchain nodes can
  • the state data is invoked when processing various services; wherein, the preset requirements include: the state data generated in each period e n can only be stored in the state tree S n corresponding to the period e n .
  • Fig. 4 is a schematic flowchart of another blockchain state data processing method provided by the implementation of this application. As shown in Figure 4, the specific steps of the block chain state data processing method include:
  • steps S401-S402 For specific terms and principle explanations of steps S401-S402, reference may be made to steps S301-S302, which will not be repeated here.
  • the storage path includes: various nodes and storage slots on the state tree S n , the nodes include intermediate nodes and leaf nodes, and the storage slots are set on the leaf nodes.
  • step S406 executes step S407.
  • the storage slot corresponding to the state data has not been created on the current state tree Snow , so it is necessary to create each intermediate node and leaf node, and at the same time create a storage slot on the leaf node, and then store the state data in the storage slot.
  • judging whether the certificate-free requirements are met according to the period identification includes:
  • the block chain network includes at least two types of block chain nodes, namely full nodes and light nodes.
  • the state trees corresponding to all periods are stored in the full nodes, but only part of the state trees are kept in the light nodes. However, at least the current state tree and the historical state tree of the previous period are saved in the light node.
  • the essence of exempting the proof requirement is: if the period corresponding to the period identifier in the address of the state data can be found in each period corresponding to all the state trees saved by the light node, then the current state can be directly Create a storage path based on the address on the tree, that is, each intermediate node, leaf node and storage slot, and then store the state data in the storage slot.
  • the light node stores the state trees corresponding to the four periods: e now in the current period, e now-1 in the previous period, e now-3 in the first three periods, and e now-5 in the first five periods.
  • the period identifier corresponds to any one of these four periods, so there is no need for the blockchain nodes to calculate the proof according to the proof algorithm, such as the Walker proof. (For the proof method, please refer to the "Proof Generation Method" described above)
  • judging whether the period identification meets the certification-free requirements includes:
  • the time range includes: k periods, the period is the duration of each period e n , and k is greater than or equal to 1.
  • the preset time range is 1 cycle, that is, the previous two periods e now-2 does not have a preset time range Inside.
  • step S404 is performed to store the state data into the storage slot.
  • step S408 if it does not exist, execute step S408, and if it exists, execute step S409.
  • the scope of the historical state tree needs to be further expanded.
  • the state tree of all periods is not stored in the light node. Therefore, for the light node, when this step is implemented, it can only send a proof request to the full node, and the full node will store it in its In the historical state tree to find whether to store the corresponding state data.
  • this step specifically includes:
  • the target historical period includes: each historical period starting from the first period e 0 corresponding to the period identifier;
  • the target historical state tree does not include each light node state tree that has been stored on the light node, and the light node state tree includes at least: the state tree S n of the current period and the first historical state tree S n of the period before the current period S n- 1 .
  • the target historical period does not include: the current period e now and the previous period e now-1 of the current period e now .
  • step S406 when the blockchain node is a block producing node, the first certification 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 certification information The data used to characterize the state is not on the individual historical state trees. Then, step S406 is executed.
  • account (e, s) is created in the period f (f>e+1), and the corresponding position on the tree S f and S f-1 has not been created, then a proof needs to be provided: account (e, s) None of the corresponding positions in these trees S e , S e+1 , . . . , S f-2 appear.
  • the generation method of the first proof information in this step includes the Walker proof, or the "proof generation method" described above.
  • step S406 when the blockchain node is a block producing node, the second certification information is added to the block corresponding to the state data, and the block is sent to the blockchain network for consensus, and the second certification information is used Characterized by: the state data is on the second state tree S 1 corresponding to the last modification time, and there is no state data on each historical state tree after the last modification period e 1 , the last modification period and the second state tree S 1 corresponds. Then, step S406 is executed.
  • the generation method of the second proof information in this step includes the Walker proof, or the "proof generation method" described above.
  • the state data is directly updated in the storage slot of the current state tree.
  • This application adopts the method of historical state tree pruning: if the "state" of an account (that is, the state data in this paper) changes in the current period, the state tree of the current period will save the latest "state” of the account, so all The node 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.
  • the embodiment of the present application provides a blockchain state data processing method, by creating a state tree S n corresponding to the period en at the beginning of each period en; obtaining state data, the state data includes: period identification and Information necessary for blockchain nodes to process incoming blocks and/or received business events; store state data in state tree S n according to period identification and preset requirements, so that blockchain nodes can
  • the state data is invoked when processing various services; wherein, the preset requirements include: the state data generated in each period e n can only be stored in the state tree S n corresponding to the period e n .
  • period 0 and period 1 are adjacent Two periods, but period 1 and period 2 are not necessarily adjacent.
  • all nodes in the blockchain system respectively create a first state tree S 0 corresponding to the current period T 0 .
  • Any client node in the blockchain network receives the transaction initiated by the user and creates a corresponding smart contract for the transaction.
  • the block node receives and executes the transaction, and the block node generates a contract address for the smart contract.
  • the contract address includes: period prefix and address code, and the period prefix corresponds to the current period.
  • the block producing node is based on the preset first rule requirements for accessing and modifying the account (i.e.: 1. If the account (e, s) is created and modified in period e, then directly in the corresponding position of the tree S e create and modify) and the contract address, determine the storage address of the smart contract on the first state tree S0 , that is, create child nodes and storage slots corresponding to the child nodes on several intermediate nodes on the first state tree S0 . It should be noted that these intermediate nodes are included in the address code of the storage address, because these intermediate nodes correspond to at least one child node in the state tree, so these intermediate nodes are also called parent nodes. Moreover, all the child nodes corresponding to a parent node can be placed in a child node set, so as to facilitate retrieval and access to the state tree.
  • the block producer saves the data of the smart contract in the storage slot.
  • the block producing node updates the accumulator vector and accumulator value corresponding to each child node set.
  • the parent node corresponding to the child node set is included in the storage address, and the storage address includes at least one parent node.
  • the parent node is the middle node.
  • the block producing node packs the transaction into a block and publishes the block to the blockchain network.
  • nodes on the blockchain network After other nodes on the blockchain network receive the block and execute the transaction, they also need to create child nodes and storage slots at the corresponding positions on the first state tree S0 of the node itself according to the first preset requirements, and put the smart contract
  • the data of is stored in the corresponding storage slot, and the accumulator vector and accumulator value corresponding to each child node set are updated at the same time.
  • the block producing node corresponding to this transaction directly modifies the data in the corresponding storage slot on the first state tree S 0 , and at the same time the After the transaction block is published by the block node to the blockchain network for consensus, all other nodes will also perform the same operation as the block node, that is, modify the corresponding storage slot on the first state tree S 0 of each node data.
  • Zhang San sends a transaction to create a smart contract C1
  • Li Si sends a transaction to create a smart contract C2.
  • the block producing node executes the transaction after receiving the transaction, and generates an address (0,0xabcdef) for the smart contract C1 and an address (0,0x123456) for the smart contract C2 respectively, according to the account access and modification rule 1 (ie: 1 . If the account (e, s) is created and modified in the period e, then it is directly created and modified at the corresponding position of the tree S e ), and the block producing node creates child nodes and The storage slot saves the data of the smart contract in the corresponding storage slot, and updates the accumulator vector and accumulator value of the child node set where 3a, 4b, 5c, 6d, 7e, and 8f are located in the first state tree S0.
  • the block producing node packs the transaction into a block, other nodes execute the transaction after receiving the block, create child nodes and storage slots at 0x3a4b5c and 0x6d7e8f of their state tree S0, and save the data of the smart contract in the
  • the corresponding storage slots update the accumulator vectors and accumulator values of the sub-node sets where 3a, 4b, 5c, 6d, 7e, and 8f are located in the state tree S0.
  • any user sends a transaction to interact with the smart contract C1 or C2, and directly modifies the data in the storage slot corresponding to the position 0x3a4b5c or 0x6d7e8f of the first state tree S0. Do the same after transactions in other sync blocks.
  • period 1 is the current period
  • the block producing node executes the transaction after receiving the transaction (regardless of whether the block producing node is a full node or a light node), and finds that there is no state data with the key 0x3a4b5c in the state tree S1, and then searches in the state tree S0, and finds the key Status data of 0x3a4b5c;
  • the block producing node builds a proof for this transaction
  • the proof key 0x3a4b5c exists in the state tree S0, and the proof is packaged into the block together with the transaction binding.
  • the block producing node is based on account access and modification rules 2 (ie: 2. If the account (e, s) is created or modified in period e+1, then it is directly created and modified at the corresponding position of tree Se +1 ) , create a child node and a storage slot at the position 0x3a4b5c of the state tree S1, store the state data after transaction execution in this position, and update the accumulator vector and accumulator value of the child node set where 3a, 4b, and 5c are located in the state tree S1;
  • account access and modification rules 2 ie: 2. If the account (e, s) is created or modified in period e+1, then it is directly created and modified at the corresponding position of tree Se +1 ) , create a child node and a storage slot at the position 0x3a4b5c of the state tree S1, store the state data after transaction execution in this position, and update the accumulator vector and accumulator value of the child node set where 3a, 4b
  • any user sends a transaction to interact with the smart contract C1, and the block producing node modifies the data directly at the position 0x3a4b5c of the state tree S1 and the corresponding storage slot according to the account access and modification rule 2. Do the same after transactions in other sync blocks.
  • period 2 is the current period
  • the block producing node is a full node, it is found that there is no state data with the key 0x6d7e8f in the state tree S2, and then searched in the historical state tree, and the state data with the key 0x6d7e8f is found in S0.
  • the full node generates a proof for the transaction That is, it is proved that the key 0x6d7e8f exists in the state tree S0 and does not exist in the state tree S1, and the proof is packaged into the block together with the transaction binding.
  • the block producing node is a light node and finds that there is no state data with the key 0x6d7e8f in both the state tree S2 and S1, it will request the proof of the state data from the full node, and the processing of the full node is the same as the previous step. After the block producing node is certified, it verifies and executes the transaction, and the subsequent operation is the same as that of the full node in the previous step.
  • any user sends a transaction to interact with the smart contract C2, and the block producing node directly modifies the data at the position 0x3a4b5c of the state tree S1 and the corresponding storage slot according to the account access and modification rule 5. Do the same after transactions in other sync blocks.
  • the full node generates a proof for the transaction That is, it is proved that the key 0xa1b2c3 does not exist in the state tree S0 and S1, and the proof is packaged into the block together with the transaction binding.
  • the block producing node is a light node and finds that there is no state data with the key 0xa1b2c3 in both the state tree S2 and S1, it will request the proof of the state data from the full node, and the processing of the full node is the same as the previous step. After the block producing node is certified, it verifies and executes the transaction, and the subsequent operation is the same as that of the full node in the previous step.
  • Wang Wu uses this address to send transactions, and the block producing node directly modifies the data at the position 0xa1b2c3 of the state tree S2 and the corresponding storage slot according to the account access and modification rule 5. Do the same after transactions in other sync blocks.
  • the blockchain state data processing method provided by this application can permanently solve the storage pressure brought by the explosive growth of the blockchain state to all nodes, and will not bring any difference in experience to ordinary users.
  • the programming method of the smart contract has not changed, only the underlying virtual machine makes corresponding changes when modifying the account status. It is possible to introduce a verifier role that does not need to store the state of the blockchain at all, so that more people can participate in the verification of blocks and transactions, and increase the security of the blockchain system.
  • the existence of light nodes makes transaction processing and block generation more efficient, because there is no need to waste computing resources on modifying huge state trees, and full nodes can also adopt some strategies to store expired states that have not been accessed for a long time in the hard disk. Time to call it out again.
  • Fig. 5 is a schematic structural diagram of a block chain state data processing device provided by an embodiment of the present application.
  • the block chain state data processing device 500 can be realized by software, hardware or a combination of both.
  • the block chain state data processing device 500 includes:
  • a processing module 502 configured to create a state tree S n corresponding to the period e n at the beginning of each period e n ;
  • the obtaining module 501 is used to obtain status data, the status data includes: period identification and information necessary for blockchain nodes to process incoming blocks and/or received business events;
  • the processing module 502 is also used to store the state data in the state tree S n according to the period identification and preset requirements, so that the blockchain nodes can call the state data when processing various services;
  • the preset requirements include: the state data generated in each period e n can only be stored in the state tree S n corresponding to the period e n .
  • the processing module 502 is also used to save and freeze the first history state tree S n-1 of the previous period if there is a first history state tree S n-1 in the blockchain node at the beginning of each period State tree S n-1 .
  • the state tree S n corresponding to each period e n is saved in the full node;
  • the blockchain node is a light node, save at least: the state tree S n and the first historical state tree S n-1 in the light node, and delete the ones that do not meet the preset storage requirements at the beginning of the current period e n Second historical state tree S m .
  • the preset storage requirement includes: the time interval between the historical period e m corresponding to the second historical state tree S m and the current period e n is smaller than the preset interval.
  • all state trees S n corresponding to a preset number of consecutive periods e n can be stored in the light node, and the preset number is greater than or equal to two.
  • the acquisition module 501 is used for:
  • the address corresponding to the state data includes: period identification and address code, correspondingly, the processing module 502 is used for:
  • the processing module 502 is configured to:
  • the processing module 502 is configured to:
  • the time range includes: k periods, the period is the duration of each period e n , and k is greater than or equal to 1.
  • processing module 502 is also used to:
  • the preset verification model uses the preset verification model to generate the first certification information, and when the blockchain node is a block node, add the first certification information to the block corresponding to the state data, and send the block to the block Consensus is carried out in the block chain network, and the first proof information is used to represent that the state data is not in each historical state tree;
  • the processing module 502 is configured to:
  • the target historical period includes: each historical period starting from the first period e 0 corresponding to the period identifier;
  • the target historical state tree does not include each light node state tree that has been stored on the light node, and the light node state tree includes at least: the state tree S n of the current period and the first historical state tree S n of the period before the current period S n- 1 .
  • the target historical period does not include: the current period e now and the previous period e now-1 of the current period e now .
  • processing module 502 is also used to:
  • the blockchain node is a block node
  • add the second certification information to the block corresponding to the state data, and send the block to the block Consensus is carried out in the chain network
  • the second proof information is used to represent: the state data is on the second state tree S 1 corresponding to the last modification, and does not exist in each historical state tree after the last modification period e 1 state data, the last modification period corresponds to the second state tree S1 ;
  • processing module 502 is also used to:
  • All blockchain nodes on the blockchain network delete the state data from each historical state tree, and only retain the hash value of the corresponding storage path of the state data in each state tree S n .
  • the processing module 502 is configured to:
  • a state tree S n is obtained after deleting nodes whose access frequency is less than a preset threshold in the first historical state tree S n-1 corresponding to the previous period e n-1 .
  • FIG. 6 is a schematic structural diagram of an electronic device provided by an embodiment of the present application. As shown in FIG. 6 , the electronic device 600 may include: at least one processor 601 and a memory 602 . FIG. 6 shows an electronic device with a processor as an example.
  • the memory 602 is used to store programs.
  • the program may include program code, and the program code includes computer operation instructions.
  • the memory 602 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.
  • the processor 601 is configured to execute the computer-executed instructions stored in the memory 602 to implement the methods described in the above method embodiments.
  • the processor 601 may be a central processing unit (central processing unit, referred to as CPU), or a specific integrated circuit (application specific integrated circuit, referred to as ASIC), or is configured to implement one or more of the embodiments of the present application. multiple integrated circuits.
  • CPU central processing unit
  • ASIC application specific integrated circuit
  • the memory 602 can be independent or integrated with the processor 601 .
  • the electronic device 600 may further include:
  • the bus 603 is used to connect the processor 601 and the memory 602 .
  • the bus may be an industry standard architecture (ISA) bus, a peripheral component interconnect (PCI) bus, or an extended industry standard architecture (EISA) bus, etc.
  • ISA industry standard architecture
  • PCI peripheral component interconnect
  • EISA extended industry standard architecture
  • the bus can be divided into address bus, data bus, control bus, etc., but it does not mean that there is only one bus or one type of bus.
  • the memory 602 and the processor 601 may communicate through an internal interface.
  • the embodiment of the present application also provides a computer-readable storage medium
  • the computer-readable storage medium may include: U disk, mobile hard disk, read-only memory (read-only memory, ROM), random access memory (random access memory) , RAM), a magnetic disk or an optical disk, and other media that can store program codes.
  • the computer-readable storage medium stores program instructions, and the program instructions are used in the methods in the above-mentioned method embodiments.
  • An embodiment of the present application further provides a computer program product, including a computer program, and when the computer program is executed by a processor, the methods in the foregoing method embodiments are implemented.
  • the embodiment of the present application also provides a computer program, including program code.
  • program code executes the methods in the above method embodiments.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Software Systems (AREA)
  • Health & Medical Sciences (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • General Business, Economics & Management (AREA)
  • Databases & Information Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请提供了一种区块链状态数据处理方法，应用于区块链节点，通过在每个时期e n开始时，创建与时期e n相对应的状态树S n；获取状态数据，状态数据包括：节点为处理传入的区块和/或接收到的业务事件所必须的信息；根据预设要求将状态数据存储到状态树S n中，以便于节点在处理各项业务时调用状态数据；其中，预设要求包括：每个时期e n内的状态数据只能存储到与时期e n对应的状态树S n中。解决了现有技术中存在当区块链系统运行一段时间后状态数据的检索和访问的效率大幅下降的技术问题。达到避免状态数据爆炸增长而导致区块链节点对交易处理效率或处理能力下降的技术效果。

Description

区块链状态数据处理方法
本申请要求于2021年11月26日提交中国专利局、申请号为202111426166.6、申请名称为“区块链状态数据处理方法”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及金融科技(Fintech)领域，尤其涉及一种区块链状态数据处理方法。
背景技术
随着计算机技术的发展，越来越多的技术应用在金融领域，传统金融业正在逐步向金融科技(Fintech)转变，区块链(Block chain)技术也不例外，但由于金融行业的安全性、实时性要求，也对技术提出的更高的要求。
目前，一般每个区块链节点都会用树状存储结构即状态树的形式，来保存区块链节点运行所必须的信息即状态数据，但是随着区块链系统不断运行，状态数据越来越多，状态树也越来越大，这就使得数据的检索和访问效率大大下降。
即现有技术中存在当区块链系统运行一段时间后状态数据的检索和访问的效率大幅下降的技术问题。
发明内容
本申请提供一种区块链状态数据处理方法，以解决现有技术中存在当区块链系统运行一段时间后状态数据的检索和访问的效率大幅下降的技术问题。
第一个方面，本申请提供一种区块链状态数据处理方法，应用于区块链节点，该方法包括：
在每个时期en开始时，创建与时期en相对应的状态树Sn；
获取状态数据，状态数据包括：时期标识以及区块链节点为处理传入的区块和/或接收到的业务事件所必须的信息；
根据时期标识以及预设要求，将状态数据存储到状态树Sn中，以便于区块链节点在处理各项业务时调用状态数据；
其中，预设要求包括：每个时期en内生成的状态数据只能存储到与时期en对应的状态树Sn中。
在一种可能的设计中，该方法还包括：在每个时期开始时，若区块链节点中存在前一个时期的第一历史状态树Sn-1，则保存并冻结第一历史状态树Sn-1。
在一种可能的设计中，当区块链节点为全节点时，在全节点中保存每个时期en对应的状态树Sn；
当区块链节点为轻节点时，在轻节点中至少保存：状态树Sn以及第一历史状态树Sn-1，并在当前的时期en开始时，删除不满足预设存储要求的第二历史状态树Sm。
在一种可能的设计中，预设存储要求包括：第二历史状态树Sm对应的历史时期em与当前的时期en的时间间隔小于预设间隔。
在一种可能的设计中，轻节点中能够保存预设数量个连续的时期en所对应的所有状态 树Sn，预设数量大于或等于2。
在一种可能的设计中，获取状态数据，包括：
获取出块节点发送的区块，并根据区块确定状态数据；
或者，获取用户发送的交易请求，并根据交易请求确定状态数据。
在一种可能的设计中，状态数据对应的地址包括：时期标识以及地址编码，根据时期标识以及预设要求，将状态数据存储到状态树Sn中，包括：
在当前时期enow对应的当前状态树Snow上，根据地址判断是否存在对应的存储路径；
当存在存储路径时，根据存储路径将状态数据存入当前状态树Snow中；
当不存在存储路径时，判断时期标识是否满足免证明要求；
若满足免证明要求，则在当前状态树Snow上，根据地址编码创建对应的存储路径；
根据存储路径将状态数据存入当前状态树Snow中。
在一种可能的设计中，根据时期标识判断是否满足免证明要求，包括：
判断在区块链网络的任意一个区块链节点中是否都储存有时期标识对应的状态树S0。
在一种可能的设计中，判断时期标识是否满足免证明要求，包括：
判断第一时期e0是否在当前时期enow之前的预设时间范围内，第一时期e0与时期标识相对应。
可选的，时间范围包括：k个周期，周期为每个时期en所持续的时间长度，k大于或等于1。
在一种可能的设计中，在判断时期标识是否满足免证明要求之后，还包括：
若不满足免证明要求，则根据地址，在各个历史时期对应的历史状态树上判断是否存在状态数据；
若不存在，则利用预设验证模型生成第一证明信息，且当区块链节点为出块节点时，将第一证明信息添加到状态数据对应的区块中，并将区块发送到区块链网络中进行共识，第一证明信息用于表征状态数据不在各个历史状态树上；
并在当前状态树Snow上，根据地址编码创建存储路径，根据存储路径将状态数据存入当前状态树Snow中。
在一种可能的设计中，根据地址，在各个历史时期对应的历史状态树上判断是否存在状态数据，包括：
在各个目标历史时期所对应的目标历史状态树上，根据地址编码判断是否存在状态数据，目标历史时期包括：从时期标识对应的第一时期e0开始的各个历史时期；
其中，目标历史状态树不包括已经存储在轻节点上的各个轻节点状态树，轻节点状态树至少包括：当前时期的状态树Sn以及当前时期之前一个时期的第一历史状态树Sn-1。
可选的，目标历史时期不包括：当前时期enow以及当前时期enow的前一个时期enow-1。
在一种可能的设计中，在各个目标历史时期所对应的目标历史状态树上，根据地址编码判断是否存在状态数据之后，还包括：
若存在，则利用预设验证模型生成第二证明信息，并且当区块链节点为出块节点时，将第二证明信息添加到状态数据对应的区块中，并将区块发送到区块链网络中进行共识，第二证明信息用于表征：状态数据在最后一次被修改时所对应的第二状态树S1上，并且在最后修改时期e1之后的各个历史状态树上都不存在状态数据，最后修改时期与第二状态 树S1相对应；
并在当前状态树Snow上，根据地址编码创建存储路径，根据存储路径将状态数据存入当前状态树Snow中。
在一种可能的设计中，在根据时期标识以及预设要求，将状态数据存储到状态树Sn中之后，还包括：
当状态数据在当前时期enow发生改变时，在当前时期对应的当前状态树Snow上更新状态数据；
区块链网络上的所有区块链节点将状态数据从各个历史状态树中删除，仅保留状态数据在各个状态树Sn中对应的存储路径的哈希值。
在一种可能的设计中，在每个时期en开始时，创建与时期en相对应的状态树Sn，包括：
将上一个时期en-1对应的第一历史状态树Sn-1中访问频率小于预设阈值的节点删除后，得到状态树Sn。
第二方面，本申请提供一种区块链状态数据处理装置，包括：
处理模块，用于在每个时期en开始时，创建与时期en相对应的状态树Sn；
获取模块，用于获取状态数据，状态数据包括：时期标识以及区块链节点为处理传入的区块和/或接收到的业务事件所必须的信息；
处理模块，还用于根据时期标识以及预设要求，将状态数据存储到状态树Sn中，以便于区块链节点在处理各项业务时调用状态数据；
其中，预设要求包括：每个时期en内生成的状态数据只能存储到与时期en对应的状态树Sn中。
第三个方面，本申请提供一种电子设备，包括：
存储器，用于存储程序指令；
处理器，用于调用并执行所述存储器中的程序指令，执行第一方面所提供的任意一种可能的物品存储信息确定方法。
第四方面，本申请提供一种存储介质，所述可读存储介质中存储有计算机程序，所述计算机程序用于执行第一方面所提供的任意一种可能的区块链状态数据处理方法。
第五方面，本申请还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现第一方面所提供的任意一种可能的区块链状态数据处理方法。
本申请提供了一种区块链状态数据处理方法，通过在每个时期en开始时，创建与时期en相对应的状态树Sn；获取状态数据，状态数据包括：时期标识以及区块链节点为处理传入的区块和/或接收到的业务事件所必须的信息；根据时期标识以及预设要求，将状态数据存储到状态树Sn中，以便于区块链节点在处理各项业务时调用状态数据；其中，预设要求包括：每个时期en内生成的状态数据只能存储到与时期en对应的状态树Sn中。解决了现有技术中存在的当区块链系统运行一段时间后状态数据的检索和访问的效率大幅下降的技术问题。达到避免状态数据爆炸增长而导致区块链节点对交易处理效率或处理能力下降的技术效果。
附图说明
图1为本申请提供的一种状态树的结构示意图；
图2为本申请实施例提供的一种区块链状态数据处理方法的应用场景示意图；
图3为本申请提供的一种区块链状态数据处理方法的流程示意图；
图4为本申请实施提供的另一种区块链状态数据处理方法的流程示意图；
图5为本申请实施例提供的一种区块链状态数据处理装置的结构示意图；
图6为本申请提供的一种电子设备的结构示意图。
通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，包括但不限于对多个实施例的组合，都属于本申请保护的范围。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
下面对本申请所涉及到的专业名词作出解释：
(1)区块链中的状态和状态树：
一般地，区块链网络中的节点，在网络中运行段时间之后，都会在本地存储装置上保存一些数据，这些数据可以根据其时间属性分为两大类：历史数据(简称为“历史”)和当前数据(简称为“状态”)。
状态：是指区块链系统的节点为了能够处理新传入的区块和/或事件而必须持有或存储的信息。状态与历史是相对的。
历史：是对过去已经发生的事件的描述信息，历史保存下来后，可以用于对已经发生的事件进行回顾，或者说是重播，并且还可以对历史进行归档管理。
应用于金融领域的区块链系统中，状态包括：
1.账户的余额和/或非余额信息，比如Nonce；
2.智能合约所对应的代码；
3.智能合约所对应的需要存储的数据；
4.各个节点间进行共识所需要的相关数据即共识数据，比如最近产生的若干区块的哈希值、数量、权益证明等共识数据。
随着时间的推移，随着新用户进入区块链网络，其创建新账户和新智能合约，调用智能合约中的函数，这些数据(即“状态”的具体承载形式)会不断增长。
在现有技术中，大部分区块链系统都是采用二叉(即有两个叶子节点)或六叉(即有 六个叶子节点)的帕夏尔-默克尔树(状态树的一种)来维护和管理状态数据，其一般是以键值对的形式，如(键，值)的形式进行存储。
帕夏尔-默克尔树：是一种字典树，有根节点、中间节点和叶子节点，每个节点都有一个唯一的“键”，根据状态数据的“键”，可以在状态树中找到这个“键”对应的存储位置，然后在这个存储位置的存储槽中存放的状态数据中的“值”。
例如，一个账户，比如0x001d3f1ef827，可以拥有无数个状态数据，要将这些状态数据放入到状态树中，可以将其哈希值即hash(0x001d3f1ef827)的结果作为“键”，用以找到状态树中的中间节点(即以“键”代表中间节点的地址或用来查找该中间节点的路径)，从而这个账户所有的状态数据都存储在这个中间节点的子树下。
沃克尔树：其本质上也是一种字典树，其存储和检索状态数据的方式和帕夏尔-默克尔树类似，但是沃克尔树更宽，即沃克尔树中一个节点的子节点数n 1比帕夏尔-默克尔树中一个节点的子节点数n 2要大很多(即n 1>>n 2)，因此对于一个固定长度的键地址，沃克尔树的深度(即树分层的总层数)比帕夏尔-默克尔树小很多。由于深度小，沃克尔树对节点的增加和修改操作更加简单。更重要的是，对于节点的存在性证明(即验证数据)，沃克尔树采用沃克尔证明，比帕夏尔-默克尔树的默克尔证明更加小。
沃克尔证明：是通过采用多项式承诺(向量承诺的一种)，证明一个节点是其父节点的众多子节点中的一个。由于沃克尔树中父节点的值由所有子节点的值决定，所以相当于只需要证明一个节点的值与其父节点的值，这两者间的关系，而无需像默克尔证明那样提供所有兄弟节点的值才能验证该节点与父节点的关系。因此沃克尔证明非常小，并且验证效率更高。
(2)全节点、轻节点和验证者节点：
不同区块链系统有不同的节点角色区分，大体上可以分为：全节点、轻节点和验证者节点。
全节点：是指保存了区块链所有数据的节点。其保存有完整的“状态”数据和所有“历史”数据(有些联盟链会丢弃历史区块中的状态数据比如FISCO BCOS)。
轻节点：是指仅保存部分常用的状态数据的节点。这就使得轻节点相对于权节点来说更能够节省内存空间，同时又可以处理大部分用户的交易以及打包区块。需要说明的是，在不同区块链系统中，轻节点的功能不一定相同。
验证者节点：是指在共识体系中仅参与验证区块的正确性，但没有打包区块能力的节点。同样在不同区块链系统中验证者节点为了能够验证区块的正确性，需要存储的状态大小也不同。
还需要说明的是，全节点中包括：各种区块的本体部分(即body，一个区块可以分为头部Header和本体Body两部分)，交易列表等等相关信息。全节点在本地保存了一个完整的区块链网络，在其上可进行任何查询、交易的验证与广播，正因为有全节点的存在，使得区块链的去中心化成为了可能，同时使得区块链网络更加安全。需要说明的是，一般全节点需要一直保持在线状态。
轻节点与全节点不同的是，不需要保存所有的交易内容，只需要通过状态树的形式，来保存各个区块的头部Header以及与节点自身相关的交易细节信息，并通过状态树所对应的验证方法(也称为“证明”)来判断交易是否在当前的区块链交易列表中。与全节点不 同，轻节点不需要一直保持在线状态。
时期epoch：表示一个固定数量(比如10000个区块)的区块所经历的时间，在这个时期e内创建或修改的“状态”(即状态数据)到了下一个时期e+1自动变成过期的“状态”。
本申请发明人发现，现有的区块链系统中，一般每个区块链节点都会用树状存储结构即状态树的形式，来保存区块链节点运行所必须的信息即状态数据，但是随着区块链系统不断运行，状态数据越来越多，状态树也越来越大，这就使得数据的检索和访问效率大大下降。
为解决上述问题，一种思路是：对于“状态”的管理使用的“两树方案”：过期的状态组成一棵过期状态树，非过期的当前状态组成一棵活跃状态树。
在活跃状态树中，每个账户(包括智能合约)对应的叶子节点上的状态存储槽在被创建后即开始计时，如果状态存储槽中的状态数据在预设时间内被修改则重新计时，相反的，如果经过一段预设时间后，该账户的状态数据没有被修改，则将此状态数据放置到过期状态树上。
全节点需要存储这两棵树，其他节点如轻节点，只存储活跃状态树。用户如果想要访问某个账户过期的状态或者将某个账户过期的状态复活，必须提供该账户对应的状态在过期状态树上的证明(即验证数据)。
但是本申请发明人发现上述做法仍然会引发下面的技术问题：
1.如果打包出块的节点不是全节点，一个账户过期后将被移出活跃状态树，当其他用户创建了相同地址的账户(相当于创建了相同的账户名)，则会妨碍原有账户对应的状态的恢复。或者若原有账户的拥有者无法提供证明(即验证数据)，则会导致整个账户的信息被重构，甚至会导致和历史数据相冲突。
2.目前的区块链大部分都是使用六叉帕夏尔-默克尔树作为状态树，状态证明最大达到4MB，导致一个区块容纳不下几个包含状态证明的交易，即访问过期状态的交易，或者导致区块过大，从而影响共识的速度。
3.现有技术无法从根本上解决状态的爆炸增长问题，很多公链的做法无法直接用在联盟链中，尤其是没有代币机制的联盟链，现有的状态树结构难以结合高级密码学来提高状态数据管理和证明的效率。
为解决上述各个技术问题，本申请采用了另一种发明构思：
改变状态数据管理的根本逻辑，不再只是区分过期状态树和活跃状态树，而是在每个预设时间单元即时期，对应在每个节点建立新的状态树，这棵状态树只保存在当前的时期内发生的状态数据，或者是修改当前的时期内变化的状态数据，对于上一个时期或者未来的时期的状态数据都不会保存在当前的状态树当中。即每个时期都有一个对应的状态树，未来时期的状态树在当前不能操作，而过去时期的状态树要访问需要提供节点存在性证明。
并且，为了使得状态数据能够正确存储到正确时期的状态树上，那么就需要在原始地址上增加一个时期前缀，这样用户无法重新创建完全相同的地址，如果想要创建一个历史时期的地址，必须提供证明，以供节点验证这个地址从未出现过。用户也无法创建未来时期的地址，从而保证地址不会冲突，并且能够拓宽地址空间的可用性。
进一步的，还可以更改状态树的组织结构，即采用沃克尔树，从根本上替换现有的帕 夏尔-默克尔树，但是不会改变原有的存储和检索逻辑，可以结合累加器来做出证明，证明的大小仅有约800KB，更加适合区块链中状态数据的维护和管理。这个特性使得区块链系统，允许完全无需存储任何状态数据的验证者节点存在，这就使得移动设备就可以完成验证，即移动设备即可成为验证者节点，使得区块链系统更加去中心化。
具体的，本申请发明人重新设置了对区块链中状态数据的处理逻辑：
(1)新的地址结构和状态树结构：
图1为本申请提供的一种状态树的结构示意图。如图1所示，每个时期都有独立的一颗状态树，所以状态包含了一列永远增长的树S 0，S 1，S 2，S 3…,每个S i表示第i个时期的状态树。因此状态是否过期无需额外的字段来表示，只有当前时期的状态树上的状态才是非过期状态。最后每棵状态树的树根10再形成一个总状态根100，这个总状态根100记录在每个区块的头部里，任何一棵状态树发生变化，总状态根100也会变化。可选的，状态树的类型包括沃克尔树。
需要说明的是，在区块链系统中必须存在至少一个存储所有的历史树的全节点，全节点的数量可以由区块链参与方决定。其他的节点根据实际情况来决定存储某些历史状态树，但是需要注意，虽然不存储所有的状态树，但是所有的状态树的树根节点都要存储，并且在每个区块链节点上至少存储上一个时期的状态树以及当前时期的状态树。
对于一个区块链节点中用于交易业务的账户来说，该账户包括：合约账户(contract accounts)和外部账户(Externally Owned Account，EOA)。例如，在以太坊中，合约账户是通过智能合约进行交易的账户，由智能合约的代码控制。只有合约账户才有代码，其中存储的是codeHash(这个账户的以太坊虚拟机代码的哈希值)，这个字段在生成后是不可修改的，这意味着智能合约代码是不可修改的。而外部账户是由以太坊网络的人类用户创建的帐户。它与公钥、私钥对相关，它是通过对公钥进行二次哈希后结果的最后20个字节导出的。
本申请定义了新的账户地址，该地址可以表示为一个元组(e，s)，e为该地址所属时期的时期标识，用4个bytes表示，s为原始地址，即当前区块链普遍所用的20个bytes的地址编码。所以新的账户地址在二进制上表示为[e:s]，即将时期标识与地址编码进行字节拼接。
(2)状态树访问和修改规则：
在当前的时期epoch e：
1.只有当前的状态树S e可以被修改。
2.历史时期的状态树会被冻结，所有想要访问历史状态树的交易必须携带证明，以证明所要访问的状态在历史某个时期的状态树的位置，例如：该状态位置的沃克尔证明，沃克尔证明中包含了旧的状态数据值，这样才能访问历史状态树。由于所有的区块链节点都存储了上一个时期的状态树S e-1，如果用户需要访问状态树S e-1中的状态数据，区块链节点会帮助用户提供对于该状态树的证明，而且大部分热数据都在这个状态树中，因此可以满足绝大部分用户。但是如果用户的交易想访问S e-1之前的树，必须寻找全节点来提供访问证明。
3.未来时期的状态树可以事先建立好，但只有未来时期变成当前时期后才能修改，或者也可以说未来时期的状态树还没有被创建。到达新的时期后，节点立即启用或创建新的状态树，该未来时期对应的状态树可以是个空白的状态树，也可以附带上了存储某些经常被访问的状态数据的树节点。
(3)账户访问和修改规则：
账户(e，s)可以在任意f>e的时期被访问，其数据永远存储在状态树的固定位置hash(e,s)，如果在当前时期epoch f，账户(e，s)的存储被修改，由于历史状态树不能修改，所以会在当前时期的状态树Sf的hash(e,s)位置创建对应的存储槽。
具体修改规则：
1.如果账户(e，s)在epoch e被创建和修改，那么直接在树S e的对应位置创建和修改；
2.如果账户(e，s)在epoch e+1被创建或修改，那么直接在树S e+1的对应位置创建和修改；
3.如果账户(e，s)在epoch f(f>e+1)被创建，而且在树S f和S f-1上对应位置还没有创建，那么需要提供证明：账户(e，s)在这些树S e，S e+1，...，S f-2的对应位置都没有出现；
4.如果账户(e，s)在epoch f(f>e+1)被修改，而且在树Sf和Sf-1上对应位置还没有创建，假设账户(e，s)最后一次被修改是在epoch e′(e≤e′<f)，那么需要提供证明：账户(e，s)出现在状态树S e′的对应位置，而且在这些树S e′+1,S e′+2...S f-2的对应位置都没有出现；
5.如果账户(e，s)在epoch f(f>e)被修改，而且在树S f上对应位置已经创建，直接修改。
(4)历史状态树修剪：
由于本申请将区块链不同时期的状态树分别存储，如果不做“状态”去重，将会给区块链节点带来很大的存储开销，尤其是全节点。
本申请采用历史状态树修剪的方式：如果某个账户的“状态”(即本文中的状态数据)在当前时期发生改变，那么当前时期的状态树会保存该账户的最新“状态”，因此所有节点可以将该账户的旧状态从各个历史状态树中删除，仅保留状态树中对应位置的节点哈希值。
(5)证明的生成方式：
当用户需要证明某个账户存在于某个历史状态树中或者不存在与某个历史状态树中，本发明采用密码学累加器来分别做出成员证明和非成员证明。
如图1所示，每个时期对应的状态树100的深度为4，广度为4个字节，即每层的子节点数量最多为256个，用16进制表示即为00～ff。假设某个账户在状态树中对应的键为0x3a4b5c，在状态树中，该账户对应的键分别在每一层的节点序号为3a、4b和5c，这些序号也构成了一个对应账户信息存储在状态树中的唯一路径。因此，当用户需要做出该账户存在于这棵状态树的证明，系统需要为该账号对应的键的路径做出证明，即为路径中每 层的节点序号分别做出成员证明。
以上述的键为例，需要分别证明：3a节点在根节点的已经存在的子节点集合中；4b节点在3a的已经存在的子节点集合中；5c在4b的已经存在的子节点集合中。已经存在的子节点集合表达了所有以这些子节点为中间路径的已经存储状态数据的键，区块链节点或区块链系统维护状态树的每一层的已经存在的子节点集合，因此对于任意一棵状态树，第二层有1个已经存在的子节点集合，第三层最多有256个已经存在的子节点集合。
具体以证明3a节点在根节点的已经存在的子节点集合中为例，使用密码学累加器做出3a的成员证明。用M表示已经存在的子节点集合累加器向量，M中记录着节点序号唯一对应的质数，用x 3a表示3a节点对应的质数，A表示累加器的值，即M中所有质数的乘积。x 3a的成员证明
Figure PCTCN2022102159-appb-000001
的计算简化逻辑可以用公式(1)来表示：
Figure PCTCN2022102159-appb-000002
对应的验证逻辑可以用公式(2)来表示：
Figure PCTCN2022102159-appb-000003
其中，g表示系统所使用的域的生成元。
如果要证明另外一个节点假设为3b不在这个子节点集合中，用y表示3b节点对应的质数，y的非成员证明u y的计算简化逻辑可以用公式(3)来表示：
Figure PCTCN2022102159-appb-000004
对应的验证逻辑可以用公式(4)来表示：
Figure PCTCN2022102159-appb-000005
其中，Bezout为贝祖定理，a和b是根据贝祖定理得到的两个系数。
依次分别得到4b节点的成员证明
Figure PCTCN2022102159-appb-000006
和5c节点的成员证明
Figure PCTCN2022102159-appb-000007
合在一起既是该账户存在于这棵状态树的证明。如果一个交易涉及的两个账户都需要提供证明，可以在每一层一起做出成员证明，假设第二个账户在第一层经过3c节点，对应的质数为z，则只需做出x*z的成员证明，无需分别做出成员证明。
下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。
图2为本申请实施例提供的一种区块链状态数据处理方法的应用场景示意图。如图2所示，用户20向区块链网络或者说是区块链系统中的任意一个区块链节点21发送交易请求，区块链节点21执行该交易请求对应的交易，使得该用户对应的用于交易的账户的各项状态数据发生了变化，接收用户20交易请求的区块链节点21也称为出块节点，其将该交易打包成区块发送到区块链网络中让其它区块链节点21进行共识。在出块节点中，在交易执行后，所产生的状态数据就对应存储在节点中当前时期对应的状态树上，而其它接收到区块的区块链节点21，也采用相同的状态数据处理方法在各自区块链节点21本地的状态树上更新状态数据。
下面具体介绍本申请提供的状态数据处理方法：
图3为本申请实施例提供的一种区块链状态数据处理方法的流程示意图。如图3所示，该区块链状态数据处理方法的具体步骤，包括：
S301、在每个时期e n开始时，创建与时期e n相对应的状态树S n。
在本步骤中，在每个时期e n开始时，区块链节点按照预设的状态树模板创建一棵新的状态树S n，同时，历史状态树即当前时期之前的时期的历史状态树会被冻结，历史状态树可以访问查询，但是不可以将新的状态数据再存入历史状态树。
可选的，在本实施例中，状态树的类型为沃克尔树。
在一种可能的设计中，在每个时期开始时，若区块链节点中存在前一个时期的第一历史状态树S n-1，则保存并冻结第一历史状态树S n-1。
即在每个时期e n开始时，对于刚结束的前一个时期e n-1所对应的状态树S n-1，并不直接删除，而是只将其冻结起来，但是仍然存储在区块链节点中。
在另一种可能的设计中，整个区块链网络中的区块链节点可以分为两类：全节点和轻节点。
当区块链节点为全节点时，在全节点中保存每个时期e n对应的状态树S n；
当区块链节点为轻节点时，在轻节点中至少保存：状态树S n以及第一历史状态树S n-1，并在当前的时期e n开始时，删除不满足预设存储要求的第二历史状态树S m。
在一种可能的设计中，预设存储要求包括：第二历史状态树S m对应的历史时期e m与当前的时期e n的时间间隔小于预设间隔。
比如，当预设间隔为2时，轻节点只存储当前时期以及前一时期，这两个时期的状态树，而轻节点如果要访问其它时期的历史状态树，就需要向全节点提出访问请求，由全节点在对应的历史状态树上进行访问查询。
当然，轻节点也可以保存更多的历史时期的状态树，比如，预设间隔的取值为3-6时，轻节点就可以存储连续3-5个时期的状态树。
需要注意的是，轻节点也可以是非连续时期的历史状态树，比如：保存当前时期，前1个历史时期，前3个历史时期，这三个时期的状态树。
保存的原则可以设置为：如果该历史时期状态数据的创建和/或修改量大于预设阈值，或者说该历史时期的交易量大于预设阈值，则证明该历史时期的状态数据有较大概率会被用到，则将该历史时期对应的状态树保留在区块链节点中，直至对应的状态数据的访问热度低于预设热度阈值后，才将该历史状态树删除。
当然，本领域技术人员也可以根据实际情况设置轻节点保存状态树的数量和保存规则，但是至少要保证轻节点至少包括：当前状态树S n和前一个时期的状态树S n-1。即轻节点中能够保存预设数量个连续的时期e n所对应的所有状态树S n，预设数量大于或等于2。
在一种可能的设计中，在本步骤中，将上一个时期e n-1对应的第一历史状态树S n-1中访问频率小于预设阈值的节点删除后，得到当前时期e n的状态树S n。
S302、获取状态数据。
在本步骤中，状态数据包括：时期标识以及所述区块链节点为处理传入的区块和/或接收到的业务事件所必须的信息。
本步骤可以分为两种情况：
第一种，当区块链节点为接收用户交易请求的节点时，由于区块链的共识机制，其需要将交易打包成区块，发布到区块链网络中进行共识，因此，此时该区块链节点也称为出块节点。
此时，获取状态数据，包括：获取用户发送的交易请求，并根据交易请求确定状态数据。
第二种，当区块链节点不是接收用户交易请求的节点，而是区块链网络中执行共识的节点时，获取状态数据，包括：获取出块节点发送的区块，并根据区块确定状态数据。
在本实施例中，状态数据对应的地址包括：时期标识以及地址编码。
S303、根据时期标识以及预设要求，将状态数据存储到状态树S n中，以便于区块链节点在处理各项业务时调用状态数据。
在本步骤中，预设要求包括：每个时期e n内生成的状态数据只能存储到与时期e n对应的状态树S n中。
具体可以分为五种情况：
1.如果账户(e，s)在时期e被创建和修改，那么直接在树S e的对应位置创建和修改；
2.如果账户(e，s)在时期e+1被创建或修改，那么直接在树S e+1的对应位置创建和修改；
3.如果账户(e，s)在时期f(f>e+1)被创建，而且在树S f和S f-1上对应位置还没有创建，那么需要提供证明：账户(e，s)在这些树S e，S e+1，...，S f-2的对应位置都没有出现；
4.如果账户(e，s)在时期f(f>e+1)被修改，而且在树Sf和Sf-1上对应位置还没有创建，假设账户(e，s)最后一次被修改是在时期e′(e≤e′<f)，那么需要提供证明：账户(e，s)出现在状态树S e′的对应位置，而且在这些树S e′+1,S e′+2...S f-2的对应位置都没有出现；
5.如果账户(e，s)在时期f(f>e)被修改，而且在树S f上对应位置已经创建，直接修改。
在一种可能的设计中，该区块链状态数据处理方法，还包括：
当所述状态数据在当前时期e now发生改变时，在所述当前时期对应的当前状态树S now上更新所述状态数据；
区块链网络上的所有所述区块链节点将所述状态数据从各个历史状态树中删除，仅保留所述状态数据在各个所述状态树S n中对应的存储路径的哈希值。
由于本申请将区块链不同时期的状态树分别存储，如果不做“状态”去重，将会给区块链节点带来很大的存储开销，尤其是全节点。
本申请采用历史状态树修剪的方式：如果某个账户的“状态”(即本文中的状态数据)在当前时期发生改变，那么当前时期的状态树会保存该账户的最新“状态”，因此所有节点可以将该账户的旧状态从各个历史状态树中删除，仅保留状态树中对应位置的节点哈希值。
本申请实施例提供了一种区块链状态数据处理方法，通过在每个时期e n开始时，创建与时期e n相对应的状态树S n；获取状态数据，状态数据包括：时期标识以及区块链节点为处理传入的区块和/或接收到的业务事件所必须的信息；根据时期标识以及预设要求，将状态数据存储到状态树S n中，以便于区块链节点在处理各项业务时调用状态数据；其中，预设要求包括：每个时期e n内生成的状态数据只能存储到与时期e n对应的状态树S n中。解决了现有技术中存在的当区块链系统运行一段时间后状态数据的检索和访问的效率大幅 下降的技术问题。达到避免状态数据爆炸增长而导致区块链节点对交易处理效率或处理能力下降的技术效果。
图4为本申请实施提供的另一种区块链状态数据处理方法的流程示意图。如图4所示，该区块链状态数据处理方法的具体步骤包括：
S401、在每个时期e n开始时，创建与时期e n相对应的状态树S n。
S402、获取状态数据。
步骤S401～S402的具体名词及原理解释可以参考S301～S302，在此不再赘述。
S403、在当前时期e now对应的当前状态树S now上，根据地址判断是否存在对应的存储路径。
在本步骤中，存储路径包括：状态树S n上的各个节点以及存储槽，节点包括中间节点以及叶子节点，存储槽设置在叶子节点上。
当存在存储路径时，执行步骤S404，当不存在存储路径时，执行步骤S405。
具体的，如果，如果还没有创建
S404、根据存储路径将状态数据存入当前状态树S now中。
在本步骤中，在当前状态树S now上已经创建了存储槽(如图1所示)，则只需要在存储槽中更新状态数据。
S405、判断时期标识是否满足免证明要求。
在本步骤中，若满足，则执行步骤S406，若不满足，则执行步骤S407。
在当前状态树S now上还没有创建与状态数据对应的存储槽，那么就需要去创建各个中间节点和叶子节点，同时在叶子节点上创建存储槽，再将状态数据存储到存储槽当中。
但是，实际情况比较复杂，由于本申请对每个时期都建立了状态树，那么状态数据比如交易的账户，可能在之前的状态树中以及存储过了，因此需要去判断是否在历史状态树当中。
在一种可能的设计中，根据时期标识判断是否满足免证明要求，包括：
判断在区块链网络的任意一个区块链节点中是否都储存有时期标识对应的状态树S0。
在本实施例中，根据时期标识判断是否满足免证明要求，包括：
判断在区块链网络的任意一个区块链节点中是否都储存有时期标识对应的状态树S 0。
在本实施例中，区块链网络中至少包括两种区块链节点，即全节点和轻节点，全节点中保存了所有时期对应的状态树，但是轻节点中只保留了部分状态树，但是，轻节点中至少保存了当前状态树和前一时期的历史状态树。
因此，免证明要求的实质是：如果状态数据的地址中的时期标识所对应的时期，能够在轻节点所保存的所有状态树所对应的各个时期中查找到，那么就可以直接在当前的状态树上根据地址创建存储路径，即各个中间节点、叶子节点和存储槽，然后将状态数据存入存储槽当中。
比如，轻节点中存储了：当前时期e now，前一时期e now-1，前三时期e now-3以及前五时期e now-5这四个时期对应的状态树，那么如果状态树的时期标识与这四个时期中的任意一个相对应，那么就不需要区块链节点根据证明算法来计算证明，如沃克尔证明。(证明方法详见上文记载的“证明的生成方式”)
在一种可能的设计中，判断时期标识是否满足免证明要求，包括：
判断第一时期e 0是否在当前时期e now之前的预设时间范围内，第一时期e 0与时期标识相对应。
可选的，时间范围包括：k个周期，周期为每个时期e n所持续的时间长度，k大于或等于1。
例如，当轻节点中存储了当前时期e now以及前一时期e now-1对应的状态树时，预设时间范围就是1个周期，即前二时期e now-2就不做预设时间范围内。
即对应S303中描述的：
1.如果账户(e，s)在时期e被创建和修改，那么直接在树S e的对应位置创建和修改；
2.如果账户(e，s)在时期e+1被创建或修改，那么直接在树S e+1的对应位置创建和修改。
5.如果账户(e，s)在时期f(f>e)被修改，而且在树S f上对应位置已经创建，直接修改。
S406、在当前状态树S now上，根据地址编码创建对应的存储路径。
在本步骤中，若满足免证明要求，直接在当前的状态树上根据地址创建存储路径，即各个中间节点、叶子节点和存储槽，然后执行步骤S404，将状态数据存入存储槽当中。
S407、根据地址，在各个历史时期对应的历史状态树上判断是否存在状态数据。
在本步骤中，若不存在，则执行步骤S408，若存在，则执行步骤S409。
具体的，当不满足免证明要求时，需要进一步扩大历史状态树的范围。此时需要注意的是，轻节点当中并没有存储所有时期的状态树，因此，对于轻节点来说，本步骤的实施时，只能是向全节点发送证明请求，由全节点在其所存储的历史状态树中去查找是否存储对应的状态数据。
在本实施例中，本步骤具体包括：
在各个目标历史时期所对应的目标历史状态树上，根据地址编码判断是否存在状态数据，目标历史时期包括：从时期标识对应的第一时期e 0开始的各个历史时期；
其中，目标历史状态树不包括已经存储在轻节点上的各个轻节点状态树，轻节点状态树至少包括：当前时期的状态树S n以及当前时期之前一个时期的第一历史状态树S n-1。
可选的，目标历史时期不包括：当前时期e now以及当前时期e now的前一个时期e now-1。
S408、利用预设验证模型生成第一证明信息。
在本步骤中，当区块链节点为出块节点时，需要将第一证明信息添加到状态数据对应的区块中，并将区块发送到区块链网络中进行共识，第一证明信息用于表征状态数据不在各个历史状态树上。然后，执行步骤S406。
即对应S303中描述的：
3.如果账户(e，s)在时期f(f>e+1)被创建，而且在树S f和S f-1上对应位置还没有创建，那么需要提供证明：账户(e，s)在这些树S e，S e+1，...，S f-2的对应位置都没有出现。
需要说明的是，只有生成了第一证明信息，才能够在当前状态树上创建存储路径，否则，是无法在当前状态树中存储状态信息。即在具体实现时，会设置对第一证明信息的检验，如果没有第一证明信息，就无法进行下一步的存储操作。
还需要说明的是，本步骤的第一证明信息的生成方式，包括沃克尔证明，或者是上文 记载的“证明的生成方式”。
S409、利用预设验证模型生成第二证明信息。
在本步骤中，当区块链节点为出块节点时，将第二证明信息添加到状态数据对应的区块中，并将区块发送到区块链网络中进行共识，第二证明信息用于表征：状态数据在最后一次被修改时所对应的第二状态树S 1上，并且在最后修改时期e 1之后的各个历史状态树上都不存在状态数据，最后修改时期与第二状态树S 1相对应。然后，执行步骤S406。
即对应S303中描述的：
4.如果账户(e，s)在时期f(f>e+1)被修改，而且在树Sf和Sf-1上对应位置还没有创建，假设账户(e，s)最后一次被修改是在时期e′(e≤e′<f)，那么需要提供证明：账户(e，s)出现在状态树S e′的对应位置，而且在这些树S e′+1,S e′+2...S f-2的对应位置都没有出现。
同理，需要说明的是，只有生成了第二证明信息，才能够在当前状态树上创建存储路径，否则，是无法在当前状态树中存储状态信息。即在具体实现时，会设置对第二证明信息的检验，如果没有第二证明信息，就无法进行下一步的存储操作。
本步骤的第二证明信息的生成方式，包括沃克尔证明，或者是上文记载的“证明的生成方式”。
S410、当状态数据在当前时期e now发生改变时，在当前时期对应的当前状态树S now上更新状态数据。
在本步骤中，如果状态数据对应的账户，在同一时期内发生多次交易业务，那么直接在当前状态树的存储槽中更新状态数据。
即对应S303中描述的：
1.如果账户(e，s)在时期e被创建和修改，那么直接在树S e的对应位置创建和修改；
2.如果账户(e，s)在时期e+1被创建或修改，那么直接在树S e+1的对应位置创建和修改。
5.如果账户(e，s)在时期f(f>e)被修改，而且在树S f上对应位置已经创建，直接修改。
S411、将状态数据从各个历史状态树中删除，仅保留状态数据在各个状态树S n中对应的存储路径的哈希值。
由于本申请将区块链不同时期的状态树分别存储，如果不做“状态”去重，将会给区块链节点带来很大的存储开销，尤其是全节点。
本申请采用历史状态树修剪的方式：如果某个账户的“状态”(即本文中的状态数据)在当前时期发生改变，那么当前时期的状态树会保存该账户的最新“状态”，因此所有节点可以将该账户的旧状态从各个历史状态树中删除，仅保留状态树中对应位置的节点哈希值。
本申请实施例提供了一种区块链状态数据处理方法，通过在每个时期e n开始时，创建与时期e n相对应的状态树S n；获取状态数据，状态数据包括：时期标识以及区块链节点为处理传入的区块和/或接收到的业务事件所必须的信息；根据时期标识以及预设要求，将状态数据存储到状态树S n中，以便于区块链节点在处理各项业务时调用状态数据；其中，预设要求包括：每个时期e n内生成的状态数据只能存储到与时期e n对应的状态树S n中。解 决了现有技术中存在的当区块链系统运行一段时间后状态数据的检索和访问的效率大幅下降的技术问题。达到避免状态数据爆炸增长而导致区块链节点对交易处理效率或处理能力下降的技术效果。
为了便于理解上述两个实施例所提供的方法，下面从时间推进角度进行示例，涉及到三个时期：时期0、时期1和时期2，需要说明的是，时期0和时期1是相邻的两个时期，但是时期1和时期2并不一定相邻。
在区块链系统初始化完成后，所有区块链系统中的节点分别创建与当前时期T 0对应的的第一状态树S 0。
一、当时间运行到时期0时，即当前时期为时期0的时候：
时期0开始时，所有节点分别创建第一状态树S 0，S 0即为当前时期的当前状态树。
区块链网络中的任意一个用户端节点接收用户发起的交易，并为该交易创建对应的智能合约。
然后出块节点接收并执行该交易，出块节点为智能合约生成一个合约地址，该合约地址包括：时期前缀以及地址编码，该时期前缀与当前时期相对应。
然后，出块节点根据预先设定的对账户的访问和修改的第一规则要求(即：1.如果账户(e，s)在时期e被创建和修改，那么直接在树S e的对应位置创建和修改)以及合约地址，确定智能合约在第一状态树S 0上的存储地址，即在第一状态树S 0上的若干中间节点上创建子节点和与该子节点对应的存储槽。需要说明的是，这些中间节点都包含在了存储地址的地址编码中，因为这些中间节点在状态树中都对应着至少一个子节点，所以也称这些中间节点为父节点。而且，可以将一个父节点所对应的子节点都放在一个子节点集合中，以便于对状态树进行检索和访问。
接下来，出块节点将智能合约的数据保存在存储槽中。
然后，出块节点更新各个子节点集合对应的累加器向量以及累加器值，该子节点集合对应的父节点包含在存储地址中，存储地址中包括至少一个父节点，该父节点为状态树上的中间节点。
然后，出块节点将交易打包区块，并向区块链网络发布该区块。
区块链网络上的其它节点收到该区块后，执行该交易，同样需要根据第一预设要求在节点自身的第一状态树S0上对应的位置创建子节点和存储槽，把智能合约的数据保存在对应的存储槽内，同时更新各个子节点集合对应的累加器向量以及累加器值。
在时期0内的任意时刻，任意用户通过用户端节点发起的交易与上述智能合约进行交互，那么这个交易对应的出块节点直接在第一状态树S 0上对应的存储槽修改数据，同时该交易的区块由出块节点发布到区块链网络进行共识后，其它所有的节点也会执行与区块节点同样的操作，即在各个节点的第一状态树S 0上对应的存储槽修改数据。
例如：在时期0开始时，即区块链系统完成初始化后，所有节点分别创建第一状态树S0；
(1)张三发送交易创建一个智能合约C1，李四发送交易创建一个智能合约C2。
(2)出块节点收到交易后执行交易，分别为智能合约C1生成一个地址(0,0xabcdef)和智能合约C2生成一个地址(0,0x123456)，根据账户访问和修改规则1(即：1.如果账户(e，s)在时期e被创建和修改，那么直接在树S e的对应位置创建和修改)，出块节点在 第一状态树S0的0x3a4b5c和0x6d7e8f对应的位置创建子节点和存储槽，把智能合约的数据保存在了对应的存储槽，更新第一状态树S0中3a，4b，5c，6d，7e，8f所在的子节点集合累加器向量和累加器值。
需要说明的是，这里生成地址的算法可以采用哈希算法，即hash(0,0xabcdef)＝0x3a4b5c，hash(0,0x123456)＝0x6d7e8f。
(3)出块节点将该交易打包区块，其他节点收到区块后执行交易，在各自的状态树S0的0x3a4b5c和0x6d7e8f位置创建子节点和存储槽，把该智能合约的数据保存在了对应的存储槽，更新状态树S0中3a，4b，5c，6d，7e，8f所在的子节点集合累加器向量和累加器值。
(4)在这个时期内，任意用户发送交易与智能合约C1或C2交互，直接在第一状态树S0的0x3a4b5c或0x6d7e8f位置对应的存储槽修改数据。其他同步区块的交易后执行同样的操作。
二、当时间运行到了时期1时，即时期1为当前时期时：
进入新的时期，所有节点都创建一棵新的空白状态树S1，保存状态树S0。
(1)任意用户发送交易与地址为(0,0xabcdef)的智能合约C1交互；
(2)出块节点收到交易后执行交易(无论出块节点是全节点还是轻节点)，发现在状态树S1中没有键为0x3a4b5c的状态数据，然后在状态树S0中查找，找到了键0x3a4b5c的状态数据；
(3)出块节点为这个交易构建证明
Figure PCTCN2022102159-appb-000008
证明键0x3a4b5c存在于状态树S0中，把该证明和交易绑定一起打包到区块中。
(4)出块节点根据账户访问和修改规则2(即：2.如果账户(e，s)在时期e+1被创建或修改，那么直接在树S e+1的对应位置创建和修改)，在状态树S1的0x3a4b5c位置创建子节点和存储槽，将交易执行后的状态数据存储到该位置，更新状态树S1中3a，4b，5c所在的子节点集合累加器向量和累加器值；
(5)其他节点收到区块后执行交易，验证证明
Figure PCTCN2022102159-appb-000009
如果不正确则拒绝整个区块；如果正确，同样根据账户访问和修改规则2(即：2.如果账户(e，s)在时期e+1被创建或修改，那么直接在树S e+1的对应位置创建和修改)，在各自的状态树S1的0x3a4b5c位置创建子节点和存储槽，把新的状态数据保存在了对应的存储槽，更新状态树S1中3a，4b，5c所在的子节点集合累加器向量和累加器值；
(6)此后，在这个时期内，任意用户发送交易与智能合约C1交互，出块节点根据账户访问和修改规则2，直接在状态树S1的0x3a4b5c位置和对应的存储槽修改数据。其他同步区块的交易后执行同样的操作。
三、当时间运行到了时期2时，即时期2为当前时期时：
进入新的时期，所有节点都创建一棵新的空白状态树S2，保存状态树S1。全节点继续保存状态树S0，轻节点丢弃状态树S0。
1.任意用户发送交易与地址为(0,0xabcdef)的智能合约C1交互，所有节点的处理方式与时期1一样；
2.任意用户发送交易与地址为(0,0x123456)的智能合约C2交互：
1)出块节点如果是全节点，发现在状态树S2中没有键为0x6d7e8f的状态数据，然后在历史状态树中查找，在S0找到了键0x6d7e8f的状态数据。全节点为该交易生成证明
Figure PCTCN2022102159-appb-000010
即证明键0x6d7e8f存在于状态树S0中且不存在于状态树S1中，把该证明和交易绑定一起打包到区块中。根据账户访问和修改规则4，在状态树S2的0x6d7e8f位置创建子节点和存储槽，将交易执行后的状态数据存储到该位置，更新状态树S2中6d，7e，8f所在的子节点集合累加器向量和累加器值，其他节点的操作与时期1中的第五步类似；
2)出块节点如果是轻节点，发现在状态树S2和S1都中没有键为0x6d7e8f的状态数据，则向全节点请求该状态数据的证明，全节点的处理和上一步一样。出块节点得到证明后，验证并执行交易，后续操作与上一步的全节点一样。
此后，在这个时期内，任意用户发送交易与智能合约C2交互，出块节点根据账户访问和修改规则5，直接在状态树S1的0x3a4b5c位置和对应的存储槽修改数据。其他同步区块的交易后执行同样的操作。
3.王五使用一个(0,0x456789)地址发送交易：
1)出块节点如果是全节点，发现在状态树S2中没有键为0xa1b2c3(假设hash(0,0x456789)＝0xa1b2c3)的状态数据，然后在历史状态树中查找都没有找到键0xa1b2c3的状态数据。全节点为该交易生成证明
Figure PCTCN2022102159-appb-000011
Figure PCTCN2022102159-appb-000012
即证明键0xa1b2c3不存在于状态树S0和S1中，把该证明和交易绑定一起打包到区块中。根据账户访问和修改规则3，在状态树S2的0xa1b2c3位置创建子节点和存储槽，将交易执行后的状态数据存储到该位置，更新状态树S2中a1，b2，c3所在的子节点集合累加器向量和累加器值，其他节点的操作与时期1中的第五步类似；
2)出块节点如果是轻节点，发现在状态树S2和S1都中没有键为0xa1b2c3的状态数据，则向全节点请求该状态数据的证明，全节点的处理和上一步一样。出块节点得到证明后，验证并执行交易，后续操作与上一步的全节点一样。
此后，在这个时期内，王五使用该地址发送交易，出块节点根据账户访问和修改规则5，直接在状态树S2的0xa1b2c3位置和对应的存储槽修改数据。其他同步区块的交易后执行同样的操作。
本申请提供的区块链状态数据处理方法，能够很好地永久性解决区块链状态的爆炸增长带给所有节点的存储压力，而且不会给普通用户带来任何体验上的区别，原有的智能合约编程方式没有改变，仅仅底层的虚拟机在修改账户状态的时候做出对应的改变。能够引入完全不需要存储区块链状态的验证者角色，使得更多人参与区块和交易的验证，增加区块链系统的安全性。轻节点的存在，使得处理交易和出块的效率更高，因为无需将计算资源浪费在修改庞大的状态树，全节点也可以采用一些策略将很久没有访问的过期状态存储在硬盘中，需要的时候再调出来。
图5为本申请实施例提供的一种区块链状态数据处理装置的结构示意图。该区块链状态数据处理装置500可以通过软件、硬件或者两者的结合实现。
如图5所示，该区块链状态数据处理装置500包括：
处理模块502，用于在每个时期e n开始时，创建与时期e n相对应的状态树S n；
获取模块501，用于获取状态数据，状态数据包括：时期标识以及区块链节点为处理传入的区块和/或接收到的业务事件所必须的信息；
处理模块502，还用于根据时期标识以及预设要求，将状态数据存储到状态树S n中，以便于区块链节点在处理各项业务时调用状态数据；
其中，预设要求包括：每个时期e n内生成的状态数据只能存储到与时期e n对应的状态树S n中。
在一种可能的设计中，处理模块502，还用于在每个时期开始时，若区块链节点中存在前一个时期的第一历史状态树S n-1，则保存并冻结第一历史状态树S n-1。
在一种可能的设计中，当区块链节点为全节点时，在全节点中保存每个时期e n对应的状态树S n；
当区块链节点为轻节点时，在轻节点中至少保存：状态树S n以及第一历史状态树S n-1，并在当前的时期e n开始时，删除不满足预设存储要求的第二历史状态树S m。
在一种可能的设计中，预设存储要求包括：第二历史状态树S m对应的历史时期e m与当前的时期e n的时间间隔小于预设间隔。
在一种可能的设计中，轻节点中能够保存预设数量个连续的时期e n所对应的所有状态树S n，预设数量大于或等于2。
在一种可能的设计中，获取模块501，用于：
获取出块节点发送的区块，并根据区块确定状态数据；
或者，获取用户发送的交易请求，并根据交易请求确定状态数据。
在一种可能的设计中，状态数据对应的地址包括：时期标识以及地址编码，对应的，处理模块502，用于：
在当前时期e now对应的当前状态树S now上，根据地址判断是否存在对应的存储路径；
当存在存储路径时，根据存储路径将状态数据存入当前状态树S now中；
当不存在存储路径时，判断时期标识是否满足免证明要求；
若满足免证明要求，则在当前状态树S now上，根据地址编码创建对应的存储路径；
根据存储路径将状态数据存入当前状态树S now中。
在一种可能的设计中，处理模块502，用于：
判断在区块链网络的任意一个区块链节点中是否都储存有时期标识对应的状态树S 0。
在一种可能的设计中，处理模块502，用于：
判断第一时期e 0是否在当前时期e now之前的预设时间范围内，第一时期e 0与时期标识相对应。
可选的，时间范围包括：k个周期，周期为每个时期e n所持续的时间长度，k大于或等于1。
在一种可能的设计中，处理模块502，还用于：
若不满足免证明要求，则根据地址，在各个历史时期对应的历史状态树上判断是否存在状态数据；
若不存在，则利用预设验证模型生成第一证明信息，且当区块链节点为出块节点时， 将第一证明信息添加到状态数据对应的区块中，并将区块发送到区块链网络中进行共识，第一证明信息用于表征状态数据不在各个历史状态树上；
并在当前状态树S now上，根据地址编码创建存储路径，根据存储路径将状态数据存入当前状态树S now中。
在一种可能的设计中，处理模块502，用于：
在各个目标历史时期所对应的目标历史状态树上，根据地址编码判断是否存在状态数据，目标历史时期包括：从时期标识对应的第一时期e 0开始的各个历史时期；
其中，目标历史状态树不包括已经存储在轻节点上的各个轻节点状态树，轻节点状态树至少包括：当前时期的状态树S n以及当前时期之前一个时期的第一历史状态树S n-1。
可选的，目标历史时期不包括：当前时期e now以及当前时期e now的前一个时期e now-1。
在一种可能的设计中，处理模块502，还用于：
若存在，则利用预设验证模型生成第二证明信息，并且当区块链节点为出块节点时，将第二证明信息添加到状态数据对应的区块中，并将区块发送到区块链网络中进行共识，第二证明信息用于表征：状态数据在最后一次被修改时所对应的第二状态树S 1上，并且在最后修改时期e 1之后的各个历史状态树上都不存在状态数据，最后修改时期与第二状态树S 1相对应；
并在当前状态树S now上，根据地址编码创建存储路径，根据存储路径将状态数据存入当前状态树S now中。
在一种可能的设计中，处理模块502，还用于：
当状态数据在当前时期e now发生改变时，在当前时期对应的当前状态树S now上更新状态数据；
区块链网络上的所有区块链节点将状态数据从各个历史状态树中删除，仅保留状态数据在各个状态树S n中对应的存储路径的哈希值。
在一种可能的设计中，处理模块502，用于：
将上一个时期e n-1对应的第一历史状态树S n-1中访问频率小于预设阈值的节点删除后，得到状态树S n。
值得说明的是，图5所示实施例提供的装置，可以执行上述任一方法实施例中所提供的方法，其具体实现原理、技术特征、专业名词解释以及技术效果类似，在此不再赘述。
图6为本申请实施例提供的一种电子设备的结构示意图。如图6所示，该电子设备600，可以包括：至少一个处理器601和存储器602。图6示出的是以一个处理器为例的电子设备。
存储器602，用于存放程序。具体地，程序可以包括程序代码，程序代码包括计算机操作指令。
存储器602可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。
处理器601用于执行存储器602存储的计算机执行指令，以实现以上各方法实施例所述的方法。
其中，处理器601可能是一个中央处理器(central processing unit，简称为CPU)，或者是特定集成电路(application specific integrated circuit，简称为ASIC)，或者是被配置成 实施本申请实施例的一个或多个集成电路。
可选地，存储器602既可以是独立的，也可以跟处理器601集成在一起。当所述存储器602是独立于处理器601之外的器件时，所述电子设备600，还可以包括：
总线603，用于连接所述处理器601以及所述存储器602。总线可以是工业标准体系结构(industry standard architecture，简称为ISA)总线、外部设备互连(peripheral component，PCI)总线或扩展工业标准体系结构(extended industry standard architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等，但并不表示仅有一根总线或一种类型的总线。
可选的，在具体实现上，如果存储器602和处理器601集成在一块芯片上实现，则存储器602和处理器601可以通过内部接口完成通信。
本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质可以包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁盘或者光盘等各种可以存储程序代码的介质，具体的，该计算机可读存储介质中存储有程序指令，程序指令用于上述各方法实施例中的方法。
本申请实施例还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的方法。
本申请实施例还提供一种计算机程序，包括程序代码，当计算机运行所述计算机程序时，所述程序代码执行如上述各方法实施例中的方法。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由本申请的权利要求书指出。
应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。
最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (21)

  1. 一种区块链状态数据处理方法，其特征在于，应用于区块链节点，所述方法包括：
    在每个时期e n开始时，创建与所述时期e n相对应的状态树S n；
    获取状态数据，所述状态数据包括：时期标识以及所述区块链节点为处理传入的区块和/或接收到的业务事件所必须的信息；
    根据所述时期标识以及预设要求，将所述状态数据存储到所述状态树S n中，以便于所述区块链节点在处理各项业务时调用所述状态数据；
    其中，所述预设要求包括：每个所述时期e n内生成的所述状态数据只能存储到与所述时期e n对应的所述状态树S n中。
  2. 根据权利要求1所述的区块链状态数据处理方法，其特征在于，还包括：在每个所述时期开始时，若所述区块链节点中存在前一个时期的第一历史状态树S n-1，则保存并冻结所述第一历史状态树S n-1。
  3. 根据权利要求1或2所述的区块链状态数据处理方法，其特征在于，当所述区块链节点为全节点时，在所述全节点中保存每个时期e n对应的状态树S n；
    当所述区块链节点为轻节点时，在所述轻节点中至少保存：所述状态树S n以及所述第一历史状态树S n-1，并在当前的时期e n开始时，删除不满足预设存储要求的第二历史状态树S m。
  4. 根据权利要求3所述的区块链状态数据处理方法，其特征在于，所述预设存储要求包括：所述第二历史状态树S m对应的历史时期e m与当前的所述时期e n的时间间隔小于预设间隔。
  5. 根据权利要求3或4所述的区块链状态数据处理方法，其特征在于，所述轻节点中能够保存预设数量个连续的所述时期e n所对应的所有所述状态树S n，所述预设数量大于或等于2。
  6. 根据权利要求1-5中任意一项所述的区块链状态数据处理方法，其特征在于，所述获取状态数据，包括：
    获取出块节点发送的区块，并根据所述区块确定所述状态数据；
    或者，获取用户发送的交易请求，并根据所述交易请求确定所述状态数据。
  7. 根据权利要求6所述的区块链状态数据处理方法，其特征在于，所述状态数据对应的地址包括：所述时期标识以及地址编码，所述根据所述时期标识以及预设要求，将所述状态数据存储到所述状态树S n中，包括：
    在当前时期e now对应的当前状态树S now上，根据所述地址判断是否存在对应的存储路径；
    当存在所述存储路径时，根据所述存储路径将所述状态数据存入所述当前状态树S now中；
    当不存在所述存储路径时，判断所述时期标识是否满足免证明要求；
    若满足所述免证明要求，则在所述当前状态树S now上，根据所述地址编码创建对应的所述存储路径；
    根据所述存储路径将所述状态数据存入所述当前状态树S now中。
  8. 根据权利要求7所述的区块链状态数据处理方法，其特征在于，所述根据所述时期标识判断是否满足免证明要求，包括：
    判断在区块链网络的任意一个所述区块链节点中是否都储存有所述时期标识对应的状态树S 0。
  9. 根据权利要求7所述的区块链状态数据处理方法，其特征在于，所述判断所述时期标识是否满足免证明要求，包括：
    判断第一时期e 0是否在当前时期e now之前的预设时间范围内，所述第一时期e 0与所述时期标识相对应。
  10. 根据权利要求9所述的区块链状态数据处理方法，其特征在于，所述时间范围包括：k个周期，所述周期为每个所述时期e n所持续的时间长度，所述k大于或等于1。
  11. 根据权利要求7-10中任意一项所述的区块链状态数据处理方法，其特征在于，在所述判断所述时期标识是否满足免证明要求之后，还包括：
    若不满足所述免证明要求，则根据所述地址，在各个历史时期对应的历史状态树上判断是否存在所述状态数据；
    若不存在，则利用预设验证模型生成第一证明信息，且当所述区块链节点为出块节点时，将所述第一证明信息添加到所述状态数据对应的所述区块中，并将所述区块发送到区块链网络中进行共识，所述第一证明信息用于表征所述状态数据不在各个所述历史状态树上；
    并在所述当前状态树S now上，根据所述地址编码创建所述存储路径，根据所述存储路径将所述状态数据存入所述当前状态树S now中。
  12. 根据权利要求11所述的区块链状态数据处理方法，其特征在于，所述根据所述地址，在各个历史时期对应的历史状态树上判断是否存在所述状态数据，包括：
    在各个目标历史时期所对应的目标历史状态树上，根据所述地址编码判断是否存在所述状态数据，所述目标历史时期包括：从所述时期标识对应的第一时期e 0开始的各个所述历史时期；
    其中，所述目标历史状态树不包括已经存储在轻节点上的各个轻节点状态树，所述轻节点状态树至少包括：当前时期的所述状态树S n以及所述当前时期之前一个时期的第一历史状态树S n-1。
  13. 根据权利要求12所述的区块链状态数据处理方法，其特征在于，所述目标历史时期不包括：所述当前时期e now以及所述当前时期e now的前一个时期e now-1。
  14. 根据权利要求11-13中任意一项所述的区块链状态数据处理方法，其特征在于，所述在各个目标历史时期所对应的目标历史状态树上，根据所述地址编码判断是否存在所述状态数据之后，还包括：
    若存在，则利用所述预设验证模型生成第二证明信息，并且当所述区块链节点为所述出块节点时，将所述第二证明信息添加到所述状态数据对应的所述区块中，并将所述区块发送到区块链网络中进行共识，所述第二证明信息用于表征：所述状态数据在最后一次被修改时所对应的第二状态树S 1上，并且在最后修改时期e 1之后的各个所述历史状态树上都不存在所述状态数据，所述最后修改时期与所述第二状态树S 1相对应；
    并在所述当前状态树S now上，根据所述地址编码创建所述存储路径，根据所述存储路径将所述状态数据存入所述当前状态树S now中。
  15. 根据权利要求1-14中任意一项所述的区块链状态数据处理方法，其特征在于，在所述根据所述时期标识以及预设要求，将所述状态数据存储到所述状态树S n中之后，还包括：
    当所述状态数据在当前时期e now发生改变时，在所述当前时期对应的当前状态树S now上更新所述状态数据；
    区块链网络上的所有所述区块链节点将所述状态数据从各个历史状态树中删除， 仅保留所述状态数据在各个所述状态树S n中对应的存储路径的哈希值。
  16. 根据权利要求1-15中任意一项所述的区块链状态数据处理方法，其特征在于，所述在每个时期e n开始时，创建与所述时期e n相对应的状态树S n，包括：
    将上一个时期e n-1对应的第一历史状态树S n-1中，访问频率小于预设阈值的节点删除后，得到所述状态树S n。
  17. 一种区块链状态数据处理装置，其特征在于，包括：
    处理模块，用于在每个时期e n开始时，创建与所述时期e n相对应的状态树S n；
    获取模块，用于获取状态数据，所述状态数据包括：时期标识以及所述区块链节点为处理传入的区块和/或接收到的业务事件所必须的信息；
    所述处理模块，还用于：
    根据所述时期标识以及预设要求，将所述状态数据存储到所述状态树S n中，以便于所述区块链节点在处理各项业务时调用所述状态数据；
    其中，所述预设要求包括：每个所述时期e n内生成的所述状态数据只能存储到与所述时期e n对应的所述状态树S n中。
  18. 一种电子设备，其特征在于，包括：处理器以及存储器；
    所述存储器，用于存储所述处理器的计算机程序；
    所述处理器配置为经由执行所述计算机程序来执行权利要求1至16任一项所述的区块链状态数据处理方法。
  19. 一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至16任一项所述的区块链状态数据处理方法。
  20. 一种计算机程序产品，包括计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至16任一项所述的区块链状态数据处理方法。
  21. 一种计算机程序，其特征在于，包括程序代码，当计算机运行所述计算机程序时，所述程序代码执行如权利要求1至16任一项所述的区块链状态数据处理方法。
PCT/CN2022/102159 2021-11-26 2022-06-29 区块链状态数据处理方法 WO2023093041A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111426166.6A CN114117489A (zh) 2021-11-26 2021-11-26 区块链状态数据处理方法
CN202111426166.6 2021-11-26

Publications (1)

Publication Number Publication Date
WO2023093041A1 true WO2023093041A1 (zh) 2023-06-01

Family

ID=80370802

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/102159 WO2023093041A1 (zh) 2021-11-26 2022-06-29 区块链状态数据处理方法

Country Status (2)

Country Link
CN (1) CN114117489A (zh)
WO (1) WO2023093041A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117151449A (zh) * 2023-10-30 2023-12-01 国网浙江省电力有限公司 基于全场景联动的数据平台链式信息交互方法

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114117489A (zh) * 2021-11-26 2022-03-01 深圳前海微众银行股份有限公司 区块链状态数据处理方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106202717A (zh) * 2016-07-06 2016-12-07 浙江大学 一种基于多状态树的退化系统风险概率计算方法
CN111837115A (zh) * 2019-07-11 2020-10-27 创新先进技术有限公司 共享的区块链数据存储
CN112887421A (zh) * 2019-07-31 2021-06-01 创新先进技术有限公司 区块链状态数据同步方法及装置、电子设备
CN113360456A (zh) * 2021-08-11 2021-09-07 腾讯科技（深圳）有限公司 数据归档方法、装置、设备以及存储介质
CN114117489A (zh) * 2021-11-26 2022-03-01 深圳前海微众银行股份有限公司 区块链状态数据处理方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106202717A (zh) * 2016-07-06 2016-12-07 浙江大学 一种基于多状态树的退化系统风险概率计算方法
CN111837115A (zh) * 2019-07-11 2020-10-27 创新先进技术有限公司 共享的区块链数据存储
CN112887421A (zh) * 2019-07-31 2021-06-01 创新先进技术有限公司 区块链状态数据同步方法及装置、电子设备
CN113360456A (zh) * 2021-08-11 2021-09-07 腾讯科技（深圳）有限公司 数据归档方法、装置、设备以及存储介质
CN114117489A (zh) * 2021-11-26 2022-03-01 深圳前海微众银行股份有限公司 区块链状态数据处理方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117151449A (zh) * 2023-10-30 2023-12-01 国网浙江省电力有限公司 基于全场景联动的数据平台链式信息交互方法
CN117151449B (zh) * 2023-10-30 2024-02-06 国网浙江省电力有限公司 基于全场景联动的数据平台链式信息交互方法

Also Published As

Publication number Publication date
CN114117489A (zh) 2022-03-01

Similar Documents

Publication Publication Date Title
WO2023093041A1 (zh) 区块链状态数据处理方法
KR102454779B1 (ko) 이벤트들의 삭제를 가능하게 하는 분산 데이터베이스를 위한 방법 및 장치
WO2021032138A1 (zh) 一种基于区块链系统的共识方法、装置及系统
US11157487B2 (en) Trusted storage method and system based on directed acyclic graph structure
US20200143366A1 (en) Methods for decentralized digital asset transfer and smart contract state transition
US20230273912A1 (en) Data processing method and apparatus for blockchain network, computer device, and computer-readable storage medium
Baswana et al. Fully dynamic randomized algorithms for graph spanners
TW201731253A (zh) 量子金鑰分發方法及裝置
CN113259456B (zh) 跨链交互方法及装置
WO2021244581A1 (zh) 联盟链中的共识方法和系统
US11818246B2 (en) Blockchain data structures and systems and methods therefor for multipath transaction management
JP2023544422A (ja) ネットワーク内の分散データベースのための方法及び装置
Jia et al. Se-chain: A scalable storage and efficient retrieval model for blockchain
Sopaoglu et al. A top-down k-anonymization implementation for apache spark
WO2024021412A1 (zh) 结构化p2p网络优化
CN113259460A (zh) 跨链交互方法及装置
WO2023050986A1 (zh) 维护区块链系统的网络架构信息
EP3939236B1 (en) Node and cluster management on distributed self-governed ecosystem
Huang et al. Blockchain based log system
CN113157450A (zh) 在区块链系统中执行区块的方法及装置
CN118400385A (zh) 区块链数据存储系统和方法
CN113259454B (zh) 跨链交互方法及装置
EP2208317B1 (en) Compressing null columns in rows of the tabular data stream protocol
CN113067838B (zh) 跨链交互方法及装置
CN113923217A (zh) 一种基于dag的异步拜占庭共识方法及系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22897137

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE