CN116049170A

CN116049170A - Block chain state storage and verification method and block chain link point

Info

Publication number: CN116049170A
Application number: CN202211522131.7A
Authority: CN
Inventors: 何家华; 刘谦; 蒋志勇
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2022-11-30
Filing date: 2022-11-30
Publication date: 2023-05-02

Abstract

A method for storing and verifying a state of a blockchain and a blockchain node are provided, wherein target state data to be stored is state data of a first parameter in the blockchain. The storage method comprises the following steps: a first state tree and a first merck tree corresponding to a last block are obtained from a block chain, wherein the first merck tree comprises a plurality of first state data of a first parameter, and the first state tree comprises a first root hash value of the first merck tree. Based on the target state data, the first merck tree is updated to obtain a second merck tree, the second merck tree including a second root hash value. And updating the first state tree based on the second root hash value to obtain a second state tree. A second state tree and a second merck tree are stored in association with the current block.

Description

Block chain state storage and verification method and block chain link point

Technical Field

The embodiment of the specification belongs to the technical field of block chains, and particularly relates to a block chain state storage and verification method and a block chain node.

Background

Blockchain (Blockchain) is a new application mode of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanisms, encryption algorithms, and the like. In the block chain system, the data blocks are combined into a chain data structure in a sequential connection mode according to the time sequence, and the distributed account book which is not tamperable and counterfeit and is ensured in a cryptographic mode is formed. Because the blockchain has the characteristics of decentralization, non-tamperability of information, autonomy and the like, the blockchain is also receiving more and more attention and application. In blockchain systems, the full nodes are typically used as the smallest facility to participate in the consensus, and the full nodes need to include the full amount of data to support the consensus function.

Disclosure of Invention

The invention aims to provide a storage and verification method of a blockchain state and a blockchain node, which can realize verification on fine-granularity data.

The first aspect of the present disclosure provides a method for storing a state of a blockchain, performed by a blockchain link point, wherein target state data to be stored is state data of a first parameter in the blockchain; the method comprises the following steps:

acquiring a first state tree and a first merck tree corresponding to a previous block from a block chain, wherein the first merck tree comprises a plurality of first state data of a first parameter, and the first state tree comprises a first root hash value of the first merck tree;

updating the first merck tree based on the target state data to obtain a second merck tree, wherein the second merck tree comprises a second root hash value;

updating the first state tree based on the second root hash value to obtain a second state tree;

the second state tree and the second merck tree are stored in association with a current block.

The second aspect of the present disclosure provides a method for verifying a blockchain status, where target status data to be verified is status data of a first parameter corresponding to a first block, the method including:

Acquiring first proving data, wherein the first proving data is determined based on the state tree and the position of the root hash value of the merck tree corresponding to the first block; a plurality of state data of the first parameter are included in the merck tree;

obtaining second attestation data, the second attestation data being determined based on the merck tree, and the location of the target state data;

and verifying the existence certification of the target state data based on the first certification data, the second certification data and the block head of the first block acquired in advance.

A third aspect of the present specification provides a blockchain node for storing target state data, the target state data being state data of a first parameter in the blockchain; the block link points include:

the acquisition unit is used for acquiring a first state tree and a first merck tree corresponding to a previous block from a block chain, wherein the first merck tree comprises a plurality of first state data of a first parameter, and the first state tree comprises a first root hash value of the first merck tree;

the updating unit is used for updating the first merck tree based on the target state data to obtain a second merck tree, wherein the second merck tree comprises a second root hash value;

The updating unit is further configured to update the first state tree based on the second root hash value to obtain a second state tree;

and a storage unit, configured to store the second state tree and the second merck tree in association with a current block.

A fourth aspect of the present disclosure provides a blockchain node for verifying target state data, where the target state data is state data of a first parameter corresponding to a first block; the block link points include:

an obtaining unit, configured to obtain first proof data, where the first proof data is determined based on the state tree and a location of a root hash value of a merck tree corresponding to the first block; a plurality of state data of the first parameter are included in the merck tree;

the acquisition unit is further configured to acquire second proof data, which is determined based on the merck tree and the location of the target state data;

and the verification unit is used for verifying the existence certification of the target state data based on the first certification data, the second certification data and the block head of the first block acquired in advance.

A fifth aspect of the present description provides a computer-readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the methods of the first and second aspects.

A sixth aspect of the present specification provides a consensus node comprising a memory and a processor, the memory having executable code stored therein, the processor implementing the methods of the first and second aspects when executing the executable code.

In the solution of the embodiment of the present disclosure, a merck tree is created for each block, where the merck tree includes a plurality of pre-coding state data (also referred to as plaintext state data) corresponding to a certain parameter in a blockchain. It should be appreciated that in conventional blockchain storage schemes, only encoded state data is typically stored, which is typically obtained by encoding a number of plaintext state data, and thus conventional schemes can only verify against coarse-grained data. The merck tree is created for the state data before encoding, so that verification for fine granularity data can be realized.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings that are needed in the description of the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments described in the present disclosure, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 illustrates a block chain architecture diagram in one embodiment;

FIG. 2 is a schematic diagram of a consensus process in a PBFT consensus algorithm;

FIG. 3 is a schematic diagram of a block chain data store for a consensus node in the related art;

FIG. 4 is a schematic diagram of the structure of an MPT tree;

FIG. 5 illustrates a flow chart of a method of constructing a binary merck tree for application layer data;

FIG. 6a is a schematic diagram of a k-ary tree and a binary tree in an embodiment of the present disclosure;

FIG. 6b is a schematic diagram of a binary Merck tree in an embodiment of the present disclosure;

FIG. 7 is a flow chart of a method of storing blockchain status in an embodiment of the present disclosure;

FIG. 8 is a schematic diagram of a first state tree and a first merck tree in an embodiment of the present disclosure;

FIG. 9 is a flowchart of a method of verifying blockchain status in an embodiment of the present description;

FIG. 10 is a block link point structure diagram in one embodiment of the present disclosure;

