Consensus voting processing method, device, apparatus, and medium for blockchain system

Abstract

Embodiments of the present application provide a consensus voting processing method and device of a blockchain system, equipment and a medium. The method comprises: receiving pre-vote information of a to-be-consensed block i in a to-be-consensed blockchain; if the pre-vote information of the to-be-consensed block i is not contained in a voting mapping table of a target node device, determining an insertion position of the to-be-consensed block i in the voting mapping table according to a chain position relationship in the to-be-consensed blockchain between the to-be-consensed block i and the pre-vote information belonging to a to-be-consensed block in the voting mapping table; adding the pre-vote information of the to-be-consensed block i at the insertion position in the voting mapping table to obtain an updated voting mapping table; and updating pre-vote numbers corresponding to N to-be-consensed blocks respectively according to the updated voting mapping table to obtain a target pre-vote number, which is used to determine whether the to-be-consensed blocks reach a consensus. By using the embodiments of the present application, the consensus efficiency in the blockchain system can be improved.

Description

Technical Field

[0001] This application relates to the field of network media technology, and in particular to a consensus voting processing method, apparatus, device, and medium for a blockchain system. Background Technology

[0002] A blockchain system is a distributed system, and a consensus mechanism is fundamental to its proper functioning. Consensus in a blockchain system can be understood as reaching an agreement. Each node in the blockchain system stores its own copy of the distributed ledger (i.e., the blockchain itself); the process of establishing a blockchain system is the process of ensuring consistency between the distributed ledgers of all nodes.

[0003] The consensus process of a blockchain system is usually based on a consensus algorithm, such as the BFT (Byzantine Fault Tolerance) algorithm. Each round of consensus in this algorithm is based on voting on a single block. That is, every time a new block is generated in the blockchain system, the nodes in the blockchain system need to vote on it, and each node participating in the block consensus needs to broadcast the voting information to the other nodes. Only after the blocks at that block height reach a consensus can the next round of consensus process begin, resulting in low consensus efficiency in the blockchain system. Summary of the Invention

[0004] This application provides a consensus voting processing method, apparatus, device, and medium for a blockchain system, which can improve the consensus efficiency of the blockchain system.

[0005] This application provides a consensus voting processing method for a blockchain system, which is executed by a target node device in the blockchain system, including:

[0006] During the consensus cycle of the blockchain system, the pre-voting information of block i to be consensus is received; block i to be consensus belongs to the blockchain to be consensus corresponding to the target node device. The blockchain to be consensus is determined by the N blocks to be consensus received by the target node device, where i and N are both positive integers and i is less than or equal to N.

[0007] If the target node device's voting mapping table does not contain the pre-voting information for block i to be reached, then the insertion position of block i to be reached in the voting mapping table is determined according to the chain position relationship between block i to be reached and the block to be reached to which the pre-voting information in the voting mapping table belongs in the blockchain to be reached; the voting mapping table includes the pre-voting information received by the target node device;

[0008] At the insertion position in the voting map table, add the pre-voting information of block i to be reached for consensus, and obtain the updated voting map table;

[0009] Based on the updated voting mapping table, the pre-vote counts corresponding to the N blocks awaiting consensus are updated to obtain the target pre-vote counts corresponding to the N blocks awaiting consensus. Based on the target pre-vote counts, the target blocks for the N blocks awaiting consensus to reach consensus during the consensus period are determined.

[0010] This application provides a consensus voting processing device for a blockchain system. This device is applied to a target node device within the blockchain system and includes:

[0011] The receiving module is used to receive the pre-voting information of block i to be reached in the consensus cycle of the blockchain system. Block i to be reached belongs to the consensus blockchain corresponding to the target node device. The consensus blockchain is determined by the N consensus blocks received by the target node device. i and N are both positive integers and i is less than or equal to N.

[0012] The position determination module is used to determine the insertion position of block i in the voting mapping table if the target node device does not contain the pre-voting information of block i to be reached for consensus, based on the chain position relationship between block i to be reached for consensus and the block to be reached for consensus to which the pre-voting information in the voting mapping table belongs in the blockchain to be reached for consensus; the voting mapping table includes the pre-voting information received by the target node device.

[0013] The addition module is used to add the pre-voting information of block i to be reached in the voting map table at the insertion position, so as to obtain the updated voting map table;

[0014] The voting statistics module is used to update the pre-vote counts corresponding to the N blocks to be reached for consensus based on the updated voting mapping table, to obtain the target pre-vote counts corresponding to the N blocks to be reached for consensus, and to determine the target blocks for the N blocks to be reached for consensus during the consensus period based on the target pre-vote counts.

[0015] The consensus cycle includes the proposal phase;

[0016] The device also includes:

[0017] The block acquisition module is used to acquire N blocks to be consensus created during the proposal phase of the consensus cycle, and to acquire the current block hash and the predecessor block hash contained in each of the N blocks to be consensus.

[0018] The block concatenation module is used to concatenate block i and block j when the predecessor block hash of block j among N blocks to be reached is the current block hash of block i to be reached, thereby generating a blockchain to be reached containing N blocks to be reached; j is a positive integer less than or equal to N.

[0019] The location determination module includes:

[0020] The voting block set determination unit is used to determine the block to be consensus to which the pre-voting information in the voting mapping table belongs as the voting block set if the voting mapping table of the target node device does not contain the pre-voting information of the block to be consensus i.

[0021] The block sorting unit is used to obtain the block height H corresponding to the block i to be reached for consensus, and to traverse the blocks to be reached for consensus in the voting block set in descending order of block height; H is a positive integer;

[0022] The first position determination unit is used to determine the insertion position of the block to be reached, i, in the voting mapping table when the voting block set contains a block to be reached with a block height greater than H.

[0023] The second position determination unit is used to determine the end position of the voting map table as the insertion position of the block to be reached in the voting map table when the voting block set does not contain a block to be reached with a block height greater than the block height H.

[0024] Specifically, the first position determination unit is used for:

[0025] When the voting block set contains a consensus block with a block height greater than H, obtain consensus block k with a block height less than H and consensus block j with a block height greater than H from the voting block set; consensus blocks k and j have an adjacent order in the voting block set, and j and k are both positive integers less than or equal to N;

[0026] In the voting mapping table, the position between block k and block j to be reached is determined as the insertion position corresponding to block i to be reached.

[0027] The added modules include:

[0028] The first set creation unit is used to create a preceding block set and a following block set for block i when the insertion position is between block k and block j to be agreed upon. Block k is added to the preceding block set of block i to be agreed upon, and block j is added to the following block set of block i to be agreed upon.

[0029] The first key-value pair construction unit is used to take the current block hash of block i to be reached as the key, and the set of preceding blocks, the set of following blocks, and the pre-voting information of block i to be reached as the numerical result.

[0030] The first mapping table update unit is used to determine the voting mapping data corresponding to block i to be reached in consensus based on the key and numerical results, add the voting mapping data at the insertion position of the voting mapping table, and obtain the updated voting mapping table; the set of subsequent blocks of block k to be reached in the updated voting mapping table includes block i to be reached, and the set of preceding blocks of block j to be reached includes block i to be reached.

[0031] The added modules include:

[0032] The second set creation unit is used to create a preceding block set and a following block set for block i to be consensused when the insertion position is the end of the voting mapping table. It adds the block to be consensused with the largest block height in the voting block set to the preceding block set of block i to be consensused, and determines that the following block set of block i to be consensused is empty.

[0033] The second key-value pair construction unit is used to take the current block hash of block i to be reached as the key, and the set of preceding blocks, the set of succeeding blocks, and the pre-voting information of block i to be reached as the numerical result.

[0034] The second mapping table update unit is used to determine the voting mapping data corresponding to block i to be reached for consensus based on the keyword and numerical results, and add the voting mapping data to the last position of the voting mapping table to obtain the updated voting mapping table; the set of subsequent blocks of the block to be reached for consensus with the highest block height in the updated voting mapping table includes block i to be reached for consensus.

[0035] The device also includes:

[0036] The recorded prompt module is used to generate a recorded prompt message if the voting mapping table of the target node device contains the pre-voting information of block i to be reached in consensus; the recorded prompt message is used to indicate that the voting mapping table remains unchanged.

[0037] The voting statistics module includes:

[0038] The block partitioning unit is used to determine the block to which the pre-voting information in the updated voting mapping table belongs as the first block to be reached for consensus, and to determine the blocks to be reached for consensus other than the first block to be reached for consensus among the N blocks to be reached for consensus as the second blocks to be reached for consensus; the first block to be reached for consensus includes block i, and the number of first blocks to be reached for consensus is one or more;

[0039] The pre-vote counting unit is used to obtain the set of subsequent blocks corresponding to each first block to be reached for consensus in the updated voting mapping table, and re-count the target pre-vote count corresponding to each first block to be reached for consensus based on the number of blocks in each set of subsequent blocks;

[0040] The aforementioned pre-vote counting unit is also used to determine the target pre-vote count corresponding to the second block awaiting consensus as an empty value.

[0041] The consensus cycle includes a pre-voting phase and a pre-commit phase, with the target pre-vote count being the number of pre-votes obtained by N blocks awaiting consensus during the pre-voting phase.

[0042] The voting statistics module includes:

[0043] The pre-commit total determination unit is used to determine the total number of pre-commits obtained by block i in the pre-commit phase based on the pre-commit information in the pre-commit phase if the target number of pre-votes obtained by block i in the pre-vote phase is greater than the quantity threshold among N blocks to be reached.

[0044] The consensus unit is used to determine that if the total number of pre-commits obtained by block i during the pre-commit phase is greater than the commit threshold, then block i has reached consensus during the consensus period and is designated as the target block.

[0045] The device also includes:

[0046] The consensus failure module is used to determine that block i has not reached consensus during the consensus period if the total number of pre-commits obtained by block i during the pre-commit phase is less than or equal to the commit threshold.

[0047] The device also includes:

[0048] The accounting module is used to add target blocks to the target blockchain in the blockchain system, delete target blocks from the blockchain awaiting consensus, and obtain the updated blockchain awaiting consensus.

[0049] The device also includes:

[0050] The candidate block determination module is used to determine the set of unvoted blocks corresponding to the target node device in the updated consensus blockchain. In the set of unvoted blocks, the consensus block corresponding to the largest number of target pre-votes is determined as a candidate block.

[0051] The block verification module is used to verify the validity of candidate blocks during the pre-voting phase of the consensus cycle and obtain the verification results corresponding to the candidate blocks.

