Block synchronization method, block chain system, device and storage medium

Abstract

To disclose a block synchronization method, a blockchain system, a device, and a storage medium.SOLUTION: A blockchain system includes a plurality of VPs and m NVP clusters. Each NVP cluster includes a first NVP and at least one second NVP. The first NVP is an NVP for communicating with a corresponding VP. Each of m VPs of the plurality of VPs sends a first message carrying a block to the first NVP in a corresponding NVP cluster, and upon receiving the first message, stores the block carried by the first message in a blockchain and sends the first message to neighboring NVPs. The VP can synchronize this block by each NVP by only sending the first message carrying the block to the first NVP, thereby reducing a load on the VP and improving block consensus efficiency.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present application relates to the field of blockchain technology, and in particular to a block synchronization method, a blockchain system, a device and a storage medium. [Background technology]

[0002] In some scenarios, a blockchain system includes multiple validating peers (VPs) and multiple non-validating peers (NVPs). VPs need to participate in the block consensus process, NVPs do not need to participate in the block consensus process, and NVPs need to synchronize blocks that have been agreed upon by VPs to maintain data integrity in the nodes.

[0003] In the related art, each of the multiple VPs may be directly connected to multiple NVPs for communication. After completing a consensus on a block, the multiple VPs add the block to the blockchain. Then, any one of the VPs can directly transmit the block to the multiple NVPs connected to the VP for communication, so as to achieve synchronization of the block among the multiple NVPs.

[0004] However, in the above scheme, as the number of blocks requiring consensus by the VP increases and the number of NVPs connected to the VP continues to increase, the VP becomes very busy, which increases the load on the VP and affects the efficiency of block consensus. Summary of the Invention

[0005] The present application provides a block synchronization method, a block chain system, a device and a storage medium, which can reduce the load of consensus nodes in a block chain system and improve the efficiency of block consensus. The technical proposal is as follows:

[0006] According to a first aspect, there is provided a block synchronization method applied to a blockchain system, the blockchain system including a plurality of consensus node VPs and m non-consensus node NVP clusters, the m VPs among the plurality of VPs correspond one-to-one with the m NVP clusters, each of the m NVP clusters includes a first NVP and at least one second NVP, the first NVP is an NVP that communicates with a corresponding VP, and has a network path between the first NVP and each of the at least one second NVP, the m being a positive integer, and the method includes:

[0007] Each time the multiple VPs complete consensus on a block and add the block to a blockchain, each of the m VPs sends a first message carrying the block to the first NVP in a corresponding NVP cluster; When each NVP in each of the m NVP clusters receives the first message, it stores the block carried in the first message in a blockchain and sends the first message to adjacent NVPs in the same NVP cluster.

[0008] According to a second aspect, a blockchain system is provided, the blockchain system including a plurality of consensus node VPs and m non-consensus node NVP clusters, the m VPs of the plurality of VPs correspond one-to-one to the m NVP clusters, each of the m NVP clusters includes a first NVP and at least one second NVP, the first NVP is an NVP that communicates with a corresponding VP, and has a network path between the first NVP and each of the at least one second NVP, the m being a positive integer; Each of the m VPs sends a first message carrying a block to the first NVP in a corresponding NVP cluster each time the VPs complete consensus on a block and add the block to a blockchain; When the first message is received, each NVP in each of the m NVP clusters stores the block carried in the first message in a blockchain and sends the first message to adjacent NVPs in the same NVP cluster.

[0009] According to a third aspect, there is provided a computer device including a memory, a processor, and a computer program stored in the memory and executable by the processor, the computer program being executed by the processor to realise the above-mentioned block synchronization method.

[0010] According to a fourth aspect, there is provided a computer readable storage medium having stored thereon a computer program which, when executed by a processor, realises the block synchronization method as set forth above.

[0011] According to a fifth aspect, there is provided a computer program product comprising instructions, which when run on a computer, cause the computer to perform the steps of the block synchronization method. [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 is a schematic structural diagram of a blockchain system according to an embodiment of the present application. [Diagram 2] 2 is a flow chart of a block synchronization method according to an embodiment of the present application; [Diagram 3] FIG. 1 is a schematic diagram of a blockchain according to an embodiment of the present application. [Figure 4] FIG. 2 is a schematic diagram of another blockchain according to an embodiment of the present application. [Diagram 5]FIG. 2 is a schematic structural diagram of a computing device according to an embodiment of the present application; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] In order to clarify the purpose, technical solution and advantages of the present application, the embodiments of the present application will be described in more detail with reference to the drawings. It should be understood that "plurality" referred to in the present application refers to two or more. In the description of the present application, unless otherwise specified, " / " represents or, for example, A / B can represent A or B, and "and / or" in the text is merely for describing the related relationship of related objects and represents that three relationships may exist, for example, A and / or B can represent three cases: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in order to clearly describe the technical solution of the present application, the letters "first", "second", etc. are used to distinguish between the same items or similar items whose functions and actions are basically the same. Those skilled in the art can understand that the letters "first", "second", etc. do not limit the quantity and execution order, and the letters "first", "second", etc. do not necessarily limit different things.

[0014] The block synchronization method according to an embodiment of the present application can be applied to an application scenario in which blocks stored in a VP of a blockchain system are synchronized with each NVP in an NVP cluster.

[0015] For example, in a consortium blockchain scenario, the consortium blockchain includes multiple prefecture agency nodes and city-level nodes belonging to some prefecture agencies. Multiple prefecture agency nodes (i.e., VPs) can participate in the block consensus process, and city-level nodes (i.e., NVPs) belonging to one prefecture agency do not need to participate in the block consensus process.

[0016] FIG. 1 is a schematic structural diagram of a blockchain system according to an embodiment of the present application.

[0017] Referring to FIG. 1, the blockchain system 100 is a system for performing data sharing between nodes, where the blockchain system 100 includes a plurality of VPs 101 and m NVP clusters 102, each of which includes a plurality of NVPs 103, where m is a positive integer.

[0018] The multiple VPs 101 are nodes that need to participate in the block consensus process in the blockchain system. Each NVP 103 in each of the m NVP clusters 102 is a node that does not need to participate in the block consensus process.

[0019] During normal operation, multiple VPs 101 can receive input information and maintain shared data in the blockchain system 100 based on the received input information. There may be information connections between multiple VPs 101, and information transmission may be performed between multiple VPs 101 via the information connections. For example, when any one VP 101 in the blockchain system 100 receives input information sent from a client, the other VPs 101 in the blockchain system 100 obtain the input information based on a consensus algorithm and store the input information as data in the shared data.

[0020] In addition, m VPs 101 among the multiple VPs 101 correspond one-to-one to m NVP clusters 102, and for any one VP 101 among the m VPs 101, this VP 101 can communicate with a corresponding NVP cluster 102 among the m NVP clusters 102. The multiple VPs 101 in the blockchain system 100 may communicate with the corresponding NVP cluster 102 after storing the input information as data in the shared data, i.e., send the input information to the corresponding NVP cluster 102 so that the multiple NVPs 103 in the corresponding NVP cluster 102 store the input information as data in the shared data.

[0021] Here, VP101 in the blockchain system 100 communicates with one NVP103 in the corresponding NVP cluster 102, i.e., VP101 in the blockchain system 100 sends a message to only one NVP103 in the corresponding NVP cluster 102, thereby reducing the load on multiple VP101 in the blockchain system 100 and improving the performance of multiple VP101 in the blockchain system 100.

[0022] To ensure the consistency of shared data stored in each node in the blockchain system 100, multiple NVPs 103 in each NVP cluster 102 need to synchronize the input data stored in the corresponding VPs 101.

