A blockchain synchronization method, device and storage medium based on state increment

Abstract

The present application relates to a blockchain synchronization method, device and storage medium based on state increment, wherein the method includes: determining the node to be synchronized, the set of synchronized nodes and the synchronization range; the node to be synchronized is a backward node in the blockchain; according to the set of synchronized nodes, determining the target node; requesting synchronization data from the target node in parallel; the synchronization data includes state increment data; verifying the synchronization data; synchronizing the node to be synchronized according to the verified synchronization data. The present application solves the problem that the existing synchronization method needs to execute the transaction body in the block to verify the validity of the block data, and the amount of calculation is large during the synchronization process, resulting in low synchronization efficiency.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a blockchain synchronization method, device and storage medium based on state increment. Background Art

[0002] In a blockchain network, due to the distributed environment, network delays, node failures, machine downtime and other issues may occur, and the status between nodes may be inconsistent. Although blockchain uses a variety of consensus algorithms to ensure that most node ledgers remain consistent in the network, there may be a small number of nodes whose ledgers store blocks that lag behind other nodes.

[0003] In addition, as the blockchain runs, the storage of the ledger will increase dramatically, the storage cost is very high, and the efficiency of data reading and writing will be reduced. Therefore, the state pruning solution is usually adopted to remove some infrequently used historical data. The node that stores the full amount of historical state data is called the archive node. Since the archive node does not perform any pruning, the storage pressure is very large. Therefore, the archive node has higher hardware configuration requirements than other blockchain nodes in the network. If the read and write performance reaches a bottleneck, the archive node will be in a backward state.

[0004] Currently, backward nodes are synchronized through full synchronization, that is, the backward nodes start from the current latest block height, request block data from other nodes in the network one by one, verify the validity of block data by executing the transaction body in the block, and update the local state storage. This synchronization method requires executing the transaction body in the block to verify the validity of block data. The amount of calculation during the synchronization process is large, resulting in low synchronization efficiency. Summary of the invention

[0005] In this embodiment, a blockchain synchronization method, device, and storage medium based on state increment are provided to solve the problem of low synchronization efficiency in the prior art.

[0006] In a first aspect, a blockchain synchronization method based on state increment is provided in this embodiment, and the method includes:

[0007] Determine the node to be synchronized, the set of synchronizeable nodes and the synchronization range; the node to be synchronized is a backward node in the blockchain;

[0008] Determine a target node according to the syncable node set;

[0009] Requesting synchronization data from the target node in parallel; the synchronization data includes state increment data;

[0010] Performing data verification on the synchronization data;

[0011] The nodes to be synchronized are synchronized according to the verified synchronization data.

[0012] In some embodiments, determining the target node according to the syncable node set includes:

[0013] The target node is determined according to the block height of the node in the syncable node set.

[0014] In some embodiments, the synchronization data further includes block header data and block body data, and the data verification of the synchronization data includes:

[0015] Performing data verification on the block header data of the target node;

[0016] After the block header data of the target node passes the data verification, the block body data of the target node is verified;

[0017] And / or, after the block header data of the target node passes the data verification, the state incremental data of the target node is verified.

[0018] In some embodiments, synchronizing the node to be synchronized according to the verified synchronization data includes:

[0019] Storing the verified synchronization data;

[0020] The block height of the node to be synchronized is updated to the block height of the target node to which the verified synchronization data belongs.

[0021] In some embodiments, after the block header data of the target node passes the data verification, the state incremental data of the target node is verified, including:

[0022] Verify whether the first state root node data of the state incremental data is consistent with the state root node data in the block header data corresponding to the state incremental data.

[0023] In some embodiments, after the block header data of the target node passes the data verification, the state incremental data of the target node is verified, including:

[0024] Calculate and obtain the second state root node data according to the state increment data;

[0025] Verify whether the first-state root node data and the second-state root node data are consistent.

[0026] In some embodiments, determining the target node according to the syncable node set includes:

[0027] A random algorithm is used to determine a target node from the synchronizable node set.

[0028] In a second aspect, a blockchain synchronization device based on state increment is provided in this embodiment, and the device includes:

[0029] A first determination module is used to determine the node to be synchronized, the set of synchronizeable nodes and the synchronization range; the node to be synchronized is a backward node in the blockchain;

[0030] A second determination module, configured to determine a target node according to the synchronizable node set;

[0031] A request module, used for requesting synchronization data from the target node in parallel; the synchronization data includes state increment data;

[0032] A verification module, used for performing data verification on the synchronization data;

[0033] The synchronization module is used to synchronize the nodes to be synchronized according to the verified synchronization data.

[0034] In a third aspect, a device is provided in this embodiment, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the state increment-based blockchain synchronization method described in the first aspect.

[0035] In a fourth aspect, a computer-readable storage medium is provided in this embodiment, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the blockchain synchronization method based on state increment described in the first aspect are implemented.

