Consensus processing method and apparatus, computer device and blockchain system

Abstract

The application relates to a consensus processing method and device, computer equipment and a blockchain system. The method comprises the following steps: acquiring a first consensus height of a current slave node and a second consensus height of a current master node; when the second consensus height is smaller than the first consensus height, determining consensus lag information corresponding to the master node based on the first consensus height and the second consensus height; the consensus lag information is used for representing a consensus lag degree of the master node relative to the slave node; determining a target waiting time length obtained by attenuating a preset waiting time length based on the consensus lag information corresponding to the master node; in the case that a voting waiting timing for a current consensus round is started, when the timing time length reaches the target waiting time length and proposal information broadcast by the master node is not received, initiating voting and broadcasting in the blockchain system in a preset mode to trigger the blockchain system to switch to a next consensus round. The method can improve the consensus performance of the blockchain.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a consensus processing method, apparatus, computer equipment, storage medium, computer program product, and blockchain system. Background Technology

[0002] Blockchain systems are widely used computing systems, applied in many fields such as blockchain and the ZooKeeper distributed service framework. Consensus algorithms are the methods used by nodes in a blockchain system to reach agreement on messages. Specifically, in the operation of a blockchain system, nodes reach consensus on messages to be processed from clients; that is, when all or a majority of nodes in the blockchain system confirm the received message, the message is then synchronously stored / processed.

[0003] In related technologies, nodes in a blockchain system complete the consensus process through two roles: master nodes and slave nodes. However, when the master node fails, there is often a problem of low consensus performance. Summary of the Invention

[0004] Therefore, it is necessary to provide a consensus processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve consensus performance, as well as a blockchain system, to address the aforementioned technical problems.

[0005] On one hand, this application provides a consensus processing method. The method includes: obtaining the current first consensus height of the slave node and obtaining the current second consensus height of the master node; when the second consensus height is less than the first consensus height, determining the consensus lag information corresponding to the master node based on the first consensus height and the second consensus height; the consensus lag information is used to characterize the degree of consensus lag of the master node relative to the slave node; based on the consensus lag information corresponding to the master node, determining a target waiting time obtained by attenuating a preset waiting time; when voting waiting timer is enabled for the current consensus round, when the timer reaches the target waiting time and no proposal information broadcast by the master node is received, initiating a vote according to a preset method and broadcasting it in the blockchain system to trigger the blockchain system to switch to the next consensus round.

[0006] On the other hand, this application also provides a consensus processing apparatus. The apparatus includes: a consensus height acquisition module, used to acquire the current first consensus height of a slave node and the current second consensus height of a master node; a consensus lag information determination module, used to determine consensus lag information corresponding to the master node based on the first consensus height and the second consensus height when the second consensus height is less than the first consensus height; the consensus lag information is used to characterize the degree of consensus lag of the master node relative to the slave node; a waiting time determination module, used to determine a target waiting time obtained by attenuating a preset waiting time based on the consensus lag information corresponding to the master node; and a consensus round switching module, used to, when voting waiting timer is enabled for the current consensus round, initiate a vote according to a preset method and broadcast it in the blockchain system when the timer reaches the target waiting time and no proposal information broadcast by the master node is received, thereby triggering the blockchain system to switch to the next consensus round.

[0007] On the other hand, this application also provides a computer device. The computer device includes a memory and a processor. The memory stores a computer program, and the processor, when executing the computer program, implements the following steps: obtaining the current first consensus height of the slave node and obtaining the current second consensus height of the master node; when the second consensus height is less than the first consensus height, determining consensus lag information corresponding to the master node based on the first consensus height and the second consensus height; the consensus lag information is used to characterize the degree of consensus lag of the master node relative to the slave node; based on the consensus lag information corresponding to the master node, determining a target waiting time obtained by attenuating a preset waiting time; when voting waiting timer is enabled for the current consensus round, when the timer reaches the target waiting time and no proposal information broadcast by the master node is received, initiating a vote according to a preset method and broadcasting it in the blockchain system to trigger the blockchain system to switch to the next consensus round.

[0008] On the other hand, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, performs the following steps: obtaining the current first consensus height of the slave node and obtaining the current second consensus height of the master node; when the second consensus height is less than the first consensus height, determining consensus lag information corresponding to the master node based on the first and second consensus heights; the consensus lag information is used to characterize the degree of consensus lag of the master node relative to the slave node; based on the consensus lag information corresponding to the master node, determining a target waiting time obtained by attenuating a preset waiting time; when voting waiting timer is enabled for the current consensus round, when the timer reaches the target waiting time and no proposal information broadcast by the master node is received, initiating a vote according to a preset method and broadcasting it in the blockchain system to trigger the blockchain system to switch to the next consensus round.

[0009] On the other hand, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, performs the following steps: obtaining the current first consensus height of the slave node and obtaining the current second consensus height of the master node; when the second consensus height is less than the first consensus height, determining consensus lag information corresponding to the master node based on the first and second consensus heights; the consensus lag information is used to characterize the degree of consensus lag of the master node relative to the slave node; based on the consensus lag information corresponding to the master node, determining a target waiting time obtained by attenuating a preset waiting time; when voting waiting timer is enabled for the current consensus round, when the timer reaches the target waiting time and no proposal information broadcast by the master node is received, initiating a vote according to a preset method and broadcasting it in the blockchain system to trigger the blockchain system to switch to the next consensus round.

[0010] On the other hand, this application also provides a blockchain system including multiple nodes; the nodes are configured to: when in the state of a slave node, obtain the current first consensus height and the current second consensus height of the master node; when the second consensus height is less than the first consensus height, determine the consensus lag information corresponding to the master node based on the first consensus height and the second consensus height; the consensus lag information is used to characterize the degree of consensus lag of the master node relative to the slave node; based on the consensus lag information corresponding to the master node, determine a target waiting time obtained by attenuating a preset waiting time; when voting waiting timer is enabled for the current consensus round, when the timer reaches the target waiting time and no proposal information broadcast by the master node is received, initiate a vote according to a preset method and broadcast it in the blockchain system to trigger the blockchain system to switch to the next consensus round.

[0011] The aforementioned consensus processing method, apparatus, computer equipment, storage medium, computer program product, and blockchain system obtain the current first consensus height of the slave node and the current second consensus height of the master node. When the second consensus height is less than the first consensus height, the system determines the consensus lag information corresponding to the master node based on the first and second consensus heights. Based on the consensus lag information corresponding to the master node, the system determines a target waiting time obtained by attenuating a preset waiting time. When voting waiting timer is enabled for the current consensus round, if the timer reaches the target waiting time and no proposal information broadcast by the master node is received, a vote is initiated according to a preset method and broadcast in the blockchain system to trigger the blockchain system to switch to the next consensus round. Since the target waiting time can be dynamically determined based on the consensus lag information corresponding to the master node, and the target waiting time is obtained by attenuating the preset waiting time, the timeout waiting time in the consensus process can be shortened in the event of a master node failure, thereby significantly improving consensus performance. Attached Figure Description

[0012] Figure 1 This is a schematic diagram of an optional structure for a distributed system applied to a blockchain system.

[0013] Figure 2 This is a schematic diagram of the block structure in one embodiment;

[0014] Figure 3 This is a schematic diagram of the consensus process of the Byzantine Fault-Tolerant Consensus Algorithm in one embodiment;

[0015] Figure 4 This is a diagram illustrating the application environment of a consensus processing method in one embodiment.

[0016] Figure 5 This is a flowchart illustrating the consensus processing method in one embodiment;

[0017] Figure 6 This is a schematic diagram illustrating state synchronization between nodes in one embodiment;

[0018] Figure 7 This is a schematic diagram of the consensus process in one embodiment where the master node is a normal node;

[0019] Figure 8 This is a schematic diagram of the consensus process in one embodiment where the master node is a faulty node;

[0020] Figure 9 This is a schematic diagram illustrating the change in target waiting time in one embodiment;

[0021] Figure 10 Here is a block diagram of a blockchain system in one embodiment;

[0022] Figure 11 This is a structural block diagram of the consensus processing device in one embodiment;

[0023] Figure 12 This is an internal structural diagram of a computer device in one embodiment;

[0024] Figure 13 This is a diagram of the internal structure of a computer device in another embodiment. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0026] This invention relates to a blockchain system, which can be a distributed system formed by clients and multiple nodes (any form of computing device connected to the network, such as servers or user terminals) connected through network communication. See also... Figure 1 , Figure 1 This is an optional structural diagram of the distributed system 100 provided in this embodiment of the invention applied to a blockchain system. It consists of multiple nodes 200 (any form of computing device in the network, such as servers or user terminals) and clients 300. The nodes form a peer-to-peer (P2P) network. The P2P protocol is an application layer protocol running on top of the Transmission Control Protocol (TCP). In the distributed system, any machine, such as a server or terminal, can join and become a node. A node includes a hardware layer, a middleware layer, an operating system layer, and an application layer.

[0027] See Figure 1 The functions of each node in the blockchain system shown include:

[0028] 1) Routing: A basic function of nodes used to support communication between nodes.

[0029] In addition to routing capabilities, nodes can also have the following functions:

[0030] 2) Applications are deployed in the blockchain to implement specific business needs. They record data related to the implementation of functions to form record data, carry digital signatures in the record data to indicate the source of the task data, and send the record data to other nodes in the blockchain system. When other nodes successfully verify the source and integrity of the record data, they add the record data to a temporary block.

[0031] For example, the business logic implemented by the application includes:

[0032] 2.1) A wallet is used to provide the function of conducting electronic currency transactions, including initiating transactions (i.e., sending the transaction record of the current transaction to other nodes in the blockchain system; after other nodes successfully verify the transaction, they store the transaction record data in the temporary block of the blockchain as a response to acknowledge the validity of the transaction; of course, the wallet also supports querying the remaining electronic currency in the electronic currency address;

[0033] 2.2) Shared ledger, used to provide functions such as storage, query and modification of ledger data. It sends the record data of the operation on the ledger data to other nodes in the blockchain system. After the other nodes verify the validity, as a response to acknowledge the validity of the ledger data, they store the record data in a temporary block. They can also send confirmation to the node that initiated the operation.

