Data synchronization method, alliance blockchain system, electronic device and storage medium

Abstract

The present application relates to a data synchronization method, a consortium blockchain system, an electronic device and a storage medium. The data synchronization method performed by each VP node includes: receiving a handshake request initiated by an NVP node, the handshake request carries a first identifier and first block status information, the value of the first identifier is used to indicate the number of times the NVP node has not responded to the heartbeat message sent by the VP node within a preset time length; comparing the value of the first identifier with the value of the second identifier of the VP node; when the value of the first identifier is not lower than the value of the second identifier, obtaining the second block status information of the VP node, comparing the first block status information with the second block status information, generating a handshake response, the handshake response is used to instruct the NVP node to adjust its own block to a block synchronization state with the VP node; sending a handshake response to the NVP node. The present application solves the problem that the VP node and the NVP node cannot synchronize blocks after restoring normal communication connection.

Description

Technical Field

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

[0002] In a blockchain network, VP (Validating Peer) is responsible for transaction packaging, consensus, execution, and external query services. However, due to the limitations of the BFT (Byzantine Fault Tolerance) consensus algorithm, the number of VP nodes cannot be expanded indefinitely, which will cause the limited VP nodes in the blockchain network to bear very high pressure. NVP (Non-Validating Peer) is responsible for synchronizing data from VP nodes, forwarding transactions to VP nodes, and providing external query services in a blockchain network. On the one hand, the existence of NVP nodes can well alleviate the query pressure of VP nodes. On the other hand, in the alliance chain scenario, not all institutions may be qualified to participate in consensus as a VP node, but can only participate in data synchronization and execution as an NVP node.

[0003] There are multiple rounds of message initiation and response operations between the VP node and the NVP node. When the network is unstable, abnormal jitter or disconnection will occur between the VP node and the NVP node. When the VP node and the NVP node are communicating normally again, if the VP node directly transmits blocks to the NVP node, it will cause inconsistency between the blocks of the NVP node and the VP node.

[0004] There is currently no effective solution to the problem in the related art that VP nodes and NVP nodes are unable to synchronize blocks after restoring normal communication connections. Summary of the invention

[0005] In this embodiment, a data synchronization method, a consortium blockchain system, an electronic device, and a storage medium are provided to solve the problem in the related art that VP nodes and NVP nodes cannot synchronize blocks after restoring normal communication connections.

[0006] In a first aspect, a data synchronization method is provided in this embodiment, which is applied to a VP node in a consortium blockchain, wherein the consortium blockchain includes at least one VP node and at least one NVP node, and each VP node can be communicatively connected with at least one NVP node. The data synchronization method performed by each VP node includes:

[0007] Receive a handshake request initiated by an NVP node, wherein the handshake request carries a first identifier and first block status information, and the value of the first identifier is used to indicate the number of times that the NVP node fails to respond to a heartbeat message sent by a VP node within a preset time period;

[0008] comparing the value of the first identifier with the value of the second identifier of the VP node;

[0009] When the value of the first identifier is not lower than the value of the second identifier, obtaining the second block status information of the VP node, comparing the first block status information with the second block status information, and generating a handshake response according to the comparison result of the first block status information and the second block status information, wherein the handshake response is used to instruct the NVP node to adjust its own block to a block synchronization state with the VP node;

[0010] Send the handshake response to the NVP node.

[0011] In some embodiments, before receiving the handshake request initiated by the NVP node, the method further includes:

[0012] Send the heartbeat message to the NVP node according to a preset period;

[0013] Detect whether a confirmation message returned by the NVP node is received within a preset time period;

[0014] If it is detected that the confirmation message returned by the NVP node is not received within the preset time, a value of one unit is accumulated in the second identifier, and the accumulated second identifier is written into the next round of heartbeat messages.

[0015] In some embodiments, the first block state information includes first stable checkpoint information of the NVP node, the second block state information includes second stable checkpoint information of the VP node, and comparing the first block state information with the second block state information, and generating a handshake response according to the comparison result of the first block state information and the second block state information includes:

[0016] comparing the first stable checkpoint information and the second stable checkpoint information;

[0017] In the case that the first stable checkpoint information and the second stable checkpoint information are inconsistent, a first handshake response is generated, wherein the first handshake response carries indication information that the NVP node has abnormal operation.

[0018] In some embodiments, the first block status information further includes a first block height and a first block hash value of the latest block in the NVP node, and the method further includes:

[0019] When the first stable checkpoint information and the second stable checkpoint information are consistent, detecting whether the VP node has a second block with the same height as the first block;

[0020] If it is detected that the VP node has a second block with the same height as the first block, obtain a second block hash value corresponding to the second block, and compare the first block hash value with the second block hash value;

[0021] When the first block hash value and the second block hash value are consistent, a second handshake response is generated, wherein the second handshake response carries indication information that the NVP node is in a normal state.

[0022] In some embodiments, the method further comprises:

[0023] In the case that the first block hash value and the second block hash value are inconsistent, a third handshake response is generated, wherein the third handshake response is used to instruct the NVP node to perform a block cut and rollback operation on its own block until the block state of the NVP node is consistent with the block state indicated by the second stable checkpoint information.

[0024] In some of the embodiments, the method further includes: after sending the handshake response or block generated by the VP node to the NVP node, ending the step of establishing a handshake connection with the NVP node.

[0025] In some embodiments, before receiving the handshake request initiated by the NVP node, the method further includes:

[0026] Obtain a first command for adding the NVP node, wherein the first command carries source information of the NVP node;

[0027] Creating an NVP instance according to the first command, wherein the NVP instance is used to maintain the block state of the NVP node, and the NVP instance is associated with source information of the NVP node;

[0028] Start the thread corresponding to the NVP instance.

[0029] In some embodiments, after creating the NVP instance according to the first command, the method further includes:

[0030] Obtain a second command for deleting the NVP node, wherein the second command carries source information of the NVP node;

[0031] Sending a disconnect request to the NVP node according to the second command;

[0032] When receiving a disconnection response returned by the NVP node, disconnecting from the NVP node; or starting a timer, sending the disconnection request according to a preset period, and disconnecting from the NVP node when the timer reaches the set time but the disconnection response is not received.

[0033] In some embodiments, when the timer reaches a set time but the disconnection response is not received, after disconnecting the NVP node, the method further includes:

[0034] Generate a notification message and send the notification message to the user, wherein the notification message is used to instruct the VP node to unilaterally delete the NVP node, and the NVP node also retains a configuration file corresponding to the VP node, a certificate of the VP node, and a VP instance corresponding to the VP node.

[0035] In some embodiments, after starting the thread corresponding to the NVP instance, the method further includes:

[0036] In the case where the VP node adds a new block, the latest block height of the NVP node is obtained according to the NVP instance, and it is detected whether the latest block height of the NVP node is less than the block height of the current VP node;

[0037] If it is detected that the latest block height of the NVP node is less than the block height of the current VP node, the newly added block of the VP node is sent to the NVP node.

[0038] In some embodiments, before sending the newly added block of the VP node to the NVP node, the method further includes:

[0039] Sending the heartbeat message to the NVP node;

[0040] Detect whether a confirmation message returned by the NVP node is received within a preset time period;

[0041] If it is detected that a confirmation message returned by the NVP node is received within a preset time period, the newly added block of the VP node is sent to the NVP node, and the block status of the NVP node maintained by the NVP instance is updated.

[0042] In a second aspect, a data synchronization method is provided in this embodiment, which is applied to an NVP node in a consortium blockchain, wherein the consortium blockchain includes at least one VP node and at least one NVP node, and each VP node can be communicatively connected with at least one NVP node. The data synchronization method performed by each NVP node includes:

[0043] Receive a heartbeat message sent by the VP node, and compare the second identifier carried in the heartbeat message with the first identifier of the NVP node;

[0044] In the case where the second identifier is lower than the first identifier, a handshake request is initiated to the VP node, wherein the handshake request carries the first identifier and the first block status information, and the value of the first identifier is used to indicate the number of times that the NVP node fails to respond to the heartbeat message sent by the VP node within a preset time period;

[0045] Receive a handshake response returned by the VP node, and adjust the block of the NVP node to a block synchronization state with the VP node according to the handshake response.

[0046] In some embodiments, adjusting the block of the NVP node to a block synchronization state with the VP node according to the handshake response includes:

[0047] The block of the NVP node is adjusted to a preset normal state according to the handshake response, wherein the handshake response carries indication information that the NVP node has abnormal operation.

[0048] In some embodiments, adjusting the block of the NVP node to a block synchronization state with the VP node according to the handshake response includes:

[0049] Perform a block cut and rollback operation on the block of the NVP node according to the handshake response until the block state of the NVP node is consistent with the block state indicated by the second stable checkpoint information, wherein the handshake response carries the second stable checkpoint information.

[0050] In some of the embodiments, the method further includes: after receiving the handshake response or block sent by the VP node, ending the step of establishing a handshake connection with the VP node.

[0051] In some embodiments, before receiving the heartbeat message sent by the VP node, the method further includes:

[0052] Obtaining a third command for adding the VP node, wherein the third command carries source information of the VP node;

[0053] Creating a VP instance according to the third command, wherein the VP instance is used to maintain the block status of the VP node, and the VP instance is associated with the source information of the VP node;

[0054] Start a thread corresponding to the VP instance.

[0055] In some embodiments, after creating the VP instance according to the third command, the method further includes:

[0056] Obtaining a fourth command for deleting the VP node, wherein the fourth command carries source information of the VP node;

[0057] sending a disconnection request to the VP node according to the fourth command;

[0058] Upon receiving a disconnect response returned by the VP node, disconnect with the VP node; or, start a timer, send the disconnect request according to a preset period, and disconnect with the VP node if the timer reaches the set time but the disconnect response is not received.

[0059] In some embodiments, when the timer reaches a set time but the disconnection response is not received, after disconnecting the VP node, the method further includes:

[0060] Generate a notification message and send the notification message to the user, wherein the notification message is used to instruct the NVP node to unilaterally delete the VP node, and the VP node also retains a configuration file corresponding to the NVP node, a certificate of the NVP node, and an NVP instance corresponding to the NVP node.

[0061] In a third aspect, a consortium blockchain system is provided in this embodiment, including: at least one VP node and at least one NVP node, each VP node is communicatively connected to at least one NVP node, each VP node is used to execute the data synchronization method described in the first aspect above, and each NVP node is used to execute the data synchronization method described in the second aspect above.

[0062] In a fourth aspect, an electronic device is provided in this embodiment, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the data synchronization method described in the first aspect when executing the computer program.

[0063] In a fifth aspect, an electronic device is provided in this embodiment, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the data synchronization method described in the second aspect when executing the computer program.

[0064] In a sixth aspect, in this embodiment, a storage medium is provided, on which a computer program is stored, and when the program is executed by a processor, the data synchronization method described in the first aspect is implemented.

[0065] In a seventh aspect, a storage medium is provided in this embodiment, on which a computer program is stored, and when the program is executed by a processor, the data synchronization method described in the second aspect is implemented.

[0066] Compared with the related art, the data synchronization method, alliance blockchain system, electronic device and storage medium provided in this embodiment, wherein the data synchronization method performed by each VP node includes: receiving a handshake request initiated by an NVP node, wherein the handshake request carries a first identifier and a first block status information, and the value of the first identifier is used to indicate the number of times that the NVP node has not responded to the heartbeat message sent by the VP node within a preset time length; comparing the value of the first identifier with the value of the second identifier of the VP node; when the value of the first identifier is not lower than the value of the second identifier, obtaining the second block status information of the VP node, comparing the first block status information with the second block status information, and generating a handshake response according to the comparison result of the first block status information and the second block status information, wherein the handshake response is used to indicate that the NVP node adjusts its own block to a block synchronization state with the VP node; sending a handshake response to the NVP node. The present application solves the problem in the related art that the VP node and the NVP node cannot synchronize blocks after restoring the normal communication connection, so that the VP node and the NVP node synchronize blocks after restoring the normal communication connection.

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

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

[0069] Figure 1 It is a hardware structure block diagram of a terminal of a data synchronization method according to an embodiment of the present application;

[0070] Figure 2 This is the process of the data synchronization method of an embodiment of the present application Figure 1 ;

[0071] Figure 3 This is the process of the data synchronization method of an embodiment of the present application Figure 2 ;

[0072] Figure 4 This is a flow chart of a heartbeat / handshake mechanism of a preferred embodiment of the present application;

[0073] Figure 5 This is a flowchart of adding and deleting nodes according to a preferred embodiment of the present application. DETAILED DESCRIPTION

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

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

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

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

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

[0079] In this embodiment, a data synchronization method is provided, which is applied to a VP node in a consortium blockchain. The consortium blockchain includes at least one VP node and at least one NVP node. Each VP node can be connected to at least one NVP node for communication. Figure 2 This is the process of the data synchronization method of an embodiment of the present application Figure 1 ,like Figure 2 As shown, the process executed by the VP node includes the following steps:

[0080] Step S201, receiving a handshake request initiated by an NVP node, wherein the handshake request carries a first identifier and first block status information, and the value of the first identifier is used to indicate the number of times that the NVP node fails to respond to a heartbeat message sent by the VP node within a preset time.

