A blockchain smart contract state data synchronization method and system

Abstract

The present application relates to the technical field of block chain, and provides a kind of block chain smart contract state data synchronization method and system, comprising: when block consensus is completed, receiving the verification cache in block, comparing the verification cache in block with local verification cache;If the verification cache in block and local verification cache are inconsistent, then the read set in local verification cache is traversed, and compared with the verification cache in block, find the inconsistent key, and generate a map, then the received write set and result set are directly written into database;When data is written to database, check whether there is key in the write set and result set in map, if yes, delete the key in map;After the received write set and result set are all written into database, check whether there is still key not deleted in map, if yes, pull the data of key from master node and write into database.The efficiency of data synchronization is improved.

Description

Technical Field

[0001] This invention belongs to the field of blockchain technology, and in particular relates to a method and system for synchronizing state data of blockchain smart contracts. Background Technology

[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.

[0003] The nature of smart contracts dictates that blockchain networks automatically execute smart contract code without the need for continuous monitoring and evaluation of whether the obligations coded within the smart contract have been fulfilled. A greater benefit is that, based on the resilience and tamper-proof nature of blockchain, all parties are confident that the underlying code of the smart contract will not be altered, nor will it be in the future. Since the coded obligations are guaranteed to be automatically executed, smart contracts will greatly facilitate transactions between individuals and institutions that do not know or trust each other; therefore, the security and execution efficiency of smart contracts become particularly important.

[0004] Due to the characteristics of blockchain, data tampering will not affect the overall consensus result, and inconsistencies in data among nodes will also not affect the final consensus result. However, if data is tampered with, the blockchain needs a certain recovery mechanism, that is, to check which data has been tampered with and to restore the tampered data to the correct data.

[0005] Currently, the Hyperledger Fabric platform uses pre-executed contracts and endorsed nodes for verification to prevent erroneous data from being uploaded to the chain. When a node malfunctions, it is removed until its data is recovered. While this approach can ensure that nodes have no erroneous data on-chain, it is prone to problems with BFT (Byzantine Fault-Tolerant) consensus mechanisms without an automatic recovery mechanism. This can easily lead to more than f erroneous nodes, preventing the consensus process from continuing.

[0006] Another approach is to use Merkle trees as the data structure for storing state data. By comparing the roots of the Merkle tree, inconsistencies can be detected, and the Merkle tree's ability to quickly locate inconsistent leaf nodes can be used to synchronize erroneous data. However, the storage and query efficiency of Merkle trees is lower than that of key-value storage. Summary of the Invention

[0007] To address the technical problems mentioned above, this invention provides a method and system for synchronizing blockchain smart contract state data. When data is missing, there is no need to re-execute the contract; only the read and write sets in the block need to be synchronized, which can improve the efficiency of data synchronization.

[0008] To achieve the above objectives, the present invention adopts the following technical solution:

[0009] The first aspect of this invention provides a method for synchronizing state data of a blockchain smart contract, comprising:

[0010] Once the block consensus is complete, the verification cache in the block is received, and the verification cache in the block is compared with the local verification cache.

[0011] If the verification cache in the block is inconsistent with the local verification cache, the read set in the local verification cache is traversed and compared with the verification cache in the block. Inconsistent keys are found, and a map is generated. Then, the received write set and result set are directly written to the database. When writing data to the database, it is checked whether there are keys in the write set and result set in the map. If so, the keys are deleted from the map. After all the received write sets and result sets are written to the database, it is checked whether there are any keys in the map that have not been deleted. If so, the data of the keys is retrieved from the master node and written to the database.

[0012] Furthermore, when comparing with the validation set in a certain block and finding an inconsistent key, if no operation is performed on the found key in subsequent blocks of that block, then the key data is retrieved from the master node; if the found key is performed in subsequent blocks of that block, then it is not necessary to retrieve the key data from the master node.

[0013] Furthermore, in response to the restart command, it determines whether there are missing blocks. If there are missing blocks, it enters block synchronization. After the block synchronization is completed, it enters contract data reconstruction.

[0014] Furthermore, during contract data reconstruction, the largest block size at the time of synchronization is recorded, and after synchronization is completed, it is checked whether a new block has been generated. If so, the contract data reconstruction is repeated; otherwise, it enters the normal state.

[0015] A second aspect of the present invention provides a blockchain smart contract state data synchronization system, comprising:

[0016] The comparison module is configured to: after block consensus is completed, receive the verification cache in the block and compare the verification cache in the block with the local verification cache;

[0017] The data synchronization module is configured as follows: If the verification cache in the block is inconsistent with the local verification cache, it iterates through the read set in the local verification cache and compares it with the verification cache in the block. It finds the inconsistent keys, generates a map, and then directly writes the received write set and result set to the database. When writing data to the database, it checks whether there are keys in the write set and result set in the map. If so, it deletes the keys from the map. After all the received write sets and result sets have been written to the database, it checks whether there are any keys in the map that have not been deleted. If so, it pulls the data of the keys from the master node and writes them to the database.

[0018] Furthermore, the data synchronization module is also configured to: when comparing with the verification set in a certain block and finding an inconsistent key, if no operation is performed on the found key in subsequent blocks of that block, then pull the key data from the master node; if an operation is performed on the found key in subsequent blocks of that block, then it is not necessary to pull the key data from the master node.

[0019] Furthermore, it also includes a restart synchronization module, which is configured to: in response to a restart command, determine whether there are missing blocks; if so, proceed to block synchronization; and after completing block synchronization, proceed to contract data reconstruction.

[0020] Furthermore, during contract data reconstruction, the largest block size at the time of synchronization is recorded, and after synchronization is completed, it is checked whether a new block has been generated. If so, the contract data reconstruction is repeated; otherwise, it enters the normal state.

[0021] A third aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the blockchain smart contract state data synchronization method described above.

[0022] A fourth aspect of the present invention provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of a blockchain smart contract state data synchronization method as described above.

[0023] Compared with the prior art, the beneficial effects of the present invention are:

[0024] This invention provides a method for synchronizing the state data of blockchain smart contracts. When data is missing, the contract does not need to be re-executed; only the read and write sets in the block need to be synchronized, which can improve the efficiency of data synchronization.

[0025] This invention provides a method for synchronizing state data of blockchain smart contracts, which avoids the need for node restarts and supports real-time data verification and synchronization. As long as a new block is generated, the data can be verified and synchronized in real time. Attached Figure Description

[0026] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0027] Figure 1 This is a flowchart illustrating the overall data synchronization process of Embodiment 1 of the present invention;