[0034] 2.3) Smart contracts are computerized protocols that can execute the terms of a contract. They are implemented through code deployed on a shared ledger that executes when certain conditions are met. Based on actual business needs, the code is used to complete automated transactions, such as querying the logistics status of goods purchased by a buyer and transferring the buyer's electronic money to the merchant's address after the buyer signs for the goods. Of course, smart contracts are not limited to executing contracts for transactions; they can also execute contracts for processing received information.

[0035] 3) A blockchain consists of a series of blocks that are sequentially generated. Once a new block is added to the blockchain, it will not be removed. The blocks contain the data submitted by the nodes in the blockchain system.

[0036] See Figure 2 , Figure 2This is an optional schematic diagram of the block structure provided in this application embodiment. Each block includes the hash value of the transaction records stored in this block (the hash value of this block) and the hash value of the previous block. The blocks are connected through their hash values ​​to form a blockchain. Additionally, the block may include information such as a timestamp when it was generated. A blockchain is essentially a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains relevant information used to verify the validity of the information (anti-counterfeiting) and to generate the next block.

[0037] In one embodiment, the consensus algorithm in the blockchain system of this application can adopt the Practical Byzantine-Fault Tolerance (PBFT) consensus algorithm. The PBFT consensus algorithm includes four phases: the proposal phase, the prevote phase, the precommit phase, and the commit phase. The following combines... Figure 3 And let's take online transaction scenarios as an example to illustrate:

[0038] During the proposal phase, if network transactions exist in the blockchain system, the master node can package and generate proposal information and broadcast this information to all slave nodes in the blockchain system except for the master node. If no network transactions exist in the blockchain system, the master node will not package and generate proposal information. Figure 3 In the blockchain system, the master node is Node 1, and the slave nodes are Nodes 2-4. Node 1 packages and generates proposal information and broadcasts the proposal information to Nodes 2-4.

[0039] During the pre-voting phase, after the master node in the blockchain system packages and generates proposal information and broadcasts it to all slave nodes in the blockchain system (excluding the master node), any node in the blockchain system (i.e., a slave node) can receive the proposal information, then conduct its first vote on the proposal information, and broadcast that slave node's first vote on the proposal information to all other nodes in the blockchain system (excluding the slave node). For example... Figure 3In the process, node 1 casts its first vote on the proposal information and broadcasts its vote to nodes 1, 2, and 3. Similarly, node 2, upon receiving the proposal information, casts its first vote and broadcasts its vote to nodes 1, 3, and 4. Likewise, node 3, upon receiving the proposal information, casts its first vote and broadcasts its vote to nodes 1, 2, and 4. Finally, node 4, upon receiving the proposal information, casts its first vote and broadcasts its vote to nodes 1, 2, and 3.

[0040] During the pre-voting phase, if the master node in the blockchain system has not packaged and generated proposal information, no slave node in the blockchain system can receive the proposal information. Regardless of whether the master node packages and generates proposal information, the master node will not receive it. Therefore, for any node in the blockchain system that will not receive proposal information (this could be a master node or a slave node), after a preset waiting time, it will conduct its first vote on the empty proposal and broadcast its first vote on the empty proposal to all nodes in the blockchain system except for that node.

[0041] During the pre-submission phase, for any node in the blockchain system (which can be a master node or a slave node), when that node receives a first vote on the proposal information broadcast by at least a first number of nodes in the blockchain system other than itself, that node performs a second vote on the proposal information and broadcasts its second vote on the proposal information to all nodes in the blockchain system other than itself. This application embodiment does not limit the first number; for example, assuming the number of nodes in the blockchain system is X, the first number can be 2X / 3, where X is a positive integer. Figure 3 In the process, when node 1 receives the first vote on the proposal information broadcast by nodes 2-4, it casts a second vote on the proposal information and broadcasts its second vote to nodes 2-4. Similarly, when node 2 receives the first vote on the proposal information broadcast by nodes 1, 3, and 4, it casts a second vote on the proposal information and broadcasts its second vote to nodes 1, 3, and 4. When node 3 receives the first vote on the proposal information broadcast by nodes 1, 2, and 4, it casts a second vote on the proposal information and broadcasts its second vote to nodes 1, 2, and 4. When node 4 receives the first vote on the proposal information broadcast by nodes 1, 2, and 3, it casts a second vote on the proposal information and broadcasts its second vote to nodes 1-3.

[0042] During the pre-submission phase, for any node in the blockchain system (which can be a master node or a slave node), when that node receives the first vote for the empty proposal broadcast by no less than a first number of nodes in the blockchain system other than itself, that node will cast a second vote for the empty proposal and broadcast its second vote for the empty proposal to all nodes in the blockchain system other than itself.

[0043] During the submission phase, for any node in the blockchain system (which can be a master node or a slave node), when that node receives a second vote on the proposal information broadcast by at least a second number of nodes in the blockchain system other than itself, that node determines that the consensus reached is the proposal information. This application embodiment does not limit the second number, which can be the same as or different from the first number. For example, if the number of nodes in the blockchain system is X, then the second number is 2X / 3, where X is a positive integer. Figure 3 In the process, when node 1 receives the second vote on the proposal information broadcast by nodes 2-4, node 1 determines that the consensus reached is for that proposal information. Similarly, when node 2 receives the second vote on the proposal information broadcast by nodes 1, 3, and 4, node 2 determines that the consensus reached is for that proposal information. When node 3 receives the second vote on the proposal information broadcast by nodes 1, 2, and 4, node 3 determines that the consensus reached is for that proposal information. When node 4 receives the second vote on the proposal information broadcast by nodes 1-3, node 4 determines that the consensus reached is for that proposal information.

[0044] During the submission phase, for any node in the blockchain system (which can be a master node or a slave node), when that node receives a second vote for an empty proposal broadcast by no less than a second number of nodes in the blockchain system other than itself, that node determines that the consensus reached is an empty proposal.

[0045] When any node determines that the consensus reached is a proposal, it indicates that that node has reached a consensus on network transactions within the blockchain system, and therefore, the consensus height of that node increases. When any node determines that the consensus reached is an empty proposal, the block height of that node remains unchanged, indicating that that node has not reached a consensus on network transactions within the blockchain system. Regardless of whether the consensus reached is a proposal or an empty proposal, it indicates that that node has completed one consensus process. At this point, the blockchain system re-selects a master node and repeats the above process to enter the next consensus round.

[0046] To ensure stable consensus operation, each node uses a timer during the proposal phase (typically set to a relatively long timeout, such as 30 seconds, to ensure the master node can construct the proposal information on time). If a slave node does not receive the proposal information from the master node within the preset waiting time, an empty proposal will be voted on to ensure consensus continues and moves to the next round as quickly as possible. Therefore, if a node in the blockchain system does not generate proposal information or other nodes do not receive it, a consensus with an empty proposal will be reached according to the consensus process. Then, another node will become the master node. If a node crashes or shuts down for other reasons, when it becomes the master node, other nodes will not receive its generated proposal information because it is already down or shut down. Therefore, other nodes will wait for the preset waiting time and then vote on an empty proposal (i.e., vote on an empty proposal). Then, a normal node will become the master node again, and this normal node will generate proposal information to continue the consensus process. Therefore, if a node crashes or shuts down, when it becomes the master node, it will not generate proposal information to send to other nodes for consensus. As a result, when this faulty node becomes the master node, the entire blockchain system will lack proposal information for consensus. This will cause other nodes to wait for a preset waiting time, and then cast empty votes to achieve empty consensus. Only when a normal node becomes the master node and generates valid proposal information can a consensus with proposal information be achieved.

[0047] Therefore, if there is a faulty node in the blockchain system, it will prevent consensus with proposal information from being reached when it becomes the master node. Assuming there is a faulty node in the blockchain network, the blockchain performance will degrade significantly. This is because when this faulty node is the master node, effective consensus cannot be achieved; it can only wait for a timeout and reach consensus with an empty proposal, then a normal node will be switched to become the master node. However, the next time this faulty node is to become the master node, it will again have to wait for a timeout. Therefore, how to handle the timeout waiting of faulty nodes becomes a problem in order to improve blockchain performance.

[0048] In one embodiment, the consensus processing method provided in this application can be applied to, for example... Figure 4In the application environment shown, terminal 402 communicates with the master node 404 in the blockchain system via the network, and master node 404 communicates with slave nodes 406 in the blockchain system via the network. The master and slave nodes can be any node in the blockchain system, and slave nodes 406 can include one or more, with "more" meaning at least two. Specifically, terminal 402 can send a request to master node 404 to trigger the blockchain system to enter the consensus processing flow. In the consensus processing flow, when a slave node obtains the consensus height of the master node, it compares its own consensus height with the master node's consensus height. If the master node's consensus height is lower than its own, it is determined that the master node may be malfunctioning. At this time, the master node can determine its consensus lag information and dynamically determine the target waiting time based on the consensus lag information to shorten the consensus waiting time and enter the next round of consensus as soon as possible, thereby improving the consensus performance of the blockchain system.

[0049] Terminal 402 can be, but is not limited to, various desktop computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, and smart in-vehicle devices. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted devices. The master node 404 and slave nodes 406 can be implemented using independent servers or a server cluster consisting of multiple servers.

[0050] In one embodiment, such as Figure 5 As shown, a consensus processing method is provided, which can be applied to... Figure 4 Taking node 406 as an example, the explanation includes the following steps:

[0051] Step 502: Obtain the current first consensus height of the slave node and the current second consensus height of the master node.

[0052] In a blockchain system, a master node is a node that can generate proposal information, and a slave node is any node other than the master node. Any node in the blockchain system can act as a master node, and any node can act as a slave node. Consensus height refers to block height, which is used to identify the rounds of consensus reached on proposal information within the blockchain system. Each time multiple nodes in the blockchain system reach consensus on proposal information, the consensus height of each of these nodes increases by 1. If the initial block height of any node in the blockchain system is 0, and its current block height is Y, it indicates that this node has reached consensus Y times on proposal information, where Y is a positive integer. It's important to understand that the proposal information here refers to proposals containing real data, not empty proposals. For example, in a network transaction scenario, each time multiple nodes in the blockchain system reach consensus on a network transaction, the consensus height of each of these nodes increases by 1. It's also important to understand that a single proposal in the blockchain system can only reach consensus once; that is, these Y consensus rounds refer to Y proposals.