[0081] VP nodes and NVP nodes are deployed on different terminals or servers respectively. A VP node can communicate with multiple NVP nodes to manage multiple NVP nodes. VP nodes and NVP nodes maintain connection activity through the heartbeat mechanism, and the heartbeat message is initiated by the VP node. VP nodes and NVP nodes maintain identifiers respectively. When the NVP node receives a heartbeat message initiated by the VP node with an identifier of a larger value, the NVP node updates the identifier it maintains to be consistent with the identifier of the VP node. The identifier can represent the number of times the message is rotated between the VP node and the NVP node. The identifier can be an increasing integer variable value, which can be represented by View.

[0082] Each heartbeat message initiated by the VP node will carry an identifier. If the NVP node does not respond to the heartbeat message within the preset time in the current message round, the VP node will add a unit value to the identifier. In the next message round, the VP node will write the latest accumulated identifier into the heartbeat message and send it to the NVP node.

[0083] Step S202: compare the value of the first identifier with the value of the second identifier of the VP node.

[0084] When the network is unstable, abnormal jitter or disconnection may occur between the VP node and the NVP node. When the VP node and the NVP node communicate normally again, there may be a situation where the VP node and the NVP node are out of sync on the message rounds. After the VP node and the NVP node are disconnected, if the VP node continues to generate blocks at this time, or the NVP node mistakenly connects to the VP node of other blockchains, the two sides will be inconsistent after reconnecting.

[0085] By comparing the value of the first identifier with the value of the second identifier, taking the block status of the VP node as a reference, it can be used to determine whether a handshake phase is required to recover the block status in the NVP node.

[0086] Step S203, when the value of the first identifier is not lower than the value of the second identifier, obtain the second block status information of the VP node, compare the first block status information with the second block status information, and generate a handshake response according to the comparison result of the first block status information and the second block status information, wherein the handshake response is used to instruct the NVP node to adjust its own block to a block synchronization state with the VP node.

[0087] When the value of the first identifier is not lower than the value of the second identifier, the VP node will consider that it is necessary to initiate the steps of establishing a handshake connection with the NVP node. The VP node will obtain its own second block status information, wherein, whether it is the first block status information or the second block status information, the data contained may be the block height and / or the block hash value, and the VP node will compare the first block status information with the second block status information, and generate a handshake response based on the comparison results of the VP node and the NVP node in terms of block height and / or block hash value, so as to instruct the NVP node to adjust its own block to the block synchronization state with the VP node. Among them, there may be many different situations in the comparison results of the VP node and the NVP node in terms of block height and / or block hash value, and the handshake response includes synchronization strategies for different comparison results.

[0088] Step S204: Send a handshake response to the NVP node.

[0089] At this point, the VP node completes sending the handshake response.

[0090] In the above steps S201 to S204, the VP node compares the value of the first identifier with the value of the second identifier, and determines whether to start the step of establishing a handshake connection with the NVP node according to the comparison result of the value of the first identifier and the value of the second identifier, and in the step of establishing a handshake connection with the NVP node, the VP node uses its own block status information as a reference, checks the block status information of the NVP node, formulates a synchronization strategy according to different inspection results, writes a handshake response, and finally sends the handshake response to the NVP node to instruct the NVP node to adjust its own block to the block synchronization state with the VP node. Through the above steps, the problem that the VP node and the NVP node cannot synchronize blocks after restoring the normal communication connection in the related art is solved, so that the VP node and the NVP node can synchronize blocks after restoring the normal communication connection.

[0091] In one embodiment of the present application, a heartbeat mechanism is also provided to maintain the activity of the connection between the VP node and the NVP node, and the implementation method is as follows:

[0092] Before the VP node receives the handshake request initiated by the NVP node, the VP node will also send a heartbeat message to the NVP node according to a preset period; detect whether a confirmation message returned by the NVP node is received within the preset time length; if it is detected that a confirmation message returned by the NVP node is not received within the preset time length, a unit value is accumulated in the second identifier, and the accumulated second identifier is written into the next round of heartbeat messages.

[0093] In this embodiment, the VP node will periodically send heartbeat messages to the NVP node. If the NVP node receives the heartbeat message, it will reply directly. If the VP node does not receive the heartbeat reply from the NVP node within the preset time, it is considered that the NVP node has timed out due to some abnormality, such as network disconnection or NVP node downtime.

[0094] In one embodiment of the present application, the first block status information includes first stable checkpoint information of the NVP node, and the second block status information includes second stable checkpoint information of the VP node. When comparing the first block status information and the second block status information, and generating a handshake response based on the comparison result of the first block status information and the second block status information, the first stable checkpoint information and the second stable checkpoint information can be compared; when the first stable checkpoint information and the second stable checkpoint information are inconsistent, a first handshake response is generated, wherein the first handshake response carries indication information that the NVP node has abnormal operation.

[0095] Among them, the second stable checkpoint information includes the block height and block hash value of the VP node determined after consensus of the blockchain where the VP node is located.

[0096] In this embodiment, each node of the blockchain independently executes a batch of transactions, and the corresponding execution results can be represented by block hash values. Due to the existence of erroneous nodes, the block hash values ​​of different nodes may be inconsistent. If, after consensus, it is confirmed that the blocks of most VP nodes in the blockchain where the VP node is located are at a consistent height and the hash values ​​remain consistent, the block at the consistent height is determined as a stable checkpoint, which may be represented by Checkpoint.

[0097] Under normal circumstances, the blocks of each node in the blockchain are consensus-based, and the stable checkpoint is absolutely correct. However, when an NVP node has an erroneous operation, such as the NVP node first connects to the VP node of a blockchain, and then connects to the VP node of another blockchain without deleting the data, the data on the two chains are completely inconsistent, and the stable checkpoint is naturally inconsistent and cannot be restored. In this embodiment, when comparing the first stable checkpoint information and the second stable checkpoint information, the hash values ​​of the stable checkpoints in the two nodes can be compared. If the hash values ​​of the two are inconsistent, the VP node will think that the NVP node is in an unrecoverable state, so it will directly report an error to the NVP node and notify the NVP node to perform the correct operation again.

[0098] In one embodiment of the present application, the first block status information also includes the first block height and the first block hash value of the latest block in the NVP node. When the first stable checkpoint information and the second stable checkpoint information are consistent, the VP node will detect whether it has a second block with the same height as the first block. If it is detected that it has a second block with the same height as the first block, it obtains the second block hash value corresponding to the second block and compares the first block hash value with the second block hash value. When the first block hash value and the second block hash value are consistent, a second handshake response is generated, wherein the second handshake response carries indication information that the NVP node is in a normal state.

