State data restoration method and apparatus for blockchain, computer device, and medium

Abstract

A state data restoration method for a blockchain, executed by a computer device that maintains a first node in a blockchain system. The method comprises: when a proposal message broadcast by a second node in the blockchain system is received, acquiring state data maintained by the first node itself, wherein the proposal message indicates a transaction task, result information for the transaction task, and a block identifier (302); executing the transaction task in the proposal message on the basis of the state data to obtain result information (304); when the result information obtained by executing the transaction task is inconsistent with the result information indicated in the proposal message, acquiring, from a snapshot of another node in the blockchain system, readset information corresponding to the block identifier in the proposal message, wherein the another node is a node in the blockchain system other than the first node (306); and restoring the state data on the basis of the readset information to obtain restored state data, wherein the restored state data is used for re-executing the transaction task to obtain an execution result (308).

Description

Blockchain state data repair method, device, computer equipment and medium

[0001] Related applications

[0002] This application claims priority to Chinese patent application number 2023108905491, filed on July 19, 2023, entitled “Blockchain state data repair method, device, computer equipment, and storage medium,” the entire text of which is hereby incorporated by reference. Technical Field

[0003] The present application relates to the field of computer technology, in particular to the field of blockchain technology, and more particularly to a method, apparatus, computer device, storage medium, and computer program product for repairing blockchain status data. Background Art

[0004] Blockchain is a new type of decentralized distributed ledger technology that can securely store transactions or other data. Its key feature is that information stored on the blockchain cannot be forged or tampered with. The blockchain consensus algorithm drives every node on the blockchain to participate in the transaction verification process, ensuring that transactions on the blockchain are confirmed and credible. To ensure the security of data and information, during the blockchain consensus process, nodes verify each transaction task in the proposal message. This means that nodes execute each transaction task included in the proposal message one by one. State data is used during the actual execution of transaction tasks. Although state data stored locally on nodes is typically stored in a database, this does not mean that database storage is problem-free. Some state data may be damaged due to special reasons, such as a power outage before data is fully written or damage to the disk corresponding to the file. Therefore, lost or damaged state data needs to be repaired.

[0005] However, the current state data repair method of the blockchain usually obtains the state data from an approved node and directly copies the state data of the node to the local computer. However, this processing requires manual intervention, that is, when the state data is lost or damaged, the above method requires manual participation. Since the damage of the state data is unpredictable, the data will continue to be unusable before manual intervention, making it impossible for the node to achieve the normal consensus process, or causing the consensus to be stuck. Alternatively, if the node verifies the various transaction tasks in the proposal message based on the lost or damaged state data, the verification result may also be wrong, which may cause the voting result generated by the node to be wrong, so that the nodes in the entire blockchain system cannot reach a consensus on the proposal message, which will have a huge impact on the consensus processing process of the entire blockchain, resulting in poor consensus processing efficiency of the blockchain.

[0006] Summary of the Invention

[0007] According to various embodiments of the present application, a blockchain consensus method, apparatus, computer device, computer-readable storage medium, and computer program product are provided.

[0008] In a first aspect, the present application provides a method for repairing state data of a blockchain, which is performed by a computer device maintaining a first node in a blockchain system, the method comprising:

[0009] Upon receiving a proposal message broadcasted by a second node in the blockchain system, obtaining state data maintained by the first node itself, wherein the proposal message indicates a transaction task, result information for the transaction task, and a block identifier;

[0010] Execute the transaction task in the proposal message based on the status data to obtain result information;

[0011] When the result information obtained by executing the transaction task is inconsistent with the result information indicated by the proposal message, obtaining read set information corresponding to the block identifier in the proposal message from snapshots of other nodes in the blockchain system, where the other nodes are nodes in the blockchain system other than the first node;

[0012] The state data is repaired based on the read set information to obtain repaired state data, and the repaired state data is used to re-execute the transaction task to obtain an execution result.

[0013] In a second aspect, the present application also provides a blockchain state data repair device. The device includes:

[0014] an acquisition module, configured to, upon receiving a proposal message broadcasted by a second node in the blockchain system, acquire state data maintained by the first node itself, wherein the proposal message indicates a transaction task, result information for the transaction task, and a block identifier;

[0015] an execution module, configured to execute the transaction task in the proposal message based on the status data and obtain result information;

[0016] The acquisition module is further configured to, when the result information obtained from executing the transaction task is inconsistent with the result information indicated by the proposal message, acquire read set information corresponding to the block identifier in the proposal message from snapshots of other nodes in the blockchain system, where the other nodes are nodes in the blockchain system other than the first node;

[0017] A repair module is used to repair the state data based on the read set information to obtain repaired state data, and the repaired state data is used to re-execute the transaction task to obtain an execution result.

[0018] In a third aspect, the present application also provides a computer device, comprising a memory and a processor, wherein the memory stores computer-readable instructions, and when the processor executes the computer-readable instructions, the state data repair method of the blockchain in the embodiment of the present application is implemented.

[0019] In a fourth aspect, the present application further provides a computer-readable storage medium having computer-readable instructions stored thereon, which, when executed by a processor, implement the blockchain state data repair method in the embodiments of the present application.

[0020] In a fifth aspect, the present application further provides a computer program product comprising computer-readable instructions that, when executed by a processor, implement the blockchain state data repair method in the embodiments of the present application.

[0021] The details of one or more embodiments of the present application are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the present application will become apparent from the description, drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the conventional technology, the following briefly introduces the drawings required for use in the embodiments or the conventional technology descriptions. Obviously, the drawings described below are merely embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the disclosed drawings without any creative work.

[0023] FIG1 is a schematic diagram of an optional structure of a distributed system applied to a blockchain system in one embodiment;

[0024] FIG2 is a schematic diagram of an optional block structure in one embodiment;

[0025] FIG3 is a schematic diagram of a flowchart of a method for repairing blockchain state data in one embodiment;

[0026] FIG4 is a schematic diagram of the overall process of state data repair in one embodiment;

[0027] FIG5 is a schematic diagram of the overall process of a method for repairing blockchain state data in one embodiment;

[0028] FIG6 is a schematic diagram of information carried by a proposal message in one embodiment;

[0029] FIG7 is a schematic diagram of obtaining a broadcast message and a response message of a read set in one embodiment;

[0030] FIG8 is a schematic diagram of using the HistoryDB database to repair data in a traditional manner in one embodiment;

[0031] FIG9 is a schematic diagram of two different methods of repairing data in a conventional manner according to an embodiment;

[0032] FIG10 is a schematic diagram of a transaction execution process in one embodiment;

[0033] FIG11 is a schematic diagram of other nodes generating read sets in one embodiment;

[0034] FIG12 is a block diagram of a state data repair device for a blockchain according to one embodiment;

[0035] FIG13 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0036] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0037] It should be noted that in the following description, the terms "first, second and third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first, second and third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0038] The system involved in the embodiment of the present invention may be a distributed system formed by connecting a client and multiple nodes (any form of computing devices in an access network, such as a server and a user terminal) through network communication.

[0039] Taking a distributed system as a blockchain system as an example, see Figure 1. Figure 1 is an optional structural diagram of a distributed system 100 provided by an embodiment of the present invention applied to a blockchain system. The distributed system 100 is composed of multiple nodes (any form of computing device connected to the network, such as a server or user terminal) and clients. The nodes form a peer-to-peer (P2P) network. The P2P protocol is an application layer protocol running on top of the Transmission Control Protocol (TCP). In a distributed system, any machine, such as a server or terminal, can join and become a node. Nodes include a hardware layer, an intermediate layer, an operating system layer, and an application layer.

[0040] Referring to Figure 1, the functions of each node in the blockchain system include:

[0041] 1) Routing: A basic function of a node, used to support communication between nodes.

[0042] In addition to the routing function, nodes can also have the following functions:

[0043] 2) Applications, deployed in the blockchain, implement specific services based on actual business needs, record data related to the implementation of functions to form record data, carry digital signatures in the record data to indicate the source of the task data, and send the record data to other nodes in the blockchain system for other nodes to add the record data to a temporary block when they successfully verify the source and integrity of the record data.

[0044] For example, the services implemented by the application include:

[0045] 2.1) Wallet: This provides functions for conducting electronic currency transactions, including initiating transactions (i.e., sending the transaction record of the current transaction to other nodes in the blockchain system. Upon successful verification by other nodes, the transaction record data is stored in a temporary block of the blockchain as a response to acknowledge the transaction validity). Of course, the wallet also supports querying the remaining electronic currency in the electronic currency address;

[0046] 2.2) Shared ledgers are used to store, query, and modify account data. Records of operations on account data are sent to other nodes in the blockchain system. After verification, other nodes acknowledge the validity of the account data by storing the recorded data in a temporary block. They can also send confirmation to the node that initiated the operation.

[0047] 2.3) Smart contracts are computerized protocols that can enforce the terms of a contract. They are implemented through code deployed on a shared ledger that is executed when certain conditions are met. Based on actual business needs, the code is used to complete automated transactions, such as querying the logistics status of a buyer's purchased goods and transferring the buyer's electronic currency to the merchant's address after the buyer signs for the goods. Of course, smart contracts are not limited to executing contracts for transactions, but can also execute contracts that process received information.

[0048] 3) Blockchain, including a series of blocks that are connected to each other in the order of their generation. Once a new block is added to the blockchain, it will not be removed. The block records the record data submitted by the nodes in the blockchain system.

[0049] See Figure 2, which is an optional schematic diagram of a block structure provided by an embodiment of the present invention. Each block includes the hash value of the transaction records stored in the block (the hash value of the current block) and the hash value of the previous block. The blocks are connected by hash values ​​to form a blockchain. In addition, the block may also include information such as the timestamp when the block was generated. Blockchain is essentially a decentralized database, a series of data blocks generated using cryptographic methods. Each data block contains relevant information used to verify the validity of the information (anti-counterfeiting) and generate the next block.

[0050] In one embodiment, as shown in FIG3 , a method for repairing state data of a blockchain is provided. This embodiment is described by taking the method as applied to the first node in the node cluster of the blockchain system in FIG1 as an example. The first node is maintained by a computer device, that is, the computer device implements the function of the first node. The method is executed by the computer device and includes the following steps:

[0051] In step 302, upon receiving a proposal message broadcasted by the second node in the blockchain system, the first node obtains the status data maintained by the first node itself, wherein the proposal message indicates a transaction task, result information for the transaction task, and a block identifier.

[0052] A blockchain is a chain of blocks. Each block contains information, and they are linked together in the order of their generation. The blockchain is stored on each node in the blockchain system. As long as at least one node in the blockchain system is functioning, the blockchain is secure. These nodes are maintained by computers, each of which performs the functions of one or more nodes, providing storage space and computing power for the entire blockchain system. The first and second nodes are nodes in the blockchain system's node cluster, and the first and second nodes are different nodes. To modify information in the blockchain, the consent of more than half of the nodes must be obtained and the information in all nodes must be modified. These nodes are often controlled by different entities, making tampering with information in the blockchain extremely difficult. Compared to traditional networks, blockchains have two core characteristics: data is difficult to tamper with, and they are decentralized. These two characteristics make the information recorded in blockchains more authentic and reliable, helping to address the problem of mutual trust. Blockchains can be divided into public, consortium, and private blockchains. The blockchain system in this application can be a consortium blockchain system.