[0023] The multiple NVPs 103 in each NVP cluster 102 include a first NVP 103 and at least one second NVP 103, and the first NVP 103 is an NVP 103 that communicates with a corresponding VP 101 in the NVP cluster 102 in which it is located, i.e., one VP 101 in the blockchain system 100 sends the input information to the first NVP 103 in the corresponding NVP cluster 102. Since new NVPs 103 can be added to each NVP cluster 102 at will, which does not affect the ability of the VP 101 in the blockchain system 100 to send messages to the corresponding NVP cluster 102, the scalability of each NVP cluster 102 in the blockchain system 100 is relatively high.

[0024] In addition, there is a network path between the first NVP 103 and each of at least one second NVP 103. A network path is used to indicate a data transmission channel between multiple NVPs 103, and the first NVP 103 may transmit data to at least one second NVP 103 through this network path. There may be multiple NVPs 103 in the network path between two NVPs 103, in which case the two NVPs 103 can communicate indirectly. There may not be other NVPs 103 in the network path between two NVPs 103, i.e., the two NVPs 103 can communicate directly, i.e., the two NVPs 103 are adjacent NVPs 103.

[0025] After a first NVP 103 of the multiple NVPs 103 receives the input information, another second NVP 103 of the multiple NVPs 103 also receives the input information by transmitting information to the input information via a network path. In this way, each of the multiple NVPs 103 stores the input information as data in the shared data so that the data stored in all nodes in the blockchain system 100 matches. That is, each node in the blockchain system 100 stores the same blockchain.

[0026] The blockchain system 100 has computer technologies such as distributed data storage, point-to-point transmission, consensus mechanism, encryption algorithm, etc. The blockchain system 100 is a distributed shared ledger and database, and has characteristics such as decentralization, immutability, whole-process retention, traceability, collective maintenance, public transparency, etc. These characteristics ensure the sharing and openness, actual integrity and safety reliability of the blockchain.

[0027] Multiple VPs 101 and m NVP clusters 102 in the blockchain system 100 can execute the block synchronization method described in the example of FIG. 2 below to synchronize blocks (i.e., the shared data described above) stored in the VPs 101 of the blockchain system 100 to each NVP 103 in the NVP cluster 102.

[0028] 2 is a flowchart of a block synchronization method according to an embodiment of the present application. This method can be applied to a blockchain system. Referring to FIG. 2, the method includes the following steps:

[0029] Step 201: After multiple VPs complete consensus on a block and add the block to the blockchain, each of m VPs among the multiple VPs sends a first message carrying the block to a first NVP in a corresponding NVP cluster.

[0030] The first NVP is an NVP that communicates with a corresponding VP in the same NVP cluster, and there is only one first NVP in the same NVP cluster, i.e., each of the m VPs among the multiple VPs sends a first message carrying this block to one NVP in the corresponding NVP cluster.

[0031] The first message carries this block, and the first message is used to instruct the NVP that receives the first message to store the block carried by the first message. Preferably, the first message may be a GOSSIP (Infectious Disease Protocol) message, and of course, the first message may be other types of messages, and the embodiment of the present application is not limited thereto.

[0032] Since each NVP in each of the m NVP clusters in the blockchain system according to an embodiment of the present application does not need to participate in the block consensus process, each of the m VPs can send a first message conveying this block to the corresponding NVP cluster so that the corresponding NVP cluster obtains and stores this block, thereby ensuring the integrity of the blockchain stored in each node in the blockchain system.

[0033] In this case, the first NVP in the NVP cluster corresponding to each of the m VPs can receive the first message carrying the block, and the first NVP in the corresponding NVP cluster can store the block. Furthermore, each of the m VPs only needs to send the first message to the first NVP in the corresponding NVP cluster, and does not need to send the first message to each NVP in the corresponding NVP cluster. This reduces the load on each VP.

[0034] In addition, before each of the m VPs sends a first message carrying a block to a first NVP in the corresponding NVP cluster, any one of the m NVP clusters may further select a primary NVP.

[0035] The primary NVP of an NVP cluster is used to communicate with the corresponding VP, i.e. the primary NVP is the first NVP, the other NVPs in an NVP cluster are secondary NVPs, and the secondary NVPs in an NVP cluster are second NVPs, i.e. an NVP cluster has one primary NVP and at least one secondary NVP.

[0036] Furthermore, after any one of the m NVP clusters selects a primary NVP (i.e., a first NVP), the first NVP in the NVP cluster may send a first notification message to the corresponding VP.

[0037] The first notification message is used to indicate that the NVP sending the first notification message is elected as the primary NVP of the NVP cluster in which it is located. In this case, the NVP sending the first notification message is an NVP that communicates with the corresponding VP in the NVP cluster in which it is located, and then the corresponding VP can send the first message to the NVP elected as the primary NVP in this NVP cluster (i.e., the first NVP) after adding the block to the blockchain, thereby ensuring that the corresponding VP can send the first message only to the first NVP in this NVP cluster.

[0038] Preferably, any one of the m NVP clusters may select one primary NVP in a dynamic selection manner.

[0039] In this way, if the primary NVP selected in this NVP cluster goes down, a single primary NVP is re-selected, ensuring that there is always one first NVP communicating with the VP corresponding to an NVP cluster, thereby improving the liveliness of this NVP cluster. Specifically, the operation in which any one of the m NVP clusters selects one primary NVP using the dynamic selection method can be realized by the following steps (1) to (4).

[0040] (1) After an NVP cluster is globally started, each of at least one NVP in the NVP cluster broadcasts a second message carrying its node identifier to other NVPs in the same NVP cluster.

[0041] The global startup of an NVP cluster refers to the startup of each of all NVPs in the NVP cluster, that is, each NVP begins to enter an operational state.

[0042] The at least one NVP is an NVP in this NVP cluster that is claimed as the primary NVP after the entire NVP cluster starts.

[0043] The node identifier of an NVP is used to uniquely identify the NVP, and may be, for example, the number of the NVP, an IP (Internet Protocol) address, or the like.

[0044] The second message carries a node identifier, and the second message is used to indicate that the NVP identified by the node identifier carried in the second message is requested as the primary NVP. Preferably, the second message may be a GOSSIP message, and of course, the second message may be other types of messages, and the embodiment of the present application is not limited thereto.

[0045] After one NVP cluster is started overall, there may be no first NVP in this NVP cluster, i.e., if there is no NVP in this NVP cluster that communicates with the corresponding VP, the corresponding VP does not know which NVP in this NVP cluster to send the first message carrying the block to after adding the block to the blockchain. Therefore, after this NVP cluster is started overall, it is necessary to first select one primary NVP, i.e., obtain the first NVP in this NVP cluster. In this case, since each NVP in the NVP cluster has the right to be applied as the primary NVP, if any NVP in this NVP cluster wants to be applied as the primary NVP, it can broadcast a second message to this NVP cluster to apply as the primary NVP in this NVP cluster.

[0046] (2) Any one of the at least one NVPs receives a second message broadcast by another NVP at a first predetermined time after the second message is broadcast.

[0047] The first predetermined time may be preset, and the first predetermined time may be set large to ensure that any one NVP can receive the second message carrying its node identifier broadcast by each of the other NVPs, for example, the first predetermined time may be set to 5 minutes.

[0048] In this case, any one of the at least one NVPs can receive the second message broadcast by another NVP after broadcasting the second message, thereby knowing which NVP in the NVP cluster is applying to be the primary NVP.