[0052] The pre-voting module is used to vote on the blocks in the updated consensus blockchain whose block height is less than that of the candidate blocks, as well as the candidate blocks, when the verification result is a successful verification result, and to generate the pre-voting information corresponding to the candidate blocks.

[0053] The broadcast module is used to broadcast the pre-voting information corresponding to the candidate block to the remaining node devices in the blockchain system, excluding the target node device; the remaining node devices and the target node device belong to the consensus committee in the blockchain system.

[0054] One aspect of this application provides a computer device, including a memory and a processor. The memory is connected to the processor, the memory is used to store computer programs, and the processor is used to call the computer programs so that the computer device executes the method provided in one aspect of this application.

[0055] One aspect of this application provides a computer-readable storage medium storing a computer program adapted to be loaded and executed by a processor, so that a computer device having a processor performs the method provided in one aspect of this application.

[0056] According to one aspect of this 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 perform the method provided in the above aspect.

[0057] In this embodiment, the target node device can receive pre-voting information for block i to be consensus during the consensus cycle of the blockchain system. Block i belongs to the consensus blockchain corresponding to the target node device, which is determined by the N consensus blocks received by the target node device. i and N are both positive integers and i is less than or equal to N. If the target node device's voting mapping table does not contain the pre-voting information for block i, the insertion position of block i in the voting mapping table is determined according to the chain position relationship between block i and the consensus blocks to which the pre-voting information in the voting mapping table belongs. The voting mapping table includes the pre-voting information received by the target node device. The pre-voting information for block i is added to the insertion position in the voting mapping table to obtain an updated voting mapping table. Then, the target pre-vote counts corresponding to each of the N consensus blocks can be counted based on the updated voting mapping table. The target pre-vote counts can be used to determine the consensus result of each consensus block in the consensus cycle. It is evident that, within the consensus cycle of a blockchain system, the blockchain-like structural characteristics can be integrated into the consensus process. Received blocks awaiting consensus can be chained together according to a block chain structure to generate a blockchain awaiting consensus. Simultaneously, a voting mapping table can be generated based on the received pre-voting information. Based on the voting mapping table, the blocks awaiting consensus that were voted on in the pre-votes can be counted, i.e., the target number of pre-votes corresponding to each block awaiting consensus can be counted. While ensuring the security of the chain, the consensus efficiency of the blockchain can be improved. Attached Figure Description

[0058] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

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

[0060] Figure 2 This is a schematic diagram of a blockchain structure provided in an embodiment of this application;

[0061] Figure 3 This is a schematic diagram illustrating the composition of a consensus committee in a blockchain system provided in an embodiment of this application;

[0062] Figure 4 This is a schematic diagram of consensus processing in a blockchain system provided in an embodiment of this application;

[0063] Figure 5This is a flowchart illustrating a consensus voting processing method for a blockchain system provided in an embodiment of this application;

[0064] Figure 6 This is a flowchart illustrating a consensus voting processing method for a blockchain system provided in an embodiment of this application;

[0065] Figure 7 This is a schematic diagram of a pre-voting information processing flow provided in an embodiment of this application;

[0066] Figure 8 This is a schematic diagram of the structure of a consensus voting processing device for a blockchain system provided in an embodiment of this application;

[0067] Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0068] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0069] This application involves blockchain technology. Blockchain is a decentralized infrastructure with distributed storage characteristics. Specifically, it is a data structure that organizes data blocks in chronological order using a linked list-like manner. It can securely store data with sequential relationships that can be verified within the system, and uses cryptography to ensure that the data is immutable and unforgeable.

[0070] Please see Figure 1 , Figure 1 This is a schematic diagram of the architecture of a blockchain network provided in an embodiment of this application. A blockchain network can consist of multiple node devices, and this application does not limit the number of node devices included in a blockchain network. Figure 1 Taking six node devices as an example, the various node devices in the blockchain network are networked in a P2P (Peer-to-Peer) manner, and the node devices communicate with each other according to the P2P protocol. All node devices jointly follow the broadcast mechanism and consensus mechanism (including core mechanisms such as PoW (Proof of Work) mechanism and POS (Proof of Stake) mechanism) to jointly ensure the immutability and unforgeability of data on the blockchain, while realizing the decentralized and trustless characteristics of the blockchain.

[0071] The node devices in the blockchain network can include, but are not limited to: PCs (Personal Computers), smartphones, tablets, laptops, PDAs, mobile internet devices (MIDs), wearable devices (such as smartwatches, smart bracelets, etc.), and mobile computers, as well as servers.

[0072] A blockchain, maintained collaboratively by nodes in a blockchain network, can consist of a series of blocks, also known as data blocks. After a block is created, consensus processing must be performed within the blockchain network. Only after successful consensus is reached can the block be added to the blockchain. Blocks in a blockchain can be linked together in ascending order of their creation timestamps to form a chain structure. A blockchain is a distributed ledger, and the information data contained within each block constitutes the ledger data of that distributed ledger.

[0073] Please see Figure 2 , Figure 2 This is a schematic diagram of a blockchain structure provided in an embodiment of this application. For example... Figure 2 As shown, blocks M-1, M, and M+1 are connected in sequence to form a chain structure, where M is a positive integer. M-1, M, and M+1 can all be considered as the block heights of the blocks in the blockchain. The block height can be used to represent the number of blocks connected to the blockchain. The block height can be considered as a block identifier, indicating the block's position in the blockchain. The default block height of the genesis block in the blockchain is 0. The block height of the first block after the genesis block is 1 (the first block can be called block 1), the block height of the second block after the genesis block is 2 (the second block can be called block 2), and so on. Each block in the blockchain can be divided into two parts: a block header and a block body. For example, the block header of block M can contain the digest value of the current block M, the digest value of the previous block M-1, and the Merkle root of this block M. The block body of block M can contain the complete information data of the current block M. Of course, the complete transaction data in the block body can be organized together in the form of a Merkle tree.

[0074] The information data in the block body can refer to the original data requested and published to the blockchain network, such as lending data, transaction data, user information, etc. Merkle trees are an important component of blockchain technology. Blockchains typically do not store plaintext raw data; the raw data needs to undergo hash operations (also known as hash calculations) and be stored as hash values. Merkle trees can be used to organize the hash values ​​generated from hash operations on multiple raw data into a binary tree structure and store them in the block body. The digest value of this block and the digest value of the previous block contained in the block header can be called hash values.

[0075] This application also relates to a consensus mechanism. A blockchain system is a distributed system, which can be considered a system with multiple layers. The blockchain network can reside at one of these layers. The consensus mechanism is fundamental to the normal operation of the blockchain system. Consensus in a blockchain system can be considered as reaching an agreement. Each node in the blockchain system can store its own copy of the distributed ledger (i.e., the blockchain). The consensus process of the blockchain system is the process of ensuring consistency between the distributed ledgers of all node devices. All or some node devices in the blockchain system can participate in the consensus process. These participating node devices collectively form the consensus committee of the blockchain system, and each participating node device can be a member of the consensus committee.

[0076] In other words, a blockchain system's consensus committee comprises multiple participating node devices, and the consensus process is executed by these nodes. The consensus process in a blockchain system is typically based on a consensus algorithm, which can include, but is not limited to, PoW, PoS, DPoS (Delegate Proof of Stake), PBFT (Practical Byzantine Fault Tolerance), and others. Each node in the consensus committee executes the corresponding steps of the consensus process by running the consensus algorithm. Among these, Byzantine fault-tolerant algorithms are a type of fault-tolerant technology in the field of distributed computing. The Byzantine hypothesis is a model of the real world, where computers and networks may exhibit unpredictable behavior due to hardware errors, network congestion or outages, or malicious attacks. Byzantine fault-tolerant algorithms are designed to handle these abnormal behaviors and meet the specification requirements of the problem being solved.

[0077] In a blockchain system, each block generated requires consensus processing from nodes within the consensus committee. A consensus cycle in a blockchain system can be divided into three phases in sequence: the proposal phase, the pre-voting phase, and the pre-commit phase. The nodes participating in the same consensus cycle within the consensus committee include two types: proposal nodes and non-proposal nodes. A proposal node is elected from among the nodes in the consensus committee. This node is responsible for generating blocks awaiting consensus (these blocks can be simply referred to as "blocks awaiting consensus") during the proposal phase of the current consensus cycle and broadcasting them to other nodes in the consensus committee for consensus processing. It is also responsible for processing the consensus on these blocks. Non-proposal nodes, on the other hand, only process the blocks awaiting consensus.

[0078] The block awaiting consensus can be a new block created by a proposing node. Any new block generated by a proposing node can be called a block awaiting consensus before it is recorded in the distributed ledger. That is, a block awaiting consensus can refer to a block that has not yet undergone consensus processing or is undergoing consensus processing. Consensus processing includes pre-voting processing and pre-commit processing. Pre-voting processing occurs during the pre-voting phase, while pre-commit processing occurs during the pre-commit phase. Pre-voting processing refers to the process of agreeing to pre-vote on the block awaiting consensus. If agreeing to pre-vote on the block awaiting consensus, it means agreeing to add the block to the blockchain (distributed ledger, which can be referred to as the target blockchain for convenience). Pre-commit processing refers to the process of agreeing to pre-commit the block awaiting consensus. If agreeing to pre-commit on the block awaiting consensus, it means confirming agreement to add the block to the target blockchain. During different consensus cycles, the node devices participating in the consensus may change, meaning the members of the consensus committee may change in each consensus cycle; different blocks awaiting consensus can be created by different proposing nodes.

[0079] Please see Figure 3 , Figure 3 This is a schematic diagram illustrating the composition of a consensus committee in a blockchain system provided in an embodiment of this application. Figure 3 As shown, the consensus committee of a blockchain system may include node devices A, B, C, D, and E. During a certain consensus cycle of the blockchain system, when node device A is the proposing node, nodes B, C, D, and E are non-proposing nodes. During the proposal phase of the consensus cycle, node device A (i.e., the proposing node) generates a block X to be reached for consensus. This block X can be a block created by node device A. Node device A can then use block X as the block to be reached for consensus and broadcast it to nodes B, C, D, and E.

