CN111163148A

CN111163148A - Synchronization method and related equipment for consensus state of block chain system

Info

Publication number: CN111163148A
Application number: CN201911350512.XA
Authority: CN
Inventors: 刘攀
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2019-12-24
Filing date: 2019-12-24
Publication date: 2020-05-15
Anticipated expiration: 2039-12-24
Also published as: CN111163148B

Abstract

An embodiment of the present application provides a synchronization method and related device for a consensus status of a blockchain system, where the blockchain system includes a blockchain and a consensus committee, the consensus committee includes a plurality of node devices participating in consensus, the method is performed by a first node device, and the first node device is any one of the node devices in the consensus committee, and the method includes: acquiring a first consensus state of first node equipment and a second consensus state of second node equipment, wherein the second node equipment is any node equipment except the first node equipment in a consensus committee; acquiring the difference between the first consensus state and the second consensus state, and acquiring a synchronization mode corresponding to the difference; and executing the synchronization operation according to the synchronization mode corresponding to the difference so as to perform state synchronization with the second node equipment. According to the embodiment of the application, synchronization of the consensus state can be kept among all node devices of the consensus committee, and stability of overall performance of the block chain system is guaranteed.

Description

Synchronization method and related equipment for consensus state of block chain system

Technical Field

The present disclosure relates to the field of blockchain technologies, and in particular, to a method for synchronizing consensus status of a blockchain system, a device for synchronizing consensus status of blockchain system, and a computer storage medium.

Background

The blockchain system is a distributed system, and the consensus mechanism is the basis for ensuring the normal operation of the blockchain system. Consensus means agreement; each node device in the blockchain system stores a distributed ledger (namely, blockchain); the consensus process of the blockchain system is a process for keeping a distributed account book consistent among node devices. The consensus process of the blockchain system is typically implemented based on a consensus algorithm, which may include, but is not limited to: a BFT (Byzantine Fault Tolerance) algorithm, a PBFT (Practical Byzantine Fault Tolerance) algorithm, and the like. Due to network failure, device failure or other reasons, the consensus status between each node device participating in consensus in the blockchain system may not be consistent, but the node devices do not synchronize the consensus status, which is not favorable for normal operation of the consensus process, is also not favorable for realizing the consistency of the distributed accounts among each node device in the blockchain system, and affects the stability of the overall performance of the blockchain system.

Disclosure of Invention

The embodiment of the application provides a synchronization method and related equipment for consensus states of a blockchain system, which can keep synchronization of the consensus states among node equipment of a consensus committee and ensure stability of overall performance of the blockchain system.

In one aspect, an embodiment of the present application provides a method for synchronizing consensus status of a blockchain system, where the blockchain system includes a blockchain and a consensus committee, where the consensus committee includes a plurality of node devices participating in consensus, and the method is performed by a first node device, where the first node device is any one of the node devices in the consensus committee, and the method includes:

acquiring a first consensus state of the first node device and a second consensus state of the second node device, wherein the second node device is any node device except the first node device in the consensus committee;

acquiring the difference between the first consensus state and the second consensus state, and acquiring a synchronization mode corresponding to the difference;

and executing synchronous operation according to the synchronous mode corresponding to the difference so as to carry out state synchronization with the second node equipment.

In one aspect, an embodiment of the present application provides a synchronization apparatus for a consensus status of a blockchain system, where the blockchain system includes a blockchain and a consensus committee, where the consensus committee includes a plurality of node devices participating in consensus, the synchronization apparatus operates in a first node device, and the first node device is any one of the node devices in the consensus committee, and the synchronization apparatus includes:

an obtaining unit, configured to obtain a first consensus state of the first node device and a second consensus state of a second node device, where the second node device is any node device except the first node device in the consensus committee; the synchronization mode acquiring unit is used for acquiring a difference between the first consensus state and the second consensus state and acquiring a synchronization mode corresponding to the difference;

and the synchronization unit is used for executing synchronization operation according to the synchronization mode corresponding to the difference so as to carry out state synchronization with the second node equipment.

In one aspect, an embodiment of the present application provides a synchronization apparatus for a consensus state of a blockchain system, where the blockchain system includes a blockchain and a consensus committee, where the consensus committee includes a plurality of node apparatuses participating in consensus, the synchronization apparatus is a first node apparatus, the first node apparatus is any one node apparatus in the consensus committee, and the synchronization apparatus includes an input interface and an output interface, and further includes:

a processor adapted to implement one or more instructions; and the number of the first and second groups,

a computer storage medium having stored thereon one or more instructions adapted to be loaded by the processor and to perform the above-described method of synchronizing consensus states of a blockchain system.

In one aspect, the present disclosure provides a computer storage medium storing one or more instructions adapted to be loaded by a processor and execute the above synchronization method for the consensus status of the blockchain system.

In the embodiment of the application, the first node device acquires the first consensus state of the first node device and the second consensus state of the second node device, when the consensus states between the node devices are different, a proper synchronization mode is determined in time according to the difference, and synchronization operation is executed between the first node device and the second node device according to the determined synchronization mode, so that synchronization of the consensus states between the first node device and the second node device is realized, the synchronization process is favorable for normal operation of the consensus process, and is favorable for realizing consistency of distributed accounts among the node devices in the block chain system, thereby ensuring stability of overall performance of the block chain system.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

FIG. 1 illustrates an architecture diagram of a blockchain system provided by an exemplary embodiment of the present application;

FIG. 2 illustrates a block chain structure provided by an exemplary embodiment of the present application;

fig. 3 is a block chain network architecture diagram provided in an exemplary embodiment of the present application;

FIG. 4 is a flow chart illustrating a method for synchronizing consensus status of a blockchain system according to an exemplary embodiment of the present application;

FIG. 5 is a flow chart illustrating a method for synchronizing consensus status of a blockchain system according to another exemplary embodiment of the present application;

FIG. 6 is a flow chart illustrating a method for synchronizing consensus status of a blockchain system according to another exemplary embodiment of the present application;