[0053] Specifically, in a blockchain system, each node broadcasts its own state to the others and can know the current consensus height of other nodes. Therefore, a slave node can obtain the second consensus height of the master node, while the first consensus height is the consensus height of the slave node itself. A slave node can obtain its own current first consensus height from its local storage.

[0054] Step 504: When the second consensus height is less than the first consensus height, determine the consensus lag information corresponding to the master node based on the first consensus height and the second consensus height; the consensus lag information is used to characterize the degree of consensus lag of the master node relative to the slave node.

[0055] Among them, consensus lag information is used to characterize the degree to which the master node lags behind the slave nodes in consensus. The greater the consensus lag, the more the master node's consensus height lags behind the slave node. The consensus lag information corresponding to the master node is positively correlated with the difference in consensus height between the master node and the slave node.

[0056] Specifically, after a slave node obtains its own first consensus height and the master node's second consensus height, it can compare the first and second consensus heights. If the second consensus height is less than the first consensus height, it means that the master node's current consensus height is lagging behind, and the master node may be a faulty node. Then, the slave node can determine the corresponding consensus lag information of the master node based on the first and second consensus heights.

[0057] In one embodiment, consensus lag information can be obtained based on the difference between the first consensus height and the second consensus height. That is, assuming the first consensus height is Bh and the second consensus height is Ph, the consensus lag information can be obtained based on (Bh - Ph). In this case, the consensus lag information is positively correlated with the degree of consensus lag; that is, the larger the value corresponding to the consensus lag information, the greater the degree of consensus lag. In another embodiment, consensus lag information can be obtained based on the ratio between the first consensus height and the second consensus height. That is, assuming the first consensus height is Bh and the second consensus height is Ph, the consensus lag information can be obtained based on Ph / Bh. In this case, the consensus lag information is negatively correlated with the degree of consensus lag; that is, the larger the value corresponding to the consensus lag information, the smaller the degree of consensus lag.

[0058] In one embodiment, a slave node can also compare its own consensus height with the consensus heights of other slave nodes. If its own consensus height is inconsistent with the consensus heights of other slave nodes, and the consensus heights of most other slave nodes are consistent, then the slave node may not participate in the current round of consensus and may directly obtain unsynchronized blocks from other slave nodes to update its own consensus height.

[0059] In one embodiment, when the current second consensus height of the master node is equal to the current first consensus height of the slave node, it indicates that the master node is a normal node. The slave node determines that the value corresponding to the consensus lag information of the master node is 0, that is, the consensus lag degree of the master node relative to the slave node is 0. At this time, the slave node can conduct normal consensus, that is, wait for the master node to generate proposal information according to the preset waiting time.

[0060] Step 506: Based on the consensus lag information corresponding to the master node, determine the target waiting time obtained by attenuating the preset waiting time.

[0061] The preset waiting time refers to the pre-set time for a slave node to wait for the master node to generate proposal information during a normal consensus process. A normal consensus process means that neither the slave nor the master node is experiencing a failure, and their consensus heights are consistent. Attenuating the preset waiting time means reducing its value based on the preset waiting time; the attenuation method can be determined according to how the consensus lag information is determined. The target waiting time is the dynamically determined time for a slave node to wait for the master node to generate proposal information when the master node's consensus height is lower than the slave node's consensus height. The target waiting time is less than the preset waiting time. The target waiting time is negatively correlated with the degree of consensus lag. This negative correlation means that, all other things being equal, when two variables change in the same direction—one variable decreasing from large to small—the other variable also increasing from small to large. It's important to understand that this negative correlation means the changes are in opposite directions, but it doesn't require that a slight change in one variable necessarily means a change in the other. For example, when variable a is 10 to 20, variable b can be set to 100; when variable a is 20 to 30, variable b can be set to 80. Thus, the direction of change for both a and b is that as a increases, b decreases. However, when a is in the range of 10 to 20, b may remain unchanged.

[0062] Specifically, when a node lags behind other nodes by a significant height, the timeout for other nodes to wait for it to generate proposal information is very short when it becomes the master node. This is because when a node lags too far behind in consensus height, it needs to synchronize blocks from other nodes. Only after synchronizing blocks and reaching the same consensus height as other nodes can it generate proposal information. Therefore, the further behind a node is in consensus height when it becomes the master node, the lower its probability of generating proposal information, and the shorter the time for slave nodes to wait for it to generate proposal information. Based on this, after determining the consensus lag information corresponding to the master node, the slave node can determine the target waiting time based on the consensus lag information, since the consensus lag information can characterize the degree of consensus lag of the master node relative to the slave node. The target waiting time is obtained by attenuating the preset waiting time and is less than the preset waiting time, thus shortening the waiting time.

[0063] Step 508: When the voting waiting timer for the current consensus round is started, if the timer reaches the target waiting time and no proposal information is received from the master node, a vote is initiated in a preset manner and broadcast in the blockchain system to trigger the blockchain system to switch to the next consensus round.

[0064] The current consensus round refers to the consensus process in the current round. In the Byzantine Fault Tolerance consensus algorithm, each consensus round includes a proposal phase, a prevote phase, a precommit phase, and a commit phase. After these four phases are completed, the next consensus round begins.

[0065] Specifically, during the proposal phase, slave nodes can start a voting wait timer for the current consensus round. When the timer reaches the target waiting time and no proposal information is received from the master node, in order to ensure that consensus can continue and enter the next round of consensus as soon as possible, slave nodes can initiate a vote in a preset manner and broadcast it in the blockchain system to trigger the blockchain system to re-select a master node and start the next consensus round.

[0066] In one embodiment, a slave node can initiate a vote on an empty proposal in a preset manner. Thus, in the pre-voting phase, after the slave node receives the first number of votes on the empty proposal from other nodes, it enters the pre-commit phase, where it votes on the empty proposal a second time. Finally, in the commit phase, a consensus is reached on the empty proposal, and then the process switches to the next consensus round.

[0067] In other embodiments, the voting initiated by the node in a preset manner can be a vote on a proposal with preset content. In the blockchain system, the nodes can pre-agree on a proposal with preset content. When the received proposal information is a proposal with preset content, even if a consensus is eventually reached, it will not be written into the blockchain, and the switch to the next consensus round will be triggered directly.

[0068] In the aforementioned consensus processing method, the current first consensus height of the slave node and the current second consensus height of the master node are obtained. When the second consensus height is less than the first consensus height, the consensus lag information corresponding to the master node is determined based on the first and second consensus heights. Based on the consensus lag information corresponding to the master node, a target waiting time obtained by attenuating a preset waiting time is determined. When voting waiting timer is enabled for the current consensus round, when the timer reaches the target waiting time and no proposal information broadcast by the master node is received, voting is initiated according to a preset method and broadcast in the blockchain system to trigger the blockchain system to switch to the next consensus round. Since the target waiting time can be dynamically determined based on the consensus lag information corresponding to the master node, and the target waiting time is obtained by attenuating the preset waiting time, the timeout waiting time in the consensus process can be shortened in the event of a master node failure, thereby significantly improving consensus performance.

[0069] In one embodiment, determining the consensus lag information corresponding to the master node based on the first consensus height and the second consensus height includes: obtaining the difference value between the first consensus height and the second consensus height, and determining the consensus lag information corresponding to the master node based on the difference value; determining the target waiting time obtained by attenuating the preset waiting time based on the consensus lag information corresponding to the master node includes: determining the target waiting time obtained by attenuating the preset waiting time according to the first preset attenuation method based on the consensus lag information corresponding to the master node.

[0070] Specifically, a slave node can subtract the second consensus height from the first consensus height to obtain the difference between the two, and then determine the consensus lag information corresponding to the master node based on the difference. In one specific embodiment, the slave node can directly use the difference as the consensus lag information corresponding to the master node. For example, assuming the first consensus height is Bh and the second consensus height is Ph, the consensus lag information is (Bh-Ph). In other embodiments, the slave node can divide the difference by a preset height difference coefficient to obtain the consensus lag information. For example, assuming the first consensus height is Bh and the second consensus height is Ph, the consensus lag information is (Bh-Ph) / y, where y is a preset height difference coefficient, which can be set as needed.

[0071] Furthermore, based on the consensus lag information corresponding to the master node, the slave node can determine a target waiting time obtained by attenuating the preset waiting time according to a first preset attenuation method. The first preset attenuation method indicates that a first target value is subtracted from the preset waiting time, and the first target value is determined based on the consensus lag information. In one specific embodiment, the slave node can attenuate the preset waiting time according to the first preset attenuation method to obtain the target waiting time during the proposal phase of the consensus process. In other embodiments, each slave node can pre-determine various possible consensus lag information, and then, based on these various possible consensus lag information, attenuate the preset waiting time according to the first preset attenuation method to obtain the corresponding target waiting time and store it. Thus, during the proposal phase of the consensus process, the target waiting time can be directly queried.

[0072] In the above embodiments, the slave node obtains the difference between the first consensus height and the second consensus height, determines the consensus lag information corresponding to the master node based on the difference value, and determines the target waiting time obtained by attenuating the preset waiting time according to the first preset attenuation method based on the consensus lag information corresponding to the master node. The target waiting time can be quickly determined, thereby improving consensus performance and consensus efficiency.

[0073] In one embodiment, based on the consensus lag information corresponding to the master node, determining the target waiting time obtained by attenuating the preset waiting time according to the first preset attenuation method includes: if the value corresponding to the consensus lag information is less than or equal to the preset waiting time, subtracting the value corresponding to the consensus lag information from the preset waiting time to obtain the target waiting time; if the value corresponding to the consensus lag information is greater than the preset waiting time, setting the preset waiting time to a preset value, wherein the preset value is obtained by subtracting a value matching the preset waiting time from the preset waiting time.

[0074] In this embodiment, the consensus lag information is a value obtained based on the difference between the first consensus height and the second consensus height. During the proposal phase of the consensus process, the slave node can reduce the preset waiting time according to the first preset attenuation method to obtain the target waiting time. That is, during the proposal phase, the slave node can subtract the first target value from the preset waiting time to obtain the target waiting time.

