Blockchain consensus method, device, computer-readable medium, and electronic device

Abstract

Embodiments of the present application provide a blockchain consensus method, apparatus, computer-readable medium, and electronic device. The blockchain consensus method includes: receiving voting messages from consensus nodes in a blockchain network for a target block to be reached; based on the chain relationship between blocks, using the voting messages for the target block as voting messages for the target block and the blocks to be reached that precede the target block; based on the voting messages for each block to be reached, counting the voting results of each block to be reached; and performing consensus processing based on the voting results of each block to be reached. The technical solutions of the embodiments of the present application can accelerate the consensus of blocks and effectively improve the consensus efficiency of blocks.

Description

Technical Field

[0001] The present application relates to the field of computer and communication technology, and more specifically, to a blockchain consensus method, device, computer-readable medium, and electronic device. Background Art

[0002] Blockchain technology is widely used in finance, credit reporting, banking and other fields. Consensus algorithms such as BFT (Byzantine Fault Tolerance) proposed for blockchain technology are serial consensus algorithms. Each block needs to go through three stages: proposal, pre-voting, and pre-submission, resulting in low consensus efficiency. Summary of the Invention

[0003] The embodiments of the present application provide a blockchain consensus method, apparatus, computer-readable medium, and electronic device, which can improve the consensus efficiency of blocks at least to a certain extent.

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

[0005] According to one aspect of an embodiment of the present application, a blockchain consensus method is provided, comprising: receiving voting messages from consensus nodes in a blockchain network for a target block to be agreed upon; based on a chain relationship between blocks, using the voting messages for the target block as voting messages for the target block and blocks to be agreed upon that are located before the target block; counting voting results for each block to be agreed upon based on the voting messages for each block to be agreed upon; and performing consensus processing based on the voting results for each block to be agreed upon.

[0006] According to one aspect of an embodiment of the present application, a blockchain consensus device is provided, comprising: a receiving unit configured to receive voting messages from consensus nodes in a blockchain network for a target block to be agreed upon; a first processing unit configured to, based on a chain relationship between blocks, use the voting messages for the target block as voting messages for the target block and a block to be agreed upon that is located before the target block; a counting unit configured to count voting results for each block to be agreed upon based on the voting messages for each block to be agreed upon; and a second processing unit configured to perform consensus processing based on the voting results of each block to be agreed upon.

[0007] In some embodiments of the present application, based on the aforementioned solution, the second processing unit is further configured to: if consensus on the designated block is successful, write the designated block and the block before the designated block into the blockchain ledger.

[0008] In some embodiments of the present application, based on the aforementioned scheme, the voting message includes a voting message in the pre-voting stage; the second processing unit is configured to: determine, based on the voting results of the respective blocks to be agreed upon, a first block whose number of votes meets the voting number requirement in the pre-voting stage; and broadcast the first block as a pre-submission block in the blockchain network to perform pre-submission processing on the pre-submission block.

[0009] In some embodiments of the present application, based on the aforementioned scheme, the second processing unit is configured as follows: if there is one block whose number of votes determined to meet the voting number requirements of the pre-voting stage, the determined block will be used as the first block; if there are multiple blocks whose number of votes determined to meet the voting number requirements of the pre-voting stage, the block with the highest block height among the multiple blocks determined will be used as the first block.

[0010] In some embodiments of the present application, based on the aforementioned scheme, the second processing unit is further configured to: after pre-submission processing is performed on the pre-submission block, receive voting messages from consensus nodes in the blockchain network for the pre-submission block; based on the chain relationship between blocks, use the voting messages for the pre-submission block as voting messages for the pre-submission block and the pre-submission blocks before the pre-submission block; based on the voting messages for each pre-submission block, count the voting results of each pre-submission block; and determine the blocks that can be written to the blockchain ledger based on the voting results of each pre-submission block.

[0011] In some embodiments of the present application, based on the aforementioned scheme, the second processing unit is configured to: determine, based on the voting results of each pre-submission block, a second block whose number of votes meets the voting number requirement of the pre-submission stage; and determine the second block and the block before the second block as blocks that can be written to the blockchain ledger.

[0012] In some embodiments of the present application, based on the aforementioned scheme, the second processing unit is configured as follows: if there is one block whose number of votes determines that meets the number of votes required in the pre-submission stage, then the determined block will be used as the second block; if there are multiple blocks whose number of votes determines that meets the number of votes required in the pre-submission stage, then the block with the highest block height among the multiple blocks determined will be used as the second block.

[0013] In some embodiments of the present application, based on the aforementioned scheme, the voting message includes a voting message in the pre-submission stage; the second processing unit is configured to: determine a second block whose number of votes meets the voting number requirement in the pre-submission stage based on the voting results of each block to be agreed upon; and write the second block and the block before the second block into the blockchain ledger.

[0014] In some embodiments of the present application, based on the aforementioned scheme, the second processing unit is configured as follows: if there is one block whose number of votes determines that meets the number of votes required in the pre-submission stage, then the determined block will be used as the second block; if there are multiple blocks whose number of votes determines that meets the number of votes required in the pre-submission stage, then the block with the highest block height among the multiple blocks determined will be used as the second block.

[0015] In some embodiments of the present application, based on the aforementioned scheme, the receiving unit is configured to: receive voting messages sent by each consensus node in the blockchain network for the highest block to be agreed upon that is maintained locally, where the highest block to be agreed upon is a block that is locally maintained by each consensus node and requires consensus and has the highest block height.

[0016] In some embodiments of the present application, based on the aforementioned solution, the consensus nodes in the blockchain network use the Byzantine Fault Tolerance BFT consensus algorithm to perform consensus processing on the consensus blocks.

[0017] According to one aspect of an embodiment of the present application, a computer-readable medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the consensus method of the blockchain as described in the above embodiment is implemented.

[0018] According to one aspect of an embodiment of the present application, an electronic device is provided, comprising: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the electronic device implements the blockchain consensus method as described in the above embodiments.

[0019] According to one aspect of an embodiment of the present application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to implement the blockchain consensus method provided in the various optional embodiments described above.

[0020] In the technical solutions provided in some embodiments of the present application, based on the chain relationship between blocks, the voting message for the target block is used as the voting message for the target block and the block to be agreed upon that is before the target block. Then, based on the voting message for each block to be agreed upon, the voting results of each block to be agreed upon are counted, and consensus processing is performed based on the voting results of each block to be agreed upon. This allows the chain structure of the blockchain to be introduced into the consensus process. In each round of the consensus process, the votes for a certain block are extended to the previous block of the block, thereby accelerating the consensus of the block and effectively improving the consensus efficiency of the block.

