CN114117489A

CN114117489A - Block chain state data processing method

Info

Publication number: CN114117489A
Application number: CN202111426166.6A
Authority: CN
Inventors: 冼祥斌; 周禄; 张开翔; 范瑞彬
Original assignee: WeBank Co Ltd
Current assignee: WeBank Co Ltd
Priority date: 2021-11-26
Filing date: 2021-11-26
Publication date: 2022-03-01
Also published as: WO2023093041A1

Abstract

The application provides a block chain state data processing method which is applied to a block chain node and used for processing data in each period e_nAt the beginning, a create and epoch e_nCorresponding state tree S_n(ii) a Acquiring status data, the status data comprising: information necessary for a node to process incoming blocks and/or received traffic events; storing state data into a state tree S according to preset requirements_nThe node calls the state data when processing each service; wherein the preset requirements include: each epoch e_nThe status data in the memory can only be stored to the AND period e_nCorresponding state tree S_nIn (1). Solves the problem that the block chain system in the prior art operates for a period of timeThe efficiency of state data retrieval and access is greatly reduced. The technical effect of avoiding the decrease of the transaction processing efficiency or the processing capacity of the block link point pair caused by the explosive increase of the state data is achieved.

Description

Block chain state data processing method

Technical Field

The application relates to the field of financial technology (Fintech), in particular to a block chain state data processing method.

Background

With the development of computer technology, more and more technologies are applied in the financial field, the traditional financial industry is gradually changing to financial technology (Fintech), and a Block chain (Block chain) technology is not an exception, but higher requirements are also put forward on the technology due to the requirements of the financial industry on safety and real-time performance.

At present, each block chain node generally uses a tree-shaped storage structure, i.e. a state tree, to store state data, which is information necessary for the operation of the block chain node, but as a block chain system continuously operates, more and more state data are available, and the state tree is larger and larger, so that the efficiency of data retrieval and access is greatly reduced.

That is, there is a technical problem in the prior art that efficiency of retrieving and accessing state data is greatly reduced after a block chain system operates for a period of time.

Disclosure of Invention

The application provides a block chain state data processing method, which aims to solve the technical problem that in the prior art, the efficiency of retrieving and accessing state data is greatly reduced after a block chain system runs for a period of time.

In a first aspect, the present application provides a method for processing blockchain state data, which is applied to a blockchain node, and includes:

at each time period e_nAt the beginning, a create and epoch e_nCorresponding state tree S_n；

Acquiring status data, the status data comprising: an epoch identifier and information necessary for the blockchain node to process incoming blocks and/or received traffic events;

according to the time period identification and the preset requirement, the shape is dividedStoring state data into a state tree S_nIn order to facilitate the calling of state data when the block chain node processes each service;

wherein the preset requirements include: each epoch e_nThe internally generated state data can only be stored to the AND period e_nCorresponding state tree S_nIn (1).

In one possible design, the method further includes: at the beginning of each epoch, if there is a first historical state tree S of the previous epoch in the blockchain node_n-1Then the first History State Tree S is saved and frozen_n-1。

In one possible design, when the blockchain node is a full node, each epoch e is saved in the full node_nCorresponding state tree S_n；

When the block chain node is a light node, at least storing in the light node: state tree S_nAnd a first history state tree S_n-1And at the current time period e_nAt the beginning, the second history state tree S which does not meet the preset storage requirement is deleted_m。

In one possible design, the preset storage requirement includes: second History State Tree S_mCorresponding historical period e_mWith the current epoch e_nIs less than a preset interval.

In one possible design, a preset number of consecutive periods e can be saved in the light node_nCorresponding all state trees S_nThe predetermined number is greater than or equal to 2.

In one possible design, obtaining the state data includes:

acquiring a block sent by a block node, and determining state data according to the block;

or acquiring a transaction request sent by a user, and determining the state data according to the transaction request.

In one possible design, the address to which the state data corresponds includes: storing the state data into the state tree S according to the period identification and the preset requirement_nIn, comprising:

at the current time e_nowCorresponding current state tree S_nowJudging whether a corresponding storage path exists according to the address;

when a storage path exists, storing the state data into the current state tree S according to the storage path_nowPerforming the following steps;

when the storage path does not exist, judging whether the time identification meets the certification-free requirement or not;

if the certification-free requirement is met, then the current state tree S_nowCreating a corresponding storage path according to the address code;

storing the state data into the current state tree S according to the storage path_nowIn (1).

In one possible design, determining whether the certification-exempt requirement is satisfied based on the epoch identifier includes:

judging whether any blockchain node of the blockchain network stores the state tree S corresponding to the time identification₀。

In one possible design, determining whether the epoch identifier satisfies the attestation-exempt requirement includes:

determining the first period e₀Whether or not in the current epoch e_nowWithin a predetermined time range, a first period e₀Corresponding to the epoch id.

Optionally, the time range includes: k cycles of each period e_nThe length of time, k, is greater than or equal to 1.

In one possible design, after determining whether the epoch identifier satisfies the attestation-exempt requirement, the method further includes:

if the certification-free requirement is not met, judging whether state data exist on a historical state tree corresponding to each historical period according to the address;

if the state data do not exist in the block chain network, generating first certification information by using a preset verification model, and when the chain link point of the block is a block outlet node, adding the first certification information into the block corresponding to the state data, and sending the block to the block chain network for consensus, wherein the first certification information is used for representing that the state data are not in each historical state tree;

and in the current state tree S_nowCreating a memory path according to the address code, and storing the state data into the current state tree S according to the memory path_nowIn (1).

In one possible design, determining whether there is state data in a history state tree corresponding to each history period according to the address includes:

judging whether state data exists on a target history state tree corresponding to each target history period according to address codes, wherein the target history period comprises the following steps: identifying a corresponding first epoch e from epochs₀Beginning respective historical periods;

wherein the target historical state tree does not include the respective light node state trees that have been stored on the light nodes, the light node state trees including at least: state tree S for the current epoch_nAnd a first history state tree S of a period before the current period_n-1。

Optionally, the target historical period does not include: current epoch e_nowAnd the current epoch e_nowPrevious epoch e of_now-1。

In one possible design, after determining whether state data exists in a target history state tree corresponding to each target history period according to address codes, the method further includes:

if the block chain node exists, generating second certification information by using a preset verification model, and when the block chain node is a block node, adding the second certification information into a block corresponding to the state data, and sending the block to a block chain network for consensus, wherein the second certification information is used for representing: a second state tree S corresponding to the last time the state data is modified₁And at the last modification epoch₁The last modification period and the second state tree S do not have state data on the history state trees₁Corresponding;

In one possible design, the state data is stored in a state tree S according to the epoch identifier and the preset requirements_nAfter, still include:

when the state data is in the current period e_nowWhen a change occurs, the current state tree S corresponding to the current period_nowUpdating the state data;

deleting the state data from each historical state tree by all block chain nodes on the block chain network, and only keeping the state data in each state tree S_nThe hash value of the corresponding storage path in (1).

In one possible design, at each epoch e_nAt the beginning, a create and epoch e_nCorresponding state tree S_nThe method comprises the following steps:

will last epoch e_n-1Corresponding first History State Tree S_n-1After deleting the nodes with the medium access frequency less than the preset threshold value, obtaining the state tree S_n。