[0028] Figure 2 This is a flowchart of node data synchronization when there is erroneous data in Embodiment 1 of the present invention;

[0029] Figure 3 This is a flowchart of the data synchronization process during restart according to Embodiment 1 of the present invention;

[0030] Figure 4 This is a flowchart illustrating the specific implementation of data synchronization during restart in Embodiment 1 of the present invention. Detailed Implementation

[0031] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0032] It should be noted that the following detailed description is illustrative and intended to provide further explanation of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0033] Example 1

[0034] This embodiment provides a method for synchronizing blockchain smart contract state data. It employs a method for real-time checking of the consistency of smart contract state data without affecting the consensus module, supports real-time data synchronization in the event of node restart, and uses a key-value storage method at the underlying level, resulting in high read and write speeds.

[0035] The contract execution process depends on the result of the previous execution. To avoid potentially erroneous data being written directly to disk, a caching mechanism is used. Data generated during contract execution is first written to the cache, and the data is only written to disk after the execution result is verified.

[0036] Therefore, three caches were designed for contract execution: execution cache, result cache, and verification cache.

[0037] Execution cache: Used to store various state data generated during contract execution.

[0038] The execution cache uses two map data structures: a state cache and a version cache. The state cache stores the current state of the key->value pair, with the storage structure key#version->value; the version cache stores the latest version number (version) for the current key, with the storage structure key->version.