[0036] Compared with the prior art, the blockchain synchronization method, device and storage medium based on state increment provided in this embodiment determine the nodes to be synchronized, the set of synchronized nodes and the synchronization range; determine the target node according to the set of synchronized nodes; request synchronization data from the target node in parallel; the synchronization data includes state increment data; verify the synchronization data; synchronize the nodes to be synchronized according to the verified synchronization data. By requesting synchronization data from the target node in parallel and verifying the synchronization data including state increment data, the problem that the existing synchronization method needs to execute the transaction body in the block to verify the validity of the block data, the amount of calculation is large during the synchronization process, and thus the synchronization efficiency is low.

[0037] Details of one or more embodiments of the present application are set forth in the following drawings and description to make other features, objects, and advantages of the present application more readily apparent. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0039] Figure 1 It is a hardware structure block diagram of a terminal for executing a blockchain synchronization method based on state increment according to an embodiment of the present application;

[0040] Figure 2 It is a flowchart of a blockchain synchronization method based on state increment according to an embodiment of the present application;

[0041] Figure 3 It is a schematic diagram of a block execution process of a blockchain in an embodiment of the present application;

[0042] Figure 4 It is a schematic diagram of a blockchain state ledger update in an embodiment of the present application;

[0043] Figure 5a It is a schematic diagram of a format for storing a state ledger in an embodiment of the present application;

[0044] Figure 5b It is a schematic diagram of another format of state ledger storage in an embodiment of the present application;

[0045] Figure 6 This is a schematic diagram of a synchronization process in an embodiment of the present application;

[0046] Figure 7 This is a schematic diagram of a verification process in an embodiment of the present application;

[0047] Figure 8 It is a flowchart of a block header verification in an embodiment of the present application;

[0048] Fig. 9 It is a schematic diagram of a hash calculation of a state increment in an embodiment of the present application;

[0049] Fig.10 It is a structural block diagram of a blockchain synchronization device based on state increment in an embodiment of the present application. DETAILED DESCRIPTION

[0050] In order to more clearly understand the purpose, technical solutions and advantages of the present application, the present application is described and illustrated below in conjunction with the accompanying drawings and embodiments.

[0051] Unless otherwise defined, the technical terms or scientific terms involved in this application shall have the general meaning understood by people with general skills in the technical field to which this application belongs. The words "one", "a", "the", "these" and the like in this application do not indicate a quantitative limitation, and they may be singular or plural. The terms "include", "comprise", "have" and any variants thereof involved in this application are intended to cover non-exclusive inclusions; for example, a process, method and system, product or device comprising a series of steps or modules (units) is not limited to the listed steps or modules (units), but may include unlisted steps or modules (units), or may include other steps or modules (units) inherent to these processes, methods, products or devices. The words "connect", "connected", "coupled" and the like involved in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. The "multiple" involved in this application refers to two or more. "And / or" describes the association relationship of associated objects, indicating that there may be three relationships, for example, "A and / or B" may mean: A exists alone, A and B exist at the same time, and B exists alone. Generally, the character " / " indicates that the objects associated with each other are in an "or" relationship. The terms "first", "second", "third", etc. in this application are only used to distinguish similar objects and do not represent a specific ordering of the objects.

[0052] The method embodiment provided in this embodiment can be executed in a terminal, a computer or a similar computing device. For example, running on a terminal, Figure 1 1 is a hardware structure block diagram of a terminal for executing a blockchain synchronization method based on state increment according to an embodiment of the present application. Figure 1 As shown, the terminal may include one or more ( Figure 1 Only one is shown in the figure) a processor 102 and a memory 104 for storing data, wherein the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA. The above terminal may also include a transmission device 106 and an input and output device 108 for communication functions. It can be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above terminal. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations shown.

[0053] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as a computer program corresponding to a blockchain synchronization method based on state increment in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, to implement the above method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories may be connected to the terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0054] The transmission device 106 is used to receive or send data via a network. The above network includes a wireless network provided by a communication provider of the terminal. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, referred to as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (Radio Frequency, referred to as RF) module, which is used to communicate with the Internet wirelessly.

[0055] This embodiment provides a blockchain synchronization method based on state increment. Figure 2 is a flowchart of a blockchain synchronization method based on state increment according to an embodiment of the present application, such as Figure 2 As shown, the process includes the following steps:

[0056] Step S210, determine the nodes to be synchronized, the set of synchronizeable nodes and the synchronization range; the nodes to be synchronized are backward nodes in the blockchain.

[0057] In this step, the nodes to be synchronized, the set of synchronized nodes and the synchronization range are determined according to the block height of each node in the blockchain. The backward nodes in the blockchain are determined as the nodes to be synchronized, and the set of other nodes in the blockchain is determined as the set of synchronized nodes. The synchronization range is determined according to the block height of the backward nodes and the block height of other nodes in the blockchain. The synchronization range and the set of synchronized nodes are both subject to consensus. The synchronization range here can be the range of block heights that need to be synchronized, or it can be the range of nodes that need to be synchronized. If the block height of the node to be synchronized is N1, the node to be synchronized is a backward node in the blockchain, and the effective highest block height in the blockchain is N m , then the range of block heights that the lagging nodes need to synchronize is determined to be (N1+1)~N m, where N1 and N m are all positive integers, and N m Greater than N1. The lower limit of the synchronization range can be the latest height of the node to be synchronized, and the upper limit of the synchronization range is the latest height of the target node in the set of synchronizeable nodes after consensus. For example, the range of the backward node to be synchronized is determined to be the block height range of (N1+1)~N m , reaching block height N in the blockchain network m The set of valid nodes or legal nodes is the syncable node set, that is, the syncable node set includes multiple nodes, and the block height of the nodes in the syncable node set is equal to or higher than N m .

