Blockchain node block data synchronization method and device

Abstract

The application discloses a kind of block data synchronization method and device of blockchain node, comprising: before block data synchronization, by familiar node, each blockchain node is sent to the detection request by the node to be synchronized;Detection request is used to obtain the state information of blockchain node;The node to be synchronized is based on the response request of each blockchain node feedback, determines first round of synchronization node and node rotation number N;Wherein, the more the number of first round of synchronization node, the less the node rotation number;The node to be synchronized is based on the block synchronization condition of each i round of synchronization node in i round of node rotation, determines i+1 round of synchronization node, until N round of block synchronization ends;I is greater than or equal to 0.To this end, the efficiency of block data synchronization is improved, the load of synchronization node is avoided for a long time, the influence of synchronization node on block consensus is reduced, and the real-time of determining the load condition of each blockchain node can be improved by selecting the blockchain node with lower load multiple times, and the efficiency of block data synchronization is improved.

Description

Technical Field

[0001] This invention relates to the field of financial technology (Fintech), and more particularly to a method and apparatus for synchronizing block data of blockchain nodes. Background Technology

[0002] With the development of computer technology, more and more technologies (such as blockchain, cloud computing or big data) are being applied in the financial field. The traditional financial industry is gradually transforming into financial technology, and big data technology is no exception. However, due to the security and real-time requirements of the financial and payment industries, higher requirements are also placed on the synchronization of block data in big data technology.

[0003] In a blockchain system, the block heights of different blockchain nodes should be consistent. However, in some scenarios, there may be blockchain nodes with inconsistent block heights (such as when a new blockchain node is added to the blockchain system, or when there is a delay in the blockchain node).

[0004] To ensure that blockchain nodes with inconsistent block heights achieve the same block height, existing technologies typically involve the blockchain nodes with inconsistent block heights obtaining block data from a synchronization node (i.e., a blockchain node with consistent block heights) to synchronize the block data, thereby achieving consistency in block heights across all blockchain nodes.

[0005] However, in existing technologies, the selection of synchronization nodes is generally done randomly, which makes it impossible to determine the load of the synchronization nodes. This can result in the selected synchronization nodes having high loads, affecting the efficiency of block data synchronization. Furthermore, the blockchain nodes are not replaced during the block data synchronization process because the synchronization of block data will increase the load of the synchronization nodes, leading to a prolonged increase in the load of the synchronization nodes, which will affect the consensus of the synchronization nodes and the consensus efficiency of the blockchain system. Summary of the Invention

[0006] This invention provides a method and apparatus for synchronizing block data of blockchain nodes.

[0007] In a first aspect, embodiments of the present invention provide a method for synchronizing block data of a blockchain node, comprising:

[0008] Before synchronizing block data, the node to be synchronized sends a probe request to each blockchain node through a well-known node; the probe request is used to obtain the status information of the blockchain node.

[0009] The node to be synchronized determines the first round of synchronization nodes and the number of node rotations N based on the response requests from each blockchain node; wherein, the more nodes in the first round of synchronization, the fewer the number of node rotations.

[0010] The node to be synchronized is determined based on the block synchronization status of each synchronization node in the i-th round of node rotation, and the synchronization node for the (i+1)-th round is determined until the N-th round of block synchronization ends; i is greater than or equal to 0.

[0011] In the above technical solution, the synchronization node is determined by the response requests from each blockchain node to prevent the selected synchronization node from being overloaded. That is, the blockchain node with a lower load is selected as the synchronization node, thereby improving the efficiency of block data synchronization. The synchronization node for block data synchronization is changed through node rotation, thereby avoiding the increase of synchronization node load over a long period of time, reducing the impact of synchronization node on block consensus, and at the same time, the blockchain node with a lower load can be selected multiple times to increase the real-time determination of the load status of each blockchain node and improve the efficiency of block data synchronization.

[0012] Optionally, probe requests can be sent to various blockchain nodes through well-known nodes, including:

[0013] The node to be synchronized constructs a probe request and sends the probe request to a well-known node of the node to be synchronized;

[0014] For any known node, the known node determines that the probe request is not recorded in the first record; the first record is used to record the probe request that has been processed; the known node sends the probe request to the known nodes of the known node that have not yet propagated the probe request based on the second record; the second record is used to record the blockchain nodes that have propagated the probe request; the known node updates the first record and the second record and determines the response request.

[0015] In the above technical solution, the first record is used to record the probe requests that have been processed, and the second record is used to record the blockchain nodes that have propagated the probe requests. For any well-known node of the node to be synchronized, after receiving the probe request, the well-known node accesses the first record and the second record, thereby avoiding the repeated processing of the same probe request, avoiding the repeated propagation of the probe request to the blockchain nodes that have propagated the probe request, reducing the propagation duplication of each blockchain node, and avoiding the waste of computing resources.

[0016] Optionally, the node to be synchronized constructs a probe request, including:

[0017] The node to be synchronized generates a probe request based on the probe sequence number, the propagation list, and the communication address of the node to be synchronized; the probe sequence number is used to indicate the order of node rotation; the propagation list is used to record the blockchain nodes that have sent the probe request.

[0018] In the above technical solution, the probe sequence number is used to indicate the order of node rotation, thereby enabling the blockchain node to respond to the feedback request again each time the node rotates, and to re-determine the synchronization node. This avoids increasing the load on the synchronization node for a long time, reduces the impact of the synchronization node on the block consensus, and improves the efficiency of block data synchronization. The propagation list is used to record the blockchain nodes that have sent the probe request, avoiding repeated propagation of the probe request to the already propagated blockchain nodes and avoiding waste of computing resources. By using the communication address of the node to be synchronized, the blockchain node can directly provide feedback to the node to be synchronized, improving the efficiency of feedback response requests, improving the efficiency of the node to be synchronized in determining the synchronization node, and thus increasing the efficiency of data synchronization.

