Node consensus method and related apparatus

Abstract

The application relates to the computer technical field, and provides a node consensus method and related devices, which are used for improving consensus efficiency and improving the performance of a distributed system, wherein the method comprises the following steps: when a target proposal is acquired and the total number of proposal generation recorded locally reaches a total number threshold, an abnormal node is screened out from each consensus node based on the respective proposal generation number of each consensus node; then, in a first voting in a pre-voting stage and a second voting in a pre-commit stage, the node identifier of the abnormal node is carried, consensus is performed through the voting of the node identifier of the abnormal node, and the abnormal node is deleted from each consensus node. In this way, the abnormal node is identified and deleted through the historical proposal record, so that the performance of the distributed system is ensured.

Description

Technical Field

[0001] This application relates to the field of computer technology, and provides a node consensus method and related apparatus. Background Technology

[0002] With the continuous development of computer technology, distributed systems are now widely used computing systems, applied in many fields such as blockchain and the ZooKeeper distributed service framework. In the operation of a distributed system, consensus needs to be reached on the messages to be processed from clients.

[0003] In related technologies, consensus mainly includes three stages: proposal, prevote, and precommit. Figure 1 As shown, taking four consensus nodes as an example, the consensus process is as follows:

[0004] After receiving a consensus request from a client, the master node generates a proposal and then broadcasts it to all slave nodes. Each slave node, upon receiving the proposal, enters the pre-voting phase, during which it generates a prevote vote (if a slave node does not receive a proposal within the timer duration, it generates a prevote vote for an empty proposal) and broadcasts its prevote vote to other nodes.

[0005] After receiving more than 2 / 3 + 1 ≈ 3 prevote votes, each node enters the precommit phase, generates a precommit vote, and broadcasts its own precommit vote to other nodes.

[0006] After each node receives 2 / 3+1≈3 precommit votes, it enters the commit phase. During the commit phase, if the consensus proposal is an empty proposal, then the proposal will not be committed.

[0007] To ensure fairness and security, after each consensus is reached, a node is typically switched to become the master node. However, if there is a faulty node among the consensus nodes, when the faulty node becomes the master node, it cannot generate a proposal and send it to other nodes for consensus. This causes other nodes to cast empty votes after the timer expires to reach an empty consensus. Then, a normal node is switched to become the master node, and the normal node generates a proposal and reaches a consensus. Obviously, the performance of a distributed system will be significantly reduced when there are faulty nodes. Summary of the Invention

[0008] This application provides a node consensus method and related apparatus to improve consensus efficiency and enhance the performance of distributed systems.

[0009] In a first aspect, embodiments of this application provide a node consensus method applied to consensus nodes, the method comprising:

[0010] When a target proposal is obtained and the total number of proposals generated locally reaches the total number threshold, based on the number of proposals generated by each consensus node in the distributed system, abnormal nodes that meet the set abnormal node conditions are selected from the consensus nodes.

[0011] Send a first vote of the pre-voting phase to each of the other nodes in the consensus nodes. The first vote carries the node identifier of the abnormal node and receives the first vote of the pre-voting phase sent by each of the other nodes.

[0012] When the number of first votes carrying the node identifier of the abnormal node reaches a first vote threshold among the received first votes, a second vote for the pre-submission stage is sent to each of the other nodes, the second vote carrying the node identifier, and the second vote for the pre-submission stage sent by each of the other nodes is received.

[0013] When the number of second votes carrying the node identifier of the abnormal node reaches the second vote threshold among the received second votes, it is determined that a consensus has been reached on the target proposal, and the abnormal node is removed from each consensus node.

[0014] Secondly, embodiments of this application provide a node consensus device, comprising:

[0015] The filtering unit is used to filter out abnormal nodes that meet the set abnormal node conditions from the consensus nodes when the target proposal is obtained and the total number of proposals generated locally reaches the total number threshold. This is based on the number of proposals generated by each consensus node in the distributed system, which is recorded locally.

[0016] The pre-voting unit is used to send a first vote of the pre-voting stage to each of the other nodes in the consensus nodes. The first vote carries the node identifier of the abnormal node and receives the first vote of the pre-voting stage sent by each of the other nodes.

[0017] The pre-submission unit is configured to send a second pre-submission phase vote to each of the other nodes when the number of first votes carrying the node identifier of the abnormal node reaches a first vote threshold, wherein the second vote carries the node identifier, and to receive the second pre-submission phase vote sent by each of the other nodes.

[0018] The node adjustment unit is used to determine that a consensus has been reached on the target proposal when the number of second votes carrying the node identifier of the abnormal node in each of the received second votes reaches a second vote threshold, and to delete the abnormal node from each consensus node.

[0019] As one possible implementation, before filtering out abnormal nodes that meet the set abnormal node conditions from the consensus nodes based on the proposal generation counts corresponding to each consensus node in the distributed system, when the target proposal is obtained and the total number of proposal generation counts recorded locally reaches the total number threshold, the filtering unit is further configured to:

[0020] In each round of consensus, if all consensus nodes reach a consensus on a non-empty proposal generated by the master node, the number of proposals generated by the master node is accumulated, and the total number of proposals generated is updated; wherein, the master node is one of the consensus nodes.

[0021] As one possible implementation, node proposal mapping information is recorded locally, which includes: the node identifier of each consensus node and the number of times the corresponding proposal is generated;

[0022] The filtering unit is used to determine the total number of proposals generated in the local record in the following way:

[0023] From the node proposal mapping information, obtain the number of proposals generated for each consensus node; based on the obtained number of proposals generated, determine the total number of proposals generated.

[0024] As one possible implementation, when filtering out abnormal nodes that meet the set abnormal node conditions from among the consensus nodes based on the number of proposals generated by each consensus node in the locally recorded distributed system, the filtering unit is specifically used for:

[0025] From the consensus nodes, at least one consensus node whose number of proposal generation is lower than the proposal generation threshold is selected; the proposal generation threshold is determined based on the number of proposals generated by each consensus node.

[0026] One of the at least one consensus nodes is designated as an abnormal node that meets the set abnormal node conditions.

[0027] As one possible implementation, when selecting one of the at least one consensus nodes as an abnormal node that meets the set abnormal node conditions, the filtering unit is specifically used for:

[0028] If the number of at least one consensus node is one, then the selected consensus node is directly regarded as an abnormal node that meets the set abnormal node conditions.

[0029] If there are multiple consensus nodes, then based on the number of proposals generated by each of the at least one consensus node, one consensus node is determined from the selected multiple consensus nodes, and this one consensus node is regarded as an abnormal node that meets the set abnormal node conditions.

