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

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, blockchain system, device and storage medium

technical field

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

Background technique

Due to the immutability of blockchain, blockchain technology has developed rapidly and has been widely used in various fields. In some scenarios, the blockchain system includes multiple consensus nodes (Validating Peer, VP) and multiple non-consensus nodes (None-Validating Peer, NVP). VP needs to participate in the block consensus process, NVP does not need to participate in the block consensus process, and in order to maintain the consistency of the data in the nodes, NVP needs to synchronize the blocks that have obtained the consensus of VP.

In the related art, each VP in the multiple VPs may directly communicate with the multiple NVPs. After multiple VPs complete the consensus on a block, the block is added to the blockchain. Afterwards, any VP can directly send the block to multiple NVPs in communication with the VP, so as to realize the synchronization of the block by each NVP in the multiple NVPs.

However, in the above method, if the number of blocks that the VP needs to agree on is increasing, and the number of NVPs communicating with the VP continues to grow, the VP will be very busy. This will lead to a large pressure on the VP, thus affecting the efficiency of block consensus.

SUMMARY OF THE INVENTION

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

In a first aspect, a block synchronization method is provided, applied to a blockchain system, the blockchain system includes a plurality of consensus nodes VP and m non-consensus node NVP clusters, m of the plurality of VPs VPs are in one-to-one correspondence with the m NVP clusters, each NVP cluster in the m NVP clusters includes a first NVP and at least one second NVP, and the first NVP is an NVP that communicates with the corresponding VP, so There is a network path between the first NVP and each of the at least one second NVP, the m is a positive integer, and the method includes:

After the multiple VPs complete the consensus on a block and add the block to the blockchain, each of the m VPs sends a message to the first NVP in the corresponding NVP cluster. there is the first message of the block;

If each NVP in each NVP cluster of the m NVP clusters receives the first message, it stores the block carried in the first message in the blockchain, and sends it to the same NVP cluster. The adjacent NVP sends the first message.

In this application, the blockchain system includes multiple VPs and m NVP clusters, m VPs in the multiple VPs are in one-to-one correspondence with the m NVP clusters, and each NVP cluster in the m NVP clusters includes the One NVP and at least one second NVP. The first NVP is an NVP that communicates with the corresponding VP, and there is a network path between the first NVP and each second NVP in the at least one second NVP, so the first NVP in the NVP cluster can both communicate with the corresponding VP It can also communicate with other NVPs in the same NVP cluster. After the multiple VPs complete the consensus on a block and add the block to the blockchain, each of the m VPs sends a message carrying the block to the first NVP in the corresponding NVP cluster. First news. If each NVP in each NVP cluster in 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 the adjacent NVP in the same NVP cluster. A message so that every NVP in every NVP cluster can sync 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 each NVP in the corresponding NVP cluster can perform the The synchronization of blocks reduces the pressure on VPs, which in turn can improve the efficiency of block consensus.

In a second aspect, a blockchain system is provided, the blockchain system includes multiple consensus node VPs and m non-consensus node NVP clusters, m VPs in the multiple VPs and the m NVPs The clusters are in one-to-one correspondence, and each NVP cluster in 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 the first NVP is connected to the There is a network path between each of the at least one second NVP, and the m is a positive integer;

Each VP in the m VPs is used for sending each VP to the first block in the corresponding NVP cluster after the multiple VPs complete the consensus on a block and add the block to the blockchain. An NVP sends the first message carrying the block;

Each NVP in each NVP cluster in the m NVP clusters is configured to, if receiving the first message, store the block carried in the first message in the blockchain, and send the same to the same NVP. Neighboring NVPs in the NVP cluster send the first message.

In a third aspect, there is provided a computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being executed by the processor When the above block synchronization method is implemented.

In a fourth aspect, a computer-readable storage medium is provided, where a computer program is stored in the computer-readable storage medium, and when the computer program is executed by a processor, the foregoing block synchronization method is implemented.

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

It can 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 relevant descriptions in the first aspect, which will not be repeated here.

Description of drawings

In order to illustrate the technical solutions in the embodiments of the present application more clearly, the following briefly introduces the drawings that are used in the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can also be obtained from these drawings without creative effort.

1 is a schematic structural diagram of a blockchain system provided by an embodiment of the present application;

2 is a flowchart of a block synchronization method provided by an embodiment of the present application;

3 is a schematic diagram of a blockchain provided by an embodiment of the present application;

4 is a schematic diagram of another blockchain provided by an embodiment of the present application;

FIG. 5 is a schematic structural diagram of a computer device provided by an embodiment of the present application.

Detailed ways

In order to make the objectives, technical solutions and advantages of the present application clearer, the embodiments of the present application will be further described in detail below with reference to the accompanying drawings.

It should be understood that the "plurality" mentioned in this application refers to two or more. In the description of this application, unless otherwise stated, "/" means or means, for example, A/B can mean A or B; "and/or" in this document is only an association relationship that describes an associated object, It means that there can be three kinds of relationships, for example, A and/or B, it can mean that A exists alone, A and B exist at the same time, and B exists alone. In addition, in order to facilitate the clear description of the technical solutions of the present application, words such as "first" and "second" are used to distinguish the same items or similar items with basically the same function and effect. Those skilled in the art can understand that words such as "first" and "second" do not limit the quantity and execution order, and the words "first" and "second" are not necessarily different.

Before explaining the embodiments of the present application in detail, the application scenarios of the embodiments of the present application are described first.

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

For example, in a consortium chain scenario, a consortium chain includes nodes of multiple provincial-level institutions and nodes of municipal-level units subordinate to some provincial-level institutions. Nodes (ie VPs) of multiple provincial institutions can participate in the block consensus process, while nodes (ie NVPs) of municipal units subordinate to a provincial institution do not need to participate in the block consensus process. In this case, the embodiments of this application The provided block synchronization method can be used in this scenario.

