Block chain consensus state synchronization method and device, equipment and medium

Abstract

The embodiment of the invention provides a block chain consensus state synchronization method and device, equipment and a medium. The block chain consensus state synchronization method comprises the steps that a first consensus node acquires a first consensus state message of a second consensus node; the first consensus state message is a byte array containing a consensus state and a consensus message bitmap; analyzing bytes occupied by the consensus state to obtain a first block height and a consensus stage of a second consensus node; the consensus process of the first block height comprises a first consensus stage and a second consensus stage; if the second consensus node is in a second consensus stage, bytes occupied by the consensus message bitmap are analyzed, and a to-be-reissued node set of the second consensus node is obtained; and if the first consensus node contains the consensus message of the consensus node in the to-be-reissued node set in the second consensus stage, sending the consensus message to the second consensus node. By adopting the embodiment of the invention, the network broadband occupation amount in the consensus process can be reduced, and the consensus performance of the block chain is further improved.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a blockchain consensus state synchronization method, device, equipment and medium. Background Art

[0002] In blockchain technology, each newly generated block needs to execute the consensus process in the blockchain network. A complete consensus process can include at least one stage. The consensus nodes participating in the consensus need to broadcast consensus messages (for example, block voting information) at each stage. The consensus process will continue only after each consensus node receives a sufficient number of consensus messages from other consensus nodes. If consensus node A fails to receive a sufficient number of consensus messages due to network packet loss or other failures, then the consensus node A will temporarily be unable to continue the consensus process. Therefore, it is necessary to resend the consensus message based on the consensus status of consensus node A to synchronize the consensus status between the consensus nodes.

[0003] In the current consensus state synchronization scheme, a timer is set to send the consensus state message of the current consensus node every 1 second. The consensus state message needs to include: the current consensus node's identifier, block height, consensus stage steps, proposal hash (Hash) and voting set, which includes all voting information received by the current consensus node at each stage. When there are many nodes participating in the consensus in the blockchain network, the message body of the consensus state message is very large, especially the number of voting information contained in the voting set, which will occupy a lot of network bandwidth and easily cause network congestion, thereby affecting the consensus performance of the blockchain. Summary of the invention

[0004] The embodiments of the present application provide a blockchain consensus state synchronization method, apparatus, device, and medium, which can reduce the network bandwidth occupancy during the consensus process, thereby improving the consensus performance of the blockchain.

[0005] On the one hand, an embodiment of the present application provides a blockchain consensus state synchronization method, which is executed by a first consensus node and includes:

[0006] Obtain the first consensus status message corresponding to the second consensus node; the first consensus status message is a byte array containing the consensus status and the consensus message bitmap, and the consensus message bitmap in the first consensus status message is used to represent the consensus message reception status of the second consensus node during the consensus process;

[0007] Parse the bytes occupied by the consensus status in the first consensus status message to obtain the first block height and consensus stage corresponding to the second consensus node; the consensus process of the first block height includes the first consensus stage and the second consensus stage;

[0008] If the consensus stage of the second consensus node is the second consensus stage, the consensus message bitmap in the first consensus status message is parsed according to the number of consensus nodes corresponding to the first block height to obtain the set of nodes to be reissued corresponding to the second consensus node;

[0009] If the first consensus node includes the consensus message of the consensus node in the to-be-reissued node set in the second consensus phase, the consensus message of the consensus node in the to-be-reissued node set in the second consensus phase is sent to the second consensus node.

[0010] On the one hand, an embodiment of the present application provides a blockchain consensus state synchronization device, which can be run in a first consensus node, and includes:

[0011] A message acquisition module, used to acquire a first consensus status message corresponding to the second consensus node; the first consensus status message is a byte array containing a consensus status and a consensus message bitmap, and the consensus message bitmap in the first consensus status message is used to represent the consensus message reception status of the second consensus node during the consensus process;

[0012] A first parsing module is used to parse the bytes occupied by the consensus state in the first consensus state message to obtain the first block height and consensus stage corresponding to the second consensus node; the consensus process of the first block height includes the first consensus stage and the second consensus stage;

[0013] A second parsing module is used to parse the consensus message bitmap in the first consensus status message according to the number of consensus nodes corresponding to the first block height if the consensus stage of the second consensus node is the second consensus stage, and obtain a set of nodes to be reissued corresponding to the second consensus node;

[0014] The voting reissue module is used to send the consensus message of the consensus node in the set of nodes to be reissued in the second consensus stage to the second consensus node if the first consensus node contains the consensus message of the consensus node in the set of nodes to be reissued in the second consensus stage.

[0015] The first parsing module is specifically used for:

[0016] Determine the height byte interval and step byte used to represent the consensus state in the first consensus state message, parse the bytes in the height byte interval, and obtain the first block height corresponding to the second consensus node;

[0017] The step bytes are parsed to obtain byte parsing results, and the consensus stage corresponding to the second consensus node is determined according to the byte parsing results.

[0018] Among them, the first consensus stage includes the proposal stage, and the second consensus stage includes the pre-voting stage and the pre-submission stage;

[0019] The first parsing module determines the consensus stage corresponding to the second consensus node according to the byte parsing result, including:

[0020] If the byte parsing result is the first value, it is determined that the consensus stage corresponding to the second consensus node is the proposal stage;

[0021] If the byte parsing result is the second value, it is determined that the consensus stage corresponding to the second consensus node is the pre-voting stage;

[0022] If the byte parsing result is the third value, it is determined that the consensus stage corresponding to the second consensus node is the pre-commit stage.

[0023] The second parsing module is specifically used for:

[0024] If the consensus stage of the second consensus node is the second consensus stage, the consensus committee corresponding to the first block height is obtained, and the number of consensus nodes in the consensus committee corresponding to the first block height is counted;

[0025] According to the number of consensus nodes, determine the bitmap byte interval corresponding to the consensus message bitmap in the first consensus status message;

[0026] According to the value of each bit contained in the bitmap byte interval, the set of nodes to be reissued corresponding to the second consensus node is determined.

[0027] The second parsing module determines the set of nodes to be reissued corresponding to the second consensus node according to the values ​​of each bit contained in the bitmap byte interval, including:

[0028] Determine the bit sorting position of the bit with a value of zero in the bitmap byte interval according to the value of each bit contained in the bitmap byte interval;

[0029] According to the node index information corresponding to the bit sorting position, the set of nodes to be reissued is determined in the consensus committee corresponding to the first block height; one consensus node in the consensus committee corresponding to the first block height corresponds to one node index information, and one node index information corresponds to one bit in the bitmap byte interval.

[0030] The device further comprises:

[0031] The index determination module is used to sort the consensus nodes in the consensus committee corresponding to the first block height according to the node sorting strategy, obtain a first node sorting list, and create node index information for the consensus nodes in the first node sorting list.

[0032] The device further comprises:

[0033] An index determination module, configured to, during the consensus process of the second block height, if it is detected that the consensus committee corresponding to the second block height is the same as the consensus committee corresponding to the first block height, continue to retain the node index information corresponding to the consensus node in the first node sorting list; and

[0034] If it is detected that the consensus committee corresponding to the second block height is different from the consensus committee corresponding to the first block height, the consensus nodes in the consensus committee corresponding to the second block height are sorted according to the node sorting strategy to obtain a second consensus node sorting list, and node index information is created for the consensus nodes in the second consensus node sorting list.

[0035] The second parsing module is also used for:

[0036] If the consensus stage of the second consensus node is the first consensus stage, the bytes occupied by the consensus message bitmap in the first consensus status message are parsed to obtain a bitmap parsing result;

[0037] If the bitmap parsing result is zero, it is determined that the second consensus node has not received the proposal data corresponding to the first block height;

[0038] If the first consensus node contains proposal data corresponding to the first block height, the proposal data corresponding to the first block height is sent to the second consensus node.

[0039] Among them, the second consensus stage includes the pre-voting stage, and the consensus message of the pre-voting stage is the pre-voting information;

[0040] The voting reissue module is specifically used for:

[0041] If the first consensus node contains the pre-voting information of the consensus nodes in the set of nodes to be reissued in the pre-voting stage, then the pre-voting information corresponding to the consensus nodes in the set of nodes to be reissued is obtained from the pre-voting information set corresponding to the first consensus node;

[0042] Send the pre-voting information corresponding to the consensus node in the set of nodes to be reissued to the second consensus node.

[0043] Among them, the second consensus stage includes a pre-submission stage, and the consensus message of the pre-submission stage is the pre-submission information;

[0044] The voting reissue module is specifically used for:

[0045] If the first consensus node contains the pre-submission information of the consensus node in the set of nodes to be reissued in the pre-submission stage, then the pre-submission information corresponding to the consensus node in the set of nodes to be reissued is obtained from the pre-submission information set corresponding to the first consensus node;

[0046] Send the pre-submission information corresponding to the consensus node in the set of nodes to be reissued to the second consensus node.

[0047] The device further comprises:

[0048] A consensus status message generation module, configured to fill the first block height in binary form to the height byte interval if the first consensus node is in the first consensus stage corresponding to the first block height and the first consensus node has received proposal data of the first block height; and

[0049] Also used to map the first consensus stage into a first value, and fill the first value into the step byte in binary form; and,

[0050] It is also used to map the received state corresponding to the proposal data of the first block height into a first value, and fill the first value into the consensus message bitmap in binary form; and

[0051] It is also used to combine the height byte interval filled with the first block height, the step byte filled with the first value, and the consensus message bitmap filled with the first value into a second consensus status message corresponding to the first consensus node.

[0052] The device further comprises:

[0053] A consensus status message generation module, configured to fill the first block height in binary form into the height byte interval, map the pre-voting stage into a second value, and fill the second value in binary form into the step byte if the first consensus node is in the pre-voting stage corresponding to the first block height; and

[0054] It is also used to obtain a pre-voting information set corresponding to the first block height, and obtain a first node sorting list corresponding to the first block height, and determine the bitmap byte interval corresponding to the consensus message bitmap according to the number of consensus nodes corresponding to the first node sorting list; the first node sorting list is obtained by sorting the consensus nodes in the consensus committee corresponding to the first block height; and,

[0055] It is also used to match the pre-voting information in the pre-voting information set with the consensus node in the first node sorting list to obtain a voting information matching result; and,

[0056] It is also used to determine the value of the bit contained in the bitmap byte interval according to the voting information matching result and the correspondence between the consensus nodes in the first node sorting list and the bits contained in the bitmap byte interval; and,

[0057] It is also used to combine the height byte interval filled with the first block height, the step byte filled with the second value, and the bitmap byte interval into a second consensus status message corresponding to the first consensus node.

[0058] On one hand, an embodiment of the present application provides a computer device, including a memory and a processor, wherein the memory is connected to the processor, the memory is used to store a computer program, and the processor is used to call the computer program so that the computer device executes the method provided in the above aspect of the embodiment of the present application.

[0059] On one hand, an embodiment of the present application provides a computer-readable storage medium, in which a computer program is stored. The computer program is suitable for being loaded and executed by a processor, so that a computer device with a processor executes the method provided in the above aspect of the embodiment of the present application.

[0060] According to one aspect of the present application, a computer program product or computer program is provided, the computer program product or computer program includes computer instructions, the computer instructions are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the method provided in the above aspect.