[0099] In this embodiment, after the NVP node passes the Checkpoint check, the VP node will then check the block height. Let the height of the first block be H. If the VP node has a second block with a height of H, the block hash value will be verified. If the hash value of the latest block in the NVP node is consistent with the hash value of the second block, it is determined that the NVP node is in a correct state at this time.

[0100] In one embodiment of the present application, after generating a handshake response indicating that the NVP node is in a normal state and sending the handshake response to the NVP node, the VP node will obtain the third block added after the second block and send the third block to the NVP node. That is, the blocks starting from H+1 are sent to the NVP node.

[0101] In one embodiment of the present application, when the first block hash value and the second block hash value are inconsistent, the VP node will generate a third handshake response, wherein the third handshake response is used to instruct the NVP node to perform a block cut and rollback operation on its own block until the block state of the NVP node is consistent with the block state indicated by the first stable checkpoint information.

[0102] In some embodiments, after the NVP node performs the block cut rollback operation, the handshake process will be triggered again, and the VP node will also start the steps of establishing a handshake connection with the NVP node accordingly. Among them, the Checkpoint of the NVP node has been checked in the previous round of handshake process, so after the rollback and when the next round of handshake process is triggered, it can be ensured that the Checkpoint of the NVP node is consistent with the Checkpoint of the VP node.

[0103] After the NVP node sends a handshake request, it needs to wait for the handshake response from the VP node before exiting the handshake process. Otherwise, the NVP node will keep resending the handshake request at regular intervals, but the VP node will not resend the handshake response. Therefore, once the handshake response is lost in the network, the VP node will think that the NVP node has recovered and is preparing to send blocks, while the NVP node is still in the handshake stage.

[0104] To this end, in one embodiment of the present application, after sending the handshake response or block generated by the VP node to the NVP node, the step of establishing a handshake connection with the NVP node is terminated. That is, the timing for the NVP node to exit the handshake process includes: receiving a handshake response from the VP node; receiving a block message from the VP node.

[0105] In one embodiment of the present application, when the value of the first identifier is lower than the value of the second identifier, the VP node determines that the handshake request has expired and ignores the handshake request.

[0106] The above embodiment introduces a heartbeat mechanism and a handshake mechanism between a VP node and an NVP node. The heartbeat mechanism is used to ensure the activity of the connection, and the handshake mechanism is used to ensure the response and recovery of abnormal scenarios. Regarding the handshake mechanism, when abnormal jitter or disconnection occurs between the VP node and the NVP node, when the VP node and the NVP node are connected to communicate normally again, the block state of the NVP node can be restored through the handshake mechanism to synchronize with the block state of the VP node.

[0107] The following embodiment will introduce the connection mechanism between the VP node and the NVP node.

[0108] In one embodiment of the present application, before the VP node receives a handshake request initiated by the NVP node, the VP node creates an NVP instance corresponding to the NVP node, wherein the NVP instance is used to maintain the block status of the NVP node, and the NVP instance is associated with the source information of the NVP node; the VP node starts a thread corresponding to the NVP instance.

[0109] It should be noted that NVP nodes and NVP instances are two different concepts. NVP nodes represent physical nodes. NVP nodes and VP nodes are deployed on two terminals or two servers respectively. An NVP instance is a logical component on a VP node used to manage a certain NVP node and is in the same process as the VP node.

[0110] In the configuration file of the VP node, the VP node can configure the domain names and IP addresses of multiple NVP nodes in advance. After the VP node is started, it first creates an empty hash table, which is a mapping of the domain name of the NVP node to the NVP instance. Then the VP node reads the configuration file of the VP node, creates and starts an NVP instance for each IP address of the NVP node, and makes these NVP nodes run on different threads. Each NVP instance is responsible for managing and maintaining the block status of a specific NVP node, including the block height, block hash value and execution status of the NVP node.

[0111] Since different NVP nodes execute blocks at different speeds, each NVP instance may also be at a different block height in the hash table maintained by the VP node. Since different NVP instances run on different threads, the block sending speed can be guaranteed.

[0112] In one embodiment of the present application, after starting the thread corresponding to the NVP instance, when a new block is added to the VP node, the VP node will obtain the latest block height of the NVP node according to the NVP instance, and detect whether the latest block height of the NVP node is less than the block height of the current VP node; if it is detected that the latest block height of the NVP node is less than the block height of the current VP node, the new block of the VP node will be sent to the NVP node.

[0113] After the VP node generates a block, it traverses the above hash table. If it finds that the block height of a certain NVP instance is smaller than the block height of the VP node, the NVP instance will send the missing block to the NVP node.

[0114] In one embodiment of the present application, before sending the newly added block of the VP node to the NVP node, the VP node will send a heartbeat message to the NVP node; detect whether a confirmation message returned by the NVP node is received within a preset time length; if it is detected that a confirmation message returned by the NVP node is received within the preset time length, the newly added block of the VP node is sent to the NVP node, and the block status of the NVP node maintained by the NVP instance is updated. If it is detected that the confirmation message returned by the NVP node is not received within the preset time length, it is determined that the NVP node is abnormal, and the sending of the newly added block of the VP node is stopped.

[0115] Due to the instability of the network, the blocks sent by the VP node to the NVP node may be lost. Therefore, after receiving a batch of blocks and successfully executing them, the NVP node needs to reply a confirmation message to the NVP instance on the VP node. Only after receiving the confirmation message will the NVP instance update the NVP node block height maintained in the NVP instance and try to send the next batch of blocks to it. Otherwise, the NVP instance will continue to resend a batch of blocks until the heartbeat times out.

[0116] The above embodiment introduces a connection mechanism in the alliance chain scenario, that is, a one-to-many connection relationship is established between the VP node and the NVP node, each connection does not affect each other, and data synchronization operations are performed completely in parallel.

[0117] The following embodiment will introduce a method for flexibly and dynamically adding and deleting VP nodes and NVP nodes.

[0118] In one embodiment of the present application, before receiving a handshake request initiated by an NVP node, the VP node obtains a first command for adding the NVP node, wherein the first command carries source information of the NVP node; creates an NVP instance according to the first command, wherein the NVP instance is used to maintain the block status of the NVP node, and the NVP instance is associated with the source information of the NVP node; and starts a thread corresponding to the NVP instance.

[0119] In one embodiment of the present application, after creating an NVP instance according to the source information of the NVP node, the VP node sends the first certificate of the VP node to the NVP node; detects whether the second certificate returned by the NVP node is received; if it is detected that the second certificate returned by the NVP node is received, determines to establish a communication connection with the NVP node.