fig. 7 is a schematic structural diagram illustrating a synchronization apparatus for a consensus status of a blockchain system according to an exemplary embodiment of the present application;

fig. 8 is a schematic structural diagram illustrating a synchronization apparatus for a consensus status of a blockchain system according to an exemplary embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

FIG. 1 illustrates an architecture diagram of a blockchain system provided by an exemplary embodiment of the present application; as shown in fig. 1, the block chain system mainly includes 5 hierarchies of 101-105 in bottom-to-top order. Wherein:

(1) the informational data and Merkle (Merkle) tree are located at the bottom level 101. The message data here refers to the original data that is requested to be distributed to the blockchain network but has not yet formed blocks, and may be, for example, loan data, transaction data, and the like. These raw data need further processing (e.g., authentication of each node in the blockchain network, hashing, etc.) to be written into the blocks. The Merkle tree is an important component of the blockchain technology, the blockchain does not directly store the plaintext original data, and the original data needs to be hashed and stored in the form of a hash value. The merkel tree is used for organizing hash values formed by hashing a plurality of original data according to a binary tree structure and storing the hash values in a block of blocks.

(2) The blocks are located at level 102. Blocks, i.e. data blocks, into which the information data of the bottom layer 101 is written after further processing. A block is created and then a consensus process is performed, and the block is allowed to be added to the blockchain only if the block consensus is successful. The block chain comprises a plurality of blocks which are connected into a chain structure according to the sequence of the creation time stamps from small to large. The block chain is a distributed account book, and the information data contained in the blocks on the block chain is the account book data of the distributed account book. FIG. 2 illustrates a block chain structure provided by an exemplary embodiment of the present application; as shown in fig. 2, block 201, block 202, and block 203 are connected in sequence in a chain structure. The block 202 is divided into a block header and a block body, where the block header includes the digest value of the previous block 201, the digest value of the current block 202, and the merkel (Merkle) root of the current block. The block body contains the complete data of this block 202 and is organized together in the form of a Merkle tree.

(3) The protocols and mechanisms followed by the blockchain are located at level 103. These protocols may include: P2P (Peer-to-Peer) protocol; mechanisms may include, but are not limited to: broadcast mechanism, consensus mechanism (including core mechanisms such as PoW (Proof Of office) mechanism, POS (Proof Of authority) mechanism).

(4) The blockchain network is located at level 104. The block chain network consists of a plurality of node devices; node devices may include, but are not limited to: a PC (Personal Computer), a server, an ore machine for bitcoin excavation design, a smart phone, a tablet Computer, a mobile Computer, and the like. Fig. 3 is a block chain network architecture diagram provided in an exemplary embodiment of the present application; in the figure, 7 node devices are taken as an example for explanation, each node device in the block chain network is networked in a P2P mode, and the node devices communicate with each other according to a P2P protocol; all the node devices commonly follow a broadcasting mechanism and a common identification mechanism (including core mechanisms such as a PoW mechanism and a POS mechanism), so that the data on the block chain can be ensured to be not tampered and counterfeited, and meanwhile, the characteristics of decentralized center, distrusted trust and the like of the block chain are realized.

(5) The smart contracts are located at upper layer 105. An intelligent contract is a set of scenarios-a countermeasure-type of programmed rules and logic, which is decentralized, information-shareable program code deployed on a blockchain. Each party signing the contract agrees on the contract content, and the contract is deployed in the block chain in the form of an intelligent contract, so that the contract can be automatically executed on behalf of each signing party without any central authority.

Due to the characteristics of decentralized, distributed storage, data non-falsification and non-falsification, more and more business activities (such as loan activities and financial transaction activities) are spread based on the blockchain technology, so as to ensure the fairness and the openness of the business activities by using the characteristics of the blockchain.

The embodiment of the application also relates to a consensus mechanism. The blockchain system is a distributed system, and the consensus mechanism is the basis for ensuring the normal operation of the blockchain system. Consensus means agreement; each node device in the blockchain system stores a distributed ledger (namely, blockchain); the consensus process of the blockchain system is a process for keeping a distributed account book consistent among node devices. All or part of the node devices in the blockchain system can participate in the consensus process of the blockchain system, the node devices participating in the consensus jointly form a consensus committee of the blockchain system, and each node device participating in the consensus serves as a member of the consensus committee; in other words, the consensus committee of the blockchain system includes a plurality of node devices participating in consensus, and the consensus process of the blockchain system is performed by the node devices in the consensus committee, and in particular, the consensus process of the blockchain system is usually implemented based on a consensus algorithm, which may include but is not limited to: BFT algorithm, PBFT algorithm, etc.; each node device in the consensus committee performs a corresponding flow of the consensus process by running a consensus algorithm.

