Consensus method and device of blockchain, computer readable medium, electronic device and program product

Abstract

Embodiments of the present application provide a blockchain consensus method, device, computer readable medium and electronic device. The blockchain consensus method comprises: in a consensus process initiated by a proposal node for a to-be-consensed block, receiving a pre-vote message sent by a consensus node in a blockchain network; according to the received pre-vote message, counting the number of first pre-vote messages for the to-be-consensed block, wherein the first pre-vote message is sent by the consensus node after receiving a proposal message of the to-be-consensed block within a set time length, the set time length corresponds to the proposal node and is determined based on a block generation time length of the proposal node; and according to the number of first pre-vote messages, adjusting the set time length recorded by the consensus node corresponding to the proposal node. The technical solution of the embodiments of the present application can shorten the consensus time of the block, which is beneficial to improving the consensus performance of the blockchain.

Description

Technical Field

[0001] This application relates to the fields of computer and communication technology, and more specifically, to a consensus method, apparatus, computer-readable medium, and electronic device for blockchain. Background Technology

[0002] In blockchain technology, the consensus mechanism is fundamental to ensuring the normal operation of the blockchain system. Consensus means reaching an agreement. Each node in a blockchain system stores its own copy of the distributed ledger (i.e., the blockchain itself). The consensus process is the process of ensuring consistency between these distributed ledgers across all nodes. The Byzantine Fault Tolerance (BFT) consensus algorithm is a commonly used algorithm in blockchain technology. Each block requires three stages: proposal, pre-voting, and pre-commit. If the proposing node fails, the validating node must wait a fixed amount of time before entering the pre-voting stage. This results in a lengthy consensus process, impacting the blockchain's consensus performance. Summary of the Invention

[0003] The embodiments of this application provide a consensus method, apparatus, computer-readable medium, and electronic device for blockchain, which can shorten the consensus time of blocks and improve the consensus performance of blockchain.

[0004] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part by practice of this application.

[0005] According to one aspect of the embodiments of this application, a consensus method for a blockchain is provided, comprising: receiving pre-voting messages sent by consensus nodes in the blockchain network during a consensus process initiated by a proposing node for a block to be consensus; counting the number of first pre-voting messages for the block to be consensus based on the received pre-voting messages, wherein the first pre-voting message is sent by the consensus node after receiving a proposal message for the block to be consensus within a set time period, the set time period corresponding to the proposing node and determined based on the block production time of the proposing node; and adjusting the set time period recorded by the consensus node corresponding to the proposing node based on the number of first pre-voting messages.

[0006] According to one aspect of the embodiments of this application, a consensus device for a blockchain is provided, comprising: a receiving unit configured to receive pre-voting messages sent by a consensus node in a blockchain network during a consensus process initiated by a proposing node for a block to be consensus; a counting unit configured to count the number of first pre-voting messages for the block to be consensus based on the received pre-voting messages, wherein the first pre-voting message is sent by the consensus node after receiving a proposal message for the block to be consensus within a set time period, the set time period corresponding to the proposing node and determined based on the block production time of the proposing node; and an adjustment unit configured to adjust the set time period recorded by the consensus node corresponding to the proposing node based on the number of the first pre-voting messages.

[0007] In some embodiments of this application, based on the foregoing scheme, the adjustment unit is configured as follows: if the number of the first pre-voting messages is less than the consensus quantity requirement of the pre-voting stage, and the number of the received second pre-voting messages for empty blocks is less than the consensus quantity requirement, then the set duration recorded by the consensus node that sent the second pre-voting message and corresponding to the proposal node is increased until the set maximum value is reached.

[0008] In some embodiments of this application, based on the foregoing scheme, the adjustment unit is configured as follows: if the number of the first pre-voting messages is less than the consensus quantity requirement of the pre-voting stage, and the number of the second pre-voting messages received for empty blocks is greater than or equal to the consensus quantity requirement, then the set duration recorded by the consensus nodes participating in the consensus process corresponding to the proposal node is increased until the set maximum value is reached.

[0009] In some embodiments of this application, based on the foregoing scheme, the adjustment unit is further configured to: after increasing the set duration recorded by the consensus node corresponding to the proposal node, if the consensus process initiated by the proposal node again meets the consensus requirements in the pre-voting stage, then the set duration recorded by the consensus node participating in the consensus process corresponding to the proposal node is decreased.

[0010] In some embodiments of this application, based on the foregoing scheme, the adjustment unit is configured to: if the number of the first pre-voting messages is greater than or equal to the consensus quantity requirement of the pre-voting stage, then control the set duration recorded by the consensus nodes participating in the consensus process corresponding to the proposal node to remain unchanged, or reduce the set duration recorded by the consensus nodes participating in the consensus process corresponding to the proposal node until the set minimum value is reached.

[0011] In some embodiments of this application, based on the foregoing scheme, the statistics unit is further configured to: count the number of times each consensus node experiences anomalies during the consensus process; the consensus device of the blockchain further includes: a generation unit configured to: if the number of consecutive anomalies of a specified consensus node reaches a set number, generate first transaction information of configuration type, the first transaction information being used to indicate the cancellation of the specified consensus node's participation in the consensus process; generate a first block based on the first transaction information; generate a proposal message for the first block; and broadcast the proposal message of the first block to other consensus nodes in the blockchain network.

[0012] In some embodiments of this application, based on the foregoing scheme, the proposal message of the first block includes type information of the proposal message and identification information of the designated consensus node. The type information of the proposal message is configured to indicate that the proposal message of the first block is used to cancel the participation of the designated consensus node in the consensus process.

[0013] In some embodiments of this application, based on the aforementioned scheme, if the first block reaches consensus in the blockchain network, then it is determined that the designated consensus node will no longer participate in the consensus process of the blockchain network.

[0014] In some embodiments of this application, based on the foregoing scheme, the statistics unit is further configured to: count the number of times each consensus node experiences anomalies during the consensus process; the consensus device of the blockchain further includes: a generation unit configured to: if the number of consecutive anomalies of a specified consensus node reaches a set number, generate second transaction information of a configuration type, the second transaction information being used to instruct the alternative node corresponding to the specified consensus node to participate in the consensus process in place of the specified consensus node; generate a second block based on the second transaction information; generate a proposal message for the second block, and broadcast the proposal message of the second block to other consensus nodes in the blockchain network and the backup node of the specified consensus node.

[0015] In some embodiments of this application, based on the foregoing scheme, the proposal message of the second block includes type information of the proposal message and identification information of the alternative node corresponding to the designated consensus node. The type information of the proposal message is configured to indicate that the proposal message of the second block is used to replace the designated consensus node in the consensus process through the alternative node corresponding to the designated consensus node.

[0016] In some embodiments of this application, based on the aforementioned scheme, if the second block reaches consensus in the blockchain network, it is determined that the designated consensus node will no longer participate in the consensus process of the blockchain network; the consensus device of the blockchain further includes: a sending unit configured to send a pre-commit voting message of the second block to a candidate node corresponding to the designated consensus node, so that after the candidate node of the designated consensus node receives the pre-commit voting message and reaches the consensus quantity requirement of the pre-commit stage, it will replace the designated consensus node in the consensus process.

[0017] In some embodiments of this application, based on the foregoing scheme, the statistics unit is further configured to: after each consensus node initiates a proposal message for the proposal block as a proposal node, count the number of pre-voting messages received for the proposal block; if the number of pre-voting messages received for the proposal block does not meet the consensus quantity requirement of the pre-voting stage, then it is determined that the consensus node that initiated the proposal message for the proposal block is abnormal.

[0018] According to one aspect of the embodiments of this application, a computer-readable medium is provided having a computer program stored thereon, which, when executed by a processor, implements the blockchain consensus method as described in the above embodiments.

[0019] According to one aspect of the embodiments of this application, an electronic device is provided, including: one or more processors; and a storage device for storing one or more computer programs, which, when executed by the one or more processors, cause the electronic device to implement the blockchain consensus method as described in the above embodiments.

[0020] According to one aspect of the embodiments of this application, a computer program product is provided, comprising a computer program stored in a computer-readable storage medium. A processor of an electronic device reads from the computer-readable storage medium and executes the computer program, causing the electronic device to perform the blockchain consensus method provided in the various alternative embodiments described above.

[0021] In some embodiments of this application, the first pre-voting message is sent by the consensus node after receiving the proposal message of the block to be consensus within a set time period. Since the set time period corresponds to the proposal node and is determined based on the block production time of the proposal node, a shorter set time period can be set according to the block production time of the proposal node. This avoids the consensus node waiting for a long time before entering the pre-voting stage, thus shortening the consensus process time. Furthermore, by adjusting the set time period recorded by the consensus node corresponding to the proposal node based on the number of first pre-voting messages, when the number of first pre-voting messages does not meet the consensus quantity requirement for the pre-voting stage, the set time period can be appropriately increased to ensure that the proposal node has sufficient time to produce blocks and construct proposal messages. Conversely, when the number of first pre-voting messages meets the consensus quantity requirement for the pre-voting stage and the set time period is relatively large, the set time period can be further reduced, thereby shortening the block consensus time and improving the consensus performance of the blockchain.

[0022] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0023] Figure 1 A schematic diagram of a blockchain network structure is shown.

[0024] Figure 2 This diagram illustrates the connection relationships between blocks in a blockchain.

[0025] Figure 3 A flowchart of a consensus algorithm is shown;

[0026] Figure 4 A schematic diagram of a consensus node broadcasting a block according to an embodiment of this application is shown;

[0027] Figure 5 A schematic diagram illustrating the processing steps of each consensus stage of a consensus algorithm is shown.

[0028] Figure 6 A flowchart of a consensus algorithm is shown;