[0061] In the embodiment of the present application, the first consensus node can obtain the first consensus status message corresponding to the second consensus node, and the first consensus status message is a byte array containing the consensus status and the consensus message bitmap. That is to say, by adopting the structure of the byte array to represent the first consensus status message, the data volume of the first consensus status message can be compressed. Further, the bytes occupied by the consensus status are parsed to obtain the first block height and consensus stage corresponding to the second consensus node. The consensus process of the first block height includes the first consensus stage and the second consensus stage; if the consensus stage of the second consensus node is the second consensus stage, the bytes occupied by the consensus message bitmap are parsed according to the number of consensus nodes corresponding to the first block height, and the set of nodes to be reissued corresponding to the second consensus node is obtained. If the first consensus node contains the consensus message of the consensus node in the set of nodes to be reissued in the second consensus stage, it can be sent to the second consensus node to synchronize the consensus state between the first consensus node and the second consensus node, which can reduce the network bandwidth occupied during the consensus state synchronization process, and thus improve the consensus performance of the blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0063] Figure 1 This is a schematic diagram of the architecture of a blockchain network provided in an embodiment of the present application;

[0064] Figure 2 It is a schematic diagram of a consensus process in a blockchain network provided by an embodiment of the present application;

[0065] Figure 3 This is a flowchart of a blockchain consensus state synchronization method provided by an embodiment of the present application. Figure 1 ;

[0066] Figure 4 This is a schematic diagram of the structure of a consensus status message provided in an embodiment of the present application;

[0067] Figure 5 This is a schematic diagram of determining node index information corresponding to a consensus node provided by an embodiment of the present application;

[0068] Figure 6 This is a schematic diagram of generating a consensus status message provided by an embodiment of the present application;

[0069] Figure 7 This is a schematic diagram of the structure of a consensus status message in the proposal stage provided in an embodiment of the present application;

[0070] Figure 8 This is a schematic diagram of the structure of a consensus status message in the pre-voting phase provided by an embodiment of the present application;

[0071] Fig. 9 It is a schematic diagram of the structure of a consensus status message in the pre-commitment phase provided by an embodiment of the present application;

[0072] Fig.10 This is a flowchart of a blockchain consensus state synchronization method provided by an embodiment of the present application. Figure 2 ;

[0073] Fig.11 It is a structural diagram of a blockchain consensus state synchronization device provided in an embodiment of the present application;

[0074] Fig.12 It is a structural diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0075] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0076] The embodiments of this application involve blockchain technology. Blockchain is a decentralized infrastructure with distributed storage characteristics. Specifically, it is a data structure that organizes data blocks in a time sequence in a manner similar to a linked list. It can safely store data that has a sequential relationship and can be verified within the system, and cryptographically ensure that the data cannot be tampered with or forged.

[0077] See also Figure 1 , Figure 1 This is a schematic diagram of the architecture of a blockchain network provided in an embodiment of the present application; the blockchain network may be composed of multiple blockchain nodes, and the present application does not limit the number of blockchain nodes included in the blockchain network. Figure 1 As shown, the blockchain network is illustrated by taking 6 blockchain nodes (e.g., node 1, node 2, node 3, node 4, node 5, and node 6) as an example. Each blockchain node in the blockchain network is networked in a peer-to-peer manner, and the blockchain nodes can communicate with each other according to the peer-to-peer network protocol. Each blockchain node in the blockchain network jointly follows the broadcast mechanism and consensus mechanism to jointly ensure that the data in the blockchain cannot be tampered with or forged, and at the same time realize the characteristics of decentralization and trustlessness of the blockchain. Among them, the consensus mechanism may include but is not limited to core mechanisms such as PoW (Proof Of Work) mechanism and POS (Proof Of Stake) mechanism.

[0078] It should be understood that each blockchain node in the blockchain network can be a terminal device or a server. Terminal devices may include, but are not limited to, tablet computers, laptops, PDAs, mobile internet devices (MID), wearable devices (such as smart watches, smart bracelets, etc.), smart voice interaction devices, smart home appliances (such as smart TVs, etc.), vehicle-mounted devices, aircraft, and other electronic devices that support the operation of blockchain systems. The server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDN), and basic cloud computing services such as big data and artificial intelligence platforms. This application does not limit the type of server.

[0079] It is understandable that information data under the chain can be requested to be published to the blockchain network. The information data here can refer to the original data that has not formed a block (for example, transaction data); these information data need to be further processed (for example, verified by each blockchain node in the blockchain network, hash operations, etc.) before they can be written into the block. After a block (which can be called a data block) is created, it needs to be processed by consensus. When the block consensus is successful, the block is allowed to be added to the blockchain. The blockchain can contain multiple blocks, which are connected into a linked structure in the order of creation timestamps from small to large. The blockchain is a distributed ledger, and the information data contained in the blocks on the blockchain is the ledger data of the distributed ledger.

[0080] The embodiments of the present application also involve a consensus mechanism. The consensus mechanism is the basis for ensuring the normal operation of the blockchain network, and consensus means reaching an agreement. Each blockchain node in the blockchain network stores a distributed ledger (i.e., blockchain); the consensus process in the blockchain network is the process of keeping the distributed ledgers between each blockchain node consistent. All or part of the blockchain nodes in the blockchain network can participate in the consensus process, and these blockchain nodes participating in the consensus can jointly form a consensus committee of the blockchain network. Each blockchain node participating in the consensus can be referred to as a member of the consensus committee. For ease of understanding, the embodiments of the present application refer to the members of the consensus committee as consensus nodes (i.e., blockchain nodes participating in the consensus); that is, the consensus committee in the blockchain network includes multiple consensus nodes participating in the consensus, and the consensus process in the blockchain network is performed by the consensus nodes in the consensus committee. Among them, the consensus process in the blockchain network is usually implemented based on a consensus algorithm, which may include but is not limited to: BFT (Byzantine Fault Tolerance) algorithm, PBFT (Practical Byzantine Fault Tolerance) algorithm, etc.; each consensus node in the consensus committee can execute the corresponding process of the consensus process, that is, the consensus process, by running the consensus algorithm.

[0081] It should be noted that any block height of the blockchain requires one or more rounds of consensus process to reach a consensus among the consensus nodes of the consensus committee. In the multiple rounds of consensus process at the same block height, the consensus nodes participating in the consensus may change with each change of a round of consensus process, that is, the members of the consensus committee in each round of consensus process may change; each time a round of consensus process is changed, the proposal node may also change, and the block to be agreed upon may also change. The embodiment of the present application is described by taking a round of consensus process of block height as an example. For ease of understanding, it can be referred to as the consensus process of block height. The block height indicates the number of blocks connected to the blockchain. The block height is the identifier of the block, which can be used to indicate the position of the block on the blockchain; the block height of the founding block of the blockchain defaults to 0, the block height of the first block after the founding block is 1 (the first block is referred to as block 1), and the block height of the second block after the founding block is 2 (the second block is referred to as block 2), and so on. The consensus process of block height H (H is a positive integer) may refer to the process of consensus processing of blocks that have not yet been put on the chain in the blockchain network when the blockchain is at block height H. If the block consensus is successful, the block can be added to the blockchain, and the block height of the blockchain can be increased by 1, that is, the block height becomes H+1.

[0082] Among them, the embodiment of the present application takes the Byzantine consensus algorithm as an example to describe the consensus process in the blockchain network. The Byzantine consensus process can be divided into three stages in order of execution, including the proposal stage, the prevoting stage, and the precommit stage; it should be noted that different Byzantine consensus algorithms may have different names for the above three stages, and the embodiment of the present application does not limit this. The multiple consensus nodes participating in the same round of consensus process in the consensus committee include two types: proposal nodes (also called master nodes) and non-proposal nodes (also called slave nodes). A proposal node refers to a consensus node generated by elections from multiple consensus nodes in the consensus committee. As a proposal node, the consensus node is responsible for generating blocks to be agreed upon in the proposal stage of the consensus process, and broadcasting the blocks to be agreed upon to other consensus nodes in the consensus committee for consensus processing; it is also responsible for consensus processing of the blocks to be agreed upon. Non-proposal nodes only need to perform consensus processing on the blocks to be agreed upon. The consensus processing here includes pre-voting and pre-submitting of the consensus block. The pre-voting process is performed in the pre-voting phase, and the pre-submitting process is performed in the pre-submitting phase. Pre-voting refers to the process of whether to agree to pre-vote on the consensus block. If you agree to pre-vote on the consensus block, it means that you agree to add the block to the blockchain. Pre-submitting refers to the process of whether to agree to pre-submit the consensus block. If you agree to pre-submit the consensus block, it means that you confirm that you agree to add the block to the blockchain.

[0083] See also Figure 2 , Figure 2 Schematic diagram of a consensus process in a blockchain network provided by an embodiment of the present application; Assuming that the specific process of the consensus process of the block height H (H is a positive integer) of the blockchain is as follows Figure 2 As shown in Figure 1, the consensus committee at this time includes 4 members, namely consensus node 1, consensus node 2, consensus node 3 and consensus node 4. Figure 2 As shown in the figure, in the consensus process of the block height H of the blockchain, consensus node 1 is the proposal node, and consensus node 2, consensus node 3 and consensus node 4 are non-proposal nodes. The specific process of the consensus process of the block height H of the blockchain includes:

[0084] ① Proposal stage: All consensus nodes in the consensus committee (consensus node 1, consensus node 2, consensus node 3 and consensus node 4) can enter the consensus process of block height H and start the timer. The timer can be used to set the length of time that the consensus nodes in the consensus committee are in the proposal stage, that is, the effective duration of the proposal stage in the consensus process, which can also be called the time range of the timer in the proposal stage. The time range of the timer here can be set according to actual needs, such as 1 minute, 2 minutes, etc., and this application does not limit this. Optionally, a timer can be set for each stage in the consensus process, and the effective duration of each stage can be set by the timer.

[0085] Consensus node 1 (i.e., proposal node) can package and generate a new proposal (for ease of understanding, the proposal here can be recorded as Proposal-X), which can include the block to be agreed upon generated by consensus node 1 (for ease of understanding, the block to be agreed upon here can be recorded as block X), and this block to be agreed upon can be a new block created by consensus node 1. Consensus node 1 can broadcast Proposal-X to consensus node 2, consensus node 3, and consensus node 4 for verification. Optionally, if consensus node 1 does not generate a new proposal (for example, no new block is created), the consensus nodes in the consensus committee of the blockchain network will time out and enter the pre-voting stage.

[0086] ② Pre-voting stage: non-proposal nodes (including consensus node 2, consensus node 3 and consensus node 4) can receive Proposal-X broadcast by consensus node 1; consensus node 2, consensus node 3 and consensus node 4 can enter the pre-voting stage after receiving Proposal-X. In the pre-voting stage, consensus node 2, consensus node 3 and consensus node 4 can use the new block (i.e., block X) contained in Proposal-X as the block to be agreed upon, and pre-vote block X to obtain their respective pre-voting information (which may include the block identifier corresponding to block X in Proposal-X). For example, consensus node 2 can pre-vote block X contained in Proposal-X to generate pre-voting information corresponding to consensus node 2, and the pre-voting information at this time may include the block identifier corresponding to block X. The pre-voting information can be either the pre-voting information for approval or the pre-voting information for opposition. The pre-voting information for approval indicates that the consensus node 2 agrees to add the block X in Proposal-X to the blockchain, and the Proposal-X has obtained the pre-voting of the consensus node 2. The pre-voting information for opposition (which can be the pre-voting information that does not contain the block identifier of the block X) indicates that the consensus node does not agree to add the block X in Proposal-X to the blockchain, and the Proposal-X has not obtained the pre-voting of the consensus node 2. Optionally, if there is a non-proposal node (for example, consensus node 3) in the consensus committee that does not receive the Proposal-X broadcast by the consensus node 2 within the timer time range of the proposal phase, then the consensus node 3 can also enter the pre-submission phase and pre-vote the empty proposal to generate the pre-voting information corresponding to the empty proposal. At this time, the pre-voting information does not contain the block identifier corresponding to the block X in Proposal-X, but contains the identifier of the empty proposal.

