CN115174598A

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

Info

Publication number: CN115174598A
Application number: CN202211064387.8A
Authority: CN
Inventors: 张珂杰; 黄方蕾; 叶晨宇; 尚璇; 胡麦芳
Original assignee: Hangzhou Qulian Technology Co Ltd
Current assignee: Hangzhou Qulian Technology Co Ltd
Priority date: 2022-09-01
Filing date: 2022-09-01
Publication date: 2022-10-11
Anticipated expiration: 2042-09-01
Also published as: JP2024035121A; CN115174598B

Abstract

The application discloses a block synchronization method, a block chain system, a device and a storage medium, and belongs to the technical field of block chains. The blockchain system includes a plurality of VPs and m NVP clusters, each NVP cluster including a first NVP and at least one second NVP, the first NVP being an NVP that communicates with a corresponding VP, the method including: each VP of m VPs in the multiple VPs sends a first message carrying a block to a first NVP in a corresponding NVP cluster; and if each NVP receives the first message, storing the block carried by the first message into a block chain, and sending the first message to the adjacent NVP. In the application, each VP in m VPs only needs to send a first message carrying a block to a first NVP in a corresponding NVP cluster, so that synchronization of each NVP in the corresponding NVP cluster to the block can be realized, the pressure of the VP is reduced, and further the block consensus efficiency can be improved.

Description

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

Technical Field

The present application relates to the field of blockchain technologies, and in particular, to a method, a system, a device, and a storage medium for block synchronization.

Background

Since the block chains have non-tamper-proof property, the block chain technology is rapidly developed and has been widely used in various fields. In some scenarios, the blockchain system includes a plurality of common nodes (VPs) and a plurality of non-common Nodes (NVPs). The VP needs to participate in the block consensus process, the NVP does not need to participate in the block consensus process, and the NVP needs to synchronize the blocks that have obtained the VP's consensus in order to maintain the consistency of the data in the nodes.

In the related art, each VP of the plurality of VPs may be directly communicatively connected to a plurality of NVPs. After a plurality of VPs have completed consensus on a block, the block is added in the block chain. Any one of the VPs may then send the block directly to the NVPs communicatively coupled to the VP to synchronize each of the NVPs with the block.

However, in the above manner, if the number of blocks that the VP needs to know is increasing and the number of NVPs in communication connection with the VP continues to increase, the VP is very busy. This results in a relatively large VP pressure, which affects the block consensus efficiency.

Disclosure of Invention

The application provides a block synchronization method, a block chain system, a device and a storage medium, which can reduce the pressure of a consensus node in the block chain system and improve the block consensus efficiency. The technical scheme is as follows:

in a first aspect, a block synchronization method is provided and applied to a blockchain system, where the blockchain system includes a plurality of common-node VPs and m non-common-node NVP clusters, m VPs in the plurality of VPs correspond to the m NVP clusters one to one, each of the m NVP clusters includes a first NVP and at least one second NVP, the first NVP is an NVP communicating with the corresponding VP, a network path is provided between the first NVP and each of the at least one second NVP, and m is a positive integer, where the method includes:

after the VPs finish the common identification of one block and add the block to a block chain, each VP in the m VPs sends a first message carrying the block to the first NVP in the corresponding NVP cluster;

and if each NVP in each NVP cluster in the m NVP clusters receives the first message, storing the block carried by the first message to a block chain, and sending the first message to an adjacent NVP in the same NVP cluster.

In this application, the blockchain system includes a plurality of VPs and m NVP clusters, where m VPs of the plurality of VPs correspond to the m NVP clusters one to one, and each of the m NVP clusters includes a first NVP and at least one second NVP. The first NVP is an NVP communicating with a corresponding VP, and a network path is provided between the first NVP and each of the at least one second NVP, so that the first NVP in the NVP cluster can communicate with the corresponding VP and also communicate with other NVPs in the same NVP cluster. After the VPs finish the common identification of one block and add the block to the block chain, each VP in the m VPs sends a first message carrying the block to a first NVP in a corresponding NVP cluster. If each NVP in each of the m NVP clusters receives the first message, storing the block carried by the first message to a block chain, and sending the first message to an adjacent NVP in the same NVP cluster, so that each NVP in each NVP cluster can synchronize the block. In this case, each VP in the m VPs only needs to send the first message carrying the block to the first NVP in the corresponding NVP cluster, so that the block can be synchronized by each NVP in the corresponding NVP cluster, the pressure of the VP is reduced, and the block consensus efficiency can be improved.

In a second aspect, a blockchain system is provided, where the blockchain system includes a plurality of common-identified-node VPs and m non-common-identified-node NVP clusters, m VPs of the plurality of VPs correspond to the m NVP clusters one-to-one, each of the m NVP clusters includes a first NVP and at least one second NVP, the first NVP is an NVP communicating with the corresponding VP, a network path is provided between the first NVP and each of the at least one second NVP, and m is a positive integer;

each VP in the m VPs is configured to send a first message carrying a block to the first NVP in the corresponding NVP cluster after the VP completes the consensus on one block and adds the block to a block chain;

each NVP in each of the m NVP clusters is configured to store the block carried by the first message to a block chain if the first message is received, and send the first message to an adjacent NVP in the same NVP cluster.

In a third aspect, a computer device is provided, the computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, the computer program, when executed by the processor, implementing the above-mentioned block synchronization method.

In a fourth aspect, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the block synchronization method described above.

In a fifth aspect, a computer program product is provided comprising instructions which, when run on a computer, cause the computer to perform the steps of the above-described block synchronization method.

It is to be understood that, for the beneficial effects of the second aspect, the third aspect, the fourth aspect and the fifth aspect, reference may be made to the description of the first aspect, and details are not described herein again.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

Fig. 1 is a schematic structural diagram of a block chain system according to an embodiment of the present disclosure;

fig. 2 is a flowchart of a block synchronization method according to an embodiment of the present application;

fig. 3 is a schematic diagram of a block chain according to an embodiment of the present application;

FIG. 4 is a schematic diagram of another blockchain provided by embodiments of the present application;

fig. 5 is a schematic structural diagram of a computer device according to an embodiment of the present application.

Detailed Description

To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

It should be understood that reference to "a plurality" in this application means two or more. In the description of the present application, "/" means "or" unless otherwise stated, for example, a/B may mean a or B; "and/or" herein is only an association relationship describing an associated object, and means that there may be three relationships, for example, a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, for the convenience of clearly describing the technical solutions of the present application, the terms "first", "second", and the like are used to distinguish the same items or similar items having substantially the same functions and actions. Those skilled in the art will appreciate that the terms "first," "second," etc. do not denote any order or quantity, nor do the terms "first," "second," etc. denote any order or importance.

Before explaining the embodiments of the present application in detail, an application scenario of the embodiments of the present application will be described.

The block synchronization method provided by the embodiment of the application can be applied to synchronizing the blocks stored in the VP of the blockchain system to each NVP scene in the NVP cluster.

For example, in a federation chain scenario, a federation chain includes nodes for a plurality of provincial enterprises and nodes for municipalities under some provincial enterprises. In this case, the block synchronization method provided by the embodiment of the present application can be applied to this scenario, where a plurality of nodes (i.e., VPs) of the provincial organization can participate in the block consensus process, and a node (i.e., NVP) of a city level unit under one provincial organization does not need to participate in the block consensus process.