[0053] The block identifier is an identifier used to uniquely identify a block. The transaction task in the proposal message refers to the transaction task obtained from the transaction pool when the master node constructs the block. In some cases, the transaction task in this application can also be referred to as a transaction. For example, the transaction task in this application can be the transaction task that the master node (i.e., the second node) screens from the transaction pool according to the processing priority corresponding to the transaction task contract from high to low.

[0054] Result information refers to the validation results obtained by the slave node for each transaction task in the proposal message. In some cases, result information can also be referred to as the validity verification result. For example, the result information in this application may include execution results and read-write sets. The execution result refers to the result returned by the contract corresponding to the transaction task.

[0055] After a newly created blockchain is started, when a new block is generated in the blockchain, the master node in the node cluster is responsible for generating a proposal message for the new block and broadcasting the proposal message so that each slave node can verify the proposal message and confirm whether the new block in the proposal message can reach a consensus. When the new block reaches a consensus, each node in the node cluster can add the new block to the local ledger, that is, store the new block. The consensus environment of the blockchain in this application can be a blockchain underlying model based on BFT consensus. Under the blockchain underlying model based on BFT consensus, there are usually master nodes and slave nodes. The master node is responsible for generating a proposal for a new block, which is verified by the slave nodes to confirm whether the block in the proposal can reach a consensus. Among them, BFT (Byzantine Fault Tolerance), that is, Byzantine Fault Tolerance, is a consensus mechanism.

[0056] The second node is the master node. The master node is the node in the node cluster responsible for generating proposal messages for new blocks. The master node can rotate within the node cluster. For example, in a blockchain model based on BFT consensus, suppose a blockchain system includes three nodes: Node 1, Node 2, and Node 3. When a new block is generated in this blockchain system, each node in the node cluster (Node 1, Node 2, and Node 3) can determine whether it is the master node. For example, each node in the node cluster can determine whether the block generation conditions are met based on the parameters in the block maintained by the first node. When a node (Node 1) determines that it meets the block generation conditions, it becomes the master node, i.e., the second node.

[0057] The first node is a slave node. Each slave node in the blockchain system can execute the blockchain status data repair method of the embodiment of the present application. When describing the blockchain status data repair method for one of the specific slave nodes, the first node is used to refer to the specific slave node.

[0058] A slave node is a node in a node cluster that is responsible for verifying proposal messages for new blocks. For example, in a blockchain underlying model based on BFT consensus, suppose a blockchain system includes three nodes, namely node 1, node 2, and node 3. At the current moment, the master node is node 2, then node 1 and node 3 are both slave nodes.

[0059] A proposal message is a communication message used when communicating between nodes in a blockchain. For example, a communication message may also include a consensus message, a voting message, etc. A proposal message in this application refers to a message that carries a proposal. For example, a proposal message indicates proposal 1, and proposal 1 is generated for the newly generated block 1.

[0060] State data refers to data generated during the execution of a transaction task. For example, the state data in this application may be key-value information generated during the execution of a transaction task. It is understood that in a blockchain system, each node maintains a local database that stores data generated during the execution of a transaction task. For example, each node may store state data in a state database and transaction task information, such as user-sent transaction information and block headers, in a block database.

[0061] Specifically, after a newly created blockchain is started, when a new block is generated in the blockchain and consensus is required, the master node (i.e., the second node) in the node cluster can grab a preset number of transaction tasks from the transaction pool, and encapsulate the captured transaction tasks into a proposal message for the new block, and broadcast the proposal message to the slave nodes in the blockchain, so that the slave nodes (including the first node) can reach consensus on the new block based on the transaction tasks in the proposal message. That is, the master node (second node) in this application can package a preset number of captured transaction tasks into a proposal, and broadcast the proposal to all slave nodes in the blockchain in the form of a message. When each slave node (including the first node) receives the proposal message, each slave node (including the first node) can verify all transaction tasks in the proposal message to obtain a verification result; when the verification result indicates that at least one transaction task among all transaction tasks in the proposal message is illegal, the slave node (including the first node) generates a voting message that disapproves of the new block consensus. At the same time, the slave node can receive voting messages broadcast by other nodes. When the number of voting messages in favor of the new block consensus in the voting message meets the preset conditions, the new block can reach a consensus, that is, the new block can be added to the blockchain, and each node of the blockchain system can also add the new block to the local ledger.

[0062] Among them, when the first node, which is a slave node, verifies the transaction task in the proposal message, the first node needs to obtain the status data maintained by the slave node itself locally, that is, when each slave node receives the proposal message broadcast by the master node (such as the second node), each slave node can obtain its own locally maintained status data. For example, when a slave node (such as the first node) in the node cluster receives the proposal message broadcast by the master node, the slave node (such as the first node) can obtain the status data from the status database maintained by the slave node (such as the first node) itself.

[0063] It can be understood that the state database in this application refers to a database used to store state data, that is, used to store Key-Value information generated during the execution of transaction tasks.

[0064] For example, in a blockchain underlying model based on a BFT consensus, after a newly created blockchain is started, when a new block is generated in the newly created blockchain, each node in the node cluster can determine whether it is a master node. For example, each node in the node cluster can determine whether the block generation conditions are met based on the parameters in the block maintained by the node itself; when a node determines that it meets the block generation conditions, the node becomes the master node. The block generation condition refers to the condition used to trigger the block generation. For example, the block generation condition in this application can be set to a height value greater than a preset threshold, and the preset threshold can be 1. The node that generates the block is qualified to encapsulate the transaction task into a proposal message for the block to be consensus.

[0065] Furthermore, after a node (node ​​1) in the node cluster determines itself as the master node, the master node generates a block and starts a new round of consensus. That is, the master node is responsible for generating proposals for the new block. The master node can grab a preset number of transaction tasks from the transaction pool, and encapsulate the captured transaction tasks into a proposal message 1 for the new block 1, and broadcast the proposal message 1 to the slave nodes in the blockchain, so that the slave nodes can reach a consensus on the new block 1 based on the transaction tasks in the proposal message 1; when a slave node in the node cluster (that is, the first node, such as node 2) receives the proposal message broadcast by the master node, the slave node can obtain status data from the local state database (StateDB) maintained by the slave node itself.

[0066] Step 304: Execute the transaction task in the proposal message based on the status data to obtain result information.

[0067] A read-write set refers to data generated during the execution of a transaction task. In some embodiments, the read-write set itself can be state data.

[0068] The block read-write set hash value is the MerkleRoot generated by the read-write sets of all transaction tasks contained in the block. The block read-write set hash value can also be called the block read-write set Hash or RWSetRoot.

[0069] Specifically, each slave node in the node cluster receives the proposal message broadcast by the second node. After the first node, which is a slave node, obtains the status data maintained by the first node itself, each node can execute the transaction task in the proposal message based on the obtained status data (in parallel or serially) to obtain the result information corresponding to the execution of each transaction task, that is, the way in which nodes execute transaction tasks in this application includes parallel execution and serial execution.

[0070] In step 306, when the result information obtained from executing the transaction task is inconsistent with the result information indicated by the proposal message, the read set information corresponding to the block identifier in the proposal message is obtained from the snapshots of other nodes in the blockchain system, where the other nodes are nodes other than the first node in the blockchain system.

[0071] Among them, the result information indicated by the proposal message refers to the information obtained by the master node when executing each transaction task in the proposal message. For example, the result information indicated by the proposal message in this application may include the execution result and the read-write set.

[0072] Other nodes refer to nodes in the node cluster other than the current slave node (itself). For example, in the underlying blockchain model based on BFT consensus, suppose a blockchain system includes three nodes, namely node 1, node 2 and node 3. At the current moment, the master node is node 2, and node 1 and node 3 are both slave nodes; for node 1, node 2 and node 3 are all other nodes.

[0073] A snapshot is a data structure used to store data read from the database when a node executes a transaction task. For example, the read set information corresponding to the block identifier can be read from the snapshot.

[0074] Read set information refers to the data read from the database when the node executes the transaction task. For example, the read set information in this application may include Key-Value information.

[0075] Furthermore, each node executes the transaction tasks in the proposal message based on the acquired status data (in parallel or serially). After obtaining the result information corresponding to the execution of each transaction task, each node can compare the result information corresponding to each transaction task obtained with the result information corresponding to each transaction task indicated in the proposal message to obtain the corresponding comparison result.

[0076] Alternatively, in some cases, if the proposal message does not carry the result information corresponding to each transaction task, but carries the block read-write set hash value, then after each node obtains the result information corresponding to the execution of each transaction task, each node can calculate the block read-write set hash value based on the result information corresponding to each transaction task obtained, and compare the block read-write set hash value calculated by itself with the block read-write set hash value indicated by the proposal message, and also obtain the corresponding comparison result.

[0077] For example, in the underlying blockchain model based on BFT consensus, when a first node (node ​​2) in a node cluster that serves as a slave node receives a proposal message A broadcast by a second node (node ​​1) that serves as a master node, the first node can obtain state data from the local state database (StateDB) maintained by the first node itself, and execute each transaction task in the proposal message based on the state data (in parallel or serially) to obtain the execution results and read-write sets corresponding to each transaction task.

[0078] Furthermore, when the proposal message A carries the transaction read-write set hash value of each transaction task, the first node as the slave node can calculate the transaction read-write set hash value of each transaction task based on the obtained read-write set corresponding to each transaction task, and compare the calculated transaction read-write set hash value of each transaction task with the transaction read-write set hash value of each transaction task carried in the proposal message A to obtain the comparison result corresponding to each transaction task.

[0079] For example, the first node can calculate the transaction read-write set hash value R of the transaction task 1 based on the read-write set 1 corresponding to the obtained transaction task 1, and compare the calculated transaction read-write set hash value R=1 of the transaction task 1 with the transaction read-write set hash value R=1 of the transaction task 1 carried in the proposal message A, and obtain the comparison result corresponding to the transaction task 1: consistent.

[0080] Alternatively, when the proposal message A does not carry the transaction read-write set hash values ​​of each transaction task but carries the block read-write set hash value B, the first node can calculate the hash value of the read-write set of all transaction tasks, that is, the block read-write set hash value B=2, based on the obtained read-write sets corresponding to each transaction task, and compare the calculated block read-write set hash value B=2 with the block read-write set hash value B=2 carried in the proposal message A. The comparison result can also be: consistent.

[0081] Furthermore, when the comparison result indicates that the result information obtained by the first node is inconsistent with the result information indicated by the proposal message, the first node can obtain the read set information corresponding to the block identifier in the proposal message from the snapshot of other nodes. For example, the first node can send a broadcast message for obtaining the read set information (carrying the block identifier in the proposal message) so that other nodes return corresponding response messages based on the block identifier in the broadcast message, that is, the response messages returned by other nodes carry the read set information obtained from the snapshot, so that the first node can obtain the read set information corresponding to the block identifier in the proposal message from the response messages returned by other nodes.

[0082] For example, in the underlying blockchain model based on BFT consensus, assume that a blockchain system includes three nodes, namely node 1, node 2 and node 3. When the first node (node ​​2) serving as a slave node in the node cluster receives a proposal message A broadcast by the second node (node ​​1) serving as a master node, the first node can obtain state data from the local state database (StateDB) maintained by the first node itself, and execute each transaction task in the proposal message based on the state data (in parallel or serially) to obtain the execution results and read-write sets corresponding to each transaction task.