[0075] Specifically, when the value corresponding to the lagging consensus information is less than or equal to the preset waiting time, the slave node can subtract the value corresponding to the lagging consensus information from the preset waiting time to obtain the target waiting time. For example, assuming the preset waiting time is T1 and the lagging consensus information is T2, the target waiting time is T1-T2. When the value corresponding to the lagging consensus information is greater than the preset waiting time, subtracting the value from the preset waiting time results in a negative value, which is obviously not realistic. In this case, the computer device can directly set the preset waiting time to a preset value. This preset value is obtained by subtracting a value that matches the preset waiting time from the preset waiting time. For example, the value that matches the preset waiting time can be a value that is the same as the preset waiting time, resulting in a preset value of 0. In this case, the slave node can vote directly according to the preset method and broadcast it in the blockchain without waiting for a timeout, thereby triggering the blockchain to switch to the next consensus round. Of course, in other embodiments, the value that matches the preset waiting time can also be a value that is very close to the preset waiting time. The preset value can be a very small value, so that a certain amount of buffer time can be reserved to ensure the smooth progress of consensus.

[0076] In the above embodiments, when the value corresponding to the consensus lag information is less than or equal to the preset waiting time, the target waiting time is obtained by subtracting the value corresponding to the consensus lag information from the preset waiting time. When the value corresponding to the consensus lag information is greater than the preset waiting time, the preset waiting time is set as the preset value. Since the preset waiting time is obtained in different ways under different circumstances, it avoids obtaining a target waiting time that cannot be timed. While improving consensus efficiency, it can also ensure that the calculated target waiting time is better adapted to the consensus process.

[0077] In one embodiment, the consensus processing method further includes: determining multiple reference consensus lag information; subtracting the value corresponding to each reference consensus lag information from a preset waiting time to obtain a candidate waiting time corresponding to each reference consensus lag information; establishing a correspondence between each reference consensus lag information and its corresponding candidate waiting time; and determining a target waiting time based on the consensus lag information corresponding to the master node by attenuating the preset waiting time according to a first preset attenuation method, including: determining a target reference consensus lag information that matches the consensus lag information corresponding to the master node from the multiple reference consensus lag information, and determining the candidate waiting time corresponding to the target reference consensus lag information as the target waiting time.

[0078] Here, "reference consensus lag information" refers to information used as a reference to determine the target waiting time. Reference consensus lag information can be a numerical range obtained by dividing possible consensus lag information, or a specific value determined based on possible consensus lag information. Specifically, possible consensus lag information can be determined based on the possible difference between the first consensus height and the second consensus height.

[0079] In this embodiment, the slave node can pre-determine possible consensus lag information, and then, based on the possible consensus lag information, reduce the preset waiting time according to a first preset attenuation method to obtain the corresponding target waiting time and store it. Thus, during the proposal phase of the consensus process, the target waiting time can be directly queried. Specifically, after determining multiple reference consensus lag information, the slave node can subtract the value corresponding to each reference consensus lag information from the preset waiting time to obtain the candidate waiting time corresponding to each reference consensus lag information. Specifically, when the value obtained by subtracting a reference consensus lag information from the preset waiting time is greater than or equal to zero, the obtained value is determined as the candidate waiting time corresponding to that reference consensus lag information. When the value obtained by subtracting a reference consensus lag information from the preset waiting time is less than zero, the candidate waiting time corresponding to that reference consensus lag information can be set to a preset value, such as zero.

[0080] Furthermore, slave nodes can establish and store the correspondence between each reference consensus lag and its corresponding candidate waiting time. When determining the target waiting time, the slave node can query this correspondence, identify the reference consensus lag that matches the target lag from among multiple reference consensus lags, and then obtain the candidate waiting time corresponding to the target lag as the target waiting time. For example, assuming the reference consensus lags are specific numerical values, including X1, X2, X3, and X4, after determining the candidate waiting time for each reference consensus lag, a correspondence is established between these reference consensus lags and their corresponding candidate waiting times, assuming it's X1-T1, X2-T2, X3-T3, and X4-T4. Then, when determining the target waiting time, the slave node can match the numerical value corresponding to the master node's consensus lag with each reference consensus lag. Assuming the reference consensus lag with the smallest difference is X1, then T1 is determined as the target waiting time.

[0081] In the above embodiments, by pre-establishing the correspondence between each reference consensus lag information and its corresponding candidate waiting time, the target waiting time can be determined by querying the target reference consensus lag information that matches the consensus lag information, thus avoiding the need to calculate the target waiting time and further improving consensus efficiency.

[0082] In one embodiment, determining multiple reference consensus lag information includes: dividing the numerical distribution range corresponding to the consensus lag information into multiple numerical intervals, and treating each numerical interval as a reference consensus lag information; determining a target reference consensus lag information that matches the consensus lag information corresponding to the master node from the multiple reference consensus lag information, and determining the candidate waiting time corresponding to the target reference consensus lag information as the target waiting time, including: determining the target interval to which the consensus lag information corresponding to the master node belongs from the multiple numerical intervals, and determining the candidate waiting time corresponding to the target interval as the target waiting time.

[0083] Specifically, the slave node can first determine the numerical distribution range corresponding to the consensus lag information, and divide this numerical distribution range into multiple numerical intervals. Each numerical interval is a reference consensus lag information. Under the premise that the consensus lag degree represented by the reference consensus lag information is negatively correlated with the candidate waiting time, the slave node determines the value corresponding to each numerical interval. The value corresponding to each numerical interval is used to represent each numerical interval. For example, the slave node can determine the median value of the numerical interval as the value corresponding to the numerical interval. Further, the slave node subtracts the value corresponding to each numerical interval from the preset waiting time to obtain the candidate waiting time corresponding to each numerical interval. Thus, when determining the target waiting time, the slave node can determine the numerical interval to which the consensus lag information corresponding to the master node belongs from the multiple numerical intervals, and determine the numerical interval to which the consensus lag information corresponding to the master node belongs as the target interval. Finally, the candidate waiting time corresponding to the target interval is determined as the target waiting time.

[0084] For example, assuming the preset waiting time is 30 seconds, and the numerical distribution range corresponding to the consensus lag information is a positive number range greater than zero, this numerical distribution range (in seconds) is divided into four numerical intervals: (0, 10], (10, 20], (20, 30], and greater than 30. The numerical values ​​corresponding to these four numerical intervals are 5, 15, 25, and X (X is any value greater than 30), respectively. Then the candidate waiting times are 25 seconds, 15 seconds, 5 seconds, and 0 seconds, respectively. Assuming the consensus lag information corresponding to the master node is 12, the target waiting time can be determined to be 15 seconds.

[0085] In the above embodiments, by dividing the numerical distribution range corresponding to the consensus lag information into multiple numerical intervals and using each numerical interval as a reference consensus lag information, the target waiting time can be determined by the numerical interval to which the consensus lag information corresponding to the master node belongs, thereby improving consensus efficiency.

[0086] In one embodiment, determining the consensus lag information corresponding to the master node based on the first consensus height and the second consensus height includes: calculating the ratio of the second consensus height to the first consensus height, and determining the consensus lag information corresponding to the master node based on the ratio; determining the target waiting time obtained by attenuating a preset waiting time based on the consensus lag information corresponding to the master node includes: determining the target waiting time obtained by attenuating the preset waiting time according to a second preset attenuation method based on the consensus lag information corresponding to the master node.

[0087] Specifically, a slave node can calculate the ratio of the second consensus height to the first consensus height, and then determine the consensus lag information corresponding to the master node based on the calculated ratio. In one specific embodiment, the slave node can directly use the calculated ratio as the consensus lag information corresponding to the master node. For example, assuming the first consensus height is Bh and the second consensus height is Ph, the consensus lag information is Ph / Bh. In other embodiments, the slave node can divide the calculated ratio by a preset height difference coefficient to obtain the consensus lag information. For example, assuming the first consensus height is Bh and the second consensus height is Ph, the consensus lag information is (Ph / Bh) / y, where y is a preset constant that can be set as needed.

[0088] Furthermore, based on the consensus lag information corresponding to the master node, the slave node can determine a target waiting time obtained by attenuating the preset waiting time according to a second preset attenuation method. The second preset attenuation method indicates that the preset waiting time should be multiplied by a second target value, which is determined based on the consensus lag information. In one specific embodiment, the slave node can attenuate the preset waiting time according to the second preset attenuation method to obtain the target waiting time during the proposal phase of the consensus process. In other embodiments, each slave node can pre-determine various possible consensus lag information, and then, based on these various possible lag information, attenuate the preset waiting time according to the second preset attenuation method to obtain the corresponding target waiting time and store it. Thus, during the proposal phase of the consensus process, the target waiting time can be directly queried.

[0089] In the above embodiments, the slave node calculates the ratio between the first consensus height and the second consensus height, determines the consensus lag information corresponding to the master node based on the calculated ratio, and determines the target waiting time obtained by attenuating the preset waiting time according to the second preset attenuation method based on the consensus lag information corresponding to the master node. The target waiting time can be quickly determined, thereby improving consensus performance and consensus efficiency.

[0090] In one embodiment, based on the consensus lag information corresponding to the master node, determining the target waiting time obtained by attenuating the preset waiting time according to the second preset attenuation method includes: multiplying the preset waiting time by the value corresponding to the consensus lag information to obtain the target waiting time.

[0091] In this embodiment, the consensus lag information is a value obtained based on the ratio between the second consensus height and the first consensus height. During the proposal phase of the consensus process, the slave node can reduce the preset waiting time according to a second preset attenuation method to obtain the target waiting time. That is, during the proposal phase, the slave node can multiply the preset waiting time by the value corresponding to the consensus lag information to obtain the target waiting time. For example, assuming the preset waiting time is T, and the value corresponding to the consensus lag information of the master node is X, the target waiting time is T*X.

[0092] In the above embodiments, the target waiting time can be obtained by multiplying the preset waiting time by the value corresponding to the consensus lag information, thereby quickly determining the target waiting time and improving consensus efficiency.

[0093] In one embodiment, the consensus processing method further includes: determining multiple reference consensus lag information; multiplying a preset waiting time by the value corresponding to each reference consensus lag information to obtain a candidate waiting time corresponding to each reference consensus lag information; establishing a correspondence between each reference consensus lag information and its corresponding candidate waiting time; and determining a target waiting time based on the consensus lag information corresponding to the master node by attenuating the preset waiting time according to a second preset attenuation method, including: determining a target reference consensus lag information that matches the consensus lag information from the multiple reference consensus lag information, and determining the candidate waiting time corresponding to the target reference consensus lag information as the target waiting time.