Specifically, each time any one of the nodes of the multiple provincial-level institutions receives a transaction sent by the client, a new block is generated, and the block is sent to the nodes of the remaining provincial-level institutions among the multiple provincial-level institutions , so that the nodes of the multiple provincial institutions can perform consensus processing on the block. After the nodes of the multiple provincial institutions complete the consensus processing of the block, the nodes of each provincial institution can send the block to the node of a municipal unit that communicates with itself among the multiple municipal units subordinate to it. piece. After that, after the node of this municipal unit receives the block, it stores the block in its own blockchain, and sends the block to the node of the adjacent municipal unit. By analogy, after the node of each municipal unit in the multiple municipal units subordinate to a provincial institution receives the block, it can store the block in its own blockchain and send it to its neighbors. The node of the municipal unit sends the block. In this way, the node of each municipal unit among the multiple municipal units subordinate to a provincial institution can synchronize the block to its own blockchain. In this case, the node of each provincial-level institution in the blockchain system only needs to send the block to the node of a municipal-level unit that communicates with itself, and then each municipal-level unit of the subordinate municipal-level units can be realized. The nodes of the unit synchronize the block, thus reducing the pressure on the nodes of multiple provincial institutions in the blockchain system and improving the efficiency of block consensus.

The following describes the relevant content of the blockchain system involved in the embodiments of the present application.

FIG. 1 is a schematic structural diagram of a blockchain system provided by an embodiment of the present application.

Referring to FIG. 1 , the 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 of the m NVP clusters 102 The NVP cluster 102 includes a plurality of NVPs 103, and m is a positive integer.

Multiple VP101s are nodes in the blockchain system that need to participate in the block consensus process. 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.

A plurality of VPs 101 can receive input information during normal operation, and maintain shared data within the blockchain system 100 based on the received input information. An information connection may exist between multiple VP101s, and information transmission may be performed between multiple VP101s through the information connection. For example, when any VP 101 in the blockchain system 100 receives the input information sent by the client, other VP 101 in the blockchain system 100 obtain the input information according to the consensus algorithm, and use the input information as shared data data in the storage.

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

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 only sends a message to one NVP103 in the corresponding NVP cluster 102, thereby 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.

In order to ensure the consistency of the 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 VP 101.

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 the NVP 103 that communicates with the corresponding VP 101 in the NVP cluster 102 where it is located, that is, the NVP 103 in the blockchain system 100 A VP 101 sends the input information to the first NVP 103 in the corresponding NVP cluster 102 . Among them, each NVP cluster 102 can add a new NVP 103 arbitrarily, and this will not affect the ability of the VP 101 in the blockchain system 100 to send messages to the corresponding NVP cluster 102, so each NVP in the blockchain system 100 The cluster 102 is highly scalable.

In addition, there is a network path between the first NVP 103 and each of the at least one second NVP 103 . The network path is used to indicate a data transmission channel between multiple NVPs 103 , and the first NVP 103 can transmit data to at least one second NVP 103 through the network path. There may be multiple NVP103s in the network path between the two NVP103s, and at this time, the two NVP103s can communicate indirectly. There may also be no other NVP103 in the network path between the two NVP103, that is, the two NVP103 can communicate directly, that is, the two NVP103 are adjacent NVP103.

After receiving the input information, the first NVP 103 of the plurality of NVPs 103 may transmit the input information through a network path, so that the remaining second NVP 103 of the plurality of NVPs 103 also receive the input information. In this way, each NVP 103 of the plurality of NVPs 103 will store the input information as data in the 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 an identical blockchain.

The blockchain system 100 has computer technologies such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm. The blockchain system 100 is a distributed shared ledger and database, which has the characteristics of decentralization, non-tampering, full traces, traceability, collective maintenance, openness and transparency, etc. These features ensure the shared openness, authenticity, integrity, security and reliability of the blockchain.

The multiple VPs 101 and m NVP clusters 102 in the blockchain system 100 can execute the block synchronization method described in the embodiment of FIG. 2 below to realize the The so-called shared data) is synchronized to each NVP 103 in the NVP cluster 102.

The block synchronization method provided by the embodiments of the present application will be explained in detail below.

FIG. 2 is a flowchart of a block synchronization method provided by an embodiment of the present application. This method can be applied to blockchain systems. Referring to Figure 2, the method includes the following steps.

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

The first NVP is an NVP that communicates with the corresponding VP in the same NVP cluster, and there is only one first NVP in the same NVP cluster, that is to say, each of the m VPs in the multiple VPs is directed to the corresponding NVP cluster. One of the NVPs sends the first message carrying the block.

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

Since each NVP in each NVP cluster in the m NVP clusters in the blockchain system provided by the embodiment of this application does not need to participate in the consensus process of the block, each VP in the m VPs can report to the corresponding NVP The cluster sends the first message carrying the block, so that the corresponding NVP cluster obtains and stores the block, thereby ensuring the consistency of the blockchain stored by each node in the blockchain system.

In this case, the first NVP in the NVP cluster corresponding to each VP of the m VPs can receive the first message carrying the block, and the first NVP in the corresponding NVP cluster can perform the operation on the block. storage. Moreover, each VP in 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 way, the pressure on each VP is relieved.

It is worth noting that, before each VP of the m VPs sends the first message carrying the block to the first NVP in the corresponding NVP cluster, any one of the m NVP clusters can also be elected. out a main NVP.

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

Further, after any one of the m NVP clusters elects a master NVP (ie, the first NVP), the first NVP in the NVP cluster may send a first notification message to the corresponding VP.

The first notification message is used to indicate that the NVP sending the first notification message has been elected as the master NVP of the NVP cluster where it is located. In this case, the NVP sending the first notification message is the NVP in the NVP cluster that communicates with the corresponding VP, then the corresponding VP can add the block to the blockchain after adding the block to the NVP cluster. The NVP of the NVP (ie, the first NVP) sends the first message, so as to ensure that the corresponding VP can only send the first message to the first NVP of this NVP cluster.

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

In this way, when the primary NVP elected by the NVP cluster goes down, a primary NVP will be re-elected to ensure that there is always a first NVP in an NVP cluster to communicate with the corresponding VP, thereby improving the activity of the NVP cluster .