[0087] Consensus node 1, consensus node 2, consensus node 3 and consensus node 4 can each broadcast their own pre-voting information. Due to network failure, equipment failure or other reasons, there may be a situation where some consensus nodes fail to receive the pre-voting information broadcast by other consensus nodes within the time range of the timer in the pre-voting phase; wherein, the timer time of the pre-voting phase can be set according to actual needs, and the timer time of the pre-voting phase can be the same as or different from the timer time of the proposal phase, and the embodiment of the present application does not limit this. When the timer time of the pre-voting phase arrives, each consensus node in the consensus committee counts the number of pre-voting obtained by block X in Proposal-X in the pre-voting phase according to the pre-voting information received within the time range of the timer in the pre-voting phase (which can be understood as the number of pre-voting information in favor of all pre-voting information received), and confirms whether the number of pre-voting exceeds the quantity threshold. The quantity threshold here can be set according to the actual situation. For example, the quantity threshold can be 50% of the number of consensus nodes in the consensus committee, or 2 / 3 of the number of consensus nodes in the consensus committee. For example, when the quantity threshold is 2 / 3 of the number of consensus nodes included in the consensus committee, if the number of pre-votes received by any consensus node in the consensus committee exceeds 2 / 3, then the consensus node can enter the pre-submission stage.

[0088] For example, assuming that the quantity threshold is 2, consensus nodes 1, 2, and 4 all obtain Proposal-X in the proposal phase, and pre-vote for block X in Proposal-X in the pre-submission phase, and the pre-voting information of consensus nodes 1, 2, and 4 all contain the block ID of block X, that is, the pre-voting information of consensus nodes 1, 2, and 4 are all affirmative pre-voting information; while consensus node 3 fails to receive Proposal-X within the timer time range of the proposal phase, and only pre-votes for the empty proposal in the pre-submission phase, then the pre-voting information of consensus node 3 cannot contain the block ID of block X, that is, the pre-voting information of consensus node 3 is negative pre-voting information. If consensus node 1 receives the pre-voting information of consensus nodes 2 and 3, combined with the pre-voting information of consensus node 1 itself, it can be counted that the number of pre-votes obtained by Proposal-X in the pre-voting phase is 2, confirming that the number of pre-votes for Proposal-X does not exceed the quantity threshold 2. Similarly, if consensus node 2 receives the pre-voting information from consensus node 1, consensus node 3, and consensus node 4, combined with consensus node 2's own pre-voting information, it can be counted that the number of pre-voting votes Proposal-X received in the pre-voting stage is 3, confirming that the number of pre-voting votes for Proposal-X exceeds the quantity threshold of 2.

[0089] ③ Pre-submission stage: Non-proposal nodes (including consensus node 2, consensus node 3 and consensus node 4) can perform pre-submission processing on block X in Proposal-X in the pre-submission stage to obtain their respective pre-submission information (which may include the block identifier corresponding to block X in Proposal-X). For example, consensus node 2 can perform pre-submission processing on block X included in Proposal-X to generate pre-submission information corresponding to consensus node 2, and the pre-submission information at this time may include the block identifier corresponding to block X. The pre-submission information can be either approval pre-submission information or opposition pre-submission information; approval pre-submission information indicates that consensus node 2 confirms that it agrees to add block X in Proposal-X to the blockchain, and Proposal-X has obtained the pre-submission of consensus node 2; opposition pre-submission information (which may be pre-submission information that does not include the block identifier of block X) indicates that the consensus node confirms that it disagrees to add block X in Proposal-X to the blockchain, and Proposal-X has not obtained the pre-submission of consensus node 2. Optionally, if there is a non-proposal node in the consensus committee (for example, consensus node 3) that does not receive Proposal-X broadcast by consensus node 2 within the timer time range of the proposal phase, then consensus node 3 performs pre-submission processing on the empty proposal in the pre-submission phase and generates pre-submission information corresponding to the empty proposal. At this time, the pre-submission information does not contain the block identifier corresponding to block X in Proposal-X, but contains the identifier of the empty proposal.

[0090] Consensus node 1, consensus node 2, consensus node 3 and consensus node 4 each broadcast their own pre-submission information. Due to network failure, equipment failure or other reasons, there may be a situation where some consensus nodes fail to receive the pre-submission information broadcast by other consensus nodes within the timer time range of the pre-submission phase; wherein, the timer time of the pre-submission phase can be set according to actual needs, and the timer time of the pre-submission phase can be the same as or different from the timer time of the aforementioned proposal phase and the timer time of the pre-voting phase, and the embodiment of the present application does not limit this. When the timer time of the pre-submission phase is reached, each consensus node in the consensus committee counts the number of pre-submissions obtained by block X in Proposal-X in the pre-submission phase according to the pre-submission information received within the time range of the timer of the pre-submission phase (which can be understood as the number of pre-submission information in favor of all pre-submission information received), and confirms whether the pre-submission number exceeds the submission threshold. The submission threshold here can be set according to the actual situation. For example, the submission threshold can be 50% of the number of consensus nodes in the consensus committee, or 2 / 3 of the number of consensus nodes in the consensus committee. For example, when the submission threshold is 2 / 3 of the number of consensus nodes included in the consensus committee, if the number of pre-submissions received by the consensus node in the consensus committee exceeds 2 / 3, then the consensus node can perform the submission operation, that is, it can be determined that the consensus of block X in Proposal-X has passed, and then block X can be added to the blockchain; if the number of pre-submissions received by the consensus node in the consensus committee does not reach 2 / 3, then the consensus node cannot perform the submission operation, that is, it can be determined that the consensus of block X in Proposal-X has not passed, and the block X cannot be added to the blockchain. It should be noted that the statistical steps of the number of pre-submissions of block X in Proposal-X in the pre-submission stage can refer to the statistical steps of the pre-voting data in the aforementioned pre-voting stage, which will not be repeated here.

[0091] based on Figure 2In the consensus process shown, the proposal stage, pre-voting stage and pre-submission stage of the consensus process need to broadcast corresponding consensus messages (which may include proposals, pre-voting information, pre-submission information, etc.), and in the pre-voting stage and pre-submission stage, the consensus nodes in the consensus committee need to broadcast consensus messages to each other. If not enough consensus messages are received in the pre-voting stage and the pre-submission stage (for example, the number of pre-voting messages in favor received in the pre-voting stage does not exceed the number threshold, and the number of pre-submission messages in favor received in the pre-submission stage does not exceed the submission threshold), then the current consensus process will be stuck and will wait until enough consensus messages are received before the consensus process will continue. In the case where the consensus nodes in the consensus committee do not collect enough consensus messages due to network failure, equipment failure or other reasons, the consensus messages can be reissued according to the consensus status of the consensus nodes in the consensus committee to synchronize the consensus status between the consensus nodes in the consensus committee. Therefore, each consensus node participating in the consensus in the consensus committee can broadcast its own consensus status to other consensus nodes at a regular interval, that is, send its own consensus status message to other consensus nodes (for example, each consensus node can send a consensus status message once every 1 second, or once every 2 seconds, etc., which is not limited in this embodiment of the present application), so that each consensus node can obtain the consensus status of other consensus nodes.

[0092] The embodiment of the present application compresses the consensus status message in the consensus process and uses a byte array to represent the consensus status message. The byte array can quickly determine the consensus message missing from the consensus node to reissue the consensus message, thereby reducing the network bandwidth usage in the consensus process. Figures 3 to 10 , describes the synchronization process of the blockchain consensus state.

[0093] See also Figure 3 , Figure 3 This is a flowchart of a blockchain consensus state synchronization method provided by an embodiment of the present application. Figure 1 It is understandable that the method can be executed by any blockchain node participating in the consensus in the blockchain network (i.e., any member of the consensus committee, such as the first consensus node). Figure 3 As shown, the blockchain consensus state synchronization method may include at least the following steps S101 to S104:

[0094] Step S101, obtaining a first consensus status message corresponding to the second consensus node; the first consensus status message is a byte array containing a consensus status and a consensus message bitmap, and the consensus message bitmap in the first consensus status message is used to represent the consensus message receiving status of the second consensus node during the consensus process.

[0095] Specifically, in the consensus process of the blockchain network, the consensus nodes participating in the consensus (i.e., members of the consensus committee) can broadcast their own consensus status. The consensus status of each consensus node can be broadcast in the form of a message, which is called a consensus status message. It is understandable that the consensus status messages of all consensus nodes in the consensus committee can have the same structure, see Figure 4 , Figure 4 is a schematic diagram of the structure of a consensus status message provided in an embodiment of the present application; Figure 4 As shown, the embodiment of the present application takes the consensus status message of any consensus node (for example, consensus node A) in the consensus committee as an example for explanation. The consensus status message is a byte array containing a consensus status and a consensus message bitmap; the consensus status in the consensus status message may include the block height of the current consensus of consensus node A, and the consensus step of consensus node A (or it can be understood as a consensus stage).

[0096] The block height of the current consensus of consensus node A (for example, the block height here can be recorded as H, where H is a positive integer) can be represented by the first 5 bytes in the consensus status message (byte array). It should be understood that a byte can include 8 bits, so the range that 5 bytes can represent is 2 to the 40th power, that is, 1 to 2 40 , which can basically include the upper limit of the block height of the blockchain consensus. The current consensus stage of consensus node A can be represented by the 6th byte in the consensus status message; when the value of the 6th byte is 1, it indicates that the consensus stage of consensus node A is the proposal stage; when the value of the 6th byte is 2, it indicates that the consensus stage of consensus node A is the pre-voting stage; when the value of the 6th byte is 3, it indicates that the consensus stage of consensus node A is the pre-submission stage; that is, the consensus stage of consensus node A can be represented by only one byte. For ease of understanding, in the embodiment of the present application, the proposal stage can be referred to as the first consensus stage, and the pre-voting stage and the pre-submission stage can be referred to as the second consensus stage.

[0097] The consensus message bitmap can be represented by the 7th byte and the bytes thereafter in the consensus status message, such as m bytes can be used to represent the consensus message bitmap in the consensus status message, m can be a positive integer, such as m can be 1, 2, ...; the consensus message bitmap can represent the consensus message reception status of consensus node A in the current consensus stage, and the consensus message reception status indicates whether the consensus node has received the consensus message of the current consensus stage. Among them, the consensus message reception status can include a received state and a non-received state; the received state indicates that consensus node A has received the consensus message in the current consensus stage, and the non-received state indicates that consensus node A has not received the consensus message in the current consensus stage. The byte length of the consensus message bitmap is not fixed, and it is associated with the current consensus stage of consensus node A and the number of consensus nodes in the consensus committee. When consensus node A is in the proposal stage, the byte length of the consensus message bitmap in the consensus status message of consensus node A in the proposal stage is 1 (i.e. m=1), and the byte length of the consensus status message at this time is 7, and the value of the 7th byte is used to characterize the consensus message reception status of consensus node A in the proposal stage (for example, it can be specifically called the proposal reception status). When consensus node A is in the pre-voting stage or the pre-submission stage, the byte length of the consensus message bitmap in the consensus status message corresponding to consensus node A depends on the number of consensus nodes in the consensus committee. One consensus node corresponds to one bit in the consensus message bitmap, and the value of one bit is used to characterize the consensus message reception status of consensus node A in the pre-voting stage or the pre-submission stage; for example, when the number of consensus nodes is less than or equal to 8, the byte length of the consensus message bitmap is 1 (ie, m=1), and the byte length of the consensus status message at this time is 7; when the number of consensus nodes is greater than 8 and less than or equal to 16, the byte length of the consensus message bitmap is 2 (ie, m=2), and the byte length of the consensus status message at this time is 8, and so on, which will not be described one by one here.

