Block chain state data recovery method and device, computer equipment and storage medium

Abstract

The invention relates to a block chain state data recovery method and device, computer equipment, a storage medium and a computer program product. The method comprises the following steps: when a proposal message broadcasted by a target node is received, obtaining self-maintained state data; executing a 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 carried in the proposal message, obtaining read set information corresponding to a block identifier in the proposal message from snapshots of other nodes; restoring the state data based on the read set information to obtain restored state data; the repaired state data is used for re-executing the transaction task to obtain a new execution result. By adopting the method, the state data can be repaired in the consensus process, so that the consensus processing efficiency of the block chain is effectively improved. The technology can be applied to the field of intelligent transportation.

Description

Technical Field

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

[0002] Blockchain is a new decentralized distributed ledger technology that can safely store transactions or other data. The characteristics are that the information stored on the blockchain cannot be forged or tampered with. The blockchain consensus algorithm drives each node on the blockchain to participate in the transaction verification process to ensure that transactions on the blockchain are confirmed and credible. In order to ensure the security of data and information, during the blockchain consensus process, the node will verify each transaction task in the proposal message, that is, the node will execute the transaction tasks contained in the proposal message one by one. The status data will be used in the actual transaction task execution process. Although the status data stored locally by the node is usually stored in a database, it does not mean that there is no problem with database storage. Some status data may be damaged due to some special reasons, such as power failure before the data is written or the disk corresponding to the file is damaged, so the lost or damaged status data needs to be repaired.

[0003] However, in the current state data repair method of the blockchain, the method usually adopted is to obtain the state data from an approved node and directly copy the state data of the node to the local, but this processing process 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 a normal consensus process, or causing a consensus jam; or, if the node verifies each transaction task 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. Summary of the invention

[0004] Based on this, it is necessary to provide a blockchain consensus method, device, computer equipment, computer-readable storage medium and computer program product to address the above-mentioned technical problems, which can complete the repair of status data during the consensus process, thereby effectively improving the consensus processing efficiency of the blockchain.

[0005] In the first aspect, the present application provides a method for repairing the state data of a blockchain. The method comprises: upon receiving a proposal message broadcast by a target node, obtaining the state data maintained by itself; executing 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 carried in the proposal message, obtaining the read set information corresponding to the block identifier in the proposal message from the snapshot of other nodes; repairing 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.

[0006] In the second aspect, the present application also provides a state data repair device for a blockchain. The device includes: an acquisition module, which is used to acquire the state data maintained by itself when receiving a proposal message broadcast by a target node; an execution module, which is used to execute the transaction task in the proposal message based on the state data to obtain result information; the acquisition module is also used to acquire the read set information corresponding to the block identifier in the proposal message from the snapshot of other nodes when the result information is inconsistent with the result information carried in the proposal message; a repair module, which is used to 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.

[0007] In a third aspect, the present application also provides a computer device. The computer device includes a memory and a processor, the memory stores a computer program, and the processor implements the following steps when executing the computer program: upon receiving a proposal message broadcast by a target node, obtain the state data maintained by itself; execute 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 carried in the proposal message, obtain the read set information corresponding to the block identifier in the proposal message from the snapshot of other nodes; 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.

[0008] In a fourth aspect, the present application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the following steps are implemented: upon receiving a proposal message broadcast by a target node, obtaining the state data maintained by itself; executing 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 carried in the proposal message, obtaining the read set information corresponding to the block identifier in the proposal message from the snapshot of other nodes; repairing 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 a new execution result.

[0009] In a fifth aspect, the present application also provides a computer program product. The computer program product includes a computer program, which implements the following steps when executed by a processor: upon receiving a proposal message broadcast by a target node, obtain the state data maintained by itself; execute 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 carried in the proposal message, obtain the read set information corresponding to the block identifier in the proposal message from the snapshot of other nodes; 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.

[0010] The state data repair method, device, computer equipment, storage medium and computer program product of the above-mentioned blockchain obtain the state data maintained by itself when receiving the proposal message broadcast by the target node; execute 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 carried in the proposal message, 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 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 node is inconsistent with the result information carried in the proposal message, the read set information corresponding to the block identifier in the proposal message obtained by the 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 repair the local state data maintained by itself based on the read set information obtained from the snapshots of other nodes to obtain the repaired state data, and then re-execute the transaction task based on the repaired state data. In this way, the node can accurately verify whether there is a problem with the state data maintained by 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. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 This is an optional structural diagram of a distributed system 100 applied to a blockchain system in an embodiment;

[0012] Figure 2 An optional schematic diagram of a block structure in an embodiment;

[0013] Figure 3 A flowchart of a method for repairing state data of a blockchain in one embodiment;

[0014] Figure 4 A schematic diagram of the overall process of state data repair in one embodiment;

[0015] Figure 5 This is a schematic diagram of the overall process of a method for repairing state data of a blockchain in one embodiment;

[0016] Figure 6 A schematic diagram of information carried by a proposal message in one embodiment;

[0017] Figure 7 A schematic diagram of obtaining a broadcast message of a read set and a response message in one embodiment;

[0018] Figure 8 A schematic diagram of using the HistoryDB database to repair data in a traditional manner in one embodiment;

[0019] Fig. 9 A schematic diagram of two different methods of repairing data in a traditional manner in one embodiment;

[0020] Fig.10 A schematic diagram of a transaction execution process in one embodiment;

[0021] Fig.11 A schematic diagram of generating a read set for other nodes in one embodiment;

[0022] Fig.12 It is a structural block diagram of a state data repair device of a blockchain in one embodiment;

[0023] Fig.13 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0024] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0025] 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 in a specific order or sequence where permitted, so that the embodiments of the present application described here can be implemented in an order other than that illustrated or described here.

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

[0027] Take the distributed system as the blockchain system as an example, see Figure 1 , Figure 1It is an optional structural diagram of the distributed system 100 provided by the embodiment of the present invention applied to the blockchain system, which is formed by multiple nodes (any form of computing devices in the access network, such as servers, user terminals) and clients, and a peer-to-peer network is formed between the nodes. The Peer To Peer protocol is an application layer protocol running on the Transmission Control Protocol (TCP). In a distributed system, any machine such as a server or a terminal can join and become a node, and the node includes a hardware layer, an intermediate layer, an operating system layer, and an application layer.

[0028] See also Figure 1 The functions of each node in the blockchain system shown include:

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

[0030] In addition to the routing function, the node can also have the following functions:

[0031] 2) Applications are deployed in the blockchain to implement specific businesses 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.

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

[0033] 2.1) Wallet, used to provide the function of conducting electronic currency transactions, including initiating transactions (i.e., sending the transaction record of the current transaction to other nodes in the blockchain system. After the other nodes successfully verify the transaction, as a response to acknowledge the validity of the transaction, the transaction record data is stored in the temporary block of the blockchain; of course, the wallet also supports querying the remaining electronic currency in the electronic currency address;

[0034] 2.2) Shared ledger, which is used to provide functions such as storage, query and modification of account data. The record data of the operation on the account data is sent to other nodes in the blockchain system. After other nodes verify the validity, as a response to acknowledging the validity of the account data, the record data is stored in a temporary block, and a confirmation can also be sent to the node that initiated the operation.