[0058] Step S220: determining a target node according to the syncable node set.

[0059] There may be multiple target nodes determined here. According to a preset node selection algorithm, multiple target nodes are determined from the nodes in the syncable node set. The preset node selection algorithm here may be a load balancing algorithm or a node random selection algorithm. The node here may be understood as a hardware node or a software node in a blockchain network.

[0060] Step S230, requesting synchronization data from the target node in parallel; the synchronization data includes state increment data.

[0061] In this step, synchronization data is requested from multiple target nodes in parallel, and the synchronization data includes multiple types of data. For example, the types of synchronization data include block header data, block body data, receipt data, state increment data, etc. Different types of synchronization data of the same block height can be requested from different target nodes in parallel, such as requesting block header data of block height N1 from target node M1 in parallel, requesting block body data of block height N1 from target node M2, and requesting state increment data of block height N1 from target node M3, etc. It is also possible to request synchronization data of multiple block heights from multiple target nodes in parallel, and the synchronization data of the same block height is requested from the same target node, such as requesting all types of synchronization data of block height N1 from target node M1 in parallel, requesting all types of synchronization data of block height N2 from target node M2, and requesting all types of synchronization data of block height N3 from target node M3, and so on. When requesting the same target node for synchronization data of the same block height, the target node corresponding to the current block height is determined according to the number of target nodes, the preset node selection algorithm and the current requested block height, and after determining the target nodes corresponding to all the block heights to be requested, synchronization data requests are made to all selected target nodes in parallel. Requesting the same target node for synchronization data of the same block height avoids duplication of requested data, which leads to waste of system resources. In addition, the node algorithm is used to randomly select the target node for requesting synchronization data, which realizes load balancing of requests and improves system performance. The block execution process of the blockchain is based on the current state ledger, and executes the interoperation contained in the transaction according to the pre-defined instruction set, and finally generates a changed state increment set or state increment data.

[0062] Step S240, verifying the synchronization data.

[0063] In this step, data verification is performed on different types of synchronization data. Different types of synchronization data can be verified in parallel, or after a certain type of synchronization data is verified, other types of synchronization data can be verified in parallel, which is not specifically limited here.

[0064] Step S250: synchronize the nodes to be synchronized according to the verified synchronization data.

[0065] In this step, after all synchronization data are verified, the nodes to be synchronized are synchronized according to the verified synchronization data.

[0066] Through the above steps, the nodes to be synchronized, the set of synchronized nodes and the synchronization range are determined; according to the set of synchronized nodes, the target node is determined; synchronization data is requested from the target node in parallel; the synchronization data includes state incremental data; data verification is performed on the synchronization data; and the nodes to be synchronized are synchronized according to the verified synchronization data. By requesting synchronization data from the target node in parallel and verifying the synchronization data including state incremental data, the existing synchronization method solves the problem that the transaction body in the block needs to be executed to verify the validity of the block data, and the amount of calculation during the synchronization process is large, resulting in low synchronization efficiency.

[0067] In some of the embodiments, the synchronization data also includes block header data and block body data, and data verification is performed on the synchronization data, including: data verification of the block header data of the target node; after the block header data of the target node passes the data verification, the block body data of the target node is verified; and / or, after the block header data of the target node passes the data verification, the state incremental data of the target node is verified.

[0068] In this step, the synchronization data includes block header data, block body data and state incremental data. First, the block header data of the target node is verified. After the block header data is successfully verified, the block body data and state incremental data of the corresponding block height are verified based on the information in the block header data. Among them, the verification of block body data and state incremental data can be performed in parallel. After the block header data is verified, the verification of synchronization data such as block body data and state incremental data is performed in parallel, which improves the efficiency of data verification and thus improves the synchronization efficiency.

[0069] In some embodiments, the synchronization data also includes receipt data. The block header data of the target node is first verified. After the block header data is successfully verified, the block body data, receipt data, and state increment data of the corresponding block height are verified based on the information in the block header data. The verification of the block body data, receipt data, and state increment data can be performed in parallel. After the block header data is verified, the verification of synchronization data such as block body data, receipt data, and state increment data is performed in parallel, which improves the efficiency of data verification and thus improves the synchronization efficiency.

[0070] In some of the embodiments, synchronizing the node to be synchronized according to the verified synchronization data includes: storing the verified synchronization data; updating the block height of the node to be synchronized to the block height of the target node to which the verified synchronization data belongs.