[0019] Optionally, the response request includes: the communication address of the blockchain node, the load index, the construction time of the response request, the maximum block height, and the probe sequence number of the probe request;

[0020] The nodes to be synchronized are determined based on the response requests from each blockchain node, including:

[0021] The node to be synchronized determines, from the response requests fed back by each blockchain node, the response requests that meet the first set condition of load index and the second set condition of request propagation time; the request propagation time is determined based on the request construction time and the request reception time.

[0022] The nodes to be synchronized will be the blockchain nodes corresponding to the response requests that meet the first set condition and the second set condition, which will be the first round of synchronization nodes.

[0023] In the above technical solution, a blockchain node with a smaller load is selected as the synchronization node by using the load index; and a blockchain node with a faster data transmission speed is selected as the synchronization node by using the request propagation time, thereby improving the efficiency of block data synchronization.

[0024] Optionally, the node to be synchronized determines the (i+1)th round synchronization node based on the block synchronization status of each synchronization node in the i-th round of node rotation, including:

[0025] The node to be synchronized sends an inquiry request to the blockchain node that is not a synchronization node in the i-th round;

[0026] For any i-th round synchronization node, the node to be synchronized determines the i-th round block data to be synchronized by the i-th round synchronization node, and receives the i-th round block data sent by the i-th round synchronization node and a feedback request carrying status information sent by the i-th round synchronization node when the i-th round block data synchronization ends.

[0027] The node to be synchronized determines the synchronization node for the (i+1)th round based on each query request and each feedback request.

[0028] In the above technical solution, the synchronization node for the (i+1)th round is determined by sending query requests to blockchain nodes that are not synchronization nodes in the i-th round and the status information sent by the synchronization node in the i-th round when the block data synchronization ends. This achieves the re-determination of synchronization nodes, thereby avoiding long-term increases in the load of synchronization nodes, reducing the impact of synchronization nodes on block consensus, and improving the efficiency of block data synchronization.

[0029] Optionally, the node to be synchronized determines the block data of the i-th round to be synchronized by the i-th round synchronization node, including:

[0030] The node to be synchronized determines the number of blocks to be synchronized in each node rotation based on the maximum block height in the response request and the number of node rotations; the number of node rotations is inversely proportional to the number of nodes in the first round of synchronization.

[0031] The node to be synchronized determines the block data to be synchronized in the i-th round based on the number of blocks to be synchronized in each node rotation and the number of synchronization nodes in the i-th round.

[0032] In the above technical solution, the number of node rotations is inversely proportional to the number of synchronized nodes in the first round. That is, if the number of synchronized nodes in the first round is small, it indicates that the overall resources of the blockchain system are tight and there are few blockchain nodes that meet the first and second conditions. At this time, the number of node rotations is increased adaptively to ensure the load balance of each blockchain node in the blockchain system, avoid increasing the load of synchronized nodes for a long time, and reduce the impact of synchronized nodes on block consensus.

[0033] Optionally, the node to be synchronized determines the synchronization node for the (i+1)th round based on each query request and each feedback request, including:

[0034] The node to be synchronized receives the response request from the blockchain node that is not a synchronization node in the i-th round, based on the query request.

[0035] The node to be synchronized determines, from the response requests fed back according to the inquiry request and the feedback requests of the i-th round of synchronization nodes, the response requests and / or feedback requests whose request propagation duration meets the third set condition.

[0036] The node to be synchronized determines the (i+1)th round synchronization node from response requests and / or feedback requests that meet the third set condition based on the load index.

[0037] In the above technical solution, a blockchain node with a smaller load is selected as the synchronization node by using the load index; a blockchain node with a faster data transmission speed is selected as the synchronization node by using the request propagation time, thereby improving the efficiency of block data synchronization; and different setting conditions are used to improve the flexibility of determining the synchronization node.

[0038] Secondly, embodiments of the present invention provide a blockchain node block data synchronization device, comprising:

[0039] The sending module is used to send probe requests to each blockchain node through a well-known node before the block data is synchronized; the probe requests are used to obtain the status information of the blockchain nodes.

[0040] The processing module is used to determine the first round of synchronization nodes and the number of node rotations N based on the response requests from each blockchain node; the more synchronization nodes there are in the first round, the fewer node rotations there will be.

[0041] Based on the block synchronization status of each synchronization node in the i-th round of node rotation, determine the synchronization node for the (i+1)-th round, until the N-th round of block synchronization ends; i is greater than or equal to 0.

[0042] Optionally, the sending module is specifically used for:

[0043] A probe request is constructed and sent to a well-known node of the node to be synchronized.

[0044] Optionally, the sending module is specifically used for:

[0045] A probe request is generated based on the probe sequence number, the propagation list, and the communication address of the node to be synchronized; the probe sequence number is used to indicate the order of node rotation; the propagation list is used to record the blockchain nodes that have sent the probe request.

[0046] Optionally, the response request includes: the communication address of the blockchain node, the load index, the construction time of the response request, the maximum block height, and the probe sequence number of the probe request;

[0047] The processing module is specifically used for:

[0048] From the response requests fed back by each blockchain node, response requests that meet the first set condition in terms of load index and the second set condition in terms of request propagation time are identified; the request propagation time is determined based on the request construction time and the request reception time.

[0049] The blockchain nodes corresponding to the response requests that meet the first and second conditions are identified as the first-round synchronization nodes.

[0050] Optionally, the processing module is specifically used for:

[0051] Send query requests to blockchain nodes that are not synchronization nodes in round i;

[0052] For any i-th round synchronization node, determine the i-th round block data to be synchronized by the i-th round synchronization node, and receive the i-th round block data sent by the i-th round synchronization node and the feedback request carrying status information sent by the i-th round synchronization node when the i-th round block data synchronization ends.