[0035] 2.3) Smart contracts are computerized protocols that can execute the terms of a contract. They are implemented by deploying code on a shared ledger that is executed when certain conditions are met. The code is used to complete automated transactions based on actual business needs, such as querying the logistics status of the goods purchased by the buyer 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 for processing received information.

[0036] 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.

[0037] See also Figure 2 , Figure 2 This is an optional schematic diagram of the block structure provided by an embodiment of the present invention. Each block includes the hash value of the transaction record stored in this block (the hash value of this block) and the hash value of the previous block. Each block is connected by the hash value to form a blockchain. In addition, the block can also include information such as the timestamp when the block was generated. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains relevant information for verifying the validity of its information (anti-counterfeiting) and generating the next block.

[0038] In one embodiment, Figure 3 As shown, a method for repairing the state data of a blockchain is provided, and the method is applied to Figure 1 The node cluster in the blockchain system in the example is used to illustrate, including the following steps:

[0039] Step 302, upon receiving the proposal message broadcast by the target node, obtain the state data maintained by itself.

[0040] Among them, blockchain is a chain composed of blocks. Each block stores certain information, and they are connected into a chain in the order of their generation. This chain is stored in all servers. As long as there is a server in the entire system that can work, the entire blockchain is safe. These servers are called nodes in the blockchain system, and they provide storage space and computing power support for the entire blockchain system. If you want to modify the information in the blockchain, you must obtain the consent of more than half of the nodes and modify the information in all nodes. These nodes are usually in the hands of different entities, so it is extremely difficult to tamper with the information in the blockchain. Compared with traditional networks, blockchain has two core characteristics: one is that data is difficult to tamper with, and the other is decentralization. Based on these two characteristics, the information recorded in the blockchain is more authentic and reliable, which can help solve the problem of people's distrust of each other. The types of blockchains include public chains, joint chains, private chains, etc. The blockchain system in this application can be a consortium chain system.

[0041] 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 verifies the proposal message and confirms 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 proposals for new blocks, which are verified by the slave nodes to confirm whether the blocks in the proposal can reach a consensus. Among them, BFT (Byzantine Fault Tolerance), that is, Byzantine Fault Tolerance, is a consensus mechanism.

[0042] The target node refers to the node in the node cluster that is responsible for generating proposal messages for new blocks. For example, the target node in this application is the master node, and the master node refers to the node in the node cluster that is responsible for generating proposal messages for new blocks. For example, in the underlying blockchain model based on BFT consensus, the master node can be rotated. Assume that a blockchain system includes 3 nodes, namely node 1, node 2 and node 3. When a new block is generated in the blockchain system, each node in the node cluster (node ​​1, node 2 and node 3) can determine whether it is a master node. For example, each node in the node cluster can determine whether the block generation condition is met based on the parameters in the block maintained by itself; when a node (node ​​1) determines that it meets the block generation condition, the node 1 becomes the master node.

[0043] A slave node refers to 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 a 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.

[0044] A proposal message is a communication message 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 carrying a proposal. For example, a proposal message carries proposal 1, and proposal 1 is generated for the newly generated block 1.

[0045] 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 can be understood that the data generated during the execution of a transaction task is stored in the local database maintained by each node in the blockchain system. For example, each node can store state data through a state database and store transaction task information through a block database, such as transaction information sent by users and block header information.

[0046] Specifically, after a newly created blockchain is started, when a new block is generated in the blockchain and consensus is required, the master node in the node cluster can capture a preset number of transaction tasks from the transaction pool, and encapsulate the captured transaction tasks into a proposal message of the new block, and broadcast the proposal message to the slave nodes in the blockchain, so that the slave nodes can reach a consensus on the new block based on the transaction tasks in the proposal message. That is, the master node in the present application can package the captured preset number of 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 receives the proposal message, each slave node can verify all the transaction tasks in the proposal message to obtain a verification result; when the verification result indicates that at least one of the transaction tasks in the proposal message is illegal, the slave node generates a voting message that does not agree with the consensus of the new block. 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 consensus of the new block 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 can also add the new block to the local account book.

[0047] Among them, when the slave node verifies the transaction task in the proposal message, the slave node needs to obtain the status data maintained by itself locally, that is, when each slave node receives the proposal message broadcast by the master node, each slave node can obtain the status data maintained locally. For example, when a slave node in the node cluster receives the proposal message broadcast by the master node, the slave node can obtain the status data from the status database maintained by itself.

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

[0049] For example, in the underlying blockchain model based on 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 it maintains; when a node determines that it meets the block generation conditions, the node is 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 consensus block.

[0050] Furthermore, when 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 of 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 (node ​​2) in the node cluster receives the proposal message broadcast by the master node, the slave node can obtain the status data from the local state database (StateDB) maintained by itself.

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

[0052] Among them, the transaction task in the proposal message refers to the transaction task obtained from the transaction pool when the master node builds a block. In some cases, the transaction task in this application can also be called a transaction. For example, the transaction task in this application can be the transaction task screened from the transaction pool by the master node in order from high to low according to the processing priority corresponding to the contract of the transaction task.

[0053] Result information refers to the verification result obtained by the node from the legality verification of each transaction task in the proposal message. In some cases, result information can also be called legality verification result. For example, the result information in this application may include execution result and read-write set, where execution result refers to the result returned by the contract corresponding to the execution transaction task.

[0054] The read-write set refers to the data generated during the execution of a transaction task. In some cases, the read-write set is the status data.

[0055] 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.

[0056] Specifically, after each node in the node cluster receives the proposal message broadcast by the target node and obtains the status data maintained by 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.

[0057] Furthermore, after each node obtains 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 carried in the proposal message to obtain the corresponding comparison result.

[0058] 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 carried in the proposal message, and can also obtain the corresponding comparison result.

[0059] For example, in the underlying blockchain model based on BFT consensus, when a slave node (node ​​2) in the node cluster receives a proposal message A broadcast by the master node (node ​​1), the slave node can obtain the state data from the local state database (StateDB) maintained by itself, and execute each transaction task in the proposal message based on the state data (in parallel or serially), and obtain the execution result and read-write set corresponding to each transaction task; further, when the proposal message A carries the transaction read-write set hash value of each transaction task, the slave node can calculate each transaction task based on the read-write set corresponding to each transaction task. The transaction read-write set hash value of the 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. For example, the slave node can calculate the transaction read-write set hash value R of the transaction task 1 according to 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.

[0060] 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 slave 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 read-write sets corresponding to the obtained transaction tasks, 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, and the comparison result can also be obtained: consistent.

[0061] Step 306: When the result information is inconsistent with the result information carried in the proposal message, obtain the read set information corresponding to the block identifier in the proposal message from the snapshot of other nodes.

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

[0063] Other nodes refer to other nodes in the node cluster except 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.

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

[0065] A block ID is an identifier used to uniquely identify a block.

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

[0067] Specifically, 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 carried in the proposal message to obtain the corresponding comparison result.

[0068] 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 carried in the proposal message, and can also obtain the corresponding comparison result.