[0098] In one or more embodiments, if the current consensus stage of consensus node A is the proposal stage (the consensus message in the proposal stage is the proposal data), then the byte length of the consensus message bitmap is 1 (i.e., m=1), that is, the consensus message bitmap at this time only occupies one byte. When the value of the consensus message bitmap is 0, it indicates that consensus node A has not received the proposal data. At this time, the consensus message receiving state corresponding to the consensus message bitmap is the unreceived state, and the consensus message bitmap in the consensus status message corresponds to a consensus message receiving state; when the value of the consensus message bitmap is 1, it indicates that consensus node A has received the proposal data. At this time, the consensus message receiving state corresponding to the consensus message bitmap is the received state, and similarly, the consensus message bitmap in the consensus status message corresponds to a consensus message receiving state.

[0099] Among them, if consensus node A is in the first consensus stage (i.e., the proposal stage) corresponding to the first block height (for example, block height H), and consensus node A has received the proposal data of the first block height, the first block height is filled in the height byte interval in binary form; the first consensus stage is mapped to a first numerical value (the first numerical value here can be 1), and the first numerical value is filled in the step byte in binary form; the received state corresponding to the proposal data of the first block height is mapped to the first numerical value, and the first numerical value is filled in the consensus message bitmap in binary form; the height byte interval filled with the first block height, the step byte filled with the first numerical value, and the consensus message bitmap filled with the first numerical value (the consensus message bitmap at this time occupies one byte) are combined into a consensus status message corresponding to consensus node A.

[0100] Optionally, if consensus node A is in the first consensus stage corresponding to the first block height, and consensus node A has not received the proposal data of the first block height, the first block height is filled in the height byte interval in binary form; the first consensus stage is mapped to a first numerical value (the first numerical value here can be 1), and the first numerical value is filled in the step byte in binary form; the unreceived state corresponding to the proposal data of the first block height is mapped to a zero value, and the zero value is filled in the consensus message bitmap; the height byte interval filled with the first block height, the step byte filled with the first numerical value, and the consensus message bitmap filled with zero values ​​(the consensus message bitmap at this time occupies one byte) are combined into a consensus status message corresponding to consensus node A.

[0101] In one or more embodiments, if the current consensus stage is the pre-voting stage or the pre-submission stage (the pre-voting information is the consensus message of the pre-voting stage, and the pre-submission information is the consensus message of the pre-submission stage), then the consensus message bitmap in the consensus status message can be used to characterize the consensus message reception state of the consensus node A in the current consensus stage. It should be noted that at this time, each bit contained in the consensus message bitmap in the consensus status message can correspond to a consensus node in the consensus committee, such as the bit sorting number (or bit position number) in the consensus message bitmap can be used as the node index information of the consensus node in the consensus committee. At this time, each bit in the consensus message bitmap can correspond to a consensus message reception state. When the value of the bit is 1, it indicates that the consensus message reception state is a received state, and when the value of the bit is 0, it indicates that the consensus message reception state is a non-received state.

[0102] It should be noted that each consensus node in the consensus committee can correspond to a node index information, and the process of determining the node index information corresponding to each consensus node in the consensus committee may include: each consensus node in the consensus committee corresponding to the block height of the current consensus can be sorted according to the node sorting strategy to obtain a first node sorting list, and then node index information can be created for the consensus nodes in the first node sorting list. In the blockchain network, different block heights can correspond to the same consensus committee or different consensus committees; that is, the consensus committee in the blockchain network can be updated. Every time the consensus committee is updated in the blockchain network, the proposal node of the current block height (the main node that generates the proposal data) can create the node index information of each consensus node in the consensus committee corresponding to the current block height, and broadcast the node index information of each consensus node in the consensus committee in the form of a message to all consensus nodes in the consensus committee, so that each consensus node in the consensus committee can obtain the node index information of all consensus nodes and save the node index information locally. Optionally, all consensus nodes in the consensus committee can share the same node sorting strategy. Each time the consensus committee is updated in the blockchain network, each consensus node in the updated consensus committee can create node index information for each consensus node according to the shared node sorting strategy, and save the node index information locally. In this way, there is no need to transmit node index information between consensus nodes, but each consensus node creates node index information separately.

[0103] Among them, the node index information of each consensus node in the consensus committee can be a bit sorting sequence number in the consensus message bitmap, such as a node index information can correspond to a bit in the consensus message bitmap; each consensus node in the consensus committee can correspond one-to-one with the bits in the consensus message bitmap contained in the first consensus status message according to the sorting in the first node sorting list. Among them, the node sorting strategy can refer to the sorting rules between the consensus nodes included in the consensus committee, and the node sorting strategy can include but is not limited to: dictionary sorting, sorting based on proof of stake (PoS), sorting based on proof of work (PoW), sorting based on delegated proof of stake (DPoS), sorting based on network reputation, etc.

[0104] See also Figure 5 , Figure 5 Schematic diagram of determining node index information corresponding to a consensus node provided by an embodiment of the present application. Figure 5As shown, the consensus committee corresponding to the first block height (for example, block height H) in the blockchain network is obtained, and the consensus committee may include N consensus nodes (N may be an integer greater than 1); and then the consensus nodes included in the consensus committee may be sorted according to the node sorting strategy to obtain a node sorting list (herein referred to as the first node sorting list), and the order of the N consensus nodes in the node sorting list here may be: consensus node 0 (which may be recorded as node0), consensus node 1 (which may be recorded as node1), consensus node 2 (which may be recorded as node2), ..., consensus node N-1 (which may be recorded as nodeN-1), consensus node N (which may be recorded as nodeN). The sorting number of each consensus node in the consensus committee in the first node sorting list may be used as the node index information of the corresponding consensus node, and the sorting number of each consensus node in the consensus committee in the first node sorting list may also be understood as the bit sorting number in the consensus message bitmap.

[0105] It is understandable that when each consensus in the blockchain network starts, the first node sorting list corresponding to each consensus node in the consensus committee is the same, and the sorting method for generating the first node sorting list is also the same; that is, each consensus node in the consensus committee can obtain the same first node sorting list according to the node sorting strategy, and each consensus node can determine the corresponding consensus node from its own first node sorting list according to the node index information, which can specifically be the node identifier of the consensus node (for example, node ID).

[0106] In one or more embodiments, when the blockchain network begins to enter the consensus process of a new block height (for example, after completing the consensus process of the first block height, entering the consensus process of the second block height), it can detect whether the consensus committee corresponding to the second block height is the same as the consensus committee corresponding to the first block height. If it is detected that the consensus committee corresponding to the second block height is the same as the consensus committee corresponding to the first block height, the node index information corresponding to the consensus node in the first node sorting list continues to be retained, that is, there is no need to redetermine the node index information of each consensus node during the consensus process of the second block height. Optionally, each consensus node can also sort the consensus nodes in the consensus committee and redetermine the node index information corresponding to each consensus block. For ease of understanding, in the embodiment of the present application, the above-mentioned first block height can be recorded as block height H, and the above-mentioned second block height can be recorded as block height H+1.

[0107] If it is detected that the consensus committee corresponding to the second block height is different from the consensus committee corresponding to the first block height, the consensus nodes in the consensus committee corresponding to the second block height are sorted according to the node sorting strategy to obtain a second consensus node sorting list, and node index information is created for the consensus nodes in the second consensus node sorting list. In other words, when the consensus process of the second block height is started, if there is a change in the consensus nodes participating in the consensus, all consensus nodes in the changed consensus committee can be sorted to obtain a second node sorting list, that is, the sorting number of each consensus node in the second node sorting list is obtained, and this sorting number can be used as the node index information corresponding to the consensus node.

[0108] It can be understood that in the embodiment of the present application, the consensus message bitmaps in the consensus status messages of the pre-voting stage and the pre-submission stage are associated with the node index information of each consensus node in the consensus committee, that is, the generation process of the consensus message bitmaps in the consensus status messages of the pre-voting stage and the pre-submission stage is the same. For ease of understanding, the following description is made by taking the generation process of the consensus status message in the pre-voting stage as an example. If the consensus node A is in the pre-voting stage corresponding to the first block height, the first block height is filled in the height byte interval in binary form, the pre-voting stage is mapped to a second value (for example, the second value may be 2), and the second value is filled in the step byte in binary form; a pre-voting information set corresponding to the first block height is obtained, and a first node sorting list corresponding to the first block height is obtained, and the bitmap byte interval corresponding to the consensus message bitmap is determined according to the number of consensus nodes corresponding to the first node sorting list; the first node sorting list is obtained by sorting the consensus nodes in the consensus committee corresponding to the first block height; the pre-voting information in the pre-voting information set is matched with the consensus nodes in the first node sorting list to obtain a voting information matching result; according to the voting information matching result and the correspondence between the consensus nodes in the first node sorting list and the bits contained in the bitmap byte interval, the value of the bits contained in the bitmap byte interval is determined; the height byte interval filled with the first block height, the step byte filled with the second value, and the bitmap byte interval are combined into a consensus status message corresponding to the consensus node A.

[0109] See also Figure 6 , Figure 6 This is a schematic diagram of generating a consensus status message provided by an embodiment of the present application. Figure 6As shown, assuming that the consensus committee corresponding to the current block height (such as the block height is 189) includes consensus node A, consensus node B, consensus node C, consensus node D, consensus node E, consensus node F, consensus node G, and consensus node H, and the node index information corresponding to the above 8 consensus nodes in the consensus committee can be expressed as 1, 2, ..., 8 in sequence, and the node index information of these 8 consensus nodes corresponds to the bit sorting sequence number of the consensus message bitmap in the consensus status message, that is, consensus node A corresponds to the 1st bit of the consensus message bitmap, consensus node B corresponds to the 2nd bit of the consensus message bitmap, and so on, consensus node H corresponds to the 8th bit of the consensus message bitmap.

[0110] Assume that the relevant information of consensus node A in the consensus process of block height 189 includes but is not limited to: the current consensus block height is 189, the current consensus stage is the pre-voting stage, the proposal data hash1 of block height 189 has been received, and the pre-voting information of consensus node A, consensus node B, consensus node D, consensus node F and consensus node H has been obtained. Then it can be determined that the byte length of the consensus status bitmap in the consensus status message of the pre-voting stage is 1, that is, one byte is used to represent the 8 consensus nodes in the consensus committee.

[0111] Consensus node A can convert the current consensus block height 189 into binary, and use 5 bytes to represent the binary block height, that is, the binary block height can be filled into 5 bytes; the pre-voting stage can be mapped to the value 2, and then the binary value 2 can be filled into one byte; Figure 6 As shown, consensus node A obtains the pre-voting information of consensus node A, consensus node B, consensus node D, consensus node F, and consensus node H in the pre-voting stage of block height 189. According to the node index information corresponding to each of the above consensus nodes, that is, the corresponding bits of each consensus node in the consensus message bitmap, the consensus message bitmap at this time can be expressed as: 11010101. Consensus node A can combine 5 bytes filled with block height 189, 1 byte filled with value 2, and consensus message bitmap 11010101 into the consensus status message of consensus node A in the pre-voting stage.