[0030] As one possible implementation, after removing the abnormal nodes from the consensus nodes, the filtering unit is further configured to:

[0031] Reset the number of proposals generated by each consensus node in the distributed system, which is recorded locally.

[0032] Reset the total number of proposals generated in the local record.

[0033] As one possible implementation, the filtering unit is also used for:

[0034] If the consensus node is the master node, then after receiving a consensus request from the client for the target transaction information, the target proposal is generated for the target transaction information.

[0035] If the consensus node is a slave node, then the target proposal is obtained through the master node.

[0036] As one possible implementation, when obtaining the target proposal through the master node, the filtering unit is specifically used for:

[0037] If a proposal is received from the master node within a set time period after the master node receives a consensus request from the client, then the proposal will be taken as the target proposal.

[0038] If no proposal is received from the master node within a set time period after the consensus request from the client is received, then an empty proposal will be used as the target proposal.

[0039] Thirdly, embodiments of this application provide an electronic device, including a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the above-described node consensus method.

[0040] Fourthly, embodiments of this application provide a computer-readable storage medium including a computer program, which, when run on an electronic device, causes the electronic device to perform the steps of the above-described node consensus method.

[0041] Fifthly, embodiments of this application provide a computer program product, the program product including a computer program stored in a computer-readable storage medium, wherein a processor of an electronic device reads from and executes the computer program from the computer-readable storage medium, causing the electronic device to perform the steps of the above-described node consensus method.

[0042] In this embodiment, when a target proposal is obtained and the total number of proposals generated locally reaches the total number threshold, abnormal nodes are selected from each consensus node based on the number of proposals generated by each consensus node locally. Then, the node identifier of the abnormal node is carried in the first vote of the pre-voting stage, and the first vote is broadcast. When the number of first votes carrying the node identifier of the abnormal node reaches the first vote threshold, the second vote of the pre-submission stage carrying the node identifier of the abnormal node is broadcast, and the second vote of the pre-submission stage sent by each other node is received. Then, when the number of second votes carrying the node identifier of the abnormal node reaches the second vote threshold, a consensus is reached on the target proposal, and the abnormal node is deleted from each consensus node.

[0043] In this way, by analyzing historical proposal records, the node identifiers of abnormal nodes are attached to the first and second votes. Finally, through the security guarantee of the Byzantine consensus protocol itself, it is ensured that all nodes unanimously remove abnormal nodes from the consensus node list. Thus, when faced with node failures, the entire consensus network can safely and correctly delete abnormal nodes, ultimately ensuring that as many nodes as possible participating in the consensus are normal nodes, thereby significantly improving the performance of the entire blockchain network.

[0044] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0045] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0046] Figure 1 This is a logical diagram illustrating a node consensus process.

[0047] Figure 2A This is a schematic diagram of the structure of a data sharing system provided in an embodiment of this application;

[0048] Figure 2BThis is a schematic diagram of a blockchain structure provided in the embodiments of this application;

[0049] Figure 2C This is a logical diagram illustrating a block generation process provided in an embodiment of this application;

[0050] Figure 3 This is a flowchart illustrating a node consensus method provided in an embodiment of this application;

[0051] Figure 4 This is a logical diagram illustrating a node consensus process where node 1 acts as the master node, as provided in an embodiment of this application.

[0052] Figure 5 This is a schematic diagram of a node proposal map with four consensus nodes provided in an embodiment of this application;

[0053] Figure 6 This is a logical diagram illustrating another node consensus process where node 1 acts as the master node, as provided in this application embodiment.

[0054] Figure 7 This is a schematic diagram of an initial node proposal map provided in an embodiment of this application;

[0055] Figure 8 This is a logical diagram of the first round of consensus process provided in the embodiments of this application;

[0056] Figure 9 This is a schematic diagram of the node proposal map after the first round of consensus provided in the embodiments of this application;

[0057] Figure 10 This is a schematic diagram of the node proposal map in the multi-round consensus process provided in the embodiments of this application;

[0058] Figure 11 This is a logical diagram of the fourth round of consensus process provided in the embodiments of this application;

[0059] Figure 12A This is a logical diagram illustrating a consensus process provided in an embodiment of this application.

[0060] Figure 12B This is a schematic diagram of the node proposal map after deleting abnormal nodes, as provided in the embodiments of this application.

[0061] Figure 13 This is a schematic diagram of the structure of a node consensus device provided in the embodiments of this application;

[0062] Figure 14 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0063] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings of the embodiments of this application. Obviously, the described embodiments are only some embodiments of the technical solutions of this application, and not all embodiments. Based on the embodiments recorded in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the technical solutions of this application.

[0064] It should be noted that the terms "first" and "second," etc., used in the embodiments of this application are used to distinguish different objects, rather than to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or modules is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other steps or modules inherent to these processes, methods, products, or devices.

[0065] In this application, "multiple" can mean at least two, such as two, three, or more, and this application does not impose any limitations on the embodiments. "And / or" describes the relationship between associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following associated objects have an "or" relationship.

[0066] With the continuous development of computer technology, distributed systems are now widely used computing systems, applied in many fields such as blockchain and the ZooKeeper distributed service framework. In the operation of a distributed system, consensus needs to be reached on the messages to be processed from clients.

[0067] In related technologies, consensus mainly includes three stages: Proposal, Prevote, and Precommit (different Byzantine algorithms may have different names, but their core processing flow consists of these three stages), such as... Figure 1 As shown, taking four consensus nodes as an example, the consensus process is as follows:

[0068] After receiving a consensus request from a client, the master node generates a proposal and then broadcasts it to all slave nodes. Each slave node, upon receiving the proposal, enters the pre-voting phase, during which it generates a prevote vote (if a slave node does not receive a proposal within the timer duration, it generates a prevote vote for an empty proposal) and broadcasts its prevote vote to other nodes.

[0069] After receiving three prevote votes, each node enters the pre-commit phase, generates a precommit vote, and broadcasts its precommit vote to other nodes.

[0070] After each node receives 3 precommit votes, it enters the commit phase. During the commit phase, if the consensus proposal is an empty proposal, then the proposal will not be committed.

[0071] To ensure fairness and security, after each consensus is reached, a node is typically switched to become the master node. However, if there is a faulty node among the consensus nodes, when the faulty node becomes the master node, it cannot generate a proposal and send it to other nodes for consensus. This causes other nodes to cast empty votes after the timer expires to reach an empty consensus. Then, a normal node is switched to become the master node, and the normal node generates a proposal and reaches a consensus. Obviously, the performance of a distributed system will be significantly reduced when there are faulty nodes.