[0069] Furthermore, when the comparison result indicates that the result information obtained by the node is inconsistent with the result information carried in the proposal message, the 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 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 node can obtain the read set information corresponding to the block identifier in the proposal message from the response messages returned by other nodes.

[0070] 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. When a slave node (node ​​2) in the node cluster receives a proposal message A broadcast by the master node (node ​​1), the slave node can obtain the state data from the local state database (StateDB) maintained by itself, and execute each transaction task in the proposal message based on the state data (in parallel or serially), and obtain the execution result and read-write set corresponding to each transaction task; further, when the proposal message A carries the transaction read-write set hash value of each transaction task, the slave 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 proposal message. By comparing the transaction read-write set hash values ​​of each transaction task carried in the proposal message A, the comparison result corresponding to each transaction task can be obtained. For example, the slave node can calculate the transaction read-write set hash value R of the transaction task 1 according to 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=2 of the transaction task 1 carried in the proposal message A, and obtain the comparison result corresponding to the transaction task 1: inconsistent, that is, when the transaction read-write set hash value R=1 of the transaction task 1 calculated by the slave node is inconsistent with the transaction read-write set hash value R=2 of the transaction task 1 carried in the proposal message A, the slave 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).

[0071] 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 a new execution result.

[0072] Among them, the repaired state data refers to the state data obtained after updating the local state data maintained by itself. For example, when node A receives the proposal message broadcast by the master node, node A obtains the state data maintained by itself as A01. Node A repairs the state data A01 maintained by itself based on the read set information A02 obtained from other nodes, and obtains the repaired state data A02. That is, the repaired state data may be different from or the same as the state data before the repair.

[0073] Specifically, after the node obtains the read set information corresponding to the block identifier in the proposal message from the snapshot of other nodes, the 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 node can repair the status data maintained by itself based on the read set information to obtain repaired status data; further, after the node obtains the repaired status data, the 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 carried in the proposal message to obtain a second comparison result.

[0074] 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. When a slave node (node ​​2) in the node cluster receives a proposal message A broadcast by the master node (node ​​1), the slave node can obtain the state data A01 from the local state database (StateDB) maintained by itself, and execute each transaction task in the proposal message based on the state data A01 (in parallel or serially), and obtain the execution result and read-write set corresponding to each transaction task; further, when the proposal message A carries When the transaction read-write set hash value of each transaction task is obtained, the slave node can calculate the transaction read-write set hash value of each transaction task according to 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, and obtain the comparison result corresponding to each transaction task. For example, the slave node can calculate the transaction read-write set hash value R of transaction task 1 according to the obtained read-write set 1 corresponding to transaction task 1, and compare the calculated transaction read-write set hash value of transaction task 1 with the transaction read-write set hash value R of transaction task 1. R=1 is compared with the transaction read-write set hash value R=2 of the transaction task 1 carried in the proposal message A, and the comparison result corresponding to the transaction task 1 is obtained as follows: inconsistent, that is, when the transaction read-write set hash value R=1 of the transaction task 1 calculated by the slave node is inconsistent with the transaction read-write set hash value R=2 of the transaction task 1 carried in the proposal message A, the slave 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). Assuming that the slave 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), The read set information corresponding to the block identifier in the proposal message is A02. When the slave node (node ​​2) verifies that the read set information A02 is credible, the node (node ​​2) can repair the state data A01 maintained by itself based on the read set information A02 to obtain the repaired state data A02, and re-execute each transaction task in the proposal message A based on the repaired state data A02 to 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 carried in the proposal message, and obtain the second comparison result: consistent.

[0075] In this embodiment, when a slave node receives a proposal message broadcast by a target node, the slave node obtains the status data maintained by itself, and 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 carried in the proposal message, the slave node obtains the read set information corresponding to the block identifier in the proposal message from the snapshot of other nodes; the slave node repairs the status data based on the read set information to obtain the repaired status data; the repaired status data is used to re-execute the transaction task to obtain a new execution result. 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 node is inconsistent with the result information carried in the proposal message, the read set information corresponding to the block identifier in the proposal message obtained by the 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 repair the local state data maintained by itself based on the read set information obtained from the snapshots of other nodes to obtain the repaired state data, and then re-execute the transaction task based on the repaired state data. In this way, the node can accurately verify whether there is a problem with the state data maintained by 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.

[0076] In one embodiment, the result information includes the execution result and the transaction read-write set; when receiving the proposal message broadcast by the target node, the step of obtaining the state data maintained by itself includes:

[0077] When receiving the proposal message broadcast by the target node, it obtains the state data from the state database maintained by itself;

[0078] The executing the transaction task in the proposal message based on the status data to obtain result information includes:

[0079] Get the contract corresponding to the transaction task in the proposal message, and execute the transaction task in the proposal message based on the contract and status data to obtain the execution result and transaction read-write set.

[0080] Among them, the transaction read-write set refers to the read-write set generated in the process of executing each transaction task. For example, the read-write set generated in the process of executing transaction task A is read-write set A, and the read-write set generated in the process of executing transaction task B is read-write set B.

[0081] A contract refers to a smart contract. It is not smart in itself, but a piece of code that can implement business logic. This code or logic will be executed through the node virtual machine of the blockchain. For the blockchain system, it requires that the status of all nodes must be consistent, that is, it is a deterministic state machine. Only in this way can the blockchain system reach a consensus, otherwise the entire blockchain cannot operate normally.

[0082] Specifically, under the underlying model of blockchain based on BFT consensus, 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 of 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 (node ​​2) in the node cluster receives the proposal message broadcast by the master node, the slave node can obtain the status data from the local state database (StateDB) maintained by itself.

[0083] Furthermore, the slave node can obtain the contract corresponding to each transaction task in the proposal message 1, and execute the transaction task in the proposal message 1 based on the acquired contract and status data (in parallel or serial), and obtain the execution result and transaction read-write set corresponding to each transaction task in the proposal message 1. For example, assuming that the proposal message 1 contains transaction task A, the slave node can obtain the contract corresponding to transaction task A in the proposal message 1 as save1, and execute the transaction task A based on the acquired contract save1 and the status data A01 maintained by itself, and obtain the execution result S and transaction read-write set K corresponding to the transaction task A.

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

[0085] In one embodiment, the result information includes a transaction read-write set corresponding to the transaction task; the proposal message carries the transaction task and a hash value of the transaction read-write set corresponding to the transaction task; the transaction task in the proposal message is executed based on the state data, and after obtaining the execution result, the method further includes:

[0086] Based on the transaction read-write set, determine the transaction read-write set hash value of the transaction task;

[0087] Compare the transaction read-write set hash value with the transaction read-write set hash value carried in the proposal message to obtain a comparison result;

[0088] Based on the comparison result, generating a first initial voting message;

[0089] When receiving the second initial voting message broadcasted by other nodes, determining the first voting message based on the first initial voting message and the second initial voting message;

[0090] When receiving the second voting message broadcasted by other nodes, based on the first voting message and the second voting message, it is determined that a consensus is reached on the block corresponding to the block identifier.

[0091] 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.