[0029] Figure 7 A flowchart illustrating a blockchain consensus method according to an embodiment of this application is shown;

[0030] Figure 8 A flowchart illustrating a blockchain consensus method according to an embodiment of this application is shown;

[0031] Figure 9 A flowchart illustrating a blockchain consensus method according to an embodiment of this application is shown;

[0032] Figure 10 A flowchart illustrating a consensus algorithm according to an embodiment of this application is shown;

[0033] Figure 11 A flowchart illustrating a consensus algorithm according to an embodiment of this application is shown;

[0034] Figure 12 A flowchart illustrating a consensus algorithm according to an embodiment of this application is shown;

[0035] Figure 13 A flowchart illustrating a consensus algorithm according to an embodiment of this application is shown;

[0036] Figure 14 A flowchart illustrating a consensus algorithm according to an embodiment of this application is shown;

[0037] Figure 15 A flowchart illustrating a consensus algorithm according to an embodiment of this application is shown;

[0038] Figure 16 A block diagram of a blockchain consensus apparatus according to an embodiment of this application is shown;

[0039] Figure 17 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0040] Exemplary embodiments will now be described in a more comprehensive manner with reference to the accompanying drawings. However, the exemplary embodiments can be implemented in various forms and should not be construed as limited to these examples; rather, these embodiments are provided so that this application will be more comprehensive and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art.

[0041] Furthermore, the features, structures, or characteristics described in this application can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to provide a full understanding of the embodiments of this application. However, those skilled in the art will recognize that when implementing the technical solutions of this application, not all detailed features in the embodiments may be used, one or more specific details may be omitted, or other methods, elements, devices, steps, etc., may be employed.

[0042] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0043] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0044] It should be noted that "multiple" in this article refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0045] The technical solutions in this application relate to blockchain technology. Specifically, blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks (i.e., blocks) linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include a blockchain underlying platform, a platform product service layer, and an application service layer.

[0046] A blockchain underlying platform can include processing modules such as user management, basic services, smart contracts, and operations management. The user management module is responsible for managing the identity information of all blockchain participants, including maintaining public and private key generation (account management), key management, and maintaining the correspondence between user information and blockchain addresses (access management). The basic service module is deployed on all blockchain node devices to verify the validity of business requests. After consensus is reached on valid requests, the module records them in storage. For a new business request, the basic service first performs interface adaptation parsing and authentication (interface adaptation), then encrypts the business information through a consensus algorithm (consensus management), and transmits it completely and consistently to the shared ledger (network communication) for recording and storage. The smart contract module is responsible for contract registration, issuance, triggering, and execution. Developers can define contract logic using a programming language and publish it to the blockchain (contract registration). According to the contract terms, the module calls keys or other events to trigger execution and complete the contract logic. It also provides functions for contract upgrades and cancellations. The operations management module is mainly responsible for deployment, configuration modification, contract settings, cloud adaptation, and real-time status visualization during product launch, such as alarms, network status monitoring, and node device health status monitoring.

[0047] The platform's product service layer provides the basic capabilities and implementation frameworks for typical applications. Developers can leverage these basic capabilities, along with the specific characteristics of their business needs, to implement blockchain-based business logic. The application service layer provides blockchain-based application services to business stakeholders.

[0048] As mentioned above, a blockchain is essentially a decentralized database, and it is maintained collaboratively by nodes within a blockchain network. For example, in... Figure 1 The illustrated blockchain network may include multiple nodes 101, which can be various clients forming the blockchain network. Each node 101, in its normal operation, receives input information and maintains shared data within the blockchain network based on this information. To ensure interoperability within the blockchain network, information connections can exist between each node, allowing for information transmission. For example, when any node in the blockchain network receives input information, other nodes in the network obtain this input information according to a consensus algorithm and store it as shared data, ensuring data consistency across all nodes in the blockchain network.

[0049] Each node in a blockchain network has a corresponding node identifier, and each node can store the node identifiers of other nodes. This allows for the broadcast of generated blocks to other nodes in the blockchain network based on their node identifiers. Each node can maintain a list of node identifiers, storing the node name and its corresponding node identifier in this list. The node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node.

[0050] Each node in a blockchain network stores the same blockchain. A blockchain consists of multiple blocks; see [link to blockchain documentation]. Figure 2 As shown, a blockchain consists of multiple blocks linked together in ascending order of creation timestamps. Each block includes a block header and a block body. The block header stores the hash of the preceding block and the Merkle root of the current block. The block body contains the complete transaction data of the block, organized in the form of a Merkle tree. The blockchain structure demonstrates that the data stored in each block is related to the data stored in its parent block (i.e., the preceding block), ensuring the security of input information within the blocks.

[0051] In a blockchain network, each node can be a server or a terminal device. A server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. Terminal devices can be smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, smart home devices, in-vehicle terminals, aircraft, etc., but are not limited to these. Nodes can be directly or indirectly connected via wired or wireless communication, and this application does not impose any restrictions on this.

[0052] It's important to note that Merkle trees are a crucial component of blockchain technology. Blockchain doesn't directly store plaintext data; the raw data needs to be hashed and stored as hash values. Merkle trees are used to organize the hash values ​​generated from hashing multiple raw data points into a binary tree structure and store them within the block body.

[0053] Another crucial technology in blockchain is the consensus mechanism, which is fundamental to ensuring the normal operation of a blockchain system. Consensus means reaching an agreement. Each node in a blockchain system stores its own copy of the distributed ledger (i.e., the blockchain itself). The consensus process is the process of ensuring consistency between these distributed ledgers across all nodes. Some or all nodes in a blockchain system can participate in the consensus process. This process is typically based on a consensus algorithm, with participating nodes executing the corresponding steps of the consensus process by running the algorithm. PoW (Proof of Work), PoS (Proof of Stake), DPoS (Delegated Proof of Stake), BFT (Byzantine Fault Tolerance), PBFT (Practical Byzantine Fault Tolerance), and TBFT (Tendermint BFT) are among the options available.

[0054] Typically, at a certain block height in a blockchain, one or more rounds of consensus processes are required to reach agreement among the participating node devices. These participating nodes are called consensus nodes, and they ensure data consistency across the entire blockchain system through a specific consensus algorithm. The consensus nodes in a blockchain include proposal nodes and verification nodes. Proposal nodes are responsible for proposing blocks, while verification nodes verify the proposed blocks according to the corresponding consensus algorithm to ensure their correctness and validity.

[0055] Block height is used to represent the number of blocks connected to the blockchain. Block height is a marker of a block and can be used to indicate the position of a block in the blockchain. For example, the block height of the genesis block in the blockchain is 0 by default, the block height of the first block after the genesis block is 1 (this first block can be simply referred to as block 1), the block height of the second block after the genesis block is 2 (this second block can be simply referred to as block 2), and so on.

[0056] For example, if the current block height of a blockchain is 300 (referred to as block 300), this means that 300 blocks have been stacked on top of the genesis block, resulting in 301 blocks on the blockchain from the genesis block to block 300. The consensus process at a specific block height refers to the process of reaching consensus on the blocks to be added to the blockchain when the blockchain is at that height. If the consensus is successful, the block is added to the blockchain, and the block height is incremented by 1. For instance, the consensus process at block height 10 refers to the process of reaching consensus on the blocks to be added to the blockchain when the blockchain is at block height 10. If the consensus is successful, the block is added to the blockchain, increasing the block height from 10 to 11.

[0057] Generally speaking, such as Figure 3 As shown, a consensus process can be divided into three phases in sequence: the proposal phase, the prevote phase, and the precommit phase. The participating nodes in the same consensus process include two types: proposal nodes and non-proposal nodes. A proposal node is an node elected by the participating nodes. This node is responsible for both generating the block to be agreed upon in the proposal phase and broadcasting it to the other participating nodes for consensus processing; it is also responsible for processing the block itself. Non-proposal nodes, on the other hand, only process the blocks to be agreed upon.

[0058] Consensus processing includes pre-voting and pre-committing. Pre-voting occurs during the pre-voting phase, while pre-committing occurs during the pre-committing phase. Pre-voting refers to the process of agreeing to pre-vote on a block to be agreed upon. If a block is pre-voted, it means the user agrees to add that block to the blockchain. Pre-committing refers to the process of agreeing to pre-commit a block to be agreed upon. If a block is pre-committed, it means the user confirms their agreement to add that block to the blockchain. In multiple rounds of consensus at the same block height, the participating node devices may change in different rounds. Specifically, the node devices participating in each round may change, the proposing nodes may change, and the blocks awaiting consensus may also change.

[0059] The following example illustrates the specific process of the Ni-th consensus round at block height H of the blockchain in this application embodiment, where H, N, and i are all positive integers, and i is less than N. Taking i=1 as an example, in the (N-1)-th consensus round at block height H of the blockchain, a total of 4 node devices participate in the consensus process. Figure 4 This illustration shows a block broadcasting diagram of a consensus node according to an embodiment of this application; as shown Figure 4 As shown, the node devices participating in the consensus process in the blockchain system are node device A, node device B, node device C, and node device D. In the (N-1)th round of consensus at block height H of the blockchain, node device B is the proposing node, and node devices A, C, and D are non-proposing nodes. (Refer to...) Figure 5 As shown, the specific process of the (N-1)th round of consensus in the blockchain at block height H includes:

[0060] I. Proposal Stage:

[0061] First, node device B (i.e., the proposing node) generates the target block Block-X to be reached in consensus. Block-X can be a new block created by node device B. Then, node device B generates a proposal message for the target block Block-X and broadcasts it to node devices A, C, and D.

[0062] II. Pre-voting stage:

[0063] Due to network failures, equipment malfunctions, or other reasons, some node devices may fail to receive Block-X broadcast by node device B in the first instance. For example, suppose node device A does not receive Block-X broadcast by node device B in the first instance, while nodes C and D both receive Block-X broadcast by node device B in the first instance. In the pre-voting phase, nodes B, C, and D all consider Block-X as the target block to be reached for consensus and perform pre-voting processing on Block-X to obtain their respective pre-voting messages. These pre-voting messages contain the identifier of the block to which pre-voting processing was performed. For example, if node device C performs pre-voting processing on Block-X to generate its own pre-voting message, this message includes the identifier of Block-X and indicates that node device C agrees to pre-vote on Block-X, i.e., agrees to add Block-X to the blockchain. Block-X thus receives node device C's pre-vote.

[0064] Understandably, if node device C does not generate its own pre-voting message, it means that node device C has not pre-voted for Block-X. If node device C's pre-voting message does not include the Block-X identifier, it means that node device C does not agree to pre-vote for Block-X, i.e., it does not agree to add Block-X to the blockchain. Since node device A did not receive Block-X in the first instance, it can identify the empty block `emptyBlock` as the target block to be reached for consensus and pre-vote for `emptyBlock` to obtain its own pre-voting message, which includes the identifier of `emptyBlock`. The "first instance" can be set according to actual needs, such as 30 seconds, 1 minute, 3 minutes, etc.

[0065] Node devices A, B, C, and D each broadcast their own pre-voting messages. Due to network failures, device failures, or other reasons, some node devices may not receive the pre-voting messages broadcast by other node devices in the second time. Therefore, when the second time arrives, each node device participating in the consensus process counts the number of pre-votes obtained by the target block to be reached in the pre-voting phase based on the pre-voting messages received in the second time, and confirms whether the number of pre-votes exceeds the quantity threshold (Quorum). The quantity threshold can be set according to the actual situation. For example, the quantity threshold can be 50% of the number of node devices participating in the consensus process, or 2 / 3 (or 2 / 3+1) of the number of node devices participating in the consensus process. Of course, in other embodiments, assuming the total number of consensus nodes is N, and the number of Byzantine nodes (i.e., malicious nodes) that can be tolerated is f, then the total number of consensus nodes N needs to satisfy N≥3f+1, and the Quorum needs to satisfy Quorum≥2f+1. Optionally, the second time here can also be set according to actual needs, such as 30 seconds, 1 minute, 3 minutes, etc.; the second time can be the same as the first time or different from the first time.

[0066] For example: Assume the threshold is 2. Since node A only performs pre-voting on emptyBlock, its pre-voting message includes the emptyBlock identifier. Nodes B, C, and D all perform pre-voting on Block-X, and their pre-voting messages all contain the Block-X identifier. Simultaneously, assume node A only receives pre-voting messages from node B. Combining this with node A's own pre-voting messages, we find that Block-X received 1 pre-vote, confirming that the number of pre-votes received by Block-X did not exceed the threshold of 2. Now, suppose node B receives pre-voting messages from nodes A, C, and D. Combining this with node B's own pre-voting messages, we find that Block-X received 3 pre-votes, confirming that the number of pre-votes received by Block-X exceeded the threshold of 2. Similarly, suppose node C receives three pre-voting messages from nodes A, B, and D. Combining these with its own pre-voting messages, node C calculates that Block-X has received 3 pre-votes, confirming that Block-X has received more than the threshold of 2 pre-votes. Similarly, suppose node D also receives three pre-voting messages from nodes A, B, and C. Combining these with its own pre-voting messages, node D calculates that Block-X has received 3 pre-votes, confirming that Block-X has received more than the threshold of 2 pre-votes.

[0067] III. Pre-submission stage:

[0068] Node devices B, C, and D all identify Block-X as the target block for consensus, and therefore each performs pre-commit processing on Block-X to obtain its own pre-commit voting message. This pre-commit voting message contains the identifier of the block for which pre-commit processing was performed. For example, node device C performs pre-commit processing on Block-X, generating node device C's pre-commit voting message. This message includes the identifier of Block-X and indicates that node device C agrees to pre-commit Block-X, thus confirming its agreement to add Block-X to the blockchain. Block-X receives node device C's pre-commit.

[0069] Understandably, if node device C does not generate its pre-commit voting message, it means that node device C has not pre-committed Block-X; if node device C's pre-commit voting message does not include the identifier of Block-X, it means that node device C does not agree to pre-commit Block-X, that is, it does not agree to add Block-X to the blockchain. Since node device A identifies the empty block emptyBlock as the target block for consensus, node device A pre-commits emptyBlock, resulting in node device A's pre-commit voting message, which includes the identifier of emptyBlock.

[0070] Node devices A, B, C, and D each broadcast their own pre-commit voting messages. Due to network failures, device failures, or other reasons, some node devices may not receive the pre-commit voting messages broadcast by other node devices within the third time period. When the third time period arrives, each participating node device calculates the number of pre-commits received in the pre-commit phase of the target block to be reached for consensus based on the pre-commit voting messages received within the third time period, and confirms whether this number of pre-commits exceeds the commit threshold. This commit threshold can be set according to actual conditions; for example, it can be 50% of the number of participating node devices, or 2 / 3 (or 2 / 3+1), or the aforementioned 2f+1. The third time period can also be set according to actual needs, such as 30 seconds, 1 minute, 3 minutes, etc.; the third time period can be the same as or different from the second time period; similarly, the third time period can be the same as or different from the first time period.

[0071] For example: Suppose the commit threshold is 2. Since node device A only performs pre-commit processing on emptyBlock, its pre-commit voting message includes the emptyBlock identifier. Node devices B, C, and D all perform pre-commit processing on Block-X, and their pre-commit voting messages all include the Block-X identifier. Simultaneously, suppose node device B receives pre-commit voting messages from nodes A and C, and by combining these with its own pre-commit voting messages, it is determined that Block-X obtained 2 pre-commits during the pre-commit phase, confirming that the number of pre-commits obtained by Block-X does not exceed (or is not greater than) the commit threshold of 2. Similarly, suppose node device C receives pre-commit voting messages from nodes A and C, and by combining these with its own pre-commit voting messages, it is determined that Block-X obtained 2 pre-commits, confirming that the number of pre-commits obtained by Block-X does not exceed (or is not greater than) the commit threshold of 2. Similarly, suppose node A receives three pre-commit vote messages from nodes B, C, and D. Combining this with node A's own pre-commit vote messages, the pre-commit count obtained by Block-X is 3, confirming that Block-X's pre-commit count exceeds the commit threshold of 2. Suppose node D also receives three pre-commit vote messages from nodes A, B, and C. Combining this with node D's own pre-commit vote messages, the pre-commit count obtained by Block-X is 3, confirming that Block-X's pre-commit count exceeds the commit threshold of 2.

[0072] After the three consensus phases described above, if the number of pre-votes received by the target block to be reached exceeds the threshold, and the number of pre-commits received also exceeds the commit threshold, then the target block to be reached successfully and can be added to the blockchain, i.e., a commit is executed; otherwise, the consensus fails and it cannot be added to the blockchain. Following the example above, node device A confirms that the number of pre-commits received by Block-X exceeds the commit threshold, but the number of pre-votes received does not exceed the threshold, therefore, Block-X consensus is considered to have failed. Node device B confirms that the number of pre-votes received by Block-X exceeds the threshold, but the number of pre-commits received does not exceed the commit threshold, therefore, Block-X consensus is considered to have failed. Node device C confirms that the number of pre-votes received by Block-X exceeds the threshold, but the number of pre-commits received does not exceed the commit threshold, therefore, Block-X consensus is considered to have failed. Node device D confirms that the number of pre-votes received by Block-X exceeds both the threshold and the commit threshold, therefore, Block-X consensus is considered to have succeeded, and node device D adds Block-X to the blockchain stored locally on node device D.

[0073] In summary, during the (N-1)th round of consensus at block height H of the blockchain, node devices A, B, and C did not reach a consensus on Block-X and did not write Block-X into their respective distributed ledgers (i.e., add it to their local blockchain storage). However, node device D reached a consensus on Block-X and wrote Block-X into its own distributed ledger. Therefore, the block height of the blockchain stored locally by node device D becomes H+1. During the Nth round of consensus at block height H of the blockchain, node device D will no longer participate in the consensus, and the node devices participating in the consensus will change to node devices A, B, and C.

[0074] It should be noted that when conducting the Nth round of consensus process at block height H of the blockchain, the proposing node may change. For example, in the above example, the proposing node in the (N-1)th round of consensus process at block height H of the blockchain is node device B, but in the Nth round of consensus process at block height H of the blockchain, it may change to node device C. Then, the above three consensus phases are re-executed to complete the Nth round of consensus process at block height H of the blockchain.

[0075] As can be seen from the consensus mechanism described above, each block needs to go through three stages: proposal, pre-voting, and pre-commit. If the proposal node malfunctions, the validating node can only enter the pre-voting stage after waiting for a set fixed time. This results in a longer consensus process, affecting the consensus performance of the blockchain. Specifically, for example... Figure 6As shown, in the new round of consensus process, node 0, as the proposing node, constructs a block in the proposal phase and encapsulates the block into a proposal message. Then, it broadcasts the proposal message to other consensus nodes. Other consensus nodes verify the validity of the proposal message and the block. After successful verification, they vote on the block in the prevote phase. This vote can be represented as a prevote message. After receiving a set number (i.e., Quorum, such as 2f+1) prevote messages, it enters the precommit phase. After entering the precommit phase, it continues to vote on the block. This vote can be represented as a precommit message. After receiving a set number (i.e., Quorum) precommit votes, consensus is reached on the block.