[0039] During contract execution, reading data requires first retrieving the highest version of the data from the execution cache. If the data is not found in the execution cache, it is retrieved from the database, and the latest version number and data are then added to the execution cache. If data needs to be written during contract execution, the latest version number of the current data in the execution cache must be updated, and the latest state cache must also be updated.

[0040] For example: Given a pair of data key1->value1, the execution cache contains no data. If key1 is read, the version cache is updated first, recording key1->1; then the state cache is updated, recording key1#v1->value1. If the value of key1 is then updated to value1', the version number of key1 needs to be updated first, that is, key1->1 in the version cache becomes key1->2; then the state cache of key1 is updated to key1#v2->value1'. At this point, the version cache in the execution cache contains one data key1->2, and the state cache contains two data key1#v1->value1 and key1#v2->value1'.

[0041] Result Cache: Used to store various result data after contract execution. The result cache uses a map data structure to directly store the key-value pairs of the results generated in this execution.

[0042] Verification cache: Used to store the result set of the contract to be verified, including the read set, write set and result set generated in this execution, which are periodically packaged into the block.

[0043] The verification cache uses a map data structure (a key->value storage structure), where the key is the block number and the value is the read and write set of all data generated during the execution of this block. The verification cache structure includes read set hash, write set hash, read set, write set, and result set. That is, the data structure of the value in the verification cache is as follows:

[0044] ReadSetHash: The hash of the read set;

[0045] WriteSetHash: The hash of the write set;

[0046] ReadSet: The key and value read during this contract execution;

[0047] WriteSet: The key and value written during this contract execution;

[0048] ResultSet: The result of this execution.

[0049] Each node has an execution cache, a result cache, and a verification cache; the block stores the verification cache, and the verification cache in the block is the verification cache after consensus among all nodes.

[0050] The structure of a block consists of a block header and a block body. The block header contains the block number, transaction root, timestamp, block hash, and hash of the previous block. The block body contains transaction requests and verification cache.

[0051] like Figure 1 As shown, after the block consensus is completed, each node needs to compare the verification cache in the block with its local verification cache; if they match, it proceeds normally; if they do not match, it enters the data synchronization state (Sync), and continues until the data synchronization is completed and no new block is generated, at which point the node returns to the normal state (Formal).

[0052] The data synchronization process is as follows:

[0053] (1) Regardless of whether the ResultSet is consistent, as long as the node receives the correct block, the data in the ResultSet is correct and can be directly written to the database.

[0054] (2) During synchronization, only the ReadSet needs to be considered. Only the ReadSet may cause the WriteSet to be inconsistent. However, if the received WriteSet is correct, it can be written directly to the database. At this time, we only need to consider whether the inconsistent key in the ReadSet has been overwritten in the subsequent WriteSet.

[0055] (3) Iterate through the ReadSet to find which keys are inconsistent, generate a map, and check if there is a corresponding key in the map when writing data to the database. If there is, delete the key in the map until the data is finally synchronized. If there is still a key in the map, fetch the data of that key from the master node.

[0056] Suppose there are 4 nodes 0, 1, 2, and 3, where the data on node 3 is incorrect. The data synchronization process is as follows:

[0057] (1) Because the data of nodes 0, 1, and 2 is correct, the three nodes can still reach a consensus and receive a correct block containing the correct verification cache.

[0058] (2) The data of the 3 nodes is incorrect, and the local verification cache data is also incorrect. When comparing it with the verification cache in the received correct block, it can be found that the data of the 3 nodes is inconsistent.

[0059] (3) At this time, the three nodes start data synchronization, traverse the ReadSet and compare it with the received verification cache, find out which keys are inconsistent, and generate a map (where the key is the data that is inconsistent after comparing the ReadSet and the received verification cache).