[0071] In this embodiment, when all synchronization data are verified, the verified synchronization data is stored. For example, the block height of the node to be synchronized is N1, and the block height of the node to be synchronized needs to be synchronized to N1+1. First, the synchronization data with a block height of N1+1 is obtained from the target node. The synchronization data can come from the same target node, or the synchronization data with a block height of N1+1 can be obtained from multiple target nodes in parallel. After obtaining the synchronization data, multiple types of synchronization data are verified. When all synchronization data with a block height of N1+1 are verified, the node to be synchronized stores the verified synchronization data and updates the block height of the node to be synchronized, where N1 is a positive integer. The synchronization data can come from the same target node, or it can obtain synchronization data with a block height of N1+1 from multiple target nodes in parallel. The data corresponding to each block height (such as block header, block body, receipt, status increment), these four types of synchronization data can come from different target nodes. Preferably, the four types of synchronization data come from different target nodes, and a specific type of synchronization data (such as block header) comes from a random target node.

[0072] In some of the embodiments, after the block header data of the target node passes the data verification, the state incremental data of the target node is verified, including: verifying whether the first state root node data of the state incremental data is consistent with the state root node data in the block header data corresponding to the state incremental data.

[0073] In this embodiment, after the state incremental data is obtained, the state incremental data includes the state root node data of the state incremental data. The state root node data in the state incremental data can be the state root node data obtained by the corresponding node after calculating the root node according to the storage format of the state incremental data, and the calculated state root node data is stored in the corresponding field of the state incremental data. The corresponding node here can be the target node in the blockchain. The block header data includes the state root node data of the state incremental data. The node to be synchronized verifies whether the first state root node data of the state incremental data is consistent with the state root node data in the block header data corresponding to the state incremental data. When the two are consistent, the state incremental data of the target node passes the verification. By verifying whether the first state root node data of the state incremental data is consistent with the state root node data in the block header data corresponding to the state incremental data, the accuracy of the verification of the synchronization data is improved.

[0074] In some of the embodiments, after the block header data of the target node passes the data verification, the state incremental data of the target node is verified, including: calculating the second state root node data based on the state incremental data; and verifying whether the first state root node data and the second state root node data are consistent.

[0075] In this implementation, the second state root node data is calculated based on the state incremental data; and it is verified whether the first state root node data and the second state root node data are consistent. According to the storage structure of the state incremental data, the node to be synchronized calculates the second state root node data, and the node to be synchronized verifies whether the calculated second state root node data and the first state root node data in the state incremental data are consistent. When the first state root node data and the second state root node data are consistent, the state incremental data of the target node passes the verification. It should be noted that it is possible to first verify whether the first state root node data of the state incremental data is consistent with the state root node data in the block header data corresponding to the state incremental data, and then verify whether the first state root node data and the second state root node data are consistent. When both are consistent, the state incremental data of the target node passes the verification. By verifying whether the first state root node data and the second state root node data are consistent, the accuracy of the verification of the synchronization data is improved.

[0076] In some embodiments, determining the target node according to the syncable node set includes: using a random algorithm to determine the target node from the syncable node set. The syncable node set is rearranged by a random algorithm. Due to the unpredictability of the arrangement algorithm, the remote node cannot predict in advance which block it is responsible for processing, thereby ensuring security.

[0077] The embodiments of the present application are described below.

[0078] The block execution process of the blockchain is as follows Figure 3 As shown in the figure, a built-in virtual machine uses the current state ledger as a benchmark and executes the interoperation contained in the transaction according to the pre-defined instruction set, ultimately generating a set of changed state increments. After the transaction is executed, the status ledger is updated: .in, is the state ledger before the update, is the updated state ledger, is the set of state increments that have been changed. By analogy, the block chain state ledger update diagram is as follows Figure 4 The state increment set here is equivalent to the state increment data in the above-mentioned embodiment.

[0079] In the embodiment, the state ledger is stored in a sparse Merkle tree format. The sparse Merkle tree consists of leaf nodes and intermediate nodes. The intermediate nodes store the index information of the leaf nodes, and the leaf nodes store specific data. When data is added or changed, it corresponds to the addition of a leaf node. When data is deleted, the existing leaf node is not deleted, but the index of the leaf node in the intermediate node is cancelled, that is, a new intermediate node with the changed index is added. For example, when adding or changing data, refer to Figure 5a , the old state includes the root node 51, the root node 51 includes the index of the intermediate node 53, the intermediate node 53 includes the index of the intermediate node 54, the intermediate node 54 includes the index of the leaf node l1 and the leaf node l2, when the data is added or changed, it corresponds to the addition of the leaf node l3, the new state increment set includes the root node 52, the root node 52 includes the index of the intermediate node 55, the intermediate node 55 includes the index of the leaf node l3, and the index of the intermediate node 54 is added to the intermediate node 55. When deleting data, refer to Figure 5b If the data corresponding to leaf node l4 needs to be deleted, leaf node l4 will not be deleted, but the index of leaf node l4 in intermediate node 63 will be cancelled, that is, a new intermediate node 64 with changed index will be added, intermediate node 64 includes the index of intermediate node 65, intermediate node 65 includes the index of leaf node l5 and leaf node l6, and the indexes are changed upward in sequence to obtain root node 62, which includes the index of intermediate node 64. That is, the old path is root node 61->intermediate node 63->leaf node l4->intermediate node 65->(leaf node l5, leaf node l6), and the new path is root node 62->intermediate node 64->intermediate node 65->(leaf node l5, leaf node l6). The new path can share the same nodes with the old path, and only new nodes need to be generated according to the state increment set (including adding, changing or deleting data, etc.), which saves system resources.