Specifically, each time any one of the plurality of provincial institutions' nodes receives a transaction sent by the client, a new block is generated, and the block is sent to the nodes of the rest of the plurality of provincial institutions, so that the nodes of the plurality of provincial institutions perform consensus processing on the block. After the nodes of the provincial institutions complete the consensus processing on the block, the node of each provincial institution may send the block to a node of a city unit communicating with the node of the city unit in the plurality of city units under its own authority. After receiving the block, the node of the city unit stores the block into its own block chain, and sends the block to the node of the adjacent city unit. By analogy, after the node of each of the plurality of city-level units under one provincial organization receives the block, the block can be stored in the block chain of the node, and the block is sent to the node of the adjacent city-level unit. In this way, the node of each city unit in a plurality of city units under one provincial organization can synchronize the block to the block chain of the node. In this case, the node of each provincial organization in the block chain system only needs to send the block to the node of one city unit communicated with the node, and synchronization of the node of each city unit in the subordinate city units to the block can be achieved.

The following describes the related contents of the block chain system related to the embodiments of the present application.

Fig. 1 is a schematic structural diagram of a blockchain system according to an embodiment of the present disclosure.

Referring to fig. 1, a blockchain system 100 refers to a system for data sharing between nodes, the blockchain system 100 includes a plurality of VPs 101 and m NVP clusters 102, each NVP cluster 102 of the m NVP clusters 102 includes a plurality of NVPs 103, and m is a positive integer.

Multiple VPs 101 are nodes in the blockchain system that need to participate in the block consensus process. Each NVP103 in each NVP cluster 102 of the m NVP clusters 102 is a node that does not need to participate in the block consensus process.

Multiple VPs 101 may receive input information during normal operation and maintain shared data within the blockchain system 100 based on the received input information. There may be an information connection between the VPs 101, and information may be transmitted between the VPs 101 through the information connection. For example, when an arbitrary VP101 in the blockchain system 100 receives input information sent by a client, other VPs 101 in the blockchain system 100 acquire the input information according to a consensus algorithm and store the input information as data in shared data.

In addition, m VPs 101 of the plurality of VPs 101 correspond to m NVP clusters 102 one-to-one, and for any one VP101 of the m VPs 101, the VP101 can communicate with a corresponding NVP cluster 102 of the m NVP clusters 102. After the VPs 101 in the blockchain system 100 store the input information as data in shared data, the corresponding NVP clusters 102 may also communicate with each other, that is, send the input information to the corresponding NVP clusters 102, so that the NVPs 103 in the corresponding NVP clusters 102 store the input information as data in shared data.

Wherein, the VP101 in the blockchain system 100 communicates with one NVP103 in the corresponding NVP cluster 102, that is, the VP101 in the blockchain system 100 sends a message to only one NVP103 in the corresponding NVP cluster 102, so that the pressure of the plurality of VPs 101 in the blockchain system 100 can be reduced, and the performance of the plurality of VPs 101 in the blockchain system 100 can be improved.

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

The plurality of NVPs 103 in each NVP cluster 102 includes a first NVP103 and at least one second NVP103, and the first NVP103 is the NVP103 in the NVP cluster 102 that communicates with the corresponding VP101, that is, one VP101 in the blockchain system 100 sends the input information to the first NVP103 in the corresponding NVP cluster 102. Wherein, each NVP cluster 102 can be arbitrarily added with a new NVP103, and this does not affect the capability of the VP101 in the blockchain system 100 to send a message to the corresponding NVP cluster 102, so the extensibility of each NVP cluster 102 in the blockchain system 100 is strong.

In addition, there is a network path between the first NVP103 and each of the at least one second NVP103. The network paths are used to indicate data transmission paths between the multiple NVPs 103, and the first NVP103 can transmit data to at least one second NVP103 through the network paths. There may be multiple NVPs 103 in the network path between two NVPs 103, in which case the two NVPs 103 may communicate indirectly. The network path between two NVPs 103 may also not have other NVPs 103, i.e. two NVPs 103 may communicate directly, i.e. the two NVPs 103 are adjacent NVPs 103.

After the first NVP103 of the NVPs 103 receives the input information, the input information can be transmitted through the network path, so that the remaining second NVPs 103 of the NVPs 103 can also receive the input information. In this way, each NVP103 in the plurality of NVPs 103 stores the input information as data in shared data, so as to achieve consistency of data stored on all nodes in the blockchain system 100. That is, each node in the blockchain system 100 stores one identical blockchain.

The blockchain system 100 has computer technologies such as distributed data storage, point-to-point transmission, consensus mechanisms, encryption algorithms, etc. The block chain system 100 is a distributed shared account book and database, and has the characteristics of decentralization, no tampering, trace retaining in the whole process, traceability, collective maintenance, openness and transparency and the like. The characteristics ensure that the block chain is shared openly, real and complete, safe and reliable.

The multiple VPs 101 and m NVP clusters 102 in the blockchain system 100 can perform the block synchronization method described in the embodiment of fig. 2 below to synchronize the blocks (i.e., the shared data described above) stored in the VPs 101 of the blockchain system 100 to each NVP103 in the NVP clusters 102.

The block synchronization method provided in the embodiments of the present application is explained in detail below.

Fig. 2 is a flowchart of a block synchronization method according to an embodiment of the present disclosure. The method can be applied to a blockchain system. Referring to fig. 2, the method includes the following steps.

Step 201: after each of the VPs completes the consensus on one block and adds the block to the block chain, each of the m VPs in the VPs sends a first message carrying the block to a first NVP in the corresponding NVP cluster.

The first NVP is an NVP in the same NVP cluster, which communicates with a corresponding VP, and only one first NVP exists in the same NVP cluster, that is, each VP of m VPs in the multiple VPs sends a first message carrying the block to an NVP in the corresponding NVP cluster.

The block is carried in the first message, and the first message is used for indicating the NVP receiving the first message to store the block carried in the first message. Optionally, the first message may be a GOSSIP (epidemic disease protocol) message, and of course, the first message may also be other types of messages, which is not limited in this embodiment of the present application.

Since each NVP in each of the m NVP clusters in the block chain system provided in the embodiment of the present application does not need to participate in the block consensus process, each VP in the m VPs may send a first message carrying the block to the corresponding NVP cluster, so that the corresponding NVP cluster obtains and stores the block, thereby ensuring the consistency of the block chain stored by each node in the block chain system.

In this case, the first NVP in the NVP cluster corresponding to each VP in the m VPs may receive the first message carrying the block, and then the first NVP in the corresponding NVP cluster may store the block. And each VP 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. In this manner, the pressure of each VP is relieved.

It is noted that before each VP in the m VPs sends the first message carrying the block to the first NVP in the corresponding NVP cluster, one NVP cluster in any one of the m NVP clusters may also elect a main NVP.

The main NVP of one NVP cluster is used for communicating with the corresponding VP, that is, the main NVP is a first NVP, the other NVPs in the one NVP cluster except the main NVP are slave NVPs, and the slave NVP in the one NVP cluster is a second NVP. That is, there is one master NVP and at least one slave NVP in one NVP cluster.

Further, after a main NVP (i.e., a first NVP) is elected by any one of the m NVP clusters, the first NVP in the NVP cluster may send a first notification message to the corresponding VP.