[0053] Based on each query request and each feedback request, determine the synchronization node for the (i+1)th round.

[0054] Optionally, the processing module is specifically used for:

[0055] The number of blocks to be synchronized in each node rotation is determined based on the maximum block height and the number of node rotations in the response request; the number of node rotations is inversely proportional to the number of nodes synchronized in the first round.

[0056] The number of blocks to be synchronized in each node rotation and the number of synchronization nodes in the i-th round are used to determine the blocks to be synchronized in the i-th round.

[0057] Optionally, the processing module is specifically used for:

[0058] Receive response requests from blockchain nodes that are not synchronization nodes in round i, based on the query request;

[0059] From the response requests fed back according to the inquiry request and the feedback requests of the i-th round of synchronization nodes, determine the response requests and / or feedback requests whose request propagation duration satisfies the third set condition;

[0060] The (i+1)th round synchronization node is determined from the response requests and / or feedback requests that meet the third set condition based on the load index.

[0061] Thirdly, embodiments of the present invention also provide a computer device, comprising:

[0062] Memory, used to store program instructions;

[0063] The processor is used to call the program instructions stored in the memory and execute the block data synchronization of the aforementioned blockchain nodes according to the obtained program.

[0064] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing computer-executable instructions for causing a computer to perform block data synchronization of the aforementioned blockchain node. Attached Figure Description

[0065] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0066] Figure 1 A schematic diagram of a system architecture provided for an embodiment of the present invention;

[0067] Figure 2 A flowchart illustrating a method for synchronizing block data of a blockchain node according to an embodiment of the present invention;

[0068] Figure 3 A schematic diagram illustrating the propagation of a probe request, provided as an embodiment of the present invention;

[0069] Figure 4 A schematic diagram illustrating the propagation of a probe request, provided as an embodiment of the present invention;

[0070] Figure 5 This is a schematic diagram of the structure of a blockchain node block data synchronization device provided in an embodiment of the present invention. Detailed Implementation

[0071] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0072] In a blockchain system, the block heights of different blockchain nodes should be consistent. However, in some scenarios, there may be blockchain nodes with inconsistent block heights (such as when a new blockchain node is added to the blockchain system, or when there is a delay in the blockchain node).

[0073] To ensure that blockchain nodes with inconsistent block heights achieve the same block height, existing technologies typically involve the blockchain nodes with inconsistent block heights obtaining block data from a synchronization node (i.e., a blockchain node with consistent block heights) to synchronize the block data, thereby achieving consistency in block heights across all blockchain nodes.

[0074] Taking the addition of blockchain node A as an example, first determine the maximum block height of synchronization node B, and then divide the maximum block height into shards. For example, if the maximum block height is 100, divide it into 10 shards, namely 1-10, 11-20, ..., 91-100. Then, according to the shards, obtain the block data corresponding to the block height from multiple synchronization nodes, thereby realizing the synchronization of block data of the new blockchain node A.

[0075] However, in existing technologies, the selection of synchronization nodes is generally done randomly, which makes it impossible to determine the load of the synchronization nodes. There are cases where the selected synchronization nodes have high loads, affecting the efficiency of block data synchronization. For example, if blockchain node B has a high load but is selected as a synchronization node, the load of blockchain node B will increase when synchronizing block data from the newly added blockchain node A. Due to the complexity of consensus algorithms and related transaction packaging and verification algorithms, the load of blockchain nodes will increase rapidly during the consensus and transaction packaging process, further exacerbating the load situation of blockchain node B and reducing the consensus efficiency of blockchain node B in the blockchain system.

[0076] Furthermore, during the block data synchronization process, the synchronization node is not replaced. For example, the maximum block height in existing technologies is generally in the tens of thousands. Assuming the maximum block height in a blockchain system is 10,000, even if the block data to be synchronized is divided into 10 shards, each shard still requires 1,000 blocks to be synchronized. In other words, a new blockchain node needs to obtain 1,000 blocks to be synchronized from a synchronization node, which will undoubtedly increase the load on the synchronization node for a long time. Without taking the global load of the blockchain system as a basis, the load of the blockchain system cannot be balanced, which affects the consensus of the synchronization nodes and the consensus efficiency of the blockchain system.

[0077] Therefore, there is an urgent need for a method to synchronize block data of blockchain nodes, which can select synchronization nodes based on the responsibility of blockchain nodes, avoid increasing the load of synchronization nodes for a long time, reduce the impact of synchronization nodes on block consensus, and improve the efficiency of block data synchronization.

[0078] Figure 1 An exemplary system architecture applicable to an embodiment of the present invention is shown, the system architecture including a blockchain system 100.

[0079] The blockchain system 100 includes ordinary nodes and backbone nodes; backbone nodes are generally blockchain nodes that participate in the creation of the blockchain system, and backbone nodes are generally directly or indirectly connected to each other; for example, backbone node 1 is directly connected to backbone node 2, and backbone node 2 and backbone node 4 are indirectly connected.

[0080] Ordinary nodes are generally blockchain nodes that are added after the blockchain system is created. When they are added, they are directly connected to multiple blockchain nodes and indirectly connected to other nodes. For example, ordinary node 4 is directly connected to backbone node 1 and backbone node 4, and ordinary node 4 is indirectly connected to other blockchain nodes (such as backbone node 2, backbone node 3, ordinary node 1, etc.).

[0081] The node to be synchronized in this embodiment of the invention can be any ordinary node or any backbone node.

[0082] It should be noted that the above Figure 1 The structure shown is merely an example, illustrating only 4 backbone nodes and 4 ordinary nodes, but the number of backbone nodes and ordinary nodes is not limited in the embodiments of the present invention.