[0076] To ensure stable algorithm operation, each consensus node uses a timer δ during the proposal phase (δ is typically set relatively large, such as 30 seconds or more, to allow nodes to construct their proposal messages on time). This timer allows the proposing node to construct the block and proposal message. If other consensus nodes do not receive the proposal message within δ, they will vote for an empty block (nilBlock) to ensure the algorithm continues and quickly enters the next round of consensus. However, if a node fails, a fixed δ of time is wasted when it's that node's turn to propose. Assuming there are four consensus nodes, each taking turns as a proposing node, if one of them fails and cannot produce blocks or participate in consensus, a fixed 1 / 4 cycle of block production by the four nodes will be wasted, impacting system availability and consensus performance.

[0077] Based on this, the technical solution of this application proposes a new consensus scheme for blockchain to achieve dynamic adjustment of the waiting time of consensus nodes, thereby shortening the consensus time of blocks and improving the consensus performance of blockchain.

[0078] The following details the various implementation details of the technical solutions in the embodiments of this application:

[0079] Figure 7 A flowchart illustrating a blockchain consensus method according to an embodiment of this application is shown. This blockchain consensus method can be executed by consensus nodes. Specifically, refer to... Figure 7 As shown, the consensus method of this blockchain includes at least steps S710 to S730, which are described in detail below:

[0080] In step S710, during the consensus process initiated by the proposing node for the block to be reached, a pre-voting message is received from the consensus node in the blockchain network.

[0081] In the embodiments of this application, a proposal node refers to a node device elected by multiple consensus nodes participating in the consensus process. The node device acting as a proposal node is responsible for both generating blocks to be agreed upon during the proposal phase of the current consensus process and broadcasting these blocks to other participating node devices for consensus processing; it is also responsible for processing these blocks. Non-proposal nodes, on the other hand, only process the blocks to be agreed upon.

[0082] In some optional embodiments of this application, the pre-voting message sent by the consensus node in the blockchain network can be a pre-voting message for a block to be reached for consensus or a pre-voting message for an empty block. Specifically, if the consensus node receives a proposal message for a block to be reached for consensus within a set time period, it will send a pre-voting message for that block after verification; if the consensus node does not receive a proposal message for a block to be reached for consensus within the set time period, it will generate a pre-voting message for an empty block.

[0083] In step S720, based on the received pre-voting messages, the number of first pre-voting messages for the block to be reached for consensus is counted. The first pre-voting message is sent by the consensus node after receiving the proposal message of the block to be reached for consensus within a set time period. The set time period corresponds to the proposal node and is determined based on the block production time of the proposal node.

[0084] In some optional embodiments of this application, after receiving a proposal message for a block to be reached for consensus, each consensus node can generate a pre-vote message for that block, broadcast its generated pre-vote message to the blockchain network, and receive pre-vote messages sent by other consensus nodes in the blockchain network.

[0085] Optionally, the consensus node records a corresponding set duration for each proposal node, and the set duration recorded for each proposal node can be different or the same. This set duration can be determined based on the block production time of the proposal node, such as 1.5 times the block production time, 2 times the block production time, etc. More specifically, assuming the block production time is 2 seconds, then the set duration for consensus node 1 (i.e., when consensus node 1 acts as a proposal node) can be 3 seconds, and the set duration for consensus node 2 (i.e., when consensus node 2 acts as a proposal node) can be 4 seconds.

[0086] Since the corresponding set duration can be determined according to the block production time of each proposal node in this embodiment, the set duration of each proposal node is related to the block production time of the proposal node. This avoids setting the set duration too long, causing the consensus node to wait for a long time before entering the pre-voting stage, thus shortening the duration of the consensus process.

[0087] In step S730, the set duration recorded by the consensus node corresponding to the proposal node is adjusted according to the number of first pre-voting messages.

[0088] In the embodiments of this application, since the number of first pre-voting messages determines whether consensus nodes reach consensus in the pre-voting stage, and indirectly reflects whether the set duration is reasonable, the set duration recorded by the consensus nodes corresponding to the proposal nodes is adjusted according to the number of first pre-voting messages. When the number of first pre-voting messages does not meet the consensus quantity requirement of the pre-voting stage, the size of the set duration can be appropriately increased to ensure that the proposal nodes have enough time to produce blocks and build proposal messages. When the number of first pre-voting messages meets the consensus quantity requirement of the pre-voting stage and the set duration is set relatively large, the size of the set duration can be further reduced, thereby shortening the consensus time of the block and improving the consensus performance of the blockchain.

[0089] In one embodiment of this application, the specific adjustment process in step S730 may be as follows: if the number of first pre-voting messages (i.e., pre-voting messages for blocks to be reached) is less than the consensus quantity requirement of the pre-voting stage, and the number of second pre-voting messages received for empty blocks is less than the consensus quantity requirement, then the set duration recorded by the consensus node that sent the second pre-voting message and corresponding to the proposal node is increased until the set maximum value is reached.

[0090] In this embodiment, if the number of pre-voting messages for blocks awaiting consensus and the number of pre-voting messages for empty blocks are both less than the consensus requirement, it means that some consensus nodes received the proposal message within the set time period, while some consensus nodes did not receive the proposal message within the set time period. In this case, the set time period corresponding to the proposal node recorded by the consensus node that sent the second pre-voting message (i.e., the consensus node that voted for the empty block, i.e., the consensus node that did not receive the proposal message within the set time period) can be increased to ensure that these consensus nodes can receive the proposal message within the adjusted set time period when the proposal node initiates a proposal again.

[0091] Optionally, the consensus requirement in the pre-voting phase is the Quorum described in the above embodiments, which can be 2 / 3+1 of all consensus nodes, or 2 / 3 of all consensus nodes, or 2f+1.

[0092] Optionally, when increasing the set duration corresponding to the proposal node recorded by the consensus node that sends the second pre-voting message (i.e., the pre-voting message for an empty block), the set value can be increased directly, such as by 5 seconds or 10 seconds. However, the adjusted set duration must be less than or equal to the maximum set value (e.g., 30 seconds). Alternatively, the set duration can be increased by a certain value first, and if the next proposal message initiated by the proposal node still results in the number of both the first and second pre-voting messages being less than the consensus requirement, then the set duration can be increased by a certain value again. That is, the set duration can be adjusted according to a certain step size (which can be fixed or variable) until the maximum value is reached.

[0093] In one embodiment of this application, after increasing the set duration recorded by the consensus node corresponding to the proposal node, if the consensus process initiated by the proposal node again meets the consensus requirements in the pre-voting stage, the set duration recorded by the consensus node participating in the consensus process corresponding to the proposal node can be decreased; or the set duration can be kept unchanged.

[0094] Optionally, when adjusting the set duration corresponding to the proposal node recorded by the consensus nodes participating in the consensus process, the set value can be directly reduced, such as by 1 second or 2 seconds. However, the adjusted set duration must be greater than or equal to the minimum set value (e.g., 3 seconds). Alternatively, it can be reduced by a certain value first, and then if the consensus process initiated by the same proposal node again meets the consensus requirements in the pre-voting stage, then the value can be reduced by another certain value. That is, adjustments can be made according to a certain step size (which can be fixed or variable) until the minimum value is reached. The technical solution of this embodiment can shorten the size of the set duration as much as possible while ensuring the normal operation of the blockchain network consensus process, thereby shortening the consensus time of the block.

[0095] In one embodiment of this application, the specific adjustment process in step S730 may be as follows: if the number of first pre-voting messages (i.e., pre-voting messages for blocks to be reached) is less than the consensus quantity requirement of the pre-voting stage, and the number of second pre-voting messages received for empty blocks is greater than or equal to the consensus quantity requirement, then the set duration recorded by the consensus nodes participating in the consensus process corresponding to the proposal nodes is increased until the set maximum value is reached.

[0096] In this embodiment, if the number of pre-voting messages for the block to be reached for consensus is less than the consensus requirement, but the number of pre-voting messages for the empty block is greater than or equal to the consensus requirement, it indicates that most consensus nodes have not received the proposal message within the set time period. In this case, the set time period recorded by the consensus nodes participating in the consensus, corresponding to the proposal node, can be increased to ensure that the consensus nodes participating in the consensus can receive the proposal message within the adjusted set time period when the proposal node initiates a proposal again. In other embodiments of this application, the set time period recorded by the consensus node that sent the second pre-voting message (i.e., the consensus node that voted for the empty block, i.e., the consensus node that did not receive the proposal message within the set time period) corresponding to the proposal node can also be increased.

[0097] Optionally, the consensus requirement in the pre-voting phase is the Quorum described in the above embodiments, which can be 2 / 3+1 of all consensus nodes, or 2 / 3 of all consensus nodes, or 2f+1.

[0098] Optionally, when increasing the set duration recorded by the consensus nodes corresponding to the proposal nodes, the set value can be increased directly, such as by 5 seconds or 10 seconds. However, the adjusted set duration must be less than or equal to the maximum set value (e.g., 30 seconds). Alternatively, the value can be increased by a certain amount first, and if the next proposal message initiated by the proposal node still shows that the number of first pre-vote messages is less than the consensus requirement, while the number of second pre-vote messages is greater than or equal to the consensus requirement, then the value can be increased by a certain amount again. That is, the value can be adjusted according to a certain step size (which can be fixed or variable) until the maximum value is reached.

[0099] In one embodiment of this application, after increasing the set duration recorded by the consensus node corresponding to the proposal node, if the consensus process initiated by the proposal node again meets the consensus requirements in the pre-voting stage, the set duration recorded by the consensus node participating in the consensus process corresponding to the proposal node can be decreased; or the set duration can be kept unchanged.