[0049] (3) Any one of the at least one NVPs may determine whether it has been selected as the primary NVP by comparing its own node identifier with a node identifier carried in a second message broadcast by another NVP received at a first predetermined time.

[0050] Specifically, any one of the at least one NVP may determine whether it has been elected as the primary NVP by comparing its own node identifier with a node identifier carried by a second message broadcast to other NVPs received within a first predetermined time period in accordance with a predetermined selection condition.

[0051] The predetermined selection condition is a condition for determining whether or not an NVP can be selected as the primary NVP. The predetermined selection condition may be set in advance, and the predetermined selection condition may be set by an engineer according to usage needs. For example, the predetermined selection condition may be that an NVP having a smallest node identifier in an NVP cluster is selected as the primary NVP. In another example, the predetermined selection condition may be that an NVP having a largest node identifier in an NVP cluster is selected as the primary NVP. Of course, the predetermined selection condition may be set as other conditions for determining whether or not an NVP can be selected as the primary NVP, and the embodiment of the present application is not limited thereto.

[0052] For example, the predetermined selection condition is that an NVP with the smallest node identifier in an NVP cluster is selected as the primary NVP. The node identifier of one NVP is 04, and the NVP receives a second message broadcast by three NVPs at a first predetermined time, and the node identifier carried in the second message broadcast by the first NVP of the three NVPs is 05, the node identifier carried in the second message broadcast by the second NVP of the three NVPs is 06, and the node identifier carried in the second message broadcast by the third NVP of the three NVPs is 07. The NVP then compares its own node identifier (04) with the node identifiers (05, 06, 07) contained in the received second message broadcast by the three NVPs to determine whether its own node identifier satisfies the predetermined selection condition. Because its node identifier is less than any of the node identifiers carried in the second message broadcast by the three NVPs, this NVP determines that it can be elected as the primary NVP.

[0053] (4) If any one of the at least one NVPs determines that it has been selected as the primary NVP, a second notification message is sent to other NVPs in the same NVP cluster at second predetermined time intervals, and if it determines that it cannot be selected as the primary NVP, the operation of applying to be the primary NVP is terminated.

[0054] The second predetermined time may be set in advance, and the second predetermined time may be set smaller to ensure that the second notification message can be continuously sent to other NVPs in the same NVP cluster, so that the other NVPs in the same NVP cluster always know which NVP is the primary NVP in the NVP cluster.

[0055] The second notification message is used to indicate that the NVP sending the second notification message has been elected as the primary NVP of the NVP cluster in which it is located, and the NVP receiving the second notification message is used to indicate that it is the secondary NVP of the NVP cluster in which it is located. In this case, if any one of the at least one NVPs determines that it has been selected as the primary NVP, it sends a second notification message to another NVP in the same NVP cluster to notify the other NVP in the same NVP cluster that it has been selected as the primary NVP, and at this time, the other NVP in the same NVP cluster is a secondary NVP. If it determines that it cannot be selected as the primary NVP, it terminates the operation of applying to be the primary NVP, i.e., it does not broadcast the second message, and logs out of the current selection of the primary NVP. In this way, after an entire NVP cluster is started, the primary NVP of this NVP cluster is selected for the first time.

[0056] Preferably, the second notification message may carry its own (ie, the primary NVP) node identifier. In this case, when any one of the secondary NVPs in the NVP cluster receives the second notification message, it compares its own node identifier with the node identifier carried by the second notification message to determine whether the NVP identified by the node identifier carried by the second notification message can continue to be selected as the primary NVP; if the secondary NVP determines that the NVP identified by the node identifier carried by the second notification message cannot continue to be selected as the primary NVP, it sends a request message carrying its own node identifier to the current primary NVP (i.e., the NVP sending the second notification message); after the current primary NVP receives the request message sent by the secondary NVP, it compares its own node identifier with the node identifier carried by the request message to determine whether it can continue to be selected as the primary NVP; if the current primary NVP determines that it cannot continue to be selected as the primary NVP, it sends a decision message to the secondary NVP; and if the secondary NVP receives the decision message and determines that it will be selected as the primary NVP, it broadcasts the second notification message to another NVP in the NVP cluster.

[0057] This request message is used to indicate that the secondary NVP sending the request message applies to be the primary NVP. The request message carries the node identifier of the secondary NVP sending the request message.

[0058] The decision message indicates that the current primary NVP has decided that it cannot continue to be elected as the primary NVP, and indicates that the secondary NVP sending the request message can be elected as the primary NVP.

[0059] When a secondary NVP receives the second notification message and compares its own node identifier with the node identifier carried in the second notification message, it can compare its own node identifier with the node identifier carried in the second notification message according to a predetermined selection condition, so as to determine whether the NVP identified by the node identifier carried in the second notification message can continue to be selected as the primary NVP. Specifically, after the secondary NVP compares its own node identifier with the node identifier carried in the second notification message, if it determines that the node identifier carried in the second notification message does not satisfy the predetermined selection condition, it can determine that the NVP identified by the node identifier carried in the second notification message cannot continue to be selected as the primary NVP, and if it determines that the node identifier of the secondary NVP does not satisfy the predetermined selection condition, it can determine that the NVP identified by the node identifier carried in the second notification message can continue to be selected as the primary NVP.

[0060] Similarly, after receiving the request message sent from this secondary NVP, the current primary NVP may compare its own node identifier with the node identifier carried in the request message based on a predetermined selection condition to determine whether it can continue to be selected as the primary NVP. Specifically, after comparing its own node identifier with the node identifier included in the request message, if the current primary NVP determines that the node identifier carried in the request message does not satisfy the predetermined selection condition, it can determine that it can continue to be selected as the primary NVP, and if it determines that its own node identifier does not satisfy the predetermined selection condition, it can determine that it cannot continue to be selected as the primary NVP.

[0061] In this case, the NVP cluster can select a primary NVP that meets the predetermined selection criteria, that is, an NVP that is more qualified to be selected as the primary NVP.

[0062] For example, the node identifier carried in the second notification message is 03, and the node identifier of one secondary NVP is 02. After receiving the second notification message, one secondary NVP in the NVP cluster compares its own node identifier (02) with the node identifier (03) carried in the second notification message, and if it determines that the NVP identified by the node identifier (03) carried in the second notification message (i.e., the current primary NVP) cannot continue to be selected as the primary NVP, this NVP sends a request message carrying its own node identifier (02) to the current primary NVP. After receiving the request message, the current primary NVP compares its own node identifier (03) with the node identifier (02) carried in the request message and determines that it cannot continue to be selected as the primary NVP. Then, the current primary NVP sends a decision message to this NVP to determine that it cannot continue to be selected as the primary NVP. After receiving the decision message, if the NVP decides that it has been selected as the primary NVP, it broadcasts a second notification message to the other NVPs in the NVP cluster to notify the other NVPs in the NVP cluster that it has been selected as the primary NVP.

[0063] Furthermore, if the primary NVP in an NVP cluster is down, the NVP cluster must reselect a new primary NVP.

[0064] If the primary NVP of this NVP cluster is down, the primary NVP cannot communicate with the corresponding VP, i.e., the NVP cluster in which it is located cannot communicate with the corresponding VP, and the primary NVP cannot communicate with other NVPs in the NVP cluster in which it is located. Therefore, this NVP cluster needs to reselect a new primary NVP so as to maintain the communication connection between this NVP cluster and the corresponding VP, i.e., this NVP cluster guarantees to receive messages sent by the corresponding VP, and guarantees the communication connection between the primary NVP and the secondary NVP in the NVP cluster.