In a second aspect, the present application provides a block chain state data processing apparatus, including:

a processing module for each period e_nAt the beginning, a create and epoch e_nCorresponding state tree S_n；

An acquisition module configured to acquire status data, the status data including: an epoch identifier and information necessary for the blockchain node to process incoming blocks and/or received traffic events;

the processing module is also used for storing the state data into the state tree S according to the period identification and the preset requirement_nIn order to facilitate the calling of state data when the block chain node processes each service;

In a third aspect, the present application provides an electronic device comprising:

a memory for storing program instructions;

and the processor is used for calling and executing the program instructions in the memory to execute any one of the possible item storage information determination methods provided by the first aspect.

In a fourth aspect, the present application provides a storage medium, where a computer program is stored, where the computer program is used to execute any one of the possible block chain state data processing methods provided in the first aspect.

In a fifth aspect, the present application further provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the computer program implements any one of the possible block chain state data processing methods provided in the first aspect.

The application provides a block chain state data processing method, which is realized by that in each period e_nAt the beginning, a create and epoch e_nCorresponding state tree S_n(ii) a Acquiring status data, the status data comprising: an epoch identifier and information necessary for the blockchain node to process incoming blocks and/or received traffic events; storing the state data into a state tree S according to the period identification and the preset requirement_nIn order to facilitate the calling of state data when the block chain node processes each service; wherein the preset requirements include: each epoch e_nThe internally generated state data can only be stored to the AND period e_nCorresponding state tree S_nIn (1). The method and the device solve the technical problem that the efficiency of retrieving and accessing the state data is greatly reduced after the block chain system operates for a period of time in the prior art. The technical effect of avoiding the decrease of the transaction processing efficiency or the processing capacity of the block link point pair caused by the explosive increase of the state data is achieved.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application.

FIG. 1 is a schematic diagram of a state tree structure provided in the present application;

fig. 2 is a schematic view of an application scenario of a block chain state data processing method according to an embodiment of the present application;

fig. 3 is a schematic flow chart of a block chain state data processing method according to the present application;

fig. 4 is a schematic flowchart of another block chain status data processing method according to an embodiment of the present disclosure;

fig. 5 is a schematic structural diagram of a block chain state data processing apparatus according to an embodiment of the present application;

fig. 6 is a schematic structural diagram of an electronic device provided in the present application.

With the above figures, there are shown specific embodiments of the present application, which will be described in more detail below. These drawings and written description are not intended to limit the scope of the inventive concepts in any manner, but rather to illustrate the inventive concepts to those skilled in the art by reference to specific embodiments.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all the embodiments. All other embodiments, including but not limited to combinations of embodiments, which can be derived by a person skilled in the art from the embodiments disclosed herein without making any inventive step are within the scope of the present application.

The terms "first," "second," "third," "fourth," and the like in the description and in the claims of the present application and in the drawings described above, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the application described herein are, for example, capable of operation in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

The following explanations are made for terms to which this application refers:

(1) state and state tree in blockchain:

generally, after a period of operation in the network, a node in the blockchain network stores data on a local storage device, and the data can be classified into two categories according to its time attribute: historical data (referred to simply as "history") and current data (referred to simply as "status").

The state is as follows: refers to information that a node of the blockchain system must hold or store in order to be able to process a newly incoming block and/or event. The status is relative to the history.

History: the event record is descriptive information of events which have occurred in the past, and after the history is stored, the event record can be used for reviewing or replaying the events which have occurred, and the history can be archived and managed.

In a blockchain system applied to the financial field, the states include:

1. account balance and/or non-balance information, such as Nonce;

2. a code corresponding to the intelligent contract;

3. data needing to be stored corresponding to the intelligent contract;

4. the related data required for consensus among the nodes is consensus data, such as hash values, number, rights and interests of the recently generated blocks.

Over time, as new users enter the blockchain network, which creates new accounts and new intelligent contracts, invoking functions in the intelligent contracts, these data (i.e., the specific bearer form of the "state") will grow.

In the prior art, most of the blockchain systems employ a binary (i.e., two leaf nodes) or a six-way (i.e., six leaf nodes) pahal-merck tree (a type of state tree) to maintain and manage state data, which is typically stored in the form of key-value pairs, e.g., (key, value).

Pascal-mercker trees: the dictionary tree is provided with a root node, a middle node and leaf nodes, each node is provided with a unique key, a storage position corresponding to the key can be found in the state tree according to the key of the state data, and then the value in the state data stored in the storage slot of the storage position.

For example, an account, such as 0x001d3f1ef827, may have a myriad of state data, and to put the state data into the state tree, the hash value, i.e., the result of the hash (0x001d3f1ef827), may be used as a "key" to find an intermediate node in the state tree (i.e., the "key" represents the address of the intermediate node or a path to find the intermediate node), so that all the state data of the account is stored under the subtree of the intermediate node.

Woklaer tree: it is also essentially a dictionary tree that stores and retrieves state data in a manner similar to the Parcel-Merck tree, but is broader in the Watcher tree, i.e., the number n of children of a node in the Watcher tree₁Number n of children of a node in Bipauer-Merkel Tree₂Is much larger (i.e. n)₁>>n₂) Thus, for a fixed length of key address, the depth of the Wolk tree (i.e., the total number of tree levels) is much less than the Pacharl-Merck tree. Due to the small depth, the addition and modification operations of the nodes by the Wolk tree are simpler. More importantly, for the proof of presence of a node (i.e., validation data), the Wolk tree uses Wolk proof that is much smaller than the Merck proof of Parsler-Merck tree.

Wacker proves that: a node is certified as one of many children of its parent node by employing a polynomial commitment (a type of vector commitment). Since the value of the parent node in the wokerr tree is determined by the values of all the child nodes, it is equivalent to proving the relationship between the value of a node and its parent node without providing the values of all sibling nodes as in the merkel proof to verify the relationship between the node and the parent node. The wacker proof is therefore very small and the validation efficiency is higher.

(2) Full node, light node and verifier node:

different blockchain systems have different node role divisions, which can be roughly divided into: a full node, a light node, and a verifier node.

All nodes: refers to a node that holds all the data of the blockchain. It holds the complete "state" data and all "history" data (some federation chains discard state data in history blocks such as FISCO BCOS).

And (3) light node: refers to a node that only holds a portion of the commonly used state data. This allows the light nodes to save more memory space than the weight nodes, while handling most of the user's transactions and packaging blocks. It should be noted that the functions of the light nodes are not necessarily the same in different blockchain systems.

A verifier node: refers to a node that only participates in verifying the correctness of a block in the consensus system, but does not have the ability to pack blocks. Similarly, in different blockchain systems, the verifier nodes need to store different sizes of states in order to be able to verify the correctness of the block.

It should be further noted that, the whole nodes include: body parts of various blocks (i.e. Body, a block can be divided into two parts of head and Body), transaction list and other related information. The whole node locally stores a complete blockchain network on which any query, transaction verification and broadcast can be carried out, and due to the existence of the whole node, the decentralized of the blockchain is possible, and meanwhile, the blockchain network is safer. It should be noted that, in general, all nodes need to be kept online all the time.