fig. 11 is a block chain node structure diagram in another embodiment of the present disclosure.

Detailed Description

In order to make the technical solutions in the present specification better understood by those skilled in the art, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only some embodiments of the present specification, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are intended to be within the scope of the present disclosure.

FIG. 1 illustrates a block chain architecture diagram in one embodiment. In the blockchain architecture diagram shown in fig. 1, the blockchain 100 includes N nodes, and nodes 1-8 are schematically shown in fig. 1. The connections between nodes schematically represent P2P (Peer to Peer) connections, which may be TCP connections or the like, for example, for transmitting data between nodes.

Transactions in the blockchain domain may refer to task units that execute in the blockchain and are recorded in the blockchain. The transaction typically includes a send field (From), a receive field (To), and a Data field (Data). Where the transaction is a transfer transaction, the From field indicates an account address From which the transaction was initiated (i.e., a transfer task To another account was initiated), the To field indicates an account address From which the transaction was received (i.e., a transfer was received), and the Data field includes the transfer amount.

The functionality of the smart contract may be provided in the blockchain. Intelligent contracts on blockchains are contracts on blockchain systems that can be executed by transaction triggers. The smart contracts may be defined in the form of codes. Invoking the smart contract in the blockchain initiates a transaction directed to the smart contract address such that each node in the blockchain runs the smart contract code in a distributed manner.

In the scenario of deploying contracts, for example, bob sends a transaction containing information to create an intelligent contract (i.e., deploying a contract) into a blockchain as shown in fig. 1, the data field of the transaction includes the code (e.g., bytecode or machine code) of the contract to be created, and the to field of the transaction is empty to indicate that the transaction is for deploying the contract. After agreement is reached between the nodes through a consensus mechanism, a contract address of '0 x6f8ae93 …' of the contract is determined, each node adds a contract account corresponding to the contract address of the intelligent contract in a state database, allocates a state storage corresponding to the contract account, stores a contract code, and stores a hash value of the contract code in the state storage of the contract, so that the contract creation is successful.

In the scenario of invoking a contract, for example, bob sends a transaction for invoking a smart contract into the blockchain as shown in fig. 1, the from field of the transaction is the address of the account of the transaction initiator (i.e., bob), the to field is the aforementioned "0x6f8ae93 …", i.e., the address of the invoked smart contract, and the data field of the transaction includes the method and parameters for invoking the smart contract. After the transaction is consensus in the blockchain, each node in the blockchain may execute the transaction separately, thereby executing the contract separately, updating the status database based on execution of the contract.

The consensus mechanism in the blockchain is a mechanism that the blockchain node achieves the full-network consensus on the blockinformation (or blockdata), and can ensure that the latest block is accurately added to the blockchain. The consensus mechanisms of the current mainstream include: proof of Work (POW), proof of equity (POS), proof of commission (Delegated Proof of Stake, DPOS), practical bayer fault tolerance (Practical Byzantine Fault Tolerance, PBFT) algorithms, and the like. Wherein in various consensus algorithms, the success of consensus for a consensus proposal is determined, typically after a preset number of consensus nodes agree on the data to be consensus (i.e. the consensus proposal). Specifically, in the PBFT algorithm, f malicious nodes can be tolerated for N.gtoreq.3f+1 consensus nodes, that is, when 2f+1 nodes in the N consensus nodes agree, success of the consensus can be determined. In the related art, in order to implement the consensus function, a full amount of ledgers, that is, states of all blocks and all accounts are stored on the consensus node. Thus, each node in the blockchain may generate the same state in the blockchain by performing the same transaction such that each node in the blockchain stores the same database of states.

Fig. 2 is a schematic diagram of a consensus process in a PBFT consensus algorithm. As shown in fig. 2, according to the PBFT consensus algorithm, the consensus process can be divided into four phases, request, prepare and Commit. Assuming that a blockchain includes four consensus nodes of node n 1-node n4, wherein node n1 is, for example, a master node, and node n 2-node n4 is, for example, a slave node, f=1 malicious nodes can be tolerated in node n 1-node n4 according to the PBFT algorithm. Specifically, during the request phase, a user of the blockchain may send a request, for example in the form of a blockchain transaction, to node n1 through his user device. In the preliminary stage, the node n1 may package a plurality of transactions into a consensus proposal after receiving the plurality of transactions from one or more user devices, and send the consensus proposal and a signature of the consensus proposal by the node n1 to other consensus nodes (i.e. nodes n 2-n 4) for generating blocks, where the consensus proposal may include information such as a transaction body of the plurality of transactions and a submitting sequence of the plurality of transactions. In the preparation phase, each slave node may sign the consensus proposal and send it to the other individual nodes. Assuming node n4 is a malicious node, nodes n1, n2, and n3, after each receiving the signatures of 2 f=2 other consensus nodes for the consensus proposal, may determine that the preparation phase is complete, and may enter the commit phase. For example, as shown in fig. 2, after receiving the signatures of node n2 and node n3, node n1 verifies that both the signatures of node n2 and node n3 are correct signatures of the consensus proposal, and then determines that the preparation phase is complete, and node n2 determines that the preparation phase is complete after receiving the signature of node n3 and the signature of preparation phase node n1 and verifying passed. In the submitting stage, each consensus node performs signature of the submitting stage on the consensus proposal and sends the signature to other consensus nodes, and each consensus node can determine that the submitting stage is completed and the consensus is successful after receiving the signatures of the submitting stages of 2 f=2 other consensus nodes. For example, the node N1 may determine that the commit phase is completed after receiving the signatures of the commit phases of the nodes N2 and N3 and verifying, so that the node N1 may execute the plurality of transactions according to the consensus proposal, generate and store a block (e.g., block N) including the plurality of transactions, update the world state according to the execution results of the plurality of transactions, and return the execution results of the plurality of transactions to the user device. Similarly, after determining that the commit phase is completed, node N2 and node N3 execute the plurality of transactions, update the world state based on the execution results of the plurality of transactions, and generate and store block N. Through the above process, the storage consistency of the node n1, the node n2 and the node n3 is realized. That is, the nodes n 1-n 4 can still realize successful consensus of the consensus proposal in the presence of a malicious node, and complete execution of the block.