[0060] (4) Since the data in the ResultSet and WriteSet received by node 3 is correct, it can be directly written to the database, and the corresponding key in the map generated in step 3 is deleted.

[0061] (5) Check if there are any keys that have not been deleted in the map generated in step 3. If so, actively pull the data of this key from its master node and write it to the local database.

[0062] The following explains whether data needs to be synchronized from other nodes in the read / write set; specifically, the method for finding inconsistent keys is explained below:

[0063] 1. Data needs to be synchronized from other nodes.

[0064] Block 3: writeSet[key1,key2,key3]readSet[key5,key6]result

[0065] Block 8: writeSet[key1,key2]readSet[key6]result

[0066] If the readSet key5 in block 3 contains erroneous data, then the execution result of transaction tx will also be erroneous. However, no operation is performed on key5 in subsequent blocks. In this case, the latest result of key5 needs to be synchronized from other nodes (master nodes) to the local state database db.

[0067] 2. No need to synchronize data from other nodes.

[0068] Block 3: writeSet[key1,key2,key3]readSet[key5,key6]result

[0069] Block 8: writeSet[key1,key5] readSet[key6] result

[0070] Suppose that readSet key5 in block 3 contains incorrect data, and subsequent blocks operate on key5, then the latest state of the correct key5 will be recorded in the block. At this point, all we need to do is write all writeSet data in the block to the database.

[0071] The specific implementation process is as follows: Figure 2 As shown:

[0072] (1) The transaction in block 1 was successfully verified in block 3. The transaction in block 3 failed to be verified by a certain node in block 8, but this does not affect the node from receiving the correct block. Therefore, both block 8 and block 10 are correct.

[0073] (2) At this time, the faulty node finds that the transaction that failed to verify in block 8 was packaged in block 3. Then, it traverses from block 3 to the next block, finds the result and writeSet that contain the verification in blocks 3, 8, and 10, and writes them into the database in order.

[0074] (3) Because the node has stopped running the contract in block 8, the contract in block 9 has been verified in block 10. This node synchronizes the result and writeSet of the transaction in block 10, and also removes the transaction of block 9 from the contract queue.

[0075] (4) If the erroneous data is key1, and key1 is not found in writeSet from block 3 to block 10, then key1 needs to be synchronized with other nodes.

[0076] The above describes the data synchronization process when a node fails. If data is missing when a node restarts, data synchronization also needs to be considered. Figure 3 As shown, the specific process is as follows:

[0077] 1. The node restarts to determine if there are missing blocks. If there are, it enters the block synchronization state (Catchup). After the block synchronization is completed, it enters the contract data reconstruction state (Rebuild).

[0078] 2. Contract data reconstruction needs to record the largest block size during the current synchronization. After synchronization is complete, check if a new block has been generated. If so, repeat the contract data reconstruction; otherwise, enter the normal state.

[0079] Taking contract request synchronization after node restart as an example, such as Figure 4 As shown, the specific implementation process is as follows:

[0080] (1) Assume that the Catchup node disconnects at block a(20) and restarts at block b(25);

[0081] (2) The Catchup node restarts, obtains the largest block as b(25), and then joins the system. During this process, other normal nodes continue to produce blocks up to c(30), and then from c+1(31), the Catchup node can receive the correct block.

[0082] (3) After the Catchup node restarts, it enters the Catchup state and begins to synchronize blocks ab(20-25);

[0083] (4) After the Catchup node is synchronized, it finds that the largest block b(25) has not caught up with the largest received block c(30). Catchup is performed again. At this time, the node is still in the Catchup state and synchronizes the bc(25-30) blocks.

[0084] (5) At this point, all missing data has been synchronized and the system enters the Rebuild state. The current maximum block d(35) is recorded. For contract requests, the verification message contained in block ad(20-35) is written to the db and the metadata is reconstructed.