The light nodes are different from the whole nodes in that all transaction contents are not required to be stored, the Header of each block and transaction detail information related to the nodes are stored only in a state tree form, and whether the transaction is in a current block chain transaction list is judged by a verification method (also called as 'certification') corresponding to the state tree. Unlike a full node, a light node does not need to remain online at all times.

Time period epoch: representing the time elapsed for a fixed number (e.g., 10000 blocks) of blocks, the "state" (i.e., state data) created or modified during this period e automatically becomes the "state" of expiration by the next period e + 1.

The inventor of the present application finds that, in the existing block chain system, each block chain node generally uses a tree-like storage structure, i.e., a state tree, to store state data, which is information necessary for the operation of the block chain node, but as the block chain system continuously operates, the number of the state data increases, and the state tree also increases, which greatly reduces the efficiency of data retrieval and access.

In order to solve the above problems, one idea is: the "two-tree scheme" used for the management of the "state": the expired states constitute an expired state tree and the non-expired current states constitute an active state tree.

In the active status tree, the status storage slot on the leaf node corresponding to each account (including the intelligent contract) is started to be timed immediately after being created, if the status data in the status storage slot is modified within a preset time, the status storage slot is re-timed, and conversely, if the status data of the account is not modified after a preset time, the status data is placed on the expired status tree.

All nodes need to store both trees, and other nodes, such as light nodes, only store the active state tree. If a user wants to access or revive an expired status of an account, the user must provide proof (i.e., verification data) that the corresponding status of the account is on the expired status tree.

However, the present inventors have found that the above-mentioned method still causes the following technical problems:

1. if the node of the packed block is not a full node, an account will be moved out of the active state tree after expiration, and when other users create accounts with the same address (equivalent to creating the same account name), recovery of the state corresponding to the original account will be hindered. Or if the owner of the original account cannot provide the proof (i.e., the verification data), it may result in the information of the entire account being reconstructed and even result in conflicts with the historical data.

2. Most of the current block chains use the hexaipara-mercke tree as a state tree, the state certificate reaches 4MB at most, which results in that one block cannot accommodate several transactions containing the state certificate, i.e. transactions accessing an expired state, or the block is too large, thereby affecting the speed of consensus.

3. The prior art can not fundamentally solve the explosion growth problem of the state, the practice of a plurality of public chains can not be directly used in a alliance chain, particularly the alliance chain without a token mechanism, and the existing state tree structure is difficult to be combined with advanced cryptography to improve the efficiency of state data management and certification.

In order to solve the above technical problems, the present application adopts another inventive concept:

the basic logic for changing the state data management does not just distinguish the expired state tree from the active state tree, but a new state tree is established corresponding to each node in each preset time unit, namely, period, and the state tree only stores the state data occurring in the current period or modifies the state data changed in the current period, and the state data for the previous period or the future period is not stored in the current state tree. That is, each epoch has a corresponding state tree, future epochs of the state tree are currently inoperable, and past epochs of the state tree to access need to provide node presence attestation.

Moreover, in order to enable the state data to be correctly stored in the state tree of the correct period, a period prefix needs to be added to the original address, so that the user cannot recreate the same address, and if the user wants to create an address of a history period, a proof must be provided for the node to verify that the address never appears. The user cannot create addresses for future periods of time, thereby ensuring that addresses do not conflict and the availability of the address space can be broadened.

Furthermore, the organizational structure of the state tree can be changed, namely, the Wolkel tree is adopted to fundamentally replace the existing Parsler-Merckel tree, but the original storage and retrieval logic is not changed, and the accumulator can be combined to make a proof that the size of the proof is only about 800KB, so that the state tree is more suitable for maintaining and managing the state data in the block chain. This feature enables the blockchain system to allow verifier nodes that do not need to store any state data at all to exist, which enables the mobile device to complete verification, i.e., the mobile device can become a verifier node, making the blockchain system more decentralized.

Specifically, the inventor of the present application resets the processing logic for the state data in the block chain:

(1) new address structure and state tree structure:

fig. 1 is a schematic structural diagram of a state tree provided in the present application. As shown in FIG. 1, there is a separate state tree for each epoch, so that the state comprises a list of ever-growing trees S₀，S₁，S₂，S₃…, each S_iA state tree representing the ith epoch. Therefore, whether the state is expired or not does not need an additional field to indicate, and only the state on the state tree of the current period is a non-expired state. Finally, the root 10 of each state tree forms a total state root 100, the total state root 100 is recorded in the head of each block, and the total state root 100 changes when any one state tree changes. Optionally, the type of state tree comprises a wacker tree.

It should be noted that there must be at least one full node storing all history trees in the blockchain system, and the number of full nodes may be determined by the blockchain participants. Other nodes decide to store some historical state trees according to actual conditions, but it should be noted that, although not all state trees are stored, the root nodes of all state trees are stored, and at least the state tree of the last period and the state tree of the current period are stored on each blockchain node.

For an account for a transaction in a block link point, the account includes: contract accounts (contracts) and external accounts (EOA). For example, in an etherhouse, a contract account is an account that is transacted via a smart contract, controlled by the code of the smart contract. Only the contract account has code stored therein, which is codeHash (hash value of the etherhouse virtual machine code for this account), this field being non-modifiable after generation, which means that the intelligent contract code is not modifiable. And the external account is an account created by a human user of the ethernet network. It is related to the public key, private key pair, which is derived by hashing the public key twice to the last 20 bytes of the result.

The application defines a new account address, which can be represented as a tuple (e, s), where e is the epoch id of the time period to which the address belongs, and is represented by 4 bytes, and s is the original address, i.e. the address code of 20 bytes commonly used by the current block chain. The new account address is represented as e.s in binary, i.e. the epoch id is byte-concatenated with the address code.

(2) State tree access and modification rules:

at the current time epoch:

1. only the current state tree S_eMay be modified.

2. The state tree of a history period is frozen, and all transactions wanting to access the history state tree must carry a certificate to prove the position of the accessed state in the state tree of a history period, such as: the state location is a wacker proof that contains the old state data value, so that the historical state tree can be accessed. Since all blockchain nodes store the state tree S of the last epoch_e-1If the user needs to access the state tree S_e-1The block chain node of the state data in (1) can help the user to provide the certification of the state tree, and most of the hot data is in the state tree, so that most of the users can be satisfied. But if the user' S transaction wants to access S_e-1Previous trees had to look for all nodes to provide proof of access.

3. The state tree for the future epoch may be established in advance but may be modified only after the future epoch becomes the current epoch, or it may be said that the state tree for the future epoch has not been created. When a new period is reached, the node immediately starts or creates a new state tree, and the state tree corresponding to the future period can be a blank state tree or can be attached with a tree node for storing some frequently accessed state data.

(3) Account access and modification rules:

accounts (e, s) can be accessed at any time period f > e, the data of which is permanently stored in a fixed location hash (e, s) of the state tree, and if the storage of the account (e, s) is modified at the current time period epoch f, a corresponding storage slot is created at the hash (e, s) location of the state tree Sf at the current time period since the historical state tree cannot be modified.

The specific modification rules are as follows:

1. if account (e, S) is created and modified at epoch e, then directly at tree S_eCreating and modifying the corresponding position of;