[0100] Optionally, when adjusting the set duration corresponding to the proposal node recorded by the consensus nodes participating in the consensus process, the set value can be directly reduced, such as by 1 second or 2 seconds. However, the adjusted set duration must be greater than or equal to the minimum set value (e.g., 3 seconds). Alternatively, it can be reduced by a certain value first, and then if the consensus process initiated by the same proposal node again meets the consensus requirements in the pre-voting stage, then the value can be reduced by another certain value. That is, adjustments can be made according to a certain step size (which can be fixed or variable) until the minimum value is reached. The technical solution of this embodiment can shorten the size of the set duration as much as possible while ensuring the normal operation of the blockchain network consensus process, thereby shortening the consensus time of the block.

[0101] In one embodiment of this application, the specific adjustment process in step S730 may be: if the number of first pre-voting messages is greater than or equal to the consensus quantity requirement of the pre-voting stage, then the set duration recorded by the consensus nodes participating in the consensus process corresponding to the proposal nodes remains unchanged, or the set duration recorded by the consensus nodes participating in the consensus process corresponding to the proposal nodes is reduced until the set minimum value is reached.

[0102] Optionally, when adjusting the set duration corresponding to the proposal node recorded by the consensus nodes participating in the consensus process, the set value can be directly reduced, such as by 1 second or 2 seconds. However, the adjusted set duration must be greater than or equal to the minimum set value (e.g., 3 seconds). Alternatively, it can be reduced by a certain value first, and then if the consensus process initiated by the same proposal node again meets the consensus requirements in the pre-voting stage, then the value can be reduced by another certain value. That is, adjustments can be made according to a certain step size (which can be fixed or variable) until the minimum value is reached. The technical solution of this embodiment can shorten the size of the set duration as much as possible while ensuring the normal operation of the blockchain network consensus process, thereby shortening the consensus time of the block.

[0103] It should be noted that the adjustment process described in the above embodiments of this application can be implemented individually or in combination. As long as the corresponding conditions are met during the adjustment process, the corresponding adjustment method can be selected.

[0104] Figure 8 A flowchart illustrating a blockchain consensus method according to an embodiment of this application is shown. This blockchain consensus method can be executed by consensus nodes. Specifically, refer to... Figure 8 As shown, the consensus method of this blockchain includes at least steps S810 to S840, which are described in detail below:

[0105] In step S810, the number of times each consensus node encounters anomalies during the consensus process is counted.

[0106] In one embodiment of this application, an abnormality in a consensus node may be due to a network anomaly causing a disconnection or a system failure causing a crash. It may also be due to the failure to perform the corresponding consensus operation, such as the proposal node failing to produce a block within the set time or failing to successfully construct a proposal message.

[0107] Optionally, after each consensus node initiates a proposal message for the proposal block as a proposal node, the number of pre-voting messages received for the proposal block can be counted. If the number of pre-voting messages received for the proposal block does not meet the consensus quantity requirement of the pre-voting stage, it indicates that the proposal node may not have produced a block within the set time, or may not have successfully constructed a proposal message, or may have failed to send the proposal message to other consensus nodes due to a network failure. In this case, it can be determined that the consensus node that initiated the proposal message for the proposal block is abnormal.

[0108] In step S820, if the number of consecutive anomalies of a specified consensus node reaches a set number, a first transaction message of configuration type is generated. This first transaction message is used to indicate the cancellation of the specified consensus node's participation in the consensus process.

[0109] Optionally, the consensus node that generates the first transaction information of the configuration type can be either the consensus node that will act as the proposal node in the next consensus cycle, or any other normal consensus node in the blockchain network. If it is generated by another consensus node, then the first transaction information needs to be sent to the consensus node that will act as the proposal node in the next consensus cycle.

[0110] In step S830, a first block is generated based on the first transaction information.

[0111] Optionally, generating the first block based on the first transaction information means packaging the first transaction information to generate the first block.

[0112] In step S840, a proposal message for the first block is generated and broadcast to other consensus nodes in the blockchain network.

[0113] Optionally, the proposal message of the first block can be distinguished from normal proposal messages, so that other consensus nodes, upon receiving the proposal message, can know that the proposal message is used to cancel the participation of a specified consensus node in the consensus process. For example, the proposal message of the first block contains proposal message type information and identifier information of the specified consensus node, and the proposal message type information is configured to indicate that the proposal message of the first block is used to cancel the participation of a specified consensus node in the consensus process.

[0114] In one embodiment of this application, if the first block reaches consensus in the blockchain network, it can be determined that the designated consensus node will no longer participate in the consensus process of the blockchain network.

[0115] Figure 8 The technical solution of the embodiment shown enables the removal of abnormal consensus nodes from the blockchain network, avoiding the problem that other consensus nodes need to wait for a long time when an abnormal consensus node acts as a proposal node, thereby shortening the consensus time of the block.

[0116] Figure 9 A flowchart illustrating a blockchain consensus method according to an embodiment of this application is shown. This blockchain consensus method can be executed by consensus nodes. Specifically, refer to... Figure 9 As shown, the consensus method of this blockchain includes at least steps S910 to S940, which are described in detail below:

[0117] In step S910, the number of times each consensus node encounters anomalies during the consensus process is counted.

[0118] In one embodiment of this application, an abnormality in a consensus node may be due to a network anomaly causing a disconnection or a system failure causing a crash. It may also be due to the failure to perform the corresponding consensus operation, such as the proposal node failing to produce a block within the set time or failing to successfully construct a proposal message.

[0119] Optionally, after each consensus node initiates a proposal message for the proposal block as a proposal node, the number of pre-voting messages received for the proposal block can be counted. If the number of pre-voting messages received for the proposal block does not meet the consensus quantity requirement of the pre-voting stage, it indicates that the proposal node may not have produced a block within the set time, or may not have successfully constructed a proposal message, or may have failed to send the proposal message to other consensus nodes due to a network failure. In this case, it can be determined that the consensus node that initiated the proposal message for the proposal block is abnormal.

[0120] In step S920, if the number of consecutive anomalies of the specified consensus node reaches a set number, a second transaction information of configuration type is generated. This second transaction information is used to instruct the alternative node corresponding to the specified consensus node to participate in the consensus process instead of the specified consensus node.

[0121] Optionally, the consensus node that generates the second transaction information of the configuration type can be either the consensus node that will act as the proposal node in the next consensus cycle, or any other normal consensus node in the blockchain network. If it is generated by another consensus node, then the second transaction information needs to be sent to the consensus node that will act as the proposal node in the next consensus cycle.

[0122] In step S930, a second block is generated based on the second transaction information.

[0123] Optionally, generating a second block based on the second transaction information means packaging the second transaction information to generate a second block.

[0124] In step S940, a proposal message for the second block is generated and broadcast to other consensus nodes in the blockchain network and the backup node of the designated consensus node.

[0125] Optionally, the proposal message of the second block can be distinguished from normal proposal messages, so that other consensus nodes, upon receiving the proposal message, can know that the proposal message is used to instruct the designated consensus node to participate in the consensus process by replacing the designated consensus node with a candidate node corresponding to the designated consensus node. For example, the proposal message of the second block contains proposal message type information and identification information of the candidate node corresponding to the designated consensus node. The proposal message type information is configured to indicate that the proposal message of the second block is used to replace the designated consensus node in the consensus process by replacing the designated consensus node with a candidate node corresponding to the designated consensus node.

[0126] It should be noted that the premise for the second block's proposal message to include the identification information of the candidate node corresponding to the specified consensus node is that the consensus nodes in the blockchain network already know the consensus nodes corresponding to the candidate nodes. For example, each consensus node in the blockchain network corresponds to a candidate node, and this has been recorded by each consensus node. Then, after knowing the identification information of the candidate node, it is possible to know which consensus node it is used to replace.

[0127] In other embodiments of this application, the proposal message of the second block may not contain the identification information of the candidate node corresponding to the specified consensus node, but only the identification information of the specified consensus node. In this case, the consensus nodes in the blockchain network already know the candidate node corresponding to the consensus node. For example, each consensus node in the blockchain network corresponds to a candidate node, and this has been recorded by each consensus node. So, after knowing the identification information of the specified consensus node, the corresponding candidate node can be known.

[0128] Furthermore, the proposal message of the second block can include the identification information of the designated consensus node and the identification information of the corresponding alternative node. So, regardless of whether the consensus nodes in the blockchain network record the correspondence between the consensus nodes and the alternative nodes, it is possible to know which alternative node needs to replace which consensus node based on the proposal message of the second block.

[0129] In one embodiment of this application, if the second block reaches consensus in the blockchain network, the designated consensus node is determined to no longer participate in the consensus process of the blockchain network. Optionally, during the pre-voting phase of the consensus process for the second block, the candidate nodes also need to participate in the pre-voting process. After receiving the proposal message of the second block and the pre-voting message sent by the candidate nodes, other consensus nodes in the blockchain network can send pre-voting messages, which can ensure that the candidate nodes are alive and can be changed into consensus nodes.

[0130] In one embodiment of this application, if the second block reaches consensus in the blockchain network, other consensus nodes participating in the consensus process can send a pre-commit voting message for the second block to the candidate node corresponding to the designated consensus node, so that after the candidate node of the designated consensus node receives the pre-commit voting message and reaches the consensus quantity requirement of the pre-commit stage, it can replace the designated consensus node to participate in the consensus process.

[0131] Optionally, the consensus quantity requirement in the pre-commit phase can also be the Quorum described in the above embodiments, which can be 2 / 3+1 of all consensus nodes, or 2 / 3 of all consensus nodes, or 2f+1.