[0080] The block synchronization based on state increment will synchronize the block header data, block body and receipt data and state increment data. Among them, the block header data includes the block header information, which contains the current block hash, parent block hash, receipt hash, state root hash, etc. This information can be used for subsequent data security verification. Block body and receipt data: The block body consists of transaction set data, and the receipt data is the result generated after the transaction set is executed in the blockchain virtual machine. Since the state increment synchronization will not execute transactions to generate receipts, the receipt data needs to be requested from other nodes. The state increment set is the node set of the sparse Merkel tree change.

[0081] The specific synchronization process is as follows: Figure 6 As shown, the following steps are included:

[0082] Step S610, start synchronization.

[0083] Step S620, determine the synchronization range and node set.

[0084] In this step, after the synchronization scope is determined, a set of nodes that can be synchronized is determined based on the determined synchronization scope.

[0085] Step S630, running the working threads in parallel.

[0086] Step S640, requesting synchronization of data.

[0087] In this step, the requested synchronization data includes block header data, block body and receipt data, and state increment data. Block header data, block body and receipt data, and state increment data can be requested in parallel to improve data request efficiency. Request block header data, the random algorithm confirms the requesting node IP, that is, the target node IP, downloads the block header, and fills the block header set. Request block body / receipt data, the random algorithm confirms the requesting node IP, that is, the target node IP, downloads the block body / receipt data, and fills the block data set. Request state increment, the random algorithm confirms the requesting node IP, that is, the target node IP, downloads the state increment, and verifies the validity of the state increment. Confirm multiple target nodes from the set of nodes that can be synchronized. For example, if the block data with a synchronization block height of 100~1000 is requested, the number of target nodes requested is 4, and all data within the synchronization range can be requested from 4 nodes at the same time. For example, when requesting block data with a block height of 101 from target node M1 and requesting block data with a block height of 102 from target node M2, there is no need to wait until the block data with a block height of 101 is returned by target node M1 before requesting block data with other block heights, thereby achieving parallelism.

[0088] Step S650: data security verification.

[0089] In this step, data security verification is performed on different types of synchronization data. After the verification is passed, all data is stored in a certain format. The specific storage content is: block header data, block data, receipt data, status data, etc.

[0090] Through the above steps, the synchronization scope and node set are determined, the working threads are run in parallel, the synchronization data is requested, and the data security verification is performed. By requesting the synchronization data from the target node in parallel and verifying the synchronization data including the state incremental data, the problem of the existing synchronization method that requires the execution of the transaction body in the block to verify the validity of the block data, the large amount of calculation during the synchronization process, and thus the low synchronization efficiency is solved.

[0091] Since these data are physically isolated, for performance reasons, multiple nodes can request in parallel. It is worth noting that subsequent data can only be verified after the block header data is verified. The block header data needs to be verified according to the order of the blockchain. For example, only after the block header data with a block height of 100 is verified, the block header data with a block height of 101 can be verified. After the block header data of the corresponding block height is verified, the block data, receipt data, and status data of the corresponding block height can be verified, and the block data, receipt data, and status data can be verified in parallel. For example, after the block header data with a block height of 101 is verified, the block data, receipt data, and status data with a block height of 101 can be verified in parallel without waiting for the block data, receipt data, and status data with a block height of 100 to be verified.

[0092] The IP (identification) of the target node of the request should take into account randomness and load balancing. For example, a random selection algorithm as shown in formula (1) can be used to determine the target node of the request.

[0093] (1)

[0094] in, node represents a node, S represents the set of all syncable remote nodes, rand_shift(S) represents a random algorithm function, len represents the length function, mod is the modulus operation, and N represents the block height of the current request. The following is an example of requesting synchronization data of the same block height to the same target node. Assume that the synchronization range is 100~1000, and the syncable remote node set S includes 4 target nodes M1, M2, M3 and M4. rand_shift(S) Rearrange the set S, len ( rand_shift(S)) is 4, assuming that the rearranged order is M2, M3, M4, M1. It should be noted that the rearranged order here is only for exemplary explanation and is not limited. The rearranged order here can be any random order. According to formula (1), all target nodes with a synchronization range of 100 to 1000 are determined: the target node requested by block height 100 is M2, the target node requested by block height 101 is M3, the target node requested by block height 102 is M4, the target node requested by block height 103 is M1, the target node requested by block height 104 is M2... The target node requested by block height 1000 is M2. After all target nodes are determined, synchronization data is requested from all target nodes in parallel. The set is rearranged by a random algorithm. Due to the unpredictability of the arrangement algorithm, the remote node cannot predict in advance which block it is responsible for processing, which guarantees security to a certain extent. At the same time, since the block height is strictly increasing, N represents the block height of the current request, and the request load balancing can be achieved through the remainder algorithm. This method can avoid downloading too much erroneous data from the same node, thereby forming a new longer chain.