[0083] Furthermore, when the proposal message A carries the transaction read-write set hash value of each transaction task, the first node can calculate the transaction read-write set hash value of each transaction task based on the read-write set corresponding to each transaction task, and compare the calculated transaction read-write set hash value of each transaction task with the transaction read-write set hash value of each transaction task carried in the proposal message A to obtain the comparison result corresponding to each transaction task.

[0084] For example, the first node as a slave node can calculate the transaction read-write set hash value R of transaction task 1 based on the obtained read-write set 1 corresponding to transaction task 1, and compare the calculated transaction read-write set hash value R=1 of transaction task 1 with the transaction read-write set hash value R=2 of transaction task 1 carried in the proposal message A, and obtain the comparison result corresponding to transaction task 1: inconsistent, that is, when the transaction read-write set hash value R=1 of transaction task 1 calculated by the first node is inconsistent with the transaction read-write set hash value R=2 of transaction task 1 carried in the proposal message A, the first node (node ​​2) can obtain the read set information corresponding to the block identifier in the proposal message from the snapshots of other nodes (node ​​1 and node 3).

[0085] Step 308: Repair the state data based on the read set information to obtain repaired state data. The repaired state data is used to re-execute the transaction task to obtain an execution result.

[0086] The repaired state data refers to the state data obtained after updating the local state data maintained by the first node itself. For example, when node A, as the first node, receives a proposal message broadcast by the second node, as the master node, node A obtains the state data it maintains as A01. Node A repairs state data A01 based on the read set information A02 obtained from other nodes, resulting in the repaired state data A02. This means that the repaired state data may be different from or the same as the state data before the repair.

[0087] Specifically, after the first node obtains the read set information corresponding to the block identifier in the proposal message from the snapshot of other nodes, the first node can perform reliability verification on the obtained read set information to obtain a verification result; when the verification result indicates that the read set information is credible, the first node can repair the status data maintained by itself based on the read set information to obtain repaired status data; further, after the first node obtains the repaired status data, the first node can re-execute the transaction task in the proposal message based on the repaired status data to obtain new result information, and compare the new result information with the result information indicated by the proposal message to obtain a second comparison result.

[0088] For example, in the underlying blockchain model based on BFT consensus, assume that a blockchain system includes three nodes, namely node 1, node 2 and node 3. When the first node (node ​​2) in the node cluster, which serves as a slave node, receives a proposal message A broadcast by the second node (node ​​1) which serves as a master node, the first node can obtain state data A01 from its own local state database (StateDB) and execute each transaction task in the proposal message based on the state data A01 (in parallel or serially) to obtain the execution results and read-write sets corresponding to each transaction task.

[0089] Furthermore, when the proposal message A carries the transaction read-write set hash value of each transaction task, the first node can calculate the transaction read-write set hash value of each transaction task based on the obtained read-write set corresponding to each transaction task, and compare the calculated transaction read-write set hash value of each transaction task with the transaction read-write set hash value of each transaction task carried in the proposal message A to obtain the comparison result corresponding to each transaction task.

[0090] For example, the first node can calculate the transaction read-write set hash value R of transaction task 1 based on the obtained read-write set 1 corresponding to transaction task 1, and compare the calculated transaction read-write set hash value R=1 of transaction task 1 with the transaction read-write set hash value R=2 of transaction task 1 carried in proposal message A. The comparison result for transaction task 1 is: inconsistent. That is, when the transaction read-write set hash value R=1 of transaction task 1 calculated by the first node is inconsistent with the transaction read-write set hash value R=2 of transaction task 1 carried in proposal message A, the first node (node ​​2) can obtain the read set information corresponding to the block identifier in the proposal message from the snapshots of other nodes (node ​​1 and node 3).

[0091] Assume that the first node (node ​​2) can obtain the read set information corresponding to the block identifier in the proposal message from the snapshots of other nodes (node ​​1 and node 3), which is A02. When the first node (node ​​2) verifies that the read set information A02 is credible, the first node (node ​​2) can repair the state data A01 maintained by the first node (node ​​2) based on the read set information A02, obtaining repaired state data A02. Based on the repaired state data A02, the first node (node ​​2) re-executes each transaction task in the proposal message A, obtains the new execution result and read-write set corresponding to each transaction task, and compares the new execution result and read-write set with the execution result and read-write set indicated in the proposal message. The second comparison result is: consistent.

[0092] In this embodiment, when the first node receives the proposal message broadcast by the second node, the first node obtains the status data maintained by the first node itself, and the first node executes the transaction task in the proposal message based on the status data to obtain result information; when the result information is inconsistent with the result information indicated by the proposal message, the first node obtains the read set information corresponding to the block identifier in the proposal message from the snapshot of other nodes; the first node repairs the status data based on the read set information to obtain repaired status data; the repaired status data is used to re-execute the transaction task to obtain a new execution result.

[0093] Because the read set information in the snapshots of other nodes is generated when the other nodes execute the transaction tasks in the proposal message, that is, the read set information in the snapshots of other nodes is read from the other nodes' own databases when executing the transaction tasks in the proposal message, when the result information obtained by the first node's execution is inconsistent with the result information indicated in the proposal message, the read set information corresponding to the block identifier in the proposal message obtained from the snapshots of other nodes is equivalent to obtaining the original state data in the database of the other node. Therefore, the node can repair the local state data maintained by the first node based on the read set information obtained from the snapshots of other nodes, obtain the repaired state data, and subsequently re-execute the transaction tasks based on the repaired state data. In this way, the node can accurately verify whether the state data maintained by the first node itself is problematic and automatically complete the repair of the state data during the consensus process, thereby effectively improving the consensus processing efficiency of the blockchain while ensuring the security of the entire blockchain.

[0094] In one embodiment, the result information includes an execution result and a transaction read / write set. Upon receiving a proposal message broadcast by a second node in the blockchain system, obtaining state data maintained by the first node includes: upon receiving a proposal message broadcast by the second node in the blockchain system, obtaining state data from a state database maintained by the first node. Executing the transaction task in the proposal message based on the state data to obtain result information includes: obtaining a contract corresponding to the transaction task in the proposal message, executing the transaction task in the proposal message based on the contract and the state data to obtain an execution result and a transaction read / write set.

[0095] The transaction read-write set refers to the read-write set generated during the execution of each transaction task. For example, the read-write set generated during the execution of transaction task A is read-write set A, and the read-write set generated during the execution of transaction task B is read-write set B.

[0096] A smart contract is not inherently intelligent; it's a piece of code that implements business logic. This code, or logic, is executed by the blockchain's node virtual machines. For a blockchain system, it requires the consistent state of all nodes, meaning it operates as a deterministic state machine. Only in this way can the blockchain system reach consensus; otherwise, the entire blockchain will not function properly.

[0097] Specifically, under the underlying blockchain model based on BFT consensus, after a second node (node ​​1) in a node cluster determines itself as the master node, the second node generates a block, initiating a new round of consensus. Specifically, the second node is responsible for generating proposals for new blocks. The second node can capture a preset number of transaction tasks from the transaction pool, encapsulate the captured transaction tasks into proposal message 1 for new block 1, and broadcast this proposal message 1 to the slave nodes in the blockchain, so that the slave nodes reach consensus on new block 1 based on the transaction tasks in proposal message 1. When a first node (node ​​2) in the node cluster, acting as a slave node, receives the proposal message broadcast by the second node, acting as the master node, the first node can obtain state data from the local state database (StateDB) maintained by the first node itself.

[0098] Furthermore, the first node can obtain the contracts corresponding to each transaction task in the proposal message 1, and execute the transaction tasks in the proposal message 1 based on the obtained contracts and status data (in parallel or serially), obtaining the execution results and transaction read-write sets corresponding to each transaction task in the proposal message 1. For example, assuming that the proposal message 1 includes transaction task A, the first node can obtain the contract corresponding to transaction task A in the proposal message 1 as save1, and execute transaction task A based on the obtained contract save1 and the status data A01 maintained by the first node itself, thereby obtaining the execution result S and transaction read-write set K corresponding to transaction task A.

[0099] In this embodiment, the first node verifies the transaction task by obtaining the local state data maintained by the first node itself. When it is found that the transaction read-write set calculated by itself is inconsistent with the transaction read-write set indicated by the proposal message, the first node can obtain the corresponding transaction read-write set from the snapshot of other nodes, so that the first node can accurately verify whether there is indeed a problem with the state data maintained by the first node itself, and then automatically complete the repair of the state data during the consensus process.

[0100] In one embodiment, the result information includes the transaction read / write set corresponding to the transaction task, the proposal message, and also indicates a transaction read / write set hash value determined based on the transaction read / write set corresponding to the transaction task. The blockchain state data repair method further includes: determining the transaction read / write set hash value of the transaction task based on the transaction read / write set; comparing the transaction read / write set hash value with the transaction read / write set hash value indicated by the proposal message to obtain a comparison result; generating a first-round voting message for the first node based on the comparison result; upon receiving a first-round voting message for another node broadcasted by another node, determining another-round voting message for the first node based on the first-round voting message and the first-round voting message of the other node; upon receiving another-round voting message for another node broadcasted by another node, determining a consensus result for the block corresponding to the block identifier based on the first-round voting message and the other-round voting message of the other node.

[0101] The transaction read-write set hash value refers to the MerkleRoot generated by all read-write sets generated by the transaction task. The transaction read-write set hash value can also be called the transaction read-write set Hash or RWSetHash.

[0102] The voting message of a first node in one round and the voting message of another round of the first node are voting messages of different rounds of the first node. For example, the voting message of a first node in one round may refer to the voting message of the first round of the current node, and the voting message of another round of the first node may refer to the voting message of the second round of the first node.

[0103] The voting messages of other nodes in one round and the voting messages of other nodes in another round are voting messages of different rounds of other nodes. For example, the voting messages of other nodes in one round may refer to the voting messages of the first round of other nodes, and the voting messages of other nodes in another round may refer to the voting messages of the second round of other nodes.

[0104] It can be understood that the voting messages of the first node in one round, the voting messages of other nodes in one round, the voting messages of the first node in another round, and the voting messages of other nodes in another round in this application are only used to distinguish the voting messages broadcast by different nodes in different rounds.

[0105] Consensus refers to the consensus on the newly generated block. Only when the newly generated block is verified by the nodes (including the first node) and consensus is reached, can the block be uploaded to the blockchain. Only then can each node in the blockchain system store the consensus block in the local ledger.

[0106] Specifically, under the underlying blockchain model based on BFT consensus, after a second node (node ​​1) in the node cluster determines itself as the master node, the second node generates a block and starts a new round of consensus. The second node can broadcast the proposal message 1 to the slave nodes (including the first node) in the blockchain, so that the slave nodes (including the first node) can reach a consensus on the new block 1 based on the transaction tasks in the proposal message 1.

[0107] When a first node (node ​​2) serving as a slave node in the node cluster receives the proposal message 1 broadcast by the second node, the first node executes the transaction task in the proposal message 1 based on the status data maintained by the first node itself, and obtains the execution results and transaction read-write sets corresponding to each transaction task. After that, the first node can determine the transaction read-write set hash value of each transaction task based on the transaction read-write set corresponding to each transaction task, and compare the transaction read-write set hash value of each transaction task with the transaction read-write set hash value of each transaction task indicated by the proposal message to obtain a comparison result.

[0108] Furthermore, the first node can generate a round of voting messages for the first node based on the comparison results; when the first node receives a round of voting messages from other nodes broadcast by other nodes, the first node can generate another round of voting messages for the first node based on the first round of voting messages and the other round of voting messages.