The first notification message is used for indicating that the NVP sending the first notification message is elected to be the main NVP of the NVP cluster. In this case, the NVP sending the first notification message is an NVP in the NVP cluster communicating with the corresponding VP, and then the corresponding VP adds the block to the block chain, and then sends the first message to the NVP (i.e., the first NVP) of the elected main NVP in the NVP cluster, thereby ensuring that the corresponding VP can send the first message only to the first NVP of the NVP cluster.

Optionally, any one of the m NVP clusters may elect a master NVP by means of dynamic election.

Therefore, when the main NVP elected by the NVP cluster is down, one main NVP is elected again to ensure that a first NVP always exists in one NVP cluster to communicate with the corresponding VP, so that the activity of the NVP cluster is improved.

Specifically, the operation of electing a main NVP by any one of the m NVP clusters in a dynamic election manner can be realized through the following steps (1) to (4).

(1) After the entire NVP cluster is started, each NVP in at least one NVP in the NVP cluster broadcasts a second message carrying the node identification of the NVP cluster to other NVPs in the same NVP cluster.

The entire NVP cluster starting is that each NVP in all NVPs in the NVP cluster is started, namely, each NVP starts to enter a working state.

The at least one NVP is an NVP which is required to be applied for becoming a main NVP in the NVP cluster after the whole NVP cluster is started.

The node id of a certain NVP is used to uniquely identify the NVP, for example, the node id of a certain NVP may be a number, an IP (Internet Protocol) address, and the like of the NVP.

The second message carries a node identifier, and the second message is used for indicating that the NVP identified by the node identifier carried by the second message applies for becoming the main NVP. Optionally, the second message may be a GOSSIP message, and of course, the second message may also be other types of messages, which is not limited in this embodiment of the present application.

After an entire NVP cluster is started, there may be no first NVP in the NVP cluster, that is, there is no NVP in the NVP cluster that communicates with the corresponding VP, and after the corresponding VP adds the block to the block chain, it may not know to which NVP in the NVP cluster the first message carrying the block is sent. Therefore, after the entire NVP cluster is started, a main NVP needs to be elected first, that is, the first NVP of the NVP cluster is obtained. At this time, each NVP in the NVP cluster has a right to apply for becoming a master NVP, so that if any NVP in the NVP cluster wants to apply for becoming a master NVP, a second message may be broadcast to the NVP cluster to apply for becoming a master NVP of the NVP cluster.

(2) And any NVP in the at least one NVP receives the second message broadcasted by other NVPs within a first preset time after the second message is broadcasted.

The first preset time duration can be preset, and the first preset time duration can be set to be larger, so that it is ensured that any one NVP can receive the second message carrying the node identifier of the NVP broadcast by each of the other NVPs. For example, the first preset time period may be set to 5 minutes.

In this case, after broadcasting the second message, any one of the at least one NVP may receive the second message broadcasted by other NVPs, so as to know which NVPs in the NVP cluster want to apply for becoming the master NVP.

(3) And any NVP in the at least one NVP compares the node identification of the NVP with the node identification carried by the second message broadcasted by other NVPs and received in the first preset time length to determine whether the NVP elects the owner.

Specifically, any one of the at least one NVP may compare its node identifier with the node identifiers carried in the second messages broadcast by other NVPs received within the first preset time period according to a preset election condition, so as to determine whether it elects the primary NVP.

The preset election condition is a condition for judging whether the main NVP can be elected. The preset election conditions can be preset, and the preset election conditions can be set by technicians according to use requirements. For example: the preset election conditions may be: and identifying the minimum NVP elected to the main NVP by the node in the NVP cluster. Another example is: the preset election conditions may be: and identifying the maximum NVP elected as the main NVP by the node in the NVP cluster. Of course, the preset election condition may also be set as another condition for judging whether the main NVP can be elected, which is not limited in this embodiment of the application.

For example: the preset election conditions are as follows: and identifying the minimum NVP elected to the main NVP by the node in the NVP cluster. The node identification of one NVP is 04, the NVP receives the second messages broadcasted by three NVPs within the first preset time duration, the node identification carried in the second message broadcasted by the first NVP in the three NVPs is 05, the node identification carried in the second message broadcasted by the second NVP in the three NVPs is 06, and the node identification carried in the second message broadcasted by the third NVP in the three NVPs is 07. Then, the NVP compares the node identification (04) of the NVP with the node identifications (05, 06 and 07) carried in the second messages broadcasted by the three NVPs, and judges whether the node identification of the NVP meets the preset election condition. Because the node identifiers of the NVPs are all smaller than the node identifiers carried in the second messages broadcast by the three NVPs, the NVP determines that the NVP can elect the master NVP.

(4) If any NVP in the at least one NVP determines that the NVP elects the main NVP, a second notification message is sent to other NVPs in the same NVP cluster every second preset time; and if determining that the NVP can not be elected as the main NVP, ending the operation of applying for becoming the main NVP.

The second preset time duration may be preset, and the second preset time duration may be set to be shorter, so as to ensure that the main NVP can continuously send the second notification message to other NVPs in the same NVP cluster, so that the other NVPs in the same NVP cluster can always know which main NVP of the NVP cluster is.

The second notification message is used for indicating that the NVP sending the second notification message is elected as the master NVP of the NVP cluster, and is used for indicating that the NVP receiving the second notification message is the slave NVP of the NVP cluster.

In this case, if any one of the at least one NVP determines that it elects its own master NVP, it sends a second notification message to other NVPs in the same NVP cluster to notify that other NVPs in the same NVP cluster have elected their own master NVP, and at this time, the other NVPs in the same NVP cluster are slave NVPs. If the NVP can not be elected by the user, the operation of applying for becoming the main NVP is finished, namely the second message is not broadcasted, and the election of the main NVP is quitted. Therefore, after the entire NVP cluster is started, the main NVP of the NVP cluster is selected for the first time.

Optionally, the second notification message may carry the node identifier of itself (i.e., the primary NVP). In this case, if any one of the NVP clusters receives the second notification message from the NVP, the node identifier of the NVP cluster may be compared with the node identifier carried in the second notification message to determine whether the NVP identified by the node identifier carried in the second notification message can continue to elect the master NVP; if the slave NVP determines that the NVP identified by the node identifier carried by the second notification message cannot continuously elect the master NVP, the slave NVP sends a request message carrying the node identifier of the slave NVP to the current master NVP (namely, the NVP sending the second notification message); after receiving the request message sent by the slave NVP, the current master NVP compares the node identifier of the master NVP with the node identifier carried in the request message to determine whether the master NVP can be continuously elected by the master NVP; if the current master NVP determines that the current master NVP cannot continuously elect the master NVP, a confirmation message is sent to the slave NVP; after receiving the confirmation message from the NVP, determining that the NVP elects the owner of the NVP, and broadcasting a second notification message to other NVPs in the NVP cluster.

The request message is used for indicating the slave NVP sending the request message to apply for becoming the master NVP. The request message carries the node identifier of the slave NVP sending the request message.

The acknowledgement message is used to indicate that the current master NVP acknowledges that itself cannot continue electing the master NVP, and to indicate that the slave NVP sending the request message can elect the master NVP.

After receiving the second notification message from the NVP, when comparing the node identifier of the node with the node identifier carried in the second notification message, the node identifier of the node with the node identifier carried in the second notification message may be compared according to a preset election condition, so as to determine whether the NVP identified by the node identifier carried in the second notification message can continue to elect the master NVP. Specifically, after the slave NVP compares the node identifier of the slave NVP with the node identifier carried in the second notification message, if it is determined that the node identifier carried in the second notification message does not meet the preset election condition, it may be determined that the NVP identified by the node identifier carried in the second notification message cannot continue to elect the master NVP; if the node identifier of the slave NVP is determined not to meet the preset election condition, it may be determined that the NVP identified by the node identifier carried in the second notification message can continue to elect the master NVP, and at this time, it is also determined that the node identifier of the slave NVP is still the slave NVP.