FIG. 3 is a schematic diagram of a block chain data store for a consensus node in the related art. In the blockchain data store shown in fig. 3, the blockhead of each block includes several fields, such as a block Hash previous_hash (PrevHash in the figure), a Nonce (in some blockchain systems this Nonce is not a Nonce or in some blockchain systems the Nonce in the blockhead is not enabled), a Timestamp, a BlockNum, a State Root Hash state_root, a Transaction Root hash_root, a Receipt Root Hash record_root, etc. The PrevHash in the header of the next block (e.g., block n+1) points to the previous block (e.g., block N), which is the block hash value of the previous block (i.e., the hash value of the header). In this way, the lock of the next block to the previous block is achieved by the block header on the blockchain. In particular, as previously described, state_root is the hash value of the root of the state tree (state trie) of the state composition of all accounts in the current block, such as the MPT tree (Merkle Patricia Tree).

The MPT Tree is a Tree structure combining Merkle Tree and Patricia Tree (compressed prefix Tree, a more space-saving Trie Tree, dictionary Tree). The Merkle Tree algorithm computes a Hash value for each leaf node, then the Hash is computed again for every two connections, up to the top-most Merkle root. An improved MPT tree is employed in the ethernet tree, for example, a 16-ary tree structure.

The state tree contains key value pairs (key and value pair) of the stored content corresponding to each account in the ethernet network. The "key" in the state tree may be a 160-bit identifier (address of the ethernet account) with the characters contained in this account address being distributed among the nodes in the path from the root node to the leaf node of the state tree. Referring to FIG. 3, the leaf nodes (e.g., node t4 and node t 5) of the MPT state tree also include values for the respective accounts. When the account is a user account (also called an external account), for example, account a in fig. 3, the Value of the account includes a counter (Nonce) and a Balance (Balance). When the account is a contract account, such as account B in fig. 3, the Value of the account includes a counter (Nonce), a Balance (Balance), a contract code hash Value (CodeHash), and a Storage root hash Value (storage_root). Wherein the counter represents, for an external account, the number of transactions sent from the account address; for a contract account, it is the number of contracts that the account is created.

Nodes in the state tree are connected through a hash, specifically, a hash value may be generated based on data in child nodes of a parent node, and the generated hash value may be stored in the parent node. Fig. 4 is a schematic diagram of the structure of the MPT tree. Assume that the node labeled "t2" in fig. 4 corresponds to node t2 in the state tree in fig. 3, and the node labeled "t4" corresponds to leaf node t4 in the state tree in fig. 3. As shown in fig. 4, states included in each leaf node in fig. 4 are represented as state1, state2, state3, and state4, respectively, and each state is a Value of each account. Characters in the left boxes of the nodes in fig. 4 are used for indexing accounts, and characters included in the nodes in the path between the leaf node and the root node are spliced to obtain account addresses corresponding to the leaf node. For example, each node between the leaf node to the root node where state1 is located includes characters "f", "5", and "324", so that the account address corresponding to state1 can be obtained as "f5324".

In fig. 4, a leaf node is included in a child node of a node including "5", and when a hash (324,74) included in the node is calculated, it can be calculated by the following formula (1):

hash(324,74)＝hash(hash(324,hash(state1)),hash(74,hash(a,c))) (1)

that is, when the hash value hash (324, hash (state 1)) of the leaf node t4 in fig. 4 is calculated, the hash value hash (state 1) of "324" and state1 in the node t4 is spliced, and then the hash value of the leaf node is calculated on the spliced data, the hash value hash (74, hash (a, c)) of the non-leaf node (e.g., the node including "74") in fig. 4 is calculated, the data in the node is directly spliced, and then the hash value of the spliced data is calculated.

Thus, the hash value included in each node between the leaf node and the root node can be calculated from bottom to top in the state tree, so that the calculated hash value of the node t2 in fig. 3 can be spliced with the hash value of the node t3, and the spliced data is hashed, so that the hash value of the node t1 is generated. The hash value of the node t1 is the State Root of the State tree, and is recorded in the state_root field of the block N.

In one variation of the MPT tree, a branch node may be included, which may connect a plurality of child nodes, and the hash value of the data in each child node to which it is connected is included in the branch node, that is, a plurality of hash values respectively corresponding to a plurality of main nodes are included in the branch node, and a leaf node is connected after the branch node. The modification also includes an extension node, which may be connected before or after the branch node, the extension node having one child node, the extension node including hash values of all data in the child nodes connected thereto. In this MPT tree variant, the hash value of the root node may likewise be recursively derived based on the level nodes. The embodiments of the present description are equally applicable to such MPT tree variants.

After the intelligent contracts are deployed on the blockchain, a corresponding contract account is generated. This contract account will typically have states that are defined by state variables in the smart contract and that generate new values when the smart contract is created and executed. As shown in fig. 3, the relevant states of the contracts are stored in a storage tree (storage trie), and the storage tree of the contract corresponding to account B is schematically shown in fig. 3. The hash Value of the root node st1 is stored in the storage_root, so that all states of the contract are locked to the Value (namely the account state) of the contract account in the state tree through the root hash. The storage tree may also have an MPT tree structure, and similar to the state tree shown in fig. 4, each node in the path from the root node to the leaf node may include a character for addressing the variable name, with the Value of the variable stored in the leaf node, thereby storing a key-Value mapping of the variable name (which may also be referred to as a state address) to a state Value. For example, referring to the storage tree in fig. 3, the leaf nodes st2, st3 of the storage tree include, for example, value of variable a, value of variable b, etc., taking variable a as an example, the characters included by each node in the node path from the root node to leaf node st2 in the storage tree constitute the variable name of variable a, which may be similarly composed of 16-ary characters.