[0021] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The accompanying drawings are incorporated into and constitute a part of the specification, illustrating embodiments consistent with the present application and, together with the specification, explaining the principles of the present application. Obviously, the drawings described below are only some embodiments of the present application, and those skilled in the art can derive other drawings based on these drawings without inventive effort. In the drawings:

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

[0024] Figure 2 A schematic diagram showing the connection relationship between blocks in the blockchain;

[0025] Figure 3 A schematic diagram showing a consensus node broadcasting a block according to an embodiment of the present application is shown;

[0026] Figure 4 A schematic diagram of the structure of a blockchain network is shown;

[0027] Figure 5 A flowchart of a consensus method for a blockchain according to an embodiment of the present application is shown;

[0028] Figure 6 A schematic diagram of a local block of a consensus node according to an embodiment of the present application is shown;

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

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

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

[0032] Figure 10 A block diagram of a consensus device for a blockchain according to an embodiment of the present application is shown;

[0033] Figure 11 A schematic diagram of the structure of a computer system suitable for implementing an electronic device according to an embodiment of the present application is shown. DETAILED DESCRIPTION

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

[0035] In addition, the features, structures or characteristics described in the present application may be combined in one or more embodiments in any suitable manner. In the following description, there are many specific details so that the embodiments of the present application can be fully understood. However, it will be appreciated by those skilled in the art that when implementing the technical solution of the present application, it is not necessary to use all the detailed features in the embodiments, one or more specific details may be omitted, or other methods, elements, devices, steps, etc. may be adopted.

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

[0037] The flowcharts shown in the accompanying drawings are for illustrative purposes only and do not necessarily include all contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps may be decomposed, while others may be combined or partially combined. Therefore, the actual execution order may vary depending on the actual situation.

[0038] It should be noted that the term "plurality" used in this document refers to two or more. "And / or" describes a relationship between associated objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A alone, A and B together, or B alone. The character " / " generally indicates an "or" relationship between the associated objects.

[0039] The technical solutions of the embodiments of this application involve blockchain technology. Blockchain is a novel application model for computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Blockchain is essentially a decentralized database, a series of data blocks (i.e., blocks) generated using cryptographic methods. Each data block contains information about a batch of network transactions, which is used to verify the validity of the information (for anti-counterfeiting) and generate the next block. Blockchain can include an underlying blockchain platform, a platform product service layer, and an application service layer.

[0040] The underlying blockchain platform can include processing modules such as user management, basic services, smart contracts, and operation monitoring. Among them, the user management module is responsible for the identity information management of all blockchain participants, including maintaining public and private key generation (account management), key management, and maintaining the corresponding relationship between the user's real identity and the blockchain address (authority management), etc., and under authorization, it supervises and audits the transactions of certain real identities and provides risk control rule configuration (risk control audit); the basic service module is deployed on all blockchain node devices to verify the validity of business requests, and records the valid requests to the storage after consensus is reached. For a new business request, the basic service first adapts the interface to parse and authenticate the request (interface adaptation), and then encrypts the business information through the consensus algorithm (consensus management). The smart contract module is responsible for the registration, issuance, triggering and execution of contracts. Developers can define the contract logic in a programming language and publish it to the blockchain (contract registration). According to the logic of the contract terms, the contract logic is triggered by calling keys or other events to trigger execution. The contract logic is completed, and the contract upgrade and cancellation functions are also provided. The operation monitoring module is mainly responsible for the deployment, configuration modification, contract setting, cloud adaptation and real-time status visualization output of the product during the product release process, such as alarms, network status monitoring, and node device health monitoring.

[0041] The platform's product service layer provides the basic capabilities and implementation framework for typical applications. Developers can build on these basic capabilities, overlay business features, and complete the blockchain implementation of business logic. The application service layer provides application services based on blockchain solutions for business participants to use.

[0042] As mentioned above, blockchain is essentially a decentralized database, and the blockchain is maintained by the nodes in the blockchain network. Figure 1The blockchain network shown may include multiple nodes 101, each of which may be the individual clients forming the blockchain network. Each node 101 may receive input information during normal operation and, based on the received input information, maintain shared data within the blockchain network. To ensure information interoperability within the blockchain network, information connections may exist between each node in the blockchain network, enabling information transmission between nodes via these connections. For example, when any node in the blockchain network receives input information, the other nodes in the blockchain network obtain the input information according to a consensus algorithm and store it as shared data, ensuring that the data stored on all nodes in the blockchain network is consistent.

[0043] Each node in a blockchain network has a corresponding node identifier, and each node in the blockchain network can store the node identifiers of other nodes so that it can subsequently broadcast generated blocks to other nodes in the blockchain network based on the node identifiers of other nodes. Each node can maintain a node identifier list, storing the node name and node identifier in the node identifier list. The node identifier can be an IP (Internet Protocol, a protocol for interconnecting networks) address or any other information that can be used to identify the node.

[0044] Each node in the blockchain network stores the same blockchain. The blockchain consists of multiple blocks, see Figure 2 As shown in Figure 1, a blockchain consists of multiple blocks, linked together in ascending order of creation timestamps. Each block consists of a header and a body. The header stores the hash of the previous block and the Merkle root of the current block, while the body contains the complete transaction data for the block, organized in the form of a Merkle tree. The blockchain structure shows that the data stored in each block is linked to the data stored in the parent block (i.e., the previous block), ensuring the security of the information entered into the block.

[0045] Each node in the blockchain network can be a server or a terminal device. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. The terminal device can be a smartphone, tablet computer, laptop computer, desktop computer, smart speaker, smart watch, smart home, car terminal, etc., but is not limited to these. The nodes can be directly or indirectly connected through wired or wireless communication, which is not limited in this application.

[0046] It's important to note that Merkle trees are a crucial component of blockchain technology. Blockchains don't directly store raw plaintext data; instead, raw data is hashed and stored as hash values. Merkle trees organize the hash values ​​of multiple raw data into a binary tree structure and store them in the block body.

[0047] Another key technology in blockchain technology is the consensus mechanism, which is fundamental to the proper functioning of blockchain systems. Consensus means reaching agreement. Each node in a blockchain system stores a copy of the distributed ledger (the blockchain). The consensus process is the process of maintaining consistency across all nodes. All or some of the nodes in a blockchain system can participate in the consensus process, which is typically based on a consensus algorithm. Each participating node executes the consensus algorithm to execute the corresponding steps. Optional consensus algorithms include Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof of Stake (DPoS), and Practical Byzantine Fault Tolerance (PBFT).