Similarly, after receiving the request message sent by the slave NVP, the current master NVP may also compare the node identifier of itself with the node identifier carried in the request message according to a preset election condition, so as to determine whether itself can continue to elect the master NVP. Specifically, after the current primary NVP compares the node identifier of the primary NVP with the node identifier carried in the request message, if it is determined that the node identifier carried in the request message does not meet the preset election condition, it may be determined that the primary NVP can continue to be elected by the primary NVP; and if the node identifier of the node is determined not to meet the preset election condition, the node identifier of the node can be determined not to be elected to the main NVP continuously.

In this case, the NVP cluster can elect a main NVP that better meets the preset election condition, that is, an NVP that is more qualified to elect the main NVP.

For example: the node identifier carried in the second notification message is 03, and the node identifier of one slave NVP is 02. One of the NVP clusters receives the second notification message from the NVP, and then compares the node identifier (02) of the NVP cluster with the node identifier (03) carried in the second notification message, and determines that the NVP identified by the node identifier (03) carried in the second notification message (i.e., the current primary NVP) cannot continuously elected the primary NVP, and then the NVP sends a request message carrying the node identifier (02) of the NVP cluster to the current primary NVP. After receiving the request message, the current main NVP compares the node identification (03) of the main NVP with the node identification (02) carried in the request message, and determines that the main NVP cannot be elected continuously. The current primary NVP may then send an acknowledgement message to this NVP acknowledging that it cannot continue electing the primary NVP. After the NVP receives the acknowledgement message, it determines that the NVP elects the owner of the NVP, and broadcasts a second notification message to other NVPs in the NVP cluster to notify the other NVPs in the NVP cluster that the owner of the NVP is elected.

It is noted that, if the main NVP in one NVP cluster is in the down state, the NVP cluster needs to reselect a new main NVP.

Because the main NVP of the NVP cluster is in the down state, the main NVP cannot communicate with the corresponding VP, that is, the NVP cluster in which the main NVP cluster is located cannot communicate with the corresponding VP, and the main NVP cannot communicate with other NVPs in the NVP cluster in which the main NVP cluster is located. Therefore, the NVP cluster needs to re-elect a new master NVP to maintain the communication connection between the NVP cluster and the corresponding VP, that is, to ensure that the NVP cluster can receive the message sent by the corresponding VP, and to ensure the communication connection between the master NVP and the slave NVP in the NVP cluster.

Specifically, if the main NVP in one NVP cluster is in a downtime state, the operation of reselecting a new main NVP by the NVP cluster can be realized through the following steps (1) to (5).

(1) And if the slave NVP in any one NVP cluster does not receive the second notification message within the third preset time length, broadcasting the second message to other NVPs in the same NVP cluster.

The third preset time duration may be preset, and the third preset time duration is greater than or equal to the second preset time duration, so that the slave NVP has sufficient time to receive the second notification message sent by the master NVP of the NVP cluster.

In this case, if the slave NVP does not receive the second notification message within the third preset time period, which indicates that the master NVP of the NVP cluster does not send the second notification message within the second preset time period, it may be determined that the master NVP of the NVP cluster is likely to be in the downtime state. In order to maintain the communication connection between the NVP cluster and the corresponding VP, the slave NVP may broadcast a second message to other NVPs in the same NVP cluster to request for the master NVP to become the NVP cluster.

(2) If any NVP in the NVP cluster receives the second message broadcasted by the slave NVP, the node identification of the NVP cluster is compared with the node identification carried by the second message broadcasted by the slave NVP, and the second message is broadcasted to other NVPs in the same NVP cluster under the condition that the slave NVP cannot select the master NVP.

After receiving the second message broadcasted from the NVP, an NVP may compare its own node identifier with the node identifier carried in the second message according to a preset election condition to determine whether it is itself or the slave NVP cannot elect the master NVP. Specifically, after comparing the node identifier of one NVP with the node identifier carried in the second message, if it is determined that the node identifier carried in the second message does not meet the preset election condition, it may be determined that the slave NVP cannot elect the master NVP; and if the node identifier of the node is determined not to meet the preset election condition, determining that the node identifier of the node cannot be elected to the main NVP.

After the slave NVP broadcasts the second message, any of the other NVPs in the NVP cluster will receive the second message broadcast by the NVP. And then the NVP can compare the node identification of the NVP with the node identification carried in the second message broadcasted by the slave NVP according to a preset election condition to determine whether the NVP can select the master NVP or not. If it is determined that the slave NVP cannot elect the master NVP, the slave NVP may broadcast a second message to other NVPs in the same NVP cluster to apply itself to become the master NVP. If the NVP can not elect the main NVP, the NVP can end the operation of broadcasting the second message, namely quitting the election of the new main NVP in the NVP cluster.

(3) Any NVP in the NVP cluster receives the second message broadcasted by other NVPs within a first preset time after the second message is broadcasted newly.

After the second message is newly broadcast by any one of the NVPs in the NVP cluster, the second message broadcast by other NVPs can be received, so that it is known which NVPs in the NVP cluster apply for becoming the master NVP.

(4) Any NVP in the NVP cluster compares the node identification of the NVP cluster with the node identification carried by the second message broadcast by other NVPs received within the first preset time length to determine whether the NVP cluster elects the owner of the NVP cluster.

Specifically, the operation in step (4) is similar to the operation in which any one of the NVPs compares its node identifier with the node identifiers carried in the second messages broadcast by other NVPs received within the first preset time period, so as to determine whether its own selected NVP is selected, which is not described herein again.

(5) And if any NVP in the NVP cluster determines that the NVP elects the main NVP, sending a second notification message to other NVPs in the same NVP cluster every second preset time.

In this case, if any one of the NVPs in the NVP cluster determines that the NVP itself elects the master NVP, a second notification message is sent to other NVPs in the same NVP cluster to notify that the other NVPs in the same NVP cluster themselves elected the master NVP, and at this time, the other NVPs in the same NVP cluster are slave NVPs. Therefore, when the main NVP in one NVP cluster is down, the new main NVP is selected again.

Step 202: if each NVP in each NVP cluster in the m NVP clusters receives the first message, the block carried by the first message is stored to the block chain, and the first message is sent to the adjacent NVP in the same NVP cluster.

Each NVP may store the chunk carried by the first message to its own chain of chunks.

The first NVP in each of the m NVP clusters receives the first message sent by the corresponding VP first, and then the first NVP may store the block carried in the first message to its own block chain and send the first message to the adjacent NVP in the same NVP cluster. After that, after any one of the NVPs in the same NVP cluster adjacent to the first NVP receives the first message sent by the first NVP, the block carried in the first message may also be stored in its own block chain, and the first message is sent to the adjacent NVP in the same NVP cluster. By analogy, each NVP in the same NVP cluster stores the block carried by the first message to its own block chain, and sends the first message to the adjacent NVPs in the same NVP cluster.

Alternatively, step 202 may be implemented by the GOSSIP protocol. That is, after receiving the first message, the first NVP in each NVP cluster broadcasts the first message to each NVP in the NVP cluster via the GOSSIP protocol, so that each NVP in the NVP cluster stores the block carried in the first message to its own block chain.