Wherein, the calculation of the hash value of each node in the storage tree can refer to the hash value calculation method of the node in the state tree. Specifically, when the hash value of a leaf node in a storage tree is calculated, the hash value of a state in the leaf node and a part of key included in the leaf node are spliced, and then the hash value is calculated on spliced data, so that the hash value of the leaf node is obtained. When the hash value of the node which is not a leaf node and is not a root node in the storage tree is calculated, the data in the node is directly spliced, and then the hash value is calculated on the spliced data, so that the hash value of the node is obtained.

As can be seen from the foregoing, the storage tree is a subtree of the state tree, that is, the state tree includes the storage tree, and thus the state tree and the storage tree will not be distinguished in the following description of the present specification, but will be collectively referred to as the state tree.

As described above, the storage content of each leaf node in the state tree is a key pair, which is also referred to as state data of the system layer (hereinafter referred to as system layer data). Some of the key-value pairs in the state tree correspond to state data of an application layer (hereinafter referred to as application layer data), for example, by encoding a number of application layer data. It should be appreciated that verification of system level data may be implemented based on a state tree, however, in most cases there will typically be a need to verify application level data, or to prove the presence of application level data. For example, for a management contract for a data asset, it is possible to store a key-value pair of a contract variable for the contract in a state tree, where the key (key) of the key-value pair corresponds to the variable name of the contract variable and the values (value) of the key-value pair store a plurality of assets in the form of an array. Often, it is not the key value pair that needs to be proven, but the existence of one of the assets. The "asset" herein may be referred to as application layer data. In addition, the service contract may have a data existence certification protocol specific to itself according to the special service requirement of itself, and needs to generate certification by itself. Finally, one key pair in a state tree is often thousands of bytes in size, but one application layer data may be tens of bytes only, and one key pair may contain hundreds of thousands of application layer data, so that verification of how to provide fine-grained data is also a need to be considered.

Some schemes propose indirectly verifying application layer data by proving the existence of encoded data (i.e., key value pairs) corresponding to the application layer data through a state tree in the blockchain and decoding the data into plaintext data. However, this scheme has the following problems.

1. Verification of application layer data is based on a state tree storing system layer data, which can lead to tight coupling of two layers of storage structures, and is unfavorable for system upgrading and maintenance.

2. Even if the encoded data (i.e., system layer data) is proved to exist on the state tree, it cannot be directly proven that its corresponding application layer data also exists in the blockchain, and the bijectivity of the codec protocol must be formally proven.

3. Only the existence of coarse-grained data can be proved, the existence of fine-grained data cannot be proved, and the requirement and the scene of richer existence proving of a business layer cannot be supported.

Therefore, the proposal proposes that the merck tree (also called as an application layer merck tree) is constructed for the application layer data, the root hash value of the merck tree is anchored into the state tree, namely, a two-layer state tree is formed, and then the application layer data is verified safely, efficiently and credibly based on the two-layer state tree.

In one embodiment, the merck tree is a binary merck tree. The construction method of the binary merck tree is described below.

Fig. 5 shows a flow chart of a method of constructing a binary merck tree for application layer data, as shown in fig. 5, which may include the steps of:

in step S502, a k-ary tree pre-built for a plurality of application layer data is obtained, each node in the k-ary tree corresponding to one application layer data.

The application layer data may be, for example, an asset or a picture.

In one embodiment, the plurality of application layer data may be derived by performing transactions that create/invoke smart contracts. The k-tree may be specifically constructed based on an organization structure of a plurality of application layer data customized by a user based on contract variables (simply referred to as variables, hereinafter also referred to as parameters) in the smart contract. The variables here may be, for example, arrays, lists, or trees, etc.

It should be appreciated that since each node in the k-ary tree corresponds to one application layer data, it can also be expressed as: the k-tree includes a plurality of application layer data.

Step S504, converting the k-fork tree into a binary tree.

In one embodiment, the k-ary tree may be converted to a binary tree using any of the known conversion methods, such as the "left child right sibling" method, and the like.

In another embodiment, the converting the k-ary tree into a binary tree may include: the k-ary tree is complemented to a complete k-ary tree. The nodes of each layer in the complete k-tree are numbered in order from top to bottom. And sequentially storing all nodes in the complete k-fork tree as all array elements into a target array according to the number of the nodes. Based on the target array, a binary tree is constructed.

Fig. 6a is a schematic diagram of a k-ary tree and a binary tree in an embodiment of the present description. In fig. 6a, the k-ary tree is specifically a 4-ary tree, and the "key" in the k-ary tree is a node position, which can also be understood as the position of the application layer data in the k-ary tree. The "idx" in the binary tree is the node position, and is also the position of the application layer data in the binary tree.

Note that, the node positions of the k-tree and the node positions of the binary tree are in one-to-one correspondence. That is, for each position of the application layer data in the k-fork tree, its position in the binary tree can be determined.

Step S506, for the binary tree, calculating target hash values of nodes of each layer according to the sequence from bottom to top until reaching a root node; thus, a binary merck tree is obtained.

Wherein, the calculating the target hash value of each layer of nodes comprises: based on the application layer data corresponding to the nodes in the binary tree, calculating initial hash values corresponding to the nodes. And for the current node in the nodes, if the current node is a leaf node, the corresponding initial hash value is used as a target hash value of the current node. If the current node is a non-leaf node, the target hash value of the left child node, the target hash value of the right child node and the initial hash value of the current node are spliced and then hashed to obtain the target hash value of the current node. Thus, each target hash value corresponding to each node can be obtained.

Taking the binary tree shown in fig. 6a as an example, the corresponding binary merck tree may be as shown in fig. 6 b. In FIG. 6b, H0-H8 are each initial hash value for each node. H0 '-H8' is each target hash value corresponding to each node, and 'H ()' is hash operation.

As can be derived from the binary merck tree generation process described above, each node in the binary merck constructed by the embodiments of the present specification includes two hash values: an initial hash value and a target hash value. The root hash value of the binary merck tree described in this specification refers to a target hash value of a root node of the binary merck tree. For example, in FIG. 6b, the root hash value of the binary merck tree is: h0'.