[0109] When the first node receives another round of voting messages from other nodes broadcast by other nodes, the first node can determine whether the block corresponding to the block identifier in the proposal message can reach a consensus based on the other round of voting messages of the first node and the other round of voting messages of other nodes.

[0110] For example, when the number of voting messages in another round of voting messages from the first node and another round of voting messages from other nodes that support the consensus on the block meets a preset condition, the first node can determine that the block has reached a consensus.

[0111] The precondition refers to the pre-set conditions for reaching consensus on a block. For example, the precondition can be set to 2f+1, where f refers to the number of malicious nodes in the blockchain system. In the Byzantine consensus model, the precondition is 3f+1. For example, if there are 4 nodes in the blockchain system, then f=1 nodes are allowed to be malicious, and no more. 2f+1 is the number of correct nodes. In other words, when the number of voting messages in favor of the block consensus meets 2f+1, the block can reach consensus.

[0112] For example, as shown in Figure 4, a schematic diagram of the overall process of state data repair is provided. In the underlying blockchain model based on BFT consensus as shown in Figure 4, after a node (Node1) in the node cluster determines itself as the leader, the leader generates a block and initiates a new round of consensus. The leader can broadcast a proposal message to the slave nodes (Node2, Node3, Node4) in the blockchain, so that the slave nodes (Node2, Node3, Node4) can reach consensus on the new block based on the transaction tasks in the proposal message. As shown in Figure 4, when a first node (Node4) in the node cluster, which is a slave node, receives the proposal message broadcast by the master node, the first node (Node4) executes the transaction tasks in the proposal message based on the state data maintained by the first node. After obtaining the execution results and transaction read-write sets corresponding to each transaction task, the first node can determine the transaction read-write set hash value of each transaction task based on the transaction read-write set corresponding to each transaction task, and compare the transaction read-write set hash value of each transaction task with the transaction read-write set hash value of each transaction task indicated in the proposal message to obtain a comparison result.

[0113] Furthermore, the first node may generate a round of voting messages (Prevote voting) for the first node based on the comparison result; when the first node receives a round of voting messages (Prevote voting) from other nodes broadcasted by other nodes, the first node may generate another round of voting messages (PreCommit voting) for the first node based on the voting messages (Prevote voting) from the first node and the voting messages (Prevote voting) from other nodes; when the first node receives another round of voting messages (PreCommit voting) from other nodes broadcasted by other nodes, the first node may determine whether a consensus can be reached on the block corresponding to the block identifier in the proposal message based on the voting messages (PreCommit voting) from the first node and the voting messages (PreCommit voting) from other nodes.

[0114] For example, when the number of voting messages in another round of voting messages from the first node and another round of voting messages from other nodes that support consensus on the block meets the preset conditions, the first node can determine that consensus has been reached on the block and submit the ledger; or when the number of voting messages in another round of voting messages from the first node and another round of voting messages from other nodes that support consensus on the block does not meet the preset conditions, the first node can determine that consensus has not been reached on the block and can enter the next round of consensus processing.

[0115] In this embodiment, the first node verifies the transaction task by obtaining the local state data maintained by the first node itself. When it is found that the transaction read-write set calculated by itself is inconsistent with the transaction read-write set indicated by the proposal message, the first node can obtain the corresponding transaction read-write set from the snapshot of other nodes, so that the first node can accurately verify whether it is indeed the state data maintained by the first node itself that has a problem. At the same time, the first node can execute the normal consensus process, that is, it can automatically complete the repair of the state data during the consensus process.

[0116] In one embodiment, when the result information obtained from executing the transaction task is inconsistent with the result information indicated by the proposal message, the read set information corresponding to the block identifier in the proposal message is obtained from the snapshot of other nodes in the blockchain system, including: when the comparison result indicates that the transaction read-write set hash value in the result information is inconsistent with the transaction read-write set hash value indicated by the proposal message, the read set information corresponding to the block identifier in the proposal message is obtained from the snapshot of at least one node among the other nodes.

[0117] Specifically, Figure 4 shows the overall process flow for state data repair. In the underlying blockchain model based on BFT consensus, as shown in Figure 4, after a node (Node1) in the node cluster determines itself as the leader, it generates a block and initiates a new round of consensus. The leader can then broadcast a proposal message to the slave nodes (Node2, Node3, Node4) in the blockchain, allowing them to reach consensus on the new block based on the transaction tasks in the proposal message.

[0118] As shown in Figure 4, when a first node (Node4) serving as a slave node in the node cluster receives the proposal message broadcast by the second node, the first node (Node4) executes the transaction task in the proposal message based on the status data maintained by the first node itself, and obtains the execution results and transaction read-write sets corresponding to each transaction task. After that, the first node can determine the transaction read-write set hash value of each transaction task based on the transaction read-write set corresponding to each transaction task, and compare the transaction read-write set hash value of each transaction task with the transaction read-write set hash value of each transaction task indicated by the proposal message to obtain a comparison result.

[0119] When the comparison result indicates that the transaction read-write set hash value obtained by the first node (Node4) is inconsistent with the transaction read-write set hash value indicated by the proposal message, as shown in Figure 4, the first node (Node4) can obtain the read set information corresponding to the block identifier in the proposal message from the snapshot of at least one of the other nodes (Node1, Node2, Node3).

[0120] For example, when the comparison result indicates that the transaction read-write set hash value K=4 of transaction task A obtained by the first node (Node4) is inconsistent with the transaction read-write set hash value K=2 of transaction task A indicated in the proposal message, the first node (Node4) can send a broadcast message for obtaining read set information (carrying the identifier of transaction task A), so that other nodes (Node1, Node2, Node3) return corresponding response messages based on the identifier of transaction task A in the broadcast message, that is, the response message returned by other nodes carries the read set information TxReadSet(1) and MerkleRoot (i.e., TxReadHash) corresponding to the identifier TxID(1) of transaction task A obtained from the snapshot, so that the node (Node4) can obtain the read set information TxReadSet(1) and MerkleRoot (i.e., TxReadHash) corresponding to the transaction task A, i.e., TxID(1), from the response message returned by other nodes. As a result, the state data synchronization process can be completed at the same time as consensus without relying on HistoryDB. Because operations are performed during the consensus process, on the one hand, the processing flow is completed automatically, and on the other hand, it will not affect the normal consensus processing flow, and it also effectively improves the security of data repair.

[0121] In one embodiment, obtaining read set information corresponding to the block identifier in the proposal message from a snapshot of at least one of the other nodes includes: obtaining the number of fault-tolerant nodes in the blockchain system, determining a target number based on the number of fault-tolerant nodes, the target number being greater than the number of fault-tolerant nodes; selecting the target number of nodes from the other nodes; and searching for read set information corresponding to the block identifier in the proposal message from the snapshots of the target number of nodes.

[0122] In some embodiments, the blockchain state data repair method also includes: when the read set information is not found, waiting for other nodes to execute the transaction tasks in the proposal message, so that other nodes update the snapshot after the execution is completed, and searching for the read set information corresponding to the block identifier in the updated snapshot.

[0123] The number of fault-tolerant nodes refers to the number of pre-set fault-tolerant nodes. For example, if the number of fault-tolerant nodes is set to f, the target number can be f+1. For example, if there are 4 nodes in the entire environment (blockchain system), then f=1 nodes are allowed to be malicious nodes, and no more. f+1 nodes means that there must be an honest node among them.

[0124] Specifically, as shown in FIG4 , when the comparison result indicates that the transaction read-write set hash value obtained by the first node (Node4) is inconsistent with the transaction read-write set hash value indicated by the proposal message, the first node (Node4) can obtain the read set information corresponding to the block identifier in the proposal message from the snapshot of at least one of the other nodes (Node1, Node2, Node3).

[0125] For example, the first node (Node4) can determine the target number as f+1=1+1=2 based on the number of fault-tolerant nodes f=1, that is, the first node (Node4) can select any two nodes (Node2 and Node3) from other nodes (Node1, Node2, Node3). Assuming that the first node (Node4) does not find the read set information corresponding to the block identifier A in the proposal message from the snapshots of Node2 and Node3, it indicates that Node2 and Node3 may not have completed all transaction tasks in the proposal message. Then, the first node (Node4) can wait for Node2 and Node3 to complete all transaction tasks in the proposal message, and update the information in the snapshot after execution, and search for the read set information corresponding to the block identifier in the updated snapshot information.

[0126] The first node (Node4) can send a broadcast message for obtaining read set information (carrying the block identifier in the proposal message), so that other nodes (Node2 and Node3) return corresponding response messages based on the block identifier in the broadcast message, that is, the response messages returned by Node2 and Node3 carry the read set information and MerkleRoot corresponding to the block identifier obtained from the snapshot, so that the node (Node4) can obtain the read set information (that is, TxReadSet) and MerkleRoot (that is, TxReadHash) corresponding to the block identifier from the response messages returned by Node2 and Node3.

[0127] Furthermore, if the node (Node4) does not receive a corresponding response message from Node2 and Node3 based on the block identifier in the broadcast message within a preset time period, the first node (Node4) can resend the broadcast message for obtaining the read set information (carrying the block identifier in the proposal message, such as BlockHeight) to other nodes in the blockchain. This allows the synchronization of state data to be completed simultaneously with consensus, without relying on HistoryDB. Because operations are performed during the consensus process, the processing flow is automatically completed and does not affect the normal consensus processing flow, effectively improving the security of data repair.

[0128] In one embodiment, the blockchain state data repair method further includes: when the comparison result indicates that the transaction read-write set hash value in the result information is inconsistent with the transaction read-write set hash value indicated by the proposal message, adding the transaction identifier of the transaction task to the target set. Obtaining read set information corresponding to the block identifier in the proposal message from snapshots of other nodes in the blockchain system includes: sending a broadcast message for obtaining the read set information, the broadcast message including the transaction identifier of the transaction task in the target set, so that the other nodes return corresponding response messages based on the transaction identifier of the transaction task in the target set; when receiving the response message returned by the other node, deserializing the response message to obtain a deserialized data structure; and using the data in the data structure as the read set information corresponding to the block identifier in the proposal message.

[0129] The target set refers to a set of transaction identifiers for storing transaction tasks with inconsistent read and write sets. For example, the target set in this application can be a set of transaction task IDs with inconsistent read and write sets.

[0130] Serialization refers to the process of converting the acquired read set information into a form that can be stored or transmitted. For example, after converting the read set information into binary form, this binary form is sent out in the form of a response message.

[0131] Deserialization refers to the process of converting binary information into its original data structure. For example, only after converting a binary response message into the original data structure can the read set information in this data structure be obtained.

[0132] Specifically, Figure 4 shows the overall process flow for state data repair. In the underlying blockchain model based on BFT consensus, as shown in Figure 4, after a node (Node1) in the node cluster determines itself as the leader, it generates a block and initiates a new round of consensus. The leader can then broadcast a proposal message to the slave nodes (Node2, Node3, Node4) in the blockchain, allowing them to reach consensus on the new block based on the transaction tasks in the proposal message.