In this case, the first message is propagated through the GOSSIP protocol, and then each NVP in each NVP cluster stores the block carried in the first message to its own block chain, so as to synchronize the block added in the corresponding VP to each NVP in each NVP cluster.

Optionally, each NVP in each of the m NVP clusters has a node list, and the node list includes node identifiers of adjacent NVPs in the same NVP cluster.

The node list in one NVP is used to indicate NVPs adjacent to this NVP, for example, the node identification of one NVP is 02, and the node identifications of this NVP adjacent NVP are 01, 03, 04 as can be known from the node list in this NVP as shown in table 1 below.

TABLE 1

In the embodiment of the present application, table 1 is taken as an example to exemplarily illustrate a node list of an NVP, and table 1 does not limit the embodiment of the present application.

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

(1) If any one of the NVPs in each of the m NVP clusters receives the first message, the block carried by the first message is stored in its own block chain.

In this case, after receiving the first message, an NVP stores the block carried in the first message to its own block chain, that is, the block added in the corresponding VP is synchronized to the NVP.

Optionally, the first message generated by the VP may also carry a message sequence number of the first message. In this case, if any one NVP in each of the m NVP clusters receives the first message, it may first determine whether the message sequence number of the first message received latest is greater than the message sequence number of the historical first message received last time; under the condition that the message sequence number of the first message received latest is larger than the message sequence number of the historical first message received last time, the block carried by the first message is stored to the block chain of the block chain; and discarding the first message received latest when the message sequence number of the first message received latest is less than or equal to the message sequence number of the historical first message received last time.

The message sequence number of the first message is used to uniquely identify the first message and the VP generated message sequence number of the first message is incremented.

The historical first message is a first message that the NVP has received before the most recently received first message.

If the message sequence number of the first message received latest by the NVP is greater than the message sequence number of the historical first message received last time, it is described that the first message received latest is newly generated by the corresponding VP, that is, the block carried in the first message received latest is newly added to the block chain by the corresponding VP, and it may be determined that the block carried in the first message received latest is a block not stored in the block chain of the NVP. Thus, the NVP can store the block carried in the first message to the block chain to achieve synchronization of the block.

If the message sequence number of the first message received latest by the NVP is less than or equal to the message sequence number of the historical first message received last time, it is described that the first message received latest is not the first message newly generated by the corresponding VP, that is, the block carried in the first message received latest is likely to have been stored by the block chain of the NVP, so that the block does not need to be stored any more, and therefore the first message received latest can be discarded.

In this case, the block stored in the block chain of any one of the NVPs in each of the m NVP clusters is the newly added block in the corresponding VP. Therefore, the blocks stored in the block chain of any one NVP in each NVP cluster in the m NVP clusters can be ensured not to be repeated.

(2) If the first message received by any NVP in each of the m NVP clusters is from the corresponding VP, adding a node identifier of the first message to update the first message; and sending the updated first message to the NVP identified by each node identifier in the node list of the node.

The first message is used to indicate that the NVP identified by the node identifier carried by the first message has received the first message, that is, indicate that the NVP identified by the node identifier carried by the first message has stored the block to block chain carried by the first message.

The NVP adds its own node id to the first message to update the first message, so that the next NVP receiving the updated first message can be guaranteed to know which NVPs have received the first message.

If the first message received by one NVP is from the corresponding VP, which indicates that the NVP is the first NVP, it is known that other NVPs in the NVP cluster at this time, except the NVP, have not received the first message, that is, the NVPs adjacent to the NVP have not received the first message, and then the NVP may send the updated first message to the NVP identified by each node identifier in its node list after updating the first message.

(3) If the first message received by any NVP in each NVP cluster in the m NVP clusters is from the NVP in the same NVP cluster, determining the node identification carried by the first message as a target node identification; adding a node identifier of the node to the first message to update the first message; and sending the updated first message to the NVPs identified by each node identification except the target node identification in the node list of the NVP.

If the first message received by one NVP is from an NVP in the same NVP cluster, which indicates that the NVP is the second NVP, it is known that at least part of NVPs (including the first NVP) in other NVPs except the NVP in the NVP cluster at that time have received the first message. Therefore, the first message received by the NVP already carries a node identifier (i.e., a target node identifier), and the NVP identified by the target node identifier is the NVP that has received the first message. Such that this NVP may not send the updated first message to the NVP identified by the target node identification. That is, after updating the first message, the NVP may send the updated first message to the NVP identified by each node identifier in its own node list except the target node identifier.

Therefore, each NVP in each NVP cluster in the m NVP clusters can not receive the repeated first message, and blocks stored in the block chain of each NVP can not be repeated.

Optionally, the node list of one NVP may further include an egress interface corresponding to the node identifier of the adjacent NVP.

The egress interface is a network interface for an NVP to send a first message from the NVP when the NVP sends the first message to an NVP identified by a node identification in the node list. Illustratively, the node of one NVP is identified as 02, and the node of the NVP's node list including three neighboring NVPs of the NVP is identified as 01, 03, 04. The node identifications of the three adjacent NVPs included in the node list correspond to the egress interfaces as shown in table 2 below.

TABLE 2

In the embodiment of the present application, table 2 is taken as an example to exemplarily illustrate a node list of an NVP, and table 2 does not limit the embodiment of the present application.

In this case, the operation of sending the updated first message by one NVP to NVPs identified by each node identifier in the node list of the NVP except the target node identifier may be: the NVP acquires an outgoing interface corresponding to each node identification except the target node identification from a node list of the NVP; for any one node identifier in each node identifier except the target node identifier in the node list of the NVP, the NVP sends the updated first message to the NVP identified by the node identifier through the outgoing interface corresponding to the node identifier.

Thus, each node identifier in the node list corresponds to one egress interface, and any one NVP in each of the m NVP clusters can send the updated first message to the adjacent NVP from the egress interface corresponding to the node identifier of the adjacent NVP. Therefore, network congestion can be avoided, and the message transmission rate is improved.

Optionally, any one of the NVPs in each of the m NVP clusters may include a first module and a second module, where the first module is configured to communicate with an adjacent NVP in the same NVP cluster, and is further configured to communicate with a corresponding VP. The second module is used for processing the blocks carried in the first message.

In this case, the operation of step 202 may be: if the first module receives the first message, the block carried by the first message is sent to the second module; after receiving the block sent by the first module, the second module stores the block to a block chain of the second module; if the first message received by the first module is from the corresponding VP, the first module adds the node identification 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 the NVP identified by each node identification in the node list of the first module; if the first message received by the first module is from the NVP in the same NVP cluster, the first module determines the node identifier carried by 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 the NVP identified by the other node identifiers except the target node identifier in the node list of the first module.

Thus, the first message is received, updated and sent by the first module, and the block sent by the first module is received by the second module and stored to its own block chain. That is, the first module and the second module have respective division of work, which can improve the efficiency of block synchronization.

The operations executed by the first module and the second module are similar to the operations executed by the NVP when receiving the first message, storing the block carried by the first message to the block chain, and sending the first message to the adjacent NVPs in the same NVP cluster, and are not described herein again.

Optionally, a 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.

The check message is used to indicate the NVP to check whether the block stored in its own block chain is correct, and the check message carries the first target block identifier and the first target block hash value. The first target block mark is the block mark of the block which is processed by the VP in a consensus mode, and the first target block hash value is the block hash value of the block which is processed by the VP in the consensus mode.