[0080] During the pre-voting phase of the consensus cycle, due to network failures, equipment failures, or other reasons, some node devices may fail to receive block X broadcast by node device A in the first instance. For example, suppose node device B does not receive block X broadcast by node device A in the first instance, while nodes C, D, and E all receive block X broadcast by node device A in the first instance. In the pre-voting phase, nodes A, C, D, and E can all treat block X as a block to be reached for consensus and perform pre-voting processing on block X to obtain their respective pre-voting information. The pre-voting information here includes the identifier of the block to which pre-voting processing has been performed. For example, node device C performs pre-voting processing on block X to generate its own pre-voting information, which includes the identifier of block X (such as the hash value of block X). This pre-voting information indicates that node device C agrees to pre-vote on block X, that is, agrees to add block X to the target blockchain, and block X receives the pre-vote from node device C. Understandably, if node device C does not generate pre-voting information, it means that node device C has not pre-voted for block X; or if node device C's pre-voting information 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 target blockchain. Since node device B did not receive block X in the first instance, node device B did not pre-vote for block X. The aforementioned "first instance" can be set according to actual needs, such as 1 minute, 3 minutes, etc.

[0081] Node devices A, B, C, D, and E can each broadcast their pre-voting information within the blockchain system. Each node in the consensus committee can receive pre-voting information from the other nodes and use this information to count the number of pre-votes received by block X during the pre-voting phase, confirming whether this number exceeds a threshold. This threshold can be set according to actual conditions; for example, it could be 50% or 2 / 3 of the number of nodes in the consensus committee. For instance, assuming a threshold of 3, if node C counts 4 pre-votes received by block X during the pre-voting phase, it confirms that block X received more than the threshold of 3.

[0082] During the pre-commit phase of the consensus cycle, nodes A, C, D, and E pre-voted on block X. Therefore, during this pre-commit phase, they can each perform pre-commit processing on block X to obtain their respective pre-commit information. This pre-commit information includes the identifier of the block to which pre-commit processing was performed. For example, node C performs pre-commit processing on block X, generating node C's pre-commit information. This pre-commit information includes the identifier of block X, and it indicates that node C agrees to pre-commit block X, meaning it confirms its agreement to add block X to the blockchain. Block X receives node C's pre-commit. It can be understood that if node C's pre-commit information is not generated, it means node C has not pre-committed block X; or if node C's pre-commit information does not include the identifier of block X, it means node C does not agree to pre-commit block X, meaning it confirms its disagreement to add block X to the blockchain.

[0083] Node devices A, B, C, D, and E can each broadcast their own pre-commit information within the blockchain system. Each node in the consensus committee can receive pre-commit information from the other nodes and use this information to count the number of pre-commits (i.e., the total number of pre-commits) obtained by block X during the pre-commit phase, and confirm whether this number exceeds the commit threshold. This commit threshold can be set according to actual conditions; for example, it could be 50% or 2 / 3 of the number of nodes in the consensus committee. Node devices A, C, D, and E have all pre-committed block X, and their pre-commit information can all contain the identifier of block X. For example, assuming the commit threshold is 3, if node device C counts 4 pre-commits for block X during the pre-commit phase, confirming that block X's pre-commit count exceeds the threshold of 3, and node device C also counts 4 pre-votes for block X during the pre-voting phase, then block X can be determined to have achieved consensus and can be added to the target blockchain. If node device C counts 3 pre-commits for block X during the pre-commit phase (not exceeding the commit threshold), then block X's consensus is unsuccessful. In other words, if block X receives both the pre-votes and pre-commits exceeding the commit threshold, then block X achieves consensus and can be added to the blockchain; otherwise, consensus fails and it cannot be added to the blockchain.

[0084] In this embodiment, to effectively improve the consensus efficiency of blocks, the chain structure of the blockchain can be introduced into the consensus processing. Each node device in the consensus committee can receive one or more blocks to be consensused. Each node device can chain the received blocks to be consensused according to the chain structure to form a blockchain to be consensused. The blockchain to be consensused here has the same chain structure as the target blockchain, except that the blocks in the blockchain to be consensused are those that have not yet undergone consensus processing or are undergoing consensus processing, i.e., the aforementioned blocks to be consensused. The target blockchain is a distributed ledger, and the blocks in the target blockchain are those that have already achieved consensus. When block 1 in the blockchain to be consensused achieves consensus, block 1 can be added to the target blockchain and then deleted from the blockchain to be consensused. In the pre-voting phase of the consensus cycle, each node device in the consensus committee no longer pre-votes for individual blocks to be consensused, but rather pre-votes for the highest block to be consensused that it considers valid, and transmits the pre-voting information to all the preceding blocks of the highest block to be consensused according to the chain structure characteristics of the blockchain to be consensused. In other words, the consensus cycle in this embodiment can still include the proposal stage, the pre-voting stage, and the pre-commit stage. However, in the pre-voting stage, each participating consensus device can pre-vote for multiple blocks awaiting consensus (the highest block awaiting consensus and its predecessor blocks), and the resulting pre-voting information can include the identifiers of multiple blocks awaiting consensus, such as the block hashes. After receiving the pre-voting information for any block awaiting consensus, each node in the consensus committee can recursively calculate the pre-vote count for the highest block awaiting consensus and all its predecessor blocks based on a chain structure. This method ensures the security of the chain and improves consensus efficiency.

[0085] In a consensus committee, each participating node can store a block awaiting consensus. Due to network failures, device malfunctions, or other reasons, the blocks awaiting consensus received by different nodes may differ, leading to inconsistencies in the consensus blockchains of different nodes. The highest block awaiting consensus can refer to the block with the highest block height that has been verified by each participating node in its respective consensus blockchain. The preceding block of this highest block awaiting consensus can be any block in the consensus blockchain with a lower block height than the highest block awaiting consensus. It should be noted that the block height of a block awaiting consensus in a blockchain can represent the number of blocks awaiting consensus in that blockchain. In other words, the block height of a block awaiting consensus is redefined and is unrelated to the block height of the target blockchain. For example, the first block awaiting consensus in the blockchain may have a block height of 1 (this first block can be simply referred to as block 1), and its header may include the block hash of the highest block in the target blockchain. The second block awaiting consensus in the blockchain may have a block height of 2 (this second block can be simply referred to as block 2), and its header may include the block hash of block 1, and so on. Alternatively, the block height of a block awaiting consensus in a blockchain can be a temporary block height determined based on the target blockchain; that is, the block height of a block awaiting consensus is determined based on the block height of the target blockchain. For example, when the block height of the highest block in the target blockchain is 100 (i.e., the target blockchain consists of a genesis block and 100 blocks), the block height of block 1 in the blockchain awaiting consensus is 101, the block height of block 2 in the blockchain awaiting consensus is 102, and so on.

[0086] Please see Figure 4 , Figure 4 This is a schematic diagram illustrating the consensus processing of a blockchain system provided in an embodiment of this application. For example... Figure 4The node device 1 shown represents any node participating in the consensus committee of the blockchain system. This node device 1 can maintain two components: a block-chain relationship component and a Directed Acyclic Graph (DAG) component. The block-chain relationship component stores all blocks awaiting consensus received by node device 1, and these blocks are linked together in a chain structure, thus storing node device 1's blockchain awaiting consensus. The DAG component can contain a voting mapping table, which may refer to a pre-voting information mapping table. This voting mapping table can use a key-value pair structure, such as generating key-value pairs using block hashes as keys and pre-voting information as values. It should be noted that when node device 1 initially has not received any blocks awaiting consensus, both the blockchain awaiting consensus in the block-chain relationship component and the voting mapping table in the DAG component are empty.

[0087] like Figure 4 As shown, assume that the blockchain component of node device 1 receives 10 blocks awaiting consensus, namely block A, block B, block C, block D, block E1, block F1, block G1, block E2, block F2, and block G2. These 10 blocks awaiting consensus can be chained together to generate blockchain 10a awaiting consensus. These 10 blocks awaiting consensus can be new blocks created during the proposal phase. Blockchain 10a forks after block D. Blocks E1 and E2 have the same block height in blockchain 10a. Similarly, blocks F1 and F2 have the same block height in blockchain 10a, and blocks G1 and G2 have the same block height in blockchain 10a. At this time, the directed acyclic graph component of node device 1 receives the pre-voting information corresponding to block B, block D, block F1 and block G2 respectively. Based on the chain position relationship of block B, block D, block F1 and block G2 in the blockchain 10a to be reached for consensus, a voting mapping table 10b can be generated. The voting mapping table 10b contains the pre-voting information corresponding to block B, block D, block F1 and block G2 respectively.

[0088] When node device 1 receives the pre-voting information for block C, it can traverse the pre-voting information in the voting mapping table 10b of the directed acyclic graph component. If the voting mapping table 10b contains the block hash of block C, it means that the pre-voting information for block C has already been recorded in the voting mapping table 10b, and there is no need to record it again. If the voting mapping table 10b does not contain the block hash of block C, it means that the pre-voting information for block C has not yet been recorded in the voting mapping table 10b. In this case, it can traverse the block hashes (keywords) in the voting mapping table 10b. For each block hash in the voting mapping table 10b, it checks whether the block height of the block to be reached for consensus corresponding to that block hash is greater than the block height of block C. The comparison of block heights can be determined through the blockchain to be reached for consensus 10a in the blockchain relationship component. For example, in voting map 10b, the block heights of blocks G2, F1, and D are all greater than the block height of block C, while the block height of block B is less than the block height of block C. It can be determined that the position of block C in voting map 10b is between block B and block D. That is, a key-value pair can be generated based on the block hash of block C and the pre-voting information of block C, and this key-value pair can be added to voting map 10b to form a new voting map 10c, which is the updated voting map.