2. if account (e, S) is created or modified at epoch e +1, then directly at tree S_e+1Creating and modifying the corresponding position of;

3. if the account (e, s) is at epoch f (f)>e +1) is created and in the tree S_fAnd S_f-1The upper correspondence has not been created, then proof needs to be provided: accounts (e, S) in these trees S_e，S_e+1，...，S_f-2None of the corresponding positions of (c) appear;

4. if the account (e, s) is at epoch f (f)>e +1) is modified and corresponding locations on trees Sf and Sf-1 have not been created, assuming account (e, s) was last modified at epoch e '(e ≦ e'<f) Then, it is necessary to provide a proof: account (e, S) appears in the status tree S_e′And in these trees S_e′+1,S_e′+2...S_f-2None of the corresponding positions of (c) appear;

5. if the account (e, s) is at epoch f (f)>e) Is modified and is in the tree S_fThe upper corresponding position is created and directly modified.

(4) Pruning a history state tree:

since the state trees of the block chain at different periods are respectively stored, if 'state' deduplication is not performed, large storage overhead can be brought to the block chain link points, especially to the whole nodes.

The method for pruning the historical state tree is as follows: if the "state" of an account (i.e., the state data in this document) changes during the current time period, the state tree for the current time period will keep the latest "state" of the account, so all nodes can delete the old state of the account from the respective historical state trees, and only the node hash value at the corresponding position in the state tree is kept.

(5) The generation mode of the certificate:

when a user needs to prove that a certain account exists in a certain historical state tree or does not exist in the certain historical state tree, the invention adopts the cryptographic accumulator to respectively make member certification and non-member certification.

As shown in fig. 1, the depth of the state tree 100 corresponding to each period is 4, and the breadth is 4 bytes, that is, the number of child nodes in each layer is up to 256, and expressed by a 16-ary expression is 00 to ff. Assuming that the key corresponding to an account in the status tree is 0x3a4b5c, the keys corresponding to the account in the status tree have

node numbers

3a, 4b and 5c at each level, and these numbers also constitute a unique path for storing the corresponding account information in the status tree. Therefore, when the user needs to make a proof that the account exists in the state tree, the system needs to make a proof for the path of the key corresponding to the account, that is, to make member proofs for the node sequence numbers of each layer in the path respectively.

Taking the above key as an example, it is necessary to separately prove that: the 3a node is in the already existing set of child nodes of the root node; the 4b node is in the already existing set of children nodes of 3 a; 5c in the already existing set of children of 4 b. The set of existing children nodes express all keys of the stored state data with the children nodes as middle paths, and the block chain node point or block chain system maintains the set of existing children nodes at each layer of the state tree, so that for any state tree, the second layer has 1 set of existing children nodes, and the third layer has 256 sets of existing children nodes at most.

Taking the example of proving that a 3a node is in an already existing set of children nodes of the root node in particular, a cryptographic accumulator is used to make the membership proof of 3 a. M represents the existing sub-node set accumulator vector, wherein M records the prime number uniquely corresponding to the node sequence number, and x represents_3aRepresenting the prime numbers corresponding to the 3a nodes, and a representing the accumulator value, i.e. the product of all prime numbers in M. x is the number of_3aIs proved by the member

The computational reduction logic of (a) can be represented by equation (1):

the corresponding verification logic can be represented by equation (2):

where g represents the generator of the domain used by the system.

If it is to be proved that another node is assumed that 3b is not in the sub-node set, y is used to represent prime number corresponding to the 3b node, and the non-member of y proves u_yThe calculation simplification logic of (a) can be expressed by equation (3):

the corresponding verification logic can be represented by equation (4):

wherein, Bezout is the betrozen's theorem, and a and b are two coefficients obtained according to the betrozen's theorem.

Sequentially and respectively obtaining member certificates of the 4b nodes

And 5c membership attestation of nodes

Taken together is a proof that the account exists in this state tree. If two accounts involved in a transaction need to provide proof, member proof can be made together at each level, and if the second account passes through the 3c node at the first level and the corresponding prime number is z, only member proof of x z needs to be made, and member proof does not need to be made separately.

The following describes the technical solutions of the present application and how to solve the above technical problems with specific embodiments. The following several specific embodiments may be combined with each other, and details of the same or similar concepts or processes may not be repeated in some embodiments. Embodiments of the present application will be described below with reference to the accompanying drawings.

Fig. 2 is a schematic application scenario diagram of a block chain state data processing method according to an embodiment of the present application. As shown in fig. 2, a user 20 sends a transaction request to any blockchain node 21 in a blockchain network or a blockchain system, the blockchain node 21 executes a transaction corresponding to the transaction request, so that each item of status data of an account for the transaction corresponding to the user changes, the blockchain node 21 receiving the transaction request of the user 20 is also called a blockchain node, and packages the transaction into blocks and sends the blocks to the blockchain network for other blockchain nodes 21 to know in common. In the out-block node, after the transaction is executed, the generated state data is correspondingly stored in the state tree corresponding to the current period in the node, and the other blockchain nodes 21 receiving the block also adopt the same state data processing method to update the state data on the local state tree of the respective blockchain node 21.

The following describes the status data processing method provided by the present application specifically:

fig. 3 is a flowchart illustrating a block chain state data processing method according to an embodiment of the present disclosure. As shown in fig. 3, the method for processing block chain state data includes the following steps:

s301, in each period e_nAt the beginning, a create and epoch e_nCorresponding state tree S_n。

In this step, at each period e_nAt the beginning, the block chain nodes create a new state tree S according to the preset state tree template_nAt the same time, the historical state tree, i.e., the historical state tree of the period prior to the current period, may be frozen, and the historical state tree may access the query, but may not restore new state data to the historical state tree.

Optionally, in this embodiment, the type of the state tree is a wacker tree.

In one possible design, at the beginning of each epoch, if there is a first historic state tree S for the previous epoch in the blockchain node_n-1Then the first History State Tree S is saved and frozen_n-1。

I.e. at each epoch e_nAt the beginning, for the immediately preceding period e_n-1Corresponding state tree S_n-1Instead of deleting it directly, it is merely frozen, but still stored in the block link point.

In another possible design, the block link points in the entire block chain network may be divided into two categories: full nodes and light nodes.

When the blockchain node is a full node, each period e is saved in the full node_nCorresponding state tree S_n；

For example, when the preset interval is 2, the light node only stores the state trees of the current period and the previous period, and if the light node needs to access the historical state trees of other periods, the light node needs to make an access request to the whole node, and the whole node performs access query on the corresponding historical state tree.

Certainly, the light node may also store more state trees of historical periods, for example, when the preset interval takes a value of 3 to 6, the light node may store the state trees of 3 to 5 consecutive periods.

It should be noted that the light nodes may also be historical state trees of non-consecutive periods, such as: and saving the state trees of the current period, the previous 1 historical period, the previous 3 historical periods and the three periods.

The principle of preservation can be set as: if the creation and/or modification amount of the state data in the historical period is larger than a preset threshold value, or the transaction amount in the historical period is larger than the preset threshold value, it is proved that the state data in the historical period has a high probability to be used, the state tree corresponding to the historical period is kept in the block chain node, and the historical state tree is not deleted until the access heat degree of the corresponding state data is lower than the preset heat degree threshold value.