[0095] The security verification of synchronized data is divided into three parts: block header verification, block body / receipt verification and state increment verification. All security verifications need to verify two parts, namely existence verification and validity verification. Existence verification: whether the data exists in the blockchain ledger. Validity verification: the authenticity of the data, that is, whether it has been tampered with. Among them, the data structure of the complete block header (block_header) usually contains the following fields: block_num (block height), parent_hash (previous block hash value), block_hash (current block hash value), receipt_root (receipt root), transaction_root (transaction root), state_root (state root).

[0096] Existence verification is usually done through the hash value recorded in the block header. Figure 7 The verification process includes the following steps:

[0097] Step S710, block header verification.

[0098] The lagging node obtains the block hash of the latest block height in the local ledger and uses it as the parent block hash. If the current latest height is 12 and the blocks to be synchronized are 13 to 20, then a legal block header with a block height of 13 meets the following two conditions: (1) Ensure the continuity and integrity of the blockchain: verify whether the hash value of the previous block is consistent with the hash value of the previous block specified in the current block header, that is, (2) Ensure the correctness of the block header: Is the data in the block header obtained through the specified calculation method? Is it established, among which, Hash is a hash function used to calculate the hash value. If both conditions are met, the block header verification passes. After the verification passes, the parent block hash is updated to the current block hash, and the verification of the next block continues. When a block header verification fails, a new node is selected for synchronization and the block header verification logic is performed again. Wait for all block headers to pass the verification, that is, the block header verification is completed. The process of block header verification is as follows: Figure 8 As shown, the block hash of the latest block in the local ledger is obtained, the parent block hash is updated, and it is determined whether the hash value of the previous block is consistent with the hash value of the previous block specified in the current block header, and whether the data of the block header is obtained through the specified calculation method. If the hash value of the current block is consistent with the hash value of the previous block specified in the current block header and the data of the block header is obtained through the specified calculation method, the verification passes. After the verification passes, the parent block hash is updated to the current block hash, and the verification of the next block continues.

[0099] Step S720: verifying block data or receipt data.

[0100] Since the block body or receipt verification needs to rely on a valid block header data, the block header verification is the prerequisite for the block body or receipt verification. A valid block body or receipt with a block height of 13 verifies whether the transaction body or receipt data is obtained through the specified calculation method, that is: , .in, body_data is the block data, receipt_data The receipt data. That is, verify whether the hash value calculated based on the block body data is consistent with the transaction root in the block header data, and verify whether the hash value calculated based on the receipt data is consistent with the receipt root in the block header data. If they are consistent, the verification passes.

[0101] Step S730, status increment check.

[0102] The state increment verification is divided into existence verification and validity verification. Existence verification: whether the state_root of the state increment is equal to the state_root of the block header, ,in, state_root for state increment, The state_root of the block header is used to verify whether the state_root of the state increment is equal to the state_root of the block header. Validity verification: Each node of the state increment is calculated from bottom to top according to the specified hash calculation method to determine whether the correct state_root can be restored. ,in, To calculate the hash value based on the state increment data, that is, to verify whether the state_root calculated based on the state increment is equal to the state_root of the state increment and the state_root of the block header. Here, state_root can be the hash value calculated based on the hash function. The hash calculation method is as follows Fig. 9 As described, the leaf node l3 only includes data, the intermediate node 4, the intermediate node 3 and the root node include indexes, the intermediate node 4 includes the indexes of the hash values ​​of the leaf node l1, the hash value of the leaf node l2 and the hash value of the leaf node l3, the intermediate node 3 includes the indexes of the hash values ​​of the intermediate node 4, the hash value of the intermediate node 5 and the hash value of the intermediate node 6, and the root node includes the indexes of the hash values ​​of the intermediate node 1, the hash value of the intermediate node 2 and the hash value of the intermediate node 3. According to the index path provided by the state increment, it is verified whether the index of the root node contains the hash value of the intermediate node 3, whether the index of the intermediate node 3 contains the hash value of the intermediate node 4, and whether the index of the intermediate node 4 contains the hash value of the leaf node l3. After the link verification is passed, the validity of the root node data is verified. The hash value is calculated according to the root node, and the hash value of the root node is the state root. It is verified whether the hash value of the root node calculated according to the state increment data is the same as the state root of the block header. After the verification is passed, the existence of the root node is verified. That is, the state increment data verification is passed.

[0103] After the state increment verification is passed, the current state is updated according to the calculation method of the previous step, that is: After all verifications are passed, all data is stored in a certain format. The specific storage contents are: block header data, block data, receipt data, status data, etc.