[0120] In this embodiment, it takes at least several seconds to establish a network connection. Therefore, although the above-mentioned new command returns success, the network connection may not have been established yet. The process of establishing a network connection includes a certificate handshake stage, that is, both parties need a certificate issued by the other party to prove their identity in order to establish a connection.

[0121] In one embodiment of the present application, after creating an NVP instance according to a first command, the VP node obtains a second command to delete the NVP node, wherein the second command carries source information of the NVP node; sends a disconnect request to the NVP node according to the second command; upon receiving a disconnect response returned by the NVP node, disconnects the connection with the NVP node; or, starts a timer, sends a disconnect request according to a preset period, and disconnects the connection with the NVP node when the timer reaches the set time but no disconnect response is received.

[0122] In one embodiment of the present application, disconnecting from the NVP node includes: disconnecting the network connection with the NVP node, deleting a configuration file of the NVP node, revoking the NVP node certificate, and deleting the NVP instance.

[0123] In one embodiment of the present application, when the timer reaches the set time but no disconnect response is received, after disconnecting from the NVP node, the VP node generates a notification message and sends the notification message to the user, wherein the notification message is used to instruct the VP node to unilaterally delete the NVP node, and the NVP node also retains the configuration file corresponding to the VP node, the certificate of the VP node, and the VP instance corresponding to the VP node.

[0124] In this embodiment, the deletion operation has not only two return values ​​of success or failure, but also considers an abnormal situation: the VP node is connected to the NVP node, but the network connection is completely disconnected at a certain moment. At this time, the VP node has no way to notify the NVP node to delete it. Until the timer times out, the VP node unilaterally deletes the NVP node. At this time, the VP node needs to notify the upper-level user of this matter, which is the third return value.

[0125] In this embodiment, another data synchronization method is provided, which is applied to an NVP node in a consortium blockchain. The consortium blockchain includes at least one VP node and at least one NVP node. Each VP node can be connected to at least one NVP node for communication. Figure 3 This is the process of the data synchronization method of an embodiment of the present application Figure 2 ,like Figure 3 As shown, the process executed by the NVP node includes the following steps:

[0126] Step S301: Receive a heartbeat message sent by a VP node, and compare a second identifier carried in the heartbeat message with a first identifier of an NVP node.

[0127] The NVP node compares the value of the first identifier with the value of the second identifier and uses the block status of the VP node as a reference to determine whether a handshake phase is required to recover the block status in the NVP node.

[0128] Step S302, when the second identifier is lower than the first identifier, initiate a handshake request to the VP node, wherein the handshake request carries the first identifier and the first block status information, and the value of the first identifier is used to indicate the number of times that the NVP node fails to respond to the heartbeat message sent by the NVP node within a preset time.

[0129] When the second identifier is lower than the first identifier, the NVP node will consider that it is necessary to initiate the steps of establishing a handshake connection with the VP node. The NVP node will send the first identifier and the first block status information, wherein the data contained in the first block status information may be the block height and / or the block hash value, and the VP node generates a handshake response in response to the first block status information to instruct the NVP node to adjust its own block to the block synchronization state with the VP node.

[0130] Step S303, receiving the handshake response returned by the VP node, and adjusting the block of the NVP node to a block synchronization state with the VP node according to the handshake response.

[0131] There may be many different comparison results between VP nodes and NVP nodes in terms of block height and / or block hash value. The handshake response contains synchronization strategies for different comparison results.

[0132] In the above steps S301 to S303, the NVP node compares the value of the first identifier with the value of the second identifier, and determines whether to start the step of establishing a handshake connection with the VP node according to the comparison result of the value of the first identifier and the value of the second identifier, and in the step of establishing a handshake connection with the VP node, the VP block status information is used as a reference, and the VP node formulates a synchronization strategy according to different inspection results and writes a handshake response, and finally sends the handshake response to the NVP node to instruct the NVP node to adjust its own block to the block synchronization state with the VP node. Through the above steps, the problem that the VP node and the NVP node cannot synchronize the block after restoring the normal communication connection in the related art is solved, so that the VP node and the NVP node can synchronize the block after restoring the normal communication connection.

[0133] In one embodiment of the present application, the handshake response carries indication information that the NVP node has abnormal operation, and the NVP node will adjust the block of the NVP node to a preset normal state according to the handshake response.

[0134] In one embodiment of the present application, the handshake response carries the second stable checkpoint information of the VP node, and the NVP node will perform a block rollback operation on the block of the NVP node according to the handshake response until the block state of the NVP node is consistent with the block state indicated by the second stable checkpoint information. The second stable checkpoint information includes the block height and block hash value of the VP node determined after consensus on the blockchain where the VP node is located.

[0135] In one embodiment of the present application, after the NVP node receives the handshake response or block sent by the VP node, the NVP node ends the step of establishing a handshake connection with the VP node.

[0136] In one embodiment of the present application, before the NVP node receives the heartbeat message sent by the VP node, the NVP node will also obtain a third command for adding the VP node, wherein the third command carries the source information of the VP node; create a VP instance according to the third command, wherein the VP instance is used to maintain the block status of the VP node, and the VP instance is associated with the source information of the VP node; and start a thread corresponding to the VP instance.

[0137] In one embodiment of the present application, after the NVP node creates a VP instance according to the third command, the NVP node will also obtain a fourth command to delete the VP node, wherein the fourth command carries the source information of the VP node; send a disconnect request to the VP node according to the fourth command; upon receiving a disconnect response returned by the VP node, disconnect the connection with the VP node; or, start a timer, send a disconnect request according to a preset period, and disconnect the connection with the VP node when the timer reaches the set time but no disconnect response is received.

[0138] In one embodiment of the present application, when the timer reaches the set time but no disconnect response is received, after the NVP node disconnects from the VP node, the NVP node will also generate a notification message and send the notification message to the user, wherein the notification message is used to instruct the NVP node to unilaterally delete the VP node, and the VP node also retains the configuration file corresponding to the NVP node, the certificate of the NVP node, and the NVP instance corresponding to the NVP node.

[0139] In combination with the data synchronization method of the above embodiment, a consortium blockchain system is also provided in this embodiment, which includes: at least one VP node and at least one NVP node, each VP node is communicatively connected with at least one NVP node, and each VP node and each NVP node are used to execute the data synchronization method of the above embodiment.

[0140] The following will introduce the alliance blockchain system through a preferred embodiment.

[0141] (1) In this preferred embodiment, a connection mechanism of a consortium blockchain system is provided, in which a one-to-many connection relationship is established between the VP node and the NVP node. Each connection does not affect each other, and data synchronization operations are performed in parallel. The implementation steps are as follows:

[0142] In the configuration file, the VP node can pre-configure the domain names and IP addresses of multiple NVP nodes, or dynamically add or delete NVP nodes through the command line.