[0092] The first initial voting message and the first voting message are only used to distinguish different rounds of voting messages of the current node. For example, the first initial voting message refers to the first round of voting messages of the current node, and the first voting message refers to the second round of voting messages of the current node.

[0093] The second initial voting message and the second voting message are only used to distinguish different rounds of voting messages of other nodes. For example, the second initial voting message refers to the first round of voting messages of other nodes, and the second voting message refers to the second round of voting messages of other nodes.

[0094] It can be understood that the first initial voting message, the second initial voting message, the first voting message, and the second voting message in the present application are only used to distinguish the voting messages broadcast by different nodes in different rounds.

[0095] Consensus refers to the consensus on the newly generated blocks. Only when the newly generated blocks are verified by the nodes and consensus is reached, can the blocks be uploaded to the blockchain, and each node can store the consensus blocks in the local ledger.

[0096] Specifically, under the underlying model of blockchain based on BFT consensus, 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. The master node can 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 (node ​​2) in the node cluster receives the proposal message 1 broadcast by the master node, the slave node executes the transaction tasks in the proposal message 1 based on the state data maintained by itself, and after obtaining the execution results and transaction read-write sets corresponding to each transaction task, the slave 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 carried in the proposal message to obtain a comparison result;

[0097] Further, the slave node can generate a first initial voting message based on the comparison result; when the slave node receives a second initial voting message broadcast by other nodes, the slave node can generate a first voting message based on the first initial voting message and the second initial voting message; when the slave node receives a second voting message broadcast by other nodes, the slave node can determine whether the block corresponding to the block identifier in the proposal message can reach a consensus based on the first voting message and the second voting message. For example, when the number of voting messages in favor of the consensus of the block in the first voting message and the second voting message meets the preset condition, the slave node can determine that the block has reached a consensus. Wherein, the preset condition refers to the pre-set condition for the block to reach a consensus. For example, the preset condition can be set to 2f+1, f refers to the maximum number of malicious nodes tolerated in this environment. In the Byzantine consensus, it is a 3f+1 model. For example, there are 4 nodes in the entire environment (blockchain system), then f=1 node is allowed to be a malicious node, no more, 2f+1 is the number of correct nodes, that is, when the number of voting messages in favor of the consensus of the block in the voting message meets the number of 2f+1, the block can reach a consensus.

[0098] For example, Figure 4 As shown in FIG. 1 , it is a schematic diagram of the overall process of state data repair. Figure 4 In the underlying blockchain model based on BFT consensus shown in , when 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 the 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; Figure 4As shown in , when a slave node (Node4) in the node cluster receives the proposal message broadcast by the master node, the slave node (Node4) executes the transaction task in the proposal message based on the state data maintained by itself, and after obtaining the execution result and transaction read-write set corresponding to each transaction task, the slave 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 carried in the proposal message to obtain a comparison result;

[0099] Further, the slave node may generate a first initial voting message (Prevote vote) based on the comparison result; when the slave node receives a second initial voting message (Prevote vote) broadcasted by other nodes, the slave node may generate a first voting message (PreCommit vote) based on the first initial voting message (Prevote vote) and the second initial voting message (Prevote vote); when the slave node receives a second voting message (PreCommit vote) broadcasted by other nodes, the slave node may determine whether the block corresponding to the block identifier in the proposal message can reach a consensus based on the first voting message (PreCommit vote) and the second voting message (PreCommit vote), for example, when the number of voting messages in favor of reaching a consensus on the block in the first voting message and the second voting message meets a preset condition, the slave node may determine that a consensus has been reached on the block and submit the ledger; or when the number of voting messages in favor of reaching a consensus on the block in the first voting message and the second voting message does not meet the preset condition, the slave node may determine that a consensus has not been reached on the block, and may enter the next round of consensus processing.

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

[0101] In one embodiment, when the result information is inconsistent with the result information carried in the proposal message, the step of obtaining the read set information corresponding to the block identifier in the proposal message from the snapshot of other nodes includes:

[0102] 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 carried in 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 of the other nodes.

[0103] Specifically, Figure 4 As shown in FIG. 1 , it is a schematic diagram of the overall process of state data repair. Figure 4 In the underlying blockchain model based on BFT consensus shown in , when 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 the 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; Figure 4 As shown in , when a slave node (Node4) in the node cluster receives the proposal message broadcast by the master node, the slave node (Node4) executes the transaction task in the proposal message based on the state data maintained by itself, and after obtaining the execution result and transaction read-write set corresponding to each transaction task, the slave 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 carried in the proposal message to obtain a comparison result;

[0104] When the comparison result indicates that the transaction read-write set hash value obtained by the slave node (Node4) is inconsistent with the transaction read-write set hash value carried in the proposal message, such as Figure 4As shown in , the slave 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). For example, when the comparison result indicates that the transaction read-write set hash value K=4 of transaction task A obtained by the slave node (Node4) is inconsistent with the transaction read-write set hash value K=2 of transaction task A carried in the proposal message, the slave node (Node4) can send a broadcast message (carrying the identifier of transaction task A) for obtaining read set information, 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 messages returned by other nodes. As a result, the synchronization process of state data can be completed at the same time as consensus, without relying on HistoryDB. Because the operation is 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.

[0105] In one embodiment, the step of 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:

[0106] Determine the target number based on the number of fault-tolerant nodes;

[0107] Select the target number of nodes from other nodes;

[0108] From the snapshots of the target number of nodes, find the read set information corresponding to the block ID in the proposal message;

[0109] When the read set information is not found, wait for other nodes to execute the transaction tasks in the proposal message so that other nodes can update the snapshot after the execution is completed, and find the read set information corresponding to the block identifier in the updated snapshot.

[0110] 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.

[0111] Specifically, Figure 4 As shown in, when the comparison result indicates that the transaction read-write set hash value obtained by the slave node (Node4) is inconsistent with the transaction read-write set hash value carried in the proposal message, the slave 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). For example, the slave 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 slave node (Node4) can select any two nodes (Node2 and Node3) from other nodes (Node1, Node2, Node3). Assuming that the slave 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 the transaction tasks in the proposal message. Then, the slave node (Node4) can wait for Node2 and Node3 to complete all the transaction tasks in the proposal message, and update the information in the snapshot after the execution is completed, and search for the read set information corresponding to the block identifier in the updated snapshot information.

[0112] That is, the slave 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 message returned by Node2 and Node3 carries 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 (i.e. TxReadSet) and MerkleRoot (i.e. TxReadHash) corresponding to the block identifier from the response message returned by Node2 and Node3. In addition, if the node (Node4) does not receive the corresponding response message returned by Node2 and Node3 based on the block identifier in the broadcast message within a preset time period, the slave node (Node4) can resend the broadcast message for obtaining read set information (carrying the block identifier in the proposal message, such as BlockHeight) to other nodes in the blockchain. As a result, the synchronization process of state data can be completed at the same time as consensus, without relying on HistoryDB. Because the operation is 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.

[0113] In one embodiment, the method further comprises:

[0114] 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 carried in the proposal message, the transaction identifier of the transaction task is added to the target set;

[0115] The obtaining, from snapshots of other nodes, the read set information corresponding to the block identifier in the proposal message includes:

[0116] Send a broadcast message for obtaining read set information, the broadcast message including 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;

[0117] When receiving a response message returned by other nodes, the response message is deserialized to obtain a deserialized data structure;

[0118] The data in the data structure is used as the read set information corresponding to the block identifier in the proposal message.

[0119] The target set refers to a set of transaction identifiers for storing transaction tasks with inconsistent read / write sets. For example, the target set in the present application may be a set of transaction task IDs with inconsistent read / write sets.

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

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

[0122] Specifically, Figure 4 As shown in FIG. 1 , it is a schematic diagram of the overall process of state data repair. Figure 4 In the underlying blockchain model based on BFT consensus shown in , when 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 the 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; Figure 4As shown in , when a slave node (Node4) in the node cluster receives the proposal message broadcast by the master node, the slave node (Node4) executes the transaction task in the proposal message based on the state data maintained by itself, and after obtaining the execution result and transaction read-write set corresponding to each transaction task, the slave 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 carried in the proposal message to obtain a comparison result;

[0123] When the comparison result indicates that the transaction read-write set hash value K=4 of transaction task A obtained by the slave node (Node4) is inconsistent with the transaction read-write set hash value K=2 of transaction task A carried in the proposal message, the slave node (Node4) can add the transaction identifier TxA of transaction task A to the target set RWIDs; further, the slave node (Node4) can serialize the target set RWIDs and broadcast it to other nodes, that is, the slave 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 slave node (Node4) receives the response message returned by other nodes (Node1, Node2, Node3), the response message is deserialized to obtain the deserialized data structure, and the data in the deserialized data structure is used as the read set information corresponding to the block identifier in the proposal message.

[0124] For example, Figure 5 The figure shows the overall process diagram of the state data repair method of the blockchain. Figure 5 The i shown in the figure indicates the transaction number, Len(Txs) indicates the number of transactions in the transaction set Txs, Len(RWIDs) indicates 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. Figure 5In the process shown in , 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 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 slave node (Node4) in the node cluster receives the proposal message broadcast by the master node, the slave 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 the verification of the legitimacy of the block-generating node and the verification of the legitimacy of the signature.

[0125] Further, when the slave node (Node4) successfully verifies the proposal in the data structure, the slave 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 RWIDs and broadcast them to other nodes, that is, the slave node (Node4) can send a broadcast message for obtaining read set information, and the broadcast message 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 slave node (Node4) receives the response message returned by other nodes (Node1, Node2, Node3), the response message is deserialized into a processable object inside the program, that is, the message structure, and the data in the message structure after deserialization is used as the read set information corresponding to the block identifier in the proposal message. In this way, the synchronization process of state data can be completed at the same time as 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 processing flow, and it also effectively improves the security of data repair.

[0126] In one embodiment, the method further comprises:

[0127] When receiving reply messages returned by other nodes, determining the number of reply messages;

[0128] When the number of reply messages is greater than or equal to the target number, and the read set information in each reply message is consistent, the step of repairing the status data based on the read set information is executed; the target number is determined based on the number of fault-tolerant nodes.

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

[0130] 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 node is allowed to be a malicious node, and no more. f+1 nodes means that there must be an honest node among them.

[0131] Specifically, in Figure 4 In the underlying blockchain model based on BFT consensus shown in , when the comparison result indicates that the transaction read-write set hash value K=4 of transaction task A obtained by the slave node (Node4) is inconsistent with the transaction read-write set hash value K=2 of transaction task A carried in the proposal message, the slave node (Node4) can add the transaction identifier TxA of transaction task A to the target set RWIDs; further, the slave node (Node4) can serialize the target set RWIDs and broadcast it to other nodes, that is, the slave node (Node4) can send a broadcast message for obtaining read set information, and the broadcast information includes the transaction identifiers of each transaction task in the target set RWIDs, so that other nodes can obtain the transaction identifiers of the transaction tasks in the target set based on the transaction identifiers of the transaction tasks in the target set. Return the corresponding reply message; when the slave node (Node4) receives the reply messages returned by other nodes (Node1, Node2, Node3), it determines that the number of reply messages n=3. Further, the slave node (Node4) can determine whether the read set information in the reply messages returned by other nodes (Node1, Node2, Node3) is consistent. Assuming the target number f+1=1+1=2, since the number of reply messages n=3>target number f+1=1+1=2, that is, when the number of reply messages is greater than the target number and the read set information in each reply message is consistent, the slave node (Node4) can execute the step of repairing the status data in the local database maintained by itself based on the read set information.

[0132] For example, Figure 5 As shown in the figure, it is a schematic diagram of the overall process of the state data repair method of the blockchain. Figure 5In the process shown in , 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 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 slave node (Node4) in the node cluster receives the proposal message broadcast by the master node, the slave 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 the verification of the legitimacy of the block-generating node and the verification of the legitimacy of the signature.

[0133] Furthermore, when the slave node (Node4) successfully verifies the proposal in the data structure, the slave 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 slave node (Node4) can send a broadcast message for obtaining read set information, and the broadcast message 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 slave node (Node4) receives other When the nodes (Node1 and Node3) return a response message, the number of response messages n=2 is determined. Further, the slave node (Node4) can determine whether the read set information in the response messages returned by other nodes (Node1, Node3) is consistent. Assuming 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 slave node (Node4) can perform the steps of repairing the state data in the local database maintained by itself based on the read set information. In this way, the synchronization process of the state data 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 processing flow, and it also effectively improves the security of data repair.

[0134] In one embodiment, the result information includes a transaction read / write set corresponding to the transaction task; the proposal message carries the transaction task and a hash value of the first block read / write set; the hash value of the first block read / write set is generated based on the transaction read / write sets of all transaction tasks in the block corresponding to the block identifier; the method further includes:

[0135] Based on the transaction read-write set of the transaction task, determine the hash value of the second block read-write set;

[0136] When the result information is inconsistent with the result information carried in the proposal message, obtaining read set information corresponding to the block identifier in the proposal message from snapshots of other nodes includes:

[0137] 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 the snapshot of at least one node of the other nodes.

[0138] The first block read-write set hash value and the second block read-write set hash value are only used to distinguish the block read-write set hash values ​​obtained by different nodes.

[0139] Specifically, Figure 6 As shown in the figure, it is a schematic diagram of the information carried by the proposal message. Figure 6 Among the information carried by the blocks shown in , some blocks carry the transaction read-write set hash value (RWSetHash), while 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 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 carried in the proposal message to obtain the corresponding comparison result. That is, 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 second block read-write set hash value based on the transaction read-write set of the transaction task; when the second block read-write set hash value is inconsistent with the first block read-write set hash value carried in 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 node of other nodes.

[0140] For example, Figure 6 As shown in , if the proposal message broadcast by the master node does not carry the transaction read-write set hash values ​​corresponding to each transaction task, but carries the block Hash, block height and block read-write set hash value, then in Figure 4In the underlying blockchain model based on BFT consensus shown, when a slave node (Node4) in the node cluster receives the proposal message broadcast by the master node, the slave node (Node4) executes the transaction task in the proposal message based on the state data maintained by itself, and after obtaining the execution results and transaction read-write sets corresponding to each transaction task, the slave 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 carried in the proposal message to obtain the corresponding comparison result. When the second block read-write set hash value is inconsistent with the first block read-write set hash value carried in the proposal message, the slave node (Node4) can obtain the read set information corresponding to the block identifier in the proposal message from the snapshot of at least one node of the other nodes (Node1, Node2, Node3).