[0094] Here, "reference consensus lag information" refers to information used as a reference to determine the target waiting time. Reference consensus lag information can be a numerical range obtained by dividing possible consensus lag information, or a specific value determined based on possible consensus lag information. Specifically, possible consensus lag information can be determined based on the calculated possible ratio between the second consensus height and the first consensus height.

[0095] In this embodiment, the slave node can pre-determine possible consensus lag information, and then, based on the possible consensus lag information, reduce the preset waiting time according to the second preset attenuation method to obtain the corresponding target waiting time and store it. Thus, during the proposal phase of the consensus process, the target waiting time can be directly queried. Specifically, after determining multiple reference consensus lag information, the slave node can multiply the preset waiting time by the value corresponding to each reference consensus lag information to obtain the candidate waiting time corresponding to each reference consensus lag information. Further, the slave node can establish and store the correspondence between each reference consensus lag information and its corresponding candidate waiting time. Then, when determining the target waiting time, the slave node can query this correspondence, determine the reference consensus lag information that matches the consensus lag information from the multiple reference consensus lag information, identify it as the target reference consensus lag information, and then obtain the candidate waiting time corresponding to the target reference consensus lag information as the target waiting time.

[0096] In one embodiment, determining multiple reference consensus lag information includes: dividing the numerical distribution range corresponding to the consensus lag information into multiple numerical intervals, and treating each numerical interval as a reference consensus lag information; determining a target reference consensus lag information that matches the consensus lag information corresponding to the master node from the multiple reference consensus lag information, and determining the candidate waiting time corresponding to the target reference consensus lag information as the target waiting time, including: determining the target interval to which the consensus lag information corresponding to the master node belongs from the multiple numerical intervals, and determining the candidate waiting time corresponding to the target interval as the target waiting time.

[0097] Specifically, the slave node can first determine the numerical distribution range corresponding to the consensus lag information, and divide this numerical distribution range into multiple numerical intervals. Each numerical interval is a reference consensus lag information. Under the premise that the consensus lag degree represented by the reference consensus lag information is negatively correlated with the candidate waiting time, the slave node determines the value corresponding to each numerical interval. The value corresponding to each numerical interval is used to represent each numerical interval. For example, the slave node can determine the median value of the numerical interval as the value corresponding to the numerical interval. Further, the slave node multiplies the preset waiting time by the value corresponding to each numerical interval to obtain the candidate waiting time corresponding to each numerical interval. Thus, when determining the target waiting time, the slave node can determine the numerical interval to which the consensus lag information corresponding to the master node belongs from the multiple numerical intervals, and determine the numerical interval to which the consensus lag information corresponding to the master node belongs as the target interval. Finally, the candidate waiting time corresponding to the target interval is determined as the target waiting time.

[0098] In the above embodiments, by pre-establishing the correspondence between each reference consensus lag information and its corresponding candidate waiting time, the target waiting time can be determined by querying the target reference consensus lag information that matches the consensus lag information, thus avoiding the need to calculate the target waiting time and further improving consensus efficiency.

[0099] In one embodiment, the consensus processing method further includes: when the second consensus height is greater than the first consensus height, sending a block acquisition request to the master node; the block acquisition request carries the first consensus height; receiving the difference block returned by the master node based on the first consensus height; verifying the difference block; and after successful verification, writing the difference block into the blockchain stored by the slave node and updating the first consensus height.

[0100] In this context, a difference block refers to a block that exists in the master node's blockchain but not in the slave node's current blockchain. In this embodiment, when the second consensus height is greater than the first consensus height, it indicates that the entire blockchain system has reached a higher consensus level. Therefore, the slave node does not need to wait for proposal information to reach consensus and can directly synchronize the interval. Specifically, the slave node can send a block retrieval request to the master node, carrying its own first consensus height in the request. Upon receiving the request, the master node can determine the difference blocks between itself and the slave node based on the first consensus height and return the difference blocks to the slave node. After receiving the difference blocks, the slave node can verify them and, upon successful verification, write them into its own blockchain to achieve block synchronization. Each time a block is written, the slave node can update its own first consensus height and broadcast the updated height to other nodes in the blockchain system, ensuring that other nodes can promptly obtain the slave node's status.

[0101] It is understood that in other embodiments, a slave node may also obtain differential blocks from any other normal slave node to achieve block synchronization.

[0102] In the above embodiments, when the second consensus height is greater than the first consensus height, the slave node performs block synchronization from the master node and updates its own first consensus height to ensure that the target waiting time can be determined based on the updated first consensus height during the subsequent consensus process.

[0103] In one embodiment, the consensus processing method further includes: when the second consensus height is equal to the first consensus height, setting a preset waiting time as the target waiting time; when the voting waiting timer for the current consensus round is enabled, when the timer reaches the target waiting time and no proposal information broadcast by the master node is received, initiating a vote in a preset manner and broadcasting it in the blockchain system to trigger the blockchain system to switch to the next consensus round.

[0104] Specifically, when the second consensus height equals the first consensus height, it indicates that the master node is in a normal state. The slave node can then set the preset waiting time as the target waiting time and wait for the master node to generate proposal information according to the timeout waiting time in the normal consensus process. Based on this, during the proposal phase, the slave node starts a voting waiting timer for the consensus round. When the timer reaches the preset waiting time and no proposal information is received from the master node, in order to ensure that the consensus can continue and enter the next round of consensus as soon as possible, the slave node can initiate a vote in a preset manner and broadcast it in the blockchain system to trigger the blockchain system to re-select a master node and start the next consensus round.

[0105] In one embodiment, a slave node can initiate a vote on an empty proposal in a preset manner. Thus, in the pre-voting phase, after the slave node receives the first number of votes on the empty proposal from other nodes, it enters the pre-commit phase, where it votes on the empty proposal a second time. Finally, in the commit phase, a consensus is reached on the empty proposal, and then the process switches to the next consensus round.

[0106] In other embodiments, the voting initiated by the node in a preset manner can be a vote on a proposal with preset content. In the blockchain system, the nodes can pre-agree on a proposal with preset content. When the received proposal information is a proposal with preset content, even if a consensus is eventually reached, it will not be written into the blockchain, and the switch to the next consensus round will be triggered directly.

[0107] In the above embodiments, when the second consensus height is equal to the first consensus height, the preset waiting time is determined as the target waiting time, so that the slave node can wait for the master node to generate proposal information according to the timeout waiting time in the consensus process under normal circumstances, thereby ensuring the smooth progress of the consensus process.

[0108] In one embodiment, the master node is determined as follows: the target consensus round and target consensus height in the blockchain are obtained; based on the target consensus round and target consensus height, a reference value for node selection is determined; the node identifiers in the target list are statistically analyzed to obtain statistical values; the statistical values ​​are moduloed based on the node selection reference value to obtain the target value; the target node identifier is determined from the target list based on the target value; and the node corresponding to the target node identifier is determined as the master node.

[0109] In this blockchain system, the node identifiers corresponding to each node are stored in a target list, and each node identifier has its own corresponding index number. The node identifier can be determined from the target list based on its index number. For example, assuming the index number of a node identifier in the target list is 3, then that node identifier can be found by using the index number 3. The target consensus round refers to the number of consensus rounds that have been completed in the blockchain system. The target consensus height refers to the height of the blocks that have reached consensus in the blockchain system.

[0110] After obtaining the target consensus round and target consensus height, a node selection reference value can be calculated based on these values ​​using a preset method. This preset method can be determined as needed; for example, the target consensus round and target consensus height can be multiplied to obtain the node selection reference value. Further, the number of node identifiers in the target list is counted to obtain a statistical value. The target value is then obtained by performing a modulo operation on the statistical value based on the node selection reference value. This process is expressed by the following formula:

[0111] p = f(h,r) Modv

[0112] Where p is the target value, h is the target consensus height, r is the target consensus round, f is a function of h and r (which can be customized), and v is a statistical value. After calculating the target value, the target value can be used as an index to determine the target node identifier from the target list, and the node corresponding to the target node identifier is determined as the master node. For example, assuming the target consensus round is 10, the target consensus height is 8, and the statistical value obtained by counting the node identifiers in the target list is 6, then the target value obtained after modulo operation is 2. Therefore, the node identifier with index number 2 can be determined from the target list as the target node identifier.

[0113] In the above embodiments, by obtaining the target consensus round and target consensus height in the blockchain, and based on the target consensus round and target consensus height, a reference value for node selection is determined. The node identifiers in the target list are statistically analyzed to obtain statistical values. Then, the target node identifier can be determined by modulo operation, thereby determining the randomness and fairness in the selection process of the master node.

[0114] In one specific embodiment, this application also provides an application scenario where the master node's proposal information is generated based on network transaction data, and the aforementioned consensus processing method is used to achieve consensus on the network transaction data received by the master node. As mentioned earlier, related technologies use a timeout mechanism to cause normal nodes to cast empty votes, allowing a new normal node to generate proposal information. This ensures normal consensus when the master node is normal, and a timeout occurs when a faulty node is involved. The specific application of this application's consensus processing method in this scenario is as follows:

[0115] In a blockchain system, nodes can broadcast their own state to each other and store the states of other nodes, thus knowing the current consensus height of other nodes. For example, see [link to example]. Figure 6 Nodes 1, 2, and 3 are normal nodes. Node 4 becomes a faulty node due to a crash or other reasons. Its consensus height before the failure was 10. Therefore, the state of Node 4 stored by Nodes 1, 2, and 3 is at height 10. The consensus state height stored between the three normal nodes is 100.

[0116] Because nodes mutually store consensus heights, during the consensus process, any slave node in the blockchain system can obtain its own first consensus height and the master node's current second consensus height. When the second consensus height is greater than the first consensus height, it indicates that the entire blockchain system has reached a higher level of consensus, and the slave node no longer needs to wait for proposal information to reach consensus; it can directly synchronize blocks from other nodes. When the second consensus height is equal to the first consensus height, it indicates that the master node is currently in a normal state and can wait for a timeout according to the preset waiting time under normal conditions. That is, when the voting waiting timer for the current consensus round is enabled, if the timer reaches the preset waiting time and no proposal information is received from the master node, a vote is initiated according to the preset method and broadcast in the blockchain system to trigger the blockchain system to switch to the next consensus round.