[0072] In this embodiment, when a target proposal is obtained and the total number of proposals generated locally reaches the total number threshold, abnormal nodes are selected from each consensus node based on the number of proposals generated by each consensus node locally. Then, the node identifier of the abnormal node is carried in the first vote of the pre-voting stage, and the first vote is broadcast. When the number of first votes carrying the node identifier of the abnormal node reaches the first vote threshold, the second vote of the pre-submission stage carrying the node identifier of the abnormal node is broadcast, and the second vote of the pre-submission stage sent by each other node is received. Then, when the number of second votes carrying the node identifier of the abnormal node reaches the second vote threshold, a consensus is reached on the target proposal, and the abnormal node is deleted from each consensus node.

[0073] In this way, by analyzing historical proposal records, the node identifiers of abnormal nodes are attached to the first and second votes. Finally, through the security guarantee of the Byzantine consensus protocol itself, it is ensured that all nodes unanimously remove abnormal nodes from the consensus node list. Thus, when faced with node failures, the entire consensus network can safely and correctly delete abnormal nodes, ultimately ensuring that as many nodes as possible participating in the consensus are normal nodes, thereby significantly improving the performance of the entire blockchain network.

[0074] See Figure 2AAs shown, this is a data sharing system provided in this embodiment of the application. The data sharing system 200 refers to a system for data sharing between nodes. This data sharing system may include multiple nodes 201, which can refer to various clients within the data sharing system. Each node 201, during normal operation, can receive input information and maintain shared data within the data sharing system based on the received input information. To ensure information interoperability within the data sharing system, information connections can exist between each node, allowing information transmission between nodes. For example, when any node in the data sharing system receives input information, other nodes in the system obtain the input information according to a consensus algorithm and store it as data in the shared data, ensuring consistency of data stored on all nodes in the data sharing system.

[0075] Each node in the data sharing system has a corresponding node identifier, and each node can also store the node identifiers of other nodes in the data sharing system. This allows for the subsequent broadcasting of generated blocks to other nodes in the data sharing system based on their node identifiers. Each node can maintain a node identifier list as shown in the table below, storing the node name and node identifier in this list. The node identifier can be an Internet Protocol (IP) address or any other information that can be used to identify the node. Table 1 uses IP addresses as an example.

[0076] Table 1 Node Identifier List

[0077] Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node N 119.123.789.258

[0078] Each node in the data-sharing system stores the same blockchain. A blockchain consists of multiple blocks; see [link to blockchain documentation]. Figure 2B A blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores input information feature values, version number, timestamp, and difficulty value, while the block body stores the input information. The next block after the genesis block takes the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores the input information feature values ​​of the current block, the block header feature values ​​of the parent block, version number, timestamp, and difficulty value, and so on. This ensures that the block data stored in each block is related to the block data stored in the parent block, guaranteeing the security of the input information in the blocks.

[0079] When generating the individual blocks in the blockchain, see Figure 2CWhen a node in the blockchain receives input information from the entire network, it verifies the input information. After verification, it stores the input information in a memory pool and updates its hash tree used to record the input information. Then, it updates the timestamp to the time the input information was received and tries different random numbers multiple times to calculate the feature value, ensuring that the calculated feature value satisfies the following formula:

[0080] SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x))<TARGET

[0081] Wherein, SHA256 is the feature value algorithm used to calculate the feature value; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header feature value of the parent block of the current block; merkle_root is the feature value of the input information; ntime is the update time of the update timestamp; nbits is the current difficulty, which is a fixed value for a period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the feature value threshold, which can be determined based on nbits.

[0082] Thus, when a random number satisfying the above formula is calculated, the information can be stored accordingly, generating a block header and a block body to obtain the current block. Subsequently, the node where the blockchain resides sends the newly generated block to other nodes in its data sharing system based on the node identifiers of other nodes in the data sharing system. The other nodes then verify the newly generated block and add it to their stored blockchain after verification.

[0083] See Figure 3 As shown, this is a flowchart illustrating a node consensus method provided in an embodiment of this application. This process is applied to consensus node x, which can be any consensus node in a distributed system. The specific process is as follows:

[0084] S301. When the target proposal is obtained and the total number of proposals generated locally reaches the total number threshold, consensus node x selects abnormal nodes that meet the set abnormal node conditions from among the consensus nodes based on the number of proposals generated by each consensus node in the distributed system recorded locally.

[0085] Before S301 is executed, in each round of consensus, if all consensus nodes reach a consensus on the non-empty proposal generated by the master node, the number of proposals generated by the master node is accumulated and the total number of proposals generated is updated; where the master node is one of the consensus nodes.

[0086] The consensus reached by all consensus nodes on a non-empty proposal generated by the master node can mean either that all consensus nodes reach a consensus on a proposal generated by the master node during the pre-commit phase, and that the proposal is a non-empty proposal, or that all consensus nodes reach a consensus on a proposal generated by the master node during the commit phase (if the proposal that reaches a consensus during the pre-commit phase is a proposal, then the consensus nodes will not commit this empty proposal).

[0087] The total number of proposals generated is the sum of the number of proposals generated by each consensus node.

[0088] The number of proposals generated is incremented by a set value each time. For example, in each round of consensus, if all consensus nodes reach a consensus on a non-empty proposal generated by the master node, the number of proposals generated by the master node is increased by 1, and the total number of proposals generated is increased by 1.

[0089] For example, refer to node 1, node 2, node 3, and node 4. Figure 4 As shown, in one round of consensus, Node 1 becomes the master node. After receiving a consensus request from the client, Node 1 generates Proposal 1 and broadcasts it to Nodes 2, 3, and 4, entering the pre-voting phase. In the pre-voting phase, it generates a prevote vote and broadcasts its own prevote vote to Nodes 2, 3, and 4. Each of Nodes 2, 3, and 4, upon receiving the proposal, enters the pre-voting phase, generating a prevote vote and broadcasting its own prevote vote to other nodes. After receiving 2 × 4 / 3 + 1 ≈ 3 prevote votes, each of Nodes 1, 2, 3, and 4 enters the pre-commit phase, generating a precommit vote and broadcasting its own precommit vote to other nodes. After each of nodes 1, 2, 3, and 4 receives 2×4 / 3+1≈3 precommit votes, it enters the commit phase. During the commit phase, if proposal 1 is not an empty proposal, it will be committed. That is, nodes 1, 2, 3, and 4 reach a consensus on proposal 1. The number of proposals generated for node 1 is incremented by 1, and the total number of proposals generated is also incremented by 1.

[0090] As one possible implementation, the number of proposals generated by each consensus node and the total number of proposals generated can be recorded in the node proposal mapping information. That is, the node proposal mapping information is recorded locally. The node proposal mapping table contains: the node identifier of each consensus node and the number of proposals generated accordingly.