[0104] It should be noted that although Figure 7 The logical order is shown in FIG. 1 , but in some cases, the steps shown or described may be performed in a different order than that shown or described herein. For example, step S720 and step S730 may be performed in parallel, or step S730 may be performed first and then step S720.

[0105] The embodiment of the present application effectively avoids the risk of continuously downloading multiple block data from the same node by adopting a random node synchronization algorithm. In addition, the prior art also uses snapshot synchronization to synchronize lagging nodes, that is, the lagging nodes download the snapshot data provided by the official, and the transaction body before the snapshot height does not need to be executed, and the state tree is reconstructed according to the state data block in the snapshot. The transaction body after the snapshot height is executed normally. Compared with the full synchronization, the performance of this synchronization method is greatly improved, but the snapshot does not perform security verification, and it is necessary to trust the data provided by a third party, and the safety factor is low. The synchronization data of the embodiment of the present application has undergone a strict security verification algorithm. As long as the nodes in the network meet the security assumptions, the method of the embodiment of the present application is safer and more reliable than the traditional snapshot synchronization method. The synchronization method of the embodiment of the present application has higher performance, which can realize the rapid joining of nodes to the network, thereby increasing the rate at which the blockchain network processes transactions and reducing transaction processing delays. The embodiment of the present application can reduce the hardware cost of the archiving node. Generally speaking, the archiving node needs to have an excellent CPU core and a hard disk with fast read and write, which means high hardware costs. The synchronization mechanism of the embodiment of the present application skips the transaction execution process, and performs synchronization data security verification based on state incremental synchronization, which greatly reduces the CPU calculation and read and write storage load, and can significantly reduce hardware costs. It should be noted that the steps shown in the above process or the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that here.

[0106] In this embodiment, a blockchain synchronization device based on state increment is also provided, which is used to implement the above embodiments and preferred implementation modes, and will not be repeated for those that have been described. The terms "module", "unit", "subunit", etc. used below can implement a combination of software and / or hardware for predetermined functions. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0107] Fig.10 is a structural block diagram of a blockchain synchronization device based on state increment according to an embodiment of the present application, such as Fig.10 As shown, the device comprises:

[0108] The first determination module 10 is used to determine the node to be synchronized, the set of synchronizeable nodes and the synchronization range; the node to be synchronized is the backward node in the blockchain;

[0109] A second determination module 20, configured to determine a target node according to the synchronizable node set;

[0110] The request module 30 is used to request synchronization data from the target node in parallel; the synchronization data includes state increment data;

[0111] A verification module 40, used for performing data verification on the synchronization data;

[0112] The synchronization module 50 is used to synchronize the nodes to be synchronized according to the verified synchronization data.

[0113] In some embodiments, the second determining module 20 is further configured to:

[0114] The target node is determined according to the block height of the nodes in the syncable node set.

[0115] In some embodiments, the synchronization data also includes block header data and block body data. The synchronization data is verified, and the verification module 40 is further used to:

[0116] Verify the block header data of the target node;

[0117] After the block header data of the target node passes the data verification, the block body data of the target node is verified;

[0118] And / or, after the block header data of the target node passes the data verification, the state incremental data of the target node is verified.

[0119] In some embodiments, the synchronization module 50 is further configured to:

[0120] Store the verified synchronization data;

[0121] Update the block height of the node to be synchronized to the block height of the target node to which the verified synchronization data belongs.

[0122] In some embodiments, the verification module 40 is further configured to:

[0123] Verify whether the first state root node data of the state incremental data is consistent with the state root node data in the block header data corresponding to the state incremental data.

[0124] In some embodiments, the verification module 40 is further configured to:

[0125] According to the state increment data, the second state root node data is calculated;

[0126] Verify whether the first-state root node data and the second-state root node data are consistent.

[0127] In some embodiments, the second determining module 20 is further configured to:

[0128] A random algorithm is used to determine the target node from the set of syncable nodes.

[0129] It should be noted that the above modules can be functional modules or program modules, and can be implemented by software or hardware. For modules implemented by hardware, the above modules can be located in the same processor; or the above modules can be located in different processors in any combination.

[0130] In this embodiment, an electronic device is further provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0131] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0132] Optionally, in this embodiment, the processor may be configured to perform the following steps through a computer program:

[0133] S1, determine the nodes to be synchronized, the set of synchronizeable nodes and the synchronization range; the nodes to be synchronized are the backward nodes in the blockchain;

[0134] S2, determine the target node based on the set of syncable nodes;

[0135] S3, request synchronization data from the target node in parallel; the synchronization data includes state increment data;

[0136] S4, verifying the synchronization data;

[0137] S5, synchronizing the nodes to be synchronized according to the verified synchronization data.

[0138] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementation modes, and will not be repeated in this embodiment.

[0139] In addition, in combination with a blockchain synchronization method based on state increment provided in the above embodiment, a storage medium can also be provided in this embodiment to implement. A computer program is stored on the storage medium; when the computer program is executed by the processor, any blockchain synchronization method based on state increment in the above embodiment is implemented.