[0143] After the VP node is started, it first creates an empty hash table, which is a mapping of the domain name of the NVP node to the NVP instance. Then the VP node reads the configuration file, creates and starts an NVP instance for each NVP node's IP address, and runs these NVP instances on different threads.

[0144] Each NVP instance is responsible for managing and maintaining the status of a specific NVP node, including the block height, block hash value, and execution status of the NVP node. Since different NVP nodes execute blocks at different speeds, each NVP instance in the NVP instance hash table maintained on the VP node may also be at a different block height.

[0145] After the VP node generates a block, it traverses the above hash table. If it finds that the block height of a certain NVP instance is less than that of the VP node, the NVP instance will send the missing block to the NVP node. Since different NVP instances run on different threads, the block sending speed can be guaranteed.

[0146] Since the network is unstable, the blocks sent to the NVP node may be lost. Therefore, after receiving a batch of blocks and successfully executing them, the NVP node needs to reply a confirmation message to the NVP instance on the VP node. Only after receiving the confirmation message will the NVP instance update the NVP node block height maintained in the NVP instance and try to send the next batch of blocks to it. Otherwise, the NVP instance will keep resending a batch of blocks.

[0147] (2) In this preferred embodiment, a heartbeat mechanism and a handshake mechanism of the alliance blockchain system are provided to ensure the activity of the connection and the response and recovery of abnormal scenarios. Since the network is unstable, abnormal jitter or disconnection may occur between the VP node and the NVP node. Therefore, this preferred embodiment provides a heartbeat mechanism to maintain the activity of the connection, and a handshake mechanism to ensure the state recovery operation after the connection is disconnected. Figure 4 This is a flow chart of the heartbeat / handshake mechanism of a preferred embodiment of the present application. The heartbeat process is as follows:

[0148] The heartbeat is initiated by the VP node, and the NVP node responds after receiving the heartbeat. Each NVP instance in the hash table on the VP node will periodically send a heartbeat message to the NVP node it is responsible for;

[0149] The NVP instance on the VP node sends a heartbeat to the NVP node every 3 seconds. If the NVP node receives the heartbeat, it will reply directly;

[0150] If the NVP instance on the VP node does not receive a heartbeat reply from the NVP node for more than 10 seconds, it is considered that the NVP node has timed out due to some abnormality (such as network disconnection or NVP node downtime);

[0151] At this time, the NVP node on the VP node needs to stop all ongoing retransmissions;

[0152] The NVP instance maintains an increasing integer variable value, denoted as View. The View value is incremented only when the above-mentioned timeout occurs, and the View value is carried in the above-mentioned heartbeat message. Then the NVP node can know the current View value of the VP node through the heartbeat message. If the View in the heartbeat is greater than the View of the NVP node, the NVP node believes that it has timed out and needs to enter the handshake process. In addition, the View value can also be used to identify the round of the message. The heartbeat message, the above-mentioned block message, the handshake message and its reply message all need to contain the current View value, and once both parties receive a message with a View value lower than their current value, they will consider it to be a timed-out message and ignore it directly.

[0153] The handshake process is as follows:

[0154] After the NVP instance on the VP node is disconnected from the NVP node, if the VP node continues to generate blocks, the two sides will be inconsistent after reconnecting, so a handshake phase is required to restore the status.

[0155] The handshake process is triggered by the heartbeat mechanism, that is, the last step of the above heartbeat, when the NVP node finds that the View value of the NVP instance is larger, it triggers the handshake; that is, the heartbeat is triggered by the NVP instance on the VP node, the handshake is triggered by the heartbeat, and the handshake is initiated by the NVP node;

[0156] The handshake message contains the current block height H of the NVP node, the block hash Hash, the latest stable checkpoint Checkpoint, and the View value of the NVP node (the View value is updated to the View value of the NVP instance). Here is an explanation of H, Hash, and Checkpoint: In the blockchain, each block contains a batch of transactions. Each node of the blockchain executes this batch of transactions independently. The corresponding execution results can be represented by Hash. Due to the existence of erroneous nodes, the Hash of different nodes may be inconsistent. If after consensus, it is confirmed that most nodes in the blockchain are at a consistent Hash, then this consistent block height and this consistent Hash are called Checkpoint;

[0157] When the NVP instance receives this handshake message, it first checks the View value. If the View value in the message is lower than the recorded View value, it is considered to be an expired message and is ignored. Otherwise, the handshake message is processed through the following steps:

[0158] Check the Checkpoint in the handshake message. If the hash values ​​are inconsistent, the NVP node is considered to be in an unrecoverable state, so an error is directly reported to the user. In a normal blockchain, the Checkpoint is absolutely correct due to the consensus of the entire network. Therefore, this situation only occurs due to user misoperation. For example, the NVP node first connects to the VP node of a blockchain, and then connects to the VP node of another chain without deleting the data. The data on the two chains are completely inconsistent, so the Checkpoint is naturally inconsistent and cannot be recovered. The user can be notified to perform the correct operation again.

[0159] After passing the Checkpoint check, check the block height; if there is a block with height H on the NVP instance, then verify the block hash. If they are consistent, it means that the NVP node is in a correct state at this time, and the NVP instance can start sending block data starting from H+1 to the NVP node; if they are inconsistent, it is necessary to notify the NVP node to roll back the block, roll back to its latest Checkpoint, and then re-trigger the above handshake process (at this time, the Checkpoint check in the previous step has been passed, so it is consistent after the rollback);

[0160] After sending a handshake, the NVP node needs to wait for the handshake reply from the NVP instance before exiting the handshake process, otherwise it will resend the handshake message regularly. However, the NVP instance will not resend the handshake reply. Therefore, once the handshake reply is lost in the network, the NVP instance believes that the NVP node has returned to normal and starts to prepare to send block events. The NVP node is still in the handshake stage. For this reason, the solution of this embodiment is that the timing for the NVP node to exit the handshake process includes: receiving a handshake reply; receiving a block message.

[0161] (3) In this preferred embodiment, a mechanism for adding and deleting consortium blockchain systems is provided, which enables NVP nodes and VP nodes to flexibly and dynamically add and delete each other. Figure 5 This is a flowchart of adding and deleting nodes according to a preferred embodiment of the present application.

[0162] As mentioned above, a hash table of NVP instances is maintained on the VP node. Each NVP instance manages an NVP node. The steps to dynamically add an NVP node on the VP node are as follows:

[0163] Enter the following command in the process of the VP node: NVP add NVP1 127.0.0.1:50015, which means adding a new NVP node with the domain name NVP1 and the address and port number 127.0.0.1:50015;