[0089] Using voting map table 10c, the pre-vote counts of each node awaiting consensus can be updated to obtain the latest pre-vote counts. For example, the pre-vote count for block B is 5, for block C it is 4, for block D it is 3, for block F1 it is 1, and for block G1 it is 1. It should be noted that after adding the pre-vote information for block C to the voting map table, it is only necessary to update the pre-vote counts for block C and for block B (whose block height is less than block C's). For instance, before adding the pre-vote information for block C, the pre-vote counts for block D were 3, for block F1 they were 1, and for block G1 they were 1, which is consistent with the pre-vote counts after adding the pre-vote information for block C. In other words, adding new pre-vote information only updates the pre-vote counts for the block itself and for blocks whose block height is less than its own. Since node device 1 has not yet received the pre-vote information for blocks A, E1, E2, F2, and G1, it is impossible to count the number of pre-votes for these blocks.

[0090] Furthermore, when the number of pre-votes for a block awaiting consensus exceeds a threshold, node device 1 can generate pre-commit information for that block during the pre-commit phase. This pre-commit information indicates that node device 1 confirms adding the block to the target blockchain. For example, assuming the threshold is 4, the node device can determine that the number of pre-votes for block B exceeds the threshold and generate pre-commit information for block B during the pre-commit phase. This pre-commit information may include the identifier of block B (e.g., the block hash of block B), and the pre-commit information is broadcast to the remaining node devices in the consensus committee. In this embodiment, by introducing a chain structure into the consensus cycle of the blockchain system and using a voting mapping table to count the number of pre-votes for each block awaiting consensus, the consensus efficiency of the blockchain can be improved while ensuring the security of the chain.

[0091] Please see Figure 5 , Figure 5 This is a flowchart illustrating a consensus voting processing method for a blockchain system provided in an embodiment of this application. It can be understood that the consensus voting processing method of this blockchain system is executed by a target node device, which can be any node device in the consensus committee of the blockchain system; such as... Figure 5 As shown, the consensus voting processing method of this blockchain system may include the following steps S101-S104:

[0092] Step S101: During the consensus cycle of the blockchain system, receive the pre-voting information of block i to be consensused; block i to be consensused belongs to the blockchain to be consensused corresponding to the target node device. The blockchain to be consensused is determined by the N blocks to be consensused received by the target node device, where i and N are both positive integers and i is less than or equal to N.

[0093] Specifically, in this embodiment, the operations performed by each node device participating in consensus processing in the consensus committee of a blockchain system during the consensus cycle are similar. For ease of understanding, this embodiment uses any one node device in the consensus committee as an example, and defines this node device as the target node device. During the consensus cycle of the blockchain system, the target node device can receive one or more blocks awaiting consensus. These blocks can refer to new blocks generated during the proposal phase of the consensus cycle. Blocks generated in the blockchain system before being added to the target blockchain can all be called blocks awaiting consensus. When the target node device is a proposal node, it can create blocks awaiting consensus; when it is a non-proposal node, it can receive blocks awaiting consensus broadcast by the proposal node. During the pre-voting phase of the consensus cycle, the target node device can receive pre-voting information corresponding to each block awaiting consensus. For example, the target node device can receive N blocks awaiting consensus during the consensus cycle of the blockchain system. These N blocks can be chained together according to the blockchain's chain structure to form a blockchain awaiting consensus (e.g., the aforementioned...). Figure 4 In the corresponding embodiment of the consensus-pending blockchain 10a), the target node device may receive pre-voting information from the aforementioned N consensus-pending blocks at different times. When the target node device receives pre-voting information from any consensus-pending block (e.g., consensus-pending block i) in the consensus-pending blockchain, it needs to perform subsequent consensus processing on the pre-voting information. Here, i and N are both positive integers, and i is less than or equal to N, such as N can take the value 1, 2, 3, ...

[0094] Step S102: If the voting mapping table of the target node device does not contain the pre-voting information of block i to be reached for consensus, then the insertion position of block i to be reached for consensus in the voting mapping table is determined according to the chain position relationship between block i to be reached for consensus and the block to be reached for consensus to which the pre-voting information in the voting mapping table belongs. The voting mapping table includes the pre-voting information received by the target node device.

[0095] Specifically, after receiving the pre-voting information for block i to be reached for consensus, the target node device can check whether the pre-voting information for block i exists in its voting mapping table. If the voting mapping table contains the pre-voting information for block i, it indicates that the target node device has already received the pre-voting information for block i, and the voting mapping table already records the pre-voting information and block hash of block i. Therefore, it does not need to record it again in the voting mapping table, and a recorded notification message can be generated. This recorded notification message can be used to instruct the voting mapping table to remain unchanged without updating. If the voting mapping table does not contain the pre-voting information for block i, it indicates that the target node device has not yet received the pre-voting information for block i. Based on the chain position relationship between block i and the block to which the pre-voting information contained in the voting mapping table belongs in the blockchain to be reached, the insertion position of block i in the voting mapping table can be determined. Each time the target node device receives pre-voting information for a block awaiting consensus, it can add it to the voting mapping table. In other words, the target node device can generate a voting mapping table based on the received pre-voting information and store the voting mapping table in the directed acyclic graph component. That is, the voting mapping table can include the pre-voting information received by the target node device.

[0096] For example, before receiving the pre-voting information for block i, the target node device has already received pre-voting information for blocks 1, 2, 5, and 6. At this time, the voting mapping table of the target node device's directed acyclic graph component contains the pre-voting information corresponding to blocks 1, 2, 5, and 6. Here, blocks 1, 2, 5, 6, and i are all blocks awaiting consensus received by the target node device; that is, blocks 1, 2, 5, 6, and i all belong to the blockchains awaiting consensus within the blockchain-based relational component. If, in the target node's blockchain awaiting consensus, the block height of block 2 is less than the block height of block 1, and the block height of block 5 is greater than the block height of block 1, then the position between blocks 2 and 5 in the voting map table can be determined as the insertion position of block 1 in the voting map table. If, in the target node's blockchain awaiting consensus, the block heights of blocks 1, 2, 5, and 6 are all less than the block height of block 1, then the last position in the voting map table can be determined as the insertion position of block 1 in the voting map table.

[0097] Step S103: Add the pre-voting information of block i to be reached for consensus at the insertion position in the voting mapping table to obtain the updated voting mapping table.

[0098] Specifically, after determining the insertion position of block i in the voting map table, pre-voting information for block i can be added to that position, thus updating the voting map table to obtain the updated version. The voting map table can be considered a directed acyclic graph (DAG). Adding the pre-voting information for block i is equivalent to inserting a node into the DAG. The order of the pre-voting information in the voting map table should match the order of the corresponding blocks in the blockchain. For example, if block i is inserted at the end of the voting map table, its pre-voting information can be added at the end of the table.

[0099] Step S104: According to the updated voting mapping table, update the pre-vote counts corresponding to the N blocks to be reached for consensus, and obtain the target pre-vote counts corresponding to the N blocks to be reached for consensus. Based on the target pre-vote counts, determine the target blocks for the N blocks to be reached for consensus during the consensus period.

[0100] Specifically, after updating the voting mapping table, the target node device can recalculate the target pre-vote counts for each of the N blocks awaiting consensus in the blockchain based on the updated voting mapping table. Furthermore, the target node device can calculate the pre-vote counts of the affected blocks in the updated voting mapping table, that is, calculate the pre-vote counts of block i and blocks with a height less than block i in the updated voting mapping table, to obtain the latest target pre-vote count.

[0101] The consensus cycle in a blockchain system can include a pre-voting phase and a pre-commit phase. The target pre-vote count can refer to the number of pre-votes obtained by N blocks awaiting consensus during the pre-voting phase of the consensus cycle. If the target pre-vote count obtained by block i among the N blocks awaiting consensus during the pre-voting phase is greater than a threshold, the total number of pre-commits obtained by block i during the pre-commit phase is determined based on the pre-commit information in the pre-commit phase. If the total number of pre-commits obtained by block i during the pre-commit phase is greater than the commit threshold, then block i is determined to have reached consensus during the consensus cycle, meaning that block i has successfully reached consensus during this period. At this point, block i can be designated as the target block, which can be added to the target blockchain in the blockchain system and then removed from the pending consensus blockchain to obtain an updated pending consensus blockchain. Optionally, if the total number of pre-commits obtained by block i during the pre-commit phase is less than or equal to the commit threshold, then block i has not reached consensus during the consensus cycle, meaning that block i has not successfully reached consensus during this period. Understandably, among the N blocks awaiting consensus in the blockchain, if the target pre-vote count for any block exceeds a threshold, it can undergo pre-commit processing. This generates pre-commit information for that block during the pre-commit phase of the consensus cycle. The target node can determine the total number of pre-commits received during this phase based on the pre-commit information. When the total number of pre-commits exceeds the commit threshold, the block is considered to have achieved consensus and can be added to the target blockchain. Blocks added to the target blockchain can be deleted from the blockchain awaiting consensus. In other words, the blocks in the target blockchain and the blocks in the blockchain awaiting consensus are not duplicates. The blockchain awaiting consensus can be updated based on the successful addition of blocks or the receipt of new blocks, resulting in an updated blockchain.

[0102] Optionally, the target node device, acting as a node in the consensus committee of the blockchain system, can participate in the consensus processing of the aforementioned N blocks awaiting consensus. Since the N blocks awaiting consensus may be generated at different times within the blockchain system, and the target node device may receive them at different times, the pre-voting process of the target node device on the N blocks will also have a temporal order. The target node device can vote on the highest-ranking block it deems valid in the blockchain awaiting consensus, and, according to the chain structure of the blockchain, pass it on to blocks whose height is less than that highest-ranking block. The highest-ranking block considered valid by the target node device can be the block with the largest number of target pre-votes among the unconsensus blocks in the blockchain.

[0103] Optionally, in the updated consensus blockchain, a set of unvoted blocks corresponding to the target node device is determined. The consensus blocks included in this set of unvoted blocks can refer to consensus blocks that the target node device has not yet voted on. In the set of unvoted blocks, the consensus block corresponding to the largest number of target pre-votes is determined as a candidate block. During the pre-voting phase of the consensus cycle, the candidate block is validated to obtain the validation result. When the validation result of the candidate block is a pass result, voting is conducted on the consensus blocks and candidate blocks in the updated consensus blockchain whose block height is smaller than that of the candidate block, generating pre-voting information corresponding to the candidate block. The pre-voting information corresponding to the candidate block can then be broadcast to the remaining node devices in the blockchain system other than the target node device. At this time, both the remaining node devices and the target node device belong to the consensus committee in the blockchain system.

[0104] In this embodiment, during the consensus cycle of the blockchain system, the blockchain-like structural characteristics can be integrated into the consensus process. The received blocks to be reached for consensus can be chained together according to the chain structure of the blocks to generate a blockchain to be reached for consensus. At the same time, a voting mapping table can be generated based on the received pre-voting information. Based on the voting mapping table, the blocks to be reached for consensus that were voted on in the pre-vote can be counted, that is, the target number of pre-votes corresponding to each block to be reached for consensus can be counted. While ensuring the security of the chain, the consensus efficiency of the blockchain can be improved.

[0105] Please see Figure 6 , Figure 6 This is a flowchart illustrating a consensus voting processing method for a blockchain system provided in an embodiment of this application. It can be understood that the consensus voting processing method of this blockchain system is executed by a target node device, which can be any node device in the consensus committee of the blockchain system; such as... Figure 6 As shown, the consensus voting processing method of this blockchain system may include the following steps S201-S216:

[0106] Step S201: Obtain the N blocks to be consensus created in the proposal phase of the consensus cycle, and obtain the current block hash and the predecessor block hash contained in the N blocks to be consensus, where N is a positive integer.

[0107] Specifically, during the proposal phase of the consensus cycle, one or more proposal nodes in the blockchain system can create N blocks to be consensused. The proposal nodes can broadcast the created blocks to be consensused to the other node devices in the consensus committee. That is, the target node device can obtain the N blocks to be consensused created during the proposal phase of the consensus cycle. Each time a block to be consensused is received, the target node device can obtain the current block hash and the predecessor block hash contained in the block header of the block to be consensused. The current block hash can refer to the block hash of the block to be consensused, and the predecessor block hash can refer to the block hash of the previous block to be consensused.

[0108] Step S202: When the hash of the predecessor block contained in block j among the N blocks to be reached is the hash of the current block contained in block i, block i and block j are concatenated to generate a blockchain to be reached containing N blocks, where i and j are positive integers less than or equal to N.

[0109] Specifically, when the target node device receives two blocks awaiting consensus (e.g., block i and block j), and the predecessor block hash contained in the block header of block j is the same as the current hash value contained in the block header of block i, then block i and block j are chained together according to the blockchain's chain structure. After receiving N blocks awaiting consensus, the target node device can chain the N blocks together according to the chain structure to generate a blockchain containing N blocks awaiting consensus. Here, i and j can both be positive integers less than or equal to N.

[0110] Step S203: During the consensus cycle of the blockchain system, receive the pre-voting information of block i to be consensused.

[0111] The specific implementation of step S203 can be found in the above description. Figure 5 Step S101 in the corresponding embodiment will not be described again here.

[0112] Step S204: Does the voting mapping table contain pre-voting information for block i awaiting consensus?

[0113] Step S205: Generate a recorded prompt message.

[0114] Specifically, when the voting mapping table contains the pre-voting information of block i to be reached in consensus, a recorded prompt message can be generated, indicating that the target node device's voting mapping table has recorded the pre-voting information of block i to be reached in consensus. This recorded prompt message is used to indicate that the voting mapping table can remain unchanged.

[0115] Step S206: Determine the block to be consensused to which the pre-voting information in the voting mapping table belongs as the voting block set; obtain the block height H corresponding to the block to be consensused i, and traverse the blocks to be consensused in the voting block set in descending order of block height; H is a positive integer.

[0116] Specifically, when the voting mapping table does not contain the pre-voting information for block i to be reached for consensus, the target node device can determine the block to be reached for consensus to which the pre-voting information contained in the voting mapping table belongs as the voting block set. That is, the target node device's directed acyclic graph component stores the pre-voting information of which nodes to be reached for consensus, and these nodes to be reached for consensus can be added to the voting block set. Optionally, the target node device can also construct a block hash set from the block hashes of the blocks to be reached for consensus in the voting block set. The block hash corresponding to the latest block of the target blockchain stored by the target node device can be recorded as the base hash, and the block height of the latest block can be recorded as the base height. Before receiving the block to be reached for consensus, the voting mapping table in the directed acyclic graph component of the target node device is empty, and the block hash set only contains the latest block hash of the target blockchain. The base hash of the latest block of the target blockchain as perceived by the current node is equal to the block hash of the latest block of the target blockchain, and the base height is equal to the block height of the latest block of the target blockchain.

[0117] Step S207: Does the voting block set contain any blocks awaiting consensus whose block height is greater than block height H?

[0118] Step S208: In the voting mapping table, the position between block k and block j to be reached is determined as the insertion position corresponding to block i to be reached; the block height of block k to be reached is less than the block height H, the block height of block j to be reached is greater than the block height H, and block k and block j to be reached have an adjacent arrangement order in the voting mapping table.

[0119] Specifically, the target node device can traverse the block hashes corresponding to the blocks awaiting consensus in the voting block set (i.e., the current block hash contained in the block header of the block awaiting consensus, or the block hash in the voting mapping table (such as the key in a key-value pair)). For each block awaiting consensus in the voting block set, it checks whether the block awaiting consensus is a subsequent block of block i, that is, it checks whether the block height of each block awaiting consensus is greater than the block height of block i (the block height of block i can be denoted as block height H). If the voting block set contains consensus blocks whose block height is greater than H, the target node device can find consensus blocks k and j with adjacent order in the voting mapping table, where the block height of consensus block k is less than the block height H of consensus block i, and the block height of consensus block j is greater than the block height H of consensus block i. The position between consensus blocks k and consensus blocks j is determined as the insertion position corresponding to consensus block i. At this time, consensus blocks k and consensus blocks j belong to the voting block set.

[0120] Step S209: Create a set of preceding blocks and a set of succeeding blocks for block i to be reached in consensus. Add block k to the set of preceding blocks for block i to be reached in consensus. Add block j to the set of succeeding blocks for block i to be reached in consensus.

[0121] Specifically, the target node device can create a preceding block set and a following block set for the node i to be consensused, and add the block k to be consensused to the preceding block set of the node i to be consensused, and add the block j to the following block set of the node i to be consensused. The preceding block set of each block to be consensused can contain only blocks in the voting map table whose block height is only less than the current block to be consensused, and the following block set can contain only blocks in the voting map table whose block height is only greater than the current block to be consensused; for example... Figure 4 The voting mapping table 10c shown shows that the set of blocks preceding block B is (block A), the set of blocks following block B is (block C), and so on. The set of blocks preceding block D is (block C), and the set of blocks following block D is (block F1, block G2).

[0122] Optionally, the set of blocks preceding each block to be reached for consensus may include all blocks in the voting map table whose block height is less than that of the current block to be reached for consensus; the set of blocks following each block to be reached for consensus may include all blocks in the voting map table whose block height is greater than that of the current block to be reached for consensus. Figure 4The voting mapping table 10c shown shows that the set of blocks preceding block B is (block A), and the set of blocks following block B is (block C, block D, block F1, block G2), and so on. The set of blocks preceding block D is (block B, block C), and the set of blocks following block D is (block F1, block G2). Simply put, the block height of the block awaiting consensus in the preceding block set is less than the block height of the current block awaiting consensus, and the block height of the block awaiting consensus in the following block set is greater than the block height of the current block awaiting consensus.

[0123] Step S210: Use the current block hash of block i to be consensused as the key, and use the set of preceding blocks, the set of succeeding blocks, and the pre-voting information of block i to be consensused as the numerical result.

[0124] Step S211: Based on the keyword and numerical results, determine the voting mapping data corresponding to block i to be reached for consensus, add the voting mapping data at the insertion position in the voting mapping table, and obtain the updated voting mapping table; the set of subsequent blocks of block k to be reached for consensus in the updated voting mapping table includes block i to be reached for consensus, and the set of preceding blocks of block j to be reached for consensus includes block i to be reached for consensus.

[0125] Specifically, after determining the insertion position of the pre-voting information of block i to be reached in the voting mapping table (the position between block k and block j to be reached), the target node device can use the block hash (i.e., the current block hash) of block i to be reached as the key, and the preceding block set, following block set, and pre-voting information corresponding to block i to be reached as the numerical result to create a key-value pair. This key-value pair can serve as the voting mapping data corresponding to block i to be reached. At the same time, block i to be reached can be added to the following block set of blocks to be reached that have a block height less than H (e.g., block k to be reached), and block i to be reached can be added to the preceding block set of blocks to be reached that have a block height greater than H (e.g., block j to be reached). By adding the voting mapping data of block i to the voting mapping table, an updated voting mapping table can be obtained. In other words, compared to the previous voting mapping table, the updated voting mapping table not only adds the voting mapping data corresponding to block i to be reached for consensus, but also updates the previous or subsequent block set of the original block to be reached for consensus.

[0126] Step S212: Determine the end position of the voting mapping table as the insertion position of the block i to be reached in the voting mapping table.

[0127] Specifically, if the voting block set does not contain any consensus blocks with a block height greater than the block height H, it means that consensus block i is the consensus block with the largest block height among all consensus blocks that have received pre-voting information. Therefore, the end position of the voting mapping table can be determined as the insertion position of consensus block i in the voting mapping table.

[0128] Step S213: Create a set of preceding blocks and a set of succeeding blocks for block i to be reached for consensus. Add the block with the highest block height in the voting block set to the set of preceding blocks for block i to be reached for consensus. Determine that the set of succeeding blocks for block i to be reached for consensus is empty.

[0129] Specifically, when the insertion position of block i in the voting map table is at the end of the voting map table, the target node device still needs to create a set of preceding blocks and a set of succeeding blocks for block i. At this time, the set of preceding blocks for block i can include all blocks in the voting map table whose block height is less than the block height H, or it can include blocks in the voting map table whose block height is only less than the block height H and which are adjacent to block i. Since there are no blocks in the voting map table whose block height is greater than the block height H, the set of succeeding blocks for block i is temporarily empty.

[0130] Step S214: Use the current block hash of block i to be reached as the key, and use the set of preceding blocks, the set of succeeding blocks, and the pre-voting information of block i to be reached as the numerical result.

[0131] Step S215: Based on the keyword and numerical results, determine the voting mapping data corresponding to block i to be reached for consensus, and add the voting mapping data to the last position of the voting mapping table to obtain the updated voting mapping table; the set of subsequent blocks of the block to be reached for consensus with the highest block height in the updated voting mapping table includes block i to be reached for consensus.

[0132] Specifically, when the insertion position of block i to be consensused in the voting mapping table is at the end of the voting mapping table, the target node device also needs to create the voting mapping data for block i to be consensused. It can also add block i to be consensused in the set of subsequent blocks of the blocks to be consensused contained in the voting mapping table, and add the voting mapping data of block i to the voting mapping table to obtain the updated voting mapping table. The construction method of the voting mapping data is similar to the description of the aforementioned steps S210 and S211, and will not be repeated here.

[0133] Step S216: According to the updated voting mapping table, update the pre-vote counts corresponding to the N blocks to be reached for consensus, and obtain the target pre-vote counts corresponding to the N blocks to be reached for consensus. Based on the target pre-vote counts, determine the target blocks for the N blocks to be reached for consensus during the consensus period.

[0134] Specifically, after updating the voting mapping table, the target node device can calculate the target pre-vote count for each block to be reached based on the number of blocks to be reached in the voting mapping table and the number of blocks to be reached in the subsequent block set of the blocks to be reached. In this context, for N blocks awaiting consensus in the blockchain, they can be divided into first and second consensus blocks based on whether the updated voting mapping table contains pre-voting information from the nodes awaiting consensus. For example, the target node device identifies the block to which the pre-voting information in the updated voting mapping table belongs as the first consensus block, and identifies the N consensus blocks other than the first consensus block as the second consensus blocks. Here, the first consensus block includes consensus block i, and the number of first consensus blocks can be one or more, and the number of second consensus blocks can also be one or more. The updated voting mapping table is used to obtain the set of subsequent blocks corresponding to each first consensus block. Based on the number of blocks in each subsequent block set, the target pre-vote count corresponding to each first consensus block is recalculated. However, since the target node device has not yet received the pre-voting information for the second consensus block, the target pre-vote count for the second consensus block is temporarily empty, i.e., zero. Figure 4 As shown in the voting mapping table 10c, when the set of subsequent blocks of block B is (block C), the set of subsequent blocks of block C is (block D), and the set of subsequent blocks of block D is (block F1, block G2), the target pre-vote count for block B can be calculated to be 5.

[0135] After the target node device counts the target pre-votes for each block awaiting consensus, it can compare the target pre-votes for each block with the quantity threshold. Based on this relationship, the subsequent consensus processing flow continues. The subsequent consensus processing flow can be found above. Figure 5 The description of step S104 in the corresponding embodiment will not be repeated here.

[0136] Please see Figure 7 , Figure 7 This is a schematic diagram illustrating a pre-voting information processing flow provided in an embodiment of this application. For example... Figure 7The node device 2 shown is any node device participating in the consensus committee of the blockchain system, such as the target node device mentioned above. Assume that the block-chain relationship component of node device 2 has received 10 blocks awaiting consensus: Block A, Block B, Block C, Block D, Block E1, Block F1, Block G1, Block E2, Block F2, and Block G2. These 10 blocks awaiting consensus can be chained together to generate a blockchain awaiting consensus 20a. At this time, the directed acyclic graph component of node device 2 has received the pre-voting information corresponding to Block B, Block C, and Block F1. Based on the chain position relationship of Block B, Block C, and Block F1 in the blockchain awaiting consensus 20a, a voting mapping table 20b can be generated. This voting mapping table 20b contains the pre-voting information corresponding to Block B, Block C, and Block F1.

[0137] When node device 2 receives the pre-voting information for block D at time t1 and the pre-voting information for block G2 at time t2, and time t1 is earlier than time t2, it means that node device 2 has received the pre-voting information for blocks D and G2 respectively. Node device 2 can process the pre-voting information for block D first, and then process the pre-voting information for block G2, according to the order in which the pre-voting information was received. The processing flow for the pre-voting information of block D by node device 2 is as follows: Node device 2 can check whether the pre-voting information for block D is recorded in the voting mapping table 20b of the directed acyclic graph component. If the pre-voting information for block D is recorded in the voting mapping table 20b, a recorded message is returned; if the pre-voting information for block D is not recorded in the voting mapping table 20b, the node device traverses the block hash set. For each block hash in the hash set (e.g., block hash1), check if block hash1 is the block hash of a subsequent block of block D. That is, check if the block height of the block to be reached corresponding to block hash1 is greater than the block height of block D. If block hash1 is the block hash of a subsequent block of block D, record it. If block hash1 is not the block hash of a subsequent block of block D, continue to check if block hash2 is the block hash of a subsequent block of block D (here, the block height of the block to be reached corresponding to block hash1 is greater than the block height of the block to be reached corresponding to block hash2), and so on, until all block hashes in the hash set have been traversed, and then return the recorded result.

[0138] If a recorded message is returned, it indicates that node device 2 has received the pre-vote information for block D from the nodes in the consensus committee. If the returned record result is empty, it indicates that the pre-vote information for block D is not pointed to by any of the pre-vote information stored in the voting mapping table 20b of the directed acyclic graph component. That is, in terms of block height, block D has the highest block height (this only applies to the block awaiting consensus for which node device 2 has received pre-vote information). Then, based on all the blocks awaiting consensus contained in the blockchain awaiting consensus 20a, i.e., each block awaiting consensus in the block-chain relationship component up to the latest block hash (base hash) and block height (base height), it is checked whether block D exists in the voting mapping table 20b. If the block awaiting consensus exists in the voting mapping table 20b, then block D or its block hash is added to the set of subsequent blocks of the block awaiting consensus (which can be denoted as ancestry). After traversing all the blocks awaiting consensus in the blockchain 20a, a set of preceding and following blocks for block D can be created. The set of preceding blocks for block D can include ancestry information, while the set of following blocks is empty. Subsequently, the pre-voting information and block hash of block D can be written into the voting mapping table 20b to obtain the updated voting mapping table.

[0139] If the returned record result is not empty, it means that there is a subsequent block (e.g., block F1) in the voting mapping table 20b that is awaiting consensus as block D, and also a preceding block (e.g., block C) that is awaiting consensus as block D. In this case, block D needs to be written between block C and block F1 to generate an updated voting mapping table. Figure 7 The voting mapping table 20c is shown.

[0140] After obtaining the updated voting mapping table 20c, the pre-vote count of the blocks awaiting consensus recorded in the voting mapping table 20c can be calculated, specifically the pre-vote count of the blocks awaiting consensus whose block height is less than that of block D.

[0141] Furthermore, following the above operational procedure, the pre-voting information of block G2 can be processed to obtain the voting mapping table 20d, and the pre-vote counts corresponding to each block awaiting consensus can be updated again. Each time node device 2 receives pre-voting information for a block awaiting consensus, it needs to execute the above operational procedure to update the pre-vote counts in the directed acyclic graph component in real time. Of course, once a block awaiting consensus reaches consensus during the consensus cycle and is officially written into the target blockchain, it can be deleted from the blockchain awaiting consensus 20a. Simultaneously, the voting mapping data for that consensus block can also be deleted from the voting mapping table of the directed acyclic graph component.

[0142] In this embodiment, during the consensus cycle of the blockchain system, the blockchain-like structural characteristics can be integrated into the consensus process. The received blocks to be reached for consensus can be chained together according to the chain structure of the blocks to generate a blockchain to be reached for consensus. At the same time, a voting mapping table can be generated based on the received pre-voting information. Based on the voting mapping table, the blocks to be reached for consensus that were voted on in the pre-vote can be counted, that is, the target number of pre-votes corresponding to each block to be reached for consensus can be counted. While ensuring the security of the chain, the consensus efficiency of the blockchain can be improved.

[0143] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of a consensus voting processing device for a blockchain system provided in an embodiment of this application. It can be understood that this consensus voting processing device 1 for the blockchain system can be applied to the target node device in the blockchain system; such as... Figure 8 As shown, the consensus voting processing device 1 of the blockchain system may include: a receiving module 11, a location determination module 12, an adding module 13, and a voting statistics module 14;

[0144] The receiving module 11 is used to receive the pre-voting information of block i to be reached in the consensus cycle of the blockchain system. Block i to be reached belongs to the blockchain to be reached corresponding to the target node device. The blockchain to be reached is determined by the N blocks to be reached received by the target node device. i and N are both positive integers and i is less than or equal to N.

[0145] The position determination module 12 is used to determine the insertion position of the block to be reached in the voting mapping table if the target node device does not contain the pre-voting information of the block to be reached in the voting mapping table, based on the chain position relationship between the block to be reached in the voting mapping table and the block to be reached to which the pre-voting information belongs, in the blockchain to be reached; the voting mapping table includes the pre-voting information received by the target node device.

[0146] Add module 13 to add the pre-voting information of block i to be reached in the voting mapping table at the insertion position, and obtain the updated voting mapping table;

[0147] The voting statistics module 14 is used to update the pre-vote counts corresponding to the N blocks to be reached for consensus according to the updated voting mapping table, to obtain the target pre-vote counts corresponding to the N blocks to be reached for consensus, and to determine the target blocks for the N blocks to be reached for consensus during the consensus period based on the target pre-vote counts.

[0148] The specific implementation methods of the receiving module 11, the location determination module 12, the adding module 13, and the voting statistics module 14 can be found above. Figure 5 Steps S101-S104 in the corresponding embodiments will not be described again here.

[0149] In one or more embodiments, the consensus cycle includes a proposal phase;

[0150] The consensus voting processing device 1 of the blockchain system may also include: a block acquisition module 15 and a block concatenation module 16;

[0151] The block acquisition module 15 is used to acquire N blocks to be consensus created during the proposal phase of the consensus cycle, and to acquire the current block hash and the predecessor block hash contained in each of the N blocks to be consensus.

[0152] The block concatenation module 16 is used to concatenate block i and block j to generate a blockchain containing N blocks to be reached when the predecessor block hash of block j to be reached is the current block hash of block i to be reached; j is a positive integer less than or equal to N.

[0153] The specific functional implementation methods of the block acquisition module 15 and the block concatenation module 16 can be found in the above description. Figure 6 Steps S201-S202 in the corresponding embodiments will not be described again here.

[0154] In one or more embodiments, the location determination module 12 may include: a voting block set determination unit 121, a block sorting unit 122, a first location determination unit 123, and a second location determination unit 124;

[0155] The voting block set determination unit 121 is used to determine the block to be consensus to which the pre-voting information in the voting mapping table belongs as the voting block set if the voting mapping table of the target node device does not contain the pre-voting information of the block to be consensus i.

[0156] Block sorting unit 122 is used to obtain the block height H corresponding to the block i to be reached for consensus, and to traverse the blocks to be reached for consensus in the voting block set in descending order of block height; H is a positive integer;

[0157] The first position determination unit 123 is used to determine the insertion position of the block to be reached in the voting mapping table based on the block to be reached in the voting block set containing blocks to be reached with a block height greater than H.

[0158] The second position determination unit 124 is used to determine the end position of the voting map table as the insertion position of the block to be reached in the voting map table when the voting block set does not contain a block to be reached with a block height greater than the block height H.

[0159] Specifically, the first position determining unit 123 is used for:

[0160] When the voting block set contains a consensus block with a block height greater than H, obtain consensus block k with a block height less than H and consensus block j with a block height greater than H from the voting block set; consensus blocks k and j have an adjacent order in the voting block set, and j and k are both positive integers less than or equal to N;

[0161] In the voting mapping table, the position between block k and block j to be reached is determined as the insertion position corresponding to block i to be reached.

[0162] The specific functional implementation methods of the voting block set determination unit 121, the block sorting unit 122, the first position determination unit 123, and the second position determination unit 124 can be found above. Figure 6 Steps S204-S208 and S212 in the corresponding embodiments will not be described again here.

[0163] In one or more embodiments, the adding module 13 may include: a first set creation unit 131, a first key-value pair construction unit 132, a first mapping table update unit 133, a second set creation unit 134, a second key-value pair construction unit 135, and a second mapping table update unit 136.

[0164] The first set creation unit 131 is used to create a preceding block set and a following block set for block i when the insertion position is between block k and block j to be agreed upon, add block k to the preceding block set of block i to be agreed upon, and add block j to the following block set of block i to be agreed upon.

[0165] The first key-value pair construction unit 132 is used to use the current block hash of the block i to be reached as the key, and the set of preceding blocks, the set of succeeding blocks, and the pre-voting information of the block i to be reached as the numerical result.

[0166] The first mapping table update unit 133 is used to determine the voting mapping data corresponding to the block i to be reached for consensus based on the keyword and numerical result, add the voting mapping data at the insertion position of the voting mapping table, and obtain the updated voting mapping table; the set of subsequent blocks of the block k to be reached for consensus in the updated voting mapping table includes the block i to be reached for consensus, and the set of preceding blocks of the block j to be reached for consensus includes the block i to be reached for consensus.

[0167] The second set creation unit 134 is used to create a preceding block set and a following block set for the block to be consensus i when the insertion position is the end of the voting mapping table, add the block to be consensus i with the largest block height in the voting block set to the preceding block set of the block to be consensus i, and determine that the following block set of the block to be consensus i is empty.

[0168] The second key-value pair construction unit 135 is used to use the current block hash of the block to be reached, i, as the key, and the set of preceding blocks, the set of following blocks, and the pre-voting information of the block to be reached, i, as the numerical result.

[0169] The second mapping table update unit 136 is used to determine the voting mapping data corresponding to the block i to be reached for consensus based on the keyword and numerical result, and add the voting mapping data to the last position of the voting mapping table to obtain the updated voting mapping table; the set of subsequent blocks of the block i to be reached for consensus with the largest block height in the updated voting mapping table includes the block i to be reached for consensus.

[0170] The specific functional implementations of the first set creation unit 131, the first key-value pair construction unit 132, the first mapping table update unit 133, the second set creation unit 134, the second key-value pair construction unit 135, and the second mapping table update unit 136 can be found above. Figure 6 Steps S209-S211 and S213-S215 in the corresponding embodiments will not be described again here. Specifically, when the first set creation unit 131, the first key-value pair construction unit 132, and the first mapping table update unit 133 are performing their respective operations, the second set creation unit 134, the second key-value pair construction unit 135, and the second mapping table update unit 136 all pause their operations; when the second set creation unit 134, the second key-value pair construction unit 135, and the second mapping table update unit 136 are performing their respective operations, the first set creation unit 131, the first key-value pair construction unit 132, and the first mapping table update unit 133 all pause their operations; the first set creation unit 131 and the second set creation unit 134 can be merged into one set creation unit, the first key-value pair construction unit 132 and the second key-value pair construction unit 135 can be merged into one key-value pair construction unit, and the second set creation unit 134 and the second mapping table update unit 136 can be merged into one mapping table update unit.

[0171] In one or more embodiments, the consensus voting processing device 1 of the blockchain system may further include: a recorded notification module 17;

[0172] The recorded prompt module 17 is used to generate a recorded prompt message if the voting mapping table of the target node device contains the pre-voting information of block i to be reached in consensus; the recorded prompt message is used to indicate that the voting mapping table remains unchanged.

[0173] The specific implementation of the recorded prompt module 17 can be found in the above description. Figure 6 Step S205 in the corresponding embodiment will not be described again here.

[0174] In one or more embodiments, the voting statistics module 14 may include: a block division unit 141 and a pre-vote counting unit 142;

[0175] Block partitioning unit 141 is used to determine the block to which the pre-voting information in the updated voting mapping table belongs as the first block to be consensus, and to determine the blocks to be consensus other than the first block to be consensus among the N blocks to be consensus as the second blocks to be consensus; the first block to be consensus includes block i, and the number of first blocks to be consensus is one or more;

[0176] The pre-vote counting unit 142 is used to obtain the set of subsequent blocks corresponding to each first block to be reached for consensus in the updated voting mapping table, and re-count the target pre-vote count corresponding to each first block to be reached for consensus based on the number of blocks in each set of subsequent blocks;

[0177] The aforementioned pre-vote counting unit 142 is also used to determine the target pre-vote count corresponding to the second block awaiting consensus as an empty value.

[0178] Optionally, the consensus cycle includes a pre-voting phase and a pre-commit phase, with the target pre-vote count being the number of pre-votes obtained by N blocks awaiting consensus during the pre-voting phase;

[0179] The voting statistics module 14 may include: a pre-submission total number determination unit 143 and a consensus approval unit 144;

[0180] The pre-commit total determination unit 143 is used to determine the total number of pre-commits obtained by block i in the pre-commit phase based on the pre-commit information in the pre-commit phase if the target number of pre-votes obtained by block i in the pre-vote phase among N blocks awaiting consensus is greater than the quantity threshold.

[0181] The consensus mechanism, through unit 144, determines that block i has reached consensus during the consensus period if the total number of pre-commits obtained by block i during the pre-commit phase is greater than the commit threshold, and then identifies block i as the target block.

[0182] The specific functional implementation of the block partitioning unit 141 and the pre-vote counting unit 142 can be found in the above description. Figure 5The specific functional implementation of step S104, the pre-submission total determination unit 143, and the consensus passing unit 144 in the corresponding embodiment can be found above. Figure 6 Step S216 in the corresponding embodiment will not be described again here.

[0183] In one or more embodiments, the consensus voting processing device 1 of the blockchain system may further include: a consensus failure module 18, an accounting module 19, a candidate block determination module 20, a block verification module 21, a pre-voting module 22, and a broadcast module 23.

[0184] The consensus failure module 18 is used to determine that block i has not reached consensus during the consensus period if the total number of pre-commits obtained by block i in the pre-commit phase is less than or equal to the commit threshold.

[0185] The accounting module 19 is used to add the target block to the target blockchain in the blockchain system, delete the target block from the blockchain to be reached for consensus, and obtain the updated blockchain to be reached for consensus.

[0186] The candidate block determination module 20 is used to determine the set of unvoted blocks corresponding to the target node device in the updated consensus blockchain, and to determine the consensus block corresponding to the largest target pre-vote number in the unvoted block set as a candidate block.

[0187] The block verification module 21 is used to verify the validity of candidate blocks during the pre-voting phase of the consensus cycle and obtain the verification result corresponding to the candidate block.

[0188] The pre-voting module 22 is used to vote on the consensus blocks and candidate blocks in the updated consensus blockchain whose block height is less than the candidate block height when the verification result is a verification pass result, and to generate the pre-voting information corresponding to the candidate blocks.

[0189] Broadcast module 23 is used to broadcast the pre-voting information corresponding to the candidate block to the remaining node devices in the blockchain system other than the target node device; the remaining node devices and the target node device belong to the consensus committee in the blockchain system.

[0190] The specific implementation methods of the consensus failure module 18, the accounting module 19, the candidate block determination module 20, the block verification module 21, the pre-voting module 22, and the broadcast module 23 can be found above. Figure 5 Step S104 in the corresponding embodiment will not be described again here.

[0191] In this embodiment, during the consensus cycle of the blockchain system, the blockchain-like structural characteristics can be integrated into the consensus process. The received blocks to be reached for consensus can be chained together according to the chain structure of the blocks to generate a blockchain to be reached for consensus. At the same time, a voting mapping table can be generated based on the received pre-voting information. Based on the voting mapping table, the blocks to be reached for consensus that were voted on in the pre-vote can be counted, that is, the target number of pre-votes corresponding to each block to be reached for consensus can be counted. While ensuring the security of the chain, the consensus efficiency of the blockchain can be improved.

[0192] Please see Figure 9 , Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 9 As shown, the computer device 1000 can be a user terminal or a server; this is not a limitation. For ease of understanding, this application uses a computer device as a user terminal as an example. The computer device 1000 may include: a processor 1001, a network interface 1004, and a memory 1005. Furthermore, the computer device 1000 may also include: a user interface 1003, and at least one communication bus 1002. The communication bus 1002 is used to implement communication between these components. The user interface 1003 may also include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 1005 may also be at least one storage device located remotely from the aforementioned processor 1001. Figure 9 As shown, the memory 1005, which is a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application.

[0193] The network interface 1004 in the computer device 1000 can also provide network communication functions, and the optional user interface 1003 can also include a display screen and a keyboard. Figure 9 In the computer device 1000 shown, the network interface 1004 provides network communication functionality; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control application stored in the memory 1005 to achieve:

[0194] During the consensus cycle of the blockchain system, the pre-voting information of block i to be consensus is received; block i to be consensus belongs to the blockchain to be consensus corresponding to the target node device. The blockchain to be consensus is determined by the N blocks to be consensus received by the target node device, where i and N are both positive integers and i is less than or equal to N.

[0195] If the target node device's voting mapping table does not contain the pre-voting information for block i to be reached, then the insertion position of block i to be reached in the voting mapping table is determined according to the chain position relationship between block i to be reached and the block to be reached to which the pre-voting information in the voting mapping table belongs in the blockchain to be reached; the voting mapping table includes the pre-voting information received by the target node device;

[0196] At the insertion position in the voting map table, add the pre-voting information of block i to be reached for consensus, and obtain the updated voting map table;

[0197] Based on the updated voting mapping table, the pre-vote counts corresponding to the N blocks awaiting consensus are updated to obtain the target pre-vote counts corresponding to the N blocks awaiting consensus. Based on the target pre-vote counts, the target blocks for the N blocks awaiting consensus to reach consensus during the consensus period are determined.

[0198] It should be understood that the computer device 1000 described in the embodiments of this application can execute the foregoing text. Figure 5 and Figure 6 The description of the consensus voting processing method for the blockchain system in any of the corresponding embodiments can also be executed as described above. Figure 8 The description of the consensus voting processing device 1 of the blockchain system in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated here.

[0199] Furthermore, it should be noted that this application embodiment also provides a computer-readable storage medium, which stores a computer program executed by the consensus voting processing device 1 of the blockchain system mentioned above. The computer program includes program instructions, and when the processor executes the program instructions, it can execute the aforementioned... Figure 5 and Figure 6The description of the consensus voting processing method of the blockchain system in any corresponding embodiment is omitted here. Furthermore, the beneficial effects of using the same method are also omitted. For technical details not disclosed in the computer-readable storage medium embodiments involved in this application, please refer to the description of the method embodiments of this application. As an example, program instructions can be deployed and executed on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network. These multiple computing devices distributed across multiple locations and interconnected via a communication network can constitute a blockchain system.

[0200] Furthermore, it should be noted that this application also provides a computer program product or computer program, which may include computer instructions, which may be stored in a computer-readable storage medium. The processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor may execute the computer instructions, causing the computer device to perform the aforementioned actions. Figure 5 and Figure 6 The description of the consensus voting processing method for the blockchain system in any corresponding embodiment is omitted here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer program products or computer program embodiments involved in this application, please refer to the description of the method embodiments of this application.

[0201] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0202] The steps in the method of this application embodiment can be adjusted, combined, or deleted according to actual needs.