[0065] Specifically, when the main NVP in one NVP cluster is in a down state, the operation of this NVP cluster to reselect a new main NVP can be realized by the following steps (1) to (5).

[0066] (1) If the second notification message is not received within a third predetermined time, any one of the secondary NVPs in the NVP cluster broadcasts a second message to other NVPs in the same NVP cluster.

[0067] The third predetermined time may be preset, and the third predetermined time is greater than or equal to the second predetermined time, so that the secondary NVP has sufficient time to receive the second notification message sent by the primary NVP of the NVP cluster.

[0068] In this case, if the secondary NVP does not receive the second notification message at the third predetermined time, it indicates that the primary NVP of the NVP cluster did not send the second notification message at the second predetermined time, and it can determine that the primary NVP of the NVP cluster is likely down. In order to maintain the communication connection between the NVP cluster and the corresponding VP, the secondary NVP can broadcast a second message to another NVP in the same NVP cluster to apply as the primary NVP of the NVP cluster.

[0069] (2) When any NVP in this NVP cluster receives the second message broadcast by this secondary NVP, after comparing its own node identifier with the node identifier carried in the second message broadcast by this secondary NVP, if it determines that this secondary NVP cannot be elected as the primary NVP, it broadcasts the second message to another NVP in the same NVP cluster.

[0070] After receiving the second message broadcast by the secondary NVP, an NVP can compare its own node identifier with the node identifier carried in the second message according to a predetermined selection condition, and determine that it or the secondary NVP cannot be selected as the primary NVP. Specifically, after comparing its own node identifier with the node identifier carried in the second message, if it is determined that the node identifier carried in the second message does not satisfy the predetermined selection condition, it can determine that the secondary NVP cannot be selected as the primary NVP, and if it is determined that its own node identifier does not satisfy the predetermined selection condition, it can determine that it cannot be selected as the primary NVP.

[0071] After the secondary NVP broadcasts the second message, any one of the other NVPs in the NVP cluster receives the second message broadcast by the NVP. Then, the NVP can compare its own node identifier with the node identifier included in the second message broadcast by the secondary NVP according to a predetermined selection condition to determine that it or the secondary NVP cannot be selected as the primary NVP. If the secondary NVP determines that it cannot be selected as the primary NVP, the NVP can broadcast the second message to other NVPs in the same NVP cluster to apply for the primary NVP. If the NVP determines that it cannot be selected as the primary NVP, the NVP can terminate the operation of broadcasting the second message, i.e., log out of the selection of a new primary NVP in the NVP cluster.

[0072] (3) Any one NVP in the NVP cluster receives a second message broadcast by another NVP at a first predetermined time after the second message was most recently broadcast.

[0073] Any one NVP in this NVP cluster can receive the second message broadcast by another NVP after the most recent broadcast of the second message and know which NVP in this NVP cluster has applied to be the primary NVP.

[0074] (4) Any one of the NVPs in the NVP cluster compares its own node identifier with the node identifiers carried in the second messages broadcast by other NVPs received at the first predetermined time to determine whether it has been elected as the primary NVP.

[0075] Specifically, the operation of step (4) is similar to the operation of any one of the at least one NVPs described above comparing its own node identifier with a node identifier carried in a second message broadcast by another NVP received at a first predetermined time to determine whether it has been elected as a primary NVP, and detailed description thereof is omitted here.

[0076] (5) When any one NVP in this NVP cluster determines that it has been selected as the primary NVP, it sends a second notification message to other NVPs in the same NVP cluster at second predetermined time intervals.

[0077] In this case, when any one NVP in this NVP cluster decides to select itself as the primary NVP, a second notification message is sent to other NVPs in the same NVP cluster to notify them that it has been selected as the new primary NVP, and the other NVPs in the same NVP cluster are now secondary NVPs. In this way, when the primary NVP in one NVP cluster goes down, a new primary NVP is selected.

[0078] Step 202: When each NVP in each of the m NVP clusters receives the first message, it stores the block carried in the first message in the blockchain and sends the first message to adjacent NVPs in the same NVP cluster.

[0079] Each NVP may store the block carried in the first message in the blockchain.

[0080] The first NVP in each of the m NVP clusters may first receive the first message sent by the corresponding VP, and the first NVP may store the block carried in the first message in its own blockchain and send the first message to the adjacent NVP in the same NVP cluster. Then, any one of the NVPs adjacent to the first NVP in the same NVP cluster may store the block carried in the first message in its own blockchain and send the first message to the adjacent NVP in the same NVP cluster after receiving the first message sent by the first NVP. In the same manner, each NVP in the same NVP cluster stores the block carried in the first message in its own blockchain and sends the first message to the adjacent NVP in the same NVP cluster.

[0081] Preferably, step 202 may be realized by the GOSSIP protocol, that is, after the first NVP in each NVP cluster receives the first message, the first NVP broadcasts the first message to each NVP in the NVP cluster by using the GOSSIP protocol, so that each NVP in the NVP cluster stores the block carried in the first message in its own block chain.

[0082] In this case, the first message is propagated by the GOSSIP protocol, and each NVP in each NVP cluster stores the block carried in the first message in its own blockchain, thereby synchronizing the block added to the corresponding VP to each NVP in each NVP cluster.

[0083] Preferably, each NVP in each of the m NVP clusters has a node list, the node list including node identifiers of adjacent NVPs in the same NVP cluster. The node list within an NVP is used to indicate the NVPs adjacent to this NVP. For example, the node identifier of an NVP is 02, and the node identifiers of the NVPs adjacent to this NVP are 01, 03, and 04, as can be seen from the node list within this NVP shown in Table 1 below.

[0084] [Table 1]

[0085] In the embodiment of the present application, the node list of one NVP is illustratively described using Table 1 as an example, and Table 1 does not limit the embodiment of the present application.

[0086] In this case, the operation of step 202 can be realized by the following steps (1) to (3).

[0087] (1) When any NVP in each of the m NVP clusters receives the first message, the block carried in the first message is stored in its own blockchain.

[0088] In this case, after receiving the first message, an NVP first stores the block carried in the first message in its own blockchain, i.e., it synchronizes the block added to the corresponding VP with this NVP.

[0089] Preferably, the first message generated by the VP may further carry the message sequence number of the first message. In this case, when any one NVP in each of the m NVP clusters receives the first message, it first determines whether the message sequence number of the most recently received first message is greater than the message sequence number of the previously received historical first message, and if the message sequence number of the most recently received first message is greater than the message sequence number of the previously received historical first message, it may store the block carried by the first message in the blockchain, and if the message sequence number of the most recently received first message is less than or equal to the message sequence number of the previously received historical first message, it may discard the most recently received first message.

[0090] The message sequence number of the first message is used to uniquely identify the first message, and the message sequence number of the first message generated by the VP is incremented.

[0091] The historical first message is the first message received by the NVP prior to the most recently received first message.

[0092] If the message sequence number of the first message most recently received by an NVP is greater than the message sequence number of the historical first message previously received, it indicates that the most recently received first message is the one most recently generated by the corresponding VP, i.e., the block carried in the most recently received first message is the one most recently added to the blockchain by the corresponding VP. In other words, the block carried in the most recently received first message is not stored in the blockchain of this NVP. In this way, this NVP can store the block carried in the first message in the blockchain to synchronize this block.

[0093] If the message sequence number of the first message most recently received by an NVP is less than or equal to the message sequence number of the last received previous first message, it indicates that the most recently received first message is not the first message most recently generated by the corresponding VP, i.e., the block carried in the most recently received first message is likely to have been stored by the blockchain of this NVP, and therefore there is no need to store the block, and therefore the most recently received first message may be discarded.