Alternatively, the VP may generate a check message and send the check message to the first NVP in the corresponding NVP cluster in two cases.

In the first case, after completing the consensus on one block and adding the block to the block chain, and sending the first message carrying the block to the first NVP in the corresponding NVP cluster, the VP may send the check message to the first NVP in the corresponding NVP cluster again, 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.

In this case, after sending the first message carrying the block to the first NVP in the corresponding NVP cluster, the check message for the block is sent to the first NVP in the corresponding NVP cluster. Therefore, each NVP in the corresponding NVP cluster can receive the check message corresponding to the block when storing one block, and each NVP can check each block stored in the block chain of the NVP cluster, so that the correctness of the block stored in the block chain of the NVP cluster is ensured.

In the second case, after completing the consensus on a block and adding the block to the block chain, and sending the first message carrying the block to the first NVP in the corresponding NVP cluster, if the block is newly generated after performing the block rollback operation, the VP may send the check message for the block to the first NVP in the corresponding NVP cluster. If this block is not newly generated after performing the block rollback operation, the VP may not send a check message for this block to the first NVP in the corresponding NVP cluster.

Since the block identifier of the block newly generated after the block rollback operation is performed is the same as the block identifier of the block generated last before the block rollback operation is performed, the VP performs the block rollback operation, which may cause the VP to send two blocks with the same block identifier to the first NVP of the corresponding NVP cluster, so that each NVP in the corresponding NVP cluster may receive two blocks with the same block identifier, but each NVP does not know which block is the correct block, which may cause a block chain of each NVP to have a short fork, i.e., a next block of one block in the block chain may be divided into two blocks with the same block identifier. In this case, when the next block of the blocks identified by the two identical block identifiers arrives, the parent block hash value of the next block needs to be compared with the block hash values of the two blocks to determine which of the two blocks is the parent block of the next block in order to store the next block to the block chain.

In this case, after the VP generates the latest chunk after performing the chunk rollback operation, it may send a check message for the chunk to the first NVP in the corresponding NVP cluster. After each NVP in the corresponding NVP cluster receives the check message, it can check which block is correct which block has the same identification with two blocks stored in the block chain. This ensures the correctness of the blocks stored in the block chain. Since the VP sends the check message to the first NVP in the corresponding NVP cluster only when the newest block is generated after performing the block rollback operation, the block chain system resources can be saved.

Further, after any one of the NVPs in each of the m NVP clusters receives the check message generated by the corresponding VP, the first chunk can be searched in its own chunk chain; and if the first block is found in the block chain of the first block, deleting the first block from the block chain of the first block under the condition that the block hash value of the first block is different from the first target block hash value.

The first block is a block with the same block identifier as the first target block identifier.

After receiving the check message generated by the corresponding VP, one NVP searches for the first block in its own block chain, that is, searches for a block with a block identifier that is the same as the first target block identifier in its own block chain. And if the first block is found in the block chain of the first block, comparing the block hash value of the first block with the first target block hash value. If the hash value of the first block is the same as the first target hash value, which indicates that the first block is correct, no processing is required. If the hash value of the first chunk is different from the first target hash value, which indicates that the chunks corresponding to the first chunk and the first target hash value are different, it may be determined that the first chunk is incorrect, that is, the first chunk is likely to be a chunk that has been rolled back, so the first chunk may be deleted from its own chunk chain.

Illustratively, after one VP completes the consensus on the block with block identification 50, a first message carrying the block with block identification 50 is sent to the first NVP in the corresponding NVP cluster. But after completing the consensus on the block, the VP rolls back the block, and after performing the block roll-back operation, the VP continues to generate a block with a block identifier of 50 and completes the consensus on the block. This VP will then send a first message to the first NVP in the corresponding NVP cluster carrying the newly generated block with this block id 50, and will send a check message for this block. In this case, each NVP in the corresponding NVP cluster will receive two blocks with block id 50, and then the block chain of the NVP cluster will correspondingly store the two blocks with block id 50, and at this time, the previously stored block with block id 50 can be deleted according to the check message.

For example: FIG. 3 is a schematic diagram of blocks stored in a block chain of NVPs. Referring to fig. 3, fig. 3 includes a block chain 300 and a plurality of blocks 301 stored in the block chain 300. The plurality of blocks 301 includes two blocks 301 with block number 50, and the two blocks 301 with block number 50 cause a temporary bifurcation of the block chain 300. An NVP receives a check message sent by a corresponding VP, where the first target block id carried in the check message is 50. The NVP can search for block 301 with block id 50 from its own blockchain 300, and then search for two blocks 301 with block id 50. Then, the NVP determines that the block hash value of the previously stored block 301 with block identifier 50 in the two blocks 301 with block identifier 50 is different from the first target block hash value carried in the check message, and then the NVP may delete the block 301 with block identifier 50 in its own blockchain 300, so that all blocks 301 stored in the blockchain 300 of the NVP are correct, and at this time, the blockchain 300 of the NVP may be as shown in fig. 4, and all blocks 301 stored in the blockchain 300 shown in fig. 4 are correct.

As described above in detail, after each NVP in each NVP cluster in the m NVP clusters receives the first message, the operation performed by each NVP in each NVP cluster in the m NVP clusters can store the block carried in the first message into its block chain, so that each NVP in each NVP cluster in the m NVP clusters is ensured to synchronize the block stored in the multiple VPs to its block chain.

It is to be noted that any one of the NVPs in each of the m NVP clusters may not receive the block for a long time due to network congestion or network partition, and then the NVP cannot synchronize the block. The operations that need to be performed in this case will be described in detail below to solve the problem that the blocks cannot be synchronized due to network reasons.

Specifically, each NVP in each of the m NVP clusters sends a block chain state to other adjacent NVPs in the same NVP cluster every fourth preset time, where the block chain state includes a node identifier of the block chain and a block identifier of a latest block in the block chain; and if no block is received within a fifth preset time length, under the condition that the block identifier of the latest block in the block chain of the NVP is smaller than the block identifier in the target block chain state, acquiring a block with a block identifier larger than the block identifier of the latest block in the block chain of the NVP from the block chain of the target NVP identified by the node identifier in the target block chain state, and storing the acquired block to the block chain of the NVP.

The fourth preset duration can be preset and can be set by a technician as required. For example, the fourth preset time period may be set to 1 minute.

The block chain state of an NVP is used to indicate the situation of the latest block stored in its block chain. The target block chain state is a block chain state sent by an adjacent NVP received by an NVP, and if the NVP has a plurality of adjacent NVPs, the NVP can receive a plurality of target block chain states.

The fifth preset duration may be preset, and the fifth preset duration may be set to be greater, so as to ensure that there is sufficient time to receive the block. For example, the fifth preset time period may be set to 2 minutes.

The target NVP identifies the NVP for a node in a target block chain state where the block identification in the target block chain state received by the NVP is greater than the block identification of the latest block in the block chain of the NVP.