[0203] The modules in the device of this application embodiment can be merged, divided, and deleted according to actual needs.

[0204] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0205] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A consensus voting processing method for a blockchain system, characterized in that, The method is executed by a target node device in the blockchain system, including: During the consensus cycle of the blockchain system, pre-voting information of block i to be consensus is received; block i to be consensus belongs to the blockchain to be consensus corresponding to the target node device, and the blockchain to be consensus is determined by the N blocks to be consensus received by the target node device, where i and N are both positive integers and i is less than or equal to N; If the voting mapping table of the target node device does not contain the pre-voting information of the block i to be reached for consensus, then the insertion position of the block i to be reached for consensus in the voting mapping table is determined according to the chain position relationship between the block i to be reached for consensus and the block to be reached for consensus to which the pre-voting information in the voting mapping table belongs; the voting mapping table includes the pre-voting information received by the target node device. At the insertion position in the voting mapping table, add the pre-voting information of the block i to be reached for consensus, and obtain the updated voting mapping table; Based on the updated voting mapping table, the pre-vote counts corresponding to the N blocks awaiting consensus are updated to obtain the target pre-vote counts corresponding to the N blocks awaiting consensus. Based on the target pre-vote counts, the target blocks for the N blocks awaiting consensus to reach consensus in the consensus period are determined.