[0091] For example, the node proposal mapping information is in the form of key-value pairs, and can also be called a node mapping map. The key is the node identifier of each consensus node, and the value is the number of proposals generated by the corresponding consensus node. The number of proposals generated is a natural number, with an initial value of 0.

[0092] Each node identifier is used to uniquely identify a consensus node. The node identifier can be represented by a sequence number (ID) or an Internet Protocol (IP) address, but is not limited to these two methods.

[0093] For example, see Figure 5 As shown, in the node mapping map, the key contains: nodeID1, nodeID2, nodeID3, and nodeID4, and the value is the number of proposals generated by the corresponding consensus node. Here, nodeID1 is the node identifier of node 1, nodeID2 is the node identifier of node 2, nodeID3 is the node identifier of node 3, and nodeID4 is the node identifier of node 4. Assuming that the initial value of the value is 0, in the first round of consensus, all consensus nodes reach consensus on the non-empty proposals generated by node 1, and the number of proposals generated by nodes 1, 2, 3, and 4 is 1, 0, 0, and 0, respectively. In the second round of consensus, all consensus nodes reach consensus on the non-empty proposals generated by node 2, and the number of proposals generated by nodes 1, 2, 3, and 4 is 1, 1, 0, and 0, respectively.

[0094] In this embodiment of the application, the total number of proposals generated locally can be determined by: obtaining the number of proposals generated for each consensus node from the node proposal mapping table; and determining the total number of proposals generated based on the obtained number of proposals generated.

[0095] For example, as shown in Table 5, after the second round of consensus, from the node proposal mapping table, the number of proposals generated by nodes 1, 2, 3 and 4 are 1, 1, 0 and 0 respectively. Based on the obtained number of proposals generated, the total number of proposals generated is determined to be 2.

[0096] In this embodiment of the application, when obtaining the target proposal, there are, but are not limited to, the following two possible situations:

[0097] Scenario 1: If consensus node x is the master node, then after receiving a consensus request from the client for the target transaction information, it generates a target proposal for the target transaction information.

[0098] It should be noted that, in the embodiments of this application, the target transaction information refers to the information that requires consensus among all consensus nodes. The target transaction information includes, but is not limited to, electronic currency transaction records, shared ledger operation records, smart contracts, etc.

[0099] Taking consensus node x as an example, assuming that node 1 is the master node, after receiving a consensus request from the client for the target transaction information, node 1 generates a target proposal for the target transaction information.

[0100] Scenario 2: If consensus node x is a slave node, then the target proposal is obtained through the master node.

[0101] To ensure the stable operation of the algorithm, each consensus node has a timer during the proposal phase to wait for the master node to generate a proposal. If a slave node does not receive a proposal constructed by the master node within a certain period of time, it will vote on an empty proposal in order to ensure that the algorithm can continue and enter the next round of consensus as soon as possible.

[0102] It should be noted that in this embodiment of the application, in order to ensure that the master node can construct the proposal on time, the timeout time is generally set to a large value, such as 30 seconds (s).

[0103] Specifically, if a proposal is received from the master node within a set time period after receiving a consensus request from the client, the proposal will be used as the target proposal; if no proposal is received from the master node within a set time period after receiving a consensus request from the client, an empty proposal will be used as the target proposal.

[0104] Taking consensus node x as node 2 as an example, assuming node 1 is the master node and node 2 is the slave node, and the set time is 30 seconds, if a proposal is received from node 1 within the set time after the consensus request is received from the master node, then that proposal is taken as the target proposal; if no proposal is received from node 1 within the set time after the consensus request is received from the master node, then an empty proposal is taken as the target proposal.

[0105] Specifically, when executing S301, if a target proposal is obtained and the total number of proposals generated locally reaches the total number threshold, consensus node x selects at least one consensus node whose corresponding proposal generation count is lower than the proposal generation threshold. Then, one of these at least one consensus node is designated as an abnormal node that meets the set abnormal node conditions. The proposal generation threshold is determined based on the number of proposals generated by each consensus node.

[0106] Specifically, when consensus node x identifies one of the at least one consensus node as an abnormal node that meets the set abnormal node conditions, it can use, but is not limited to, the following methods:

[0107] If the number of at least one consensus node is one, then consensus node x will directly select one of the consensus nodes as the abnormal node that meets the set abnormal node conditions.

[0108] If there are multiple consensus nodes, then consensus node x determines one consensus node from the multiple consensus nodes selected based on the number of proposals generated by each of the at least one consensus node, and this consensus node is designated as an abnormal node that meets the set abnormal node conditions.

[0109] The proposal generation threshold can be determined based on the average number of proposals generated by each consensus node. For example, 1 / 10 of the average number of proposals generated can be used as the proposal generation threshold. It should be noted that the average value is used as an example in this embodiment, and other statistical values ​​such as the median can also be used in actual applications.

[0110] When determining a consensus node from multiple selected consensus nodes, the consensus node with the fewest proposal generation times can be selected as the determined consensus node, or any one of the selected consensus nodes can be selected as the determined consensus node. There are no restrictions on this, and it will not be elaborated here.

[0111] Taking a total number of proposals threshold of 1000 as an example, since each consensus node records the last 1000 proposals generated, when a node becomes the master node, other nodes analyze the last 1000 proposals. Under normal circumstances, the number of proposals generated by each consensus node in the last 1000 proposals should be average. If the number of proposals generated by a consensus node in the last 1000 proposals is lower than the proposal generation threshold (e.g., 1 / 10 of the average), then this node is an abnormal node (also called a faulty node). Consensus nodes can then vote to remove the abnormal node from the consensus, thereby ensuring that all consensus nodes participating in the consensus are normal nodes.

[0112] Taking four consensus nodes as an example, in the last 1000 generated proposals, if a consensus node is a node with normal system resources and normal operation, then the number of proposals generated by that node should be close to 250. However, if a consensus node only generates 25 proposals in the last 1000, then other nodes can determine that this consensus node is an abnormal node. An abnormal node may be due to operational abnormalities caused by downtime or network failures, because if it were a node with normal system resources and normal operation, its historical proposal activity in the last 1000 proposals would not be less than 1 / 10 of the average. Therefore, at the 1001st proposal, the consensus nodes can vote to remove the abnormal node whose historical proposal activity in the last 1000 proposals is less than 1 / 10 of the average.