[0112] After the other consensus nodes in the consensus committee, except for consensus node A, receive the consensus status message of consensus node A, by parsing the consensus status message of consensus node A, it can be obtained that the current consensus block height of consensus node A is 189, and the consensus step is the pre-voting stage. Based on the consensus message bitmap 11010101, it can be known that consensus node A has received the pre-voting information of five consensus nodes, namely, consensus node A, consensus node B, consensus node D, consensus node F, and consensus node H, in the pre-voting stage, but has not received the pre-voting information of the three consensus nodes, namely, consensus node C, consensus node E, and consensus node G. When the other consensus nodes already have the pre-voting information of the three consensus nodes, namely, consensus node C, consensus node E, and consensus node G, the pre-voting information of the three consensus nodes can be resent to consensus node A. Optionally, when the other consensus nodes only have the pre-voting information of any one or two of consensus nodes C, consensus node E, and consensus node G, the pre-voting information that exists and has not been received by consensus node A can be resent to the consensus node A.

[0113] It should be noted that the embodiment of the present application is described by the message interaction process between any two consensus nodes (for example, the first consensus node and the second consensus node) in the consensus committee corresponding to the first block height (such as block height H) to synchronize the consensus status between the two consensus nodes. For ease of understanding, the embodiment of the present application refers to the consensus status message corresponding to the first consensus node as the second consensus status message, and the consensus status message corresponding to the second consensus node as the first consensus status message; the generation process of the first consensus status message and the second consensus status message can refer to the generation process of the consensus status message of the aforementioned consensus node A, as mentioned above Figure 6 The description in the corresponding embodiment will not be repeated here. In the consensus process of the first block height, the consensus status message of each consensus node in the consensus committee can be broadcast to other consensus nodes; for example, the first consensus node in the consensus committee corresponding to the first block height can receive the first consensus status message broadcasted regularly by the second consensus node, and the second consensus node can also receive the second consensus status message broadcasted regularly by the first consensus node. The structures of the first consensus status message and the second consensus status message can be as follows: Figure 4 As shown, no further description is given here.

[0114] Step S102, parse the bytes occupied by the consensus status in the first consensus status message to obtain the first block height and consensus stage corresponding to the second consensus node; the consensus process of the first block height includes the first consensus stage and the second consensus stage.

[0115] The first block height in the embodiment of the present application may refer to the block height currently agreed upon by the second consensus node, the consensus stage corresponding to the second consensus node may refer to the current consensus step of the second consensus node, and the consensus process of the first block height may include a first consensus stage and a second consensus stage, the first consensus stage may be the aforementioned proposal stage, and the second consensus stage may include the aforementioned pre-voting stage and pre-submission stage.

[0116] Specifically, after receiving the first consensus status message corresponding to the second consensus node, the first consensus node can determine the height byte interval and step byte used to represent the consensus status in the first consensus status message. The height byte interval here can be the first 5 bytes in the first consensus status message, and the step byte can be the sixth byte in the first consensus status message. By parsing the bytes in the height byte interval, the first block height corresponding to the second consensus node can be obtained. The first block height here can be the decimal value corresponding to the first 5 bytes in the first consensus status message; parsing the step byte can obtain the byte parsing result, and the consensus stage corresponding to the second consensus node can be determined according to the byte parsing result. The byte parsing result here can be the decimal value corresponding to the sixth byte in the first consensus status message.

[0117] Among them, if the byte parsing result of the 6th byte in the first consensus status message is the first value, the consensus stage corresponding to the second consensus node is determined to be the proposal stage; if the byte parsing result of the 6th byte in the first consensus status message is the second value, the consensus stage corresponding to the second consensus node is determined to be the pre-voting stage; if the byte parsing result of the 6th byte in the first consensus status message is the third value, the consensus stage corresponding to the second consensus node is determined to be the pre-submission stage. The first value here can be 1, the second value can be 2, and the third value can be 3; of course, other three different values ​​can also be used to represent the proposal stage, pre-voting stage, and pre-submission stage in turn, and the embodiments of the present application are not limited to this.

[0118] In one or more embodiments, if the consensus stage of the second consensus node is the first consensus stage (i.e., the proposal stage), the consensus message bitmap in the first consensus status message (i.e., the 7th byte in the first consensus status message) is parsed to obtain the bitmap parsing result; if the bitmap parsing result is a non-zero value (for example, the bitmap parsing result is a value of 1), it is determined that the second consensus node has received the proposal data of the first block height. If the bitmap parsing result is a zero value, it is determined that the second consensus node has not received the proposal data corresponding to the first block height. When the first consensus node contains the proposal data corresponding to the first block height, the proposal data corresponding to the first block height can be sent to the second consensus node, that is, the first consensus node resends the proposal data corresponding to the first block height to the second consensus node. In other words, the consensus message in the proposal stage can be the proposal data of the first block height.

[0119] See also Figure 7 , Figure 7 : is a schematic diagram of the structure of a consensus status message in the proposal stage provided in an embodiment of the present application; assuming that the first consensus status message corresponding to the second consensus node received by the first consensus node is as follows Figure 7 As shown, the first 5 bytes in the first consensus status message are parsed, and the first block height of the current consensus of the second consensus node is 189; the 6th byte in the first consensus status message is parsed, and the byte parsing result corresponding to the 6th byte is 1, which can determine that the current consensus step of the second consensus node is the proposal stage. At this time, the consensus message bitmap in the first consensus status message only occupies one byte, that is, the 7th byte, that is, the first consensus status message in the proposal stage only requires 7 bytes. By parsing the 7th byte in the first consensus status message, the value of the 7th byte is 0, that is, the value of the consensus message bitmap is 0, indicating that the second consensus node has not received the proposal data of block height 189. If the first consensus node itself receives the proposal data of block height 189, then the proposal data of block height 189 can be resent to the second consensus node to synchronize the consensus status between the first consensus node and the second consensus node.

[0120] Step S103, if the consensus stage of the second consensus node is the second consensus stage, the consensus message bitmap in the first consensus status message is parsed according to the number of consensus nodes corresponding to the first block height to obtain the set of nodes to be reissued corresponding to the second consensus node.

[0121] Specifically, if the consensus stage of the second consensus node is the second consensus stage (i.e., the consensus stage of the second consensus node is the pre-voting stage or the pre-submission stage), the first consensus node can obtain the consensus committee corresponding to the first block height, and count the number of consensus nodes in the consensus committee corresponding to the first block height; according to the number of consensus nodes, determine the bitmap byte interval corresponding to the consensus message bitmap in the first consensus status message, and the bitmap byte interval can be the 7th byte and the bytes thereafter in the first consensus status message; and then determine the set of nodes to be reissued corresponding to the second consensus node according to the values ​​of each bit contained in the bitmap byte interval. Among them, the set of nodes to be reissued can include the consensus nodes corresponding to the consensus messages that the second consensus node has not received in the second consensus stage, that is, the second consensus node has not received the consensus messages of the consensus nodes in the set of nodes to be reissued in the second consensus stage.

[0122] Among them, the process of determining the set of nodes to be reissued may include but is not limited to: the first consensus node may determine the bit sorting position of the bit with a value of zero in the bitmap byte interval according to the values ​​of each bit contained in the bitmap byte interval; according to the node index information corresponding to the bit sorting position, determine the set of nodes to be reissued in the consensus committee corresponding to the first block height. In other words, if the value of the bit in the bitmap byte interval is zero, then the consensus node corresponding to the node index information of the bit can be added to the set of nodes to be reissued. When the value of a certain bit is zero, it means that the second consensus node has not received the consensus message of the consensus node corresponding to the bit. It should be noted that the consensus message in the pre-voting stage can be pre-voting information, and the consensus message in the pre-submission stage can be pre-submission information.

[0123] Step S104: If the first consensus node includes the consensus message of the consensus node in the to-be-reissued node set in the second consensus phase, the consensus message of the consensus node in the to-be-reissued node set in the second consensus phase is sent to the second consensus node.

[0124] Specifically, if the consensus stage currently in which the second consensus node is located is the pre-voting stage, that is, the second consensus stage is the pre-voting stage, then the consensus message of the second consensus stage is the pre-voting information, and then it can be checked whether the first consensus node itself contains the pre-voting information of the consensus nodes in the set of nodes to be reissued in the pre-voting stage. If the first consensus node contains the pre-voting information of the consensus nodes in the set of nodes to be reissued in the pre-voting stage, then in the pre-voting information set corresponding to the first consensus node, the pre-voting information corresponding to the consensus nodes in the set of nodes to be reissued is obtained; and the pre-voting information corresponding to the consensus nodes in the set of nodes to be reissued is sent to the second consensus node. For example, if the second consensus node lacks the pre-voting information of consensus node A in the pre-voting stage, and the first consensus node itself has the pre-voting information of consensus node A, then the first consensus node can resend the pre-voting information of consensus node A to the first consensus node. In other words, the first consensus node may not be able to resend the pre-voting information of all consensus nodes in the set of nodes to be reissued to the second consensus node, but can only resend the pre-voting information that the second consensus node has not received and the pre-voting information that the first consensus node itself has to the second consensus node.

[0125] See also Figure 8 , Figure 8 : is a schematic diagram of the structure of a consensus status message in the pre-voting phase provided in an embodiment of the present application; assuming that the first consensus status message corresponding to the second consensus node received by the first consensus node is as follows Figure 8As shown, the first 5 bytes in the first consensus status message are parsed, and the first block height of the current consensus of the second consensus node is 189; the 6th byte in the first consensus status message is parsed, and the byte parsing result corresponding to the 6th byte is 2, which can determine that the current consensus step of the second consensus node is the pre-voting stage. Assuming that the number of consensus nodes in the consensus committee corresponding to the block height 189 is 11, the byte length of the consensus message bitmap in the first consensus status message is 2 (including the 7th and 8th bytes in the first consensus status message), that is, the first consensus status message in the pre-voting stage requires 8 bytes. The binary representation of the 7th and 8th bytes in the first consensus status message is 10110100100, then through the consensus message bitmap in the first consensus status message, it is indicated that the second consensus node has received the pre-voting information of the six consensus nodes 1, 3, 4, 6, 7, and 9, and has not received the pre-voting information of the five consensus nodes 2, 5, 8, 10, and 11. If the first consensus node contains the pre-voting information of consensus nodes 2 and 5, then the first consensus node can resend the pre-voting information of the two consensus nodes 2 and 5 to the second consensus node; if the first consensus node contains the pre-voting information of five consensus nodes 2, 5, 8, 10, and 11, then the first consensus node can resend the pre-voting information of the five consensus nodes 2, 5, 8, 10, and 11 to the second consensus node to synchronize the consensus status between the first consensus node and the second consensus node.

[0126] If the consensus stage currently in which the second consensus node is located is the pre-submission stage, that is, the second consensus stage is the pre-submission stage, then the consensus message of the second consensus stage is the pre-submission information, and then it can be checked whether the first consensus node itself contains the pre-submission information of the consensus nodes in the set of nodes to be reissued in the pre-submission stage. If the first consensus node contains the pre-submission information of the consensus nodes in the set of nodes to be reissued in the pre-submission stage, then in the pre-submission information set corresponding to the first consensus node, the pre-submission information corresponding to the consensus nodes in the set of nodes to be reissued is obtained; and the pre-submission information corresponding to the consensus nodes in the set of nodes to be reissued is sent to the second consensus node. For example, if the second consensus node lacks the pre-submission information of consensus node A in the pre-submission stage, and the first consensus node itself has the pre-submission information of consensus node A, then the first consensus node can resend the pre-submission information of consensus node A to the first consensus node. In other words, the first consensus node may not be able to resend the pre-submission information of all consensus nodes in the set of nodes to be reissued to the second consensus node, but can only resend the pre-submission information that the second consensus node has not received and the pre-submission information that the first consensus node itself has to the second consensus node.