[0132] Figure 9 The technical solution of the embodiment shown enables the removal of abnormal consensus nodes from the blockchain network while introducing new consensus nodes. This avoids the problem that other consensus nodes need to wait for a long time when an abnormal consensus node acts as a proposal node, and also avoids the problem that the consensus algorithm becomes inaccurate due to a decrease in the number of consensus nodes in the blockchain network.

[0133] The following combination Figures 10 to 15 The implementation details of the technical solutions in the embodiments of this application will be described again:

[0134] The technical solution of this application mainly includes three parts: First, a dynamic adjustment mechanism for the block production timeout of consensus nodes, which weakens the impact of proposal nodes failing to produce blocks on the consensus process; second, an algorithm for stripping the proposal rights of abnormal consensus nodes, which fundamentally avoids the performance impact on the consensus process when a consensus node that has actually crashed and continuously timed out is elected as a proposer; and finally, a candidate backup node upgrade algorithm, which upgrades the configured candidate backup nodes to consensus nodes, avoiding the problem that the total number of consensus nodes does not meet the algorithm's security requirements after a crashed consensus node is stripped of its proposal rights, thereby improving the security of the consensus algorithm and the reliability of the system.

[0135] In one embodiment of this application, the main process of the dynamic adjustment mechanism for the block production timeout of consensus nodes can be referred to... Figure 10As shown, in the new round phase (i.e., when a new round of consensus process begins), each consensus node updates its own consensus state to prepare for the start of this round of consensus. Subsequently, each consensus node will enter the proposal phase.

[0136] During the proposal phase, all consensus nodes start a timer for that round of proposals. The timer duration is γ, where γ = min(δ, φ). Here, δ is a relatively large fixed timeout, such as 30 seconds; φ is a time maintained by each consensus node for that specific proposal node, which can be twice the actual block production time of that node (or the average block production time over several consensus cycles). The proposal node constructs a block based on local transactions and combines the block and consensus state to construct a proposal message. The format of the proposal message can be...<PROPOSAL,block,state,i> σ i Where `block` represents the proposal block, which contains numerous transactions; `state` represents the consensus state, including the current block height, the current consensus round, and currently locked blocks; `i` represents the sequence number of the node that sent the proposal message; and `σ` represents the consensus state. i This represents the signature of the node that sent the proposal message.

[0137] During the prevote phase, when a consensus node receives a proposal message from a proposing node, it updates its record of the time taken to produce a block for that proposing node. If a consensus node acting as a validator does not receive the proposal message broadcast by the proposing node within time γ, it will directly vote for the nil block (i.e., an empty block) to obtain a prevote message, thus entering the precommit phase as quickly as possible. If it receives the proposal message broadcast by the proposing node within time γ, it will vote for the proposed block after successful validation, obtaining a prevote message. The format of the prevote message can be...<PREVOTE,hash,state,j> σ j Where hash represents the hash value of the block being voted on; state represents the consensus state, including the current block height, the current consensus round, and the currently locked blocks; j represents the sequence number of the node that sent the pre-vote message, and <>σ j This represents the signature of the node that sent the pre-vote message.

[0138] During the precommit phase, consensus nodes vote normally. If they have previously voted on a block and received prevote votes from all Quorum nodes, they continue to vote for the precommit of that block and receive a precommit message. If they have not received prevote votes from all Quorum nodes for a specific block, they vote on nilBlock and receive a precommit message to complete this round of consensus as quickly as possible and move on to the next round. The format of the precommit message can be...<PRECOMMIT,hash,state,j> σ j Where hash represents the hash value of the voted block; state represents the consensus state, including the current block height, the current consensus round, and the currently locked blocks; j represents the sequence number of the node that sent the precommit message, and <>σ j This indicates the signature of the node that sent the precommit message.

[0139] In the above process, the consensus node, acting as a validator, sets a proposal timeout of γ, where γ is twice the historical average block production time recorded by that validator. Therefore, it's possible that in a certain round, a proposal node may not have crashed, but its block production time exceeds twice the average proposal time perceived by some validators. Consequently, some nodes might vote for the nil block without receiving the proposal message, while others might have actually received the proposal message and voted on the block within it. The following analysis uses four consensus nodes as an example, illustrating the following possibilities. Figures 11 to 13 Three situations:

[0140] like Figure 11 As shown, if consensus node 3 believes that consensus node 0 (i.e., the proposing node) failed to produce a block and construct a proposal message within the specified time, it will directly vote on nilBlock. At this time, the other three consensus nodes (i.e., consensus node 0, consensus node 1, and consensus node 2) receive the proposal message broadcast by the proposing node within the specified time. These three consensus nodes will then receive a Quorum of prevote votes for the block in the proposal message, reaching consensus for this round without any security issues. In this case, the φ recorded by the consensus nodes for the proposing node can remain unchanged; alternatively, φ can be appropriately reduced to further shorten the time consensus nodes spend waiting for the proposing node to produce a block and construct a proposal message during the consensus process.

[0141] like Figure 12As shown, consensus nodes 2 and 3 believe that consensus node 0 (i.e., the proposing node) failed to produce a block and construct a proposal message within the specified time. Therefore, they will directly vote on nilBlock. Meanwhile, the other two consensus nodes (i.e., consensus node 0 and consensus node 1) have received the proposal message broadcast by the proposer within the specified time. They will not be able to reach a consensus on the empty block nilBlock and the actual block in the proposal message, thus entering the next round of consensus without any security issues. In this case, the consensus node that did not receive the proposal message broadcast by the proposing node within the specified time can set the φ recorded for that proposing node to δ (or a value larger than φ but smaller than δ) to avoid the node continuously missing proposal messages from the proposer due to the φ time being too short.

[0142] like Figure 13 As shown, consensus nodes 2, 3, and 4 believe that consensus proposal node 0 (i.e., the proposal node) failed to produce a block and construct a proposal message within the specified time. Therefore, they will directly vote on nilBlock. In this case, the three consensus nodes will receive a Quorum of prevote votes for the empty block nilBlock, achieving consensus in this round without any security issues. In this scenario, each consensus node can set the φ recorded for the proposal node to δ (or a value larger than φ but smaller than δ) to avoid nodes continuously missing proposal messages from the proposer due to a short φ time. In other embodiments of this application, a consensus node that fails to receive the proposal message broadcast by the proposal node within the specified time can also set the φ recorded for the proposal node to δ.

[0143] It should be noted that, for Figure 12 and Figure 13 As shown, after increasing φ, if the subsequent proposal message initiated by the same node receives a prevote vote from Quorum Zhang for the proposal block during the prevote phase, then φ can be appropriately reduced to shorten the time for consensus nodes to wait for the proposal node to produce a block and construct a proposal message during the consensus process.

[0144] In one embodiment of this application, the algorithm for depriving abnormal consensus nodes of their proposal rights is mainly based on the number of times each consensus node fails to produce blocks and / or successfully constructs proposal messages when other consensus nodes are acting as proposal nodes. If this number reaches a certain threshold... If (assuming 10 times), the consensus node is identified as an abnormal consensus node. The current consensus node will then initiate a proposal message to strip the abnormal consensus node of its proposal rights, and other consensus nodes will reach a consensus. If the consensus is successful, the proposal rights of the abnormal consensus algorithm will be removed.

[0145] Specifically, such as Figure 14 As shown, in the new round phase (i.e., when a new round of consensus process begins), each consensus node updates its own consensus state, prepares for the start of this round of consensus, and calculates the number of times other consensus nodes have consecutively failed to produce blocks and / or failed to successfully construct proposal messages. If a consensus node is found to have consecutively failed to produce blocks and / or failed to successfully construct proposal messages, the node will be notified. If no block is produced and / or the proposal message is not successfully constructed, the change phase is entered to execute the proposal right removal algorithm.

[0146] During the change phase, assuming consensus node 1 is the proposal node, it is found that consensus node 0 has failed to produce blocks consecutively and / or has failed to successfully construct proposal messages a certain number of times. Next, a configuration-type transaction will be constructed. This transaction removes the proposal right of consensus node 0 and is placed in the block, constructing a special type of proposal message:<CHANGE,block,state,i,k> σ i Where block represents the proposal block, which contains transactions of this configuration type; state represents the consensus state, including the current block height, the current consensus round, and the currently locked blocks; i represents the sequence number of the node that sent the proposal message (consensus node 1 in this example); k represents the sequence number of the consensus node whose proposal right is to be removed (consensus node 0 in this example); <>σ i This indicates the signature of the node that sent the proposal message (consensus node 1 in this example). The change message is then broadcast to the other consensus nodes.

[0147] During the prevote phase, other consensus nodes may or may not receive the change message, as described above. Figures 11 to 13 Of the three scenarios shown, only when all remaining consensus nodes receive the change message and also consider consensus node 0 to be consecutive will the outcome be determined. A consensus on a proposal will only be reached if no block is produced and / or the proposal message is not successfully constructed. It's important to note that the remaining three consensus nodes may not reach a consensus in this round, indicating that one of the consensus nodes did not consider consensus node 0 to be discontinuous. It doesn't matter if no block is produced and / or the proposal message is not successfully constructed. If consensus node 0 truly crashes, all consensus nodes will eventually consider it continuous. Even if no block is produced and / or no proposal message is successfully constructed, a consensus will eventually be reached to strip the abnormally downed node of its proposal rights.

[0148] In the precommit phase, similar to the prevote phase mentioned above, the remaining three consensus nodes must reach a consensus before consensus node 0's proposal right can be truly stripped.

[0149] The algorithm for depriving abnormal consensus nodes of their proposal rights in this application embodiment can remove abnormal consensus nodes from the blockchain network, avoiding the problem that other consensus nodes need to wait for a long time when an abnormal consensus node acts as a proposal node, thereby shortening the consensus time of the block.