Typically, one or more rounds of consensus are required at a certain block height of the blockchain to achieve agreement between the node devices of the consensus committee. The block height is used to indicate the number of blocks connected on the block chain. The block height is an identifier of the block, which can be used to indicate the position of the block in the block chain; the block height of the starting block in the block chain is default to 0, the block height of the first block after the starting block is 1 (the first block is simply referred to as block 1), the block height of the second block after the starting block is 2 (the second block is simply referred to as block 2), and so on. For example, the block height of the current block of a block chain is 300 (this current block may be referred to as block 300), which means that 300 blocks are already stacked on the starting block, i.e. the number of blocks in the block chain formed from the starting block to block 300 is 301. The common identification process performed at a certain block height of the blockchain refers to a process of common identification of a block to be linked in the blockchain system when the blockchain is at the certain block height, if the common identification of the block to be linked is successful, the block is added to the blockchain, and the block height of the blockchain is + 1; for example: the process of identifying a block at a block height 10 of a block chain refers to a process of identifying a block to be linked in a block chain system when the block chain is at the block height 10, and if the block identification is successful, the block is added to the block chain so that the block height of the block chain is changed from 10 to 11. The round of consensus process can be sequentially divided into three consensus stages according to the execution sequence, wherein the consensus stages comprise a proposal stage, a pre-vote stage and a pre-submission stage. The proposal phase is a phase of generating a target block to be agreed by a node device serving as a proposal node in the consensus committee and broadcasting the target block to other node devices in the consensus committee. The proposed node is a node device generated by election by a plurality of node devices in the consensus committee, and the node device serving as the proposed node is responsible for generating a block to be identified in the proposal stage of the consensus process of the current round and broadcasting the block to be identified to other node devices in the consensus committee for consensus processing; and is also responsible for carrying out consensus processing on the blocks to be consensus. And the non-proposal node only processes the consensus on the blocks to be treated as consensus. The target block to be identified may be a new block created by the proposal node, or may be a block to be identified obtained from the cache space of the proposal node. The pre-voting process is a process of pre-voting for the target block to be agreed by the node equipment in the consensus committee, and if the pre-voting for the block to be agreed is agreed, the pre-voting indicates that the block to be agreed is agreed to be added to the block chain. The pre-commit stage is a stage in which the node device in the consensus committee performs pre-commit processing on the target blocks to be agreed. The pre-commit process is a process of determining whether to approve the pre-commit of the to-be-consensus blocks, and if so, indicating that the to-be-consensus blocks are approved to be added to the block chain. In one round of consensus process, the consensus process of the node devices in the consensus committee on the target blocks to be agreed comprises a pre-voting process and a pre-submission process. Due to network failure, equipment failure or other reasons, the consensus status of each node device in the consensus committee may not be consistent, and the consensus status of a node device refers to information describing the consensus process and the stage of the consensus process in which the node device is currently located. The consensus status comprises a block height and a consensus phase; for example: the consensus state of the node equipment A comprises a block height of 10, and the consensus stage is a pre-vote stage; the consensus status of the node device a describes that the node device a is currently in the pre-vote phase of the consensus process at block height 10. The following steps are repeated: the consensus state of the node device B includes a block height of 10, and the consensus phase is a pre-commit phase, and the consensus state of the node device B describes that the node device B is currently in a pre-commit phase of the consensus process at the block height of 10; the following steps are repeated: the consensus status of node C includes a block height of 11 and the consensus phase is a proposal phase, and the consensus status of node B describes that node B is currently in a proposal phase of the consensus process at block height 11. Comparing the above example, the common knowledge state of the node device a is not consistent with the common knowledge state of the node device B, the node device a and the node device B are in the common knowledge process of the same block height, but the common knowledge stages of the node device a and the node device B are different, and the common knowledge state of the node device a lags behind the common knowledge state of the node device B. Similarly, the consensus state of the node device a is inconsistent with the consensus state of the node device C, and the node device a falls behind the node device C by a block height.

The embodiment of the application provides a synchronization scheme of a consensus state of a block chain system, each node device of a consensus committee exchanges respective consensus states, when the consensus states between the node devices are different, a synchronization mode is determined in time according to the difference, and synchronization operation is executed between the node devices, so that synchronization of the consensus states can be maintained between the node devices, normal proceeding of a consensus process is facilitated, consistency of distributed accounts among the node devices in the block chain system is facilitated, and stability of overall performance of the block chain system is guaranteed.

FIG. 4 is a flow chart illustrating a method for synchronizing consensus status of a blockchain system according to an exemplary embodiment of the present application; in this embodiment, the blockchain system includes a blockchain and a consensus committee, where the consensus committee includes a plurality of node devices participating in consensus, and the method is performed by a first node device, where the first node device is any one of the node devices in the consensus committee, and the method includes the following steps S401 to S404:

s401, obtain a first consensus state of a first node device and a second consensus state of a second node device, where the second node device is any node device except the first node device in the consensus committee.

The first consensus state is used for describing a consensus process and a stage of the consensus process in which the first node equipment is currently located; for example: the first consensus state describes that the first node device is currently in the pre-vote phase of the consensus process at block height 10. Similarly, the second consensus state is used to describe the consensus process and the stage of the consensus process in which the second node device is currently located; for example: the second consensus state describes that the second node device is currently in the pre-commit phase of the consensus process at block height 10. In a possible implementation manner, the first node device may store the consensus statuses of the node devices in the consensus committee in advance, and update the consensus statuses in time, so that the first node device may obtain the first consensus status and the second consensus status from its own storage space in step S401. In another possible implementation manner, the first node device may detect the first consensus state of itself in real time or at regular time, or may interact with the second node device in real time or at regular time to obtain the second consensus state.

S402, acquiring the difference between the first consensus state and the second consensus state.

After obtaining the first common identification state and the second common identification state, the first node device compares whether the first common identification state and the second common identification state are consistent, and if the first common identification state and the second common identification state are consistent, the first node device and the second node device are in the same common identification stage in the same common identification process; this indicates that the first node device and the second node device do not need to synchronize the consensus status, and the process ends. If the first common status is inconsistent with the second common status, the first node device obtains a difference between the first common status and the second common status.

And S403, acquiring a synchronization mode corresponding to the difference.

And S404, executing synchronous operation according to the synchronous mode corresponding to the difference so as to carry out state synchronization with the second node equipment.

In steps S403-S404, the synchronization mode may include a push mode or a pull mode. If the difference indicates that the first common status lags the second common status, the synchronization mode corresponding to the difference may be a pull mode, which requires the first node device to pull the content to be synchronized from the second node device, so that the first node device may implement status update by means of the second node device, thereby maintaining status synchronization between the first node device and the second node device. If the difference indicates that the second common status is behind the first common status, the synchronization mode corresponding to the difference may be a push mode, which requires the first node device to push the content to be synchronized to the second node device, so that the first node device can help the second node device to implement status update, thereby maintaining status synchronization between the first node device and the second node device.