[0140] It should be understood that the specific embodiments described herein are only used to explain the application, rather than to limit it. Based on the embodiments provided in this application, all other embodiments obtained by ordinary technicians in this field without creative work are within the protection scope of this application.

[0141] Obviously, the drawings are only some examples or embodiments of the present application. For ordinary technicians in the field, the present application can also be applied to other similar situations based on these drawings without creative work. In addition, it is understandable that although the work done in this development process may be complicated and lengthy, for ordinary technicians in the field, certain changes in design, manufacturing or production based on the technical content disclosed in this application are only conventional technical means and should not be regarded as insufficient content disclosed in this application.

[0142] The term "embodiment" in this application refers to a specific feature, structure or characteristic described in conjunction with the embodiment that can be included in at least one embodiment of the present application. The appearance of this phrase in various locations in the specification does not necessarily mean the same embodiment, nor does it mean that it is mutually exclusive with other embodiments and is independent or optional. It is clearly or implicitly understood by those of ordinary skill in the art that the embodiments described in this application can be combined with other embodiments without conflict.

[0143] The above-mentioned 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 patent protection. 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 scope of protection of the present application. Therefore, the scope of protection of the present application shall be subject to the attached claims.

Claims

1. A blockchain synchronization method based on state increment, characterized in that: The method comprises: Determine the node to be synchronized, the set of synchronizeable nodes and the synchronization range; the node to be synchronized is a backward node in the blockchain; Determine a target node according to the syncable node set; Requesting synchronization data from the target node in parallel; the synchronization data includes block header data, block body data and state increment data; Performing data verification on the synchronization data; Synchronize the node to be synchronized according to the verified synchronization data; Wherein, requesting synchronization data from the target node in parallel includes: requesting different types of synchronization data of the same block height from different target nodes in parallel; The data verification of the synchronization data includes: firstly verifying the block header data of the target node, and after the block header data is successfully verified, based on the information in the block header data, verifying the block body data and the state increment data of the corresponding block height in parallel; Among them, the state ledger of the blockchain is stored in a sparse Merkle tree format, the state incremental data is a set of nodes changed in the sparse Merkle tree, and the verification of the state incremental data includes validity verification, and the validity verification includes: whether the state root calculated from bottom to top by a specified hash calculation method for each node of the state incremental data is equal to the state root corresponding to the state incremental data.

2. A blockchain synchronization method based on state increment according to claim 1, characterized in that: The step of determining the target node according to the synchronizable node set includes: The target node is determined according to the block height of the node in the syncable node set.

3. A blockchain synchronization method based on state increment according to claim 1, characterized in that: The step of synchronizing the node to be synchronized according to the verified synchronization data includes: Storing the verified synchronization data; The block height of the node to be synchronized is updated to the block height of the target node to which the verified synchronization data belongs.

4. A blockchain synchronization method based on state increment according to claim 1, characterized in that: After the block header data of the target node passes the data verification, the state incremental data of the target node is verified, including: Verify whether the first state root node data of the state incremental data is consistent with the state root node data in the block header data corresponding to the state incremental data.

5. A blockchain synchronization method based on state increment according to claim 4, characterized in that: After the block header data of the target node passes the data verification, the state incremental data of the target node is verified, including: Calculate and obtain the second state root node data according to the state increment data; Verify whether the first-state root node data and the second-state root node data are consistent.

6. A blockchain synchronization method based on state increment according to claim 1, characterized in that: The step of determining the target node according to the synchronizable node set includes: A random algorithm is used to determine a target node from the synchronizable node set.

7. A blockchain synchronization device based on state increment, characterized in that: The device comprises: A first determination module is used to determine the node to be synchronized, the set of synchronizeable nodes and the synchronization range; the node to be synchronized is a backward node in the blockchain; A second determination module, configured to determine a target node according to the synchronizable node set; A request module, used to request synchronization data from the target node in parallel; the synchronization data includes block header data, block body data and state increment data; A verification module, used for performing data verification on the synchronization data; A synchronization module, used to synchronize the nodes to be synchronized according to the verified synchronization data; Wherein, requesting synchronization data from the target node in parallel includes: requesting different types of synchronization data of the same block height from different target nodes in parallel; The data verification of the synchronization data includes: firstly verifying the block header data of the target node, and after the block header data is successfully verified, based on the information in the block header data, verifying the block body data and the state increment data of the corresponding block height in parallel; Among them, the state ledger of the blockchain is stored in a sparse Merkle tree format, the state incremental data is a set of nodes changed in the sparse Merkle tree, and the verification of the state incremental data includes validity verification, and the validity verification includes: whether the state root calculated from bottom to top by a specified hash calculation method for each node of the state incremental data is equal to the state root corresponding to the state incremental data.

8. A device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to run the computer program to execute the state increment-based blockchain synchronization method according to any one of claims 1 to 6.

9. 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 blockchain synchronization method based on state increment according to any one of claims 1 to 6 are implemented.

Images