[0048] Typically, a block height in a blockchain requires one or more consensus rounds to reach agreement among participating nodes. Block height represents the number of blocks connected to the blockchain. It serves as a block identifier, indicating a block's position within the blockchain. For example, the genesis block in a blockchain has a default block height of 0. The first block after the genesis block has a block height of 1 (referred to as block 1). The second block after the genesis block has a block height of 2 (referred to as block 2), and so on.

[0049] For example, the current block of a blockchain has a block height of 300 (referred to as block 300). This means that 300 blocks have already been stacked on top of the genesis block, meaning that the number of blocks in the blockchain from the genesis block to block 300 is 301. The consensus process at a specific block height in a blockchain refers to the process of reaching consensus on the blocks to be added to the blockchain system at that block height. If consensus on the block to be added is successful, the block is added to the blockchain, and the block height of the blockchain is increased by 1. For example, the consensus process at block height 10 in a blockchain refers to the process of reaching consensus on the blocks to be added to the blockchain system at block height 10. If consensus on the block is successful, the block is added to the blockchain, increasing the block height from 10 to 11.

[0050] Generally speaking, a consensus round can be divided into three phases, in descending order: the proposal phase, the pre-voting phase, and the pre-commit phase. The multiple nodes participating in a consensus round include two types: proposing nodes and non-proposing nodes. A proposing node is a node elected by the participating nodes. As a proposing node, it is responsible for generating blocks to be agreed upon during the proposal phase of the consensus round and broadcasting these blocks to other participating nodes for consensus processing. It also handles consensus processing on these blocks. Non-proposing nodes, on the other hand, only process consensus on blocks to be agreed upon.

[0051] Consensus processing consists of 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 pre-voting on the block to be agreed upon. Agreeing to pre-vote on the block to be agreed upon indicates agreement to add the block to the blockchain. Pre-committing refers to the process of pre-committing the block to be agreed upon. Agreeing to pre-commit the block to be agreed upon indicates confirmation of agreement to add the block to the blockchain. During multiple rounds of consensus at the same block height, the nodes participating in each round may vary. This means that the nodes participating in each round may change, the proposing nodes may change, and the blocks to be agreed upon may also change.

[0052] The following is a detailed description of the specific process of the consensus process in the Ni-th round of the blockchain block height H according to an embodiment of the present application using a specific example, where H, N, and i are all positive integers, and i is less than N. Taking i=1 as an example, in the consensus process in the N-1th round of the blockchain block height H, there are a total of 4 node devices participating in the consensus process. Figure 3 FIG. 1 shows a block broadcast diagram of a consensus node according to an embodiment of the present application; FIG. Figure 3 As shown in the figure, 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 round of consensus at block height H of the blockchain, node device B is the proposing node, and node devices A, node device C, and node device D are non-proposing nodes. The specific process of the N-1 round of consensus at block height H of the blockchain includes:

[0053] 1. Proposal Stage:

[0054] First, node device B (i.e., the proposal node) generates a target block Block-X to be agreed upon. Block-X can be a new block created by node device B. Node device B then broadcasts target block Block-X to node devices A, C, and D.

[0055] 2. Pre-voting stage:

[0056] Due to network failure, device failure or other reasons, some node devices may not be able to receive Block-X broadcast by node device B in the first time. For example, if node device A does not receive Block-X broadcast by node device B in the first time, and node device C and node device D both receive Block-X broadcast by node device B in the first time; then in the pre-voting stage, node device B, node C and node device D all use Block-X as the target block to be agreed upon, and pre-vote Block-X to obtain their respective pre-voting information. The pre-voting information here includes the block identifier of the block on which the pre-voting process is performed. For example, node device C pre-votes Block-X to generate the pre-voting information of node device C. The pre-voting information of node device C includes the identifier of Block-X, and the pre-voting information indicates that node device C agrees to pre-vote Block-X, that is, agrees to add Block-X to the blockchain, and Block-X obtains the pre-vote of node device C.

[0057] It is understandable that if node device C does not generate pre-voting information for node device C, it means that node device C has not pre-voted for Block-X; if the pre-voting information for node device C does not include the identifier of Block-X, it means that node device C does not agree to pre-vote for Block-X, that is, it does not agree to add Block-X to the blockchain. Since node device A did not receive Block-X in the first time, it can determine the empty block emptyBlock as the target block to be agreed upon, and pre-vote for emptyBlock to obtain the pre-voting information of node device A, and the pre-voting information of node device A includes the identifier of emptyBlock. The first time can be set according to actual needs, for example, 1 minute, 3 minutes, etc.

[0058] Node device A, node device B, node device C, and node device D each broadcast their own pre-voting information. Due to network failure, device failure, or other reasons, some node devices may not receive the pre-voting information broadcast by other node devices within 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 consensus in the pre-voting stage based on the pre-voting information received within the second time, and confirms whether the number of pre-votes exceeds the quantity threshold. The quantity threshold here can be set according to actual conditions. For example, the quantity threshold can be 50% of the number of node devices participating in the consensus process, or 2 / 3 of the number of node devices participating in the consensus process. The second time here can also be set according to actual needs, such as 1 minute, 3 minutes, etc.; the second time can be the same as the first time, or different from the first time.

[0059] For example, assume the number threshold is 2. Since node A only pre-votes for emptyBlock, node A's pre-voting information includes the emptyBlock identifier. Nodes B, C, and D all pre-vote for Block-X, and their pre-voting information includes the Block-X identifier. Assume that node A only receives pre-voting information from node B. Combined with node A's own pre-voting information, the number of pre-votes obtained by Block-X during the pre-voting phase is 1, confirming that the number of pre-votes obtained by Block-X does not exceed the number threshold of 2. Assume that node B receives pre-voting information from nodes A, C, and D. Combined with node B's own pre-voting information, the number of pre-votes obtained by Block-X is 3, confirming that the number of pre-votes obtained by Block-X exceeds the number threshold of 2. Similarly, suppose node C receives three pre-voting messages from node A, node B, and node D. Combined with node C's own pre-voting information, the calculated number of pre-votes obtained by Block-X is 3, confirming that the number of pre-votes obtained by Block-X exceeds the threshold of 2. Suppose node D also receives three pre-voting messages from node A, node B, and node C. Combined with node D's own pre-voting information, the calculated number of pre-votes obtained by Block-X is 3, confirming that the number of pre-votes obtained by Block-X exceeds the threshold of 2.

[0060] 3. Pre-submission stage:

[0061] Node devices B, C, and D all identify Block-X as the target block to be agreed upon, and therefore perform a pre-commit process on Block-X to obtain their respective pre-commit information. This pre-commit information includes the identifier of the block on which the pre-commit process is performed. For example, node device C performs a pre-commit process on Block-X to generate node device C's pre-commit information. This pre-commit information includes the identifier of Block-X, and indicates that node device C agrees to pre-commit Block-X, thereby confirming its agreement to add Block-X to the blockchain. Block-X then receives node device C's pre-commit.

[0062] It is understandable that if node device C does not generate node device C's pre-commit information, it means that node device C has not pre-committed Block-X; if node device C's pre-commit information 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. However, since node device A determines the empty block emptyBlock as the target block to be agreed upon, node device A pre-commits emptyBlock and obtains node device A's pre-commit information, which includes the identifier of emptyBlock.

[0063] Node device A, node device B, node device C, and node device D each broadcast their own pre-commit information. Due to network failure, device failure, or other reasons, some node devices may not receive the pre-commit information broadcast by other node devices within the third time. When the third time arrives, each node device participating in the consensus process counts the number of pre-commits obtained in the pre-commit phase of the target block to be agreed upon based on the pre-commit information received within the third time, and confirms whether the number of pre-commits exceeds the commit threshold. The commit threshold here can be set according to actual conditions. For example, the commit threshold can be 50% of the number of node devices participating in the consensus process, or 2 / 3 of the number of node devices participating in the consensus process. The third time here can also be set according to actual needs, for example, 1 minute, 3 minutes, etc.; the third time can be the same as or different from the second time; similarly, the third time can be the same as or different from the first time.

[0064] For example, assume the commit threshold is 2. Since node A only pre-commits emptyBlock, node A's pre-commit information includes the emptyBlock identifier. Nodes B, C, and D all pre-commit Block-X, and their pre-commit information also includes the Block-X identifier. Assume that node B receives pre-commit information from nodes A and C, and combines it with its own pre-commit information to determine that the number of pre-commits Block-X has received during the pre-commit phase is 2, confirming that the number of pre-commits Block-X has received does not exceed (is not greater than) the commit threshold of 2. Assume that node C receives pre-commit information from nodes A and C, and combines it with its own pre-commit information to determine that the number of pre-commits Block-X has received is also 2, confirming that the number of pre-commits Block-X has received does not exceed (is not greater than) the commit threshold of 2. Similarly, suppose node A receives three pre-commit messages from node B, node C, and node D. Combined with node A's own pre-commit information, the pre-commit count for 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 messages from node A, node B, and node C. Combined with node D's own pre-commit information, the pre-commit count for Block-X is 3, confirming that Block-X's pre-commit count exceeds the commit threshold of 2.

[0065] After the three consensus phases, if the target block to be agreed upon receives more pre-votes than the threshold and more pre-commits than the commit threshold, consensus on the target block is successful and the block can be added to the blockchain. Otherwise, consensus fails and the block cannot be added to the blockchain. In the example above, node A confirms that the pre-commits for Block-X exceed the commit threshold, but the pre-votes do not. Therefore, consensus on Block-X fails. Node B confirms that the pre-votes for Block-X exceed the threshold, but the pre-commits do not. Therefore, consensus on Block-X fails. Node C confirms that the pre-votes for Block-X exceed the threshold, but the pre-commits do not. Therefore, consensus on Block-X fails. Node D confirms that the pre-votes for Block-X exceed the threshold, but the pre-commits do not. Therefore, consensus on Block-X fails.

[0066] To summarize, during the N-1 round of consensus for a block height of H on 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 locally stored blockchains). However, node device D reached a consensus on Block-X and wrote Block-X into its own distributed ledger. Then, the block height of the blockchain locally stored by node device D becomes H+1. During the N-1 round of consensus for a block height of H on the blockchain, node device D will no longer participate in the consensus, and the node devices participating in the consensus will be changed to node devices A, B, and C.

[0067] It should be noted that during the Nth round of consensus at block height H of the blockchain, the proposal node may change. For example, in the above example, the proposal node during the N-1th round of consensus at block height H of the blockchain is node B, but during the Nth round of consensus at block height H of the blockchain, it may be changed to node C. The above three consensus stages are then re-executed to complete the Nth round of consensus at block height H of the blockchain.

[0068] From the above consensus mechanism, it can be seen that each block needs to go through three stages: proposal, pre-voting, and pre-submission, resulting in low consensus efficiency. In order to improve consensus efficiency and speed up block generation, the embodiment of this application proposes to integrate the chain structure characteristics of the blockchain into the consensus algorithm. Specifically, Figure 4 As shown in the figure, a blockchain network with five consensus nodes is used as an example for explanation. For any consensus node, when it receives a voting message for a target block to be agreed upon from a consensus node in the blockchain network, it can use the voting message for the target block as the voting message for the target block and the previous consensus block based on the chain relationship between blocks. Then, based on the voting messages for each consensus block, it calculates the voting results for each consensus block and then performs consensus processing based on the voting results of each consensus block.

[0069] For example, consensus node 1 has 6 blocks to be agreed upon locally (recorded as block 1, block 2, block 3, block 4, block 5 and block 6 in chronological order). Assume that in the pre-voting stage, consensus node 1 receives 1 vote for block 3, 2 votes for block 4, and 1 vote for block 5. Then, when counting the votes in the pre-voting stage, block 3 has 4 votes, block 4 has 3 votes, and block 5 has 1 vote. If the number of votes in the pre-voting stage is agreed by more than 2 / 3 of the consensus nodes, then only block 3 meets the condition, and block 3 can be broadcast as a pre-committed block.

[0070] Similarly, in the pre-submission phase, assuming that consensus node 1 receives 2 votes for block 3, 2 votes for block 4, and 2 votes for block 5, then when counting the votes in the pre-submission phase, block 3 has 6 votes, block 4 has 4 votes, and block 5 has 2 votes. If the number of votes in the pre-submission phase is that more than 2 / 3 of the consensus nodes agree, then both block 3 and block 4 meet the condition. At this time, since the block height of block 4 is higher than the block height of block 3, block 4 and the blocks before block 4 (i.e., block 1, block 2, and block 3) can be written into the blockchain account book at the same time. It can be seen that the technical solution of the embodiment of the present application can accelerate the consensus of blocks and effectively improve the consensus efficiency of blocks.

[0071] The following describes in detail the various implementation details of the technical solutions of the embodiments of the present application:

[0072] Figure 5 A flowchart of a consensus method for a blockchain according to an embodiment of the present application is shown, which can be executed by a consensus node. Specifically, referring to Figure 5 As shown, the consensus method of the blockchain includes at least steps S510 to S540, which are described in detail as follows:

[0073] In step S510, a voting message for a target block to be agreed upon is received from a consensus node in the blockchain network.