[0085] (6) If Rebuild is completed, compare whether the maximum block in the record is equal to the maximum block received. If it is less, continue to repeat step (5). Otherwise, enter the formal state, and the contract can be executed normally and a consensus block containing the verification message can be reached.

[0086] Currently, most methods involve executing the contract first, without generating new blocks during execution. Once execution is complete, a new block is created, and the contract result is then added to the consensus mechanism. This embodiment provides a blockchain smart contract state data synchronization method that does not affect the consensus module. Contract verification and consensus can be executed asynchronously, with the contract being verified in the latest block after execution.

[0087] Hyperledger Fabric requires a restart for data recovery. This embodiment provides a blockchain smart contract state data synchronization method that avoids the need for node restarts, supporting real-time data verification and synchronization. Data can be verified and synchronized in real time whenever a new block is generated.

[0088] This embodiment provides a method for synchronizing blockchain smart contract state data, which uses a key-value storage method at the underlying level and has a high read and write speed.

[0089] This embodiment provides a method for synchronizing the state data of a blockchain smart contract. When data is missing, there is no need to re-execute the contract; only the read and write sets in the block need to be synchronized, which can improve the efficiency of data synchronization.

[0090] Example 2

[0091] This embodiment provides a blockchain smart contract state data synchronization system, which specifically includes:

[0092] The comparison module is configured to: after block consensus is completed, receive the verification cache in the block and compare the verification cache in the block with the local verification cache;

[0093] The data synchronization module is configured as follows: If the verification cache in the block is inconsistent with the local verification cache, it iterates through the read set in the local verification cache and compares it with the verification cache in the block. It finds the inconsistent keys, generates a map, and then directly writes the received write set and result set to the database. When writing data to the database, it checks whether there are keys in the write set and result set in the map. If so, it deletes the keys from the map. After all the received write sets and result sets have been written to the database, it checks whether there are any keys in the map that have not been deleted. If so, it pulls the data of the keys from the master node and writes them to the database.

[0094] The data synchronization module is also configured to: when comparing with the validation set in a certain block and finding an inconsistent key, if no operation is performed on the found key in subsequent blocks of that block, then fetch the key data from the master node; if the found key is operated on in subsequent blocks of that block, then it is not necessary to fetch the key data from the master node.

[0095] The restart synchronization module is configured to: respond to the restart command, determine if there are missing blocks, and if so, proceed to block synchronization. After the block synchronization is completed, proceed to contract data reconstruction.

[0096] When reconstructing contract data, the largest block size during synchronization is recorded, and after synchronization is complete, it is checked whether a new block has been generated. If so, the contract data reconstruction is repeated; otherwise, it enters the normal state.

[0097] It should be noted that each module in this embodiment corresponds one-to-one with each step in Embodiment 1, and their specific implementation processes are the same, so they will not be repeated here.

[0098] Example 3

[0099] This embodiment provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in the blockchain smart contract state data synchronization method described in Embodiment 1 above.

[0100] Example 4

[0101] This embodiment provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps in the blockchain smart contract state data synchronization method described in Embodiment 1 above.

[0102] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of hardware embodiments, software embodiments, or embodiments combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