FIG. 5 is a flow chart illustrating a method for synchronizing consensus status of a blockchain system according to another exemplary embodiment of the present application; in this embodiment, the blockchain system includes a blockchain and a consensus committee, where the consensus committee includes a plurality of node devices participating in consensus, and the method is performed by a first node device, where the first node device is any one of the node devices in the consensus committee, and the method includes the following steps S501-S507:

s501, receiving a second consensus state sent by a second node device when a heartbeat cycle of a first node device is reached; the second node apparatus is any one of the node apparatuses except the first node apparatus in the consensus commission.

The heartbeat cycle of the first node device may be set according to actual conditions, for example: the heartbeat period of the first node device may be 2 minutes, 5 minutes, and so on, and taking the heartbeat period of the first node device as 2 minutes as an example, the second node device sends the second consensus status to the first node device every 2 minutes. Similarly, the second node device also has its own heartbeat period (e.g., 3 minutes), and the first node device sends the first consensus state to the second node device every 3 minutes. Therefore, the two node devices interact with each other in the common recognition state, so that the subsequent state synchronization process is facilitated.

S502, detecting whether a second consensus state sent by the second node equipment is consistent with a second consensus state of the second node equipment recorded in a state list stored in a cache space; the status list records the identifier of each node device in the consensus committee, the consensus status of each node device, and the consensus message sent by each node device for the block in the block chain.

And S503, if the two states are not consistent, updating the state list by using the second consensus state sent by the second node device.

In steps S502-S203, the first node device may store a state list in the cache space in advance, where the state list may represent the following table 1:

table 1: status list

Identification of node devices	Consensus status	Consensus messages
			A	Block height H-A, consensus phase N1	Consensus message a1, consensus message a2.
B	Block height H-B, consensus phase N2	Consensus message b1, consensus message b2..
			......	......	......

In each round of consensus process, the first node equipment receives consensus messages sent by other node equipment in the consensus committee, wherein the consensus messages can comprise pre-vote information and pre-submission information; the first node device stores the consensus messages passing the verification into the cache space and updates the first consensus state of the first node device according to the consensus messages; the first node device will cache the complete consensus messages of the last rounds (the number can be set according to actual needs) of the consensus process. In addition, the first node device may also receive the consensus state of the other node device sent by the other node device according to the heartbeat cycle of the first node device, and in combination with the cached consensus message and the consensus state sent by the other node device, may construct the state list shown in table 1 above. Moreover, each time the first node device receives the consensus status and the new consensus message of the other node devices, the first node device checks and updates the content shown in table 1, and the timeliness and validity of table 1 are always maintained.

S504, a first common status of the first node device and a second common status of the second node device are obtained from the status list in the buffer space.

S505, a difference between the first consensus state and the second consensus state is obtained.

In this embodiment, the first common status includes a first block height, and the second common status includes a second block height. Step S505 specifically includes the following steps S11-S13:

s11, comparing the size between the first block height and the second block height.

s12, if the first block height is greater than the second block height, obtaining a positive height difference between the first consensus state and the second consensus state.

s13, if the first block height is less than the second block height, obtaining a negative height difference between the first consensus state and the second consensus state.

In steps s11-s13, both the positive and negative height differences include an identification of a difference patch between the first patch height and the second patch height. The first block height is greater than the second block height, which indicates that the second node device lags behind the first node device by a plurality of block heights, the lagged block height is specifically the difference between the second block height and the first block height, the block indicated by the difference is the difference block, and the identification of the difference block can be the sequence number or identifier of the difference block in the block chain; for example: the first block height is 12 and the second block height is 10, which means that the second node device is two block heights behind the first node device, and the difference blocks are block 11 and block 12. The first block height is smaller than the second block height, which indicates that the first node device lags behind the second node device by a plurality of block heights, the lagged block height is specifically the difference between the first block height and the second block height, the block indicated by the difference is the difference block, and the identification of the difference block can be the sequence number or the identifier of the difference block in the block chain; for example: the first block height is 10 and the second block height is 12, which means that the first node device is two block heights behind the second node device, and the difference blocks are block 11 and block 12.

S506, acquiring a synchronization mode corresponding to the difference.

The synchronous mode corresponding to the forward height difference is a block pushing mode; this approach requires the first node device to push the difference block to be synchronized to the second node device, so that the first node device can help the second node device to implement the status update, thereby maintaining the status synchronization between the first node device and the second node device. The synchronization mode corresponding to the negative height difference is a block pulling mode, which requires the first node device to pull a difference block to be synchronized from the second node device, so that the first node device can realize state update by means of the second node device, and thus the first node device and the second node device keep state synchronization.

And S507, executing synchronous operation according to the synchronous mode corresponding to the difference so as to carry out state synchronization with the second node equipment.

In one embodiment, if the difference is a forward height difference, the synchronization mode is a block push mode; then step S507 specifically includes the following steps S21-S22:

s21, obtaining the difference block and the consensus of the difference block according to the identification of the difference block. The consensus messages of the difference block refer to the consensus messages recorded in table 1, which are sent by each node device in the consensus committee for the difference block, and these consensus messages may include the pre-vote information and the pre-commit information of each node device for the difference block.

s22, sending the difference block and the consensus message of the difference block to the second node device according to the block pushing method, so that the second node device updates the second consensus status by using the consensus message of the difference block and the difference block.

In another embodiment, if the difference is a negative height difference, the synchronization mode is a block pull mode; then step S507 specifically includes the following steps S23-S25:

s23, a chunk get request is generated, the chunk get request carries the identification of the difference chunk.

s24, sending the block acquisition request to the second node device according to the block pulling mode, and enabling the second node device to return the difference block and the consensus message of the difference block.

s25, the first consensus status is updated with the difference block and the consensus message of the difference block.

In the embodiment of the application, the first node device acquires the first consensus state of the first node device and the second consensus state of the second node device, when the consensus states between the node devices have block height differences, a proper synchronization mode is determined in time according to the block height differences, and synchronization operation is executed between the first node device and the second node device according to the determined synchronization mode, so that synchronization of the consensus states between the first node device and the second node device is realized, the synchronization process is favorable for normal operation of the consensus process, the consistency of distributed accounts among the node devices in the block chain system is favorable for realization, and the stability of the overall performance of the block chain system is ensured.