[0113] For example, Node 1 is the master node, and Nodes 2, 3, and 4 are slave nodes. The total number of proposals threshold is 1000, and the proposal generation threshold is 1 / 10 of the average value, i.e., the proposal generation threshold is 1000 × 1 / 10 = 100. The number of proposals generated by Nodes 1, 2, 3, and 4 are 340, 320, 320, and 20, respectively. Taking Node 1 as an example, when Node 1 obtains the target proposal and the total number of proposals generated locally recorded by Node 1 reaches 1000, Node 1 selects at least one consensus node from the consensus nodes whose corresponding number of proposals generated is less than 100. The selected consensus node is Node 4. At this time, Node 1 directly regards Node 4 as an abnormal node that meets the set abnormal node conditions.

[0114] For example, node 1 is the master node, and nodes 2, 3, and 4 are slave nodes. The total number of proposals threshold is 1000, and the proposal generation threshold is 1 / 10 of the average value, i.e., the proposal generation threshold is 1000 × 1 / 10 = 100. The number of proposals generated by nodes 1, 2, 3, and 4 are 450, 450, 60, and 40, respectively. Taking node 1 as an example, when node 1 obtains the target proposal and the total number of proposals generated locally recorded by node 1 reaches 1000, node 1 selects at least one consensus node from among the consensus nodes whose corresponding number of proposals generated is less than 100. The selected consensus nodes include nodes 3 and 4. At this time, based on the number of proposals generated by nodes 3 and 4, consensus node 1 selects the consensus node with the fewest corresponding number of proposals generated from nodes 3 and 4: node 4, as a determined consensus node, and regards node 4 as an abnormal node that meets the set abnormal node conditions.

[0115] Each consensus node can obtain the number of node proposals of each consensus node from the node proposal map recorded locally. Then, from each consensus node, consensus nodes with a value less than 1 / 10 of the average value are selected, and abnormal nodes are identified from the selected consensus nodes.

[0116] S302. Consensus node x sends the first vote of the pre-voting phase to each of the other consensus nodes. The first vote carries the node identifier of the abnormal node and receives the first vote of the pre-voting phase sent by each of the other nodes.

[0117] In this embodiment, the first vote in the pre-voting phase can also be called a prevote vote. For each consensus node, each node generates a prevote vote during the prevote phase. The prevote vote includes the ID of the node to be removed, i.e., the node identifier of the abnormal node. Furthermore, each consensus node broadcasts its generated prevote vote to all other nodes in the consensus node hierarchy and receives prevote votes from each of the other nodes.

[0118] Taking consensus node x as an example of node 1, see [link / reference]. Figure 6 As shown, assuming that the abnormal node identified in S301 is node 4, in the prevote phase of the Byzantine consensus, node 1 generates a prevote vote, which carries the node identifier of node 4: nodeID4. Then, node 1 broadcasts its own generated prevote vote to nodes 2, 3 and 4, and receives the prevote votes sent by nodes 2, 3 and 4 respectively.

[0119] S303. When the number of first votes carrying the node identifier of the abnormal node in the received first votes reaches the first vote threshold, consensus node x sends the second vote of the pre-commit phase to each other node, the second vote carrying the node identifier, and receives the second vote of the pre-commit phase sent by each other node.

[0120] In this embodiment of the application, the second vote in the pre-commit phase can also be called the precommit vote. The first vote threshold can be 2n / 3+1, where n represents the number of consensus nodes. It should be noted that when the value of 2n / 3+1 is not an integer, the first vote threshold is obtained by rounding down. For example, when there are 4 consensus nodes, the first vote threshold is 2n / 3+1, that is, when the number of first votes received by consensus node x carrying the node identifier of the abnormal node reaches 3, it enters the precommit phase.

[0121] It should be noted that each received first vote may include the first vote generated by the consensus node x itself. In this case, the first vote threshold can be 2n / 3+1. Alternatively, each received first vote may not include the first vote generated by the consensus node x itself. In this case, the first vote threshold can be 2n / 3. There is no restriction on this.

[0122] For each consensus node, if a node receives at least 2n / 3+1 prevote votes with the same node identifier (i.e., the node identifier of the abnormal node) in the second phase (prevote phase), then in the third phase (precommit phase), it generates a precommit vote and adds the node ID to be kicked out, i.e., the node identifier of the abnormal node, to the content of the precommit vote. Then, it broadcasts its own generated precommit vote to all other nodes in the consensus nodes and receives the precommit votes sent by each other node.

[0123] Taking consensus node x as an example of node 1, see [link / reference]. Figure 6 As shown, assuming the abnormal node identified in S301 is node 4, during the prevote phase of the Byzantine consensus, node 1 receives prevote votes from nodes 2, 3, and 4, and each of these prevote votes carries nodeID4. Therefore, the number of received first votes carrying nodeID4 reaches 2. At this point, node 1 sends precommit votes to nodes 2, 3, and 4, each carrying nodeID4, and also receives precommit votes from nodes 2, 3, and 4. It should be noted that because node 4 is abnormal, it cannot participate in voting, meaning it cannot receive or send prevote or precommit votes. Figure 6 The process of sending a vote to node 4 is not shown in the document.

[0124] It should be noted that, in this embodiment of the application, if the number of first votes carrying the node identifier of the abnormal node in each of the received first votes does not reach the first vote threshold, and the number of received first votes reaches the first vote threshold, then the consensus node x can directly enter the precommit stage and generate a precommit vote without carrying the node identifier.

[0125] S304. When the number of second votes carrying the node identifier of the abnormal node in the received second votes reaches the second vote threshold, consensus node x determines that a consensus has been reached on the target proposal and removes the abnormal node from each consensus node.

[0126] The second vote threshold can be the same as or different from the first vote threshold. In this paper, we will take the example of the second vote threshold being the same as the first vote threshold.

[0127] For each consensus node, if a node receives at least 2n / 3+1 precommit votes carrying the same node identifier (i.e., the node identifier of the abnormal node) in the third phase (precommit phase), it confirms that consensus has been reached on the target proposal and removes the abnormal node from the consensus nodes. Furthermore, if the target proposal that has reached consensus is an empty proposal, then the target proposal will not be committed; if the target proposal that has reached consensus is a non-empty proposal, then the target proposal will be committed.

[0128] Taking consensus node x as an example of node 1, see [link / reference]. Figure 6 As shown, assuming that the abnormal node identified in S301 is node 4, in the precommit phase of the Byzantine consensus, the second vote threshold is 3. Node 1 receives precommit votes from nodes 2, 3, and 4, and each of the precommit votes from nodes 2, 3, and 4 carries nodeID4. Then, it is determined that the number of first votes carrying nodeID4 received has reached 3. At this point, it is determined that a consensus has been reached on the target proposal, and nodeID4 is deleted from each consensus node. The consensus nodes after deletion include: node 1, node 2, and node 3.