[0133] As shown in Figure 4, when a first node (Node4) serving as a slave node in the node cluster receives the proposal message broadcast by the master node, the first node (Node4) executes the transaction task in the proposal message based on the status data maintained by the first node itself, and obtains the execution results and transaction read-write sets corresponding to each transaction task. After that, the first node can determine the transaction read-write set hash value of each transaction task based on the transaction read-write set corresponding to each transaction task, and compare the transaction read-write set hash value of each transaction task with the transaction read-write set hash value of each transaction task indicated by the proposal message to obtain a comparison result.

[0134] When the comparison result indicates that the transaction read-write set hash value K=4 of transaction task A obtained by the first node (Node4) is inconsistent with the transaction read-write set hash value K=2 of transaction task A indicated in the proposal message, the first node (Node4) can add the transaction identifier TxA of transaction task A to the target set RWIDs; further, the first node (Node4) can serialize the target set RWIDs and broadcast it to other nodes, that is, the first node (Node4) can send a broadcast message for obtaining read set information, and the broadcast information includes the transaction identifier of each transaction task in the target set RWIDs, so that other nodes return corresponding response messages based on the transaction identifier of the transaction task in the target set; when the first node (Node4) receives the response message returned by other nodes (Node1, Node2, Node3), it deserializes the response message to obtain the deserialized data structure, and uses the data in the deserialized data structure as the read set information corresponding to the block identifier in the proposal message.

[0135] For example, Figure 5 shows the overall process flow of the blockchain state data repair method. In Figure 5, i represents the transaction number, Len(Txs) represents the number of transactions in the transaction set Txs, Len(RWIDs) represents the number of transactions in the set RWIDs, and i++ indicates that after i participates in the operation, the value of i is incremented by 1. In the process shown in Figure 5, after a node (Node1) in the node cluster determines itself as the leader, the leader generates a block and starts a new round of consensus. The leader can broadcast a proposal message to the slave nodes (Node2, Node3, Node4) in the blockchain, so that the slave nodes (Node2, Node3, Node4) can reach a consensus on the new block based on the transaction tasks in the proposal message. When a first node (Node4) in the node cluster that serves as a slave node receives a proposal message broadcast by the master node, the first node (Node4) deserializes the proposal message, that is, converts the proposal message (network message) into a data structure that can be processed within the program, and verifies the proposal in the data structure. The verification content includes but is not limited to verification of the legitimacy of the block-generating node and verification of the legitimacy of the signature.

[0136] Furthermore, when the first node (Node4) successfully verifies the proposal in the data structure, the first node (Node4) can execute the transaction tasks contained in the proposal one by one (serially), and add the transaction task IDs with inconsistent transaction read-write set hash values ​​to RWIDs, and serialize the RWIDs and broadcast them to other nodes. That is, the first node (Node4) can send a broadcast message for obtaining read set information, which includes each transaction task ID in RWIDs, so that other nodes return corresponding response messages based on the transaction task ID in RWIDs; when the first node (Node4) receives the response message returned by other nodes (Node1, Node2, Node3), it deserializes the response message into a program-internal processable object, namely, the response message structure, and uses the data in the deserialized response message structure as the read set information corresponding to the block identifier in the proposal message. In this way, the state data synchronization process can be completed at the same time as the consensus, without relying on HistoryDB, because the operation is performed during the consensus process. On the one hand, its processing process is automatically completed, and on the other hand, it does not affect the normal consensus processing process, and also effectively improves the security of data repair.

[0137] In one embodiment, the blockchain state data repair method also includes: when receiving response messages returned by other nodes, determining the number of response messages; when the number of response messages is greater than or equal to the target number, and the read set information in each response message is consistent, executing the step of repairing the state data based on the read set information, and the target number is determined based on the number of fault-tolerant nodes in the blockchain system, and the target number is greater than the number of fault-tolerant nodes.

[0138] Among them, the number of response messages refers to the number of response messages received. For example, the first node (Node4) can send a broadcast message for obtaining read set information, so that other nodes (Node1, Node2, Node3) return corresponding response messages based on the block identifier in the broadcast message. In theory, the number of response messages that the first node (Node4) can receive is 3, but in actual applications, the number of response messages received by the first node (Node4) can be 0, 1, 2, 3, that is, some nodes do not return corresponding response messages (or time out).

[0139] The target number refers to the number determined based on the number of fault-tolerant nodes. For example, the target number in this application can be f+1, where f represents the number of fault-tolerant nodes. For example, if there are 4 nodes in the entire environment (blockchain system), then f=1 nodes are allowed to be malicious nodes, and no more. f+1 nodes means that there must be an honest node among them.

[0140] Specifically, under the underlying blockchain model based on BFT consensus as shown in Figure 4, when the comparison result indicates that the transaction read-write set hash value K=4 of transaction task A obtained by the first node (Node4) is inconsistent with the transaction read-write set hash value K=2 of transaction task A indicated by the proposal message, the first node (Node4) can add the transaction identifier TxA of transaction task A to the target set RWIDs.

[0141] Furthermore, the first node (Node4) can serialize the target set RWIDs and broadcast them to other nodes, that is, the first node (Node4) can send a broadcast message for obtaining read set information, and the broadcast information includes the transaction identifier of each transaction task in the target set RWIDs, so that other nodes return corresponding response messages based on the transaction identifier of the transaction task in the target set; when the first node (Node4) receives the response message returned by other nodes (Node1, Node2, Node3), it determines the number of response messages n=3.

[0142] Furthermore, the first node (Node4) can determine whether the read set information in the response messages returned by other nodes (Node1, Node2, Node3) is consistent. Assuming that the target number f+1=1+1=2, since the number of response messages n=3>the target number f+1=1+1=2, that is, when the number of response messages is greater than the target number and the read set information in each response message is consistent, the first node (Node4) can execute the step of repairing the status data in the local database maintained by the first node itself based on the read set information.

[0143] For example, as shown in Figure 5, it is a schematic diagram of the overall process of the state data repair method of the blockchain. In the process shown in Figure 5, after a node (Node1) in the node cluster determines that it is the master node (Leader), the master node generates a block and starts a new round of consensus. The master node can broadcast the proposal message to the slave nodes (Node2, Node3, Node4) in the blockchain, so that the slave nodes (Node2, Node3, Node4) can reach a consensus on the new block based on the transaction tasks in the proposal message. When a first node (Node4) in the node cluster that serves as a slave node receives the proposal message broadcast by the second node, the first node (Node4) deserializes the proposal message, that is, converts the proposal message (network message) into a data structure that can be processed within the program, and verifies the proposal in the data structure. The verification content includes but is not limited to verification of the legitimacy of the block-producing node and signature legitimacy.

[0144] Furthermore, when the first node (Node4) successfully verifies the proposal in the data structure, the first node (Node4) can execute the transaction tasks contained in the proposal one by one (serial), and add the transaction task IDs with inconsistent transaction read-write set hash values ​​to RWIDs, and serialize the RWIDs and broadcast them to other nodes, that is, the first node (Node4) can send a broadcast message for obtaining read set information, and the broadcast information includes each transaction task ID in RWIDs, so that other nodes return corresponding response messages based on the transaction task ID in RWIDs; when the first node (Node4) receives the response messages returned by other nodes (Node1 and Node3), it determines the number of response messages n=2.

[0145] Furthermore, the first node (Node4) can determine whether the read set information in the response messages returned by other nodes (Node1, Node3) is consistent. Assuming that the target number f+1=1+1=2, since the number of response messages n=2 is equal to the target number f+1=1+1=2, that is, when the number of response messages is equal to the target number and the read set information in each response message is consistent, the first node (Node4) can execute the step of repairing the status data in the local database maintained by the first node itself based on the read set information.

[0146] In this way, the state data synchronization process can be completed at the same time as consensus, without relying on HistoryDB. Because the operation is carried out during the consensus process, on the one hand, the processing flow is completed automatically, and on the other hand, it will not affect the normal consensus processing flow, and it also effectively improves the security of data repair.

[0147] In one embodiment, the result information includes a transaction read / write set corresponding to the transaction task, the proposal message indicates a first block read / write set hash value, and the first block read / write set hash value is generated based on the transaction read / write sets of all transaction tasks in the block corresponding to the block identifier. The blockchain state data repair method further includes: determining a second block read / write set hash value based on the transaction read / write sets of the transaction tasks. When the result information obtained from executing the transaction task is inconsistent with the result information indicated by the proposal message, obtaining read set information corresponding to the block identifier in the proposal message from snapshots of other nodes in the blockchain system includes: when the second block read / write set hash value is inconsistent with the first block read / write set hash value, obtaining read set information corresponding to the block identifier in the proposal message from a snapshot of at least one of the other nodes.

[0148] Specifically, as shown in Figure 6, it is a schematic diagram of the information carried by the proposal message. Among the information carried by the blocks shown in Figure 6, some blocks carry the transaction read-write set hash value (RWSetHash), and some blocks do not carry the transaction read-write set hash value (RWSetHash). In some cases, if the proposal message broadcast by the master node does not carry the transaction read-write set hash value corresponding to each transaction task, but carries the block read-write set hash value, then after each slave node (including the first node) obtains the result information corresponding to the execution of each transaction task, each slave node can calculate the block read-write set hash value based on the result information corresponding to each transaction task, and compare the block read-write set hash value calculated by itself with the block read-write set hash value indicated by the proposal message to obtain the corresponding comparison result.

[0149] When the proposal message broadcast by the master node carries the transaction task and the hash value of the first block read-write set, after each slave node obtains the execution result and transaction read-write set corresponding to each transaction task, each slave node can determine the hash value of the second block read-write set based on the transaction read-write set of the transaction task; when the hash value of the second block read-write set is inconsistent with the hash value of the first block read-write set indicated by the proposal message, the slave node can obtain the read set information corresponding to the block identifier in the proposal message from the snapshot of at least one of the other nodes.

[0150] For example, as shown in Figure 6, if the proposal message broadcast by the master node does not carry the transaction read-write set hash value corresponding to each transaction task, but carries the block hash, block height and block read-write set hash value, then under the blockchain underlying model based on BFT consensus as shown in Figure 4, when a first node (Node4) serving as a slave node in the node cluster receives the proposal message broadcast by the master node, the first node (Node4) executes the transaction task in the proposal message based on the status data maintained by the first node itself, and obtains the execution results and transaction read-write sets corresponding to each transaction task. After that, the first node (Node4) can calculate the second block read-write set hash value based on the transaction read-write set corresponding to each transaction task, and compare the second block read-write set hash value calculated by itself with the first block read-write set hash value indicated by the proposal message to obtain the corresponding comparison result.

[0151] When the second block read-write set hash value is inconsistent with the first block read-write set hash value indicated by the proposal message, the first node (Node4) can obtain the read set information corresponding to the block identifier in the proposal message from the snapshot of at least one of the other nodes (Node1, Node2, Node3).

[0152] In this embodiment, since the read set information in the snapshots of other nodes is generated when other nodes execute the transaction tasks in the proposal message, that is, the read set information in the snapshots of other nodes is read from their own databases when other nodes execute the transaction tasks in the proposal message, when the result information obtained by the first node is inconsistent with the result information indicated by the proposal message, the read set information corresponding to the block identifier in the proposal message obtained by the first node from the snapshots of other nodes is equivalent to obtaining the original state data in the database of other nodes. Therefore, the node can accurately verify whether there is a problem with the state data maintained by the first node itself, and can automatically complete the repair of the state data during the consensus process, thereby effectively improving the consensus processing efficiency of the blockchain while ensuring the security of the entire blockchain.