Of course, those skilled in the art can set the number of the light nodes to save the state tree and the saving rule according to the actual situation, but at least the light nodes are guaranteed to include: current State Tree S_nAnd the state tree S of the previous epoch_n-1. I.e. a preset number of consecutive periods e can be kept in the light node_nCorresponding all state trees S_nThe predetermined number is greater than or equal to 2.

In one possible design, in this step, the last epoch e is added_n-1Corresponding first History State Tree S_n-1After deleting the nodes with the medium access frequency less than the preset threshold value, obtaining the current period e_nState tree S of_n。

S302, acquiring state data.

In this step, the status data includes: an epoch identifier and information necessary for the blockchain node to process incoming blocks and/or received traffic events.

This step can be divided into two cases:

first, when a blockchain node is a node that receives a transaction request from a user, due to a consensus mechanism of the blockchain, the transaction needs to be packaged into blocks and issued to a blockchain network for consensus, and therefore, the blockchain node is also called a blockchain node at this time.

At this time, acquiring status data includes: and acquiring a transaction request sent by a user, and determining state data according to the transaction request.

Second, when the blockchain node is not a node receiving a user transaction request but a node performing consensus in the blockchain network, acquiring status data, comprising: and acquiring a block sent by the block node, and determining state data according to the block.

In this embodiment, the address corresponding to the status data includes: epoch identification and address coding.

S303, storing the state data into a state tree S according to the time identification and the preset requirement_nThe method and the device facilitate the blockchain node to call the state data when processing various services.

In this step, the preset requirements include: each epoch e_nThe internally generated state data can only be stored to the AND period e_nCorresponding state tree S_nIn (1).

The method can be divided into five cases:

1. if an account (e, S) is created and modified during time period e, then directly in tree S_eCreating and modifying the corresponding position of;

2. if account (e, S) is created or modified during period e +1, then directly in tree S_e+1Creating and modifying the corresponding position of;

3. if the account (e, s) is in the period f (f)>e +1) is created and in the tree S_fAnd S_f-1The upper correspondence has not been created, then proof needs to be provided: accounts (e, S) in these trees S_e，S_e+1，...，S_f-2None of the corresponding positions of (c) appear;

4. if the account (e, s) is in the period f (f)>e +1) is modified and corresponding locations on trees Sf and Sf-1 have not been created, assuming account (e, s) was last modified at epoch e '(e ≦ e'<f) Then, it is necessary to provide a proof: account (e, S) appears in the status tree S_e′And in these trees S_e′+1,S_e′+2...S_f-2None of the corresponding positions of (c) appear;

5. if the account (e, s) is in the period f (f)>e) Is modified and is in the tree S_fThe upper corresponding position is created and directly modified.

In one possible design, the block chain state data processing method further includes:

when the state data is in the current period e_nowWhen the change occurs, the current state tree S corresponding to the current period_nowUpdating the state data;

deleting the state data from each historical state tree by all the block chain nodes on the block chain network, and only keeping the state data in each state tree S_nThe hash value of the corresponding storage path in (1).

The embodiment of the application provides a block chain state data processing method, which is used for processing block chain state data in each period e_nAt the beginning, a create and epoch e_nCorresponding state tree S_n(ii) a Acquiring status data, the status data comprising: epoch id and blockchain node for handling incoming blocks and/or received traffic eventsThe necessary information; storing the state data into a state tree S according to the period identification and the preset requirement_nIn order to facilitate the calling of state data when the block chain node processes each service; wherein the preset requirements include: each epoch e_nThe internally generated state data can only be stored to the AND period e_nCorresponding state tree S_nIn (1). The method and the device solve the technical problem that the efficiency of retrieving and accessing the state data is greatly reduced after the block chain system operates for a period of time in the prior art. The technical effect of avoiding the decrease of the transaction processing efficiency or the processing capacity of the block link point pair caused by the explosive increase of the state data is achieved.

Fig. 4 is a schematic flowchart of another block chain status data processing method according to an embodiment of the present disclosure. As shown in fig. 4, the method for processing block chain state data includes the following steps:

s401, in each period e_nAt the beginning, a create and epoch e_nCorresponding state tree S_n。

S402, acquiring state data.

The specific terms and principle explanations of steps S401 to S402 can refer to steps S301 to S302, which are not described herein again.

S403, in the current period e_nowCorresponding current state tree S_nowAnd judging whether a corresponding storage path exists according to the address.

In this step, the storage path includes: state tree S_nThe nodes comprise a middle node and a leaf node, and the storage slots are arranged on the leaf node.

When a storage path exists, step S404 is performed, and when a storage path does not exist, step S405 is performed.

In particular, if not already created

S404, storing the state data into the current state tree S according to the storage path_nowIn (1).

In this step, in the current state tree S_nowHaving created the storage slots (as shown in fig. 1), only the state data need be updated in the storage slots.

S405, judging whether the time period identification meets the certification-free requirement.

In this step, if yes, step S406 is executed, and if no, step S407 is executed.

At the current state tree S_nowIf the storage slot corresponding to the state data is not created, then each intermediate node and leaf node need to be created, and the storage slot is created on the leaf node, and then the state data is stored in the storage slot.

However, the situation is complicated, since the present application establishes a state tree for each period, the state data such as the account of the transaction may be in the previous state tree and stored, and thus it is necessary to determine whether the state data is in the historical state tree.

it is determined whether a state tree corresponding to the time period identifier is stored in any blockchain node of the blockchain network S0.

In this embodiment, determining whether the certification-exempting requirement is met according to the time period identifier includes:

In this embodiment, the blockchain network includes at least two kinds of blockchain nodes, that is, a full node and a light node, where the full node stores state trees corresponding to all periods, but the light node only maintains a part of the state trees, but the light node stores at least a current state tree and a historical state tree of a previous period.

Thus, the essence of the proof-exempt 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 stored in the light node, a storage path, namely 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 is stored in the storage slot.

For example, the light node stores therein: current epoch e_nowThe previous period e_now-1First three periods e_now-3And the first five epochs e_now-5A state tree corresponding to the four epochs, then if the epoch id of the state tree corresponds to any of the four epochs, then there is no need for the blockchain node to compute a proof, such as a wacker proof, according to a proof algorithm. (the method of identification is described in detail in "method of producing identification" described above.)

For example, when the light node stores the current epoch e therein_nowAnd the previous period e_now-1The predetermined time range is 1 cycle, i.e. the first two periods e, when corresponding to the state tree_now-2The preset time range is not made.

Namely, corresponding to the description in S303:

2. if account (e, S) is created or modified during period e +1, then directly in tree S_e+1Is created and modified.

S406, in the current state tree S_nowAnd creating a corresponding storage path according to the address coding.

In this step, if the proof-exempt requirement is satisfied, a storage path, i.e., each intermediate node, leaf node, and slot, is directly created on the current state tree according to the address, and then step S404 is performed to store the state data in the slot.

S407, judging whether state data exists in the history state tree corresponding to each history period according to the address.

In this step, if not present, step S408 is executed, and if present, step S409 is executed.

Specifically, when the certification exemption requirement is not satisfied, the range of the history state tree needs to be further expanded. At this time, it should be noted that the light nodes do not store the state trees of all the periods, so for the light nodes, the step can be implemented only by sending the attestation request to all the nodes, and the all the nodes look up whether to store the corresponding state data in the stored history state tree.