[0074] Optionally, the voting message can be a voting message in the pre-voting phase, or a voting message in the pre-submission phase. Of course, in some embodiments of the present application, the voting message can be both a voting message in the pre-voting phase and a voting message in the pre-submission phase, that is, the voting message can be used for both the pre-voting phase and the pre-submission phase. Figure 5 The technical solution of the embodiment shown.

[0075] Since in an embodiment of the present application, the voting message for a block can be extended to the blocks before the block, each consensus node in the blockchain network can vote for the highest block to be agreed upon maintained locally and send a voting message. The highest block to be agreed upon can be the block with the highest block height that is required for consensus and maintained locally by each consensus node.

[0076] Optionally, the consensus nodes in the blockchain network can use the Byzantine Fault Tolerance (BFT) consensus algorithm to perform consensus processing on the consensus block. Of course, in some embodiments of the present application, other consensus algorithms can also be used to perform consensus processing.

[0077] In step S520, based on the chain relationship between blocks, the voting message for the target block is used as the voting message for the target block and the block to be agreed upon that is located before the target block.

[0078] In one embodiment of the present application, since each block in the blockchain contains the hash information of the previous block, once a block is voted on, the preceding blocks are also considered to be determined, based on the chain structure of the blockchain, and so on until the genesis block. Therefore, when voting, voting for a block can also be extended to voting for the blocks before it.

[0079] Specifically, assuming that a consensus node maintains a blockchain structure such as Figure 6 As shown in the figure, it receives blocks A, B, C, and D, and forks at block D. One fork is E1, F1, and G1, and the other is E2, F2, and G2. If the consensus node receives 1 vote for block D, 1 vote for block E1, and 1 vote for block F2, then when counting the votes, block D will receive 3 votes (that is, the votes for blocks E1 and F2 are also counted as the votes for block D).

[0080] In step S530, based on the voting messages for each block to be agreed upon, the voting results of each block to be agreed upon are counted.

[0081] In step S540 , consensus processing is performed based on the voting results of each block to be consensus.

[0082] In one embodiment of the present application, as previously described, since each block in the blockchain contains the hash information of the previous block, once a block is voted on, the preceding blocks are also considered to be finalized, based on the chain-like structure of the blockchain, and so on until the genesis block. Therefore, if consensus on a specific block is successful, the specified block and the blocks preceding it can be written into the blockchain ledger.

[0083] The following is a detailed explanation of the pre-voting stage and the pre-submission stage:

[0084] In one embodiment of the present application, Figure 5 The voting message in the embodiment shown may be a voting message in the pre-voting phase (hereinafter referred to as the pre-voting message for ease of description). In this case, Figure 5 Step S540 shown may be to determine the block that meets the voting quantity requirement of the pre-voting stage, and then broadcast the determined block as a pre-committed block. Figure 7 The blockchain consensus method shown in FIG. 1 may be executed by a consensus node and includes at least steps S710 to S750, which are described in detail below:

[0085] In step S710, a pre-voting message from a consensus node in the blockchain network is received for a target block to be agreed upon.

[0086] Since in an embodiment of the present application, the pre-voting message for a block can be extended to the blocks before the block, each consensus node in the blockchain network can vote for the highest block to be agreed upon that is maintained locally and send a pre-voting message. The highest block to be agreed upon can be a block with the highest block height that is required for consensus and that is maintained locally by each consensus node.

[0087] In step S720, based on the chain relationship between blocks, the pre-voting message for the target block is used as the pre-voting message for the target block and the block to be agreed upon that is located before the target block.

[0088] In one embodiment of the present application, since each block in the blockchain contains the hash information of the previous block, once a block is pre-voted and confirmed, the preceding blocks are also considered confirmed due to the chain-like structure of the blockchain, and so on until the genesis block. Therefore, during the pre-voting phase, pre-voting for a block can also be extended to pre-voting for blocks preceding it.

[0089] Specifically, assuming that a consensus node maintains a blockchain structure such as Figure 6 As shown in the figure, it received blocks A, B, C, and D, and forked at block D. One fork is E1, F1, and G1, and the other is E2, F2, and G2. If, during the pre-voting phase, the consensus node received 1 vote for block D, 1 vote for block E1, and 1 vote for block F2, then when counting the votes, block D would receive 3 votes (i.e., the votes for blocks E1 and F2 would also be counted as the votes for block D).

[0090] In step S730, based on the pre-voting messages for each block to be agreed upon, the voting results of each block to be agreed upon are counted.

[0091] In step S740, based on the voting results of each block to be agreed upon, the first block whose number of votes meets the voting number requirement of the pre-voting stage is determined.

[0092] In one embodiment of the present application, if the number of votes determined to satisfy the number of votes required in the pre-voting phase is one block, the determined block is used as the first block.

[0093] If there are multiple blocks whose number of votes meets the voting number requirement of the pre-voting stage, the block with the highest block height among the multiple blocks determined is used as the first block. This is because in the embodiment of the present application, the voting messages for a block (including the voting messages in the pre-voting stage and the voting messages in the pre-commitment stage) can be extended to the blocks before the block, so the consensus node can use the block with the highest block height among the multiple blocks determined as the first block for pre-commitment processing.

[0094] In step S750, the determined first block is broadcast as a pre-commit block in the blockchain network to perform pre-commitment processing on the pre-commitment block.

[0095] In one embodiment of the present application, after the pre-submission block is pre-submitted, a pre-submission voting process may be performed on the pre-submission block, and when the number of votes meets the number of votes required in the pre-submission stage, it is determined that the pre-submission block can be written into the blockchain ledger.

[0096] Of course, in the embodiment of the present application, the voting process in the pre-submission stage can also adopt a similar processing method to the pre-voting stage, specifically as follows Figure 8 As shown, after step S750, the following steps S810 to S840 may be further included:

[0097] In step S810, a voting message for a pre-committed block is received from a consensus node in the blockchain network.

[0098] Since in an embodiment of the present application, the voting message for a block in the pre-commitment stage can be extended to the blocks before the block, each consensus node in the blockchain network can vote for the highest block to be agreed upon maintained locally and send a voting message. The highest block to be agreed upon can be a block with the highest block height that is required for consensus and maintained locally by each consensus node.

[0099] In step S820, based on the chain relationship between blocks, the voting message for the pre-submitted block is used as the voting message for the pre-submitted block and the pre-submitted block before the pre-submitted block.

[0100] Similar to the pre-voting phase, the voting messages in the pre-commit phase can also be extended to the blocks before the pre-commit block.

[0101] In step S830, based on the voting messages for each pre-submitted block, the voting results of each pre-submitted block are counted.