[0153] In one embodiment, the state data repair method of the blockchain further includes: performing reliability verification on the read set information to obtain a verification result; when the verification result indicates that the read set information is credible, executing the step of repairing the state data based on the read set information.

[0154] Among them, reliability verification refers to verifying the credibility of the read set information, and the verification result refers to the result obtained by reliability verification of the read set information. For example, the results obtained by reliability verification of the read set information in this application include: the verification result indicates credibility and the verification result indicates untrustworthy.

[0155] Specifically, as shown in Figure 4, when a first node (Node4) serving as a slave node in the node cluster receives the proposal message broadcast by the master node (Node1), the first node (Node4) executes the transaction task in the proposal message based on the status data maintained by the first node itself, and obtains the execution results and transaction read-write sets corresponding to each transaction task. After that, the first node can determine the transaction read-write set hash value of each transaction task based on the transaction read-write set corresponding to each transaction task, and compare the transaction read-write set hash value of each transaction task with the transaction read-write set hash value of each transaction task indicated by the proposal message to obtain a comparison result.

[0156] When the comparison result indicates that the transaction read-write set hash value obtained by the first node (Node4) is inconsistent with the transaction read-write set hash value indicated by the proposal message, as shown in Figure 4, the first node (Node4) can obtain the read set information corresponding to the block identifier in the proposal message from the snapshot of at least one of the other nodes (Node1, Node2, Node3). After the first node (Node4) obtains the read set information corresponding to the block identifier in the proposal message from the snapshot of at least one of the other nodes (Node1, Node2, Node3), assuming that the first node (Node4) obtains three read set information corresponding to the block identifier in the proposal message from the snapshots of three of the other nodes (Node1, Node2, Node3), namely read set A, read set B, and read set C, the first node (Node4) needs to verify the reliability of the three read set information (read set A, read set B, and read set C) obtained.

[0157] For example, the first node (Node4) needs to verify the reliability of the data in the three read set information (read set A, read set B, and read set C) obtained. After the data in the read set information is verified, the first node (Node4) further verifies the three read set information (read set A, read set B, and read set C) obtained based on preset conditions. For example, the preset conditions are: the responses obtained from f+1 nodes are consistent, that is, the first node (Node4) determines whether the three read set information (read set A, read set B, and read set C) obtained are consistent. If the three read set information are consistent, a verification result indicating that the read set information (read set A, read set B, and read set C) is credible can be obtained. Then the first node (Node4) can execute the steps of repairing the status data maintained by the first node itself based on the read set information (read set A, read set B, and read set C).

[0158] For example, Figure 7 shows a schematic diagram of a broadcast message and a response message for obtaining a read set. Specifically, when a node requests a read set from another node's snapshot, the structure of the broadcast message it sends and the response message it receives are shown in Figure 7.

[0159] As shown in FIG7 , FIG7 shows the structures of two broadcast messages and three response messages. When the transaction read-write set hash value calculated by the first node (Node4) itself is inconsistent with the transaction read-write set hash value indicated by the proposal message, the first node (Node4) can send a broadcast message for obtaining the read set information. The broadcast message includes a block identifier (block height), i.e., a request broadcast message (1) as shown in FIG7 .

[0160] In addition, in some cases, the broadcast information may also include a block identifier (block height) and a transaction task identifier (TxID), i.e., a request broadcast message (2) as shown in FIG7 , so that other nodes return corresponding response messages based on the request broadcast message; that is, the first node (Node4) in this application can receive three types of response messages as shown in FIG7 , including response message (1), response message (2) and response message (3), that is, when the first node (Node4) receives the response message (1), response message (2) and response message (3) returned by other nodes (Node1, Node2, Node3), the first node (Node4) can verify the data in the response message (1), response message (2) and response message (3). After the verification is passed, the first node (Node4) needs to further determine whether the read set information in the response message (1), the response message (2) and the response message (3) are consistent. Assuming that the target number f+1=1+1=2, since the number of response messages n=3 is greater than the target number f+1=1+1=2, that is, when the number of response messages is greater than the target number and the read set information in each response message is consistent, it indicates that the read set information in the response message (1), the response message (2) and the response message (3) is credible, then the first node (Node4) can execute the step of repairing the status data in the local database maintained by the first node itself based on the read set information in the response message (1), the response message (2) and the response message (3).

[0161] In this way, the state data synchronization process can be completed at the same time as consensus, without relying on HistoryDB. Because the operation is carried out during the consensus process, on the one hand, the processing flow is completed automatically, and on the other hand, it will not affect the normal consensus processing flow, and it also effectively improves the security of data repair.

[0162] In one embodiment, the read set information includes key-value pair information, and the state data is repaired based on the read set information to obtain the repaired state data, including: updating the data in the local state database based on the key-value pair information, and using the updated data as the repaired state data.

[0163] The key-value pair information refers to the key-value information generated during the execution of the transaction task.

[0164] Specifically, when the transaction read-write set hash value K=4 of transaction task A calculated by the first node (Node4) itself is inconsistent with the transaction read-write set hash value K=2 of transaction task A indicated in the proposal message, the first node (Node4) can send a broadcast message for obtaining read set information (carrying the identifier of transaction task A), so that other nodes (Node1, Node2, Node3) return corresponding response messages based on the identifier of transaction task A in the broadcast message, that is, the response messages returned by other nodes carry the read set information and MerkleRoot corresponding to the identifier of transaction task A obtained from the snapshot, so that the node (Node4) can obtain the read set information and MerkleRoot corresponding to the transaction task A from the response messages returned by other nodes.

[0165] Assume that the first node (Node4) obtains read set information A01, A02, and A03 from the response message returned by other nodes (Node1, Node2, and Node3). When the first node (Node4) verifies that the read set information A01, A02, and A03 are consistent and credible, the node (Node4) can select any one of the read set information A01, A02, and A03, and update the key-value pair information in the selected read set information A02 to the status database maintained by the first node itself, and obtain the updated status data A02. The updated status data A02 is used as the repaired status data, so that the node can re-execute each transaction task in the proposal message A based on the repaired status data A02, obtain the new execution result and read-write set corresponding to each transaction task, and compare the new execution result and read-write set with the execution result and read-write set indicated by the proposal message to obtain a secondary comparison result. As a result, the first node can accurately verify whether there is a problem with the status data maintained by the first node itself, and can automatically repair the status data during the consensus process, thereby effectively improving the consensus processing efficiency of the blockchain while ensuring the security of the entire blockchain.

[0166] In one embodiment, the blockchain state data repair method further includes: deserializing the proposal message to obtain a deserialized proposal message. Executing a transaction task in the proposal message based on the state data includes: executing the transaction task in the deserialized proposal message based on the state data.

[0167] Deserialization refers to the process of converting binary information into its original data structure. For example, only after converting a binary proposal message into its original data structure can the transaction task in this data structure be obtained.

[0168] Specifically, as shown in Figure 5, it is a schematic diagram of the overall process of the state data repair method of the blockchain. In the process shown in Figure 5, after a node (Node1) in the node cluster determines that it is the master node (Leader), the master node generates a block and starts a new round of consensus. The master node can broadcast the proposal message to the slave nodes (Node2, Node3, Node4) in the blockchain, so that the slave nodes (Node2, Node3, Node4) can reach a consensus on the new block based on the transaction tasks in the proposal message. When a first node (Node4) in the node cluster that serves as a slave node receives the proposal message broadcast by the master node, the first node (Node4) can deserialize the proposal message, that is, convert the proposal message (network message) into a data structure that can be processed within the program, and verify the proposal in the data structure. The verification content includes but is not limited to verification of the legitimacy of the block-generating node, verification of the legitimacy of the signature, etc.

[0169] Furthermore, when the first node (Node4) successfully verifies the proposal in the data structure, the first node (Node4) can execute the transaction tasks contained in the proposal one by one (serially) based on the status data maintained by the first node itself, and add the transaction task IDs with inconsistent transaction read-write set hash values ​​to RWIDs.

[0170] As a result, the node can accurately verify whether there is a problem with the status data maintained by the first node itself, and can automatically repair the status data during the consensus process, thereby effectively improving the consensus processing efficiency of the blockchain while ensuring the security of the entire blockchain.

[0171] In one embodiment, the state data repair method of the blockchain further includes: performing a legitimacy verification on the deserialized proposal message to obtain a verification result; when the verification result indicates that the verification is successful, executing the transaction task in the deserialized proposal message based on the state data.

[0172] In one embodiment, the state data repair method of the blockchain further includes: when the verification result indicates that the verification fails, discarding the proposal message.

[0173] Specifically, as shown in Figure 5, it is a schematic diagram of the overall process of the state data repair method of the blockchain. In the process shown in Figure 5, after a node (Node1) in the node cluster determines that it is the master node (Leader), the master node generates a block and starts a new round of consensus. The master node can broadcast the proposal message 1 to the slave nodes (Node2, Node3, Node4) in the blockchain, so that the slave nodes (Node2, Node3, Node4) can reach a consensus on the new block based on the transaction task in the proposal message 1; when the first node (Node4) in the node cluster, which is a slave node, receives the proposal message 1 broadcast by the master node, the first node (Node4) can deserialize the proposal message 1, that is, convert the proposal message 1 (network message) into a data structure that can be processed within the program, and verify the proposal in the data structure to obtain a corresponding verification result, wherein the verification content includes but is not limited to verification of the legitimacy of the block-generating node, verification of the legitimacy of the signature, etc.

[0174] Furthermore, when the verification result indicates a failure, the first node (Node4) may discard the proposal message 1. When the verification result indicates a success, the first node (Node4) may execute the transaction tasks in the deserialized proposal message (the proposal in the data structure) based on the state data. That is, the first node (Node4) may execute the transaction tasks contained in the proposal one by one (serially) based on the state data maintained by the first node itself, and add the transaction task IDs with inconsistent transaction read-write set hash values ​​to the RWIDs. This allows the node to accurately verify whether there is a problem with the state data maintained by the first node itself, and automatically complete the repair of the state data during the consensus process, thereby effectively improving the consensus processing efficiency of the blockchain while ensuring the security of the entire blockchain.

[0175] In one embodiment, the present application further provides an application scenario, which applies the above-mentioned blockchain state data repair method. Specifically, the application of the blockchain state data repair method in this application scenario is as follows:

[0176] When you want to complete the repair of state data at the same time as consensus, you can use the above-mentioned blockchain state data repair method, that is, in the blockchain system, when the second node as the master node in the node cluster produces a block, the second node broadcasts the proposal message to the slave nodes in the blockchain, so that the slave nodes reach a consensus on the new block; when the first node among the slave nodes receives the proposal message broadcast by the second node, the first node obtains the state data maintained by the first node itself, and executes the transaction task in the proposal message based on the state data to obtain result information; when the result information is inconsistent with the result information indicated by the proposal message, the first node can obtain the read set information corresponding to the block identifier in the proposal message from the snapshot of other nodes, and repair the state data based on the read set information to obtain the repaired state data; the repaired state data is used to re-execute the transaction task to obtain a new execution result. Since when the result information obtained by the first node is inconsistent with the result information indicated by the proposal message, the read set information corresponding to the block identifier in the proposal message obtained by the first node from the snapshot of other nodes is equivalent to obtaining the original state data in the database of other nodes. Therefore, the node can repair the local state data maintained by the first node itself based on the read set information obtained from the snapshot of other nodes to obtain the repaired state data. Subsequently, the transaction task can be re-executed based on the repaired state data, so that the state data synchronization process can be completed at the same time as the consensus, without relying on HistoryDB. Because the operation is performed during the consensus process, on the one hand, its processing flow is automatically completed, and on the other hand, it will not affect the normal consensus. The state data can be repaired during the consensus process, thereby effectively improving the consensus processing efficiency of the blockchain.