In this embodiment, the step specifically includes:

And S408, generating first certification information by using a preset verification model.

In this step, when the block chain node is a block exit node, first certification information is required to be added to a block corresponding to the state data, and the block is sent to the block chain network for consensus, where the first certification information is used to represent that the state data is not in each historical state tree. Then, step S406 is performed.

Namely, corresponding to the description in S303:

3. if account (e, s) is inPeriod f (f)>e +1) is created and in the tree S_fAnd S_f-1The upper correspondence has not been created, then proof needs to be provided: accounts (e, S) in these trees S_e，S_e+1，...，S_f-2Does not appear at all.

It should be noted that only the first certification information is generated, the storage path can be created on the current state tree, otherwise, the state information cannot be stored in the current state tree. That is, in a specific implementation, a check is set for the first certification information, and if the first certification information is not available, the next storage operation cannot be performed.

The method of generating the first certification information in this step includes the wacker certification or the "certification generating method" described above.

And S409, generating second certification information by using a preset verification model.

In this step, when the block chain node is a block exit node, second certification information is added to the block corresponding to the state data, and the block is sent to the block chain network for consensus, where the second certification information is used to characterize: a second state tree S corresponding to the last time the state data is modified₁And at the last modification epoch₁The last modification period and the second state tree S do not have state data on the history state trees₁And correspondingly. Then, step S406 is performed.

Namely, corresponding to the description in S303:

4. if the account (e, s) is in the period f (f)>e +1) is modified and corresponding locations on trees Sf and Sf-1 have not been created, assuming account (e, s) was last modified at epoch e '(e ≦ e'<f) Then, it is necessary to provide a proof: account (e, S) appears in the status tree S_e′And in these trees S_e′+1,S_e′+2...S_f-2Does not appear at all.

Similarly, it should be noted that the storage path can be created on the current state tree only if the second certification information is generated, otherwise, the state information cannot be stored in the current state tree. That is, in the specific implementation, the verification of the second certification information is set, and if the second certification information is not available, the next storage operation cannot be performed.

The second certification information generation method in this step includes the wacker certification or the "certification generation method" described above.

S410, when the state data is in the current period e_nowWhen a change occurs, the current state tree S corresponding to the current period_nowAnd updating the state data.

In this step, if the account corresponding to the state data has multiple transaction services in the same period, the state data is directly updated in the storage slot of the current state tree.

Namely, corresponding to the description in S303:

S411, deleting the state data from each historical state tree, and only keeping the state data in each state tree S_nThe hash value of the corresponding storage path in (1).

The embodiment of the application provides a block chain state data processing method, which is used for processing block chain state data in each period e_nAt the beginning, a create and epoch e_nCorresponding state tree S_n(ii) a Acquiring status data, the status data comprising: an epoch identifier and information necessary for the blockchain node to process incoming blocks and/or received traffic events; storing the state data into a state tree S according to the period identification and the preset requirement_nIn order to facilitate the calling of state data when the block chain node processes each service; wherein the preset requirements include: each epoch e_nThe internally generated state data can only be stored to the AND period e_nCorresponding state tree S_nIn (1). The method and the device solve the technical problem that the efficiency of retrieving and accessing the state data is greatly reduced after the block chain system operates for a period of time in the prior art. The technical effect of avoiding the decrease of the transaction processing efficiency or the processing capacity of the block link point pair caused by the explosive increase of the state data is achieved.

To facilitate understanding of the methods provided by the two embodiments described above, the following examples are made from a time advancing perspective, involving three periods: the period 0, the period 1 and the period 2 are the adjacent two periods, but the period 1 and the period 2 are not necessarily adjacent.

After the initialization of the blockchain system is completed, all nodes in the blockchain system are respectively created and associated with the current period T₀Corresponding first state tree S₀。

When the time runs to the period 0, namely the current period is the period 0:

at the beginning of epoch 0, all nodes respectively create a first state tree S₀，S₀I.e. the current state tree for the current epoch.

Any user end node in the block chain network receives the transaction initiated by the user and creates a corresponding intelligent contract for the transaction.

The transaction is then received and executed by the out-of-block node, which generates a contract address for the intelligent contract, the contract address including: a time period prefix corresponding to the current time period, and an address code.

The out-blocking node then requires according to a first rule of access and modification to the account set in advance (i.e.: 1. if the account (e, S) is created and modified in the period e, then directly in the tree S_eCorresponding location creation and modification) and contract addresses, determine intelligent contracts to first state tree S₀At a memory address of, i.e. in, the first state tree S₀And creating child nodes and storage slots corresponding to the child nodes on the plurality of intermediate nodes. It should be noted that, these intermediate nodes are all included in the address code of the storage address, and since these intermediate nodes all correspond to at least one child node in the state tree, these intermediate nodes are also called parent nodes. Moreover, the child nodes corresponding to a parent node can be placed in a set of child nodes to facilitate retrieval and access of the state tree.

Next, the egress block node saves the data of the intelligent contract in a storage slot.

And then, updating the accumulator vectors and the accumulator values corresponding to each child node set by the node out of the block, wherein the parent node corresponding to the child node set is contained in a storage address, the storage address comprises at least one parent node, and the parent node is an intermediate node on the state tree.

The out-block node then packages the transaction into blocks and publishes the blocks to the blockchain network.

After receiving the block, other nodes in the blockchain network execute the transaction, and also need to create sub-nodes and storage slots at corresponding positions in the first state tree S0 of the node itself according to the first preset requirement, store the data of the intelligent contract in the corresponding storage slots, and update the accumulator vectors and the accumulator values corresponding to the respective sub-node sets.

At any time during period 0, any user interacts with the intelligent contract through a transaction initiated by a user end node, and the corresponding out-block node of the transaction is directly in the first state tree S₀The corresponding storage slot modifies data, and after the block of the transaction is issued to the blockchain network by the block-out node for consensus, all other blocksThe nodes of (2) also perform the same operations as the block nodes, i.e. the first state tree S at each node₀The corresponding slot modifies the data.

For example: at the beginning of period 0, i.e. after the block chain system has been initialized, all nodes respectively create a first state tree S0;

(1) the Ztriplet Send transaction creates an intelligent contract C1 and the Liqund Send transaction creates an intelligent contract C2.

(2) The out-block node executes the transaction upon receipt of the transaction, generates an address (0,0xabcdef) for Smart contract C1 and an address (0,0x123456) for Smart contract C2, respectively, according to Account Access and modification rule 1 (i.e.: 1. if an account (e, S) is created and modified during time period e, then directly at Tree S_eCorresponding location creation and modification) of the first state tree S0, the out-block node creates sub-nodes and slots at locations corresponding to 0x3a4b5c and 0x6d7e8f of the first state tree S0, saves the data of the intelligent contract in the corresponding slots, updates the accumulator vector and accumulator value of the set of sub-nodes where 3a, 4b, 5c, 6d, 7e, 8f is located in the first state tree S0.

Note that, the algorithm for generating the address may use a hash algorithm, that is, hash (0,0xabcdef) ═ 0x3a4b5c, and hash (0,0x123456) ═ 0x6d7e8 f.