[0127] See also Fig. 9 , Fig. 9: is a schematic diagram of the structure of a consensus status message in the pre-commitment phase provided in an embodiment of the present application; assuming that the first consensus status message corresponding to the second consensus node received by the first consensus node is as follows Fig. 9 As shown, the first 5 bytes in the first consensus status message are parsed, and the first block height of the current consensus of the second consensus node is 189; the 6th byte in the first consensus status message is parsed, and the byte parsing result corresponding to the 6th byte is 3, which can determine that the current consensus step of the second consensus node is the pre-submission stage. Assuming that the number of consensus nodes in the consensus committee corresponding to the block height 189 is 11, the byte length of the consensus message bitmap in the first consensus status message is 2 (including the 7th and 8th bytes in the first consensus status message). The binary representation of the 7th and 8th bytes in the first consensus status message is 00101100101, then through the consensus message bitmap in the first consensus status message, it is indicated that the second consensus node has received the pre-submission information of the five consensus nodes 3, 5, 6, 9, and 11, and has not received the pre-submission information of the six consensus nodes 1, 2, 4, 7, 8, and 10. If the first consensus node contains the pre-commit information of the five consensus nodes 3, 5, 6, 9, and 11, then the first consensus node can resend the pre-commit information of the six consensus nodes 1, 2, 4, 7, 8, and 10 to the second consensus node to synchronize the consensus status between the first consensus node and the second consensus node.

[0128] It is understandable that, through the form of the aforementioned first consensus status message, even if there is no direct connection between the first consensus node and the second consensus node, as long as there is an intermediate node between the two, the consensus message in each consensus stage can be forwarded. For example, the network connection between consensus node A and consensus node B is disconnected, while consensus node A, consensus node B and consensus node C are all connected. Consensus node A sends its own consensus message to consensus node C. If the consensus message sent by consensus node A to consensus node B is lost, then consensus node B can send its own consensus status to consensus node C. Consensus node C parses the consensus message bitmap in B's consensus status message, and can obtain that the binary value of the bit corresponding to consensus node A is 0, which means that consensus node B now lacks the consensus message of consensus node A, and consensus node C has received the consensus message of consensus node A, so consensus node C can send the consensus message of consensus node A it received to consensus node B.

[0129] See also Fig.10 , Fig.10 This is a flowchart of a blockchain consensus state synchronization method provided by an embodiment of the present application. Figure 2 It is understandable that the method can be executed by any blockchain node participating in the consensus in the blockchain network (i.e., any member of the consensus committee, such as the first consensus node). Figure 5 As shown, the blockchain consensus state synchronization method may include at least the following steps S201 to S216:

[0130] In step S201, the first consensus node may receive a first consensus status message corresponding to the second consensus node.

[0131] Specifically, the first consensus status message is a byte array containing a consensus state and a consensus message bitmap, where the consensus state may include the first block height (for example, block height H) currently agreed upon by the second consensus node, and the current consensus step (i.e., consensus stage) of the second consensus node; wherein the first 5 bytes in the first consensus status message represent the block height H currently agreed upon by the second consensus node, the 6th byte represents the current consensus stage of the second consensus node, and the 7th and subsequent bytes represent a consensus message bitmap, which is used to represent the consensus message received by the second consensus node in the current consensus stage.

[0132] In step S202, the first 5 bytes in the first consensus status message may be parsed to obtain the first block height corresponding to the second consensus node.

[0133] Specifically, the first 5 bytes in the first consensus status message can be parsed, that is, the first 5×8=40 bits in the first consensus status message can be parsed, and the binary system can be converted into decimal to obtain the block height H (first block height) of the current consensus of the second consensus node.

[0134] In step S203, the sixth byte in the first consensus status message may be parsed to obtain the consensus stage corresponding to the second consensus node.

[0135] Specifically, the 8 bits contained in the 6th byte in the first consensus status message are parsed to obtain the value of the 6th byte (the byte parsing result can be a decimal result). When the value of the 6th byte is 1, it indicates that the current consensus stage of the second consensus node is the proposal stage; when the value of the 6th byte is 2, it indicates that the current consensus stage of the second consensus node is the pre-voting stage; when the value of the 6th byte is 3, it indicates that the current consensus stage of the second consensus node is the pre-submission stage.

[0136] In step S204, it can be determined whether the consensus stage corresponding to the second consensus node is the proposal stage.

[0137] Specifically, if the consensus stage corresponding to the second consensus node is the proposal stage, step S205 to step S208 may be continued; if the consensus stage corresponding to the second consensus node is not the proposal stage, step S209 may be continued.

[0138] In step S205, the value of the seventh byte in the first consensus status message may be parsed.

[0139] Specifically, if the value of the 6th byte in the first consensus status message is 1, it means that the current consensus stage of the second consensus node is the proposal stage. At this time, the first consensus status message is a byte array consisting of 7 bytes. The 8 bits contained in the 7th byte can be parsed to obtain the value of the 7th byte.

[0140] In step S206, it can be determined whether the value of the 7th byte in the first consensus status message is 0.

[0141] Specifically, if the value of the 7th byte in the first consensus status message is 0, then step S207 can be continued; if the value of the 7th byte is not 0, then the current consensus status synchronization process can be terminated.

[0142] In step S207, it can be determined whether the second consensus node has proposal data corresponding to the first block height based on the value of the 7th byte in the first consensus status message.

[0143] Specifically, if the second consensus node has proposal data corresponding to the first block height, the current consensus state synchronization process can be terminated; if the second consensus node does not have proposal data corresponding to the first block height, step S208 can be continued.

[0144] Step S208, reissue the proposal data corresponding to the first block height.

[0145] Specifically, if the second consensus node does not have proposal data corresponding to the first block height, and the first consensus node itself has proposal data corresponding to the first block height, the proposal data corresponding to the first block height can be resent to the second consensus node.

[0146] Step S209, determining whether the consensus phase of the second consensus node is a pre-voting phase.

[0147] Specifically, if the consensus stage of the second consensus node is the pre-voting stage, step S210 to step S212 may be continued; if the consensus stage of the second consensus node is not the pre-voting stage, step S213 may be continued.

[0148] In step S210, the first consensus node may parse the bytes occupied by the consensus status bitmap according to the number of consensus nodes corresponding to the first block height.

[0149] Specifically, if the value of the 6th byte in the first consensus status message is 2, it means that the current consensus stage of the second consensus node is the pre-voting stage. When the number of consensus nodes participating in the consensus process of block height H is 18, the first consensus status message at this time is a byte array consisting of 9 bytes (the consensus status bitmap occupies 3 bytes); the 7th and subsequent bytes in the first consensus status message are parsed to obtain the parsing result corresponding to the consensus status bitmap.

[0150] Step S211, obtaining a set of nodes to be reissued corresponding to the pre-voting information missing from the second consensus node.

[0151] Specifically, when the value of a bit in the consensus status bitmap of the first consensus status message is 0, it indicates that the second consensus node has not received the pre-voting information of the consensus node corresponding to the bit; when the value of a bit in the consensus status bitmap is 1, it indicates that the second consensus node has received the pre-voting information of the consensus node corresponding to the bit. In other words, the number of pre-voting information received by the second consensus node and the pre-voting information of the consensus nodes received can be determined based on the number and position of the numerical value "1" contained in the consensus status bitmap; similarly, the number of pre-voting information not received by the second consensus node and the pre-voting information of the consensus nodes not received can be determined based on the number and position of the numerical value "0" contained in the consensus status bitmap, and the consensus nodes for which the pre-voting information has not been received can be added to the set of nodes to be reissued.

[0152] Step S212, reissue the pre-voting information that exists in the first consensus node and is missing in the second consensus node.

[0153] Specifically, if the first consensus node has pre-voting information of some or all of the consensus nodes in the set of nodes to be reissued, then the pre-voting information that the first consensus node already has and the second consensus node has not yet received can be reissued to the second consensus node.

[0154] Step S213, determining whether the consensus phase of the second consensus node is a pre-commit phase.

[0155] Specifically, if the current consensus step of the second consensus node is neither the proposal stage nor the pre-voting stage, it is possible to continue to determine whether the current consensus stage of the second consensus node is the pre-submission stage. For example, when the value of the sixth byte in the first consensus status message is 3, it indicates that the current consensus stage of the second consensus node is the pre-submission stage. If the consensus stage of the second consensus node is the pre-submission stage, steps S214 to S216 can be continued; if the consensus stage of the second consensus node is not the pre-submission stage, the current consensus status synchronization process can be terminated.

[0156] In step S214, the bytes occupied by the consensus status bitmap can be parsed according to the number of consensus nodes corresponding to the first block height.

[0157] Step S215, obtaining a set of nodes to be reissued corresponding to the pre-submitted information missing from the second consensus node.

[0158] Step S216, resending the pre-submission information that exists in the first consensus node and is missing from the second consensus node, that is, the pre-submission information of the consensus nodes in the set of nodes to be resent that exist in the first consensus node can be resent to the second consensus node.

[0159] Among them, when the current consensus stage of the second consensus node is the pre-submission stage, the parsing process of the consensus status bitmap in the first consensus status message is the same as the parsing process of the consensus status bitmap in the first consensus status message in the aforementioned pre-voting stage, except that the consensus status bitmap in the first consensus status message in the pre-submission stage represents the pre-submission information received by the second consensus node, while the consensus status bitmap in the first consensus status message in the pre-voting stage represents the pre-voting information received by the second consensus node, which will not be repeated here.

[0160] Optionally, if the current consensus stage of the second consensus node does not belong to any of the proposal stage, the pre-voting stage, and the pre-submission stage, there is no need to reissue any consensus node to the second consensus node.

[0161] In the embodiment of the present application, the first consensus node can obtain the first consensus status message corresponding to the second consensus node, and the first consensus status message is a byte array containing the consensus status and the consensus message bitmap. That is to say, by adopting the structure of the byte array to represent the first consensus status message, the data volume of the first consensus status message can be compressed. Further, the bytes occupied by the consensus status are parsed to obtain the first block height and consensus stage corresponding to the second consensus node. The consensus process of the first block height includes the first consensus stage and the second consensus stage; if the consensus stage of the second consensus node is the second consensus stage, the bytes occupied by the consensus message bitmap are parsed according to the number of consensus nodes corresponding to the first block height, and the set of nodes to be reissued corresponding to the second consensus node is obtained. If the first consensus node contains the consensus message of the consensus node in the set of nodes to be reissued in the second consensus stage, it can be sent to the second consensus node to synchronize the consensus state between the first consensus node and the second consensus node, which can reduce the network bandwidth occupied during the consensus state synchronization process, and thus improve the consensus performance of the blockchain.

[0162] It is understandable that in the specific implementation of this application, the information data submitted to the blockchain network may involve user transaction data, loan data, user authentication information and other related information. When the above embodiments of this application are applied to specific products or technologies, it is necessary to obtain the permission or consent of the relevant users, and the collection, use and processing of relevant data need to comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0163] See also Fig.11 , Fig.11 1 is a schematic diagram of the structure of a blockchain consensus state synchronization device provided in an embodiment of the present application. It can be understood that the blockchain consensus state synchronization device 1 can be applied to any consensus node (for example, the aforementioned first consensus node) in the consensus committee of the blockchain network; Fig.11 As shown, the blockchain consensus state synchronization device 1 may include: a message acquisition module 11, a first parsing module 12, a second parsing module 13, and a voting reissue module 14;

[0164] The message acquisition module 11 is used to acquire the first consensus status message corresponding to the second consensus node; the first consensus status message is a byte array including the consensus status and the consensus message bitmap;

[0165] The first parsing module 12 is used to parse the bytes occupied by the consensus state in the first consensus state message to obtain the first block height and consensus stage corresponding to the second consensus node; the consensus process of the first block height includes the first consensus stage and the second consensus stage, and H is a positive integer;