[0102] In step S840, the blocks that can be written into the blockchain ledger are determined based on the voting results of each pre-submitted block.

[0103] Optionally, if the number of votes determined based on the voting results of the pre-submission block meets the voting number requirement of the pre-submission stage, then it can be determined that the pre-submission block can be written into the blockchain ledger.

[0104] In addition, since each block in the blockchain contains the hash information of the previous block, after a block is pre-voted and determined, according to the chain structure characteristics of the blockchain, the predecessor block of the block can also be understood as determined, and so on until the genesis block. Therefore, if a second block is determined based on the voting results of each pre-submission block whose number of votes meets the voting number requirements of the pre-submission stage, then the second block and the blocks before the second block can be determined as blocks that can be written into the blockchain ledger.

[0105] In one embodiment of the present application, if the determined block has a number of votes that meets the requirement of the number of votes in the pre-commitment phase, the determined block may be used as the second block.

[0106] If there are multiple blocks whose number of votes meets the voting number requirement in the pre-commit phase, the block with the highest block height among the multiple blocks determined can be used as the second block. This is because in the embodiments of the present application, the voting message for a block in the pre-commit phase can be extended to the blocks before the block, and after a block consensus is successful, the previous block of the block can also be understood as a consensus success. Therefore, the consensus node can use the block with the highest block height among the multiple blocks determined as the second block.

[0107] exist Figure 8 In the technical solution shown, voting messages in the pre-voting stage and the pre-commitment stage can be extended to the previous block, thereby speeding up the consensus process of the block and helping to improve the consensus efficiency of the blockchain.

[0108] In one embodiment of the present application, Figure 5 The voting message in the embodiment shown may be a voting message in the pre-submission phase (hereinafter referred to as the pre-submission voting message for ease of description). In this case, Figure 5 Step S540 shown may be to determine the block that meets the voting quantity requirement of the pre-submission phase, and then write the determined block and the block before the block into the blockchain ledger. Figure 9 The blockchain consensus method shown in FIG. 1 may be executed by a consensus node and includes at least steps S910 to S950, which are described in detail below:

[0109] In step S910, a pre-submission voting message for a target block to be agreed upon is received from a consensus node in the blockchain network.

[0110] Since in an embodiment of the present application, the pre-submission voting message for a block can be extended to the blocks before the block, each consensus node in the blockchain network can vote for the highest block to be agreed upon that is maintained locally and send a pre-submission voting message. The highest block to be agreed upon can be the block with the highest block height that is required for consensus and maintained locally by each consensus node.

[0111] In step S920, based on the chain relationship between blocks, the pre-commit voting message for the target block is used as the pre-commit voting message for the target block and the block to be agreed upon that is before the target block.

[0112] In one embodiment of the present application, since each block in the blockchain contains the hash information of the previous block, once a block is confirmed through pre-commit voting, the preceding blocks of that block are also considered confirmed due to the chain-like structure of the blockchain, and so on until the genesis block. Therefore, during the pre-commit phase, the pre-commit voting for a block can also be extended to pre-commit voting for blocks preceding it.

[0113] Specifically, assuming that a consensus node maintains a blockchain structure such as Figure 6 As shown in the figure, it receives blocks A, B, C, and D, and forks at block D. One fork is E1, F1, and G1, and the other is E2, F2, and G2. If, during the pre-commit phase, the consensus node receives 1 vote for block D, 1 vote for block E1, and 1 vote for block F2, then when counting the votes, block D will receive 3 votes (i.e., the votes for blocks E1 and F2 are also counted as the votes for block D).

[0114] In step S930, the voting results of each block to be agreed upon are counted based on the pre-submitted voting messages for each block to be agreed upon.

[0115] In step S940, based on the voting results of each block to be agreed upon, a second block is determined whose number of votes meets the voting number requirement of the pre-commitment stage.

[0116] In one embodiment of the present application, if the determined block has a number of votes that meets the requirement of the number of votes in the pre-commitment phase, the determined block may be used as the second block.

[0117] If there are multiple blocks whose number of votes meets the voting number requirement in the pre-commit phase, the block with the highest block height among the multiple blocks determined can be used as the second block. This is because in the embodiments of the present application, the voting message for a block in the pre-commit phase can be extended to the blocks before the block, and after a block consensus is successful, the previous block of the block can also be understood as a consensus success. Therefore, the consensus node can use the block with the highest block height among the multiple blocks determined as the second block.

[0118] In step S950, the second block and the block before the second block are written into the blockchain ledger.

[0119] exist Figure 9 In the technical solution shown, the voting messages in the pre-commitment phase can be extended to the previous block, which can also speed up the consensus process of the block and help improve the consensus efficiency of the blockchain.

[0120] The following combination Figure 6 , the technical solution of the embodiment of the present application is described in detail with a specific example:

[0121] In an embodiment of the present application, the blockchain chain structure can be integrated into the consensus process under the premise of the BFT algorithm. The blockchain consensus node votes on the highest block it considers valid. In each round of consensus, the votes at each stage will be passed to all predecessor blocks of the valid highest block according to the characteristics of the blockchain chain structure, and each consensus node can determine the highest block (i.e., the block with the highest block height) based on the state of the chain it maintains.

[0122] Specifically, suppose the consensus network includes 4 consensus nodes, and the state of the blockchain maintained locally by one consensus node is as follows: Figure 6 As shown, it received blocks A, B, C, and D, and forked at block D. One fork is E1, F1, and G1, and the other is E2, F2, and G2. Due to factors such as the network, the consensus votes received by each consensus node may be different. In this embodiment of the application, it is assumed that in the pre-voting stage, the consensus node received 1 vote for block C, 1 vote for block E2, and 1 vote for block F1. Then, according to the voting transfer principle in the embodiment of the application (that is, the vote for a block can be extended to the previous block of the block), block C received 3 votes, which meets the 2 / 3 condition required by BFT. Therefore, in the pre-commitment stage, the node will pre-commit block C and broadcast it.

[0123] Similarly, in the pre-commit phase, assuming that all consensus nodes have received 1 vote for block C, 2 votes for block E2, and 1 vote for block D, then according to the aforementioned voting transmission principle, the pre-committed vote counts for both block C and block D exceed 2 / 3 (4 votes for block C, 3 votes for block D). Since the block height of block D is higher than that of block C, block D can be regarded as the highest valid block. At the same time, blocks A, B, and C before block D are also valid. Therefore, in this round of consensus, all consensus nodes can write blocks A, B, C, and D into the blockchain ledger.