[0141] 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 node is inconsistent with the result information carried in the proposal message, the read set information corresponding to the block identifier in the proposal message obtained by the 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 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.

[0142] In one embodiment, after obtaining the read set information corresponding to the block identifier in the proposal message from the snapshot of other nodes, the method further includes:

[0143] Perform reliability verification on the read set information and obtain verification results;

[0144] When the verification result indicates that the read set information is credible, a step of repairing the state data based on the read set information is executed.

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

[0146] Specifically, Figure 4As shown in , when a slave node (Node4) in the node cluster receives the proposal message broadcast by the master node (Node1), the slave node (Node4) executes the transaction task in the proposal message based on the state data maintained by itself, and after obtaining the execution result and transaction read-write set corresponding to each transaction task, the slave 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 carried in the proposal message to obtain a comparison result;

[0147] When the comparison result indicates that the transaction read-write set hash value obtained by the slave node (Node4) is inconsistent with the transaction read-write set hash value carried in the proposal message, such as Figure 4 As shown in, the slave 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 slave 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 slave node (Node4) obtains three read set information corresponding to the block identifier in the proposal message from the snapshots of three nodes among the other nodes (Node1, Node2, Node3), namely, read set A, read set B, and read set C. Then, the slave node (Node4) needs to verify the reliability of the three read set information (read set A, read set B, and read set C) obtained. For example, the slave node (Node4) needs to verify the reliability of the three read set information (read set A, read set B, and read set C) obtained. C), and when the data in the read set information is verified, the slave 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 slave 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, and the slave node (Node4) can execute the steps of repairing the status data maintained by itself based on the read set information (read set A, read set B, and read set C).

[0148] For example, Figure 7 As shown in Figure 1, it is a schematic diagram of obtaining the broadcast message and the response message of the read set. That is, for a node to request to obtain the read set in the snapshot of another node, the specific structure of the broadcast message it sends and the response message it receives is as follows: Figure 7 As shown in Figure 7 As shown, in Figure 7 The structure of two broadcast messages and three response messages are shown in Figure 1. When the transaction read-write set hash value calculated by the slave node (Node4) itself is inconsistent with the transaction read-write set hash value carried in the proposal message, the slave node (Node4) can send a broadcast message for obtaining the read set information. The broadcast message contains the block identifier (block height), that is, Figure 7 In addition, in some cases, the broadcast information may also include a block identifier (block height) and a transaction task identifier (TxID), such as Figure 7 The request broadcast message (2) shown in the figure is used to enable other nodes to return corresponding response messages based on the request broadcast message; that is, the slave node (Node4) in the present application can receive the following response messages: Figure 7 The three types of response messages shown in the figure include response message (1), response message (2) and response message (3), that is, when the slave node (Node4) receives the response message (1), response message (2) and response message (3) returned by other nodes (Node1, Node2, Node3), the slave node (Node4) can verify the data in the response message (1), response message (2) and response message (3). When the verification is passed, the slave node (Node4) needs to further determine the response messages (1), response messages (2) and response messages. Whether the read set information in message (3) is 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 response message (1), response message (2) and response message (3) is credible, then the slave node (Node4) can perform the steps of repairing the state data in the local database maintained by itself based on the read set information in response message (1), response message (2) and response message (3). In this way, the synchronization process of the state data 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 processing flow, and it also effectively improves the security of data repair.

[0149] In one embodiment, the read set information includes key-value pair information; and the step of repairing the state data based on the read set information to obtain the repaired state data includes:

[0150] Based on the key-value pair information, the data in the local state database is updated, and the updated data is used as the repaired state data.

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

[0152] Specifically, when the transaction read-write set hash value K=4 of transaction task A calculated by the slave node (Node4) itself is inconsistent with the transaction read-write set hash value K=2 of transaction task A carried in the proposal message, the slave node (Node4) can send a broadcast message for obtaining read set information (carrying the identifier of the transaction task A), so that other nodes (Node1, Node2, Node3) return corresponding response messages based on the identifier of the 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 the 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. Assume that the slave node (Node4) obtains read set information A01, A02, and A03 from the response messages returned by other nodes (Node1, Node2, and Node3). When the slave 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 itself, and obtain the updated status data A02, and use the updated status data A02 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 carried in the proposal message, and obtain the secondary comparison result. As a result, the slave node can accurately verify whether there is a problem with the status data it maintains, 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.

[0153] In one embodiment, after receiving the proposal message broadcast by the target node, the method further includes:

[0154] Deserialize the proposal message to obtain the deserialized proposal message;

[0155] The executing the transaction task in the proposal message based on the state data includes:

[0156] Execute the transaction tasks in the deserialized proposal message based on the state data.

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

[0158] Specifically, Figure 5 As shown in the figure, it is a schematic diagram of the overall process of the state data repair method of the blockchain. Figure 5 In the process shown in , 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 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 slave node (Node4) in the node cluster receives the proposal message broadcast by the master node, the slave 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 the verification of the legitimacy of the block-generating node and the verification of the legitimacy of the signature.

[0159] Furthermore, when the slave node (Node4) successfully verifies the proposal in the data structure, the slave node (Node4) can execute the transaction tasks contained in the proposal one by one (serially) based on the state data maintained by itself, and add the transaction task IDs with inconsistent transaction read-write set hash values ​​to RWIDs. In this way, the node can accurately verify whether there is a problem with the state data maintained by itself, and can automatically repair 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.

[0160] In one embodiment, the method further comprises:

[0161] Verify the legitimacy of the deserialized proposal message and obtain the verification result;

[0162] When the verification result indicates failure, the proposal message is discarded;

[0163] When the verification result indicates success, the step of executing the transaction task in the deserialized proposal message based on the state data is executed.

[0164] Specifically, Figure 5 As shown in the figure, it is a schematic diagram of the overall process of the state data repair method of the blockchain. Figure 5In the process shown in , 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 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 tasks in the proposal message 1; when a slave node (Node4) in the node cluster receives the proposal message 1 broadcast by the master node, the slave 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 the verification of the legitimacy of the block-generating node, the verification of the legitimacy of the signature, etc.

[0165] Furthermore, when the verification result indicates that the verification fails, the slave node (Node4) can discard the proposal message 1; when the verification result indicates that the verification succeeds, the slave node (Node4) can execute the steps of executing the transaction tasks in the deserialized proposal message (proposal in the data structure) based on the state data, that is, the slave node (Node4) can execute the transaction tasks contained in the proposal one by one (serially) based on the state data maintained by itself, and add the transaction task IDs with inconsistent transaction read-write set hash values ​​to RWIDs. In this way, the node can accurately verify whether there is a problem with the state data maintained by 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.

[0166] 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 the application scenario is as follows:

[0167] When you want to complete the repair of state data while reaching consensus, you can use the above-mentioned blockchain state data repair method, that is, in the blockchain system, when the master node in the node cluster produces a block, the master node broadcasts the proposal message to the slave nodes in the blockchain, so that the slave nodes can reach a consensus on the new block; when the slave node receives the proposal message broadcast by the master node, the slave node obtains the state data maintained by itself, and executes the transaction task in the proposal message based on the state data to obtain the result information; when the result information is inconsistent with the result information carried in 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 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. When the result information obtained by the node's execution is inconsistent with the result information carried in the proposal message, the read set information corresponding to the block identifier in the proposal message obtained by the 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 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.

[0168] The method provided in the embodiment of the present application can be applied to consensus scenarios of various blockchains. The following takes the blockchain consensus scenario in a BFT consensus environment as an example to illustrate the state data repair method of the blockchain provided in the embodiment of the present application.

[0169] With the development of technology, blockchain technology has become more and more mature. Due to the open and transparent nature of blockchain itself, more and more systems have directly moved their businesses to blockchain. Blockchain is essentially a distributed storage system. Each of its nodes stores data, and the data storage of nodes is based on databases.

[0170] Generally speaking, 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.

[0171] In the actual transaction execution process, StateDB information is used. For example, a historical transaction modifies the value of a key, and the current transaction needs to read the value. Although nodes generally use databases to store StateDB, it is not completely problem-free. Some data may be damaged due to special reasons, such as power failure before writing is completed or the disk corresponding to the file is damaged.

[0172] Then a recovery mechanism is needed. To address this problem, this application proposes a mechanism for automatic repair during transaction execution. Through this mechanism, StateDB can be repaired without external human intervention.

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

[0174] The first option, such as Figure 8 As shown in the figure, it is a schematic diagram of using the HistoryDB database to repair data in the traditional way. In the blockchain system, a database is added: HistoryDB, which is used to store all read-write sets generated by transactions in each block (read-write sets can be understood as Key-Value). Then, when repair is needed, the following method can be used: Figure 8 The processing method shown in Figure 8 In the processing method shown, the data of the corresponding block in HistoryDB can be manually restored to a certain height.

[0175] The second solution is that there is no HistoryDB in the blockchain system. For this method, there are two processing mechanisms in the industry, such as Fig. 9 As shown, it is a schematic diagram of two different methods used in traditional methods to repair data. Fig. 9 Solution 1 shown in the figure is very simple, which is to copy the stateDB data directly from an approved node to the local node. This method requires manual intervention. Fig. 9 Solution 2 shown in the figure 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, and the block information of other nodes will need to be synchronized later (the block information here includes the content of StateDB). In this case, the synchronization must support a mode called "fast synchronization". In this mode, the node will use the content of other nodes to overwrite the local data.

[0176] The defects of the traditional method are divided into the following according to the implementation scheme:

[0177] 1. The first solution (with HistoryDB) has two problems. First, it is for blocks. If the damaged StateDB involves multiple blocks, it is difficult to repair HistoryDB because it is difficult to know which blocks have damaged data. Second, it is impossible to determine the correctness of HistoryDB itself. If the data in HistoryDB is also damaged, it cannot be repaired correctly.

[0178] 2. The two solutions in the second solution are explained respectively:

[0179] 1) Direct copying: This solution has two major problems. First, it requires manual intervention. Since StateDB corruption is unpredictable, the data will remain unusable before manual intervention. Second, if the StateDB is large and the data volume is large, the copying process will take a long time.

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

[0181] 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:

[0182] In response to the problems existing in the above-mentioned industry solutions, an optimized processing solution is proposed, in which the StateDB synchronization process can be completed at the same time as the consensus. This method does not need to rely on HistoryDB, and 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.

[0183] On the product side, the method provided in this application can be applied to the actual development of blockchain underlying software, and can also be used as a method of external publicity. It can also be implemented at the code level according to the solution of this application to optimize the corresponding blockchain underlying code.

[0184] On the technical side,

[0185] 1.1 Overall Process

[0186] 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 indicates 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 itself, and then re-execute the transaction based on the updated state data.

[0187] From the perspective of consensus process, the overall process is as follows: Figure 5 shown.

[0188] like Figure 6 As shown in , 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:

[0189] 1. Each transaction carries the corresponding read-write set Hash (i.e., transaction read-write set Hash), so that when verifying, the slave node can accurately determine which transaction itself is inconsistent, so that it can clearly know which keys in stateDB have problems;

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

[0191] 1.2 Read-Write Set Request / Response

[0192] When a slave node finds that its read-write set is inconsistent with the read-write set carried in the proposal message, the slave node 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.

[0193] like Fig.10 The following is a schematic diagram of the transaction execution process. The reason for reading from the snapshot is that the read set generated during the transaction execution comes from multiple aspects, such as Fig.10 As shown in , it will first read from the write set, then read from the read set, and finally read from the snapshot. For transaction execution, the overall data flow is as follows Fig.10 As shown in , the final transaction execution is based on the transaction context.

[0194] like Fig.11 As shown in Figure 1, it is a schematic diagram of other nodes generating read sets. For other nodes, the process of generating read sets is as follows: Fig.11 as shown in .

[0195] For the process that needs to obtain the read set, the messages it propagates and responds to are as follows: Figure 7 As shown in , in practice, requests and responses can be matched with each other, and for different matches, the node needs to adopt different processing procedures.

[0196] This application proposes a method for repairing blockchain status data, and its overall processing process is as follows: Figure 5 As shown in , it is important to note 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, so the data in the response message can be used.

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

[0198] The StateDB synchronization process can be completed at the same time as consensus, without relying on HistoryDB. Because the operation is 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. 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.

[0199] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0200] Based on the same inventive concept, the embodiment of the present application also provides a blockchain state data repair device for implementing the blockchain state data repair method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in the embodiments of the state data repair device of one or more blockchains provided below can refer to the limitations of the blockchain state data repair method above, and will not be repeated here.

[0201] In one embodiment, Fig.12 As shown, a state data repair device of a blockchain is provided, comprising: an acquisition module 1202, an execution module 1204 and a repair module 1206, wherein:

[0202] The acquisition module 1202 is used to acquire the state data maintained by itself when receiving the proposal message broadcast by the target node.

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

[0204] The acquisition module 1202 is also used to acquire the read set information corresponding to the block identifier in the proposal message from the snapshot of other nodes when the result information is inconsistent with the result information carried in the proposal message.

[0205] 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 a new execution result.

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

[0207] In one embodiment, the result information includes the transaction read-write set corresponding to the transaction task; the proposal message carries the transaction task and the transaction read-write set hash value corresponding to the transaction task; the device also includes: a determination module, a comparison module and a generation module. The determination module is used to determine the transaction read-write set hash value of the transaction task based on the transaction read-write set; the comparison module is used to compare the transaction read-write set hash value with the transaction read-write set hash value carried in the proposal message to obtain a comparison result; the generation module is used to generate a first initial voting message based on the comparison result; the determination module is also used to determine the first voting message based on the first initial voting message and the second initial voting message when receiving the second initial voting message broadcast by the other node; when receiving the second voting message broadcast by the other node, it is determined based on the first voting message and the second voting message that the block corresponding to the block identifier reaches a consensus.