FIG. 6 is a flow chart illustrating a method for synchronizing consensus status of a blockchain system according to another exemplary embodiment of the present application; in this embodiment, the blockchain system includes a blockchain and a consensus committee, the consensus committee includes a plurality of node devices participating in consensus, the method is performed by a first node device, the first node device is any one of the node devices in the consensus committee, and the method includes the following steps S601-S604:

s601, receiving a second consensus state sent by a second node device when the heartbeat cycle of the first node device is reached; the second node apparatus is any one of the node apparatuses except the first node apparatus in the consensus commission.

S602, detecting whether a second consensus state sent by the second node equipment is consistent with a second consensus state of the second node equipment recorded in a state list stored in a cache space; the status list records the identifier of each node device in the consensus committee, the consensus status of each node device, and the consensus message sent by each node device for the block in the block chain.

And S603, if the two states are not consistent, updating the state list by adopting a second consensus state sent by the second node equipment.

S604, a first common status of the first node device and a second common status of the second node device are obtained from the status list in the buffer space.

S605, obtain a difference between the first consensus state and the second consensus state.

In this embodiment, the first consensus status includes a first block height and a consensus phase, and the second consensus status includes a second block height and a consensus phase. The step S605 specifically includes the following steps S31-S34:

s31, comparing the size between the first block height and the second block height.

s32, if the first block height is equal to the second block height, comparing the consensus phase in the first consensus state with the consensus phase in the second consensus state.

s33, if the consensus phase in the second consensus state lags behind the consensus phase in the first consensus state; a forward phase difference between the first consensus state and the second consensus state is obtained.

s34, if the consensus phase in the first consensus state lags the consensus phase in the second consensus state, obtaining a negative phase difference between the first consensus state and the second consensus state.

In steps s31-s34, if the first block height is equal to the second block height, which indicates that the first node device and the second node device are in the process of identifying the same block height, it is further required to compare whether the two node devices are in the same identifying stage. The consensus phase comprises any of the following: a proposal stage, a pre-vote stage and a pre-submission stage; if the consensus phase in the first consensus state is different from the consensus phase in the second consensus state, this is divided into two cases, one is the case when the consensus phase in the first consensus state lags behind the consensus phase in the second consensus state, which is called negative phase difference, and mainly includes either: the consensus stage in the first consensus state is a proposal stage and the consensus stage in the second consensus state is a pre-vote stage; the consensus phase in the first consensus state is a proposal phase and the consensus phase in the second consensus state is a pre-submission phase; the consensus phase in the first consensus state is a pre-vote phase and the consensus phase in the second consensus state is a pre-commit phase. Another situation is where the consensus phase in the second consensus state lags behind the consensus phase in the first consensus state, which is called a forward phase difference, including any of the following: the consensus stage in the second consensus state is a proposal stage and the consensus stage in the first consensus state is a pre-vote stage; the consensus phase in the second consensus state is a proposal phase and the consensus phase in the first consensus state is a pre-commit phase; the consensus phase in the second consensus state is a pre-vote phase and the consensus phase in the first consensus state is a pre-commit phase.

And S606, acquiring a synchronization mode corresponding to the difference.

The synchronous mode corresponding to the forward stage difference is a message pushing mode; this approach requires the first node device to push a consensus message that needs to be synchronized to the second node device, so that the first node device can help the second node device to implement state update, thereby maintaining state synchronization between the first node device and the second node device. The synchronization mode corresponding to the negative-going stage difference is a message pulling mode; this approach requires the first node device to pull a consensus message requiring synchronization from the second node device, such that the first node device can implement a status update by means of the second node device, thereby maintaining status synchronization between the first node device and the second node device.

And S607, executing the synchronization operation according to the synchronization mode corresponding to the difference so as to perform state synchronization with the second node equipment.

In one embodiment, if the difference is a forward stage difference, the synchronization mode is a message push mode; then step S607 specifically includes the following steps S41-S42:

s41, obtaining the consensus message that the first block is highly correlated. Since the first block height is equal to the second block height, the consensus message related to the first block height is the consensus message related to the second block height, where the consensus message related to the first block height refers to the consensus messages sent by the node devices in the consensus committee recorded in table 1 in the multiple rounds of consensus processes of the first block height, and the consensus messages may be pre-vote information or pre-commit information.

s42, sending the consensus message with the height-related to the first block to the second node device according to the message pushing manner, so that the second node device updates the second consensus state by using the consensus message with the height-related to the first block.

In another embodiment, if the difference is a negative phase difference, the synchronization mode is a message pull mode; in this embodiment, optionally, before step S607, the method further includes:

s608, acquiring the consensus status of each node device in the consensus committee; if the consensus status of the node devices greater than the number threshold exists in the consensus committee and the second consensus status of the second node device is in the same consensus phase, step S607 is performed.

The step S608 is provided to prevent an attack action by the malicious node device. The number threshold may be set according to actual conditions, for example, the number threshold may be 50% of the number of node devices in the consensus committee, or 2/3% of the number of node devices in the consensus committee. The first node device may obtain the consensus status of each node device in the consensus committee from table 1, then count the consensus statuses, and determine whether there are node devices greater than the number threshold and the second node device in the same consensus phase of the same consensus process, for example: assuming that the number threshold is 3, the first consensus status describes that the first node device is in the proposal phase of the consensus process of the block height 10, and the second consensus status describes that the second node device is in the pre-submission phase of the consensus process of the block height 10, the first node device may count whether the number of the node devices in the pre-submission phase of the consensus process of the block height 10 in the consensus committee also exceeds 3, and if the number of the node devices exceeds 3, the first node device continues to perform step S607; if the number of the first node device and the number of the second node device do not exceed 3, the second node device may belong to a malicious node device, and the act of the second node device sending the second consensus state to the first node device may belong to an attack act. To ensure the security, the first node device may end the synchronization process of the consensus status, and not continue to execute step S607.