Specifically, the operation of electing a master NVP by any one of the m NVP clusters through dynamic election may be implemented through the following steps (1) to (4).

(1) After an NVP cluster is started as a whole, each NVP in at least one NVP in the NVP cluster broadcasts a second message carrying its own node identifier to other NVPs in the same NVP cluster.

The overall startup of an NVP cluster means that each NVP in all NVPs in the NVP cluster is started, that is, each NVP starts to enter a working state.

The at least one NVP is an NVP in the NVP cluster that wants to apply to be the master NVP after the NVP cluster is started as a whole.

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

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

After an NVP cluster is started as a whole, the first NVP may not exist in the NVP cluster, that is, there is no NVP in the NVP cluster that communicates with the corresponding VP, then the corresponding VP adds the block to the blockchain after adding the block to the blockchain. , it will not know which NVP in this NVP cluster to send the first message carrying the block. Therefore, after the overall startup of the NVP cluster, it is necessary to elect a master NVP, that is, to obtain the first NVP of the NVP cluster. At this time, each NVP in this NVP cluster has the right to apply to become the master NVP, so if any NVP in this NVP cluster wants to apply to become the master NVP, it can broadcast a second message to this NVP cluster to apply for becoming the master NVP The primary NVP for this NVP cluster.

(2) Any one NVP of the at least one NVP receives the second message broadcast by other NVPs within a first preset time period after broadcasting the second message.

The first preset duration can be set in advance, and the first preset duration can be set to be larger, so as to ensure that any one NVP can receive the second message broadcasted by each NVP in other NVPs and carrying its own node identifier. For example, the first preset duration may be set to 5 minutes.

In this case, after broadcasting the second message, any one of the NVPs in 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) Any one of the at least one NVP compares its own node identifier with the node identifier carried in the second message broadcast by other NVPs received within the first preset time period to determine whether it is elected as the master NVP.

Specifically, any one NVP of the at least one NVP may compare its own node identifier with the node identifier carried in the second message broadcast by other NVPs received within the first preset duration to determine Whether it is elected as the main NVP.

The preset election condition is a condition for judging whether it is possible to be elected as the main NVP. The preset election conditions can be set in advance, and the preset election conditions can be set by technicians according to usage requirements. For example, the preset election condition may be: the NVP with the smallest node identification in the NVP cluster is elected as the master NVP. For another example, the preset election condition may be: the NVP with the largest node identification in the NVP cluster is elected as the master NVP. Certainly, the preset election condition may also be set to other conditions for determining whether the primary NVP can be elected, which is not limited in this embodiment of the present application.

For example, the preset election condition is: the NVP with the smallest node ID in the NVP cluster is elected as the master NVP. The node identifier of an NVP is 04, the NVP receives the second messages broadcast by three NVPs within the first preset duration, and the node identifier carried in the second message broadcast by the first NVP among the three NVPs is 05 , the node identifier carried in the second message broadcast by the second NVP among the three NVPs is 06, and the node identifier carried in the second message broadcast by the third NVP among the three NVPs is 07. After that, the NVP compares its own node ID (04) with the node IDs (05, 06, 07) carried in the second messages broadcast by the three NVPs received, and determines whether its own node ID meets the preset election conditions . Since the node identifiers of its own are smaller than the node identifiers carried in the second messages broadcast by the three NVPs, the NVP determines that it can be elected as the master NVP.

(4) If any NVP of the at least one NVP determines that it is elected as the primary NVP, it sends a second notification message to other NVPs in the same NVP cluster every second preset time period; if it is determined that it cannot be elected as the primary NVP, then End the application to become the main NVP.

The second preset duration can be set in advance, and the second preset duration can be set smaller to ensure that the master NVP can continuously send the second notification message to other NVPs in the same NVP cluster, so that other NVPs in the same NVP cluster can NVP always knows which main NVP of this NVP cluster is.

The second notification message is used to indicate that the NVP sending the second notification message has been elected as the master NVP of the NVP cluster where it is located, and is used to indicate that the NVP receiving the second notification message is the slave NVP of the NVP cluster where it is located.

In this case, if any NVP in the at least one NVP determines that it is elected as the master NVP, it sends a second notification message to other NVPs in the same NVP cluster to notify other NVPs in the same NVP cluster that it has been elected as the master NVP. , other NVPs in the same NVP cluster are slave NVPs. If it is determined that it cannot be elected as the main NVP, the operation of applying to become the main NVP is ended, that is, the second message is not broadcast, and the election of the main NVP is withdrawn. In this way, after an NVP cluster is started as a whole, the primary NVP of the NVP cluster is elected for the first time.

Optionally, the second notification message may carry the node identifier of itself (ie, the primary NVP). In this case, if any one of the NVP clusters receives the second notification message from the NVP, it can compare its own node ID with the node ID carried in the second notification message to determine the node carried in the second notification message. Whether the NVP identified by the identifier can continue to be elected as the master NVP; if the slave NVP determines that the NVP identified by the node identifier carried in the second notification message cannot continue to be elected as the master NVP, it will send the current master NVP (that is, the NVP that sent the second notification message) to the current master NVP. ) sends a request message carrying its own node ID; after the current master NVP receives the request message sent from the NVP, it compares its own node ID with the node ID carried in the request message to determine whether it can continue to be elected as the master NVP ; If the current master NVP determines that it cannot continue to be the master NVP, it will send a confirmation message to the slave NVP; after receiving the confirmation message, the slave NVP determines that it is elected as the master NVP, and broadcasts the second NVP to other NVPs in the NVP cluster. notification message.

The request message is used to instruct 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 that sends the request message.

The confirmation message is used to indicate that the current master NVP confirms that it cannot continue to be elected as the master NVP, and is used to indicate that the slave NVP sending the request message can be elected as the master NVP.