[0117] When the second consensus height of the master node is less than the first consensus height of the slave node, the timeout waiting time in this embodiment is dynamically adjusted. The timeout waiting time for the slave node to wait for the master node to generate proposal information is adjusted from the preset waiting time under normal conditions to the target waiting time (timeout), as shown in the following formula:

[0118] timeout (in seconds / s) = X - ((Bh - Ph) / y)

[0119] Where Bh represents the current second consensus height of the slave node, Ph represents the current first consensus height of the master node, X is a constant representing the preset waiting time, which is the time the slave node waits for the master node to generate proposal information under normal circumstances, and y is a constant representing a height difference coefficient. If the calculated timeout is greater than or equal to 0, the calculated value is used as the target waiting time; if the calculated timeout is less than 0, the timeout is set to 0 seconds.

[0120] As can be seen from the timeout formula above, when a node lags behind other nodes by a significant height, the timeout for other nodes to wait for it to generate proposal information is very short when it becomes the master node. This is because when a node lags behind by too much consensus height, it needs to synchronize blocks from other nodes. Only after synchronizing blocks and reaching the same height as other nodes can it generate proposal information. Therefore, when a node becomes the master node, the further behind it is in consensus height, the lower the probability that it can generate proposal information, and the shorter the time it takes to generate proposal information.

[0121] For example, suppose the nodes of a blockchain system include Figure 6 If nodes 1, 2, 3, and 4 in the network have a preset waiting time of X, then the consensus processing method is as follows:

[0122] 1. A normal node becomes the master node (for ease of description, node 1 will be used as the master node in the following text):

[0123] Because Node 1 is a normal node, it can generate normal proposal information based on network transaction data and then broadcast the proposal information to other nodes. (Reference) Figure 7Nodes 2 and 3 are normal nodes. They compare their current consensus height with the consensus height of Node 1 that they have saved. If their consensus height matches that of Node 1, then the preset waiting time X is the target waiting time. Therefore, the time for Node 2 and Node 3 to wait for Node 1 to generate proposal information is X. During the proposal phase, Nodes 2 and 3 start a voting wait timer for the current consensus round. Within time X, Nodes 2 and 3 can receive the proposal information generated by Node 1. Then, in the pre-voting phase, Node 1 casts its first vote on the proposal information and broadcasts it to Nodes 2 and 3. After receiving the proposal information, Node 2 casts its first vote on the proposal information and broadcasts it to Nodes 1 and 3. After receiving the proposal information, Node 3 casts its first vote on the proposal information and broadcasts it to Nodes 1 and 2. In the pre-commit phase, when Node 1 receives the first vote on the proposal information broadcast by Nodes 2 and 3, it casts its second vote on the proposal information and broadcasts it to Nodes 2 and 3. Upon receiving the first vote on the proposal information broadcast by nodes 1 and 3, node 1 conducts a second vote on the proposal information and broadcasts it to nodes 1 and 3. Similarly, upon receiving the first vote on the proposal information broadcast by nodes 1 and 2, node 3 conducts a second vote on the proposal information and broadcasts it to nodes 1 and 2. During the commit phase, upon receiving the second vote on the proposal information broadcast by nodes 2 and 3, node 1 determines that the consensus reached is the proposal information. Similarly, upon receiving the second vote on the proposal information broadcast by nodes 1 and 3, node 2 determines that the consensus reached is the proposal information. Finally, upon receiving the second vote on the proposal information broadcast by nodes 1 and 2, node 3 determines that the consensus reached is the proposal information.

[0124] 2. The faulty node (i.e., node 4) becomes the master node:

[0125] Since node 4 is a faulty node, it cannot generate proposal information. (See reference...) Figure 8 Normal nodes 1, 2, and 3 will calculate the target waiting time based on the status of node 4 and time out accordingly. If node 4's failure time is long, and it lags behind in consensus height by a significant amount, the timeout for normal nodes will be shorter. For example... Figure 6 The current consensus height of the normal nodes is 100, and the height of the faulty node 4 is 10. Therefore, the target waiting time for nodes 1, 2, and 3 is (X - 90 / y) seconds. After waiting for (X – 90 / y) seconds, nodes 1, 2, and 3 will time out and cast empty votes, ultimately reaching a consensus with an empty proposal. Then, one of the normal nodes (nodes 1, 2, and 3) will become the master node and can generate proposal information normally for consensus.

[0126] 3. The consensus continues to advance; possible scenarios for reaching a consensus include:

[0127] 1) As consensus continues to advance, the consensus heights of nodes 1, 2, and 3 will continue to increase, while node 4, being a faulty node, will not see its consensus height increase. Therefore, when node 4 becomes the master node, the target waiting time for nodes 1, 2, and 3 to wait for node 4 to generate proposal information will become increasingly shorter. Even when node 4 lags behind by a certain consensus height, and then becomes the master node, the target waiting time for nodes 1, 2, and 3 to wait for node 4 to generate proposal information will become 0. At this point, the existence of node 4 as a faulty node essentially has no impact on the consensus performance of the blockchain system.

[0128] 2) Node 4, which had failed, restarted and recovered at some point. After recovery, like all blockchain systems, it began synchronizing blocks from other nodes, and its consensus height gradually caught up with the normal nodes. As it gradually caught up with the normal nodes' consensus height, when it became the master node, nodes 1, 2, and 3 judged that the probability of it generating proposal information increased, thus increasing the timeout waiting time for it to generate proposal information. Once node 4 caught up with the normal nodes, it became the master node and was able to generate proposal information, and the consensus performance was restored.

[0129] As we know from the formula above, the target waiting time for a node to wait for the master node to generate proposal information is a variable value, a sliding value between 0 seconds and X seconds, such as... Figure 9 As shown, when a node's state lags significantly, the target waiting time for other nodes to generate proposal information is very short when it becomes the master node. As it gradually catches up with the network's consensus state, the likelihood of it recovering to become a normal node increases. Therefore, when it becomes the master node, the target waiting time for other nodes to generate proposal information is longer. Finally, when it recovers to become a normal node and can generate proposal information, the blockchain performance returns to normal.

[0130] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0131] Based on the same inventive concept, this application also provides a consensus processing system for implementing the consensus processing method described above. The solution provided by this consensus processing system is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more consensus processing system embodiments provided below can be found in the limitations of the consensus processing method described above, and will not be repeated here.

[0132] In one embodiment, such as Figure 10 As shown, a blockchain system 1000 is provided, which includes multiple nodes, such as... Figure 10 Nodes 1002, 1004, 1006, and 1008 in the blockchain system 1000 are included. It is understood that the blockchain system 1000 may also include other nodes, and this application does not impose any restrictions. Specifically, any node in the blockchain system 1000 is used for:

[0133] When in slave node state, obtain the current first consensus height and the current second consensus height of the master node;

[0134] When the second consensus height is lower than the first consensus height, the consensus lag information corresponding to the master node is determined based on the first and second consensus heights; the consensus lag information is used to characterize the degree of consensus lag of the master node relative to the slave node;

[0135] Based on the consensus lag information corresponding to the master node, the target waiting time is determined by attenuating the preset waiting time.

[0136] When a voting wait timer is started for the current consensus round, if the timer reaches the target waiting time and no proposal information is received from the master node, a vote is initiated according to a preset method and broadcast in the blockchain system to trigger the blockchain system to switch to the next consensus round.

[0137] In the aforementioned blockchain system, when a node is in slave state, it can obtain the current first consensus height of the slave node and the current second consensus height of the master node. When the second consensus height is less than the first consensus height, the consensus lag information corresponding to the master node is determined based on the first and second consensus heights. Based on the consensus lag information corresponding to the master node, a target waiting time obtained by attenuating a preset waiting time is determined. When voting waiting timer is enabled for the current consensus round, if the timer reaches the target waiting time and no proposal information broadcast by the master node is received, a vote is initiated according to a preset method and broadcast in the blockchain system to trigger the blockchain system to switch to the next consensus round. Since the target waiting time can be dynamically determined based on the consensus lag information corresponding to the master node, and the target waiting time is obtained by attenuating the preset waiting time, the timeout waiting time in the consensus process can be shortened in the event of a master node failure, thereby significantly improving consensus performance.

[0138] It is understandable that any node in the aforementioned blockchain system 1000, when in the state of a slave node, can execute the steps in any of the embodiments corresponding to the consensus processing method described above.

[0139] Based on the same inventive concept, this application also provides a consensus processing apparatus for implementing the consensus processing method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more consensus processing apparatus embodiments provided below can be found in the limitations of the consensus processing method described above, and will not be repeated here.

[0140] In one embodiment, such as Figure 11 As shown, a consensus processing device 1100 is provided, comprising:

[0141] The consensus height acquisition module 1102 is used to acquire the current first consensus height of the slave node and the current second consensus height of the master node;

[0142] The consensus lag information determination module 1104 is used to determine the consensus lag information corresponding to the master node based on the first consensus height and the second consensus height when the second consensus height is less than the first consensus height; the consensus lag information is used to characterize the degree of consensus lag of the master node relative to the slave node;

[0143] The waiting time determination module 1106 is used to determine the target waiting time obtained by attenuating the preset waiting time based on the consensus lag information corresponding to the master node.

[0144] The consensus round switching module 1108 is used to initiate a vote and broadcast it in the blockchain system in a preset manner when the voting waiting time for the current consensus round is started and the timer reaches the target waiting time and no proposal information is received from the master node, so as to trigger the blockchain system to switch to the next consensus round.

[0145] The aforementioned consensus processing device obtains the current first consensus height of the slave node and the current second consensus height of the master node. When the second consensus height is less than the first consensus height, it determines the consensus lag information corresponding to the master node based on the first and second consensus heights. Based on the consensus lag information corresponding to the master node, it determines the target waiting time obtained by attenuating a preset waiting time. When voting waiting timer is enabled for the current consensus round, if the timer reaches the target waiting time and no proposal information broadcast by the master node is received, a vote is initiated according to a preset method and broadcast in the blockchain system to trigger the blockchain system to switch to the next consensus round. Since the target waiting time can be dynamically determined based on the consensus lag information corresponding to the master node, and the target waiting time is obtained by attenuating the preset waiting time, the timeout waiting time in the consensus process can be shortened in the event of a master node failure, thereby significantly improving consensus performance.