[0103] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0104] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0105] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0106] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0107] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for synchronizing state data of a blockchain smart contract, characterized in that, Comprising: After the block consensus is completed, receiving the verification cache in the block, comparing the verification cache in the block with the local verification cache; If consistent, then normal processing; If inconsistent, then enter data synchronization state; If the verification cache in the block and the local verification cache are inconsistent, then traverse the read set in the local verification cache and compare with the verification cache in the block, find the inconsistent key, and generate a map, then write the received write set and result set directly into the database; When writing data to the database, check whether there is a key in the write set and the result set in the map, if yes, delete the key in the map; After the received write set and result set are all written into the database, check whether there is an un-deleted key in the map, if yes, pull the data of the key from the master node and write into the database; The data synchronization process is as follows: (1) Do not consider whether the ResultSet is consistent, as long as the node receives the correct block, the data in the ResultSet is correct, and it can be directly written into the database; (2) When synchronizing, only the ReadSet needs to be considered, only the ReadSet can cause the WriteSet to be inconsistent, and the received WriteSet is correct, which can be directly written into the database; At this time, only the inconsistent key in the ReadSet needs to be considered whether it is covered in the subsequent WriteSet; (3) Traverse the ReadSet to find out which keys are inconsistent, generate a map, and check whether there is a corresponding key in the map when writing data into the database, if yes, delete the key in the map until the data synchronization is completed; If there is a key in the map, pull the data of the key from the master node. 2.The method of claim 1, wherein, When comparing with the verification set in a certain block and finding an inconsistent key, if the subsequent block of the block does not operate on the found key, the data of the key is pulled from the master node; If the subsequent block of the block has an operation on the found key, the data of the key does not need to be pulled from the master node. 3.The method of claim 1, wherein, In response to a restart instruction, it is judged whether there is a missing block, if yes, then enter block synchronization, and after the block synchronization is completed, enter contract data reconstruction.

4. The method of claim 3, wherein, When performing contract data reconstruction, record the maximum block during synchronization, and after synchronization is completed, check whether there is a new block, if yes, then repeat the contract data reconstruction; If not, then enter the normal state. 5.A blockchain smart contract state data synchronization system, characterized in that, Comprising: A comparison module configured to: after the block consensus is completed, receiving the verification cache in the block, comparing the verification cache in the block with the local verification cache; if consistent, then normal processing; if inconsistent, then enter data synchronization state; The data synchronization module is configured to: if the verification cache in the block and the local verification cache are inconsistent, traverse the read set in the local verification cache, compare with the verification cache in the block, find the inconsistent key, and generate a map, then write the received write set and result set directly into the database; when writing data to the database, check whether there is a key in the write set and the result set in the map, if there is, delete the key in the map; after the received write set and result set are all written into the database, check whether there is a key in the map that has not been deleted, if there is, pull the data of the key from the master node and write it into the database; The data synchronization process is as follows: (1) Do not consider whether the ResultSet is consistent, as long as the node receives the correct block, the data in the ResultSet is correct, and it can be directly written into the database; (2) Only the ReadSet needs to be considered during synchronization, only the ReadSet can cause the WriteSet to be inconsistent, and the received WriteSet is correct, which can be directly written into the database; At this time, only the inconsistent key in the ReadSet needs to be considered whether it is covered in the subsequent WriteSet; (3) Traverse the ReadSet to find out which keys are inconsistent, generate a map, and check whether there is a corresponding key in the map when writing data into the database, if there is, delete the key in the map until the data synchronization is completed; if there is a key in the map, pull the data of the key from the master node.

6. The blockchain smart contract state data synchronization system of claim 5, wherein, The data synchronization module is further configured to: when comparing with the verification set in a certain block and finding an inconsistent key, if the subsequent block of the block does not operate on the found key, pull the data of the key from the master node; if the subsequent block of the block has an operation on the found key, the data of the key does not need to be pulled from the master node.

7. The blockchain smart contract state data synchronization system of claim 5, wherein, Further comprising a restart synchronization module configured to: in response to a restart instruction, determine whether there is a missing block, if there is, enter block synchronization, and after the block synchronization is completed, enter contract data reconstruction.

8. The blockchain smart contract state data synchronization system of claim 7, wherein, When performing contract data reconstruction, record the maximum block during synchronization, and after synchronization is completed, check whether there is a new block, if there is, repeat the contract data reconstruction; if not, enter the normal state.

9. A computer-readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the steps in the blockchain smart contract state data synchronization method of any one of claims 1-4.

10. A computer device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the program to implement the steps in the blockchain smart contract state data synchronization method of any one of claims 1-4.

Images