After receiving the second notification message from the NVP, when comparing its own node ID with the node ID carried in the second notification message, it can compare its own node ID with the node ID carried in the second notification message according to preset election conditions. A comparison is performed to determine whether the NVP identified by the node identifier carried in the second notification message can continue to be elected as the master NVP. Specifically, after the slave NVP compares its own node identifier 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 conditions, the second notification message can be determined. The NVP identified by the node identification carried in the NVP cannot continue to be elected as the master NVP; and if it is determined that the node identification of the slave NVP does not meet the preset election conditions, it can be determined that the NVP identified by the node identification carried in the second notification message can continue to be elected. The master NVP also determines that it is still a slave NVP at this time.

Similarly, after the current master NVP receives the request message sent from the NVP, it can also compare its own node ID with the node ID carried in the request message according to the preset election conditions to determine whether it can continue to be elected as the master. NVP. Specifically, after the current master NVP compares its own node identifier 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 conditions, it can determine that it can continue to be elected as the master NVP. ; and if it is determined that its own node identifier does not meet the preset election conditions, it can be determined that it cannot continue to be elected as the main NVP.

In this case, the NVP cluster can elect a master NVP that better meets the preset election conditions, that is, it can elect an NVP that is more qualified to be the master NVP.

For example, the node identifier carried in the second notification message is 03, and the node identifier of a slave NVP is 02. One of the NVP clusters receives the second notification message from the NVP, and then compares its own node ID (02) with the node ID (03) carried in the second notification message to determine the node ID carried in the second notification message (03) If the identified NVP (ie, the current master NVP) cannot continue to be elected as the master NVP, the NVP sends a request message carrying its own node identifier (02) to the current master NVP. After the current master NVP receives the request message, it compares its own node identifier (03) with the node identifier (02) carried in the request message, and determines that it cannot continue to be elected as the master NVP. After that, the current master NVP can send a confirmation message to this NVP to confirm that it cannot continue to be elected as the master NVP. After the NVP receives the confirmation message and determines that it is elected as the master NVP, it broadcasts a second notification message to other NVPs in the NVP cluster to notify other NVPs in the NVP cluster that it has been elected as the master NVP.

It is worth noting that if the master NVP in an NVP cluster is down, the NVP cluster needs to re-elect a new master NVP.

Because the main NVP of this NVP cluster is in the down state, the main NVP cannot communicate with the corresponding VP, that is, the NVP cluster where it is located cannot communicate with the corresponding VP, and the main NVP cannot communicate with other NVPs in the NVP cluster where it is located. to communicate. 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 messages sent by the corresponding VP, and to ensure that the master NVP in the NVP cluster Communication connection between NVP and slave NVP.

Specifically, if the master NVP in an NVP cluster is in a down state, the operation of re-electing a new master NVP in the NVP cluster may be implemented through the following steps (1) to (5).

(1) If any slave NVP in the NVP cluster does not receive the second notification message within the third preset time period, it broadcasts the second message to other NVPs in the same NVP cluster.

The third preset duration may be preset, and the third preset duration is greater than or equal to the second preset 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, indicating that the master NVP of this NVP cluster has not sent the second notification message within the second preset time period, it can determine the NVP cluster to which it belongs. The primary NVP is likely to be down. 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, so as to apply for becoming the master NVP of the NVP cluster.

(2) If any NVP in the NVP cluster receives the second message broadcast from the NVP, after comparing its own node identifier with the node identifier carried in the second message broadcast from the NVP, determine the slave. If the NVP cannot be elected as the master NVP, broadcast the second message to other NVPs in the same NVP cluster.

After an NVP receives the second message broadcasted by the slave NVP, it can compare its own node ID with the node ID carried in the second message according to the preset election conditions to determine whether it is itself or the slave NVP cannot be elected as the master NVP. . Specifically, after an NVP compares its own node ID with the node ID carried in the second message, if it is determined that the node ID carried in the second message does not meet the preset election conditions, it can be determined that the slave NVP cannot be elected as the master NVP; and if it is determined that its own node identifier does not meet the preset election conditions, it can be determined that it cannot be elected as the main NVP.

After the slave NVP broadcasts the second message, any one of the other NVPs in the NVP cluster will receive the second message broadcast by the NVP. Afterwards, the NVP can compare its own node identifier with the node identifier carried in the second message broadcasted by the slave NVP according to the preset election condition to determine whether it or the slave NVP cannot be elected as the master NVP. If it is determined that the slave NVP cannot be elected as the master NVP, the NVP may broadcast a second message to other NVPs in the same NVP cluster to apply for itself to be the master NVP. If it is determined that it cannot be elected as the master NVP, the NVP can end the operation of broadcasting the second message, that is, quit the election of the new master NVP in the NVP cluster.

(3) Any NVP in the NVP cluster receives the second message broadcast by other NVPs within the first preset time period after the latest broadcast of the second message.

After the latest broadcast of the second message, any NVP in the NVP cluster can receive the second message broadcast by other NVPs, so as to know which NVPs in the NVP cluster apply to become the master NVP.

(4) Any NVP in the NVP cluster compares its own node identification with the node identification carried in the second message broadcast by other NVPs received within the first preset time period to determine whether it is elected as the master NVP.

Specifically, the operation of step (4) and any one of the above-mentioned at least one NVP compares its own node identifier with the node identifier carried in the second message broadcast by other NVPs received within the first preset duration, The operation of determining whether it is elected as the main NVP is similar, and will not be repeated here.

(5) If any NVP in the NVP cluster determines that it is elected as the master NVP, it sends a second notification message to other NVPs in the same NVP cluster every second preset time period.

In this case, if any NVP in this NVP cluster determines that it is elected as the master NVP, it will send a second notification message to other NVPs in the same NVP cluster to notify other NVPs in the same NVP cluster that it has been elected as the new master. NVP, at this time other NVPs in the same NVP cluster are slave NVPs. In this way, when the primary NVP in an NVP cluster goes down, a new primary NVP is re-elected.

Step 202: If each NVP in each NVP cluster in the m NVP clusters receives the first message, it stores the block carried in the first message in the blockchain, and sends the message to the adjacent NVP cluster in the same NVP cluster. The NVP sends the first message.