In this embodiment, step S607 specifically includes the following steps S43-S45:

and s43, generating a message acquisition request.

s44, sending the message acquisition request to the second node device according to the message pulling mode, so that the second node device returns the consensus message with the second block height correlation.

s45, the first consensus status is updated with the second highly tile correlated consensus message.

It is to be understood that, in step S607, the first node device may also send a message acquisition request to any other node device except the second node device in the consensus commission and having the same consensus status as the second consensus status, so as to perform synchronous update of the status.

In the embodiment of the application, a first node device obtains a first consensus state of the first node device and a second consensus state of a second node device, when the consensus states between the node devices are different in a consensus stage at the same block height, a proper synchronization mode is determined in time according to the consensus stage difference, and synchronization operation is executed between the first node device and the second node device according to the determined synchronization mode, so that synchronization of the consensus states between the first node device and the second node device is realized, the synchronization process is favorable for normal operation of the consensus process, and is favorable for realizing consistency of distributed accounts among the node devices in a block chain system, and stability of overall performance of the block chain system is ensured.

Fig. 7 is a schematic structural diagram illustrating a synchronization apparatus for a consensus status of a blockchain system according to an exemplary embodiment of the present application; the block chain system comprises a block chain and a consensus committee, wherein the consensus committee comprises a plurality of node devices participating in consensus, and the synchronization device operates in a first node device which is any one of the node devices in the consensus committee. In particular, the synchronization means may be a computer program (comprising program code) running in the first node device, e.g. the synchronization means may be an application software in the first node device; the synchronization means may be used to perform the corresponding steps in the methods shown in fig. 4-6. As shown in fig. 7, the synchronization apparatus includes:

an obtaining unit 701, configured to obtain a first consensus state of a first node device and a second consensus state of a second node device, where the second node device is any node device except the first node device in a consensus committee; the synchronization mode acquiring unit is used for acquiring the difference between the first consensus state and the second consensus state and acquiring the synchronization mode corresponding to the difference;

a synchronization unit 702, configured to perform a synchronization operation according to the synchronization mode corresponding to the difference, so as to perform state synchronization with the second node device.

In one embodiment, the first consensus status comprises a first block height and the second consensus status comprises a second block height; the obtaining unit 701 is specifically configured to:

comparing the size between the first block height and the second block height;

if the first block height is larger than the second block height, acquiring a forward height difference between the first consensus state and the second consensus state;

if the first block height is less than the second block height, acquiring a negative height difference between the first consensus state and the second consensus state;

wherein the positive and negative height differences each comprise an identification of a difference block between the first block height and the second block height.

In one embodiment, the synchronization method corresponding to the forward height difference is a block pushing method; the synchronization unit 702 is specifically configured to:

acquiring the difference block and the consensus information of the difference block according to the identification of the difference block;

and sending the difference block and the consensus information of the difference block to the second node equipment according to a block pushing mode, so that the second node equipment updates the second consensus state by adopting the difference block and the consensus information of the difference block.

In one embodiment, the synchronization mode corresponding to the negative height difference is a block pull mode; the synchronization unit 702 is specifically configured to:

generating a block acquisition request, wherein the block acquisition request carries the identification of the difference block;

sending the block acquisition request to the second node equipment according to a block pulling mode, and enabling the second node equipment to return the difference block and the consensus information of the difference block;

and updating the first consensus state by adopting the difference block and the consensus information of the difference block.

In one embodiment, the consensus status further comprises a consensus phase; the obtaining unit 701 is further specifically configured to:

if the first block height is equal to the second block height, comparing the consensus stage in the first consensus state with the consensus stage in the second consensus state;

if the consensus phase in the second consensus state lags behind the consensus phase in the first consensus state; acquiring a forward stage difference between the first consensus state and the second consensus state;

if the consensus phase in the first consensus state lags behind the consensus phase in the second consensus state, a negative phase difference between the first consensus state and the second consensus state is obtained.

In one embodiment, the consensus phase comprises any of: a proposal stage, a pre-vote stage and a pre-submission stage;

the case where the consensus phase in the first consensus state lags behind the consensus phase in the second consensus state includes any of: the consensus stage in the first consensus state is a proposal stage and the consensus stage in the second consensus state is a pre-vote stage; the consensus phase in the first consensus state is a proposal phase and the consensus phase in the second consensus state is a pre-submission phase; the consensus stage in the first consensus state is a pre-vote stage and the consensus stage in the second consensus state is a pre-commit stage;

the case where the consensus phase in the second consensus state lags behind the consensus phase in the first consensus state includes any of: the consensus stage in the second consensus state is a proposal stage and the consensus stage in the first consensus state is a pre-vote stage; the consensus phase in the second consensus state is a proposal phase and the consensus phase in the first consensus state is a pre-commit phase; the consensus stage in the second consensus state is a pre-vote stage and the consensus stage in the first consensus state is a pre-commit stage;

in one embodiment, the synchronization mode corresponding to the forward stage difference is a message pushing mode; the synchronization unit 702 is specifically configured to:

acquiring a consensus message highly related to a first block;

and sending the consensus information highly related to the first block to the second node equipment according to a message pushing mode, so that the second node equipment updates the second consensus state by adopting the consensus information highly related to the first block.

In one embodiment, the synchronization mode corresponding to the negative-going phase difference is a message pull mode; the synchronization unit 702 is specifically configured to:

generating a message acquisition request;

sending the message acquisition request to the second node equipment according to a message pulling mode, and enabling the second node equipment to return the consensus message highly related to the second block;

and updating the first consensus state by using the consensus information highly related to the second block.

In an embodiment, the obtaining unit 701 is further configured to:

acquiring a consensus state of each node device in a consensus committee;

if the consensus status of the node devices greater than the number threshold and the second consensus status of the second node device are in the same consensus phase in the consensus committee, the trigger synchronization unit 702 performs the synchronization operation according to the synchronization mode corresponding to the difference.