(3) The block exit node packs the transaction into a block, other nodes execute the transaction after receiving the block, child nodes and storage slots are created in the positions of 0x3a4b5c and 0x6d7e8f of the respective state tree S0, the data of the intelligent contract is stored in the corresponding storage slots, and the child nodes where 3a, 4b, 5c, 6d, 7e, 8f in the state tree S0 are located are updated to collect accumulator vectors and accumulator values.

(4) During this period, any user sending a transaction interacts with the smart contract C1 or C2, directly modifying data at the corresponding storage slot at the 0x3a4b5C or 0x6d7e8f position of the first state tree S0. The same operation is performed after the transaction of other sync blocks.

When the time runs to the period 1, namely the period 1 is the current period:

entering a new epoch, all nodes create a new empty state tree S1, saving state tree S0.

(1) Any user sending a transaction interacts with smart contract C1 with address (0,0 xabcdef);

(2) after receiving the transaction, the out-block node executes the transaction (whether the out-block node is a full node or a light node), finds that there is no state data with the key 0x3a4b5c in the state tree S1, and then searches in the state tree S0 to find the state data with the key 0x3a4b5 c;

(3) the out-of-block node constructs a proof for this transaction

The attestation key 0x3a4b5c exists in the state tree S0, packaging the attestation and the transaction binding together in a tile.

(4) The out-blocking node accesses and modifies rule 2 according to the account (i.e.: 2. if account (e, S) is created or modified during time period e +1, then directly in tree S_e+1Corresponding location creation and modification) of the state tree S1, creating child nodes and storage slots at the 0x3a4b5c location of the state tree S1, storing the state data after the transaction is executed at that location, updating the accumulator vector and accumulator value of the set of child nodes where 3a, 4b, 5c are located in the state tree S1;

(5) other nodes execute transaction after receiving the block, and verify

If not, rejecting the entire block; if correct, rule 2 is accessed and modified also according to the account (i.e.: 2. if account (e, S) is created or modified during period e +1, then directly in tree S_e+1Corresponding location creation and modification) of the state tree S1, creating child nodes and slots at the 0x3a4b5c location of the respective state tree S1, saving the new state data in the corresponding slots, updating the child node set accumulator vector and accumulator value where 3a, 4b, 5c is located in the state tree S1;

(6) thereafter, during this period, any user sent transactions to interact with the smart contract C1, the chunking node modifies the data according to the account access and modification rules 2, directly at the 0x3a4b5C location and corresponding storage slot of the state tree S1. The same operation is performed after the transaction of other sync blocks.

Thirdly, when the time runs to the period 2, namely the period 2 is the current period:

entering a new epoch, all nodes create a new empty state tree S2, saving state tree S1. The full node continues to save the state tree S0, the light node discards the state tree S0.

1. Any user sends a transaction to interact with the intelligent contract C1 with the address of (0,0xabcdef), and all nodes are processed in the same way as in the period 1;

2. any user sending a transaction interacts with smart contract C2 with address (0,0x 123456):

1) if the out-block node is a full node, it is found that there is no state data with a key of 0x6d7e8f in the state tree S2, and then it is looked up in the history state tree, and the state data with a key of 0x6d7e8f is found in S0. The full node generates a proof for the transaction

I.e., the attestation key 0x6d7e8f is present in the state tree S0 and absent in the state tree S1, the attestation and transaction bindings are packaged together into a block. According to the account access and modification rule 4, child nodes and storage slots are created at the 0x6d7e8f position of the state tree S2, the state data after the transaction is executed is stored at the position, the accumulator vectors and the accumulator values of the child nodes at which 6d, 7e and 8f are located in the state tree S2 are updated, and the operation of other nodes is similar to the fifth step in the period 1;

2) if the out-block node is a light node, and it is found that there is no state data with a key of 0x6d7e8f in both the state trees S2 and S1, the proof of the state data is requested from the full node, and the processing of the full node is the same as the previous step. After the node is proved, the transaction is verified and executed, and the subsequent operation is the same as that of the whole node in the previous step.

Thereafter, during this period, any user sent transactions to interact with the smart contract C2, the chunking node modifies the data according to the account access and modification rules 5 directly at the 0x3a4b5C location and corresponding storage slot of the state tree S1. The same operation is performed after the transaction of other sync blocks.

3. Wang five uses a (0,0x456789) address to send the transaction:

1) if the out-block node is a full node, no state data with a key of 0xa1b2c3 (assuming hash (0,0x456789) ═ 0xa1b2c3) is found in the state tree S2, and then no state data with a key of 0xa1b2c3 is found in the history state tree. The full node generates a proof for the transaction

I.e., the attestation key 0xa1b2c3 is not present in the state trees S0 and S1, the attestation is packaged with the transaction bindings into blocks. According to the account access and modification rule 3, child nodes and storage slots are created at the 0xa1b2c3 position of the state tree S2, the state data after the transaction is executed is stored at the position, the accumulator vectors and the accumulator values of the child nodes where a1, b2 and c3 are located in the state tree S2 are updated, and the operation of other nodes is similar to the fifth step in the period 1;

2) if the out-block node is a light node, and it is found that there is no state data with a key of 0xa1b2c3 in both the state trees S2 and S1, the proof of the state data is requested from the full node, and the processing of the full node is the same as the previous step. After the node is proved, the transaction is verified and executed, and the subsequent operation is the same as that of the whole node in the previous step.

Thereafter, during this period, wang five uses the address to send a transaction, and the chunking node modifies the data directly at the 0xa1b2c3 location and corresponding storage slot of the state tree S2 according to account access and modification rules 5. The same operation is performed after the transaction of other sync blocks.

The block chain state data processing method can better permanently solve the storage pressure brought to all nodes by the explosion increase of the block chain state, and can not bring any experience difference to common users. The verifier role of completely not needing to store the state of the block chain can be introduced, so that more people participate in the verification of the blocks and the transaction, and the safety of the block chain system is improved. The existence of the light nodes enables the transaction and the block output to be processed more efficiently, because the computing resources are not required to be wasted in modifying a huge state tree, and the full nodes can also adopt some strategies to store the expired state which is not accessed for a long time in a hard disk and call the expired state out when needed.

Fig. 5 is a schematic structural diagram of a block chain state data processing apparatus according to an embodiment of the present application. The block chain state data processing apparatus 500 may be implemented by software, hardware or a combination of both.

As shown in fig. 5, the block chain state data processing apparatus 500 includes:

a processing module 502 for each epoch e_nAt the beginning, a create and epoch e_nCorresponding state tree S_n；

An obtaining module 501, configured to obtain status data, where the status data includes: an epoch identifier and information necessary for the blockchain node to process incoming blocks and/or received traffic events;

the processing module 502 is further configured to store the state data into the state tree S according to the time identifier and the preset requirement_nIn order to facilitate the calling of state data when the block chain node processes each service;

In one possible design, the processing module 502 is further configured to determine, at the beginning of each epoch, if there is a first historic state tree S of a previous epoch in the blockchain node_n-1Then the first History State Tree S is saved and frozen_n-1。

When the block chain node is a light node, at least storing in the light node: state tree S_nAnd a first history state tree S_n-1And is combined withAt the current time period e_nAt the beginning, the second history state tree S which does not meet the preset storage requirement is deleted_m。