[0094] In this case, the block stored in the blockchain of any one of the m NVP clusters each time is a block newly added to the corresponding VP. In this way, it can be guaranteed that the blocks stored in the blockchain of any one of the m NVP clusters each time are not duplicated.

[0095] (2) If the first message received by any NVP in each of the m NVP clusters is from the corresponding VP, then its own node identifier is added to the first message to update the first message, and the updated first message is sent to each NVP identified by the node identifier in its own node list.

[0096] The first message is used to indicate that the NVP identified by the node identifier carried in the first message has received the first message, i.e., that the NVP identified by the node identifier carried in the first message has stored the block carried in the first message in the blockchain.

[0097] This NVP adds its own node identifier to the first message to update it, thereby ensuring that the next NVP that receives the updated first message knows which NVP received the first message.

[0098] If the first message received by an NVP is from the corresponding VP, it indicates that this NVP is the first NVP, and in this case, other NVPs in the NVP cluster other than this NVP know that they have not received the first message, i.e., the NVPs adjacent to this NVP have not received the first message, so that this NVP will update the first message and then send the updated first message to the NVPs identified by each node identifier in its node list.

[0099] (3) If the first message received by any one NVP in each of the m NVP clusters is from an NVP in the same NVP cluster, the node identifier carried by the first message is determined as the target node identifier, its own node identifier is added to the first message to update the first message, and the updated first message is sent to the NVPs identified by each other node identifier in its own node list except for the target node identifier.

[0100] If the first message received by an NVP is from an NVP in the same NVP cluster, it indicates that this NVP is a second NVP. At this time, it is known that the first message is received by at least some NVPs (including the first NVP) in other NVPs except this NVP in the NVP cluster where it is located. Therefore, the first message received by this NVP carries a node identifier (i.e., a target node identifier), and the NVP identified by the target node identifier is the NVP that received the first message. Therefore, this NVP may not send an updated first message to the NVP identified by the target node identifier. That is, after the first message is updated, this NVP may send an updated first message to NVPs identified by each other node identifier other than the target node identifier in its node list.

[0101] In this way, it is guaranteed that each NVP in each of the m NVP clusters does not receive a duplicate first message, thereby ensuring that the blocks stored in each NVP's blockchain are unique.

[0102] Preferably, the node list of one NVP may further include an output interface corresponding to the node identifier of an adjacent NVP.

[0103] The output interface is the network interface through which an NVP sends the first message when the NVP sends the first message to an NVP identified by the node identifier in the node list. For example, the node identifier of an NVP is 02, and the node identifiers of the three adjacent NVPs including the NVP in the node list of the NVP are 01, 03, and 04. The output interfaces corresponding to the node identifiers of the three adjacent NVPs included in the node list are shown in Table 2 below.

[0104] [Table 2]

[0105] In the embodiment of the present application, the node list of one NVP is illustratively described using Table 2 as an example, and Table 2 does not limit the embodiment of the present application.

[0106] In this case, the operation of sending an updated first message by one NVP to an NVP identified by each other node identifier other than the target node identifier in the node list of the NVP may be that the NVP obtains an output interface corresponding to each other node identifier other than the target node identifier from the node list of the NVP, and for any one node identifier among each other node identifier other than the target node identifier in the node list of the NVP, the NVP sends the updated first message to the NVP identified by this node identifier by using the output interface corresponding to this node identifier.

[0107] In this way, each node identifier in the node list corresponds to one output interface, and any one NVP in each of the m NVP clusters can send an updated first message to an adjacent NVP from an output interface corresponding to the node identifier of the adjacent NVP, thereby avoiding network congestion and improving message transmission speed.

[0108] Preferably, any one of the NVPs in each of the m NVP clusters includes a first module and a second module, the first module is configured to communicate with adjacent NVPs in the same NVP cluster and is further configured to communicate with a corresponding VP, and the second module is configured to process a block carried in the first message.

[0109] In this case, the operation of step 202 may be: if the first module receives the first message, it sends the block carried in the first message to the second module; after the second module receives the block sent by the first module, it stores the block in its own block chain; if the first message received by the first module is from a corresponding VP, the first module adds the node identifier of the NVP to which the first module belongs to the first message to update the first message, and sends the updated first message to each NVP identified by the node identifier in its own node list; if the first message received by the first module is from an NVP in the same NVP cluster, the first module determines the node identifier carried in the first message as a target node identifier, adds the node identifier of the NVP to which the first module belongs to the first message to update the first message, and sends the updated first message to NVPs identified by other node identifiers than the target node identifier in its own node list.

[0110] In this way, the first module receives, updates and sends the first message, and the second module receives the block sent by the first module and stores the block in its own blockchain, that is, the first module and the second module have their own division of labor, which can improve the efficiency of block synchronization.

[0111] Among them, the operations performed by the first module and the second module are similar to the operations of one NVP receiving a first message, storing the block carried in the first message in the blockchain, and sending the first message to an adjacent NVP in the same NVP cluster, and detailed description thereof is omitted here.

[0112] Preferably, the VP corresponding to each of the m NVP clusters may generate a check message in the block consensus process, and the VP may further send the check message to the first NVP in the corresponding NVP cluster.

[0113] The check message is used to instruct the NVP to check whether the block stored in its blockchain is correct, and the check message carries a first target block identifier and a first target block hash value. The first target block identifier is the block identifier of the block on which the VP performs the consensus process, and the first target block hash value is the block hash value of the block on which the VP performs the consensus process.

[0114] Preferably, a VP may generate a check message and send the check message to the first NVP in the corresponding NVP cluster in the following two cases:

[0115] In the first case, each time a VP completes consensus on a block, it may add the block to the blockchain, send a first message carrying the block to a first NVP in the corresponding NVP cluster, and then send a check message to the first NVP in the corresponding NVP cluster, where the first target block identifier carried in the check message is the block identifier of the block, and the first target block hash value is the block hash value of the block.

[0116] In this case, every time the first message carrying this block is sent to the first NVP in the corresponding NVP cluster, a check message for this block is sent to the first NVP in the corresponding NVP cluster. This can ensure that every time each NVP in the corresponding NVP cluster stores a block, it receives a check message corresponding to this block, and ensure that each NVP can check each block stored in its own blockchain, thereby ensuring the accuracy of the blocks stored in its own blockchain.

[0117] In the second case, after the VP completes the consensus for a block, adds the block to the blockchain, and sends a first message carrying the block to the first NVP in the corresponding NVP cluster, if the block is generated after the block rollback operation is executed, the VP may send a check message for the block to the first NVP in the corresponding NVP cluster. If the block is not the latest generated after the block rollback operation is executed, the VP may not send a check message for the block to the first NVP in the corresponding NVP cluster.

[0118] Since the block identifier of the block most recently generated after the block rollback operation is executed is the same as the block identifier of the block last generated before the block rollback operation is executed, by the VP executing the block rollback operation, the VP sends the block with the two block identifiers being the same to the first NVP of the corresponding NVP cluster, and each NVP in the corresponding NVP cluster receives the block with the two block identifiers being the same, but each NVP does not know which block is the correct block, so the blockchain of each NVP temporarily branches, that is, the next block of one block in the blockchain is divided into blocks with the two block identifiers being the same. In this case, when the next block of the block identified by the two same block identifiers comes, in order to store the next block in the blockchain, it is necessary to compare the parent block hash value of the next block with the block hash values ​​of these two blocks to determine which of these two blocks is the parent block of the next block.