In an embodiment, the obtaining unit 701 is specifically configured to:

acquiring a first consensus state of the first node device and a second consensus state of the second node device from a state list in a cache space;

the status list records the identifier of each node device in the consensus committee, the consensus status of each node device, and the consensus message sent by each node device for the block in the block chain.

In an embodiment, the synchronization apparatus further includes an updating unit 703, where the updating unit 703 is configured to:

receiving a second consensus state sent by a second node device when a heartbeat period of a first node device is reached;

detecting whether a second consensus state sent by the second node equipment is consistent with a second consensus state of the second node equipment recorded in the state list;

and if the two states are not consistent, updating the state list by adopting a second consensus state sent by the second node equipment.

According to an embodiment of the present application, the units in the synchronization apparatus shown in fig. 7 may be respectively or entirely combined into one or several other units to form the synchronization apparatus, or some unit(s) may be further split into multiple functionally smaller units to form the synchronization apparatus, which may achieve the same operation without affecting the achievement of the technical effect of the embodiment of the present application. The units are divided based on logic functions, and in practical application, the functions of one unit can be realized by a plurality of units, or the functions of a plurality of units can be realized by one unit. In other embodiments of the present application, the synchronization apparatus may also include other units, and in practical applications, these functions may also be implemented by being assisted by other units, and may be implemented by cooperation of multiple units. According to another embodiment of the present application, the synchronization apparatus as shown in fig. 7 may be constructed by running a computer program (including program codes) capable of executing the steps involved in the respective methods as shown in fig. 4 to 6 on a general-purpose computing device such as a computer including a processing element such as a Central Processing Unit (CPU), a random access storage medium (RAM), a read-only storage medium (ROM), and a storage element, and the synchronization method of the embodiment of the present application may be implemented. The computer program may be recorded on a computer-readable recording medium, for example, and loaded and executed in the above-described computing apparatus via the computer-readable recording medium.

Fig. 8 is a schematic structural diagram illustrating a synchronization apparatus for a consensus status of a blockchain system according to an exemplary embodiment of the present application. The blockchain system comprises a blockchain and a consensus committee, wherein the consensus committee comprises a plurality of node devices participating in consensus, the synchronization device is a first node device, and the first node device is any one of the node devices in the consensus committee. Referring to fig. 8, the synchronization device includes at least a processor 801, an input device 802, an output device 803, and a computer storage medium 804. The processor 801, the input device 802, the output device 803, and the computer storage medium 804 may be connected by a bus or other means. A computer storage medium 804 may be stored in the memory of the synchronization device, the computer storage medium 804 being used for storing a computer program comprising program instructions, the processor 801 being used for executing the program instructions stored by the computer storage medium 804. Processor 801 (or CPU)

(Central Processing Unit)) is a computing core and a control core of a synchronization device, which is adapted to implement one or more instructions, and in particular to load and execute one or more instructions to implement a corresponding method flow or a corresponding function.

An embodiment of the present application further provides a computer storage medium (Memory), which is a Memory device in the synchronization device and is used to store programs and data. It is understood that the computer storage medium herein may include both a built-in storage medium in the synchronization device and, of course, an extended storage medium supported by the synchronization device. The computer storage medium provides a storage space that stores an operating system of the synchronization apparatus. Also stored in the memory space are one or more instructions, which may be one or more computer programs (including program code), suitable for loading and execution by the processor 801. The computer storage medium may be a high-speed RAM memory, or may be a non-volatile memory (non-volatile memory), such as at least one disk memory; and optionally at least one computer storage medium located remotely from the processor.

In one embodiment, the computer storage medium has one or more instructions stored therein; the processor 801 loads and executes one or more instructions stored in the computer storage medium to implement the corresponding steps in the synchronization method embodiment of the consensus status of the blockchain system; in particular implementations, one or more instructions in the computer storage medium are loaded and executed by the processor 801 to perform the steps of:

In one embodiment, the first consensus status comprises a first block height and the second consensus status comprises a second block height; when one or more instructions in the computer storage medium are loaded by the processor 801 and the step of obtaining the difference between the first consensus state and the second consensus state is performed, the following steps are specifically performed:

comparing the size between the first block height and the second block height;

In one embodiment, the synchronization method corresponding to the forward height difference is a block pushing method; when one or more instructions in the computer storage medium are loaded by the processor 801 and the step of performing the synchronization operation in the synchronization manner corresponding to the difference is performed, the following steps are specifically performed:

In one embodiment, the synchronization mode corresponding to the negative height difference is a block pull mode; when one or more instructions in the computer storage medium are loaded by the processor 801 and the step of performing the synchronization operation in the synchronization manner corresponding to the difference is performed, the following steps are specifically performed:

In one embodiment, the consensus status further comprises a consensus phase; when one or more instructions in the computer storage medium are loaded by the processor 801 and the step of obtaining a difference between the first consensus state and the second consensus state is performed, the steps of:

in one embodiment, the synchronization mode corresponding to the forward stage difference is a message pushing mode; when one or more instructions in the computer storage medium are loaded by the processor 801 and the step of performing the synchronization operation in the synchronization manner corresponding to the difference is performed, the following steps are specifically performed:

acquiring a consensus message highly related to a first block;

In one embodiment, the synchronization mode corresponding to the negative-going phase difference is a message pull mode; when one or more instructions in the computer storage medium are loaded by the processor 801 and the step of performing the synchronization operation in the synchronization manner corresponding to the difference is performed, the following steps are specifically performed:

generating a message acquisition request;

In one embodiment, before one or more instructions in the computer storage medium are loaded by the processor 801 and the step of performing the synchronization operation in the synchronization manner corresponding to the difference is performed, the following steps are performed:

acquiring a consensus state of each node device in a consensus committee;

and if the consensus state of the node equipment with the number greater than the threshold value and the second consensus state of the second node equipment are in the same consensus stage in the consensus committee, executing the synchronization operation according to the synchronization mode corresponding to the difference.