[0146] In one embodiment, the consensus lag information determination module is further configured to: obtain the difference value between the first consensus height and the second consensus height, and determine the consensus lag information corresponding to the master node based on the difference value; the waiting time determination module is further configured to: determine the target waiting time obtained by attenuating the preset waiting time according to the first preset attenuation method based on the consensus lag information corresponding to the master node; the first preset attenuation method is used to indicate that the preset waiting time is subtracted from the first target value, and the first target value is determined based on the consensus lag information.

[0147] In one embodiment, the waiting time determination module is further configured to: when the value corresponding to the consensus lag information is less than or equal to the preset waiting time, subtract the value corresponding to the consensus lag information from the preset waiting time to obtain the target waiting time; when the value corresponding to the consensus lag information is greater than the preset waiting time, set the preset waiting time to a preset value, wherein the preset value is obtained by subtracting a value matching the preset waiting time from the preset waiting time.

[0148] In one embodiment, the apparatus further includes: a first correspondence establishment module, configured to determine multiple reference consensus lag information; subtract the value corresponding to each reference consensus lag information from a preset waiting time to obtain a candidate waiting time corresponding to each reference consensus lag information; establish a correspondence between each reference consensus lag information and its corresponding candidate waiting time; and a waiting time determination module, further configured to determine a target reference consensus lag information that matches the consensus lag information corresponding to the master node from the multiple reference consensus lag information, and determine the candidate waiting time corresponding to the target reference consensus lag information as the target waiting time.

[0149] In one embodiment, the correspondence establishment module is further configured to divide the numerical distribution range corresponding to the consensus lag information into multiple numerical intervals, and use each numerical interval as a reference consensus lag information; the waiting time determination module is further configured to determine the target interval to which the consensus lag information corresponding to the master node belongs from the multiple numerical intervals, and determine the candidate waiting time corresponding to the target interval as the target waiting time.

[0150] In one embodiment, the consensus lag information determination module is further configured to: calculate the ratio of the second consensus height to the first consensus height, and determine the consensus lag information corresponding to the master node based on the ratio; the waiting time determination module is configured to determine, based on the consensus lag information corresponding to the master node, a target waiting time obtained by attenuating a preset waiting time according to a second preset attenuation method; the second preset attenuation method is used to indicate multiplying the preset waiting time by a second target value, the second target value being determined based on the consensus lag information.

[0151] In one embodiment, the waiting time determination module is further configured to multiply the preset waiting time by the value corresponding to the consensus lag information to obtain the target waiting time.

[0152] In one embodiment, the apparatus further includes: a first correspondence establishment module, which determines multiple reference consensus lag information; multiplies a preset waiting time by the value corresponding to each reference consensus lag information to obtain a candidate waiting time corresponding to each reference consensus lag information; establishes a correspondence between each reference consensus lag information and its corresponding candidate waiting time; and a waiting time determination module, which determines a target reference consensus lag information that matches the consensus lag information from the multiple reference consensus lag information, and determines the candidate waiting time corresponding to the target reference consensus lag information as the target waiting time.

[0153] In one embodiment, the apparatus further includes: a consensus height update module, configured to send a block acquisition request to the master node when the second consensus height is greater than the first consensus height; the block acquisition request carries the first consensus height; receive the difference block returned by the master node according to the first consensus height; verify the difference block; and after verification, write the difference block into the blockchain stored by the slave node and update the first consensus height.

[0154] In one embodiment, the device is further configured to determine a preset waiting time as a target waiting time when the second consensus height is equal to the first consensus height; when the voting waiting timer for the current consensus round is enabled, when the timer reaches the target waiting time and no proposal information broadcast by the master node is received, a vote is initiated in a preset manner and broadcast in the blockchain system to trigger the blockchain system to switch to the next consensus round.

[0155] In one embodiment, the node identifiers corresponding to each node in the blockchain system are stored in a target list; the device further includes: a master node determination module, used to obtain the target consensus round and target consensus height in the blockchain, and determine the node selection reference value based on the target consensus round and target consensus height; to perform statistics on the node identifiers in the target list to obtain statistical values; to perform a modulo operation on the statistical values ​​based on the node selection reference value to obtain the target value; to determine the target node identifier from the target list based on the target value; and to determine the node corresponding to the target node identifier as the master node.

[0156] Each module in the aforementioned consensus processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can invoke and execute the operations corresponding to each module.

[0157] In one embodiment, a computer device is provided, which can be any node in a blockchain system, and its internal structure diagram can be as follows: Figure 12As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores block data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a consensus processing method.

[0158] In one embodiment, a computer device is provided, which can be any node in a blockchain system, and its internal structure diagram can be as follows: Figure 13 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements a consensus processing method. The display unit of the computer device is used to form a visually visible image. It can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0159] Those skilled in the art will understand that Figure 12 and Figure 13The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0160] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the consensus processing method described above.

[0161] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the consensus processing method described above.

[0162] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the consensus processing method described above.

[0163] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions. For example, the consensus rounds and consensus heights involved in this application were obtained under full authorization.

[0164] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0165] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0166] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A consensus processing method applied to slave nodes in a blockchain system, characterized in that, The method includes: Obtain the current first consensus height of the slave node, and obtain the current second consensus height of the master node; When the second consensus height is less than the first consensus height, the difference between the first consensus height and the second consensus height is obtained, and the consensus lag information corresponding to the master node is determined based on the difference value; the consensus lag information is used to characterize the degree of consensus lag of the master node relative to the slave node; Based on the consensus lag information corresponding to the master node, a target waiting time is determined by attenuating the preset waiting time according to a first preset attenuation method; the first preset attenuation method is used to indicate subtracting a first target value from the preset waiting time, and the first target value is determined based on the consensus lag information; When a voting wait timer is started for the current consensus round, if the timer reaches the target waiting time and no proposal information is received from the master node, a vote is initiated according to a preset method and broadcast in the blockchain system to trigger the blockchain system to switch to the next consensus round.

2. The method according to claim 1, characterized in that, The step of determining the target waiting time based on the consensus lag information corresponding to the master node, by attenuating the preset waiting time according to the first preset attenuation method, includes: If the value corresponding to the consensus lag information is less than or equal to the preset waiting time, the target waiting time is obtained by subtracting the value corresponding to the consensus lag information from the preset waiting time. If the value corresponding to the consensus lag information is greater than the preset waiting time, the preset waiting time is set to a preset value, which is obtained by subtracting a value that matches the preset waiting time from the preset waiting time.

3. The method according to claim 1, characterized in that, The method further includes: Identify multiple reference consensus messages that are outdated; Subtract the value corresponding to each reference consensus lag information from the preset waiting time to obtain the candidate waiting time corresponding to each reference consensus lag information. Establish a correspondence between the lagging information of each reference consensus and their respective candidate waiting times; The step of determining the target waiting time based on the consensus lag information corresponding to the master node, by attenuating the preset waiting time according to the first preset attenuation method, includes: From the plurality of reference consensus lag information, a target reference consensus lag information that matches the consensus lag information corresponding to the master node is determined, and the candidate waiting time corresponding to the target reference consensus lag information is determined as the target waiting time.

4. The method according to claim 3, characterized in that, The determination of multiple reference consensus lag information includes: The numerical distribution range corresponding to the consensus lag information is divided into multiple numerical intervals, and each numerical interval is used as a reference consensus lag information. The step of determining the target reference consensus lag information that matches the consensus lag information corresponding to the master node from the plurality of reference consensus lag information, and determining the candidate waiting time corresponding to the target reference consensus lag information as the target waiting time, includes: From the multiple numerical intervals, determine the target interval to which the consensus lag information corresponding to the master node belongs, and determine the candidate waiting time corresponding to the target interval as the target waiting time.

5. The method according to claim 1, characterized in that, The method further includes: When the second consensus height is greater than the first consensus height, a block acquisition request is sent to the master node; the block acquisition request carries the first consensus height. Receive the difference block returned by the master node according to the first consensus height; The difference block is verified. After verification, the difference block is written into the blockchain stored by the slave node, and the first consensus height is updated.

6. The method according to claim 1, characterized in that, The method further includes: When the second consensus height is equal to the first consensus height, the preset waiting time is determined as the target waiting time; When a voting wait timer is started for the current consensus round, if the timer reaches the target waiting time and no proposal information is received from the master node, a vote is initiated according to a preset method and broadcast in the blockchain system to trigger the blockchain system to switch to the next consensus round.

7. The method according to any one of claims 1 to 6, characterized in that, The node identifiers corresponding to each node in the blockchain system are stored in a target list; the master node is determined through the following steps: Obtain the target consensus round and target consensus height in the blockchain, and determine the reference values ​​for node selection based on the target consensus round and target consensus height; The node identifiers of the target list are statistically analyzed to obtain statistical values; Based on the reference value selected by the node, the statistical value is moduloed to obtain the target value. Based on the target value, the target node identifier is determined from the target list, and the node corresponding to the target node identifier is determined as the master node.

8. A consensus processing method applied to slave nodes in a blockchain system, characterized in that, The method includes: Obtain the current first consensus height of the slave node, and obtain the current second consensus height of the master node; When the second consensus height is less than the first consensus height, the ratio of the second consensus height to the first consensus height is calculated, and the consensus lag information corresponding to the master node is determined based on the ratio; the consensus lag information is used to characterize the degree of consensus lag of the master node relative to the slave node; Based on the consensus lag information corresponding to the master node, a target waiting time is determined by attenuating the preset waiting time according to the second preset attenuation method; the second preset attenuation method is used to indicate multiplying the preset waiting time by a second target value, and the second target value is determined based on the consensus lag information; When a voting wait timer is started for the current consensus round, if the timer reaches the target waiting time and no proposal information is received from the master node, a vote is initiated according to a preset method and broadcast in the blockchain system to trigger the blockchain system to switch to the next consensus round.

9. The method according to claim 8, characterized in that, The step of determining the target waiting time based on the consensus lag information corresponding to the master node, by attenuating the preset waiting time according to the second preset attenuation method, includes: Multiply the preset waiting time by the value corresponding to the consensus lag information to obtain the target waiting time.