Each NVP can store the block carried in the first message to its own blockchain.

The first NVP in each NVP cluster in the m NVP clusters first receives the first message sent by the corresponding VP, and the first NVP can store the block carried in the first message in its own blockchain, and send the first message to adjacent NVPs in the same NVP cluster. After that, after receiving the first message sent by the first NVP, any one of the NVPs adjacent to the first NVP in the same NVP cluster can also store the block carried in the first message to its own blockchain , and send the first message to adjacent NVPs in the same NVP cluster. By analogy, each NVP in the same NVP cluster will store the block carried in the first message in its own blockchain, and send the first message to adjacent NVPs in the same NVP cluster.

Optionally, step 202 may be implemented through the GOSSIP protocol. That is, after the first NVP in each NVP cluster receives the first message, it broadcasts the first message to each NVP in the NVP cluster where it is located through the GOSSIP protocol, so that each NVP in the NVP cluster where it is located sends the first message to the The blocks carried in the message are stored in their own blockchain.

In this case, if the first message is propagated through the GOSSIP protocol, each NVP in each NVP cluster will store the block carried in the first message in its own blockchain, thereby realizing the storage of the corresponding VP in the This added block is synchronized to each NVP in each NVP cluster.

Optionally, each NVP in each NVP cluster 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 an NVP is used to indicate the NVP adjacent to this NVP. For example, the node identifier of an NVP is 02. From the node list in this NVP shown in Table 1 below, we can know the NVP adjacent to this NVP. The node IDs are 01, 03, 04.

Table 1

In this embodiment of the present application, only the above Table 1 is taken as an example to illustrate the node list of one NVP, and the above Table 1 does not limit the embodiment of the present application.

In this case, the operation of step 202 can be implemented through the following steps (1)-(3).

(1) If any NVP in each NVP cluster of the m NVP clusters receives the first message, it stores the block carried in the first message in its own blockchain.

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

Optionally, the first message generated by the VP may further carry the message sequence number of the first message. In this case, if any NVP in each NVP cluster of the m NVP clusters receives the first message, it can first determine whether the message sequence number of the newly received first message is greater than the historical first message received last time. The message sequence number of the message; if the message sequence number of the newly received first message is greater than the message sequence number of the historical first message received last time, the block carried in the first message will be stored in its own blockchain. ; and in the case that the message sequence number of the newly received first message is less than or equal to the message sequence number of the historical first message received last time, the newly received first message is discarded.

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.

The historical first message is the first message that an NVP has received before the newly received first message.

If the message sequence number of the latest first message received by an NVP is greater than the message sequence number of the historical first message received last time, it means that the newly received first message is newly generated by the corresponding VP, that is, the latest received first message The block carried in a message is newly added to the blockchain by the corresponding VP, so it can be determined that the block carried in the newly received first message is an unstored area in the blockchain of this NVP. piece. In this way, the NVP can store the block carried in the first message to the blockchain to synchronize the block.

If the message sequence number of the latest first message received by an NVP is less than or equal to the message sequence number of the historical first message received last time, it indicates that the newly received first message is not the first message newly generated by the corresponding VP, that is, the latest The block carried in the received first message is likely to have been stored by the blockchain of the NVP, so there is no need to store the block, so the newly received first message can be discarded.

In this case, the block stored each time in the blockchain of any NVP in each NVP cluster in the m NVP clusters is the newly added block in the corresponding VP. In this way, it can be ensured that the blocks stored in the blockchain of any NVP in each NVP cluster in the m NVP clusters will not be repeated.

(2) If the first message received by any NVP in each NVP cluster in the m NVP clusters is from the corresponding VP, add its own node identifier to the first message to update the first message; The NVP identified by each node identifier in the node list sends the updated first message.

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

The NVP adds its own node identifier to the first message to update the first message, so as to ensure that the next NVP that receives the updated first message knows which NVPs have received the first message.

If the first message received by an NVP comes from the corresponding VP, indicating that this NVP is the first NVP, it can be known that other NVPs in the NVP cluster except this NVP have not received the first message, that is, the NVP of this NVP has not yet received the first message. If none of the adjacent NVPs has received the first message, after updating the first message, this NVP may send the updated first message to the NVP identified by each node identifier in its own node list.

(3) If the first message received by any NVP in each NVP cluster in the m NVP clusters is from an NVP in the same NVP cluster, the node identifier carried in the first message is determined as the target node identifier; Add its own node identification to a message to update the first message; send the updated first message to the NVP identified by each node identification except the target node identification in the own node list.

If the first message received by an NVP comes from an NVP in the same NVP cluster, indicating that this NVP is the second NVP, it can be known that there are at least some NVPs (including the first NVP) in other NVPs except this NVP in the NVP cluster at this time. NVP) has received the first message. Therefore, the first message received by this NVP already carries the node identifier (ie, the target node identifier), and the NVP identified by the target node identifier is the NVP that has received the first message. Therefore, the NVP does not need to send the updated first message to the NVP identified by the target node identification. That is, after updating the first message, the NVP can send the updated first message to the NVP identified by each node identification except the target node identification in its own node list.

In this way, it can be ensured that each NVP in each NVP cluster in the m NVP clusters will not receive a duplicate first message, thereby ensuring that the blocks stored in the blockchain of each NVP will not be duplicated.

Optionally, the node list of one NVP may further include outgoing interfaces corresponding to the node identifiers of adjacent NVPs.

The outgoing interface is a network interface that sends the first message from the NVP when an NVP sends the first message to the NVP identified by the node identifier in the node list. For example, the node identifier of one NVP is 02, and the node identifiers of three adjacent NVPs including this NVP in the node list of this NVP are 01, 03, and 04. The outbound interfaces corresponding to the node identifiers of the three adjacent NVPs included in the node list are shown in Table 2 below.

Table 2

In this embodiment of the present application, only the above Table 2 is taken as an example to illustrate the node list of an NVP, and the above Table 2 does not constitute a limitation to the embodiment of the present application.