[0083] Based on the above description Figure 2 An exemplary schematic diagram of a block data synchronization method for a blockchain node provided by an embodiment of the present invention is shown. This process can be executed by a block data synchronization device of a blockchain node.

[0084] like Figure 2 As shown, the process specifically includes:

[0085] Step 210: Before the block data is synchronized, the node to be synchronized sends a probe request to each blockchain node through the well-known node.

[0086] In this embodiment of the invention, the probe request is constructed by the node to be synchronized and is used to obtain the state information of the blockchain node.

[0087] Step 220: The node to be synchronized determines the first synchronization node and the node rotation number N based on the response requests from each blockchain node.

[0088] In this embodiment of the invention, the nodes to be synchronized determine the first round of synchronization nodes based on each response request by setting conditions, and the more nodes in the first round of synchronization, the fewer the number of node rotations.

[0089] Step 230: The node to be synchronized determines the synchronization node for the (i+1)th round based on the block synchronization status of each synchronization node in the i-th round of node rotation, until the N-th round of block synchronization ends.

[0090] In this embodiment of the invention, i is greater than or equal to 0; when i = 0, it is the first round, that is, the synchronization node of the 0th round is the synchronization node of the first round.

[0091] In step 210, the node to be synchronized creates a probe request based on a preset data structure, including the order of node rotation and the unique identifier of the node to be synchronized.

[0092] Specifically, the node to be synchronized generates a probe request based on the probe sequence number, the propagation list, and the communication address of the node to be synchronized; wherein, the probe sequence number is used to indicate the order of node rotation; and the propagation list is used to record the blockchain nodes that have sent the probe request.

[0093] Table 1 illustrates an exemplary detection request according to an embodiment of the present invention; as shown in Table 1 below.

[0094] Table 1

[0095]

[0096] The Index field represents the order of node rotation. Specifically, during each node rotation, a probe request for the current order is initiated to the blockchain nodes to obtain real-time status information of each blockchain node, thus providing a basis for determining the synchronization node. For example, the Index field value of the probe request when determining the first round of synchronization nodes is 0; after synchronizing block data based on the first round of synchronization nodes, the first round of node rotation is performed, and the Index field value of the probe request for the synchronization node in the first round of node rotation is 1. That is, the probe sequence number of the i-th node rotation will increment by 1 based on the probe sequence number of the (i-1)-th node rotation; similarly, the increment number can also be 2, and there is no limitation on the increment number here.

[0097] The SourceAdd field represents the communication address of the node to be synchronized, such as a P2P connection address; its format is IP address + colon + port. This allows each blockchain node in the system to send a response request to the node to be synchronized via this communication address after receiving a probe request; and the SourceAdd and Index fields serve as unique identifiers for the probe request.

[0098] The HistoryAdds field records the blockchain nodes that have sent probe requests. Taking a newly added node in the blockchain system as an example, assuming the probe request is sent by the new node A, forwarded by blockchain node B, and finally reaches blockchain node C; then the HistoryAdds field in the probe request sent by the new node A will store the list {A's network communication address}; the HistoryAdds field in the probe request sent by blockchain node B will store the list {A's network communication address, B's network communication address}; if blockchain node C propagates the probe request, then the HistoryAdds field in the probe request sent by blockchain node C will store the list {A's network communication address, B's network communication address, C's network communication address}, and so on, which will not be elaborated further here.

[0099] When determining the first round of synchronization nodes, after the node to be synchronized creates a probe request, the node to be synchronized propagates through well-known nodes; where well-known nodes are blockchain nodes with direct connection relationships.

[0100] Specifically, the node to be synchronized constructs a probe request and sends the probe request to a well-known node of the node to be synchronized; for any well-known node, the well-known node determines that no probe request is recorded in the first record; the first record is used to record the probe request that has been processed; based on the second record, the well-known node sends a probe request to a well-known node of the well-known node that has not yet propagated the probe request; the second record is used to record the blockchain node that has propagated the probe request; the well-known node updates the first record and the second record and determines the response request.

[0101] Based on the above Figure 1 For example, the node to be synchronized is ordinary node 4. A probe request I (Index = 0; SourceAdd = the communication address of ordinary node 4; HistoryAdds = {the communication address of ordinary node 4}) is constructed for ordinary node 4. Ordinary node 4 obtains the list of well-known nodes. The list of well-known nodes L for ordinary node 4 is created when ordinary node 4 joins the blockchain system. For example, the information of the list of well-known nodes L is: {the P2P communication port of backbone node 1, the P2P communication port of backbone node 4}.

[0102] Ordinary node 4 traverses the list of known nodes and sends probe request a1 to each blockchain node in the list of known nodes L1. That is, probe request a1 is sent to backbone node 1 through the P2P communication port of backbone node 1 and to backbone node 4 through the P2P communication port of backbone node 4.

[0103] To better illustrate the above technical solution, Figure 3 This is a schematic diagram illustrating a probe request propagation as exemplified by an embodiment of the present invention, such as... Figure 3 As shown.

[0104] The node to be synchronized obtains the list of well-known nodes L1 of the nodes to be synchronized; in the list of well-known nodes L1, a certain well-known node is taken out in order and assigned the value of the target node X1 (i.e. the blockchain node to be propagated, such as X1 = the IP address of backbone node 1: the P2P communication port of backbone node 1).

[0105] The node to be synchronized determines whether the target node X1 is empty. If it is, it indicates that the probe request has been propagated to all blockchain nodes in the well-known node list L1, and the process ends; otherwise, a probe request I1 is created, with the node to be synchronized as described above. Figure 1Taking ordinary node 4 as an example, in probe request I1, Index = 0, SourceAdd = IP address of ordinary node 4: P2P communication port of ordinary node 4, and HistoryAdds = {IP address of ordinary node 4: P2P communication port of ordinary node 4}. Finally, probe request I1 is sent to target node X1.