[0177] The method provided in the embodiments of this application can be applied to various blockchain consensus scenarios. The following uses a blockchain consensus scenario in a BFT-type consensus environment as an example to illustrate the blockchain state data repair method provided in the embodiments of this application.

[0178] With the development of blockchain technology, it has become increasingly mature. Due to the open and transparent nature of blockchain, more and more systems are directly migrating their operations to the blockchain. Blockchain is essentially a distributed storage system, with each node storing data, and the node's data storage is based on a database.

[0179] Generally speaking, a blockchain has at least two databases: BlockDB and StateDB. The former is used to store transaction information, mainly transaction information and block headers sent by users; the latter stores state data, which is the Key-Value information generated during the transaction execution process.

[0180] StateDB information is used throughout the actual transaction execution process. For example, if a historical transaction modified the value of a key, the current transaction needs to read that value. Although nodes typically use a database to store StateDB, this is not without problems. Some data may become corrupted due to unusual circumstances, such as a power outage before the data is fully written or the corresponding disk is damaged.

[0181] Then a recovery mechanism is needed. To address this problem, this application proposes a mechanism that automatically repairs during transaction execution. Through this mechanism, StateDB can be repaired without the need for external human intervention.

[0182] There are generally two solutions in the traditional way:

[0183] The first solution, shown in Figure 8, is a diagram of the traditional method of restoring data using the HistoryDB database. A database, HistoryDB, is added to the blockchain system. This database stores all read-write sets (which can be thought of as key-value pairs) generated by transactions in each block. When a repair is needed, the method shown in Figure 8 can be used. In this method, the data in the corresponding block in HistoryDB is manually restored to a certain level.

[0184] The second solution is that HistoryDB does not exist in the blockchain system. For this method, there are also two processing mechanisms in the industry. As shown in Figure 9, it is a schematic diagram of two different methods used in traditional methods to repair data. Solution 1 shown in Figure 9 is very simple, which is to copy the stateDB data directly from an approved node to the local computer. This method requires manual intervention. Solution 2 shown in Figure 9 does not pay attention to this error, that is, if a vote of disapproval is cast during the consensus process, the corresponding node will not be able to reach a consensus in this round. Subsequently, the block information of other nodes will need to be synchronized (the block information here includes the content of StateDB). Therefore, the synchronization must support the so-called "fast synchronization" mode. In this mode, the node will use the content of other nodes to overwrite the local data.

[0185] The defects of traditional methods are divided into the following categories according to the implementation scheme:

[0186] 1. The first solution (with HistoryDB) has two problems. First, it targets blocks. If the damaged StateDB involves multiple blocks, then HistoryDB is difficult to repair because it is difficult to determine which blocks' data is damaged. Second, it is impossible to determine the correctness of HistoryDB itself. If the data in HistoryDB is also damaged, it will not be able to be properly repaired.

[0187] 2. The two options in the second option are explained separately:

[0188] 1) Direct replication: This solution has two major issues. First, it requires manual intervention. Since StateDB corruption is unpredictable, the data will remain unusable until manual intervention is performed. Second, if the StateDB is large and the data volume is large, replication will take a long time.

[0189] 2) The problem with the fast synchronization solution is that the nodes will not be able to reach a consensus normally before the synchronization is completed, and because of this problem, the nodes may not be able to reach a consensus normally.

[0190] Therefore, in order to solve the above problems, this application provides a solution, that is, this application proposes a method for repairing blockchain status data. The key issues to be solved by this application include:

[0191] In response to the problems existing in the above-mentioned industry solutions, an optimized processing solution is proposed. In this solution, the StateDB synchronization process can be completed at the same time as consensus. This method does not need to rely on HistoryDB. Moreover, because it operates during the consensus process, its processing flow is completed automatically and will not affect the normal consensus. It can complete the repair of state data during the consensus process, thereby effectively improving the consensus processing efficiency of the blockchain while ensuring the security of the entire blockchain.

[0192] On the product side, the method provided in this application can be applied to the actual development of blockchain underlying software, and can be implemented at the code level according to the solution of this application to optimize the corresponding blockchain underlying code.

[0193] On the technical side,

[0194] 1.1 Overall Process

[0195] The core of the solution proposed in this application is: when the slave node verifies the proposal, if it finds that its execution status is inconsistent with the master node, it may indicate to a certain extent that there may be a problem with the local stateDB (of course, it may also be that the master node is malicious). Then its processing flow is: the slave node can obtain the read set in this operation from other nodes, and then use the read set to update the state data maintained by the first node itself, and then re-execute the transaction based on the updated state data.

[0196] From the perspective of the consensus process, the overall process is shown in Figure 5.

[0197] As shown in Figure 6, in order for the slave node to accurately verify that there is a problem with the read-write set, the master node actually has two proposed solutions:

[0198] 1. Each transaction carries the corresponding read-write set hash (i.e., the transaction read-write set hash). This allows the slave node to accurately determine which transaction is inconsistent during verification, and thus clearly identify which keys in the stateDB have issues.

[0199] 2. The transaction does not need to carry the corresponding read-write set hash, but it must carry the Merkle root generated by these read-write set hashes (i.e. the block read-write set hash), so that it can be determined whether there is indeed a problem with the read-write set.

[0200] 1.2 Read-Write Set Request or Response

[0201] When a slave node discovers that its read-write set is inconsistent with the read-write set indicated in the proposal message, it needs to obtain the corresponding information from other nodes. This information is the read set information read from the snapshot when the node executes the transaction, that is, the key information read from the snapshot.

[0202] Figure 10 shows a schematic diagram of the transaction execution process. Reading from snapshots is done because the read sets generated during transaction execution come from multiple sources. As shown in Figure 10, reads are prioritized from the write set, then the read set, and finally from the snapshot. The overall data flow for transaction execution is shown in Figure 10, and transaction execution is ultimately based on the transaction context.

[0203] FIG11 is a schematic diagram of generating a read set for other nodes. For other nodes, the process of generating a read set is shown in FIG11 .

[0204] For the process that needs to obtain the read set, the propagation and response messages are shown in Figure 7. In practice, the request and response can be matched with each other. For different combinations, the node needs to adopt different processing procedures.

[0205] The present application proposes a method for repairing blockchain state data, and the overall processing flow is shown in FIG5 . It should be noted that: to ensure the security of decision-making, the information in the read set must meet the f+1 condition before it can be used. f+1 means that there must be an honest node that has responded, and then the data in the response message can be used.

[0206] The beneficial effects of the technical solution of this application include:

[0207] The StateDB synchronization process can be completed at the same time as consensus, without relying on HistoryDB. Because the operation is carried out during the consensus process, on the one hand, the processing flow is completed automatically, and on the other hand, it will not affect the normal consensus. The state data can be repaired during the consensus process, thereby ensuring the security of the entire blockchain while effectively improving the consensus processing efficiency of the blockchain.

[0208] It should be understood that, although the steps in the flowcharts of the above embodiments are shown in sequence as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be performed in other orders. Moreover, at least a portion of the steps in the flowcharts of the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily performed at the same time, but can be performed at different times. The execution order of these steps or stages is not necessarily to be performed in sequence, but can be performed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0209] Based on the same inventive concept, embodiments of the present application also provide a blockchain state data repair device for implementing the aforementioned blockchain state data repair method. The solution provided by this device is similar to the solution described in the aforementioned method. Therefore, the specific limitations of the one or more blockchain state data repair device embodiments provided below can be found in the limitations of the blockchain state data repair method described above and will not be repeated here.

[0210] In one embodiment, as shown in FIG12 , a state data repair device for a blockchain is provided, including: an acquisition module 1202 , an execution module 1204 , and a repair module 1206 , wherein:

[0211] The acquisition module 1202 is used to obtain the status data maintained by the first node itself when receiving the proposal message broadcast by the second node in the blockchain system, where the proposal message indicates a transaction task, result information for the transaction task, and a block identifier.

[0212] The execution module 1204 is used to execute the transaction task in the proposal message based on the status data and obtain result information.

[0213] The acquisition module 1202 is also used to obtain read set information corresponding to the block identifier in the proposal message from snapshots of other nodes in the blockchain system when the result information obtained by executing the transaction task is inconsistent with the result information indicated by the proposal message. The other nodes are nodes in the blockchain system other than the first node.

[0214] The repair module 1206 is used to repair the state data based on the read set information to obtain repaired state data. The repaired state data is used to re-execute the transaction task to obtain an execution result.

[0215] In one embodiment, the result information includes an execution result and a transaction read-write set; the acquisition module 1202 is further used to obtain status data from a status database maintained by the first node itself when receiving a proposal message broadcast by a second node in the blockchain system; obtain a contract corresponding to the transaction task in the proposal message; the execution module 1204 is further used to execute the transaction task in the proposal message based on the contract and status data, and obtain an execution result and a transaction read-write set.

[0216] In one embodiment, the result information includes the transaction read-write set corresponding to the transaction task, the proposal message, and an indication of a transaction read-write set hash value determined based on the transaction read-write set corresponding to the transaction task; the device also includes: a voting module, used to determine the transaction read-write set hash value of the transaction task based on the transaction read-write set; used to compare the transaction read-write set hash value with the transaction read-write set hash value indicated by the proposal message to obtain a comparison result; used to generate a voting message of the first node in one round based on the comparison result; when receiving a voting message of another node in one round broadcasted by other nodes, based on the voting message of the first node in one round and the voting message of the other nodes in one round, determine the voting message of the first node in another round; when receiving a voting message of another node in another round broadcasted by other nodes, based on the voting message of the first node in one round and the voting message of the other nodes in one round, determine the consensus result of the block corresponding to the block identifier.

[0217] In one embodiment, the voting module is further used to obtain the read set information corresponding to the block identifier in the proposal message from the snapshot of at least one node among the other nodes when the comparison result indicates that the transaction read-write set hash value in the result information is inconsistent with the transaction read-write set hash value indicated by the proposal message.

[0218] In one embodiment, the voting module is further used to obtain the number of fault-tolerant nodes in the blockchain system, determine a target number based on the number of fault-tolerant nodes, and the target number is greater than the number of fault-tolerant nodes; select the target number of nodes from other nodes; and search for read set information corresponding to the block identifier in the proposal message from a snapshot of the target number of nodes.

[0219] In one embodiment, the voting module is also used to wait for other nodes to execute the transaction tasks in the proposal message when the read set information is not found, so that other nodes can update the snapshot after the execution is completed, and search for the read set information corresponding to the block identifier in the updated snapshot.

[0220] In one embodiment, the device further includes: a joining module, a sending module, and a processing module.

[0221] The adding module is used to add the transaction identifier of the transaction task to the target set when the comparison result indicates that the transaction read-write set hash value in the result information is inconsistent with the transaction read-write set hash value indicated by the proposal message.

[0222] The sending module is used to send a broadcast message for obtaining read set information, where the broadcast message includes the transaction identifier of the transaction task in the target set, so that other nodes return corresponding response messages based on the transaction identifier of the transaction task in the target set.