Each NVP in each NVP cluster in the m NVP clusters sends a block chain state to other adjacent NVPs in the same NVP cluster every fourth preset time, and then each NVP can know the latest block stored in the block chain of the adjacent NVP. If an NVP does not receive a block within the fifth preset duration, which indicates that the NVP does not receive a block within a long time, the NVP may check whether a block identifier larger than the block identifier of the latest block in its own block chain exists in any one of the target block chain states, and if a block identifier in one of the target block chain states is larger than the block identifier of the latest block in its own block chain, the NVP may obtain a block whose block identifier is larger than the block identifier of the latest block in its own block chain from the block chain of the target NVP identified by the node identifier in the target block chain state. The acquired blocks can be stored in the block chain of the self block chain, so that the synchronization of the blocks which are not stored in the block chain of the self block chain is realized. If the block id in each of the target block chain states is less than or equal to the block id of the latest block in the block chain of the NVP, the NVP continues to wait for receiving the block.

Therefore, under the condition that one NVP does not receive the block for a long time, the block which is larger than the block identifier of the latest block in the block chain of the NVP is directly obtained from the block chain of the adjacent target NVP, so that system resources can be saved, block synchronization time is saved, and block synchronization efficiency is improved.

Optionally, the blockchain state further includes a blockhash value of a newest blockin the blockchain, in this case, from the blockchain of the target NVP identified by the node identifier in the target blockchain state, the operation of obtaining the block with the blockidentity larger than the blockidentity of the newest blockin the blockchain of the block chain may be: the NVP sends a third message to the target NVP identified by the node identification in the target block chain state; and if the target NVP receives the third message, searching the second block from the block chain of the target NVP, and if the second block is searched from the block chain of the target NVP, sending all the blocks of which the block identifiers in the block chain are greater than the third target block identifier and less than or equal to the second target block identifier to the NVP under the condition that the block hash value of the second block is the same as the second target block hash value.

Here, the target block chain status is a target block chain status of block identities in the plurality of target block chain statuses that is greater than the block identity of the newest block in the block chain of the NVP.

The third message is used to instruct the target NVP to send the block of the block chain greater than the block identifier of the newest block in the block chain of the NVP to the 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 id is a block id in the target block chain state, i.e. a block id of a block not stored in the block chain of the NVP. The second target block hash value is a block hash value in the target block chain state, that is, a block hash value of a block not stored in the block chain of the NVP. The third target block id is the block id of the newest block in the block chain of this NVP.

The second block is a block having the same block id as the second target block id.

In this case, after receiving the third message, the target NVP searches first whether a block (i.e., a second block) with a block identifier that is the same as the second target block identifier exists in its own block chain, and if the second block is found to exist in its own block chain, compares the block hash value of the second block with the second target block hash value carried 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 that are not stored in the block chain of the NVP, in this case, the block identifier in the block chain of the target NVP is greater than the block identifier (i.e., the third target block identifier) of the latest block in the block chain of the NVP, and all blocks that are less than or equal to the block identifier (i.e., the second target block identifier) of the second block are the blocks that are not stored in the block chain of the NVP. The target NVP may send all blocks in its own block chain whose block id is greater than the third target block id and less than or equal to the second target block id to the NVP. After receiving the block sent by the target NVP, the NVP may store the received block to its own block chain to synchronize the block that is not stored in its own block chain, thereby ensuring that the block stored in its own block chain is the same as the block stored in the block chain of other NVPs.

Optionally, during the operation of the block chain system, an NVP may be newly added to any one of the m NVP clusters, and a block chain of the newly added NVP may not store a block yet, so that the newly added NVP may synchronize all blocks stored in the block chains of other NVPs in the NVP cluster. In this case, the newly added NVP may perform the above-mentioned step of acquiring all blocks from the target NVP, so as to synchronize blocks stored in the block chains of other NVPs in the NVP cluster.

The above detailed description is made on the operation that any one NVP in each of the m NVP clusters actively acquires the non-stored blocks in its own block chain from the target NVP. In this embodiment of the application, when any one of the NVPs in each of the m NVP clusters finds that some blocks are missing in its own block chain, all the missing blocks are actively acquired from the target NVP (i.e., point-to-point pulling), so as to implement synchronization of all the missing blocks. Therefore, system resources can be saved, and the block synchronization efficiency can be improved.

In an embodiment of the present application, the blockchain system includes a plurality of VPs and m NVP clusters, m VPs of the plurality of VPs correspond to the m NVP clusters one to one, and each of the m NVP clusters includes a first NVP and at least one second NVP. The first NVP is an NVP communicating with a corresponding VP, and a network path is provided between the first NVP and each of the at least one second NVP, so that the first NVP in the NVP cluster can communicate with the corresponding VP and also communicate with other NVPs in the same NVP cluster. After the VPs finish the common identification of one block and add the block to the block chain, each VP in the m VPs sends a first message carrying the block to a first NVP in a corresponding NVP cluster. If each NVP in each of the m NVP clusters receives the first message, storing the block carried by the first message to a block chain, and sending the first message to an adjacent NVP in the same NVP cluster, so that each NVP in each NVP cluster can synchronize the block. In this case, each VP in the m VPs only needs to send the first message carrying the block to the first NVP in the corresponding NVP cluster, so that the block can be synchronized by each NVP in the corresponding NVP cluster, the pressure of the VP is reduced, and the block consensus efficiency can be improved.

Fig. 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 on the processor 50, the steps in the block synchronization method in the above embodiments being implemented when the processor 50 executes the computer program 52.

The computer device 5 may be a server cluster comprising a plurality of servers, which may be a blockchain system. Those skilled in the art will appreciate that fig. 5 is merely an example of the computer device 5 and does not constitute a limitation of the computer device 5, and may include more or less components than those shown, or combine some of the components, or different components, such as input output devices, network access devices, etc.

The Processor 50 may be a Central Processing Unit (CPU), and the Processor 50 may also be other general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic, discrete hardware components, etc. A general purpose processor may be a microprocessor or any conventional processor.

The memory 51 may in some embodiments be an internal storage unit of the computer device 5, such as a hard disk or a memory of the computer device 5. The memory 51 may be an external storage device of the computer device 5 in other embodiments, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), and the like provided on the computer device 5. Further, the memory 51 may also include both an internal storage unit of the computer device 5 and an external storage device. The memory 51 is used for storing an operating system, an application program, a Boot Loader (Boot Loader), data, and other programs. The memory 51 may also be used to temporarily store data that has been output or is to be output.

An embodiment of the present application further provides a computer device, where the computer device includes: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor, the processor implementing the steps of any of the various method embodiments described above when executing the computer program.

The embodiments of the present application also provide a computer-readable storage medium, where a computer program is stored, and when the computer program is executed by a processor, the steps in the above-mentioned method embodiments can be implemented.

The embodiments of the present application provide a computer program product, which when run on a computer causes the computer to perform the steps of the above-described method embodiments.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a separate product, may be stored in a computer readable storage medium. Based on such understanding, all or part of the processes in the above method embodiments may be implemented by a computer program, which may be stored in a computer readable storage medium and used by a processor to implement the steps of the above method embodiments. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, an executable file or some intermediate form, etc. The computer readable medium may include at least: any entity or apparatus capable of carrying computer program code to a photographing apparatus/terminal device, a recording medium, computer Memory, ROM (Read-Only Memory), RAM (Random Access Memory), CD-ROM (Compact Disc Read-Only Memory), magnetic tape, floppy disk, optical data storage device, etc. The computer-readable storage medium referred to herein may be a non-volatile storage medium, in other words, a non-transitory storage medium.

It should be understood that all or part of the steps for implementing the above embodiments may be implemented by software, hardware, firmware or any combination thereof. When implemented in software, may be implemented in whole or in part 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 computer-readable storage medium described above.