[0119] In this case, after the latest block is generated after the block rollback operation is executed, the VP may send a check message for this block to the first NVP in the corresponding NVP cluster. After receiving this check message, each NVP in the corresponding NVP cluster can check that which of the blocks with the same two block identifiers stored in the blockchain is correct. This can ensure the accuracy of the blocks stored in the blockchain. Only when the latest block is generated after the block rollback operation is executed, the VP sends a check message to the first NVP in the corresponding NVP cluster, so that blockchain system resources can be saved.

[0120] Furthermore, after receiving the check message generated by the corresponding VP, any one NVP in each of the m NVP clusters can search for a first block in its own blockchain, and when the first block is searched for in its own blockchain, if the block hash value of the first block is different from the first target block hash value, the first block is deleted from the blockchain.

[0121] The first block is the block whose block identifier is the same as the first target block identifier.

[0122] After receiving the check message generated by the corresponding VP, an NVP searches for a first block in its own blockchain, i.e., searches for a block whose block identifier is the same as the first target block identifier in its own blockchain. If the first block is searched for in its own blockchain, it compares the block hash value of the first block with the first target block hash value. If the block hash value of the first block is the same as the first target block hash value, it indicates that the first block is correct, and no processing is required. If the block hash value of the first block is different from the first target block hash value, it indicates that the first block is different from the block corresponding to the first target block hash value, and it can be determined that the first block is incorrect, i.e., the first block is likely to be a rolled back block, and the first block can be deleted from its own blockchain.

[0123] For example, after one VP completes consensus on a block with a block identifier of 50, a first message carrying the block with a block identifier of 50 is sent to the first NVP in the corresponding NVP cluster. However, after the VP completes consensus on this block, it performs a rollback on this block, and after performing the block rollback operation, the VP continues to generate a block with a block identifier of 50 and completes consensus on this block. Then, the VP sends a first message carrying the newly generated block with a block identifier of 50 to the first NVP in the corresponding NVP cluster, and sends a check message for this block. In this case, each NVP in the corresponding NVP cluster receives two blocks with a block identifier of 50, and correspondingly stores the two blocks with a block identifier of 50 in its own blockchain, and at this time, it can delete the previously stored block with a block identifier of 50 in response to the check message.

[0124] For example, FIG. 3 is a schematic diagram of blocks stored in a blockchain of an NVP. Referring to FIG. 3, FIG. 3 includes a blockchain 300 and a plurality of blocks 301 stored in the blockchain 300. The plurality of blocks 301 includes a block 301 with two block identifiers of 50, and the block 301 with two block identifiers of 50 causes a temporary branch in the blockchain 300. One NVP receives a check message sent by a corresponding VP, and the first target block identifier carried in the check message is 50. When the NVP searches for the block 301 with the block identifier of 50 from its own blockchain 300, it can find the block 301 with the two block identifiers of 50. Then, if the NVP determines that the block hash value of the previously stored block 301 with a block identifier of 50 among the two blocks 301 with a block identifier of 50 is different from the first target block hash value included in the check message, the NVP can delete the previously stored block 301 with a block identifier of 50 from its own blockchain 300, and thus, all blocks 301 stored in the NVP's blockchain 300 are correct blocks 301.In this case, the NVP's blockchain 300 is as shown in FIG. 4, and all blocks 301 stored in the blockchain 300 shown in FIG. 4 are correct blocks 301.

[0125] The operations performed after each NVP in each of the m NVP clusters receives the first message have been described in detail above, but it is realized that each NVP in each of the m NVP clusters stores the block carried in the first message in its own blockchain, thereby ensuring that each NVP in each of the m NVP clusters synchronizes the blocks stored in multiple VPs with its own blockchain.

[0126] In addition, any one of the NVPs in each of the m NVP clusters may not be able to receive blocks for a long time due to network congestion or network partition, etc., and therefore it is not possible to synchronize this NVP with blocks. Below, we will explain in detail the operations that need to be performed in such cases to solve the problem of not being able to synchronize blocks due to the network.

[0127] Specifically, each NVP in each of the m NVP clusters transmits a blockchain state to other adjacent NVPs in the same NVP cluster at every fourth predetermined time, and the blockchain state includes its own node identifier and the block identifier of the latest block in the blockchain. Any one NVP in each of the m NVP clusters determines the blockchain state transmitted from the adjacent NVP it received as a target blockchain state. If no block is received at the fifth predetermined time, and the block identifier of the latest block in its own blockchain is smaller than the block identifier in the target blockchain state, it obtains a block whose block identifier is larger than the block identifier of the latest block in its own blockchain from the blockchain of the target NVP identified by the node identifier in the target blockchain state, and stores the obtained block in its own blockchain.

[0128] The fourth predetermined time may be preset or may be set by the technician as needed. For example, the fourth predetermined time may be set to 1 minute.

[0129] The blockchain state of an NVP is used to indicate the state of the latest block stored in its own blockchain. The target blockchain state is the blockchain state sent by a neighboring NVP that an NVP receives, and if an NVP has multiple neighboring NVPs, it can receive multiple target blockchain states.

[0130] The fifth predetermined time may be preset, and may be set large to ensure that the block is received in a sufficient time, for example, the fifth predetermined time may be set to 2 minutes.

[0131] A target NVP is an NVP identified by a node identifier in a target blockchain state whose block identifier is greater than the block identifier of the latest block in the NVP's blockchain among multiple target blockchain states received by this NVP.

[0132] Each NVP in each of the m NVP clusters transmits a blockchain state to other adjacent NVPs in the same NVP cluster at every fourth predetermined time, and each NVP can know the status of the latest block stored in the blockchain of the adjacent NVP. If an NVP does not receive a block at the fifth predetermined time, it indicates that the NVP has not received a block within a very long period of time, and the NVP can check whether a block identifier greater than the block identifier of the latest block in its own blockchain exists in any one of the target blockchain states among the multiple target blockchain states, and if the block identifier in one target blockchain state is greater than the block identifier of the latest block in its own blockchain in the multiple target blockchain states, the NVP can obtain a block whose block identifier is greater than the block identifier of the latest block in its own blockchain from the blockchain of the target NVP identified by the node identifier in the target blockchain state. The obtained block can then be stored in its own blockchain to realize synchronization of blocks not stored in its own blockchain. If the block identifier in each of the multiple target blockchain states is less than or equal to the block identifier of the most recent block in its own blockchain, the NVP continues to wait to receive a block.

[0133] In this way, when an NVP does not receive a block for a long time, it can directly obtain a block whose block identifier is greater than the block identifier of the latest block in its own blockchain from the blockchain of the neighboring target NVP, thereby saving system resources, saving block synchronization time, and improving block synchronization efficiency.

[0134] Preferably, the blockchain state further includes a block hash value of the latest block in the blockchain, in which case the operation of the NVP obtaining a block whose block identifier is greater than the block identifier of the latest block in its own blockchain from the blockchain of the target NVP identified by a node identifier in the target blockchain state may be the NVP sending a third message to the target NVP identified by a node identifier in the target blockchain state, and upon receiving the third message, the target NVP searching for a second block from its own blockchain, and if upon searching for the second block from its own blockchain, the target NVP sending to the NVP all blocks whose block identifiers in its own blockchain are greater than the third target block identifier and less than or equal to the second target block identifier, if the block hash value of the second block is the same as the second target block hash value.

[0135] Here, the target blockchain state is a target blockchain state among multiple target blockchain states whose block identifier is greater than the block identifier of the latest block in the blockchain of this NVP.