In this case, the operation of an NVP sending the updated first message to the NVP identified by each node identification except the target node identification in its own node list may be: the NVP obtains from its own node list The outgoing interface corresponding to each other node identifier except the target node identifier; for any node identifier in each node identifier except the target node identifier in its own node list, the NVP passes the node identifier corresponding to the The outbound interface sends the updated first message to the NVP identified by the node identification.

In this way, each node identifier in the node list corresponds to an outgoing interface, and any NVP in each NVP cluster in the m NVP clusters can send an update to the adjacent NVP from the outgoing interface corresponding to the node identifier of the adjacent NVP. After the first news. As a result, network congestion can be avoided, thereby increasing the message transmission rate.

Optionally, any one NVP in each NVP cluster in the m NVP clusters may include a first module and a second module, and the first module is used to communicate with adjacent NVPs in the same NVP cluster, and is also used to communicate with NVPs in the same NVP cluster. communicate with the corresponding VP. The second module is used to process the block carried in the first message.

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; the second module receives the block sent by the first module Then, store the block in its own blockchain; if the first message received by the first module is from the 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 send the updated first message to the NVP identified by each 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, then the first module The node identifier carried in the first message is determined as the target node identifier, and the node identifier of the NVP to which the first module belongs is added to the first message, to update the first message, and other than the target node identifier in the node list of itself is added. The NVP identified by the node identifier sends the updated first message.

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 block synchronization efficiency.

The operations performed by the first module and the second module are the same as the above-mentioned one NVP receives the first message, stores the block carried in the first message to the blockchain, and sends the first message to the adjacent NVP in the same NVP cluster. The operation of a message is similar and will not be repeated here.

Optionally, the VP corresponding to each NVP cluster in the m NVP clusters may generate a check message during the block consensus process, and the VP may also send the check message to the first NVP in the corresponding NVP cluster.

The check message is used to instruct the NVP to check whether the blocks stored in its own blockchain are correct, and the check message carries the identifier of the first target block and the hash value of the first target block. The first target block identifier is the block identifier of the block that VP performs consensus processing, and the first target block hash value is the block hash value of the block that VP performs consensus processing.

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

In the first case, after the VP completes the consensus on a block, adds the block to the blockchain, and sends the first message carrying the block to the first NVP in the corresponding NVP cluster, The check message can be sent to the first NVP in the corresponding NVP cluster, the first target block identifier carried in the check message is the block identifier of this block, and the hash value of the first target block is this block. the block hash value.

In this case, after each sending the first message carrying the block to the first NVP in the corresponding NVP cluster, a check message for the block is sent to the first NVP in the corresponding NVP cluster. This ensures that each NVP in the corresponding NVP cluster will receive a check message corresponding to this block every time it stores a block, and can ensure that each NVP can check each block stored in its own blockchain. , so as to ensure the correctness of the blocks stored in its own blockchain.

In the second case, after the VP completes the consensus on a block, adds the block to the blockchain, and sends the first message carrying the block to the first NVP in the corresponding NVP cluster, if This block is newly generated after the block rollback operation is performed, and the VP can then send a check message for this block to the first NVP in the corresponding NVP cluster. If the block is not newly generated after the block rollback operation is performed, 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 newly generated block after the block rollback operation is performed is the same as the block identifier of the last block generated before the block rollback operation is performed, the VP performs the block rollback operation, which will cause the VP to The first NVP of the corresponding NVP cluster sends two blocks with the same block identifier, then each NVP in the corresponding NVP cluster will receive two blocks with the same block identifier, but each NVP does not know which block The block is the correct block. This will cause a short-term fork in the blockchain of each NVP, that is, the next block of a block in the blockchain will be divided into two blocks with the same identifier. block. In this case, when the next block of the block identified by the two same block identifiers arrives, in order to store the next block in the blockchain, the parent area of the next block needs to be stored. The block hash is compared with the block hash of the two blocks to determine which of the two blocks is the parent of the next block.

In this case, after the VP generates the latest block after performing the block rollback operation, it can send a check message for the block 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 of the two blocks stored in the blockchain with the same identifier is correct. This ensures the correctness of the blocks stored in the blockchain. Since the VP sends a check message to the first NVP in the corresponding NVP cluster only when the latest block is generated after the block rollback operation is performed, the blockchain system resources can be saved.

Further, after any NVP in each NVP cluster of the m NVP clusters receives the check message generated by the corresponding VP, it can search for the first block in its own blockchain; If the block hash value of the first block is different from the hash value of the first target block, the first block will be deleted from its own blockchain.

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

After an NVP receives the check message generated by the corresponding VP, it searches for the first block in its own blockchain, that is, it searches its own blockchain for a block with the same block ID as the first target block ID. . If the first block is found in its own blockchain, the block hash value of the first block is compared with the hash value of the first target block. If the block hash value of the first block is the same as the first target block hash value, it means that the first block is correct, and no processing is required. If the block hash value of the first block is different from the hash value of the first target block, it means that the block corresponding to the hash value of the first block and the first target block is not the same, and the first block can be determined. Incorrect, that is, the first block is likely to be a block that has been rolled back, so the first block can be deleted from its own blockchain.

For example, after a VP completes consensus on a block with a block identifier of 50, it sends a first message carrying a block with a block identifier of 50 to the first NVP in the corresponding NVP cluster. However, after the VP completed the consensus on the block, it rolled back the block. After the VP performed the block rollback operation, it continued to generate a block with a block ID of 50 and completed the verification of the block. The consensus of this block. After that, the VP will send the first message carrying the newly generated block with the block identifier 50 to the first NVP in the corresponding NVP cluster, and will send a check message for this block. In this case, each NVP in the corresponding NVP cluster will receive two blocks with a block ID of 50, then its own blockchain will also store two blocks with a block ID of 50 accordingly. At this time, the previously stored block with the block identifier 50 can be deleted according to the check message.