In the above embodiments, the descriptions of the respective embodiments have respective emphasis, and reference may be made to the related descriptions of other embodiments for parts that are not described or illustrated in a certain embodiment.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus/computer device and method may be implemented in other ways. For example, the above-described apparatus/computer device embodiments are merely illustrative, and for example, a module or a unit may be divided into only one logical function, and may be implemented in other ways, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted, or not implemented. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

Units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

The above-mentioned embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications and substitutions do not substantially depart from the spirit and scope of the embodiments of the present application and are intended to be included within the scope of the present application.

Claims

1. A block synchronization method applied to a blockchain system, the blockchain system including a plurality of common-node VPs and m non-common-node NVP clusters, m VPs of the plurality of VPs corresponding to the m NVP clusters one-to-one, each of the m NVP clusters including a first NVP and at least one second NVP, the first NVP being an NVP communicating with the corresponding VP, the first NVP and each of the at least one second NVP having a network path therebetween, the m being a positive integer, the method comprising:

2. The method of claim 1, wherein before each VP of the m VPs sends the first message carrying the block to the first NVP in the corresponding NVP cluster, further comprising:

selecting a master NVP by any one NVP cluster in the m NVP clusters in a dynamic election mode, wherein other NVPs except the master NVP in the NVP cluster are slave NVPs, the master NVP in the NVP cluster is the first NVP, and the slave NVP in the NVP cluster is the second NVP;

and the first NVP in the NVP cluster sends a first notification message to the corresponding VP, wherein the first notification message is used for indicating that the NVP sending the first notification message is elected as the main NVP of the NVP cluster.

3. The method of claim 2, wherein the electing a primary NVP by any one of the m NVP clusters by means of dynamic election comprises:

after the entire NVP cluster is started, each NVP in at least one NVP in the NVP cluster broadcasts a second message carrying a node identifier of the NVP cluster to other NVPs in the same NVP cluster, wherein the second message is used for indicating that the NVP identified by the node identifier carried by the second message applies for becoming a main NVP;

any one of the at least one NVP performs the following operations:

receiving the second message broadcasted by other NVPs within a first preset time after the second message is broadcasted;

comparing the node identification of the node with the node identifications carried by the second messages broadcast by other NVP (network video protocol) received within the first preset time length to determine whether the node identification of the node is elected as a main NVP;

and if the NVP elected by the NVP self is determined, sending a second notification message to other NVPs in the same NVP cluster every second preset time, wherein the second notification message is used for indicating that the NVP sending the second notification message elects the main NVP of the NVP cluster, and is used for indicating that the NVP receiving the second notification message is the slave NVP of the NVP cluster.

4. The method of claim 3, wherein the method further comprises:

if any slave NVP in the NVP cluster does not receive the second notification message within a third preset time, broadcasting the second message to other NVPs in the same NVP cluster, wherein the third preset time is longer than or equal to the second preset time;

if any NVP in one NVP cluster receives the second message broadcasted by one slave NVP, after comparing the node identification of the NVP with the node identification carried by the second message broadcasted by one slave NVP, determining that the slave NVP cannot select the master NVP, and broadcasting the second message to other NVPs in the same NVP cluster;

any NVP in the NVP cluster performs the following operations:

receiving the second messages broadcasted by other NVPs within the first preset time after the second message is broadcasted newly;

if it is determined that the NVP elects itself, and sending the second notification message to other NVPs in the same NVP cluster every other second preset time.

5. The method of claim 1, wherein the NVP has a node list that includes node identifications of neighboring NVPs in the same NVP cluster;

if each NVP in each of the m NVP clusters receives the first message, storing the block carried by the first message to a block chain, and sending the first message to an adjacent NVP in the same NVP cluster, including:

any one NVP in each of the m NVP clusters performs the following operations:

if the first message is received, storing the block carried by the first message to a block chain of the block;

if the received first message is from the corresponding VP, adding a node identifier of the first message to the first message so as to update the first message; sending the updated first message to the NVP identified by each node identifier in the node list;

if the received first message is from the NVP in the same NVP cluster, determining the node identification carried by the first message as a target node identification; adding a node identification of the node to the first message to update the first message; and sending the updated first message to the NVPs identified by each node identification in the node list except the target node identification.

6. The method of claim 5, wherein the first message generated by the VP further carries a message sequence number of the first message, wherein the message sequence number of the first message generated by the VP is incremented, and wherein before storing the blocks carried by the first message into its block chain, further comprising:

if the first message is received, under the condition that the message sequence number of the first message received latest is larger than the message sequence number of the historical first message received last time, the step of storing the block carried by the first message to the block chain of the block chain is executed.

7. The method of claim 1, wherein the method further comprises:

any one NVP in each of the m NVP clusters performs the following operations:

receiving a check message generated by a corresponding VP, wherein the check message carries a first target block identifier and a first target block hash value;

searching a first block in a block chain of the first block, wherein the first block is a block with a block identifier same as that of the first target block;

if the first block is found in the block chain of the first block, deleting the first block from the block chain of the first block under the condition that the block hash value of the first block is different from the first target block hash value.

8. The method of any one of claims 1-7, wherein the method further comprises:

each NVP in each NVP cluster in the m NVP clusters sends a block chain state to other adjacent NVPs in the same NVP cluster every fourth preset time, wherein the block chain state comprises a node identifier of the block chain state and a block identifier of a latest block in the block chain;

and any NVP in each of the m NVP clusters determines the received block chain state sent by the adjacent NVP as a target block chain state, if no block is received within a fifth preset time, under the condition that the block identifier of the latest block in the block chain of the NVP is smaller than the block identifier in the target block chain state, a block of which the block identifier is larger than the block identifier of the latest block in the block chain of the NVP is obtained from the block chain of the target NVP identified by the node identifier in the target block chain state, and the obtained block is stored in the block chain of the NVP.

9. The method of claim 8, wherein the blockchain state further includes a blockhash value of a latest chunk in the blockchain, and wherein the one NVP obtains, from the blockchain of the target NVP identified by the node identification in the target blockchain state, a chunk having a chunk identification greater than the chunk identification of the latest chunk in its blockchain, including:

the NVP sends a third message to the target NVP identified by the node identifier in the target block chain state, where 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 the block identifier in the target block chain state, the second target block hash value is the block hash value in the target block chain state, and the third target block identifier is the block identifier of the latest block in the block chain of the NVP;

if the target NVP receives the third message, searching a second block from its own block chain, where the second block is a block whose block identifier is the same as the second target block identifier, and if the second block is found from its own block chain, sending all blocks whose block identifiers are greater than the third target block identifier and less than or equal to the second target block identifier in its own block chain to the NVP under the condition that the block hash value of the second block is the same as the second target block hash value.

10. The method of any of claims 1-7, wherein the first message is a GOSSIP protocol GOSSIP message.

11. A blockchain system, the blockchain system comprising a plurality of common-identified nodes (VPs) and m non-common-identified Node (NVP) clusters, wherein m VPs in the VPs correspond to the m NVP clusters one-to-one, each NVP cluster in the m NVP clusters comprises a first NVP and at least one second NVP, the first NVP is an NVP communicating with the corresponding VP, a network path is arranged between the first NVP and each second NVP in the at least one second NVP, and m is a positive integer;

12. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program when executed by the processor implementing the method of any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program which, when executed by a processor, implements the method of any one of claims 1 to 10.