[0124] It can be seen that the technical solution of the embodiment of the present application incorporates the chain structure characteristics of the blockchain into the consensus process. Each round of consensus process can extend the voting for a block to the previous blocks of the block, which speeds up the block consensus speed and effectively improves the consensus efficiency.

[0125] The following describes an embodiment of the device of the present application, which can be used to implement the blockchain consensus method described in the above embodiments of the present application. For details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the blockchain consensus method described in the above embodiments of the present application.

[0126] Figure 10 A block diagram of a consensus device of a blockchain according to an embodiment of the present application is shown, and the consensus device of the blockchain can be set in a consensus node.

[0127] Reference Figure 10 As shown, the consensus device 1000 of the blockchain according to an embodiment of the present application includes: a receiving unit 1002, a first processing unit 1004, a statistical unit 1006 and a second processing unit 1008.

[0128] Among them, the receiving unit 1002 is configured to receive voting messages from consensus nodes in the blockchain network for the target block to be agreed upon; the first processing unit 1004 is configured to use the voting messages for the target block as voting messages for the target block and the block to be agreed upon that is before the target block based on the chain relationship between the blocks; the counting unit 1006 is configured to count the voting results of each block to be agreed upon based on the voting messages for each block to be agreed upon; and the second processing unit 1008 is configured to perform consensus processing based on the voting results of each block to be agreed upon.

[0129] In some embodiments of the present application, based on the aforementioned solution, the second processing unit 1008 is further configured to: if the consensus on the specified block is successful, write the specified block and the block before the specified block into the blockchain ledger.

[0130] In some embodiments of the present application, based on the aforementioned scheme, the voting message includes a voting message in the pre-voting stage; the second processing unit 1008 is configured to: determine, based on the voting results of the respective blocks to be agreed upon, a first block whose number of votes meets the voting number requirement in the pre-voting stage; and broadcast the first block as a pre-submission block in the blockchain network to perform pre-submission processing on the pre-submission block.

[0131] In some embodiments of the present application, based on the aforementioned scheme, the second processing unit 1008 is configured as follows: if there is one block whose number of votes determines that meets the number of votes required in the pre-voting stage, then the determined block is used as the first block; if there are multiple blocks whose number of votes determines that meets the number of votes required in the pre-voting stage, then the block with the highest block height among the multiple blocks determined is used as the first block.

[0132] In some embodiments of the present application, based on the aforementioned scheme, the second processing unit 1008 is further configured to: after performing pre-submission processing on the pre-submission block, receive voting messages from consensus nodes in the blockchain network for the pre-submission block; based on the chain relationship between blocks, use the voting messages for the pre-submission block as voting messages for the pre-submission block and the pre-submission blocks before the pre-submission block; based on the voting messages for each pre-submission block, count the voting results of each pre-submission block; and determine the blocks that can be written into the blockchain ledger based on the voting results of each pre-submission block.

[0133] In some embodiments of the present application, based on the aforementioned scheme, the second processing unit 1008 is configured to: determine, based on the voting results of each of the pre-submission blocks, a second block whose number of votes meets the voting number requirement of the pre-submission stage; and determine the second block and the block before the second block as blocks that can be written to the blockchain ledger.

[0134] In some embodiments of the present application, based on the aforementioned scheme, the second processing unit 1008 is configured as follows: if there is one block whose number of votes determines that meets the number of votes required in the pre-submission phase, then the determined block is used as the second block; if there are multiple blocks whose number of votes determines that meets the number of votes required in the pre-submission phase, then the block with the highest block height among the multiple blocks determined is used as the second block.

[0135] In some embodiments of the present application, based on the aforementioned solution, the voting message includes a voting message in the pre-submission stage; the second processing unit 1008 is configured to: determine, based on the voting results of the respective blocks to be agreed upon, a second block whose number of votes meets the voting number requirement in the pre-submission stage; and write the second block and the block before the second block into the blockchain ledger.

[0136] In some embodiments of the present application, based on the aforementioned scheme, the second processing unit 1008 is configured as follows: if there is one block whose number of votes determines that meets the number of votes required in the pre-submission phase, then the determined block is used as the second block; if there are multiple blocks whose number of votes determines that meets the number of votes required in the pre-submission phase, then the block with the highest block height among the multiple blocks determined is used as the second block.

[0137] In some embodiments of the present application, based on the aforementioned scheme, the receiving unit 1002 is configured to: receive voting messages sent by each consensus node in the blockchain network for the highest block to be agreed upon that is maintained locally, where the highest block to be agreed upon is a block that is locally maintained by each consensus node and requires consensus and has the highest block height.

[0138] In some embodiments of the present application, based on the aforementioned solution, the consensus nodes in the blockchain network use the Byzantine Fault Tolerance BFT consensus algorithm to perform consensus processing on the consensus blocks.

[0139] Figure 11 A schematic diagram of the structure of a computer system suitable for implementing an electronic device according to an embodiment of the present application is shown.

[0140] It should be noted that Figure 11 The computer system 1100 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0141] like Figure 11As shown, the computer system 1100 includes a central processing unit (CPU) 1101, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 1102 or the program loaded from the storage part 1108 into the random access memory (RAM) 1103, such as executing the method described in the above embodiment. Various programs and data required for system operation are also stored in the RAM 1103. The CPU 1101, ROM 1102 and RAM 1103 are connected to each other via a bus 1104. An input / output (I / O) interface 1105 is also connected to the bus 1104.

[0142] The following components are connected to the I / O interface 1105: an input section 1106 including a keyboard, a mouse, and the like; an output section 1107 including devices such as a cathode ray tube (CRT), a liquid crystal display (LCD), and a speaker; a storage section 1108 including a hard disk; and a communication section 1109 including a network interface card such as a LAN (Local Area Network) card or a modem. The communication section 1109 performs communication processing via a network such as the Internet. A drive 1110 is also connected to the I / O interface 1105 as needed. Removable media 1111, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the drive 1110 as needed, so that computer programs read from the removable media can be installed in the storage section 1108 as needed.

[0143] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a computer program for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 1109, and / or installed from a removable medium 1111. When the computer program is executed by the central processing unit (CPU) 1101, the various functions defined in the system of the present application are executed.

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

[0145] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. Among them, each box in the flowchart or block diagram can represent a module, program segment, or part of the code, and the above-mentioned module, program segment, or part of the code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0146] The units involved in the embodiments described in this application may be implemented by software or hardware, and the units described may also be set in a processor. In some cases, the names of these units do not constitute limitations on the units themselves.

[0147] As another aspect, the present application further provides a computer-readable medium, which may be included in the electronic device described in the above embodiments, or may exist independently without being incorporated into the electronic device. The computer-readable medium carries one or more programs, and when the one or more programs are executed by the electronic device, the electronic device implements the method described in the above embodiments.