[0150] In one embodiment of this application, the candidate backup node upgrade algorithm is primarily designed to ensure the stability and reliability of the blockchain system. In actual deployment, a candidate backup node can be set for each consensus node. The algorithm is activated when a consensus node fails to produce blocks consecutively and / or fails to successfully construct a proposal message a set number of times. When necessary, candidate backup nodes can be upgraded to consensus nodes, keeping the total number of consensus nodes N≥3f+1, thus ensuring that the algorithm's fault tolerance remains unchanged.

[0151] Specifically, such as Figure 15 As shown, in the new round phase (i.e., when a new round of consensus process begins), each consensus node updates its own consensus state, prepares for the start of this round of consensus, and calculates the number of times other consensus nodes have consecutively failed to produce blocks and / or failed to successfully construct proposal messages. If a consensus node is found to have consecutively failed to produce blocks and / or failed to successfully construct proposal messages, the node will be notified. If a consensus node fails to produce a block and / or fails to construct a proposal message, and there is a candidate backup node, then the node enters the update phase to execute the candidate node upgrade algorithm.

[0152] During the update phase, assuming consensus node 1 is the proposal node, it is found that consensus node 0 has failed to produce blocks consecutively and / or has failed to successfully construct proposal messages a certain number of times. Next, a configuration-type transaction will be constructed. This transaction removes consensus node 0's proposal right and upgrades its candidate backup node 0 to a consensus node. This transaction will then be placed in the block, constructing a special type of proposal message:<UPDATE,block,state,i,k> σ iWhere block represents the proposal block, which contains transactions of this configuration type; state represents the consensus state, including the current block height, the current consensus round, and the currently locked blocks; i represents the sequence number of the node that sent the proposal message (consensus node 1 in this example); k represents the sequence number of the candidate backup node (i.e., candidate backup node 0 of consensus node 0); <>σ i This indicates the signature of the node that sent the proposal message (consensus node 1 in this example). The update message is then broadcast to other consensus nodes and candidate backup node 0.

[0153] It should be noted that the premise for this special type of proposal message to include the sequence number of the candidate backup node is that each consensus node already knows the consensus node corresponding to the candidate backup node. For example, each consensus node corresponds to a candidate backup node, and this has been recorded by each consensus node. Then, after knowing the sequence number of the candidate backup node, it is possible to know which consensus node it is used to replace.

[0154] In other embodiments of this application, the special type of proposal message may not contain the sequence number of the candidate node, but only the sequence number of the consensus node whose proposal right needs to be removed. In this case, each consensus node already knows the candidate node corresponding to the consensus node. For example, each consensus node corresponds to a candidate node, and this has been recorded by each consensus node. So, after knowing the sequence number of the consensus node whose proposal right needs to be removed, the corresponding candidate node can be known.

[0155] Furthermore, this special type of proposal message can contain the sequence number of the consensus node that needs to be removed from the proposal list and the sequence number of the corresponding candidate node. So, regardless of whether the consensus nodes in the blockchain network record the correspondence between the consensus nodes and the candidate nodes, we can know which candidate node needs to replace which consensus node based on this special type of proposal message.

[0156] During the prevote phase, other consensus nodes may or may not receive the update message, similar to the change message processing described above. Ultimately, consensus will be reached, which will not be elaborated upon here. It's important to note that at this stage, consensus nodes will only vote on the proposal after receiving both the update message and the prevote message broadcast by candidate backup node 0. This ensures the candidate backup node survives and can be upgraded to a consensus node.

[0157] In the precommit phase, similar to the prevote phase, the remaining three consensus nodes must reach a consensus before consensus node 0's proposal right can be truly stripped and candidate backup node 0 can be upgraded to a consensus node.

[0158] During the commit phase, each consensus node will send its generated precommit message to candidate backup node 0. After candidate backup node 0 receives 2f+1 precommit messages, it will replace consensus node 0 and become the real consensus node.

[0159] The candidate backup node upgrade algorithm of this application embodiment can remove abnormal consensus nodes from the blockchain network and introduce new consensus nodes at the same time. This avoids the problem that other consensus nodes need to wait for a long time when an abnormal consensus node is a proposal node, and it can also avoid the problem that the consensus algorithm becomes inaccurate due to the reduction in the number of consensus nodes in the blockchain network.

[0160] The technical solution of the above embodiments of this application adopts a mechanism of dynamically adjusting the block production timeout time of consensus nodes. This allows consensus nodes, acting as verification nodes, to vote on nilBlocks without waiting for a fixed, long time. Instead, they only need to wait a short time, reducing meaningless timeout waiting and improving consensus efficiency. Simultaneously, by employing an algorithm to remove abnormal consensus node proposal rights, the proposal rights of nodes that have been down for extended periods and have continuously timed out are revoked, avoiding prolonged timeouts and increasing system availability. Furthermore, by using a mechanism to upgrade candidate backup nodes to consensus nodes, abnormal consensus nodes can be replaced when candidate backup nodes are set. This ensures that the total number of nodes participating in the consensus always meets the security requirements, guaranteeing that the algorithm's fault tolerance is not compromised.

[0161] The following describes an apparatus embodiment of this application, which can be used to execute the blockchain consensus method in the above embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the above embodiments of the blockchain consensus method of this application.

[0162] Figure 16 A block diagram of a consensus device for a blockchain according to an embodiment of this application is shown, which can be set within a consensus node.

[0163] Reference Figure 16 As shown, a blockchain consensus device 1600 according to an embodiment of this application includes: a receiving unit 1602, a statistics unit 1604, and an adjustment unit 1604.

[0164] The receiving unit 1602 is configured to receive pre-voting messages sent by consensus nodes in the blockchain network during the consensus process initiated by the proposing node for the block to be reached; the counting unit 1604 is configured to count the number of first pre-voting messages for the block to be reached based on the received pre-voting messages, wherein the first pre-voting message is sent by the consensus node after receiving the proposal message for the block to be reached within a set time period, the set time period corresponding to the proposing node and determined based on the block production time of the proposing node; the adjusting unit 1604 is configured to adjust the set time period recorded by the consensus node corresponding to the proposing node based on the number of first pre-voting messages.

[0165] In some embodiments of this application, based on the foregoing scheme, the adjustment unit 1604 is configured to: if the number of the first pre-voting messages is less than the consensus quantity requirement of the pre-voting stage, and the number of the second pre-voting messages received for empty blocks is less than the consensus quantity requirement, then the set duration recorded by the consensus node that sent the second pre-voting message and corresponding to the proposal node is increased until the set maximum value is reached.

[0166] In some embodiments of this application, based on the foregoing scheme, the adjustment unit 1604 is configured to: if the number of the first pre-voting messages is less than the consensus quantity requirement of the pre-voting stage, and the number of the second pre-voting messages received for empty blocks is greater than or equal to the consensus quantity requirement, then the set duration recorded by the consensus nodes participating in the consensus process corresponding to the proposal node is increased until the set maximum value is reached.

[0167] In some embodiments of this application, based on the foregoing scheme, the adjustment unit 1604 is further configured to: after increasing the set duration recorded by the consensus node corresponding to the proposal node, if the consensus process initiated by the proposal node again meets the consensus requirements in the pre-voting stage, then the set duration recorded by the consensus node participating in the consensus process corresponding to the proposal node is decreased.

[0168] In some embodiments of this application, based on the foregoing scheme, the adjustment unit 1604 is configured to: if the number of the first pre-voting messages is greater than or equal to the consensus quantity requirement of the pre-voting stage, then control the set duration recorded by the consensus nodes participating in the consensus process corresponding to the proposal node to remain unchanged, or reduce the set duration recorded by the consensus nodes participating in the consensus process corresponding to the proposal node until the set minimum value is reached.

[0169] In some embodiments of this application, based on the foregoing scheme, the statistics unit 1604 is further configured to: count the number of times each consensus node experiences anomalies during the consensus process; the consensus device 1600 of the blockchain further includes: a generation unit configured to: if the number of consecutive anomalies of a specified consensus node reaches a set number, generate first transaction information of configuration type, the first transaction information being used to indicate the cancellation of the specified consensus node's participation in the consensus process; generate a first block based on the first transaction information; generate a proposal message for the first block; and broadcast the proposal message of the first block to other consensus nodes in the blockchain network.

[0170] In some embodiments of this application, based on the foregoing scheme, the proposal message of the first block includes type information of the proposal message and identification information of the designated consensus node. The type information of the proposal message is configured to indicate that the proposal message of the first block is used to cancel the participation of the designated consensus node in the consensus process.

[0171] In some embodiments of this application, based on the aforementioned scheme, if the first block reaches consensus in the blockchain network, then it is determined that the designated consensus node will no longer participate in the consensus process of the blockchain network.

[0172] In some embodiments of this application, based on the foregoing scheme, the statistics unit 1604 is further configured to: count the number of times each consensus node experiences anomalies during the consensus process; the blockchain consensus device 1600 further includes: a generation unit configured to: if the number of consecutive anomalies of a specified consensus node reaches a set number, generate second transaction information of a configuration type, the second transaction information being used to instruct the alternative node corresponding to the specified consensus node to participate in the consensus process in place of the specified consensus node; generate a second block based on the second transaction information; generate a proposal message for the second block; and broadcast the proposal message of the second block to other consensus nodes in the blockchain network and the backup node of the specified consensus node.

[0173] In some embodiments of this application, based on the foregoing scheme, the proposal message of the second block includes type information of the proposal message and identification information of the alternative node corresponding to the designated consensus node. The type information of the proposal message is configured to indicate that the proposal message of the second block is used to replace the designated consensus node in the consensus process through the alternative node corresponding to the designated consensus node.