2. The method according to claim 1, characterized in that, The consensus cycle includes a proposal phase; The method further includes: Obtain the N blocks to be consensus created during the proposal phase of the consensus cycle, and obtain the current block hash and the predecessor block hash contained in the N blocks to be consensus respectively; When the hash of the predecessor block contained in block j among the N blocks to be reached is the hash of the current block contained in block i, the blocks i and j are concatenated to generate a blockchain to be reached containing the N blocks to be reached; j is a positive integer less than or equal to N.

3. The method according to claim 1, characterized in that, If the voting mapping table of the target node device does not contain the pre-voting information of the block i to be reached for consensus, then the insertion position of the block i to be reached for consensus in the voting mapping table is determined according to the chain position relationship between the block i to be reached for consensus and the block to be reached for consensus to which the pre-voting information in the voting mapping table belongs, in the blockchain to be reached for consensus, including: If the voting mapping table of the target node device does not contain the pre-voting information of the block i to be reached for consensus, then the block to be reached for consensus to which the pre-voting information in the voting mapping table belongs is determined as the voting block set; Obtain the block height H corresponding to the block i to be reached for consensus, and traverse the blocks to be reached for consensus in the voting block set in descending order of block height; H is a positive integer; When the voting block set contains a block to be consensused that has a block height greater than the block height H, the insertion position of the block to be consensused i in the voting mapping table is determined based on the block to be consensused that has a block height greater than the block height H contained in the voting block set. When the voting block set does not contain a consensus block whose block height is greater than the block height H, the end position of the voting mapping table is determined as the insertion position of the consensus block i in the voting mapping table.