In one embodiment, when one or more instructions in the computer storage medium are loaded by the processor 801 and the step of obtaining the first consensus state of the first node device and the second consensus state of the second node device is performed, the following steps are specifically performed:

In one embodiment, one or more instructions in a computer storage medium are loaded by processor 801 and further perform the steps of:

The above disclosure is only for the purpose of illustrating the preferred embodiments of the present invention, and it is therefore to be understood that the invention is not limited by the scope of the appended claims.

Claims

1. A method for synchronizing consensus status of a blockchain system, the blockchain system comprising a blockchain and a consensus committee, the consensus committee comprising a plurality of node devices participating in consensus, the method being performed by a first node device, the first node device being any one of the consensus committee, the method comprising:

2. The method of claim 1, wherein the first consensus status comprises a first block height, and the second consensus status comprises a second block height; the obtaining a difference between the first consensus state and the second consensus state comprises:

comparing a size between the first block height and the second block height;

if the first block height is greater than the second block height, acquiring a forward height difference between the first consensus state and the second consensus state;

3. The method of claim 2, wherein the synchronization method corresponding to the forward height difference is a block pushing method; the executing the synchronization operation according to the synchronization mode corresponding to the difference comprises:

and sending the difference block and the consensus information of the difference block to the second node equipment according to the block pushing mode, so that the second node equipment updates the second consensus state by adopting the difference block and the consensus information of the difference block.

4. The method of claim 2, wherein the negative height difference corresponds to a synchronization mode that is a block pull mode; the executing the synchronization operation according to the synchronization mode corresponding to the difference comprises:

sending the block acquisition request to the second node equipment according to the block pulling mode, so that the second node equipment returns the difference block and the consensus information of the difference block;

updating the first consensus status with the difference block and a consensus message of the difference block.

5. The method of claim 2, wherein the consensus state further comprises a consensus phase; the obtaining a difference between the first consensus status and the second consensus status further comprises:

comparing a consensus phase in the first consensus state with a consensus phase in the second consensus state if the first block height and the second block height are equal;

if the consensus phase in the second consensus state lags behind the consensus phase in the first consensus state; obtaining a forward stage difference between the first consensus state and the second consensus state;

if the consensus phase in the first consensus state lags behind the consensus phase in the second consensus state, obtaining a negative phase difference between the first consensus state and the second consensus state.

6. The method of claim 5, wherein the consensus phase comprises any one of: a proposal stage, a pre-vote stage and a pre-submission stage;

the case where the consensus phase in the first consensus state lags behind the consensus phase in the second consensus state comprises any of: the consensus stage in the first consensus state is a proposal stage and the consensus stage in the second consensus state is a pre-vote stage; the consensus phase in the first consensus state is a proposal phase and the consensus phase in the second consensus state is a pre-submission phase; the consensus phase in the first consensus state is a pre-vote phase and the consensus phase in the second consensus state is a pre-commit phase;

the case where the consensus phase in the second consensus state lags behind the consensus phase in the first consensus state comprises any of: the consensus stage in the second consensus state is a proposal stage and the consensus stage in the first consensus state is a pre-vote stage; the consensus phase in the second consensus state is a proposal phase and the consensus phase in the first consensus state is a pre-submission phase; a consensus phase in the second consensus state is a pre-vote phase and a consensus phase in the first consensus state is a pre-commit phase.

7. The method of claim 5, wherein the synchronization mode corresponding to the forward phase difference is a message pushing mode; the executing the synchronization operation according to the synchronization mode corresponding to the difference comprises:

acquiring the consensus information highly related to the first block;

and sending the consensus information highly related to the first block to the second node equipment according to the message pushing mode, so that the second node equipment updates the second consensus state by adopting the consensus information highly related to the first block.

8. The method of claim 5, wherein the synchronization mode corresponding to the negative-going phase difference is a message pull mode; the executing the synchronization operation according to the synchronization mode corresponding to the difference comprises:

generating a message acquisition request;

sending the message acquisition request to the second node equipment according to the message pulling mode, so that the second node equipment returns the consensus message highly related to the second block;

updating the first consensus status with the second block highly correlated consensus message.

9. The method of claim 8, wherein before performing the synchronization operation in the synchronization manner corresponding to the difference, further comprising:

acquiring the consensus state of each node device in the consensus committee;

10. The method of claim 1, wherein the obtaining the first consensus state of the first node device and the second consensus state of the second node device comprises:

acquiring a first common identification state of the first node device and a second common identification state of the second node device from a state list in a cache space;

wherein, the status list records an identifier of each node device in the consensus committee, a consensus status of each node device, and a consensus message sent by each node device for a block in the block chain.

11. The method of claim 10, wherein the method further comprises:

receiving a second consensus state sent by the second node device when the heartbeat period of the first node device is reached;

and if the two common identification states are not consistent, updating the state list by adopting a second common identification state sent by the second node equipment.

12. A synchronization apparatus of a consensus status of a blockchain system, the blockchain system comprising a blockchain and a consensus committee, the consensus committee comprising a plurality of node devices participating in consensus, the synchronization apparatus operating in a first node device, the first node device being any one of the node devices in the consensus committee, the synchronization apparatus comprising:

13. A synchronization apparatus of a consensus status of a blockchain system, the blockchain system comprising a blockchain and a consensus committee, the consensus committee comprising a plurality of node apparatuses participating in consensus, the synchronization apparatus being a first node apparatus being any one of the node apparatuses in the consensus committee, the synchronization apparatus comprising an input interface and an output interface, further comprising:

computer storage medium having stored thereon one or more instructions adapted to be loaded by the processor and to perform a method of synchronization of consensus states of a blockchain system according to any of claims 1-11.

14. A computer storage medium having stored thereon one or more instructions adapted to be loaded by a processor and to perform a method of synchronizing consensus states of a blockchain system according to any of claims 1-11.