[0148] It should be noted that, although several modules or units of the device for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiment of the application, the features and functions of two or more modules or units described above can be concretized in one module or unit. On the contrary, the features and functions of one module or unit described above can be further divided into multiple modules or units to be concretized.

[0149] Through the description of the above embodiments, it is easy for those skilled in the art to understand that the example embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solution according to the embodiments of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which can be a personal computer, a server, a touch terminal, or a network device, etc.) to execute the method according to the embodiments of the present application.

[0150] Those skilled in the art will readily conceive of other embodiments of the present application after considering the specification and practicing the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present application that follow the general principles of this application and include common knowledge or customary techniques in the art that are not disclosed herein.

[0151] It should be understood that the present application is not limited to the exact structures described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A consensus method for blockchain, characterized in that: include: Receive voting messages from consensus nodes in the blockchain network for the target block to be agreed upon; Based on the chain relationship between blocks, the voting message for the target block is used as the voting message for the target block and the consensus-pending block before the target block; According to the voting information for each block to be agreed upon, the voting results of each block to be agreed upon are counted; Perform consensus processing based on the voting results of each block to be agreed upon; The voting message includes the voting message in the pre-voting stage; consensus processing is performed according to the voting results of each block to be consensus, including: Determine, based on the voting results of each of the blocks to be agreed upon, the first block whose number of votes meets the voting number requirement of the pre-voting stage; Broadcasting the first block as a pre-commit block in the blockchain network to perform pre-commit processing on the pre-commit block; After pre-submission processing is performed on the pre-submission block, a voting message for the pre-submission block from a consensus node in the blockchain network is received; Based on the chain relationship between blocks, the voting message for the pre-submitted block is used as the voting message for the pre-submitted block and the pre-submitted block before the pre-submitted block; According to the voting messages for each pre-submitted block, counting the voting results of each pre-submitted block; The blocks that can be written into the blockchain account book are determined based on the voting results of the pre-submitted blocks.

2. The blockchain consensus method according to claim 1, characterized in that: The consensus method of the blockchain also includes: If the consensus on the specified block is successful, the specified block and the block before the specified block will be written into the blockchain account book.

3. The blockchain consensus method according to claim 1, characterized in that: Determining the first block whose number of votes meets the voting number requirement of the pre-voting stage based on the voting results of each block to be agreed upon, including: If the number of votes determined to satisfy the voting requirement in the pre-voting phase is one, the determined block is used as the first block; If there are multiple blocks whose number of votes meets the voting number requirement in the pre-voting stage, the block with the highest block height among the multiple blocks determined will be used as the first block.

4. The blockchain consensus method according to claim 1, characterized in that: The blocks that can be written into the blockchain ledger are determined based on the voting results of the pre-committed blocks, including: Determining, based on the voting results of each pre-submission block, a second block whose number of votes meets the voting number requirement of the pre-submission stage; The second block and a block preceding the second block are determined as blocks that can be written into the blockchain ledger.

5. The blockchain consensus method according to claim 4, characterized in that: Determining, based on the voting results of each pre-committed block, a second block whose number of votes meets the voting number requirement of the pre-committed stage, includes: If the number of votes determined to satisfy the pre-submission phase voting requirement is one, the determined block is used as the second block; If there are multiple blocks whose number of votes meets the voting number requirement in the pre-commitment phase, the block with the highest block height among the multiple blocks determined will be used as the second block.

6. The blockchain consensus method according to claim 1, characterized in that: The voting message includes a voting message in the pre-submission phase; Consensus processing is performed based on the voting results of each block to be agreed upon, including: Determine, based on the voting results of each of the blocks to be agreed upon, a second block whose number of votes meets the voting number requirement of the pre-commitment phase; The second block and the block before the second block are written into the blockchain ledger.

7. The blockchain consensus method according to claim 6, characterized in that: Determining, based on the voting results of each of the blocks to be agreed upon, a second block whose number of votes meets the voting number requirement in the pre-commitment phase, including: If the number of votes determined to satisfy the pre-submission phase voting requirement is one, the determined block is used as the second block; If there are multiple blocks whose number of votes meets the voting number requirement in the pre-commitment phase, the block with the highest block height among the multiple blocks determined will be used as the second block.

8. The blockchain consensus method according to any one of claims 1 to 7, characterized in that: Receive voting messages from consensus nodes in the blockchain network for the target block to be agreed upon, including: Receive voting messages sent by each consensus node in the blockchain network for the highest block to be agreed upon maintained locally, where the highest block to be agreed upon is a block with the highest block height that is locally maintained by each consensus node and requires consensus.

9. The blockchain consensus method according to any one of claims 1 to 7, characterized in that: The consensus nodes in the blockchain network use the Byzantine Fault Tolerance (BFT) consensus algorithm to process consensus blocks.

10. A consensus device for blockchain, characterized in that: include: A receiving unit configured to receive voting messages from consensus nodes in the blockchain network for a target block to be agreed upon; a first processing unit configured to, based on a chain relationship between blocks, use the voting message for the target block as a voting message for the target block and a block to be agreed upon that precedes the target block; a statistics unit configured to count the voting results of each block to be consensus based on the voting messages for the block to be consensus; A second processing unit is configured to perform consensus processing according to the voting results of each block to be consensus; The voting message includes a voting message in a pre-voting phase; and the second processing unit is configured to: Determine, based on the voting results of each of the blocks to be agreed upon, the first block whose number of votes meets the voting number requirement of the pre-voting stage; Broadcasting the first block as a pre-commit block in the blockchain network to perform pre-commit processing on the pre-commit block; After pre-submission processing is performed on the pre-submission block, a voting message for the pre-submission block from a consensus node in the blockchain network is received; Based on the chain relationship between blocks, the voting message for the pre-submitted block is used as the voting message for the pre-submitted block and the pre-submitted block before the pre-submitted block; According to the voting messages for each pre-submitted block, counting the voting results of each pre-submitted block; The blocks that can be written into the blockchain account book are determined based on the voting results of the pre-submitted blocks.

11. A computer-readable medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the consensus method of the blockchain according to any one of claims 1 to 9 is implemented.

12. An electronic device, characterized in that: include: one or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, enables the electronic device to implement the consensus method of the blockchain as described in any one of claims 1 to 9.

13. A computer program product, characterized in that The computer program product includes computer instructions, which are stored in a computer-readable storage medium. A processor of a computer device reads and executes the computer instructions from the computer-readable storage medium, so that the computer device executes the consensus method of the blockchain according to any one of claims 1 to 9.

Images