[0129] Furthermore, after deleting or adding a node, the number of proposals generated for each consensus node in the distributed system is reset in the local record, and the total number of proposals generated in the local record is also reset.

[0130] Specifically, the number of proposals generated and the total number of proposals generated for each consensus node in the distributed system, which are recorded locally, are reset to their initial values, for example, 0.

[0131] Taking consensus node x as an example of node 1, see [link / reference]. Figure 6 As shown, for the node proposal map recorded locally by node 1, the node identifier of node 4 and its corresponding value are deleted from the node proposal map. The number of proposals generated by each of nodes 1, 2 and 3 recorded in the node proposal map is reset to 0. Since the sum of the number of proposals generated by each consensus node is the total number of proposals generated, the total number of proposals generated is also reset to 0.

[0132] In this embodiment, by analyzing historical proposal records, the node ID (i.e., the node identifier of the abnormal node) to be kicked out is included in the node voting (prevote voting and precommit voting). Finally, through the security guarantee of the Byzantine consensus protocol itself, it is ensured that all nodes unanimously kick out the node that needs to be kicked out from the consensus. In this way, when faced with node failure, the entire consensus network can safely and correctly kick out the faulty node, ultimately ensuring that as many nodes as possible participating in the consensus are normal nodes, thereby significantly improving the performance of the entire blockchain network.

[0133] The following description uses a specific embodiment as an example.

[0134] See Figure 7 As shown, the distributed system contains 6 consensus nodes, namely node 1 to node 6. Each of node 1 to node 6 records a node proposal map locally. Each node maintains its own node proposal map and initializes it. The node proposal map contains the node IDs of each of node 1 to node 6, and the value corresponding to each node ID is initialized to 0.

[0135] Suppose that node 4 becomes an abnormal node due to a crash or other reasons, while the other 5 nodes are normal nodes.

[0136] In the first round of consensus, Node 1 became the master node. (See also...) Figure 8 As shown, node 1 is a normal node. Therefore, after receiving the consensus request from the client, node 1 generates a proposal and broadcasts the proposal to nodes 2 to 6. In the pre-voting phase, node 1 generates a prevote and broadcasts its prevote to nodes 2 to 6.

[0137] Nodes 2, 3, 5, and 6 are all normal nodes. Therefore, after receiving the proposal from node 1, each of these nodes generates a prevote during the prevote phase and broadcasts its prevote to other nodes.

[0138] After each of the nodes 1, 2, 3, 5, and 6 receives 2 × 6 / 3 + 1 = 5 prevote votes, it generates a precommit vote during the precommit phase and broadcasts its precommit vote to the other nodes.

[0139] Each of nodes 1, 2, 3, 5, and 6, after receiving 2 × 6 / 3 + 1 = 5 precommit votes, determines that a consensus has been reached on the proposal and, if the proposal is not empty, commits it. After committing the proposal, nodes 1 through 6 increment the value of the node ID (key of node 1) in their maintained node proposal map by 1, effectively incrementing the proposal generation count of node 1 by 1. See also... Figure 9 As shown, after the consensus was finally reached, the node proposal map of each node and the value of each node ID are as follows: the number of proposals generated for each of nodes 1 to 6 are 1, 0, 0, 0, 0, 0.

[0140] In the second round of consensus, Node 2 becomes the master node. After Node 2 generates a proposal, Nodes 1 through 6 reach a consensus on the proposal generated by Node 2. Since the consensus process for the proposal generated by Node 2 is the same as the process for reaching a consensus on the proposal generated by Node 2, it will not be repeated here. Please refer to [link / reference]. Figure 10 As shown, after the consensus was finally reached, the node proposal map of each node and the value of each node ID are as follows: the number of proposals generated for each of nodes 1 to 6 are 1, 1, 0, 0, 0, 0.

[0141] In the third round of consensus, node 3 becomes the master node. After node 3 generates a proposal, nodes 1 through 6 reach a consensus on the proposal generated by node 3. Since the consensus process for the proposal generated by node 3 is the same as the process for reaching a consensus on the proposal generated by node 3, it will not be repeated here. Please refer to [link to relevant documentation]. Figure 10 As shown, after the consensus was finally reached, the node proposal map of each node and the value of each node ID are as follows: the number of proposals generated for each of nodes 1 to 6 are 1, 1, 1, 0, 0, 0.

[0142] See Figure 11 As shown, in the fourth round of consensus, node 4 becomes the master node. Since node 4 is a faulty node, it cannot generate a proposal. Therefore, starting from the moment node 4 receives the consensus request from the client, nodes 1, 2, 3, 5, and 6 will start a timer while waiting for node 4 to generate a proposal. If they do not receive a proposal generated by node 4 within the set time, then nodes 1, 2, 3, 5, and 6 will generate a vote for the empty proposal and reach a consensus on the empty proposal.

[0143] Since nodes 1, 2, 3, 5, and 6 did not receive any proposals, their respective node proposal maps will not increment the value of the key 'node 4'. After consensus is reached on an empty proposal, it is not committed to the blockchain; instead, a new node is selected to continue generating proposals. Therefore, after node 4 did not generate a proposal and other nodes reached consensus by voting on an empty proposal at timeout, node 4's value remained unchanged. The value of each node ID in the node proposal map is as follows: the number of proposals generated for nodes 1 through 6 are 1, 1, 1, 0, 0, and 0, respectively.

[0144] As consensus continues to advance, the values ​​of nodes 1, 2, 3, 5, and 6 will continue to increase. However, node 4 is a faulty node, so its value will not increase or will increase more slowly due to network or machine performance issues. When the total value of all nodes reaches 1000, node 4's value has not reached 1 / 10 of the average value of 166, i.e., 16. Let's assume that the values ​​of each node ID in the current node proposal map are as follows: 200, 200, 200, 20, 200, 180.

[0145] See Figure 12A As shown, when a target proposal is obtained and the sum of the values ​​of each node ID in the locally recorded node proposal map reaches 1000 (i.e., the total number of proposals generated reaches 1000), each node selects consensus nodes from the consensus nodes whose corresponding proposal generation count is less than 16 as abnormal nodes. The abnormal node is node 4. Then, each node generates a prevote vote, which carries nodeID4, and broadcasts its own prevote vote to other nodes, as well as receiving prevote votes from other nodes. When each node receives at least 2 × 6 / 3 + 1 = 5 prevote votes carrying the same node ID, it generates a precommit vote, which carries nodeID4, and broadcasts its own precommit vote to other nodes, as well as receiving precommit votes from other nodes. When each node receives at least 2 × 6 / 3 + 1 = 5 precommit votes carrying the same node ID, it confirms that consensus has been reached on the proposal and removes node 4 from the consensus nodes. It should be noted that, in this embodiment of the application, since node 4 cannot receive or send votes, therefore, Figure 12A The process of each node sending a vote to node 4 is not shown in the document.