[0223] The processing module is used to deserialize the response message when receiving it from other nodes, and obtain the deserialized data structure; the data in the data structure is used as the read set information corresponding to the block identifier in the proposal message.

[0224] In one embodiment, the repair module 1206 is further used to determine the number of response messages when receiving response messages returned by other nodes; when the number of response messages is greater than or equal to the target number and the read set information in each response message is consistent, the state data is repaired based on the read set information. The target number is determined based on the number of fault-tolerant nodes in the blockchain system, and the target number is greater than the number of fault-tolerant nodes.

[0225] In one embodiment, the result information includes the transaction read-write set corresponding to the transaction task, and the proposal message indicates a first block read-write set hash value. The first block read-write set hash value is generated based on the transaction read-write sets of all transaction tasks in the block corresponding to the block identifier.

[0226] Acquisition module 1202 is further configured to determine a second block read / write set hash value based on the transaction read / write set of the transaction task. If the second block read / write set hash value is inconsistent with the first block read / write set hash value, the acquisition module 1202 acquires read set information corresponding to the block identifier in the proposal message from a snapshot of at least one of the other nodes.

[0227] In one embodiment, the repair module 1206 is further configured to perform reliability verification on the read set information to obtain a verification result; when the verification result indicates that the read set information is credible, the status data is repaired based on the read set information.

[0228] In one embodiment, the read set information includes key-value pair information, and the repair module 1206 is further configured to update data in the local state database based on the key-value pair information, and use the updated data as repaired state data.

[0229] In one embodiment, the execution module 1204 is further configured to deserialize the proposal message to obtain a deserialized proposal message; and execute the transaction task in the deserialized proposal message based on the state data.

[0230] In one embodiment, the execution module 1204 is further configured to perform validity verification on the deserialized proposal message to obtain a verification result; when the verification result indicates successful verification, the transaction task in the deserialized proposal message is executed based on the status data.

[0231] In one embodiment, the execution module 1204 is further configured to discard the proposal message when the verification result indicates that the verification fails.

[0232] Each module in the aforementioned blockchain state data repair device can be implemented in whole or in part through software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in hardware form, or can be stored in a computer device's memory in software form, so that the processor can call and execute the corresponding operations of each module.

[0233] In one embodiment, a computer device is provided, which may be a server. Its internal structure diagram may be as shown in Figure 13. The computer device includes a processor, memory, an input / output (I / O) interface, and a communication interface. The processor, memory, and I / O interface are connected via a system bus, and the communication interface is connected to the system bus via the I / O interface. The processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer-readable instructions, and a database. The internal memory provides an environment for the operation of the operating system and computer-readable instructions in the non-volatile storage medium. The database of the computer device is configured to store blockchain status data. The I / O interface of the computer device is configured to exchange information between the processor and external devices. The communication interface of the computer device is configured to communicate with external terminals via a network connection. When executed by the processor, the computer-readable instructions implement a method for repairing blockchain status data.

[0234] Those skilled in the art will understand that the structure shown in FIG13 is merely a block diagram of a portion of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different arrangement of components.

[0235] In one embodiment, a computer device is provided, including a memory and a processor. The memory stores computer-readable instructions, and the processor implements the steps in the above-mentioned method embodiments when executing the computer-readable instructions.

[0236] In one embodiment, a computer-readable storage medium is provided, on which computer-readable instructions are stored. When the computer-readable instructions are executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0237] In one embodiment, a computer program product is provided, comprising computer-readable instructions, which implement the steps in the above-mentioned method embodiments when executed by a processor.

[0238] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions.

[0239] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing the relevant hardware through computer-readable instructions. The computer-readable instructions can be stored in a non-volatile computer-readable storage medium. When the computer-readable instructions are executed, they can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, database or other media used in the embodiments provided in this application may include at least one of non-volatile and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory may include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchains. The processor involved in the various embodiments provided herein may be, but are not limited to, a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic unit, a data processing logic unit based on quantum computing, and the like.

[0240] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0241] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art could make various modifications and improvements without departing from the spirit of the present application, all of which fall within the scope of protection of the present application. Therefore, the scope of protection of the present patent application shall be determined by the appended claims.

Claims

1. A method for repairing state data of a blockchain, performed by a computer device maintaining a first node in a blockchain system, the method comprising: When receiving a proposal message broadcasted by a second node in the blockchain system, obtaining state data maintained by the first node itself, the proposal message indicating a transaction task, result information for the transaction task, and a block identifier; Execute the transaction task in the proposal message based on the status data to obtain result information; When the result information obtained by executing the transaction task is inconsistent with the result information indicated by the proposal message, obtaining read set information corresponding to the block identifier in the proposal message from snapshots of other nodes in the blockchain system, wherein the other nodes are nodes in the blockchain system other than the first node; and The state data is repaired based on the read set information to obtain repaired state data, and the repaired state data is used to re-execute the transaction task to obtain an execution result.

2. According to the method of claim 1, the result information includes the execution result and the transaction read-write set; When receiving the proposal message broadcasted by the second node in the blockchain system, obtaining the state data maintained by the first node itself includes: When receiving a proposal message broadcasted by a second node in the blockchain system, obtaining state data from a state database maintained by the first node itself; The executing the transaction task in the proposal message based on the status data to obtain result information includes: A contract corresponding to the transaction task in the proposal message is obtained, and the transaction task in the proposal message is executed based on the contract and the status data to obtain the execution result and the transaction read-write set.

3. According to the method of claim 1 or 2, the result information includes the transaction read-write set corresponding to the transaction task, and the proposal message further indicates a transaction read-write set hash value determined based on the transaction read-write set corresponding to the transaction task; The method further comprises: Based on the transaction read-write set, determining the transaction read-write set hash value of the transaction task; Compare the transaction read-write set hash value with the transaction read-write set hash value indicated by the proposal message to obtain a comparison result; Based on the comparison result, generating a round of voting messages for the first node; When receiving a round of voting messages of other nodes broadcasted by the other nodes, determining another round of voting messages of the first node based on the first round of voting messages of the first node and the other round of voting messages of the other nodes; When another round of voting messages of other nodes broadcasted by the other nodes are received, the consensus result of the block corresponding to the block identifier is determined based on the another round of voting messages of the first node and the another round of voting messages of the other nodes.

4. The method according to claim 3, when the result information obtained by executing the transaction task is inconsistent with the result information indicated by the proposal message, obtaining the read set information corresponding to the block identifier in the proposal message from the snapshots of other nodes in the blockchain system, comprising: When the comparison result indicates that the transaction read-write set hash value in the result information is inconsistent with the transaction read-write set hash value indicated by the proposal message, the read set information corresponding to the block identifier in the proposal message is obtained from a snapshot of at least one of the other nodes.

5. According to the method of claim 4, obtaining the read set information corresponding to the block identifier in the proposal message from the snapshot of at least one of the other nodes comprises: Obtaining the number of fault-tolerant nodes in the blockchain system, and determining a target number based on the number of fault-tolerant nodes, wherein the target number is greater than the number of fault-tolerant nodes; Select the target number of nodes from the other nodes; From the snapshots of the target number of nodes, search for read set information corresponding to the block identifier in the proposal message.

6. The method according to claim 5, further comprising: When the read set information is not found, wait for the other nodes to execute the transaction tasks in the proposal message. The other nodes are enabled to update the snapshot after the execution is completed, and search for the read set information corresponding to the block identifier in the updated snapshot.

7. The method according to any one of claims 3 to 6, further comprising: When the comparison result indicates that the transaction read-write set hash value in the result information is inconsistent with the transaction read-write set hash value indicated by the proposal message, adding the transaction identifier of the transaction task to the target set; The acquiring, from snapshots of other nodes in the blockchain system, read set information corresponding to the block identifier in the proposal message includes: Sending a broadcast message for acquiring the read set information, wherein the broadcast message includes a transaction identifier of the transaction task in the target set, so that the other nodes return a corresponding response message based on the transaction identifier of the transaction task in the target set; When receiving the response message returned by the other node, deserialize the response message to obtain a deserialized data structure; The data in the data structure is used as the read set information corresponding to the block identifier in the proposal message.

8. The method according to claim 7, further comprising: When receiving the response message returned by the other node, determining the number of response messages; When the number of response messages is greater than or equal to the target number, and the read set information in each of the response messages is consistent, the step of repairing the state data based on the read set information is performed, and the target number is determined based on the number of fault-tolerant nodes in the blockchain system, and the target number is greater than the number of fault-tolerant nodes.

9. According to the method according to any one of claims 1 to 3, the result information includes the transaction read-write set corresponding to the transaction task, the proposal message indicates a first block read-write set hash value, and the first block read-write set hash value is generated based on the transaction read-write sets of all transaction tasks in the block corresponding to the block identifier, and the method further includes: Based on the transaction read-write set of the transaction task, determine the hash value of the second block read-write set; When the result information obtained by executing the transaction task is inconsistent with the result information indicated by the proposal message, obtaining the read set information corresponding to the block identifier in the proposal message from the snapshots of other nodes in the blockchain system, including: When the second block read-write set hash value is inconsistent with the first block read-write set hash value, the read set information corresponding to the block identifier in the proposal message is obtained from a snapshot of at least one of the other nodes.

10. The method according to any one of claims 1 to 9, further comprising: Performing reliability verification on the read set information to obtain a verification result; When the verification result indicates that the read set information is credible, the step of repairing the state data based on the read set information is performed.

11. The method according to any one of claims 1 to 10, wherein the read set information includes key-value pair information, and the repairing the state data based on the read set information to obtain the repaired state data comprises: The data in the local state database is updated based on the key-value pair information, and the updated data is used as the repaired state data.

12. The method according to any one of claims 1 to 11, further comprising: Deserialize the proposal message to obtain the deserialized proposal message; The executing the transaction task in the proposal message based on the state data includes: Execute the transaction task in the deserialized proposal message based on the state data.

13. The method according to claim 12, further comprising: Performing a validity verification on the deserialized proposal message to obtain a verification result; When the verification result indicates that the verification is successful, the step of executing the transaction task in the deserialized proposal message based on the status data is performed.

14. The method according to claim 13, further comprising: When the verification result indicates that the verification fails, the proposal message is discarded.

15. A state data repair device for a blockchain, the device comprising: an acquisition module, configured to acquire state data maintained by the first node itself upon receiving a proposal message broadcasted by the second node in the blockchain system, wherein the proposal message indicates a transaction task, result information for the transaction task, and a block identifier; An execution module, configured to execute the transaction task in the proposal message based on the status data to obtain result information; The acquisition module is further configured to acquire, when the result information obtained by executing the transaction task is inconsistent with the result information indicated by the proposal message, the read set information corresponding to the block identifier in the proposal message from the snapshots of other nodes in the blockchain system, wherein the other nodes are nodes in the blockchain system other than the first node; and A repair module is used to repair the state data based on the read set information to obtain repaired state data, and the repaired state data is used to re-execute the transaction task to obtain an execution result.

16. A computer device comprising a memory and a processor, wherein the memory stores computer-readable instructions, and the processor implements the method according to any one of claims 1 to 14 when executing the computer-readable instructions.

17. A computer-readable storage medium having computer-readable instructions stored thereon, wherein the computer-readable instructions implement the method according to any one of claims 1 to 14 when executed by a processor.

18. A computer program product comprising computer readable instructions, wherein when the computer readable instructions are executed by a processor, the method according to any one of claims 1 to 14 is implemented.

Images