4. The method according to claim 3, characterized in that, When the voting block set contains a consensus block with a block height greater than the block height H, determining the insertion position of the consensus block i in the voting mapping table based on the consensus blocks in the voting block set with block heights greater than the block height H includes: When the voting block set contains a consensus block with a block height greater than the block height H, obtain a consensus block k with a block height less than the block height H and a consensus block j with a block height greater than the block height H from the voting block set; the consensus blocks k and j have an adjacent arrangement order in the voting block set, and j and k are both positive integers less than or equal to N; In the voting mapping table, the position between the block k to be reached and the block j to be reached is determined as the insertion position corresponding to the block i to be reached.

5. The method according to claim 4, characterized in that, The pre-voting information of the block i to be reached for consensus is added at the insertion position in the voting mapping table to obtain the updated voting mapping table, including: When the insertion position is between the block to be reached (k) and the block to be reached (j), a preceding block set and a following block set are created for the block to be reached (i). The block to be reached (k) is added to the preceding block set of the block to be reached (i), and the block to be reached (j) is added to the following block set of the block to be reached (i). The current block hash of the block i to be reached for consensus is used as the key, and the set of preceding blocks, the set of succeeding blocks, and the pre-voting information of the block i to be reached for consensus are used as the numerical result. Based on the keyword and the numerical result, the voting mapping data corresponding to the block i to be reached for consensus is determined, and the voting mapping data is added to the insertion position in the voting mapping table to obtain an updated voting mapping table; the set of subsequent blocks of the block k to be reached for consensus in the updated voting mapping table includes the block i to be reached for consensus, and the set of preceding blocks of the block j to be reached for consensus includes the block i to be reached for consensus.