[0146] For further details, please refer to [link / reference]. Figure 12BAs shown, for each node's locally recorded node proposal map, the node identifier of node 4 and its corresponding value are deleted from the node proposal map. The number of proposals generated for each of nodes 1, 2, 3, 5, and 6 recorded in the node proposal map is reset to 0. Since the sum of the number of proposals generated for each consensus node is the total number of proposals generated, the total number of proposals generated is also reset to 0.

[0147] Using the above implementation, if a node becomes a faulty node, its value will not increase after several consensus events. Other nodes, being normal nodes, will generate proposals, causing their values ​​to increase. After 1000 proposals, the faulty node's value will be very low. If it falls below 1 / 10 of the average, it can be considered a faulty node, and it will be voted out of the consensus process, ensuring that only normal nodes participate in the consensus, thus restoring the blockchain's performance to normal.

[0148] Based on the same inventive concept, embodiments of this application provide a node consensus device. For example... Figure 13 As shown, this is a structural schematic diagram of the node consensus device 1300, which may include:

[0149] The filtering unit 1301 is used to filter out abnormal nodes that meet the set abnormal node conditions from the consensus nodes based on the number of proposals generated by each consensus node in the distributed system, when a target proposal is obtained and the total number of proposals generated locally reaches the total number threshold.

[0150] The pre-voting unit 1302 is used to send a first vote of the pre-voting stage to each of the other nodes in the consensus nodes. The first vote carries the node identifier of the abnormal node and receives the first vote of the pre-voting stage sent by each of the other nodes.

[0151] The pre-submission unit 1303 is configured to send a second vote in the pre-submission stage to each of the other nodes when the number of first votes carrying the node identifier of the abnormal node reaches a first vote threshold, wherein the second vote carries the node identifier, and to receive the second vote in the pre-submission stage sent by each of the other nodes.

[0152] The node adjustment unit 1304 is used to determine that a consensus has been reached on the target proposal when the number of second votes carrying the node identifier of the abnormal node in the received second votes reaches a second vote threshold, and to delete the abnormal node from each consensus node.

[0153] As one possible implementation, before filtering out abnormal nodes that meet the set abnormal node conditions from the consensus nodes based on the proposal generation counts corresponding to each consensus node in the distributed system, when the target proposal is obtained and the total number of proposal generation counts recorded locally reaches the total number threshold, the filtering unit 1301 is further configured to:

[0154] In each round of consensus, if all consensus nodes reach a consensus on a non-empty proposal generated by the master node, the number of proposals generated by the master node is accumulated, and the total number of proposals generated is updated; wherein, the master node is one of the consensus nodes.

[0155] As one possible implementation, node proposal mapping information is recorded locally, which includes: the node identifier of each consensus node and the number of times the corresponding proposal is generated;

[0156] The filtering unit 1301 is used to determine the total number of proposals generated in the local record in the following way:

[0157] From the node proposal mapping information, obtain the number of proposals generated for each consensus node; based on the obtained number of proposals generated, determine the total number of proposals generated.

[0158] As one possible implementation, when filtering out abnormal nodes that meet the set abnormal node conditions from among the consensus nodes based on the number of proposals generated by each consensus node in the locally recorded distributed system, the filtering unit 1301 is specifically used for:

[0159] From the consensus nodes, at least one consensus node whose number of proposal generation is lower than the proposal generation threshold is selected; the proposal generation threshold is determined based on the number of proposals generated by each consensus node.

[0160] One of the at least one consensus nodes is designated as an abnormal node that meets the set abnormal node conditions.

[0161] As one possible implementation, when selecting one of the at least one consensus nodes as an abnormal node that meets the set abnormal node conditions, the filtering unit 1301 is specifically used for:

[0162] If the number of at least one consensus node is one, then the selected consensus node is directly regarded as an abnormal node that meets the set abnormal node conditions.

[0163] If there are multiple consensus nodes, then based on the number of proposals generated by each of the at least one consensus node, one consensus node is determined from the selected multiple consensus nodes, and this one consensus node is regarded as an abnormal node that meets the set abnormal node conditions.

[0164] As one possible implementation, after removing the abnormal nodes from the consensus nodes, the filtering unit 1301 is further configured to:

[0165] Reset the number of proposals generated by each consensus node in the distributed system, which is recorded locally.

[0166] Reset the total number of proposals generated in the local record.

[0167] As one possible implementation, the filtering unit 1301 is also used for:

[0168] If the consensus node is the master node, then after receiving the consensus request for the target transaction information from the client, the target proposal is generated for the target transaction information.

[0169] If the consensus node is a slave node, then the target proposal is obtained through the master node.

[0170] As one possible implementation, when obtaining the target proposal through the master node, the filtering unit 1301 is specifically used for:

[0171] If a proposal is received from the master node within a set time period after the master node receives a consensus request from the client, then the proposal will be taken as the target proposal.

[0172] If no proposal is received from the master node within a set time period after the consensus request from the client is received, then an empty proposal will be used as the target proposal.

[0173] For ease of description, the above sections are divided into modules (or units) according to their functions and described separately. Of course, in implementing this application, the functions of each module (or unit) can be implemented in one or more software or hardware components.

[0174] Regarding the apparatus in the above embodiments, the specific manner in which each unit executes the request has been described in detail in the embodiments related to the method, and will not be elaborated here.

[0175] Those skilled in the art will understand that various aspects of this application can be implemented as a system, method, or program product. Therefore, various aspects of this application can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, collectively referred to herein as a "circuit," "module," or "system."

[0176] Based on the same inventive concept, embodiments of this application also provide an electronic device. In one embodiment, the electronic device can be a server or a terminal device. See also... Figure 14 As shown, it is a schematic diagram of the structure of a possible electronic device provided in an embodiment of this application. Figure 14 In the electronic device 1400, there are: processor 1410 and memory 1420.

[0177] The memory 1420 stores a computer program that can be executed by the processor 1410. The processor 1410 can execute the steps of the above-mentioned node consensus method by executing the instructions stored in the memory 1420.

[0178] Memory 1420 may be volatile memory, such as random-access memory (RAM); memory 1420 may also be non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); or memory 1420 may be any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory 1420 may also be a combination of the above-described memories.

[0179] Processor 1410 may include one or more central processing units (CPUs) or digital processing units, etc. Processor 1410 implements the above-described node consensus method when executing computer programs stored in memory 1420.