[0174] In some embodiments of this application, based on the aforementioned scheme, if the second block reaches consensus in the blockchain network, it is determined that the designated consensus node will no longer participate in the consensus process of the blockchain network; the consensus device 1600 of the blockchain further includes: a sending unit configured to send a pre-commit voting message of the second block to a candidate node corresponding to the designated consensus node, so that after the candidate node of the designated consensus node receives the pre-commit voting message and reaches the consensus quantity requirement of the pre-commit stage, it can replace the designated consensus node in the consensus process.

[0175] In some embodiments of this application, based on the foregoing scheme, the statistics unit 1604 is further configured to: after each consensus node initiates a proposal message for the proposal block as a proposal node, count the number of pre-voting messages received for the proposal block; if the number of pre-voting messages received for the proposal block does not meet the consensus quantity requirement of the pre-voting stage, then it is determined that the consensus node that initiated the proposal message for the proposal block is abnormal.

[0176] Figure 17 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown.

[0177] It should be noted that, Figure 17 The computer system 1700 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0178] like Figure 17 As shown, the computer system 1700 includes a Central Processing Unit (CPU) 1701, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 1702 or programs loaded from storage portion 1708 into Random Access Memory (RAM) 1703, such as performing the methods described in the above embodiments. Various programs and data required for system operation are also stored in RAM 1703. The CPU 1701, ROM 1702, and RAM 1703 are interconnected via bus 1704. An Input / Output (I / O) interface 1705 is also connected to bus 1704.

[0179] The following components are connected to I / O interface 1705: an input section 1706 including a keyboard, mouse, etc.; an output section 1707 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1708 including a hard disk, etc.; and a communication section 1709 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1709 performs communication processing via a network such as the Internet. Drive 1710 is also connected to I / O interface 1705 as needed. Removable media 1711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1710 as needed so that computer programs read from them can be installed into storage section 1708 as needed.

[0180] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1709, and / or installed from removable medium 1711. When the computer program is executed by central processing unit (CPU) 1701, it performs various functions defined in the system of this application.

[0181] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. The transmitted data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0182] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and a computer program.

[0183] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0184] In another aspect, this application also provides a computer-readable medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The computer-readable medium carries one or more computer programs, which, when executed by the electronic device, cause the electronic device to perform the methods described in the above embodiments.

[0185] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0186] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this application.

[0187] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0188] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A consensus method for blockchain, characterized in that, include: During the consensus process initiated by the proposing node for the block to be reached, it receives pre-voting messages sent by consensus nodes in the blockchain network; The pre-voting message includes a first preset voting message and a second pre-voting message. The first pre-voting message is generated by the consensus node for the block to be reached after receiving and verifying the proposal message of the block to be reached within a set time period. The second preset voting message is generated by the consensus node for an empty block after failing to receive the proposal message within the set time period. The set time period corresponds to the proposal node and is determined based on the block production time of the proposal node. The consensus node records the set time period corresponding to each proposal node. Based on the received pre-voting messages, count the number of first pre-voting messages for the block awaiting consensus; Based on the number of the first pre-voting messages, the set duration recorded by the consensus node corresponding to the proposal node is adjusted; The step of adjusting the set duration recorded by the consensus node corresponding to the proposal node based on the number of the first pre-voting messages includes: If the number of the first pre-voting messages is less than the consensus requirement for the pre-voting phase, and the number of the second pre-voting messages received for empty blocks is less than the consensus requirement, then the set duration recorded by the consensus node that sent the second pre-voting message, corresponding to the proposal node, will be increased.

2. The consensus method for blockchain according to claim 1, characterized in that, Increasing the set duration recorded by the consensus node that sent the second pre-voting message, corresponding to the proposal node, includes: The consensus node that sent the second pre-voting message increases the set duration corresponding to the proposal node by a set value, and the adjusted set duration is less than or equal to the set maximum value; or The set duration recorded by the consensus node that sends the second pre-voting message, corresponding to the proposal node, is increased according to the set step size until the set maximum value is reached.

3. The consensus method for blockchain according to claim 1, characterized in that, Based on the number of the first pre-voting messages, the set duration recorded by the consensus node corresponding to the proposal node is adjusted, including: If the number of the first pre-voting messages is less than the consensus requirement for the pre-voting phase, and the number of the second pre-voting messages received for empty blocks is greater than or equal to the consensus requirement, then the set duration recorded by the consensus nodes participating in the consensus process corresponding to the proposal node will be increased until the set maximum value is reached.

4. The consensus method for blockchain according to claim 2 or 3, characterized in that, The consensus method also includes: After increasing the set duration recorded by the consensus node corresponding to the proposal node, if the consensus process initiated by the proposal node again meets the consensus requirements in the pre-voting stage, then the set duration recorded by the consensus node participating in the consensus process corresponding to the proposal node will be decreased.

5. The consensus method for blockchain according to any one of claims 1 to 3, characterized in that, Based on the number of the first pre-voting messages, the set duration recorded by the consensus node corresponding to the proposal node is adjusted, including: If the number of the first pre-voting messages is greater than or equal to the consensus quantity requirement of the pre-voting stage, then the set duration recorded by the consensus nodes participating in the consensus process corresponding to the proposal node remains unchanged, or the set duration recorded by the consensus nodes participating in the consensus process corresponding to the proposal node is reduced until the set minimum value is reached.

6. The consensus method for blockchain according to claim 1, characterized in that, The method further includes: Count the number of times each consensus node encounters anomalies during the consensus process; If the number of consecutive anomalies of a specified consensus node reaches a set number, a first transaction message of configuration type is generated. The first transaction message is used to indicate the cancellation of the specified consensus node from participating in the consensus process. The first block is generated based on the first transaction information; Generate a proposal message for the first block and broadcast the proposal message for the first block to other consensus nodes in the blockchain network.

7. The consensus method for blockchain according to claim 6, characterized in that, The proposal message of the first block contains type information of the proposal message and identification information of the designated consensus node. The type information of the proposal message is configured to indicate that the proposal message of the first block is used to cancel the participation of the designated consensus node in the consensus process.

8. The consensus method for blockchain according to claim 6, characterized in that, The method further includes: If the first block reaches a consensus in the blockchain network, then the designated consensus node is determined to no longer participate in the consensus process of the blockchain network.

9. The consensus method for blockchain according to claim 1, characterized in that, The method further includes: Count the number of times each consensus node encounters anomalies during the consensus process; If the number of consecutive anomalies of a specified consensus node reaches a set number, a second transaction information of configuration type is generated. The second transaction information is used to instruct the alternative node corresponding to the specified consensus node to participate in the consensus process in place of the specified consensus node. A second block is generated based on the second transaction information; Generate a proposal message for the second block and broadcast the proposal message for the second block to other consensus nodes in the blockchain network and the backup nodes of the designated consensus node.

10. The consensus method for blockchain according to claim 9, characterized in that, The proposal message of the second block contains type information of the proposal message and identification information of the alternative node corresponding to the specified consensus node. The type information of the proposal message is configured to indicate that the proposal message of the second block is used to replace the specified consensus node in the consensus process by the alternative node corresponding to the specified consensus node.

11. The consensus method for blockchain according to claim 9, characterized in that, The method further includes: If the second block reaches a consensus in the blockchain network, then it is determined that the designated consensus node will no longer participate in the consensus process of the blockchain network; Send a pre-commit voting message for the second block to the candidate node corresponding to the designated consensus node, so that after the candidate node receives the pre-commit voting message and reaches the consensus quantity requirement of the pre-commit phase, it can replace the designated consensus node in the consensus process.

12. The consensus method for blockchain according to any one of claims 6 to 11, characterized in that, The method further includes: After each consensus node initiates a proposal message for the proposal block as a proposal node, the number of pre-vote messages received for the proposal block is counted. If the received pre-voting messages for the proposed block do not meet the consensus quantity requirements of the pre-voting phase, it is determined that the consensus node that initiated the proposal message for the proposed block has encountered an anomaly.

13. A consensus device for blockchain, characterized in that, include: The receiving unit is configured to receive pre-voting messages sent by consensus nodes in the blockchain network during the consensus process initiated by the proposing node for the block to be reached; The pre-voting message includes a first preset voting message and a second pre-voting message. The first pre-voting message is generated by the consensus node for the block to be reached after receiving and verifying the proposal message of the block to be reached within a set time period. The second preset voting message is generated by the consensus node for an empty block after failing to receive the proposal message within the set time period. The set time period corresponds to the proposal node and is determined based on the block production time of the proposal node. The consensus node records the set time period corresponding to each proposal node. The statistics unit is configured to count the number of first pre-voting messages for the block to be reached based on the received pre-voting messages; The adjustment unit is configured to adjust the set duration recorded by the consensus node corresponding to the proposal node based on the number of the first pre-voting messages; The step of adjusting the set duration recorded by the consensus node corresponding to the proposal node based on the number of the first pre-voting messages includes: If the number of the first pre-voting messages is less than the consensus requirement for the pre-voting phase, and the number of the second pre-voting messages received for empty blocks is less than the consensus requirement, then the set duration recorded by the consensus node that sent the second pre-voting message, corresponding to the proposal node, will be increased.

14. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the consensus method of the blockchain as described in any one of claims 1 to 12.

15. An electronic device, characterized in that, include: One or more processors; A memory for storing one or more computer programs that, when executed by one or more processors, cause the electronic device to implement the consensus method of a blockchain as described in any one of claims 1 to 12.

16. A computer program product, characterized in that, The computer program product includes a computer program stored in a computer-readable storage medium, and the processor of an electronic device reads from and executes the computer program, causing the electronic device to perform the consensus method of the blockchain as described in any one of claims 1 to 12.

Images