6. The method according to claim 3, characterized in that, The pre-voting information of the block i to be reached for consensus is added at the insertion position in the voting mapping table to obtain the updated voting mapping table, including: When the insertion position is at the end of the voting mapping table, a set of preceding blocks and a set of following blocks are created for the block i to be consensused. The block to be consensused with the largest block height in the voting block set is added to the set of preceding blocks of the block i to be consensused. The set of following blocks of the block i to be consensused is determined to be empty. The current block hash of the block i to be reached for consensus is used as the key, and the set of preceding blocks, the set of succeeding blocks, and the pre-voting information of the block i to be reached for consensus are used as the numerical result. Based on the keyword and the numerical result, the voting mapping data corresponding to the block i to be reached for consensus is determined, and the voting mapping data is added to the last position of the voting mapping table to obtain the updated voting mapping table; the set of subsequent blocks of the block i to be reached for consensus with the largest block height in the updated voting mapping table includes the block i to be reached for consensus.

7. The method according to claim 1, characterized in that, Also includes: If the voting mapping table of the target node device contains the pre-voting information of the block i to be reached for consensus, then a recorded prompt message is generated; The recorded prompt information is used to instruct the voting mapping table to remain unchanged.

8. The method according to claim 1, characterized in that, The step of updating the pre-vote counts corresponding to the N blocks awaiting consensus based on the updated voting mapping table to obtain the target pre-vote counts corresponding to the N blocks awaiting consensus includes: The block to which the pre-voting information in the updated voting mapping table belongs is determined as the first block to be reached for consensus. The blocks to be reached for consensus among the N blocks to be reached for consensus, excluding the first block to be reached for consensus, are determined as the second blocks to be reached for consensus. The first block to be reached for consensus includes the block to be reached for consensus i, and the number of the first blocks to be reached for consensus is one or more. Obtain the set of subsequent blocks corresponding to each first block awaiting consensus from the updated voting mapping table, and recalculate the target pre-vote count corresponding to each first block awaiting consensus based on the number of blocks in each set of subsequent blocks; The target pre-vote count corresponding to the second block awaiting consensus is set to an empty value.

9. The method according to claim 1, characterized in that, The consensus cycle includes a pre-voting phase and a pre-commit phase, and the target pre-vote count is the number of pre-votes obtained by the N blocks to be reached in the pre-voting phase; The step of determining the target block for consensus among the N blocks to be reached during the consensus period based on the target pre-vote count includes: If the target number of pre-votes obtained by block i in the pre-voting phase is greater than the quantity threshold, then the total number of pre-commits obtained by block i in the pre-commit phase is determined according to the pre-commit information in the pre-commit phase. If the total number of pre-commits obtained by the block i to be reached in the pre-commit phase is greater than the commit threshold, then the block i to be reached in the consensus period is determined to be the target block.

10. The method according to claim 9, characterized in that, Also includes: If the total number of pre-commits obtained by the block i to be reached in the pre-commit phase is less than or equal to the commit threshold, then it is determined that the block i to be reached has not reached consensus in the consensus period.

11. The method according to claim 1, characterized in that, Also includes: The target block is added to the target blockchain in the blockchain system, and the target block is deleted from the blockchain to be reached for consensus, resulting in an updated blockchain to be reached for consensus.

12. The method according to claim 11, characterized in that, Also includes: In the updated consensus blockchain, determine the set of unvoted blocks corresponding to the target node device, and in the set of unvoted blocks, determine the consensus block corresponding to the largest number of target pre-votes as a candidate block; During the pre-voting phase of the consensus cycle, the candidate blocks are validated to obtain the validation results corresponding to the candidate blocks; When the verification result is a successful verification result, voting is conducted on the block blocks in the updated consensus blockchain whose block height is less than the candidate block's block height, as well as the candidate block, to generate pre-voting information corresponding to the candidate block; The pre-voting information corresponding to the candidate block is broadcast to the remaining node devices in the blockchain system, excluding the target node device. The remaining node devices and the target node device belong to the consensus committee of the blockchain system.

13. A consensus voting processing device for a blockchain system, characterized in that, The device is applied to a target node device in a blockchain system, including: The receiving module is used to receive pre-voting information of block i to be consensus during the consensus cycle of the blockchain system; the block i to be consensus belongs to the blockchain to be consensus corresponding to the target node device, and the blockchain to be consensus is determined by the N blocks to be consensus received by the target node device, where i and N are both positive integers and i is less than or equal to N; The position determination module is used to determine the insertion position of the block to be reached in the voting mapping table if the target node device's voting mapping table does not contain the pre-voting information of the block to be reached in the voting mapping table, based on the chain position relationship between the block to be reached in the voting mapping table and the block to be reached to which the pre-voting information belongs in the voting mapping table in the blockchain to be reached; the voting mapping table includes the pre-voting information received by the target node device; An add module is used to add the pre-voting information of the block i to be reached for consensus at the insertion position in the voting mapping table, so as to obtain an updated voting mapping table; The voting statistics module is used to update the pre-vote counts corresponding to the N blocks to be reached for consensus according to the updated voting mapping table, to obtain the target pre-vote counts corresponding to the N blocks to be reached for consensus, and to determine the target blocks for the N blocks to be reached for consensus in the consensus period based on the target pre-vote counts.

14. A computer device, characterized in that, Including memory and processor; The memory is connected to the processor, the memory is used to store computer programs, and the processor is used to invoke the computer programs so that the computer device performs the method according to any one of claims 1-12.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded and executed by a processor to cause a computer device having the processor to perform the method of any one of claims 1-12.

Images