[0180] In some embodiments, the processor 1410 and the memory 1420 may be implemented on the same chip, while in other embodiments they may be implemented on separate chips.

[0181] This application embodiment does not limit the specific connection medium between the processor 1410 and the memory 1420. This application embodiment takes the connection between the processor 1410 and the memory 1420 via a bus as an example. Figure 14 The diagram uses thick lines to describe the connections between other components; these are merely illustrative and not intended to be limiting. Buses can be categorized as address buses, data buses, control buses, etc. For ease of description, Figure 14 It is described using only a thick line, but does not indicate that there is only one bus or one type of bus.

[0182] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium including a computer program. When the computer program is run on an electronic device, it causes the electronic device to perform the steps of the aforementioned node consensus method. In some possible implementations, various aspects of the node consensus method provided in this application can also be implemented as a program product including a computer program. When the program product is run on an electronic device, the computer program causes the electronic device to perform the steps in the aforementioned node consensus method. For example, the electronic device can perform actions such as... Figure 3 The steps are shown in the figure.

[0183] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, RAM, ROM, erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0184] The program product of the embodiments of this application may be a CD-ROM and include a computer program, and may run on an electronic device. However, the program product of this application is not limited thereto. In this document, the readable storage medium may be any tangible medium that contains or stores a computer program that may be used by or in conjunction with a command execution system, apparatus, or device.

[0185] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a readable computer program. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a computer program for use by or in conjunction with a command execution system, apparatus, or device.

[0186] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0187] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A node consensus method, characterized in that, Applied to consensus nodes, the method includes: When a target proposal is obtained and the total number of proposals generated locally reaches the total number threshold, based on the number of proposals generated by each consensus node in the distributed system, abnormal nodes that meet the set abnormal node conditions are selected from the consensus nodes. Send a first vote of the pre-voting phase to each of the other nodes in the consensus nodes. The first vote carries the node identifier of the abnormal node and receives the first vote of the pre-voting phase sent by each of the other nodes. When the number of first votes carrying the node identifier of the abnormal node reaches a first vote threshold among the received first votes, a second vote for the pre-submission stage is sent to each of the other nodes, the second vote carrying the node identifier, and the second vote for the pre-submission stage sent by each of the other nodes is received. When the number of second votes carrying the node identifier of the abnormal node reaches the second vote threshold among the received second votes, it is determined that a consensus has been reached on the target proposal, and the abnormal node is removed from each consensus node.

2. The method as described in claim 1, characterized in that, Before selecting abnormal nodes that meet the set abnormal node conditions from among the consensus nodes based on the proposal generation counts corresponding to each consensus node in the distributed system, when the target proposal is obtained and the total number of proposal generation counts recorded locally reaches the total number threshold, the process further includes: In each round of consensus, if all consensus nodes reach a consensus on a non-empty proposal generated by the master node, the number of proposals generated by the master node is accumulated, and the total number of proposals generated is updated; wherein, the master node is one of the consensus nodes.

3. The method as described in claim 2, characterized in that, The local records contain node proposal mapping information, which includes: the node identifier of each consensus node and the number of times its proposals have been generated. The total number of proposals generated locally is determined in the following way: From the node proposal mapping information, obtain the number of proposals generated for each consensus node; based on the obtained number of proposals generated, determine the total number of proposals generated.

4. The method as described in claim 1, 2, or 3, characterized in that, The number of proposals generated by each consensus node in the locally recorded distributed system is used to filter out abnormal nodes that meet the set abnormal node conditions, including: From the consensus nodes, at least one consensus node whose number of proposal generation is lower than the proposal generation threshold is selected; the proposal generation threshold is determined based on the number of proposals generated by each consensus node. One of the at least one consensus nodes is designated as an abnormal node that meets the set abnormal node conditions.

5. The method as described in claim 4, characterized in that, The step of designating one of the at least one consensus nodes as an abnormal node that meets the set abnormal node conditions includes: If the number of at least one consensus node is one, then the selected consensus node is directly regarded as an abnormal node that meets the set abnormal node conditions. If there are multiple consensus nodes, then based on the number of proposals generated by each of the at least one consensus node, one consensus node is determined from the selected multiple consensus nodes, and this one consensus node is regarded as an abnormal node that meets the set abnormal node conditions.

6. The method as described in claim 1, 2, or 3, characterized in that, After removing the abnormal node from each consensus node, the process also includes: Reset the number of proposals generated by each consensus node in the distributed system, which is recorded locally. Reset the total number of proposals generated in the local record.

7. The method as described in claim 1, 2, or 3, characterized in that, The target proposal was obtained through the following methods: If the consensus node is the master node, then after receiving the consensus request for the target transaction information from the client, the target proposal is generated for the target transaction information. If the consensus node is a slave node, then the target proposal is obtained through the master node.

8. The method as described in claim 7, characterized in that, The step of obtaining the target proposal through the master node includes: If a proposal is received from the master node within a set time period after the master node receives a consensus request from the client, then the proposal will be taken as the target proposal. If no proposal is received from the master node within a set time period after the consensus request from the client is received, then an empty proposal will be used as the target proposal.

9. A node consensus device, characterized in that, include: The filtering unit is used to filter out abnormal nodes that meet the set abnormal node conditions from the consensus nodes when the target proposal is obtained and the total number of proposals generated locally reaches the total number threshold. This is based on the number of proposals generated by each consensus node in the distributed system, which is recorded locally. The pre-voting unit is used to send a first vote of the pre-voting stage to each of the other nodes in the consensus nodes. The first vote carries the node identifier of the abnormal node and receives the first vote of the pre-voting stage sent by each of the other nodes. The pre-submission unit is configured to send a second pre-submission phase vote to each of the other nodes when the number of first votes carrying the node identifier of the abnormal node reaches a first vote threshold, wherein the second vote carries the node identifier, and to receive the second pre-submission phase vote sent by each of the other nodes. The node adjustment unit is used to determine that a consensus has been reached on the target proposal when the number of second votes carrying the node identifier of the abnormal node in each of the received second votes reaches a second vote threshold, and to delete the abnormal node from each consensus node.

10. An electronic device, characterized in that, It includes a processor and a memory, wherein the memory stores a computer program that, when executed by the processor, causes the processor to perform the steps of any one of the methods described in claims 1 to 8.

11. A computer-readable storage medium, characterized in that, It includes a computer program that, when run on an electronic device, causes the electronic device to perform the steps of any of the methods described in claims 1 to 8.

12. A computer program product, characterized in that, It includes a computer program stored in a computer-readable storage medium, and a processor of an electronic device reads from and executes the computer program, causing the electronic device to perform the steps of the method of any one of claims 1 to 8.

Images