For example: Figure 3 is a schematic diagram of blocks stored in the blockchain of 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 include two blocks 301 with the block identifier 50, and the two blocks 301 with the block identifier 50 cause the block chain 300 to temporarily fork. An NVP receives a check message sent by a corresponding VP, and the first target block identifier carried in the check message is 50. The NVP can search the block 301 with the block ID 50 from its own blockchain 300, and will find two blocks 301 with the block ID 50. Then the NVP determines the block hash value of the block 301 with the block identifier 50 stored previously in the block 301 with the block identifier 50 and the first target block hash carried in the check message. If the value is different, the NVP can delete the block 301 with the block ID 50 stored previously in its own blockchain 300. In this way, the block 301 stored in the blockchain 300 of this NVP is the correct block 301. At this time, the blockchain 300 of the NVP may be as shown in FIG. 4 , and the correct blocks 301 are stored in the blockchain 300 shown in FIG. 4 .

The operations performed by each NVP in each NVP cluster in the m NVP clusters after receiving the first message are described in detail above, and each NVP in each NVP cluster in the m NVP clusters can be implemented. Store the block carried in the first message in its own blockchain, thus ensuring that each NVP in each NVP cluster in the m NVP clusters synchronizes the block stored in the multiple VPs to itself blockchain.

It is worth noting that any NVP in each NVP cluster in the m NVP clusters may be unable to receive blocks for a long time due to network congestion or network partitions, etc., then this NVP cannot realize the block. Synchronize. The following is a detailed description of what needs to be done in this case to solve the problem of not being able to synchronize blocks due to network reasons.

Specifically, each NVP in each NVP cluster in the m NVP clusters sends a blockchain state to other adjacent NVPs in the same NVP cluster every fourth preset time period, where the blockchain state includes its own node ID and the block ID of the latest block in the blockchain; any NVP in each NVP cluster in the m NVP clusters determines the state of the blockchain sent by the received adjacent NVP as the target blockchain If no block is received within the fifth preset time period, if the block ID of the latest block in the own blockchain is smaller than the block ID in the target blockchain In the blockchain of the target NVP identified by the node ID in the chain state, obtain the block whose block ID is greater than the block ID of the latest block in its own blockchain, and store the obtained block in its own area. blockchain.

The fourth preset duration can be set in advance, and the fourth preset duration can be set by a technician according to requirements. For example, the fourth preset duration may be set to 1 minute.

An NVP's blockchain state is used to represent the state of the latest block stored in its own blockchain. The target blockchain state is the blockchain state received by an NVP and sent by an adjacent NVP. If this NVP has multiple adjacent NVPs, this NVP can receive multiple target blockchain states.

The fifth preset duration can be set in advance, and the fifth preset duration can be set larger to ensure sufficient time to receive blocks. For example, the fifth preset duration may be set to 2 minutes.

The target NVP is the NVP identified by the node identifier in the target blockchain state where the block identifier in the multiple target blockchain states received by the NVP is greater than the block identifier of the latest block in the blockchain of the NVP.

Each NVP in each NVP cluster in the m NVP clusters sends the blockchain status to other adjacent NVPs in the same NVP cluster every fourth preset time period, then each NVP can know the area of the adjacent NVP The condition of the latest block stored in the blockchain. If an NVP does not receive a block within the fifth preset time period, it means that the NVP has not received a block for a long time, and the NVP can view any target block in the status of multiple target blockchains Whether there is a block ID in the chain state that is larger than the block ID of the latest block in its own blockchain, if there is a block ID in the target blockchain state that is larger than itself in multiple target blockchain states The block ID of the latest block in the blockchain, the NVP can obtain the latest block ID from the blockchain of the target NVP identified by the node ID in the target blockchain state. The block identified by the block's block. Afterwards, the acquired blocks can be stored in their own blockchain to synchronize unstored blocks in their own blockchain. If the block ID in each target blockchain state of the multiple target blockchain states is less than or equal to the block ID of the latest block in its own blockchain, the NVP continues to wait to receive blocks.

In this way, when an NVP has not received a block for a long time, it can directly obtain a block with a block ID larger than the latest block in its own block chain from the block chain of the adjacent target NVP, which can save system resources. , and saves the block synchronization time, thereby improving the block synchronization efficiency.

Optionally, the blockchain state also includes the block hash value of the latest block in the blockchain. In this case, this NVP is obtained from the blockchain of the target NVP identified by the node ID in the target blockchain state. , the operation of obtaining a block whose block identifier is greater than the block identifier of the latest block in its own blockchain may be: the NVP sends a third message to the target NVP identified by the node identifier in the target blockchain state; the target If the NVP receives the third message, it will search for the second block from its own blockchain, and if it finds the second block from its own blockchain, the block hash value of the second block will be the same as that of the second block. If the hash value of the second target block is the same, all blocks in its own blockchain whose block identifier is greater than the third target block identifier and less than or equal to the second target block identifier are sent to this NVP.

Here, the target blockchain state is the target blockchain state in which the block ID of the multiple target blockchain states is greater than the block ID of the latest block in the blockchain of the NVP.

The third message is used to instruct the target NVP to send a block in its own blockchain that is larger than the block identifier of the latest block in the blockchain of this NVP to this NVP. The third message carries the second target block identifier, the second target block hash value and the third target block identifier. The second target block identifier is the block identifier in the target blockchain state, that is, the block identifier of a block that is not stored in the blockchain of the NVP. The second target block hash value is the block hash value in the target blockchain state, that is, the block hash value of a block not stored in the NVP's blockchain. The third target block identifier is the block identifier of the latest block in the blockchain of this NVP.

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

In this case, after receiving the third message, the target NVP first checks whether there is a block with the same block ID as the second target block ID (ie, the second block) in its own blockchain, and if it finds itself If there is a second block in the blockchain of the second block, the block hash value of the second block is compared with the hash value of the second target block carried in the third message. The hash value is the same as the hash value of the second target block, indicating that the second block is one of the unstored blocks in the blockchain of this NVP. In this case, the block ID in the blockchain of the target NVP is greater than The block ID of the latest block in the blockchain of this NVP (ie, the third target block ID), and all blocks that are less than or equal to the block ID of the second block (ie, the second target block ID) All are unstored blocks in the blockchain of this NVP. Then the target NVP can send all the blocks in its own blockchain whose block identifier is greater than the third target block identifier and less than or equal to the second target block identifier to this NVP. After the NVP receives the block sent by the target NVP, it can store the received block in its own blockchain to synchronize the unstored blocks in its own blockchain, thus ensuring its own blockchain The blocks stored in the blockchain are the same as those stored in other NVP's blockchains.