[0164] After receiving the command, the VP node first checks whether NVP1 exists in the hash table. If so, the NVP1 already exists and the command execution fails. If not, the following process is entered;

[0165] Create a new NVP instance and add it to the hash table, then try to establish a network connection with it and start sending heartbeats to it, finally write the NVP node information to the configuration file and return the command execution success result. It should be noted here that it takes at least several seconds to establish a network connection, so although the above-mentioned new command returns success, the network connection may not be established yet. The process of establishing a network connection includes the certificate handshake stage, that is, both parties need the certificate issued by the other end to prove their identity before they can establish a connection;

[0166] After receiving the network connection from the VP node, the NVP node also checks whether it is connected to other VP nodes. If there are other connections, the connection of the VP node is rejected because the NVP node can only connect to one VP node at the same time; otherwise, it enters the following process;

[0167] The NVP node creates and starts a listening instance and writes the VP node information into the configuration file. The instance receives heartbeat, block and other messages from the VP node and responds accordingly.

[0168] The above heartbeat process will trigger a handshake, allowing both parties to restore their status and enter the block synchronization process.

[0169] The process of adding a new VP node on the NVP node is similar to the above process, which will not be repeated here. The deletion process is introduced next.

[0170] As mentioned above, the VP node maintains instances of all NVP nodes, and the NVP node also maintains an instance of the VP node. Therefore, if you delete the peer on a node, you need to notify the peer to delete yourself, including clearing resources, disconnecting network connections, modifying configuration files, etc. The following takes the example of a VP node deleting an NVP node:

[0171] Enter the following command in the process of the VP node: NVP remove NVP1, which means to delete an NVP node with the domain name NVP1;

[0172] After receiving the command, the VP node first checks whether NVP1 exists in the hash table. If not, it means that the VP node is not connected to the NVP node and the command execution fails. If it exists, it enters the following process;

[0173] The NVP instance sends a disconnect request to the NVP node and starts a timer. During the timer, the NVP instance will keep trying to resend the disconnect request and wait for the disconnect reply from the NVP node.

[0174] After receiving the disconnection request, the NVP node also starts a timer. During the timer, the NVP node will continue to reply to the disconnection request from the NVP instance. After the timer times out, the VP node is deleted, including: disconnecting the network connection with the VP node, deleting the configuration of the VP node, revoking the certificate of the VP node, and finally deleting the listening instance on the NVP node;

[0175] After receiving a disconnection reply from the NVP node, or after the timer on the NVP instance times out, the NVP instance performs the NVP node deletion operation, including: disconnecting the network connection with the NVP node, deleting the NVP node configuration, revoking the NVP node certificate, and finally deleting the NVP instance;

[0176] It should be noted that the deletion operation has not only two return values, success or failure. Consider an abnormal situation: the VP node is connected to the NVP node, but the network connection is completely disconnected at a certain moment. At this time, the VP node has no way to notify the NVP node to delete itself. It will not be until the timer times out that the NVP node is unilaterally deleted. At this time, it is necessary to notify the upper-level user of this matter, which is the third return value.

[0177] Consider another situation where the disconnection request sent by the NVP node to the VP node is lost. At this time, due to the existence of the timer on the NVP node and the VP node resending the disconnection request, both parties still have the opportunity to exchange messages to complete the mutual deletion.

[0178] Even if the final result is a unilateral deletion, such as the VP node unilaterally deleting the NVP node, the NVP node will no longer have a chance to connect to the VP node because the VP node has revoked the NVP node's certificate. Therefore, the only impact of unilateral deletion is that some information and resources of the VP node are still stored on the NVP node, which requires the user to actively handle.

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

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

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

[0182] In addition, in combination with the data synchronization method provided in the above embodiments, a storage medium may be provided in this embodiment to implement the data synchronization method. The storage medium stores a computer program, and when the computer program is executed by a processor, any one of the data synchronization methods in the above embodiments is implemented.

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

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

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

[0186] The above-mentioned embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of patent protection. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the scope of protection of the present application. Therefore, the scope of protection of the present application shall be subject to the attached claims.

Claims

1. A data synchronization method, applied to VP nodes in a consortium blockchain, characterized in that: The alliance blockchain includes at least one VP node and at least one NVP node, each VP node is in communication connection with at least one NVP node, and the data synchronization method performed by each VP node includes: Receive a handshake request initiated by an NVP node, wherein the handshake request carries a first identifier and first block status information, and the value of the first identifier is used to indicate the number of times that the NVP node fails to respond to a heartbeat message sent by a VP node within a preset time period; Compare the value of the first identifier with the value of the second identifier of the VP node; wherein the value of the second identifier is used to indicate the number of times that the VP node fails to respond to the heartbeat message sent by the NVP node within a preset time period; In the case where the value of the first identifier is not lower than the value of the second identifier, the second block status information of the VP node is obtained, the first block status information and the second block status information are compared, and a handshake response is generated according to the comparison result of the first block status information and the second block status information, wherein the handshake response is used to instruct the NVP node to adjust its own block to a block synchronization state with the VP node, the first block status information includes the first stable checkpoint information of the NVP node, the second block status information includes the second stable checkpoint information of the VP node, the first stable checkpoint information includes the block height and block hash value of the NVP node determined after consensus of the blockchain where the NVP node is located, and the second stable checkpoint information includes the block height and block hash value of the VP node determined after consensus of the blockchain where the VP node is located; Send the handshake response to the NVP node.

2. The data synchronization method according to claim 1, characterized in that: Before receiving the handshake request initiated by the NVP node, the method further includes: Send the heartbeat message to the NVP node according to a preset period; Detect whether a confirmation message returned by the NVP node is received within a preset time period; If it is detected that the confirmation message returned by the NVP node is not received within the preset time, a value of one unit is accumulated in the second identifier, and the accumulated second identifier is written into the next round of heartbeat messages.

3. The data synchronization method according to claim 1, characterized in that: Comparing the first block status information with the second block status information, and generating a handshake response according to the comparison result of the first block status information and the second block status information includes: comparing the first stable checkpoint information and the second stable checkpoint information; In the case that the first stable checkpoint information and the second stable checkpoint information are inconsistent, a first handshake response is generated, wherein the first handshake response carries indication information that the NVP node has abnormal operation.

4. The data synchronization method according to claim 3, characterized in that: The first block status information also includes a first block height and a first block hash value of the latest block in the NVP node, and the method further includes: When the first stable checkpoint information and the second stable checkpoint information are consistent, detecting whether the VP node has a second block with the same height as the first block; If it is detected that the VP node has a second block with the same height as the first block, obtain a second block hash value corresponding to the second block, and compare the first block hash value with the second block hash value; When the first block hash value and the second block hash value are consistent, a second handshake response is generated, wherein the second handshake response carries indication information that the NVP node is in a normal state.