[0136] The third message is used to instruct the target NVP to send a block in its blockchain that is greater than the block identifier of the latest block in the blockchain of this NVP to this NVP. The third message carries a second target block identifier, a second target block hash value, and a third target block identifier. The second target block identifier is a block identifier in the target blockchain state, i.e., the block identifier of one block that is not stored in the blockchain of this NVP. The second target block hash value is a block hash value in the target blockchain state, i.e., the block hash value of one block that is not stored in the blockchain of this NVP. The third target block identifier is the block identifier of the latest block in the blockchain of this NVP.

[0137] The second block is the block whose block identifier is the same as the second target block identifier.

[0138] In this case, after receiving the third message, the target NVP searches whether there is a block (i.e., a second block) whose block identifier is the same as the second target block identifier in its blockchain, and if it is found that the second block exists in its blockchain, it compares the block hash value of the second block with the second target block hash value included in the third message, and if the block hash value of the second block is the same as the second target block hash value, it indicates that the second block is one of the blocks not stored in this NVP's blockchain, in which case the block identifier in the target NVP's blockchain is greater than the block identifier of the latest block in this NVP's blockchain (i.e., the third target block identifier), and all blocks equal to or less than the block identifier of the second block (i.e., the second target block identifier) ​​are blocks not stored in this NVP's blockchain. The target NVP may send all blocks whose block identifiers in its blockchain are greater than the third target block identifier and less than or equal to the second target block identifier to this NVP. After receiving the blocks sent by the target NVP, this NVP can store the received blocks in its own blockchain and synchronize blocks that are not stored in its own blockchain, thereby ensuring that the blocks stored in its own blockchain are the same as the blocks stored in the blockchains of other NVPs.

[0139] Preferably, during the execution of the blockchain system, an NVP may be added to any one of the m NVP clusters, and the added NVP may not yet have any blocks stored in its blockchain, so the added NVP can synchronize all blocks stored in the blockchains of other NVPs in its NVP cluster. In this case, the newly added NVP can synchronize blocks stored in the blockchains of other NVPs in its NVP cluster by performing the above-mentioned step of obtaining all blocks from the target NVP.

[0140] The above describes in detail the operation of any one NVP in each of the m NVP clusters actively acquiring blocks that are not stored in its own blockchain from the target NVP. In an embodiment of the present application, when any one NVP in each of the m NVP clusters finds that some blocks in its own blockchain are missing, it actively acquires all the missing blocks from the target NVP to perform synchronization of all the missing blocks (i.e., point-to-point pull). In this way, system resources can be saved and block synchronization efficiency can be improved.

[0141] In an embodiment of the present application, the blockchain system includes a plurality of VPs and m NVP clusters, and the m VPs of the plurality of VPs correspond one-to-one to the m NVP clusters, and each of the m NVP clusters includes a first NVP and at least one second NVP. The first NVP is an NVP that communicates with the corresponding VP, and has a network path between the first NVP and each of the at least one second NVP, and therefore the first NVP in an NVP cluster may communicate with the corresponding VP or may communicate with another NVP in the same NVP cluster. After the multiple VPs complete consensus on a block and add the block to the blockchain, each of the m VPs sends a first message carrying the block to the first NVP in the corresponding NVP cluster. When each NVP in each of the m NVP clusters receives the first message, the block carried by the first message is stored in the blockchain, and the first message is sent to the adjacent NVP in the same NVP cluster, and in this way, each NVP in each NVP cluster can synchronize this block. In this case, each of the m VPs can synchronize the block by each NVP in the corresponding NVP cluster by only sending the first message carrying the block to the first NVP in the corresponding NVP cluster, thereby reducing the load of the VP and improving the consensus efficiency of the block.

[0142] 5 is a schematic structural diagram of a computer device according to an embodiment of the present application. As shown in FIG. 5, the computer device 5 includes a processor 50, a memory 51, and a computer program 52 stored in the memory 51 and executable by the processor 50. When the processor 50 executes the computer program 52, the steps of the block synchronization method in the above embodiment are realized.

[0143] The computing device 5 may be a server cluster including multiple servers, and the server cluster may be a blockchain system. As can be understood by those skilled in the art, FIG. 5 is merely an example of the computing device 5, and is not intended to be limiting, and may include more or fewer components than those shown, or may combine some components, or may include different components, such as input / output devices, network access devices, etc.

[0144] Processor 50 may be a Central Processing Unit (CPU) or other general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, etc. The general purpose processor may be a microprocessor or any conventional processor.

[0145] The memory 51 may be an internal storage unit of the computer device 5, such as a hard disk or memory of the computer device 5, in some embodiments. The memory 51 may be an external storage device of the computer device 5, such as a plug-in hard disk mounted on the computer device 5, a Smart Media Card (SMC), a Secure Digital (SD) card, a Flash Card, etc., in other embodiments. Furthermore, the memory 51 may include both an internal storage unit and an external storage device of the computer device 5. The memory 51 is configured to store an operating system, application programs, a boot loader, data, other programs, etc. The memory 51 may be configured to temporarily store data that is output or to be output.

[0146] An embodiment of the present application further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, can realize the steps of each of the above method embodiments.

[0147] An embodiment of the present application provides a computer program product, which, when executed on a computer, causes the computer to perform the steps of each of the method embodiments described above.

[0148] Based on such understanding, the present application realizes all or part of the flow in the above method embodiments, and can complete the relevant hardware by instructing it by a computer program, which can be stored in a computer-readable storage medium, and can realize the steps of each of the above method embodiments when the computer program is executed by a processor. The computer program includes a computer program code, which may be in source code format, object code format, executable file, or some intermediate format, etc. The computer-readable medium may include at least any entity or device that can carry the computer program code to a shooting device / terminal device, a recording medium, a computer memory, a ROM (Read-Only Memory), a RAM (Random Access Memory), a CD-ROM (Compact Disc Read-Only Memory, a playback-only optical disk), a magnetic tape, a floppy disk, and an optical data storage device, etc. The computer-readable storage medium referred to in the present application may be a non-volatile storage medium, in other words, a non-transitory storage medium.

[0149] It should be understood that all or part of the steps of the above embodiment may be realized by software, hardware, firmware, or any combination thereof. When realized using software, all or part may be realized in the form of a computer program product. The computer program product includes one or more computer instructions. The computer instructions may be stored in the above computer-readable storage medium.

[0150] In the above embodiments, the emphasis of the description in each embodiment is different, and for parts that are not detailed or described in one embodiment, reference can be made to the relevant descriptions of other embodiments.

[0151] Those skilled in the art can recognize that each example unit and algorithm step described in connection with the embodiments disclosed herein can be realized by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed by hardware or software depends on the specific application and design constraints of the technical solution. Professional engineers can realize the described functions using different methods for each specific application, but such realization should be considered within the scope of the present application.

[0152] The above examples are only for explaining the technical solutions of the present application, but are not limiting thereof. Although the present application has been described in detail with reference to the above examples, those skilled in the art may still modify the technical solutions described in the above examples or make equivalent substitutions for some of the technical features therein, and such modifications or substitutions shall not deviate from the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and all of them shall be included in the protection scope of the present application.

Claims

1. A block synchronization method applied to a blockchain system, comprising: The blockchain system includes a plurality of consensus node VPs and m non-consensus node NVP clusters, and the m VPs of the plurality of VPs correspond one-to-one to the m NVP clusters, and each of the m NVP clusters includes a first NVP and at least one second NVP, and the first NVP is an NVP that communicates with a corresponding VP, and has a network path between the first NVP and each of the at least one second NVP, and the m is a positive integer; The method comprises: Each time the multiple VPs complete consensus on a block and add the block to the blockchain, each of the m VPs sends a first message including the block and conveying the block to the first NVP in a corresponding NVP cluster; When each NVP in each of the m NVP clusters receives the first message, the NVP stores the block carried in the first message in the blockchain of the respective NVP, and transmits the first message to adjacent NVPs in the same NVP cluster.