In one possible design, the obtaining module 501 is configured to:

In one possible design, the address to which the state data corresponds includes: the epoch id and address code, correspondingly, the processing module 502, is configured to:

In one possible design, the processing module 502 is configured to:

In one possible design, the processing module 502 is further configured to:

In one possible design, the processing module 502 is configured to:

In one possible design, the processing module 502 is further configured to:

In one possible design, the processing module 502 is configured to:

It should be noted that the apparatus provided in the embodiment shown in fig. 5 can execute the method provided in any of the above method embodiments, and the specific implementation principle, technical features, term explanation and technical effects thereof are similar and will not be described herein again.

Fig. 6 is a schematic structural diagram of an electronic device according to an embodiment of the present application. As shown in fig. 6, the electronic device 600 may include: at least one processor 601 and memory 602. Fig. 6 shows an electronic device as an example of a processor.

A memory 602 for storing programs. In particular, the program may include program code including computer operating instructions.

The memory 602 may comprise high-speed RAM memory, and may also include non-volatile memory (non-volatile memory), such as at least one disk memory.

The processor 601 is configured to execute computer-executable 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 (CPU), an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application.

Alternatively, the memory 602 may be separate or integrated with the processor 601. When the memory 602 is a device independent from the processor 601, the electronic device 600 may further include:

a bus 603 for connecting the processor 601 and the memory 602. The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended ISA (EISA) bus, or the like. Buses may be classified as address buses, data buses, control buses, etc., but do not represent only one bus or type of bus.

Alternatively, in a specific implementation, if the memory 602 and the processor 601 are integrated into a single chip, the memory 602 and the processor 601 may communicate via an internal interface.

An embodiment of the present application further provides a computer-readable storage medium, where the computer-readable storage medium may include: various media that can store program codes, such as a usb disk, a removable hard disk, a read-only memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and in particular, the computer-readable storage medium stores program instructions for the methods in the above method embodiments.

An embodiment of the present application further provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the computer program implements the method in the foregoing method embodiments.

Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.

It will be understood that the present application is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims

1. A method for processing block chain state data, which is applied to a block chain node, the method comprises:

at each time period e_nAt the beginning, creating the epoch_nCorresponding state tree S_n；

Obtaining status data, the status data comprising: an epoch identifier and information necessary for the blockchain node to process incoming blocks and/or received traffic events;

storing the state data into the state tree S according to the period identifier and a preset requirement_nSo that the block chain node calls the state data when processing each service;

wherein the preset requirements include: each of said periods e_nThe status data generated in the memory can only be stored until the period e_nCorrespond toSaid state tree S of_nIn (1).

2. A block chaining state data processing method according to claim 1, further comprising: at the beginning of each of said periods, if there is a first historical state tree S of the previous period in said blockchain nodes_n-1Then the first History State Tree S is saved and frozen_n-1。

3. A block chain state data processing method according to claim 2, wherein when the block chain node is a full node, each time period e is held in the full node_nCorresponding state tree S_n；

When the block chain node is a light node, at least storing in the light node: the state tree S_nAnd the first history state tree S_n-1And at the current time period e_nAt the beginning, the second history state tree S which does not meet the preset storage requirement is deleted_m。

4. A block chaining state data processing method according to claim 3, wherein said preset storage requirements comprise: the second historical state tree S_mCorresponding historical period e_mWith the current said period e_nIs less than a preset interval.

5. A block chain state data processing method according to claim 3, wherein a preset number of consecutive said time periods e can be saved in said light node_nAll the corresponding state trees S_nThe preset number is greater than or equal to 2.

6. A block chaining status data processing method according to any one of claims 1 to 5, wherein said obtaining status data comprises:

acquiring a block sent by a block node, and determining the state data according to the block;

7. The method according to claim 6, wherein the address corresponding to the status data comprises: the time period identification and the address code are used for storing the state data into the state tree S according to the time period identification and the preset requirement_nIn, comprising:

when the storage path exists, storing the state data into the current state tree S according to the storage path_nowPerforming the following steps;

when the storage path does not exist, judging whether the time period identification meets the certification-free requirement or not;

if the proof-exempting requirement is met, the current state tree S is set_nowAccording to the address code, the corresponding storage path is established;

8. The method according to claim 7, wherein said determining whether the certification-free requirement is satisfied according to the epoch identifier comprises:

judging whether any one of the blockchain nodes of the blockchain network stores the state tree S corresponding to the time period identifier or not₀。

9. The method of block chaining status data processing according to claim 7, wherein said determining whether said epoch identifier satisfies a certification exemption requirement comprises:

determining the first period e₀Whether or not in the current epoch e_nowWithin a predetermined time period before, whatThe first period e₀Corresponding to the epoch id.

10. A block chaining state data processing method according to claim 9, wherein said time range comprises: k cycles of each of the periods e_nFor a length of time, k is greater than or equal to 1.

11. The method of block chaining status data processing according to claim 7, further comprising, after said determining whether said epoch identifier satisfies a credential exemption requirement:

if the certification-free requirement is not met, judging whether the state data exist on a historical state tree corresponding to each historical period according to the address;

if the state data does not exist in the historical state trees, generating first certification information by using a preset verification model, and when the block chain node is a block outlet node, adding the first certification information into the block corresponding to the state data, and sending the block to a block chain network for consensus, wherein the first certification information is used for representing that the state data is not in each historical state tree;

and in the current state tree S_nowCreating said storage path according to said address code, storing said state data into said current state tree S according to said storage path_nowIn (1).

12. The method according to claim 11, wherein said determining whether the state data exists in a history state tree corresponding to each history period according to the address comprises:

judging whether the state data exists on a target history state tree corresponding to each target history period according to the address code, wherein the target history period comprises the following steps: identifying a corresponding first epoch e from said epochs₀Beginning each of said historical time periods;

wherein, the purpose isThe nominal historical state tree does not include the respective light node state trees already stored on the light nodes, the light node state trees including at least: the state tree S of the current epoch_nAnd a first history state tree S of a period preceding said current period_n-1。

13. A block chaining status data processing method as claimed in claim 12, wherein said target history period does not include: the current period e_nowAnd the current epoch e_nowPrevious epoch e of_now-1。

14. The method according to claim 11, wherein after determining whether the state data exists in the target history state tree corresponding to each target history period according to the address code, the method further comprises:

if the block chain node exists, generating second certification information by using the preset verification model, and when the block chain node is the block outlet node, adding the second certification information to the block corresponding to the state data, and sending the block to a block chain network for consensus, wherein the second certification information is used for representing: a second state tree S corresponding to the last time the state data is modified₁And at the last modification epoch₁None of the subsequent historical state trees have the state data, the last modification period and the second state tree S₁Corresponding;

15. A method as claimed in claim 1, wherein said state data is stored in said state tree S according to said epoch id and a predetermined requirement_nAfter, still include:

16. A block chaining state data processing method according to claim 1, wherein said each time period e_nAt the beginning, creating the epoch_nCorresponding state tree S_nThe method comprises the following steps:

will last epoch e_n-1Corresponding first History State Tree S_n-1And after deleting the nodes with the access frequency less than the preset threshold value, obtaining the state tree S_n。