5. The data synchronization method according to claim 4, characterized in that: The method further comprises: In the case that the first block hash value and the second block hash value are inconsistent, a third handshake response is generated, wherein the third handshake response is used to instruct the NVP node to perform a block cut and rollback operation on its own block until the block state of the NVP node is consistent with the block state indicated by the second stable checkpoint information.

6. The data synchronization method according to any one of claims 1 to 5, characterized in that: The method further comprises: After sending the handshake response or block generated by the VP node to the NVP node, the step of establishing a handshake connection with the NVP node is terminated.

7. The data synchronization method according to claim 1, characterized in that: Before receiving the handshake request initiated by the NVP node, the method further includes: Obtain a first command for adding the NVP node, wherein the first command carries source information of the NVP node; Creating an NVP instance according to the first command, wherein the NVP instance is used to maintain the block state of the NVP node, and the NVP instance is associated with source information of the NVP node; Start the thread corresponding to the NVP instance.

8. The data synchronization method according to claim 7, characterized in that: After creating the NVP instance according to the first command, the method further includes: Obtain a second command for deleting the NVP node, wherein the second command carries source information of the NVP node; Sending a disconnect request to the NVP node according to the second command; When receiving a disconnection response returned by the NVP node, disconnecting from the NVP node; or starting a timer, sending the disconnection request according to a preset period, and disconnecting from the NVP node when the timer reaches the set time but the disconnection response is not received.

9. The data synchronization method according to claim 8, characterized in that: When the timer reaches the set time but the disconnection response is not received, after disconnecting the connection with the NVP node, the method further includes: Generate a notification message and send the notification message to the user, wherein the notification message is used to instruct the VP node to unilaterally delete the NVP node, and the NVP node also retains a configuration file corresponding to the VP node, a certificate of the VP node, and a VP instance corresponding to the VP node.

10. The data synchronization method according to claim 7, characterized in that: After starting the thread corresponding to the NVP instance, the method further includes: In the case where the VP node adds a new block, the latest block height of the NVP node is obtained according to the NVP instance, and it is detected whether the latest block height of the NVP node is less than the block height of the current VP node; If it is detected that the latest block height of the NVP node is less than the block height of the current VP node, the newly added block of the VP node is sent to the NVP node.

11. The data synchronization method according to claim 10, characterized in that: Before sending the newly added block of the VP node to the NVP node, the method further includes: Sending the heartbeat message to the NVP node; Detect whether a confirmation message returned by the NVP node is received within a preset time period; If it is detected that a confirmation message returned by the NVP node is received within a preset time period, the newly added block of the VP node is sent to the NVP node, and the block status of the NVP node maintained by the NVP instance is updated.

12. A data synchronization method, applied to NVP nodes in a consortium blockchain, characterized in that: The alliance blockchain includes at least one VP node and at least one NVP node, each VP node is in communication connection with at least one NVP node, and the data synchronization method performed by each NVP node includes: Receive a heartbeat message sent by the VP node, and compare the second identifier carried in the heartbeat message with the first identifier of the NVP node; In the case where the second identifier is lower than the first identifier, a handshake request is initiated to the VP node, wherein the handshake request carries the first identifier and first block status information, the value of the first identifier is used to indicate the number of times that the NVP node has not responded to the heartbeat message sent by the VP node within a preset time length, the value of the second identifier is used to indicate the number of times that the VP node has not responded to the heartbeat message sent by the NVP node within the preset time length, the first block status information includes the first stable checkpoint information of the NVP node, and the first stable checkpoint information includes the block height and block hash value of the NVP node determined after consensus of the blockchain where the NVP node is located; Receive a handshake response returned by the VP node, and adjust the block of the NVP node to a block synchronization state with the VP node according to the handshake response.

13. The data synchronization method according to claim 12, characterized in that: Adjusting the block of the NVP node to a block synchronization state with the VP node according to the handshake response includes: The block of the NVP node is adjusted to a preset normal state according to the handshake response, wherein the handshake response carries indication information that the NVP node has abnormal operation.

14. The data synchronization method according to claim 13, characterized in that: Adjusting the block of the NVP node to a block synchronization state with the VP node according to the handshake response includes: The block of the NVP node is cut and rolled back according to the handshake response until the block status of the NVP node is consistent with the block status indicated by the second stable checkpoint information of the VP node, wherein the handshake response carries the second stable checkpoint information, and the second stable checkpoint information includes the block height and block hash value of the VP node determined after consensus of the blockchain where the VP node is located.

15. The data synchronization method according to any one of claims 12 to 14, characterized in that: The method further comprises: After receiving the handshake response or block sent by the VP node, the step of establishing a handshake connection with the VP node is terminated.

16. The data synchronization method according to claim 12, characterized in that: Before receiving the heartbeat message sent by the VP node, the method further includes: Obtaining a third command for adding the VP node, wherein the third command carries source information of the VP node; Creating a VP instance according to the third command, wherein the VP instance is used to maintain the block status of the VP node, and the VP instance is associated with the source information of the VP node; Start a thread corresponding to the VP instance.

17. The data synchronization method according to claim 16, characterized in that: After creating the VP instance according to the third command, the method further includes: Obtaining a fourth command for deleting the VP node, wherein the fourth command carries source information of the VP node; sending a disconnection request to the VP node according to the fourth command; Upon receiving a disconnect response returned by the VP node, disconnect with the VP node; or, start a timer, send the disconnect request according to a preset period, and disconnect with the VP node if the timer reaches the set time but the disconnect response is not received.

18. The data synchronization method according to claim 17, characterized in that: When the timer reaches a set time but the disconnection response is not received, after disconnecting from the VP node, the method further includes: Generate a notification message and send the notification message to the user, wherein the notification message is used to instruct the NVP node to unilaterally delete the VP node, and the VP node also retains a configuration file corresponding to the NVP node, a certificate of the NVP node, and an NVP instance corresponding to the NVP node.

19. A consortium blockchain system, characterized in that: include: At least one VP node and at least one NVP node, each VP node is communicatively connected to at least one NVP node, each VP node is used to execute the data synchronization method described in any one of claims 1 to 11, and each NVP node is used to execute the data synchronization method described in any one of claims 12 to 18.

20. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to run the computer program to execute the data synchronization method according to any one of claims 1 to 11.

21. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to run the computer program to execute the data synchronization method according to any one of claims 12 to 18.

22. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the data synchronization method according to any one of claims 1 to 11 are implemented.

23. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the data synchronization method according to any one of claims 12 to 18 are implemented.

Images