23. A block synchronization method comprising:

2. Before each of the m VPs transmits the first message carrying the block to the first NVP in a corresponding NVP cluster, The method comprises: Any one of the m NVP clusters selects a primary NVP in a dynamic selection manner, and another NVP other than the primary NVP in the one NVP cluster is a secondary NVP, the primary NVP in the one NVP cluster is the first NVP, and the secondary NVP in the one NVP cluster is the second NVP; The first NVP in the one NVP cluster sends a first notification message to a corresponding VP, and the first notification message is used to indicate that the NVP sending the first notification message has been elected as a primary NVP in the NVP cluster in which the NVP is located.

2. The method according to claim 1 .

3. Any one of the m NVP clusters selects one primary NVP in a dynamic selection manner; After the one NVP cluster is globally activated, each of at least one NVP in the one NVP cluster broadcasts a second message carrying its node identifier to another NVP in the one NVP cluster, the second message being used to indicate that the NVP identified by the node identifier carried in the second message applies to be a primary NVP; Any one of the at least one NVPs is receiving the second message broadcast by another NVP at a first predetermined time after the second message is broadcast; comparing its own node identifier with node identifiers carried in the second messages broadcast by other NVPs received within the first predetermined time period to determine whether it has been elected as a primary NVP; when it is determined that the NVP has been selected as the primary NVP, a second notification message is sent to another NVP in the same NVP cluster at every second predetermined time, the second notification message being used to indicate that the NVP sending the second notification message has been selected as the primary NVP of the NVP cluster in which the NVP is located, and the second notification message is used to indicate that the NVP receiving the second notification message is a secondary NVP of the NVP cluster in which the NVP is located.

3. The method according to claim 2 .

4. The method comprises: if any one of the secondary NVPs in the one NVP cluster does not receive the second notification message within a third predetermined time, the second message is broadcast to another NVP in the same NVP cluster, and the third predetermined time is equal to or greater than the second predetermined time; When any one NVP in the one NVP cluster receives the second message broadcast by the one secondary NVP, the NVP compares its own node identifier with the node identifier carried in the second message broadcast by the one secondary NVP, and if the one secondary NVP determines that it cannot be selected as the primary NVP, the NVP broadcasts the second message to other NVPs in the same NVP cluster; Any one of the NVPs in the one NVP cluster is receiving the second message broadcast by another NVP at the first predetermined time after the second message was most recently broadcast; comparing its own node identifier with node identifiers carried in the second messages broadcast by other NVPs received at the first predetermined time to determine whether it has been elected as a primary NVP; When it is determined that the NVP is selected as the primary NVP, the second notification message is sent to other NVPs in the same NVP cluster at the second predetermined time interval.

4. The method according to claim 3 .

5. The NVP has a node list, the node list including node identifiers of adjacent NVPs in the same NVP cluster; When each NVP in each of the m NVP clusters receives the first message, storing the block carried in the first message in a blockchain and transmitting the first message to a neighboring NVP in the same NVP cluster, Any one NVP in each of the m NVP clusters, upon receiving the first message, storing the block carried in the first message in its blockchain; If the received first message is from a corresponding VP, updating the first message by adding its own node identifier to the first message, and sending the updated first message to each NVP identified by the node identifier in the node list; If the received first message is from an NVP in the same NVP cluster, a node identifier carried in the first message is determined as a target node identifier, and the first message is updated by adding its own node identifier to the first message, and the updated first message is sent to each NVP identified by another node identifier other than the target node identifier in the node list. Including, 2. The method according to claim 1 .

6. The first message generated by the VP further carries a message sequence number of the first message, and the message sequence number of the first message generated by the VP is incremented. Prior to storing the block carried in the first message in its blockchain, the method further comprises: When the first message is received, the step of storing the block carried in the first message in its own blockchain is performed when a message sequence number of the most recently received first message is greater than a message sequence number of a previously received historical first message.

6. The method according to claim 5 .

7. The method comprises: Any one NVP in each of the m NVP clusters, receiving a check message generated by a corresponding VP, the check message carrying a first target block identifier and a first target block hash value; searching for a first block in the blockchain, the first block being a block whose block identifier is the same as the first target block identifier; when the first block is detected in its own blockchain, if a block hash value of the first block is different from the first target block hash value, delete the first block from its own blockchain. [0023] 2. The method according to claim 1 .

8. The method comprises: Each NVP in each of the m NVP clusters transmits a blockchain state to other adjacent NVPs in the same NVP cluster at every fourth predetermined time, the blockchain state including its own node identifier and a block identifier of the latest block in the blockchain; Any one NVP in each of the m NVP clusters determines the blockchain state transmitted from the received neighboring NVP as a target blockchain state, and if no block is received within a fifth predetermined time, if the block identifier of the latest block in the NVP's blockchain is smaller than the block identifier in the target blockchain state, obtains a block whose block identifier is larger than the block identifier of the latest block in the NVP's blockchain from the blockchain of the target NVP identified by the node identifier in the target blockchain state, and stores the obtained block in the NVP's blockchain.

2. The method according to claim 1 .

9. The blockchain state further includes a block hash value of a latest block in the blockchain, and the one NVP obtains a block from the blockchain of a target NVP identified by a node identifier in the target blockchain state, the block identifier being greater than the block identifier of the latest block in the one NVP's blockchain. the one NVP sends a third message to the target NVP identified by a node identifier in the target blockchain state, the third message carrying a second target block identifier, a second target block hash value, and a third target block identifier, the second target block identifier being a block identifier in the target blockchain state, the second target block hash value being a block hash value in the target blockchain state, and the third target block identifier being a block identifier of a latest block in the one NVP's blockchain; the target NVP, upon receiving the third message, searches for a second block from its own blockchain, the second block being a block whose block identifier is the same as the second target block identifier; and upon finding the second block from its own blockchain, if the block hash value of the second block is the same as the second target block hash value, sending to the one NVP all blocks whose block identifiers in its own blockchain are greater than the third target block identifier and less than or equal to the second target block identifier.

9. The method according to claim 8 .

10. The first message is an infectious disease protocol GOSSIP message; 2. The method according to claim 1 .

11. A blockchain system, The blockchain system includes a plurality of consensus node VPs and m non-consensus node NVP clusters, and the m VPs of the plurality of VPs correspond one-to-one to the m NVP clusters, and each of the m NVP clusters includes a first NVP and at least one second NVP, and the first NVP is an NVP that communicates with a corresponding VP, and has a network path between the first NVP and each of the at least one second NVP, and the m is a positive integer; Each of the m VPs sends a first message including and carrying a block to the first NVP in a corresponding NVP cluster each time the multiple VPs complete consensus on a block and add the block to a blockchain; Each NVP in each of the m NVP clusters, when the first message is received, stores the block carried in the first message in the blockchain of the respective NVP, and transmits the first message to a neighboring NVP in the same NVP cluster. A blockchain system characterized by:

12. 1. A computing device comprising: A method according to any one of claims 1 to 10, comprising: a memory; a processor; and a computer program stored in the memory and executable by the processor, the computer program being executed by the processor to implement the method according to any one of claims 1 to 10. A computing device comprising:

13. A computer-readable storage medium having a computer program stored thereon, When the computer program is executed by a processor, the method according to any one of claims 1 to 10 is realized. A computer-readable storage medium comprising:

Images