Optionally, during the operation of the blockchain system, an NVP may be added to any one of the m NVP clusters, and blocks may not yet be stored in the blockchain of the newly added NVP. The newly added NVP can synchronize all blocks stored in the blockchains of other NVPs in the NVP cluster. In this case, the newly added NVP can perform the above steps of obtaining all blocks from the target NVP, so as to synchronize the blocks stored in the blockchains of other NVPs in the NVP cluster.

The operation of any one NVP in each NVP cluster in the m NVP clusters actively acquires blocks not stored in its own blockchain from the target NVP has been described in detail above. In the embodiment of this application, when any NVP in each NVP cluster of the m NVP clusters finds that some blocks are missing in its own blockchain, it actively obtains all the missing blocks from the target NVP (that is, point-to-point pull) to synchronize all missing blocks. In this way, system resources can be saved and block synchronization efficiency can be improved.

In this embodiment of the present application, the blockchain system includes multiple VPs and m NVP clusters, m VPs in the multiple VPs are in one-to-one correspondence with the m NVP clusters, and each NVP cluster in the m NVP clusters A first NVP and at least one second NVP are included. The first NVP is an NVP that communicates with the corresponding VP, and there is a network path between the first NVP and each second NVP in the at least one second NVP, so the first NVP in the NVP cluster can both communicate with the corresponding VP It can also communicate with other NVPs in the same NVP cluster. After the multiple VPs complete the consensus on a block and add the block to the blockchain, each of the m VPs sends a message carrying the block to the first NVP in the corresponding NVP cluster. First news. If each NVP in each NVP cluster in 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 the adjacent NVP in the same NVP cluster. A message so that every NVP in every NVP cluster can sync 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 each NVP in the corresponding NVP cluster can perform the The synchronization of blocks reduces the pressure on VPs, which in turn can improve the efficiency of block consensus.

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 running on the processor 50 . When the processor 50 executes the computer program 52 , the above-mentioned embodiments are implemented. Steps in a block synchronization method.

The computer device 5 may be a server cluster including a plurality of servers, and the server cluster may be a blockchain system. Those skilled in the art can understand that FIG. 5 is only an example of the computer device 5, and does not constitute a limitation to the computer device 5. It may include more or less components than the one shown, or combine some components, or different components , for example, it may also include input and output devices, network access devices, and so on.

The processor 50 may be a central processing unit (Central Processing Unit, CPU), and the processor 50 may also be other general-purpose processors, a digital signal processor (Digital Signal Processor, DSP), an application specific integrated circuit (Application Specific Integrated Circuit, ASIC) , Off-the-shelf programmable gate array (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or it may be 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 also be an external storage device of the computer device 5 in other embodiments, such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), and a Secure Digital (SD) card equipped on the computer device 5 , Flash card (Flash Card) and so on. 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 to store an operating system, application programs, a boot loader (Boot Loader), data, and other programs. The memory 51 can also be used to temporarily store data that has been output or is to be output.

Embodiments of the present application further provide a computer device, the computer device comprising: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor, the processor executing the computer program The steps in any of the foregoing method embodiments are implemented at the same time.

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

The embodiments of the present application provide a computer program product, which, when running on a computer, enables the computer to execute the steps in the foregoing method embodiments.

The integrated unit, if implemented as a software functional unit and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the foregoing method embodiments can be implemented by a computer program that instructs the relevant hardware. The computer program can be stored in a computer-readable storage medium, and the computer program can be When executed by the processor, the steps of the foregoing method embodiments may be implemented. Wherein, the computer program includes computer program code, and the computer program code may be in the form of source code, object code, executable file or some intermediate form, and the like. The computer-readable medium may include at least: any entity or device capable of carrying the computer program code to the photographing device/terminal device, recording medium, computer memory, ROM (Read-Only Memory, read-only memory), RAM (Random Access Memory) , random access memory), CD-ROM (Compact Disc Read-Only Memory, CD-ROM), magnetic tape, floppy disk and optical data storage devices, etc. The computer-readable storage medium mentioned in this application may be a non-volatile storage medium, in other words, may be a non-transitory storage medium.

It should be understood that, all or part of the steps of implementing the above embodiments may be implemented by software, hardware, firmware or any combination thereof. When implemented in software, it can 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 foregoing embodiments, the description of each embodiment has its own emphasis. For parts that are not described or described in detail in a certain embodiment, reference may be made to the relevant descriptions of other embodiments.

Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Skilled artisans may implement the described functionality using different methods for each particular application, but such implementations should not be considered beyond the scope of this application.

In the embodiments provided in this application, it should be understood that the disclosed apparatus/computer equipment and method may be implemented in other manners. For example, the apparatus/computer equipment embodiments described above are only illustrative. For example, the division of modules or units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components. May be combined or may be integrated into another system, or some features may be omitted, or not implemented. On the other hand, the shown or discussed mutual coupling or direct coupling or communication connection may be through some interfaces, indirect coupling or communication connection of devices or units, and may be in electrical, mechanical or other forms.

Units described as separate components may or may not be physically separated, and components shown as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution in this embodiment.

The above-mentioned embodiments are only used to illustrate the technical solutions of the present application, but not to limit them; although the present application has been described in detail with reference to the above-mentioned embodiments, those of ordinary skill in the art should understand that: it is still possible to implement the above-mentioned implementations. The technical solutions described in the examples are modified, or some technical features thereof are equivalently replaced; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions in the embodiments of the application, and should be included in the within the scope of protection of this application.

Claims (13)

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:

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.

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;

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;

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;

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.

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.

Images