Furthermore, since the binary merck tree is converted based on the k-ary tree, the binary merck tree includes a plurality of application layer data.

Thus, the merck tree corresponding to the application layer data defined based on one variable is obtained. It should be appreciated that when a user customizes multiple sets of application layer data in an intelligent contract based on multiple variables, a corresponding merck tree may be built based on each set of application layer data, and thus multiple merck trees may be built.

It should be understood that, in the embodiment of the present specification, the binary merck tree is not limited to be constructed, for example, a trigeminal merck tree may be constructed, which is not limited thereto. In addition, in the present embodiment, the construction of the binary merck tree is not limited to that shown in fig. 6a and 6 b. For example, it is also possible to construct a general merck tree in which a plurality of application layer data are generated as only leaf nodes in the merck tree. In this case, the hash value of a leaf node in the merck tree is the hash value of the data in that leaf node, and the hash value of a parent node in the merck tree is the hash value of the concatenated data of the hash values of child nodes of that parent node. The binary merck tree shown in fig. 6a and 6b has fewer tree nodes and occupies less memory than a typical merck tree.

It should be noted that, the merck tree described in this specification is in a one-to-one correspondence with the chunks, and the merck tree may be specifically constructed or updated when the chunks are generated. For a built merck tree, its root hash value may be anchored into the corresponding state tree to satisfy the non-tamper-resistance of the data in the blockchain. The specific anchoring method is described later.

In addition, the above-mentioned update is because in the embodiment of the present disclosure, the nodes of the merck tree can be shared among the blocks, in other words, after the merck tree is built for the current block, only the nodes that change in the merck tree need to be updated to obtain the merck tree corresponding to the next block. It should be appreciated that the update of the merck tree for the current block is based on the current newly generated state data, so that the update process can also be understood as a process of storing state data of parameters. This storage process is described below.

FIG. 7 is a flow chart of a method of storing blockchain status by blockchain points in an embodiment of the present description when generating a current block. As shown in fig. 7, the method may include the following steps.

Step S702, a first state tree and a first merck tree corresponding to a previous block are obtained from the blockchain, wherein the first merck tree includes a plurality of first state data of a first parameter, and the first state tree includes a first root hash value of the first merck tree.

The first state tree here may be in the form of a merck tree, which may in particular be obtained by transforming a mpt tree.

The first state data is the application layer data, and the first merck tree is constructed based on a plurality of application layer data of the first parameter. The specific construction method may refer to each method step in fig. 5, and the embodiments of the present disclosure are not repeated herein.

The first parameter is, for example, a variable a defined in a contract, in which case one node (e.g., a first node) corresponding to the variable a is included in the first state tree. The first parameter may be, for example, account a in the blockchain (including external accounts and contract accounts), in which case one node corresponding to account a is included in the first state tree. The following describes taking the first parameter as an example of a variable defined in a contract. It can be understood that, in the case where the first parameter is an account, the same processing may be performed on a plurality of status data included in the value of the account, which will not be described herein.

In one embodiment, the first root hash value of the first merck tree included in the first state tree may be understood as the first root hash value included in the first node. Specifically, the first root hash value is included in the value of the first node.

The first state tree and the first merck tree described above may be as shown in fig. 8 when the first root hash value is included in the first node. In fig. 8, the first-level state tree and the second-level state tree together constitute a first state tree. The value of the account B is stored in the first-layer state tree, the variable a defined in the intelligent contract corresponding to the account B is stored in the second-layer state tree, the variable a corresponds to the node st6 (i.e., the first node), and the node st6 includes the merkle_root (i.e., the first hash value) of the first merck tree. In fig. 8, it is assumed that the first merck tree is a binary merck tree, and that the nodes mst 0-mst 7 therein correspond to the nodes mst 0-mst 7 in fig. 6b, respectively.

In another embodiment, the first root hash value of the first merck tree is included in the first state tree, and the first root hash value is included in a second node, where the second node is a node associated with the first node. Specifically, the key of the second node may be, for example, a combination of an account address and prefix/suffix characters for defining the contract accounts of the plurality of first state data, where the value of the second node includes the first root hash value. In one example, the prefix/suffix character herein may be the variable name of variable a.

In summary, with both implementations described above, the first root hash value of the first merck tree may be anchored into the first state tree.

Step S704, based on the target state data to be stored, updates the first merck tree to obtain a second merck tree, where the second merck tree includes the second root hash value.

The target state data to be stored may be understood as updated first state data, which may be obtained by performing a transaction calling the smart contract in the current block. In the intelligent contract, a user customizes a plurality of application layer data through a first parameter.

The updating the first merck tree may include: based on the target state data, updating the hash value of the target node corresponding to the target state data in the first merck tree. Hash values for other nodes in the path from the target node to the root node of the first merck tree are updated bottom-up.

Specifically, referring to fig. 8, assuming that the target state data corresponds to the node mst4, the above-mentioned updating the hash value of the target node corresponding to the target state data in the first merck tree is to update two hash values included in the node mst 4. Specifically, both the initial hash value H4 and the target hash value H4' are updated to hash values of the target state data. The updated target hash value of the node mst4 is recorded as: h4'.

In addition, the above-mentioned updating of the hash value of each other node is to successively update the target hash value included in each of the node mst1 and the node mst0, where the updated target hash value of the node mst1 is recorded as: h1″ and the updated target hash value for node mst0 are noted as: h0″. Then H1 "=h (H3 '║ H1 ║ H4"), H0 "=h (H1" ║ H0 ║ H2'), where "H ()" is a hash operation and "║" is a concatenation operation, i.e., the front and rear two characters are concatenated.

It should be understood that after the update of the target hash value of the node mst0 is completed, the second merck tree is obtained, and the updated target hash value H0 "of the node mst0 is the second root hash value of the second merck tree.