[0166] The second parsing module 13 is used to parse the bytes occupied by the consensus message bitmap in the first consensus status message according to the number of consensus nodes corresponding to the first block height if the consensus stage of the second consensus node is the second consensus stage, and obtain the set of nodes to be reissued corresponding to the second consensus node;

[0167] The voting reissue module 14 is used to send the consensus message of the consensus node in the set of nodes to be reissued in the second consensus stage to the second consensus node if the first consensus node contains the consensus message of the consensus node in the set of nodes to be reissued in the second consensus stage.

[0168] In one or more embodiments, the first parsing module 12 is specifically used for:

[0169] Determine the height byte interval and step byte used to represent the consensus state in the first consensus state message, parse the bytes in the height byte interval, and obtain the first block height corresponding to the second consensus node;

[0170] The step bytes are parsed to obtain byte parsing results, and the consensus stage corresponding to the second consensus node is determined according to the byte parsing results.

[0171] In one or more embodiments, the first consensus phase includes a proposal phase, and the second consensus phase includes a pre-voting phase and a pre-commit phase;

[0172] The first parsing module 12 determines the consensus stage corresponding to the second consensus node according to the byte parsing result, including:

[0173] If the byte parsing result is the first value, it is determined that the consensus stage corresponding to the second consensus node is the proposal stage;

[0174] If the byte parsing result is the second value, it is determined that the consensus stage corresponding to the second consensus node is the pre-voting stage;

[0175] If the byte parsing result is the third value, it is determined that the consensus stage corresponding to the second consensus node is the pre-commit stage.

[0176] In one or more embodiments, the second parsing module 13 is specifically used for:

[0177] If the consensus stage of the second consensus node is the second consensus stage, the consensus committee corresponding to the first block height is obtained, and the number of consensus nodes in the consensus committee corresponding to the first block height is counted;

[0178] According to the number of consensus nodes, determine the bitmap byte interval corresponding to the consensus message bitmap in the first consensus status message;

[0179] According to the value of each bit contained in the bitmap byte interval, the set of nodes to be reissued corresponding to the second consensus node is determined.

[0180] In one or more embodiments, the second parsing module 13 determines the set of nodes to be reissued corresponding to the second consensus node according to the values ​​of each bit contained in the bitmap byte interval, including:

[0181] Determine the bit sorting position of the bit with a value of zero in the bitmap byte interval according to the value of each bit contained in the bitmap byte interval;

[0182] According to the node index information corresponding to the bit sorting position, the set of nodes to be reissued is determined in the consensus committee corresponding to the first block height; one consensus node in the consensus committee corresponding to the first block height corresponds to one node index information, and one node index information corresponds to one bit in the bitmap byte interval.

[0183] In one or more embodiments, the blockchain consensus state synchronization device 1 further includes: an index determination module 15;

[0184] The index determination module 15 is used to sort the consensus nodes in the consensus committee corresponding to the first block height according to the node sorting strategy, obtain a first node sorting list, and create node index information for the consensus nodes in the first node sorting list.

[0185] An index determination module 15 is used to, during the consensus process of the second block height, if it is detected that the consensus committee corresponding to the second block height is the same as the consensus committee corresponding to the first block height, continue to retain the node index information corresponding to the consensus node in the first node sorting list; and

[0186] If it is detected that the consensus committee corresponding to the second block height is different from the consensus committee corresponding to the first block height, the consensus nodes in the consensus committee corresponding to the second block height are sorted according to the node sorting strategy to obtain a second consensus node sorting list, and node index information is created for the consensus nodes in the second consensus node sorting list.

[0187] In one or more embodiments, the second parsing module 13 is further configured to:

[0188] If the consensus stage of the second consensus node is the first consensus stage, the bytes occupied by the consensus message bitmap in the first consensus status message are parsed to obtain a bitmap parsing result;

[0189] If the bitmap parsing result is zero, it is determined that the second consensus node has not received the proposal data corresponding to the first block height;

[0190] If the first consensus node contains proposal data corresponding to the first block height, the proposal data corresponding to the first block height is sent to the second consensus node.

[0191] In one or more embodiments, the second consensus phase includes a pre-voting phase, and the consensus message of the pre-voting phase is pre-voting information;

[0192] The voting reissue module 14 is specifically used for:

[0193] If the first consensus node contains the pre-voting information of the consensus nodes in the set of nodes to be reissued in the pre-voting stage, then the pre-voting information corresponding to the consensus nodes in the set of nodes to be reissued is obtained from the pre-voting information set corresponding to the first consensus node;

[0194] Send the pre-voting information corresponding to the consensus node in the set of nodes to be reissued to the second consensus node.

[0195] In one or more embodiments, the second consensus phase includes a pre-commit phase, and the consensus message of the pre-commit phase is pre-commit information;

[0196] The voting reissue module 14 is specifically used for:

[0197] If the first consensus node contains the pre-submission information of the consensus node in the set of nodes to be reissued in the pre-submission stage, then the pre-submission information corresponding to the consensus node in the set of nodes to be reissued is obtained from the pre-submission information set corresponding to the first consensus node;

[0198] Send the pre-submission information corresponding to the consensus node in the set of nodes to be reissued to the second consensus node.

[0199] In one or more embodiments, the blockchain consensus state synchronization device 1 further includes: a consensus state message generation module 16;

[0200] The consensus status message generation module 16 is specifically used for:

[0201] If the first consensus node is in the first consensus stage corresponding to the first block height, and the first consensus node has received the proposal data of the first block height, the first block height is filled in binary form to the height byte interval;

[0202] Mapping the first consensus stage to a first value, and filling the first value into the step byte in binary form;

[0203] Mapping the received state corresponding to the proposal data of the first block height to a first value, and filling the first value into the consensus message bitmap in binary form;

[0204] The height byte interval filled with the first block height, the step byte filled with the first value, and the consensus message bitmap filled with the first value are combined into a second consensus status message corresponding to the first consensus node.

[0205] Optionally, the blockchain consensus state synchronization device 1 further includes: a consensus state message generation module 16;

[0206] The consensus status message generation module 16 is specifically used for:

[0207] If the first consensus node is in the pre-voting stage corresponding to the first block height, fill the first block height in binary form to the height byte interval, map the pre-voting stage to the second value, and fill the second value in binary form to the step byte;

[0208] Obtain a pre-voting information set corresponding to the first block height, and obtain a first node sorting list corresponding to the first block height, and determine a bitmap byte interval corresponding to the consensus message bitmap according to the number of consensus nodes corresponding to the first node sorting list; the first node sorting list is obtained by sorting the consensus nodes in the consensus committee corresponding to the first block height;

[0209] Matching the pre-voting information in the pre-voting information set with the consensus nodes in the first node sorting list to obtain a voting information matching result;

[0210] Determine the value of the bit contained in the bitmap byte interval according to the voting information matching result and the correspondence between the consensus nodes in the first node sorting list and the bits contained in the bitmap byte interval;

[0211] The height byte interval filled with the first block height, the step byte filled with the second value, and the bitmap byte interval are combined into a second consensus status message corresponding to the first consensus node.

[0212] According to an embodiment of the present application, the steps involved in the blockchain consensus state synchronization method shown above can be Fig.11 The blockchain consensus state synchronization device 1 shown in the figure is executed by each module. For example, Figure 3 Step S101 shown can be performed by Fig.11 The message acquisition module 11 shown is used to execute, Figure 3 Step S102 shown can be performed by Fig.11 The first parsing module 12 shown is used to execute, Figure 3 Step S103 shown can be performed by Fig.11 The second parsing module 13 shown is used to execute, Figure 3 Step S104 shown can be performed by Fig.11 The voting reissue module 14 shown is used to perform the following operations.

[0213] According to one embodiment of the present application, Fig.11 The various modules in the blockchain consensus state synchronization device 1 shown can be combined into one or several modules separately or in whole, or one (some) of the modules can be further divided into at least two functionally smaller units to achieve the same operation without affecting the realization of the technical effects of the embodiments of the present application. The above modules are divided based on logical functions. In practical applications, the functions of one module can also be implemented by at least two modules, or the functions of at least two modules can be implemented by one module. In other embodiments of the present application, Fig.11 The blockchain consensus state synchronization device 1 shown may also include other modules. In practical applications, these functions may also be implemented with the assistance of other modules, and may be implemented by the collaboration of at least two modules.

[0214] In the embodiment of the present application, the first consensus node can obtain the first consensus status message corresponding to the second consensus node, and the first consensus status message is a byte array containing the consensus status and the consensus message bitmap. That is to say, by adopting the structure of the byte array to represent the first consensus status message, the data volume of the first consensus status message can be compressed. Further, the bytes occupied by the consensus status are parsed to obtain the first block height and consensus stage corresponding to the second consensus node. The consensus process of the first block height includes the first consensus stage and the second consensus stage; if the consensus stage of the second consensus node is the second consensus stage, the bytes occupied by the consensus message bitmap are parsed according to the number of consensus nodes corresponding to the first block height, and the set of nodes to be reissued corresponding to the second consensus node is obtained. If the first consensus node contains the consensus message of the consensus node in the set of nodes to be reissued in the second consensus stage, it can be sent to the second consensus node to synchronize the consensus state between the first consensus node and the second consensus node, which can reduce the network bandwidth occupied during the consensus state synchronization process, and thus improve the consensus performance of the blockchain.

[0215] See also Fig.12 , Fig.12 Schematic diagram of the structure of a computer device provided in an embodiment of the present application. Fig.12 As shown, the computer device 1000 can be a terminal device or a server, which will not be limited here. For ease of understanding, this application takes the computer device as a terminal device as an example. The computer device 1000 may include: a processor 1001, a network interface 1004 and a memory 1005. In addition, the computer device 1000 may also include: a user interface 1003, and at least one communication bus 1002. Among them, the communication bus 1002 is used to realize the connection and communication between these components. Among them, the user interface 1003 may also include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 1004 may be a high-speed RAM memory or a non-volatile memory (non-volatile memory), such as at least one disk storage. The memory 1005 may optionally be at least one storage device located away from the aforementioned processor 1001. As Fig.12 As shown, the memory 1005 as a computer-readable storage medium may include an operating system, a network communication module, a user interface module, and a device control application program.

[0216] The network interface 1004 in the computer device 1000 can also provide a network communication function, and the optional user interface 1003 can also include a display screen (Display) and a keyboard (Keyboard). Fig.12In the computer device 1000 shown, the network interface 1004 can provide a network communication function; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control application stored in the memory 1005 to achieve:

[0217] Obtain the first consensus status message corresponding to the second consensus node; the first consensus status message is a byte array containing the consensus status and the consensus message bitmap, and the consensus message bitmap in the first consensus status message is used to represent the consensus message reception status of the second consensus node during the consensus process;

[0218] Parse the bytes occupied by the consensus status in the first consensus status message to obtain the first block height and consensus stage corresponding to the second consensus node; the consensus process of the first block height includes the first consensus stage and the second consensus stage;

[0219] If the consensus stage of the second consensus node is the second consensus stage, the consensus message bitmap in the first consensus status message is parsed according to the number of consensus nodes corresponding to the first block height to obtain the set of nodes to be reissued corresponding to the second consensus node;

[0220] If the first consensus node includes the consensus message of the consensus node in the to-be-reissued node set in the second consensus phase, the consensus message of the consensus node in the to-be-reissued node set in the second consensus phase is sent to the second consensus node.

[0221] It should be understood that the computer device 1000 described in the embodiment of the present application can execute the above Figure 3 , Fig.10 The description of the blockchain consensus state synchronization method in any corresponding embodiment can also be performed as described above. Fig.11 The description of the blockchain consensus state synchronization device 1 in the corresponding embodiment will not be repeated here. In addition, the description of the beneficial effects of adopting the same method will not be repeated here.