[0106] After receiving a probe request, a well-known node that is to be synchronized records its own communication address in the probe request propagation list, updates the probe request, and constructs a corresponding response request based on the probe request.

[0107] The response request includes: the communication address of the blockchain node, the load index, the construction time of the response request, the maximum block height, and the probe sequence number of the probe request.

[0108] Table 2 illustrates an exemplary response request according to an embodiment of the present invention; as shown in Table 2 below.

[0109] Table 2

[0110]

[0111] The Index field represents the order in which nodes rotate, and corresponds to the Index field value of the probe request.

[0112] The ResponseAdd field represents the communication address of the blockchain node that created the response request. It serves as a unique identifier for issuing the response request, and its format is: IP address + colon + port. Both the Index and ResponseAdd fields serve as unique identifiers for the response request.

[0113] The Busy field represents the load index, which is used to measure the current load of a blockchain node. It is calculated as: Busy = (Cup utilization rate * 100 + Memory utilization rate * 100) / 2.

[0114] The CreateTime field represents the time it took to construct the response request.

[0115] The CurrentHigh field represents the maximum block height in a blockchain node, which is the number of blocks that a blockchain node has confirmed and synchronized to its local ledger.

[0116] In this embodiment of the invention, each blockchain node avoids repeatedly processing the same probe request based on its own first record; as described above Figure 1 For example, suppose a probe request (index probe number i) is sent from the newly added node S1 (ordinary node 4) and received by blockchain nodes S2 (backbone node 1) and S3 (backbone node 3).

[0117] Assume that blockchain node S2 has a relatively small load and can process detection request data relatively quickly; blockchain node S3 has a relatively large load and processes detection request data relatively slowly. That is to say, blockchain node S3 will receive the detection request I1 sent by the newly added node S1 first; after blockchain node S2 finishes processing the detection request I1, blockchain node S3 will receive the detection request I2 sent by blockchain node S2 later.

[0118] When blockchain node S3 processes the detection request I1, it accesses the first record. If it determines that there is no Index field value and SourceAdd field value in the first record that are the same as those in the detection request I1, it processes the detection request I1 and records the detection request I1 in the first record, such as recording it in Map_Index (Map_Index = {<IP address of S1: P2P communication port of S1, i>}); when blockchain node S3 processes the detection request I2, it accesses the first record and determines that there are Index field value and SourceAdd field value in the first record that are the same as those in the detection request I2 (i.e., the detection request I1). Therefore, blockchain node S3 does not process the detection request I2 to avoid duplicate processing of the same detection request.

[0119] In an embodiment of the present invention, after any blockchain node receives a detection request, it records the value of the HistoryAdds field in the detection request in its own second record, updates the detection request according to the second record, and then propagates the updated detection request.

[0120] Furthermore, the blockchain node propagates to its well-known nodes, thereby propagating the detection request to each blockchain node in the blockchain system.

[0121] To better illustrate the above technical solution, based on the above Figure 3 , Figure 4 is a schematic diagram of the propagation of a detection request示例性示出 in an embodiment of the present invention, as Figure 4 shown.

[0122] The well-known node X1 of the node to be synchronized accesses its own second record to determine the blockchain nodes recorded in the second record.

[0123] The well-known node X1 obtains the well-known node list L2 of the well-known node X1, and removes the blockchain nodes recorded in the second record from the well-known node list L2 to obtain the well-known node list L`2.

[0124] Take a certain well-known node in the well-known node list L`2 in order and assign it as the target node X2 (as Figure 1 shown, X1 is backbone node 1, and X2 is backbone node 2).