In one case, the target state data may be one of the state data of the first parameter newly generated during execution of the contract, that is, a node corresponding to the target state data is not included in an existing merck tree (i.e., the first merck tree). In this case, a new node corresponding to the target state data may first be created in the k-ary tree, and a binary merck tree may be regenerated from the updated k-ary tree, resulting in a second merck tree.

Taking fig. 8 as an example, the regenerating binary merck tree specifically includes: creating a node mst9 (not shown in fig. 8) corresponding to a new node in the k-ary tree in the binary merck tree, calculating a hash value of the target state data, taking the calculated hash value as an initial hash value H9 and a target hash value H9' of the node mst9, respectively, and storing the two hash values in the node mst 9. Thereafter, each node associated with the tree path from node mst9 to node mst0 is updated. Specific updating methods may be referred to above, and will not be described here.

Step S706, based on the second root hash value, the first state tree is updated to obtain a second state tree.

The updating the first state tree may include: based on the second root hash value, updating the hash value of the target node corresponding to the first root hash value in the first state tree. Hash values for other nodes in the path from the target node to the root node of the state tree are updated bottom-up.

And when the first node comprises the first root hash value, updating the hash value of the target node corresponding to the first root hash value in the first state tree, namely replacing the first root hash value in the value of the first node with the second root hash value to obtain the updated value of the first node. And updating the hash value of each other node, namely splicing the hash value based on the updated value and the hash value included by the brother node of the first node, calculating the hash value, replacing the hash value of the father node of the first node by using the calculated hash value, and the like until reaching the root node of the first state tree, thereby obtaining the second state tree.

Specifically, referring to fig. 8, the merkle_root in the node st6 may be replaced with the second root hash value to obtain an updated value of the node st 6. Then, the hash value can be calculated after the hash value of the value updated by the node st6 and the hash value of the node st7 are spliced, the hash value of the node st4 is replaced by the calculated hash value, and the like until the node st1 is reached, so that an updated second-layer state tree is obtained.

Then, the storage_root in the node t5 is replaced by the updated hash value of the node st1, and the updated value of the node t5 is obtained. And updating the hash value of each node associated with the tree path from the node t5 to the node t1 in the first-layer state tree based on the updated value of the node t5 to obtain a second state tree.

And when the second node comprises the first root hash value, updating the hash value of the target node corresponding to the first root hash value in the first state tree, namely replacing the first root hash value in the value of the second node with the second root hash value. And updating the hash value of each other node, namely splicing the second root hash value with the hash value of the brother node of the second node, then calculating the hash value, replacing the hash value of the father node of the second node by the calculated hash value, and the like until reaching the root node of the first state tree, thereby obtaining the second state tree.

Step S708, a second state tree and a second merck tree are stored in association with the current block.

The storage method of the second state tree can refer to a traditional storage method.

For the second merck tree, taking the binary merck tree as shown in fig. 8 as an example, the corresponding storage method can be as follows:

The size of each node in the binary merck tree is fixed, i.e., includes two hash values. Since the binary merck tree can be considered a complete binary tree, the binary merck nodes of each level can be stored in turn using a "sequential store" approach. If the binary merck tree is deep and the underlying storage system is a "key-value" store, then the "sequentially stored" binary merck tree may be split according to a certain size, storing each fixed-size "chunk" in a "key-value". Since the node positions of the K-fork tree and the node positions of the binary merck tree are in one-to-one correspondence, and the binary merck tree can be used as a complete binary tree for 'sequential storage', the node positions of the K-fork tree are in one-to-one correspondence with hash values of specific positions of specific 'key-values' in the sequential storage.

The update of the state tree and the merck tree for the current block, or the storage of the target state data to be stored, is thus completed. Similarly, status data for other parameters may also be stored.

In summary, in this approach, multiple merck trees may be maintained for the same contract account, each for storing multiple sets of application layer data defined in the smart contracts created by the contract account.

In summary, the blockchain state storage method provided by the embodiment of the specification can realize the storage of application layer data, so that the generation of the existence evidence of the application layer data can be facilitated.

It should be appreciated that for the application layer data included in the merck tree, verification of presence certificates (e.g., SPV verification) may also be performed. Verification of presence certificates may be used to verify whether a data is present on a particular block, i.e. presence certificates of data, by simple means, with less traffic and computation.

In one embodiment, the user requests the block link point to generate the certification data of the target state data to be verified through the user equipment, and verifies the target state data based on the certification data.

In another embodiment, the target state data may be verified by the blockchain node.

The following describes a method of verifying a blockchain status performed by a blockchain point.

Fig. 9 is a flowchart of a method for verifying a blockchain status in an embodiment of the present disclosure, where the method is performed by a blockchain link point, and target status data to be verified may be application layer data of a first parameter corresponding to an arbitrary first block in the blockchain. As shown in fig. 9, the method may include the following steps.

In step S902, first proof data is obtained, where the first proof data is determined based on the state tree corresponding to the first chunk and the root hash value of the merck tree corresponding to the first chunk at the position of the state tree.

The merck tree herein may refer to the above, wherein a plurality of state data (i.e. application layer data) of the first parameter may be included, in other words, each node in the merck tree corresponds to one state data.

The first proof data may include hash values of a plurality of nodes associated with a tree path from a node corresponding to a root hash value of the merck tree to the root node in the state tree. The hash values of the plurality of nodes are used to participate in a subsequent verification process of the presence attestation of the first node.

Specifically, referring to fig. 8, for example, the node to be verified is the node mst4, and since the root hash value of the merck tree including the node mst4 is stored in the value of the variable a, the hash values of the plurality of nodes include the hash values of each of the node st7, the node st5, and the node st3 in the second-level state tree, the hash value of the sibling node of the node t5 in the first-level state tree, the hash value of the sibling node of the parent node of the node t5, and the like.

In step S904, second proof data is acquired, and the second proof data is determined based on the merck tree corresponding to the first block and the position of the target state data in the merck tree.