10. The method according to claim 8, characterized in that, The method further includes: Identify multiple reference consensus messages that are outdated; The preset waiting time is multiplied by the value corresponding to each reference consensus lag information to obtain the candidate waiting time corresponding to each reference consensus lag information. Establish a correspondence between the lagging information of each reference consensus and their respective candidate waiting times; The step of determining the target waiting time based on the consensus lag information corresponding to the master node, by attenuating the preset waiting time according to the second preset attenuation method, includes: From the plurality of reference consensus lag information, a target reference consensus lag information that matches the consensus lag information is determined, and the candidate waiting time corresponding to the target reference consensus lag information is determined as the target waiting time.

11. The method according to claim 8, characterized in that, The method further includes: When the second consensus height is greater than the first consensus height, a block acquisition request is sent to the master node; the block acquisition request carries the first consensus height. Receive the difference block returned by the master node according to the first consensus height; The difference block is verified. After verification, the difference block is written into the blockchain stored by the slave node, and the first consensus height is updated.

12. The method according to claim 8, characterized in that, The method further includes: When the second consensus height is equal to the first consensus height, the preset waiting time is determined as the target waiting time; When a voting wait timer is started for the current consensus round, if the timer reaches the target waiting time and no proposal information is received from the master node, a vote is initiated according to a preset method and broadcast in the blockchain system to trigger the blockchain system to switch to the next consensus round.

13. The method according to any one of claims 8 to 12, characterized in that, The node identifiers corresponding to each node in the blockchain system are stored in a target list; the master node is determined through the following steps: Obtain the target consensus round and target consensus height in the blockchain, and determine the reference values ​​for node selection based on the target consensus round and target consensus height; The node identifiers of the target list are statistically analyzed to obtain statistical values; Based on the reference value selected by the node, the statistical value is moduloed to obtain the target value. Based on the target value, the target node identifier is determined from the target list, and the node corresponding to the target node identifier is determined as the master node.

14. A blockchain system, characterized in that, Includes multiple nodes; the nodes are used for: When in slave node state, obtain the current first consensus height and the current second consensus height of the master node; When the second consensus height is less than the first consensus height, the difference between the first consensus height and the second consensus height is obtained, and the consensus lag information corresponding to the master node is determined based on the difference value; the consensus lag information is used to characterize the degree of consensus lag of the master node relative to the slave node; Based on the consensus lag information corresponding to the master node, a target waiting time is determined by attenuating the preset waiting time according to the first preset attenuation method. The first preset attenuation method is used to indicate that the preset waiting time is subtracted from the first target value, and the first target value is determined based on the consensus lag information; When a voting wait timer is started for the current consensus round, if the timer reaches the target waiting time and no proposal information is received from the master node, a vote is initiated according to a preset method and broadcast in the blockchain system to trigger the blockchain system to switch to the next consensus round.

15. A blockchain system, characterized in that, Includes multiple nodes; the nodes are used for: When in slave node state, obtain the current first consensus height and the current second consensus height of the master node; When the second consensus height is less than the first consensus height, the ratio of the second consensus height to the first consensus height is calculated, and the consensus lag information corresponding to the master node is determined based on the ratio; the consensus lag information is used to characterize the degree of consensus lag of the master node relative to the slave node; Based on the consensus lag information corresponding to the master node, a target waiting time is determined by attenuating the preset waiting time according to the second preset attenuation method. The second preset attenuation method is used to indicate that the preset waiting time is multiplied by a second target value, the second target value being determined based on the consensus lag information; When a voting wait timer is started for the current consensus round, if the timer reaches the target waiting time and no proposal information is received from the master node, a vote is initiated according to a preset method and broadcast in the blockchain system to trigger the blockchain system to switch to the next consensus round.

16. A consensus processing apparatus, characterized in that, The device includes: The consensus height acquisition module is used to obtain the current first consensus height of the slave node and the current second consensus height of the master node; The consensus lag information determination module is used to obtain the difference value between the first consensus height and the second consensus height when the second consensus height is less than the first consensus height, and determine the consensus lag information corresponding to the master node based on the difference value; the consensus lag information is used to characterize the degree of consensus lag of the master node relative to the slave node; The waiting time determination module is used to determine a target waiting time obtained by attenuating a preset waiting time according to a first preset attenuation method based on the consensus lag information corresponding to the master node; the first preset attenuation method is used to indicate that the preset waiting time is subtracted from a first target value, and the first target value is determined based on the consensus lag information; The consensus round switching module is used to initiate a vote and broadcast it in the blockchain system in a preset manner when the voting waiting time for the current consensus round is started and the timer reaches the target waiting time and no proposal information broadcast by the master node is received, so as to trigger the blockchain system to switch to the next consensus round.

17. The apparatus according to claim 16, characterized in that, The waiting time determination module is further configured to subtract the value corresponding to the consensus lag information from the preset waiting time to obtain the target waiting time when the value corresponding to the consensus lag information is less than or equal to the preset waiting time. If the value corresponding to the consensus lag information is greater than the preset waiting time, the preset waiting time is set to a preset value, which is obtained by subtracting a value that matches the preset waiting time from the preset waiting time.

18. The apparatus according to claim 16, characterized in that, The device further includes: The first correspondence establishment module is used to determine multiple reference consensus lag information; subtract the value corresponding to each reference consensus lag information from the preset waiting time to obtain the candidate waiting time corresponding to each reference consensus lag information; and establish the correspondence between each reference consensus lag information and its corresponding candidate waiting time. The waiting time determination module is further configured to determine, from the plurality of reference consensus lag information, a target reference consensus lag information that matches the consensus lag information corresponding to the master node, and determine the candidate waiting time corresponding to the target reference consensus lag information as the target waiting time.

19. The apparatus according to claim 18, characterized in that, The first correspondence establishment module is also used to divide the numerical distribution range corresponding to the consensus lag information into multiple numerical intervals, and use each numerical interval as a reference consensus lag information; The waiting time determination module is further used to determine the target interval to which the consensus lag information corresponding to the master node belongs from the plurality of numerical intervals, and to determine the candidate waiting time corresponding to the target interval as the target waiting time.

20. The apparatus according to claim 16, characterized in that, The device further includes: The consensus height update module is used to send a block acquisition request to the master node when the second consensus height is greater than the first consensus height; the block acquisition request carries the first consensus height; receive the difference block returned by the master node according to the first consensus height; verify the difference block; after verification, write the difference block into the blockchain stored by the slave node and update the first consensus height.

21. The apparatus according to claim 16, characterized in that, The device is used to determine the preset waiting time as the target waiting time when the second consensus height is equal to the first consensus height; when the voting waiting timer for the current consensus round is enabled, when the timer reaches the target waiting time and no proposal information broadcast by the master node is received, a vote is initiated in a preset manner and broadcast in the blockchain system to trigger the blockchain system to switch to the next consensus round.

22. The apparatus according to any one of claims 16 to 21, characterized in that, The node identifiers corresponding to each node in the blockchain system are stored in a target list; the device also includes: The master node determination module is used to obtain the target consensus round and target consensus height in the blockchain, determine the node selection reference value based on the target consensus round and target consensus height, count the node identifiers in the target list to obtain a statistical value, perform a modulo operation on the statistical value based on the node selection reference value to obtain a target value, determine the target node identifier from the target list based on the target value, and determine the node corresponding to the target node identifier as the master node.

23. A consensus processing apparatus, characterized in that, The device includes: The consensus height acquisition module is used to obtain the current first consensus height of the slave node and the current second consensus height of the master node; The consensus lag information determination module is used to calculate the ratio of the second consensus height to the first consensus height when the second consensus height is less than the first consensus height, and determine the consensus lag information corresponding to the master node based on the ratio; the consensus lag information is used to characterize the degree of consensus lag of the master node relative to the slave node; The waiting time determination module is used to determine a target waiting time obtained by attenuating a preset waiting time according to a second preset attenuation method based on the consensus lag information corresponding to the master node; the second preset attenuation method is used to indicate that the preset waiting time is multiplied by a second target value, and the second target value is determined based on the consensus lag information; The consensus round switching module is used to initiate a vote and broadcast it in the blockchain system in a preset manner when the voting waiting time for the current consensus round is started and the timer reaches the target waiting time and no proposal information broadcast by the master node is received, so as to trigger the blockchain system to switch to the next consensus round.

24. The apparatus according to claim 23, characterized in that, The waiting time determination module is further configured to multiply the preset waiting time by the value corresponding to the consensus lag information to obtain the target waiting time.

25. The apparatus according to claim 23, characterized in that, The device further includes: The first correspondence establishment module is used to determine multiple reference consensus lag information; multiply the preset waiting time by the value corresponding to each reference consensus lag information to obtain the candidate waiting time corresponding to each reference consensus lag information; and establish the correspondence between each reference consensus lag information and its corresponding candidate waiting time. The waiting time determination module is further configured to determine a target reference consensus lag information that matches the consensus lag information from the plurality of reference consensus lag information, and determine the candidate waiting time corresponding to the target reference consensus lag information as the target waiting time.

26. The apparatus according to claim 23, characterized in that, The device further includes: The consensus height update module is used to send a block acquisition request to the master node when the second consensus height is greater than the first consensus height; the block acquisition request carries the first consensus height; receive the difference block returned by the master node according to the first consensus height; verify the difference block; after verification, write the difference block into the blockchain stored by the slave node and update the first consensus height.

27. The apparatus according to claim 23, characterized in that, The device is used to determine the preset waiting time as the target waiting time when the second consensus height is equal to the first consensus height; when the voting waiting timer for the current consensus round is enabled, when the timer reaches the target waiting time and no proposal information broadcast by the master node is received, a vote is initiated in a preset manner and broadcast in the blockchain system to trigger the blockchain system to switch to the next consensus round.

28. The apparatus according to any one of claims 23 to 27, characterized in that, The node identifiers corresponding to each node in the blockchain system are stored in a target list; the device also includes: The master node determination module is used to obtain the target consensus round and target consensus height in the blockchain, determine the node selection reference value based on the target consensus round and target consensus height, count the node identifiers in the target list to obtain a statistical value, perform a modulo operation on the statistical value based on the node selection reference value to obtain a target value, determine the target node identifier from the target list based on the target value, and determine the node corresponding to the target node identifier as the master node.

29. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 13.

30. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 13.

31. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 13.

Images