[0125] The well-known node X1 determines whether the target node X2 is empty. If so, it indicates that the detection request has been propagated to each blockchain node in the well-known node list L`2, and the process ends; otherwise, the detection request I1 is updated to obtain the detection request I2; Index in the detection request I2 = 0, SourceAdd = the IP address of ordinary node 4: the P2P communication port of ordinary node 4, HistoryAdds = {the IP address of ordinary node 4: the P2P communication port of ordinary node 4, the IP address of backbone node 1: the P2P communication port of backbone node 1}. Finally, the detection request I2 is sent to the target node X2; when updating the detection request, the values of the Index field and the SourceAdd field of the detection request are not changed.

[0126] In the embodiments of the present invention, each blockchain node avoids sending detection requests to duplicate blockchain nodes according to its own second record; as above Figure 1 For example, assume that the detection request (Index detection sequence number is i) is sent from the new node S1 (ordinary node 4) and is received by the blockchain node S2 (backbone node 1) and the blockchain node S3 (backbone node 3). Assume that the detection request (Index detection sequence number is i) is sent from the new node S1 (ordinary node 4) and is received by the blockchain node S2 (backbone node 1) and the blockchain node S3 (backbone node 3).

[0127] Assume that the blockchain node S2 has a small load and processes detection request data faster; the blockchain node S3 has a large load and processes detection request data slower. That is to say, the blockchain node S3 will receive the detection request I1 sent by the new node S1 first; after the blockchain node S2 finishes processing the detection request I1, the blockchain node S will receive the detection request I2 sent by the blockchain node S2 later.

[0128] When the blockchain node S3 receives the detection request I1 and / or the detection request I2, it records the value of the HistoryAdds field of the detection request I1 and / or the detection request I2 in its own second record (such as the second record is Map_Adds). At this time, Map_Adds of the blockchain node S3 = {<IP address of S1: P2P communication port of S1, i>, <IP address of S2: P2P communication port of S2, i>}; and updates the detection request to obtain the detection request I3.

[0129] Before propagating probe request I3, blockchain node S3 accesses its own Map_Adds. Since both the newly added node S1 and blockchain node S2 are recorded in blockchain node S3's Map_Adds, blockchain node S3 will not send probe requests with matching SourceAdd and Index field values ​​to the newly added node S1 and blockchain node S2, thus avoiding duplicate propagation of probe requests among the blockchain nodes.

[0130] In this embodiment of the invention, the processing and propagation of probe requests by any blockchain node are executed asynchronously, thereby improving the parallelism of block data synchronization.

[0131] In step 220, the node to be synchronized determines the selected response request based on the load index of each response request, and determines the synchronization node corresponding to the selected response request based on the selected response request.

[0132] Specifically, the node to be synchronized determines the response requests from the response requests fed back by each blockchain node that meet the first set condition of load index and the second set condition of request propagation time; the request propagation time is determined based on the construction time and reception time of the request; the blockchain node corresponding to the response request that meets the first set condition and the second set condition is determined as the first round of synchronization node.

[0133] Furthermore, after receiving the response requests from each blockchain node, the node to be synchronized determines the load index of each response request and records the receiving time corresponding to each response request; the difference between the receiving time corresponding to each response request and the construction time of each response request is used to obtain the request propagation time corresponding to each response request.

[0134] In one feasible approach, the node to be synchronized can preset a waiting time and only record response requests within the preset waiting time. For example, the preset waiting time is named Wait_Time and has an initial value of -1. If no response request is received within one or more preset waiting times, the response request acquisition process ends.

[0135] To give a further example, at the end of the process of obtaining response requests, the set of obtained response requests is named RespList. For any response request R in RespList, the request propagation time T = Rt - Ct of response request R is calculated; where Rt is the time of receiving response request R and Ct is the time of constructing response request R, that is, the time of creating response request R.

[0136] In this embodiment of the invention, the first set condition is that the load index of the response request is not greater than a first threshold; wherein, the first threshold is a value preset based on experience, such as 70%, 80%, etc., and is not limited here.

[0137] The second condition is that the propagation time of the response request is not greater than a second threshold. The second threshold is determined based on the propagation time of the response request that satisfies the first condition. For example, the average propagation time of the response request that satisfies the first condition can be used as the second threshold. Alternatively, it can be based on a preset value, which is not limited here.

[0138] For example, the node to be synchronized receives 10 response requests, namely R1, R2, ..., R9. R1, R2, ..., R9 are treated as the full set of response requests, named RespList_All. First, response requests that meet the first set condition (e.g., load index not greater than 70%) are identified, namely R3, R5, R6, and R7. The average propagation time of response requests R3, R5, R6, and R7 is determined as Ta. Ta*3 / 2 is used as the second threshold. From response requests R3, R5, R6, and R7, response requests that meet the second set condition (request propagation time not greater than Ta*3 / 2) are identified, namely R3, R5, and R7. R3, R5, and R7 are treated as the selected set of response requests, named RespList_Select. The non-selected response requests (R1, R2, R4, R6, R8, R9) are treated as the non-selected set of response requests, named RespList_Delete.

[0139] In other words, response requests with a load index greater than 70% and response requests with a propagation time greater than Ta*3 / 2 are recorded in the unselected response request set.

[0140] In this embodiment of the invention, the node to be synchronized determines the blockchain node corresponding to the selected response request as the first-round synchronization node. The number of node rotations is determined according to the number of each response request and the number of selected response requests. The number of node rotations is inversely proportional to the number of the first-round synchronization nodes. Taking the above example, the number of selected response requests (R3, R5, R7) is 3, and the number of each response request (R1, R2, ..., R9) is 9. Then the number of node rotations is 9 / 3 = 3.

[0141] After obtaining the number of node rotations, the block data that needs to be synchronized from the synchronization node is determined. Specifically, the node to be synchronized determines the number of blocks to be synchronized in each node rotation based on the maximum block height in the response request and the number of node rotations. The i-th round of block data to be synchronized by the i-th round synchronization node is determined based on the number of blocks to be synchronized in each node rotation and the number of synchronization nodes in the i-th round.

[0142] In this embodiment of the invention, the number of blocks to be synchronized in each node rotation = maximum block height / (number of node rotations N+1); based on the above example, assuming the maximum block height in the response request is 4000 and the number of node rotations is 3, then 4000 / 4 = 1000 in each node rotation; that is, in the 0th node rotation, the blocks to be synchronized by the node to be synchronized are blocks with heights 1 to 1000; in the 1st node rotation, the blocks to be synchronized by the node to be synchronized are blocks with heights 1001 to 2000; in the 2nd node rotation, the blocks to be synchronized by the node to be synchronized are blocks with heights 2001 to 3000; and in the 3rd node rotation, the blocks to be synchronized by the node to be synchronized are blocks with heights 3001 to 4000.

[0143] For any node rotation, the block data that the node to be synchronized needs to synchronize is determined from each synchronization node. Specifically, for any synchronization node in the i-th round, the node to be synchronized determines the block data of the i-th round to be synchronized from the synchronization node in the i-th round. For example, in the 0th node rotation, the synchronization nodes include n1 and n2, that is, the synchronization nodes in the first round are n1 and n2. Then, the block data that the node to be synchronized from the synchronization node in the first round is determined to be block height 1 to 500; and the block data that the node to be synchronized from the synchronization node in the first round is determined to be block height 501 to 1000.

[0144] In step 230, after the i-th round of block data synchronization is completed, the synchronization node for the (i+1)-th round is determined, thereby completing the (i+1)-th round of block data synchronization, and so on, until the N-th round of block synchronization is completed.

[0145] Specifically, the node to be synchronized sends an inquiry request to the blockchain node that is not a synchronization node in the i-th round; receives the i-th round block data sent by the i-th round synchronization node and the feedback request carrying state information sent by the i-th round synchronization node when the i-th round block data synchronization ends; and determines the synchronization node for the (i+1)-th round based on each inquiry request and each feedback request.

[0146] Furthermore, the node to be synchronized receives response requests from blockchain nodes that are not synchronization nodes in the i-th round, based on the query request; the node to be synchronized determines response requests and / or feedback requests whose request propagation duration meets the third set condition from the response requests based on the query request and the feedback requests from the synchronization nodes in the i-th round; the load index determines the synchronization node in the (i+1)-th round from the response requests and / or feedback requests that meet the third set condition.

[0147] The third condition is that the request propagation time is not greater than the third threshold, which is the median of the request propagation time of response requests and feedback requests. It can also be a value preset based on experience, and is not limited here.

[0148] For example, after the block data synchronization of the i-th round of node rotation is completed, the i-th round synchronization node will send the i+1-th round response request through the communication address of the node to be synchronized, so as to reflect the current status information in real time. For non-i-th round synchronization nodes, the node to be synchronized sends the query request to each non-i-th round synchronization node through the corresponding communication address, without needing to propagate through well-known nodes, so that each non-i-th round synchronization node returns the i+1-th round feedback request. The data structure of the feedback request is consistent with that of the response request.

[0149] Then, based on the third setting condition, the response request and / or feedback request that satisfy the third setting condition are determined from the response request and feedback request of the (i+1)th round, and the response request and / or feedback request that satisfy the third setting condition are selected as the response request of the (i+1)th round.

[0150] Based on the load index in ascending order, the i+1th round selection response request with the number of synchronization nodes in the first round is determined from each i+1th round selection response request, and the blockchain node corresponding to the i+1th round selection response request with the number of synchronization nodes in the first round is determined as the i+1th round synchronization node.

[0151] In this embodiment of the invention, before synchronizing block data, the load of the blockchain system is first measured by network link quality and node load. Then, node rotation is determined based on the blockchain system load, and the blockchain system load is measured every time a node rotation occurs. Nodes with good network performance and optimal load are selected as synchronization nodes for block data synchronization. This avoids the impact of block data synchronization on the consensus of the blockchain system, improves the efficiency of block data synchronization, and avoids occupying a single blockchain node for an extended period, thus increasing the flexibility of block data synchronization.

[0152] Based on the same technological concept Figure 5 An exemplary schematic diagram of a blockchain node block data synchronization device provided in an embodiment of the present invention is shown. This device can execute the process of a blockchain node block data synchronization method.

[0153] like Figure 5 As shown, the device specifically includes:

[0154] The sending module 510 is used to send a probe request to each blockchain node through a well-known node before the block data is synchronized; the probe request is used to obtain the status information of the blockchain node.

[0155] Processing module 520 is used to determine the first round of synchronization nodes and the number of node rotations N based on the response requests fed back by each blockchain node; wherein, the more synchronization nodes there are in the first round, the fewer the number of node rotations.

[0156] Based on the block synchronization status of each synchronization node in the i-th round of node rotation, determine the synchronization node for the (i+1)-th round, until the N-th round of block synchronization ends; i is greater than or equal to 0.

[0157] Optionally, the sending module 510 is specifically used for:

[0158] A probe request is constructed and sent to a well-known node of the node to be synchronized.

[0159] Optionally, the sending module 510 is specifically used for:

[0160] A probe request is generated based on the probe sequence number, the propagation list, and the communication address of the node to be synchronized; the probe sequence number is used to indicate the order of node rotation; the propagation list is used to record the blockchain nodes that have sent the probe request.

[0161] Optionally, the response request includes: the communication address of the blockchain node, the load index, the construction time of the response request, the maximum block height, and the probe sequence number of the probe request;

[0162] The processing module 520 is specifically used for:

[0163] From the response requests fed back by each blockchain node, response requests that meet the first set condition in terms of load index and the second set condition in terms of request propagation time are identified; the request propagation time is determined based on the request construction time and the request reception time.

[0164] The blockchain nodes corresponding to the response requests that meet the first and second conditions are identified as the first-round synchronization nodes.

[0165] Optionally, the processing module 520 is specifically used for:

[0166] Send query requests to blockchain nodes that are not synchronization nodes in round i;

[0167] For any i-th round synchronization node, determine the i-th round block data to be synchronized by the i-th round synchronization node, and receive the i-th round block data sent by the i-th round synchronization node and the feedback request carrying status information sent by the i-th round synchronization node when the i-th round block data synchronization ends.

[0168] Based on each query request and each feedback request, determine the synchronization node for the (i+1)th round.

[0169] Optionally, the processing module 520 is specifically used for:

[0170] The number of blocks to be synchronized in each node rotation is determined based on the maximum block height and the number of node rotations in the response request; the number of node rotations is inversely proportional to the number of nodes synchronized in the first round.

[0171] The number of blocks to be synchronized in each node rotation and the number of synchronization nodes in the i-th round are used to determine the blocks to be synchronized in the i-th round.

[0172] Optionally, the processing module 520 is specifically used for:

[0173] Receive response requests from blockchain nodes that are not synchronization nodes in round i, based on the query request;

[0174] From the response requests fed back according to the inquiry request and the feedback requests of the i-th round of synchronization nodes, determine the response requests and / or feedback requests whose request propagation duration satisfies the third set condition;

[0175] The (i+1)th round synchronization node is determined from the response requests and / or feedback requests that meet the third set condition based on the load index.

[0176] Based on the same technical concept, embodiments of the present invention also provide a computer device, including:

[0177] Memory, used to store program instructions;

[0178] The processor is used to call the program instructions stored in the memory and execute the block data synchronization of the aforementioned blockchain nodes according to the obtained program.

[0179] Based on the same technical concept, embodiments of the present invention also provide a computer-readable storage medium storing computer-executable instructions for causing a computer to perform block data synchronization of the aforementioned blockchain node.

[0180] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application 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, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0181] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should 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. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

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

[0183] 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 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0184] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for synchronizing block data of a blockchain node, characterized in that, The method comprises the following steps: Before the block data synchronization, the to-be-synchronized node sends a detection request to each blockchain node through a well-known node; The detection request is used to obtain the state information of the blockchain node; The to-be-synchronized node determines the first round of synchronization nodes and the number of node rotation N based on the response request fed back by each blockchain node; the more the number of first round of synchronization nodes is, the less the number of node rotation is; The to-be-synchronized node determines the (i+1)th round of synchronization nodes based on the block synchronization situation of each ith round of synchronization node in the ith round of node rotation until the Nth round of block synchronization ends; i is greater than or equal to 0; The response request comprises the communication address of the blockchain node, the load index, the construction time of the response request, the maximum block height, and the detection serial number of the detection request; the to-be-synchronized node determines the first round of synchronization nodes based on the response request fed back by each blockchain node, specifically comprising: the to-be-synchronized node determines the response request whose load index meets the first set condition and whose request propagation time meets the second set condition from the response request fed back by each blockchain node; the request propagation time is determined according to the construction time of the request and the receiving time of the request; and the to-be-synchronized node determines the blockchain node corresponding to the response request meeting the first set condition and the second set condition as the first round of synchronization nodes; The to-be-synchronized node determines the (i+1)th round of synchronization nodes based on the block synchronization situation of each ith round of synchronization node in the ith round of node rotation, specifically comprising: the to-be-synchronized node sends an inquiry request to the blockchain node which is not the ith round of synchronization node; for any ith round of synchronization node, the to-be-synchronized node determines the ith round of block data synchronized by the ith round of synchronization node, and receives the ith round of block data sent by the ith round of synchronization node and the feedback request carrying the state information sent by the ith round of synchronization node at the end of the ith round of block data synchronization; the to-be-synchronized node determines the (i+1)th round of synchronization nodes according to each inquiry request and each feedback request.

2. The method of claim 1, wherein, The to-be-synchronized node sends a detection request to each blockchain node through a well-known node, comprising: The to-be-synchronized node constructs a detection request and sends the detection request to the well-known node of the to-be-synchronized node; For any well-known node, the well-known node determines that the detection request is not recorded in the first record; the first record is used to record the processed detection request; the well-known node sends the detection request to the well-known node of the well-known node which has not propagated the detection request based on the second record; the second record is used to record the blockchain node which has propagated the detection request; the well-known node updates the first record and the second record and determines a response request.

3. The method of claim 2, wherein, The to-be-synchronized node constructs a detection request, comprising: The to-be-synchronized node generates a detection request according to a detection serial number, a propagation list and the communication address of the to-be-synchronized node; the detection serial number is used to indicate the order of node rotation; the propagation list is used to record the blockchain node which has sent the detection request.

4. The method of claim 1, wherein, The to-be-synchronized node determines the ith round of block data synchronized by the ith round of synchronization node, comprising: The to-be-synchronized node determines the number of to-be-synchronized block data in each node rotation according to the maximum block height and the number of node rotations in the response request; the number of node rotations is inversely proportional to the number of first round of synchronization nodes; The to-be-synchronized node determines the i-th round of block data synchronized by the i-th round of synchronization nodes according to the number of to-be-synchronized block data in each node rotation and the number of i-th round of synchronization nodes.

5. The method of claim 1, wherein, The to-be-synchronized node determines the i+1-th round of synchronization nodes according to each inquiry request and each feedback request, including: The to-be-synchronized node receives a response request fed back by a blockchain node that is not a i-th round of synchronization node according to the inquiry request; The to-be-synchronized node determines a response request and / or a feedback request that satisfies a third set condition in terms of request propagation duration from the response request fed back according to the inquiry request and the feedback request of the i-th round of synchronization nodes; The to-be-synchronized node determines the i+1-th round of synchronization nodes from the response request and / or the feedback request that satisfies the third set condition according to the load index. 6.A block data synchronization apparatus of a blockchain node, characterized in that, Including: The sending module is configured to send a detection request to each blockchain node through a well-known node before block data synchronization; The detection request is used to obtain state information of the blockchain node; The processing module is configured to determine the first round of synchronization nodes and the number of node rotations N based on the response request fed back by each blockchain node; the more the number of first round of synchronization nodes is, the less the number of node rotations is; Based on the block synchronization of each i-th round of synchronization nodes in the i-th round of node rotation, the i+1-th round of synchronization nodes are determined until the N-th round of block synchronization ends; i is greater than or equal to 0; The response request includes: the communication address of the blockchain node, the load index, the construction time of the response request, the maximum block height, and the detection serial number of the detection request; the processing module is specifically configured to: determine the response request that satisfies a first set condition in terms of load index and a second set condition in terms of request propagation duration from the response request fed back by each blockchain node; the request propagation duration is determined according to the construction time of the request and the receiving time of the request; and determine the blockchain node corresponding to the response request that satisfies the first set condition and the second set condition as the first round of synchronization nodes; and send an inquiry request to the blockchain node that is not the i-th round of synchronization node; for any i-th round of synchronization node, determine the i-th round of block data synchronized by the i-th round of synchronization node, and receive the i-th round of block data sent by the i-th round of synchronization node and the feedback request carrying state information sent by the i-th round of synchronization node at the end of the i-th round of block data synchronization; determine the i+1-th round of synchronization nodes according to each inquiry request and each feedback request.

7. A computer device, comprising: Including: The memory is configured to store program instructions; The processor is configured to invoke the program instructions stored in the memory to execute the method of any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer executable instructions for causing a computer to execute the method of any one of claims 1 to 5.

Images