[0222] In addition, it should be pointed out here that: the embodiment of the present application also provides a computer-readable storage medium, and the computer-readable storage medium stores a computer program executed by the blockchain consensus state synchronization device 1 mentioned above, and the computer program includes program instructions. When the processor executes the program instructions, it can execute the above-mentioned Figure 3 , Fig.10The description of the blockchain consensus state synchronization method in any corresponding embodiment will not be repeated here. In addition, the description of the beneficial effects of the same method will not be repeated. For technical details not disclosed in the computer-readable storage medium embodiment involved in this application, please refer to the description of the method embodiment of this application. As an example, program instructions can be deployed on a computer device for execution, or on multiple computer devices located at one location, or on multiple computer devices distributed at multiple locations and interconnected by a communication network. Multiple computer devices distributed at multiple locations and interconnected by a communication network can form a blockchain network.

[0223] In addition, it should be noted that: the embodiment of the present application also provides a computer program product or a computer program, which may include computer instructions, and the computer instructions may be stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor may execute the computer instructions, so that the computer device executes the above Figure 3 , Fig.10 The description of the blockchain consensus state synchronization method in any corresponding embodiment will not be repeated here. In addition, the description of the beneficial effects of the same method will not be repeated. For technical details not disclosed in the computer program product or computer program embodiment involved in this application, please refer to the description of the method embodiment of this application.

[0224] The terms "first", "second", etc. in the description, claims, and drawings of the embodiments of the present application are used to distinguish different media contents, rather than to describe a specific order. In addition, the term "comprising" and any variation thereof are intended to cover non-exclusive inclusions. For example, a process, method, device, product, or equipment comprising a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules that are not listed, or may optionally include other step units inherent to these processes, methods, devices, products, or equipment.

[0225] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0226] The method and related apparatus provided by the embodiment of the present application are described with reference to the method flow chart and / or structural diagram provided by the embodiment of the present application. Specifically, each process and / or box in the method flow chart and / or structural diagram, as well as the combination of the processes and / or boxes in the flow chart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the process in the process. Figure 1 A process or multiple processes and / or structures Figure 1 These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing device to work in a specific way, so that the instructions stored in the computer-readable memory produce a product including an instruction device, which implements the functions specified in the process. Figure 1 A process or multiple processes and / or structures Figure 1 These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide for implementing the process in the process. Figure 1 A flow or multiple flows and / or structures illustrate the steps of the functions specified in one block or multiple blocks.

[0227] The above disclosure is only the preferred embodiment of the present application, which certainly cannot be used to limit the scope of rights of the present application. Therefore, equivalent changes made according to the claims of the present application are still within the scope covered by the present application.

Claims

1. A blockchain consensus state synchronization method, characterized in that: The method is performed by a first consensus node, and the method includes: Obtaining a first consensus status message corresponding to the second consensus node; the first consensus status message is a byte array containing a consensus status and a consensus message bitmap, and the consensus message bitmap in the first consensus status message is used to represent the consensus message receiving status of the second consensus node during the consensus process; Parsing the bytes occupied by the consensus status in the first consensus status message to obtain the first block height and consensus stage corresponding to the second consensus node; the consensus process of the first block height includes a first consensus stage and a second consensus stage; If the consensus stage of the second consensus node is the second consensus stage, the consensus message bitmap in the first consensus status message is parsed according to the number of consensus nodes corresponding to the first block height to obtain a set of nodes to be reissued corresponding to the second consensus node; If the first consensus node includes the consensus message of the consensus nodes in the set of nodes to be reissued in the second consensus phase, the consensus message of the consensus nodes in the set of nodes to be reissued in the second consensus phase is sent to the second consensus node.

2. The method according to claim 1, characterized in that The parsing of the bytes occupied by the consensus state in the first consensus state message to obtain the first block height and consensus stage corresponding to the second consensus node includes: Determining a height byte interval and a step byte for indicating a consensus state in the first consensus state message, parsing bytes in the height byte interval, and obtaining a first block height corresponding to the second consensus node; The step bytes are parsed to obtain a byte parsing result, and a consensus stage corresponding to the second consensus node is determined according to the byte parsing result.

3. The method according to claim 2, characterized in that The first consensus stage includes a proposal stage, and the second consensus stage includes a pre-voting stage and a pre-submission stage; The determining the consensus stage corresponding to the second consensus node according to the byte parsing result includes: If the byte parsing result is the first value, determining that the consensus stage corresponding to the second consensus node is the proposal stage; If the byte parsing result is a second value, determining that the consensus stage corresponding to the second consensus node is a pre-voting stage; If the byte parsing result is a third value, it is determined that the consensus stage corresponding to the second consensus node is a pre-commit stage.

4. The method according to claim 1, characterized in that: If the consensus stage of the second consensus node is the second consensus stage, the consensus message bitmap in the first consensus status message is parsed according to the number of consensus nodes corresponding to the first block height to obtain a set of nodes to be reissued corresponding to the second consensus node, including: If the consensus stage of the second consensus node is the second consensus stage, obtaining the consensus committee corresponding to the first block height, and counting the number of consensus nodes in the consensus committee corresponding to the first block height; Determining, in the first consensus status message, a bitmap byte interval corresponding to a consensus message bitmap according to the number of consensus nodes; According to the values ​​of each bit contained in the bitmap byte interval, the set of nodes to be reissued corresponding to the second consensus node is determined.

5. The method according to claim 4, characterized in that The step of determining the set of nodes to be reissued corresponding to the second consensus node according to the values ​​of each bit contained in the bitmap byte interval includes: Determine, according to the values ​​of the respective bits contained in the bitmap byte interval, the bit sorting position of the bit whose value is zero in the bitmap byte interval; According to the node index information corresponding to the bit sorting position, a set of nodes to be reissued is determined in the consensus committee corresponding to the first block height; one consensus node in the consensus committee corresponding to the first block height corresponds to one node index information, and one node index information corresponds to one bit in the bitmap byte interval.

6. The method according to claim 4 or 5, characterized in that: The method further comprises: The consensus nodes in the consensus committee corresponding to the first block height are sorted according to the node sorting strategy to obtain a first node sorting list, and node index information is created for the consensus nodes in the first node sorting list.

7. The method according to claim 6, characterized in that The method further comprises: During the consensus process of the second block height, if it is detected that the consensus committee corresponding to the second block height is the same as the consensus committee corresponding to the first block height, the node index information corresponding to the consensus node in the first node sorting list continues to be retained; If it is detected that the consensus committee corresponding to the second block height is different from the consensus committee corresponding to the first block height, the consensus nodes in the consensus committee corresponding to the second block height are sorted according to the node sorting strategy to obtain a second consensus node sorting list, and node index information is created for the consensus nodes in the second consensus node sorting list.

8. The method according to claim 1, characterized in that The method further comprises: If the consensus stage of the second consensus node is the first consensus stage, the bytes occupied by the consensus message bitmap in the first consensus status message are parsed to obtain a bitmap parsing result; If the bitmap parsing result is a zero value, it is determined that the second consensus node has not received the proposal data corresponding to the first block height; If the first consensus node contains proposal data corresponding to the first block height, the proposal data corresponding to the first block height is sent to the second consensus node.

9. The method according to claim 1, characterized in that: The second consensus stage includes a pre-voting stage, and the consensus message of the pre-voting stage is pre-voting information; If the first consensus node includes the consensus message of the consensus node in the set of nodes to be reissued in the second consensus phase, sending the consensus message of the consensus node in the set of nodes to be reissued in the second consensus phase to the second consensus node includes: If the first consensus node contains the pre-voting information of the consensus nodes in the set of nodes to be reissued in the pre-voting stage, then in the pre-voting information set corresponding to the first consensus node, obtain the pre-voting information corresponding to the consensus nodes in the set of nodes to be reissued; Send the pre-voting information corresponding to the consensus node in the set of nodes to be reissued to the second consensus node.

10. The method according to claim 1, characterized in that The second consensus stage includes a pre-commit stage, and the consensus message of the pre-commit stage is pre-commit information; If the first consensus node includes the consensus message of the consensus node in the set of nodes to be reissued in the second consensus phase, sending the consensus message of the consensus node in the set of nodes to be reissued in the second consensus phase to the second consensus node includes: If the first consensus node contains the pre-submission information of the consensus nodes in the set of nodes to be reissued in the pre-submission stage, then in the pre-submission information set corresponding to the first consensus node, obtain the pre-submission information corresponding to the consensus nodes in the set of nodes to be reissued; Send the pre-submission information corresponding to the consensus node in the set of nodes to be reissued to the second consensus node.

11. The method according to claim 1, characterized in that: The method further comprises: If the first consensus node is in the first consensus stage corresponding to the first block height, and the first consensus node has received the proposal data of the first block height, fill the first block height in binary form to the height byte interval; Mapping the first consensus stage to a first value, and filling the first value into the step byte in binary form; Mapping the received state corresponding to the proposal data of the first block height into a first value, and filling the first value into the consensus message bitmap in binary form; The height byte interval filled with the first block height, the step byte filled with the first value, and the consensus message bitmap filled with the first value are combined into a second consensus status message corresponding to the first consensus node.

12. The method according to claim 1, characterized in that The method further comprises: If the first consensus node is in the pre-voting stage corresponding to the first block height, fill the first block height into the height byte interval in binary form, map the pre-voting stage into a second value, and fill the second value into the step byte in binary form; Obtain a pre-voting information set corresponding to the first block height, and obtain a first node sorting list corresponding to the first block height, and determine a bitmap byte interval corresponding to a consensus message bitmap according to the number of consensus nodes corresponding to the first node sorting list; the first node sorting list is obtained by sorting the consensus nodes in the consensus committee corresponding to the first block height; Matching the pre-voting information in the pre-voting information set with the consensus nodes in the first node sorting list to obtain a voting information matching result; Determine the value of the bit contained in the bitmap byte interval according to the voting information matching result and the correspondence between the consensus nodes in the first node sorting list and the bits contained in the bitmap byte interval; The height byte interval filled with the first block height, the step byte filled with the second value, and the bitmap byte interval are combined into a second consensus status message corresponding to the first consensus node.

13. A blockchain consensus state synchronization device, characterized in that: The device runs in a first consensus node, and includes: A message acquisition module, used to acquire a first consensus status message corresponding to the second consensus node; the first consensus status message is a byte array containing a consensus status and a consensus message bitmap, and the consensus message bitmap in the first consensus status message is used to represent the consensus message reception status of the second consensus node during the consensus process; A first parsing module is used to parse the bytes occupied by the consensus state in the first consensus state message to obtain the first block height and consensus stage corresponding to the second consensus node; the consensus process of the first block height includes a first consensus stage and a second consensus stage; A second parsing module is configured to parse the consensus message bitmap in the first consensus status message according to the number of consensus nodes corresponding to the first block height to obtain a set of nodes to be reissued corresponding to the second consensus node if the consensus stage of the second consensus node is the second consensus stage; The voting reissue module is used to send the consensus message of the consensus node in the set of nodes to be reissued in the second consensus stage to the second consensus node if the first consensus node contains the consensus message of the consensus node in the set of nodes to be reissued in the second consensus stage.

14. A computer device, characterized in that: including memory and processor; The memory is connected to the processor, the memory is used to store a computer program, and the processor is used to call the computer program so that the computer device executes the method according to any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and the computer program is suitable for being loaded and executed by a processor, so that a computer device having the processor executes the method according to any one of claims 1 to 12.

16. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to any one of claims 1 to 12 when being executed by a processor.

Images