The second proof data may include hash values of a plurality of nodes associated with a tree path from a node corresponding to the target state data to the root node in the merck tree. The hash values of the plurality of nodes are used to participate in a subsequent verification process of presence attestation of nodes in the merck tree corresponding to the target state data.

Also taking the node to be verified as the node mst4 in fig. 8 as an example, the hash values of the plurality of nodes include: the target hash value for node mst3, the initial hash value for node mst1, the target hash value for node mst2, and the initial hash value for node mst 0.

It should be appreciated that the first attestation data and the second attestation data described above together constitute an attestation of the presence of the target state data, that is, in the present embodiment of the present specification, the attestation data of the application layer data includes two pieces of content.

Step S906, performing verification of presence certification on the target state data based on the first certification data, the second certification data, and the block header of the first block acquired in advance.

It should be appreciated that the root hash value of the state tree of the first chunk is stored in the chunk header of the first chunk herein.

The verification of the presence certificate may include verification of the following two aspects:

first, based on the first attestation data, the existence of a root hash value of the merck tree corresponding to the first chunk is attested. Specifically, a root hash value of the state tree is calculated based on hash values of other respective nodes in the tree path included in the first attestation data; the calculated root hash value is compared with the root hash value of the state tree stored in the block header to determine whether the root hash value of the merck tree is present in the state tree.

Specifically, referring to fig. 8, first, in the first-layer state tree, a hash value of a node st6 is calculated, and the hash value is calculated after the hash value is spliced with a hash value of a node st7, and then the calculated hash value is spliced with a hash value of a node st5, and then the hash value is calculated. And finally, splicing the recalculated hash value with the hash value of the node st3, and calculating the hash value to obtain a root hash value corresponding to the second-layer state tree.

Then, in the first-layer State tree, based on the calculated Root hash value corresponding to the second-layer State tree and the hash value of the sibling node of the node t5, calculating the hash value from bottom to top until the Root hash value of the first-layer State tree is calculated, namely obtaining the hash value of the node t1, and comparing the hash value of the node t1 with the state_root in the block header to determine whether the Root hash value of the merck tree exists in the State tree.

Second, presence of the target state data is certified based on the second certification data. Specifically, a root hash value of the merck tree is calculated based on hash values of other respective nodes in the tree path included in the second proof data; the calculated root hash value is compared to the root hash value of the merck tree that is looked up based on the location of the target state data to determine whether the target state data is present in the merck tree. In one example, the correspondence of the root hash value of the merck tree to the various state data in the merck tree may be recorded in a mapping table.

Specifically, referring to fig. 8, the target hash value of the node mt4 is calculated first, then the target hash value of the node mt4, the target hash value of the node mst3, and the initial hash value of the node mst1 are spliced, and then the hash value is calculated. Finally, the calculated hash value, the target hash value of the node mst2 and the initial hash value of the node mst0 are spliced, and then the hash value is calculated. The recalculated hash value is compared to the root hash value of the merck tree to determine whether the target state data is present in the merck tree.

It will be appreciated that after verification in both aspects passes, then verification of presence evidence for the target state data passes.

In summary, the method for verifying the blockchain state provided by the embodiments of the present disclosure decouples the presence of the application layer data from its storage structure in the state tree, so as to facilitate upgrading and maintenance. In addition, the root hash value of the merck tree uses simple direct encoding when anchored to the state tree, without formalizing the bijective of its codec protocol. Finally, the method for proving the existence of the application layer data in the scheme can be used for application layer data with any granularity, and is particularly beneficial to realizing the proving of the existence of the fine-granularity data.

In addition, the scheme innovates in the following aspects: business semantics are introduced for presence attestation so that application layer contracts can combine their business logic to provide presence attestation with semantics for their business data, rather than simple key-value pairs. The platform layer API enables the application layer to generate the customized data existence evidence of the service, the existing existence evidence is generally provided with a unified generation mechanism by the platform layer or the storage layer, the service contract can generate the customized existence evidence based on the service requirement of the service contract by enabling the platform layer API to generate the customized data existence evidence, and possibility is provided for innovative service scenes. Finally, the present solution can provide fine-grained data presence evidence, and existing presence evidence can only generally provide presence evidence of key value pairs, and the present solution increases fine-grained support, so that business contracts can prove the presence of fine-grained data such as monotonic assets.

Fig. 10 is a block link point structure diagram in one embodiment of the present disclosure. The block link point is used to store target state data, which is state data of a first parameter in the block chain. The blockchain node specifically implements storage of target state data by performing the method as shown in fig. 7, which includes:

the obtaining unit 1002 is configured to obtain, from a blockchain, a first state tree and a first merck tree corresponding to a previous block, where the first merck tree includes a plurality of first state data of a first parameter, and the first state tree includes a first root hash value of the first merck tree.

The updating unit 1004 is configured to update the first merck tree based on the target state data, to obtain a second merck tree, where the second merck tree includes a second root hash value.

The updating unit 1004 is further configured to update the first state tree based on the second root hash value, to obtain a second state tree.

A storage unit 1006 is configured to store a second state tree and a second merck tree in association with the current block.

Fig. 11 is a block chain node structure diagram in another embodiment of the present disclosure. The block link point is used for verifying target state data, wherein the target state data is state data of a first parameter corresponding to the first block. The blockchain node implements verification of the target state data by performing the method as shown in fig. 9, which includes:

The obtaining unit 1102 is configured to obtain first proof data, where the first proof data is determined based on a state tree and a location of a root hash value of a merck tree corresponding to the first block, and the merck tree includes a plurality of state data of the first parameter.

The obtaining unit 1102 is further configured to obtain second proof data, where the second proof data is determined based on the merck tree and the location of the target state data.

And a verification unit 1104 for verifying the presence certificate of the target state data based on the first certification data, the second certification data, and the block header of the first block acquired in advance.

The present description also provides a computer-readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method shown in fig. 5, 7 or 9.