[0208] In one embodiment, the acquisition module is also used to obtain the read set information corresponding to the block identifier in the proposal message from a snapshot of at least one of 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 carried in the proposal message.

[0209] In one embodiment, the device further includes: a selection module and a search module. The determination module is further used to determine the target number based on the number of fault-tolerant nodes; the selection module is used to select the target number of nodes from the other nodes; the search module is used to search for read set information corresponding to the block identifier in the proposal message from the snapshots of the target number of nodes; when the read set information is not found, wait for the other nodes to execute the transaction tasks in the proposal message, so that the other nodes update the snapshot after execution, and search for the read set information corresponding to the block identifier in the updated snapshot.

[0210] In one embodiment, the device further includes: a joining module, a sending module and a processing module. The joining 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 carried in the proposal message; the sending module is used to send a broadcast message for obtaining the read set information, and the broadcast information includes 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; the processing module is used to deserialize the response message when receiving the response message returned by the other node to obtain the deserialized data structure; and the data in the data structure is used as the read set information corresponding to the block identifier in the proposal message.

[0211] In one embodiment, the determination module is also used to determine the number of reply messages when receiving the reply messages returned by the other nodes; the execution module is also used to execute the step of repairing the status data based on the read set information when the number of reply messages is greater than or equal to the target number and the read set information in each of the reply messages is consistent; the target number is determined based on the number of fault-tolerant nodes.

[0212] In one embodiment, the result information includes the transaction read-write set corresponding to the transaction task; the proposal message carries the transaction task and the 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; the determination module is also used to determine the second block read-write set hash value based on the transaction read-write set of the transaction task; the acquisition module is also used to obtain the read set information corresponding to the block identifier in the proposal message from the snapshot of at least one node of the other nodes when the second block read-write set hash value is inconsistent with the first block read-write set hash value.

[0213] In one embodiment, the device also includes: a verification module, used to verify the reliability of the read set information and obtain a verification result; the execution module is also used to execute the step of repairing the status data based on the read set information when the verification result indicates that the read set information is credible.

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

[0215] In one embodiment, the processing module is further used to deserialize the proposal message to obtain the deserialized proposal message; the execution module is further used to execute the transaction task in the deserialized proposal message based on the status data.

[0216] In one embodiment, the device further includes: a discarding module, and the verification module is also used to verify the legitimacy of the deserialized proposal message to obtain a verification result; the discarding module is used to discard the proposal message when the verification result indicates failure; the execution module is also used to execute the step of executing the transaction task in the deserialized proposal message based on the status data when the verification result indicates success.

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

[0218] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Fig.13As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store the status data of the blockchain. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a method for repairing the status data of a blockchain is implemented.

[0219] Those skilled in the art will understand that Fig.13 The structure shown in the figure is only a block diagram of a part 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 those shown in the figure, or combine certain components, or have a different arrangement of components.

[0220] In one embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above-mentioned method embodiments when executing the computer program.

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

[0222] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0223] 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 relevant laws, regulations and standards of relevant countries and regions.

[0224] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an 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 each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but are not limited to this.

[0225] The technical features of the above embodiments may 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.

[0226] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A method for repairing state data of a blockchain, characterized in that: The method comprises: When receiving the proposal message broadcast by the target node, obtain the state data maintained by itself; Execute 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 carried in the proposal message, obtaining the read set information corresponding to the block identifier in the proposal message from the snapshot of other nodes; The state data is repaired 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 a new execution result.

2. The method according to claim 1, characterized in that: The result information includes execution results and transaction read-write sets; When receiving the proposal message broadcast by the target node, the state data maintained by the node is obtained, including: Upon receiving the proposal message broadcast by the target node, obtaining the state data from the state database maintained by itself; The executing the transaction task in the proposal message based on the status data to obtain result information includes: The 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. The method according to claim 1, characterized in that The result information includes the transaction read-write set corresponding to the transaction task; the proposal message carries the transaction task and the hash value of the transaction read-write set corresponding to the transaction task; After executing the transaction task in the proposal message based on the status data and obtaining the execution result, the method further includes: 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 carried in the proposal message to obtain a comparison result; Based on the comparison result, generating a first initial voting message; When receiving the second initial voting message broadcast by the other node, determining the first voting message based on the first initial voting message and the second initial voting message; When receiving the second voting message broadcast by the other node, it is determined that a consensus is reached on the block corresponding to the block identifier based on the first voting message and the second voting message.

4. The method according to claim 3, characterized in that When the result information is inconsistent with the result information carried in the proposal message, obtaining read set information corresponding to the block identifier in the proposal message from snapshots of other nodes 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 carried in 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. The method according to claim 4, characterized in that The acquiring, from a snapshot of at least one of the other nodes, read set information corresponding to the block identifier in the proposal message includes: Based on the number of fault-tolerant nodes, determine the target number; Select the target number of nodes from the other nodes; Searching for read set information corresponding to the block identifier in the proposal message from the snapshots of the target number of nodes; When the read set information is not found, wait for the other nodes to execute the transaction tasks in the proposal message, so that the other nodes update the snapshot after the execution is completed, and search for the read set information corresponding to the block identifier in the updated snapshot.

6. The method according to claim 3, characterized in that The method further comprises: 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 carried in the proposal message, adding the transaction identifier of the transaction task to the target set; The obtaining, from snapshots of other nodes, the 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.

7. The method according to claim 6, characterized in that The method further comprises: 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 response message is consistent, a step of repairing the status data based on the read set information is executed; the target number is determined based on the number of fault-tolerant nodes.

8. The method according to claim 1, characterized in that The result information includes the transaction read-write set corresponding to the transaction task; the proposal message carries the transaction task and the hash value of the first block read-write set; 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 method further comprises: 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 is inconsistent with the result information carried in the proposal message, obtaining read set information corresponding to the block identifier in the proposal message from snapshots of other nodes includes: 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.

9. The method according to claim 1, characterized in that: After obtaining the read set information corresponding to the block identifier in the proposal message from the snapshot of other nodes, the method 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, a step of repairing the state data based on the read set information is performed.

10. The method according to claim 1, characterized in that The read set information includes key-value pair information; The repairing the state data based on the read set information to obtain the repaired state data includes: 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.

11. The method according to any one of claims 1 to 10, characterized in that: After receiving the proposal message broadcast by the target node, the method further includes: 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.

12. The method according to claim 11, characterized in that The method further comprises: Performing a validity verification on the deserialized proposal message to obtain a verification result; When the verification result indicates failure, discarding the proposal message; When the verification result indicates success, the step of executing the transaction task in the deserialized proposal message based on the state data is performed.

13. A state data repair device for a blockchain, characterized in that: The device comprises: The acquisition module is used to obtain the state data maintained by itself when receiving the proposal message broadcast by the target node; 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 used to acquire the read set information corresponding to the block identifier in the proposal message from the snapshot of other nodes when the result information is inconsistent with the result information carried in the proposal message; A repair module 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 a new execution result.

14. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 12 are implemented.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 12 are implemented.

16. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 12 are implemented.

Images