The embodiment of the present disclosure further provides a blockchain node, including a memory and a processor, where the memory stores executable code, and the processor implements the method shown in fig. 5, fig. 7, or fig. 9 when executing the executable code.

In the 90 s of the 20 th century, improvements to one technology could clearly be distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable Gate Array, FPGA)) is an integrated circuit whose logic function is determined by the programming of the device by a user. A designer programs to "integrate" a digital system onto a PLD without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented by using "logic compiler" software, which is similar to the software compiler used in program development and writing, and the original code before the compiling is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but not just one of the hdds, but a plurality of kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), lava, lola, myHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog are currently most commonly used. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), programmable logic controllers, and embedded microcontrollers, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller in a pure computer readable program code, it is well possible to implement the same functionality by logically programming the method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Such a controller may thus be regarded as a kind of hardware component, and means for performing various functions included therein may also be regarded as structures within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.

The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation device is a server system. Of course, the present application does not exclude that as future computer technology evolves, the computer implementing the functions of the above-described embodiments may be, for example, a personal computer, a laptop computer, a car-mounted human-computer interaction device, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

Although one or more embodiments of the present description provide method operational steps as described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps recited in the embodiments is merely one way of performing the order of steps and does not represent a unique order of execution. When implemented in an actual device or end product, the instructions may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even in a distributed data processing environment) as illustrated by the embodiments or by the figures. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, it is not excluded that additional identical or equivalent elements may be present in a process, method, article, or apparatus that comprises a described element. For example, if first, second, etc. words are used to indicate a name, but not any particular order.

For convenience of description, the above devices are described as being functionally divided into various modules, respectively. Of course, when one or more of the present description is implemented, the functions of each module may be implemented in the same piece or pieces of software and/or hardware, or a module that implements the same function may be implemented by a plurality of sub-modules or a combination of sub-units, or the like. The above-described apparatus embodiments are merely illustrative, for example, the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

One skilled in the relevant art will recognize that one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Moreover, one or more embodiments of the present description can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

One or more embodiments of the present specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the present description may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments. In the description of the present specification, a description referring to terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present specification. In this specification, schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, the different embodiments or examples described in this specification and the features of the different embodiments or examples may be combined and combined by those skilled in the art without contradiction.

The foregoing is merely an example of one or more embodiments of the present specification and is not intended to limit the one or more embodiments of the present specification. Various modifications and alterations to one or more embodiments of this description will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, or the like, which is within the spirit and principles of the present specification, should be included in the scope of the claims.

Claims

1. A storage method of a block chain state is executed by a block chain link point, and target state data to be stored is state data of a first parameter in the block chain; the method comprises the following steps:

2. The method of claim 1, wherein the updating the first merck tree comprises:

updating a hash value of a first tree node corresponding to the target state data in the first merck tree based on the target state data;

hash values of other tree nodes in a path from the first tree node to a root node of the first merck tree are updated bottom-up.

3. The method of claim 1, wherein the updating the first state tree comprises:

updating the hash value of a second tree node corresponding to the first root hash value in the first state tree based on the second root hash value;

hash values of other respective tree nodes in a path from the second tree node to a root node of the state tree are updated bottom-up.

4. The method of claim 1, wherein the target state data corresponds to an asset or picture.

5. The method of claim 1, wherein the first merck tree is a binary merck tree; the binary merck tree is constructed by the following steps:

acquiring a k-fork tree pre-constructed for the plurality of first state data; each tree node in the k-tree corresponds to a first state data;

Converting the k-fork tree into a binary tree;

for the binary tree, calculating a target hash value of each layer of tree nodes according to the sequence from bottom to top until reaching a root node; the binary merck tree is thus obtained.

6. The method of claim 5, wherein the computing the target hash value for each level of tree nodes comprises:

calculating each initial hash value corresponding to each tree node based on each first state data corresponding to each tree node in the binary tree;

for the current node in each tree node, if the current node is a leaf node, the corresponding initial hash value is used as a target hash value of the current node;

if the current node is a non-leaf node, the target hash value of the left child node, the target hash value of the right child node and the initial hash value of the current node are spliced and then hashed to obtain the target hash value of the current node.

7. The method of claim 6, wherein the first root hash value is a target hash value of a root node of the binary merck tree.

8. The method of claim 5, wherein the converting the k-fork tree to a binary tree comprises:

the k-fork tree is complemented into a complete k-fork tree;

Numbering the tree nodes of each layer in the complete k-fork tree according to the sequence from top to bottom;

according to the number, each tree node in the complete k-tree is used as each array element and sequentially stored into a target array;

and constructing the binary tree based on the target array.

9. The method of claim 1, wherein the first state tree is a merck tree, the merck tree resulting from transforming a mpt tree.

10. A method for verifying a blockchain state, wherein target state data to be verified is state data of a first parameter corresponding to a first block, the method comprising:

acquiring first proving data, wherein the first proving data is determined based on a state tree corresponding to the first block and the position of a root hash value of a merck tree corresponding to the first block in the state tree; a plurality of state data of the first parameter are included in the merck tree;

obtaining second attestation data, the second attestation data determined based on the merck tree and a location of the target state data in the merck tree;

11. The method of claim 10, wherein the method is performed by a user device, the first attestation data and the second attestation data being obtained by the user device from the blockchain.

12. A blockchain node to store target state data, the target state data being state data of a first parameter in the blockchain; the block link points include:

13. A blockchain node for verifying target state data, wherein the target state data is state data of a first parameter corresponding to a first block; the block link points include:

An obtaining unit, configured to obtain first proof data, where the first proof data is determined based on a state tree corresponding to the first block and a position of a root hash value of a merck tree corresponding to the first block in the state tree; a plurality of state data of the first parameter are included in the merck tree;

the acquisition unit is further configured to acquire second proof data, which is determined based on the merck tree and a position of the target state data in the merck tree;

14. A computer readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method of any of claims 1-11.

15. A blockchain node comprising a memory having executable code stored therein and a processor that, when executing the executable code, implements the method of any of claims 1-11.