Blockchain node consensus methods, devices, equipment and storage media

Abstract

This invention discloses a blockchain node consensus method, apparatus, device, and storage medium. The method includes: obtaining the node health value of each blockchain node in the blockchain network during the current consensus process; determining a consensus node set based on the node health values ​​and pre-generated distributed verifiable random numbers; wherein the consensus node set includes at least one target consensus node; generating and verifying transaction blocks through the blockchain nodes in the consensus node set to obtain a block consensus result; and realizing the production of transaction blocks in the blockchain network based on the block consensus result. This invention improves the consensus speed in large-scale scenarios while enhancing the security of the consensus process.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a blockchain node consensus method, apparatus, device, and storage medium. Background Technology

[0002] PBFT (Practical Byzantine Fault Tolerance) is a deterministic consensus protocol that tolerates Byzantine faults and does not produce forks. It is widely used in consortium blockchains. However, because the network communication complexity of PBFT is n squared or even n cubed, it is typically used with a small number of nodes. Its consensus speed decreases significantly as the number of nodes exceeds a certain scale.

[0003] However, existing solutions for using the PBFT consensus protocol in large-scale scenarios typically employ a fixed set of blockchain nodes for consensus. The identities of these blockchain nodes are public and transparent, making them vulnerable to pre-planned attacks and thus resulting in low security. Summary of the Invention

[0004] This invention provides a blockchain node consensus method, apparatus, device, and storage medium to improve consensus speed in large-scale scenarios while enhancing the security of the consensus process.

[0005] According to one aspect of the present invention, a blockchain node consensus method is provided, the method comprising:

[0006] Obtain the node health value of each blockchain node in the blockchain network in this consensus;

[0007] A consensus node set is determined based on the health values ​​of each node and a pre-generated distributed verifiable random number; wherein the consensus node set includes at least one target consensus node;

[0008] By generating and verifying transaction blocks through the blockchain nodes in the consensus node set, a block consensus result is obtained;

[0009] Based on the consensus result of the block, the transaction block is generated in the blockchain network.

[0010] According to another aspect of the present invention, a blockchain node consensus device is provided, the device comprising:

[0011] The node health value acquisition module is used to acquire the node health value of each blockchain node in the blockchain network during this consensus process.

[0012] A consensus node set determination module is used to determine a consensus node set based on the health values ​​of each node and a pre-generated distributed verifiable random number; wherein the consensus node set includes at least one target consensus node;

[0013] The transaction block generation module is used to generate and verify transaction blocks through the blockchain nodes in the consensus node set to obtain the block consensus result;

[0014] The block generation module is used to generate the transaction block in the blockchain network based on the block consensus result.

[0015] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0016] At least one processor; and

[0017] A memory communicatively connected to the at least one processor; wherein,

[0018] The memory stores a computer program that can be executed by the at least one processor, which enables the at least one processor to execute the blockchain node consensus method according to any embodiment of the present invention.

[0019] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the blockchain node consensus method according to any embodiment of the present invention.

[0020] This invention's embodiment obtains the node health value of each blockchain node in the blockchain network during the current consensus process; determines a consensus node set based on each node's health value and a pre-generated distributed verifiable random number; generates and verifies transaction blocks through the blockchain nodes in the consensus node set to obtain a block consensus result; and produces a transaction block in the blockchain network based on the block consensus result. This technical solution improves consensus speed in large-scale blockchain scenarios by determining the consensus node set and using target consensus nodes within that set to complete the current consensus. Furthermore, by determining the consensus node set based on each node's health value and a pre-generated distributed verifiable random number, the randomness of each target consensus node within the determined consensus node set is increased, ensuring that the target consensus node is unknown to each blockchain node, thereby enhancing the security of the consensus process.

[0021] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0023] Figure 1 This is a flowchart of a blockchain node consensus method provided in Embodiment 1 of the present invention;

[0024] Figure 2 This is a flowchart of a blockchain node consensus method provided in Embodiment 2 of the present invention;

[0025] Figure 3 This is a flowchart of a blockchain node consensus method provided in Embodiment 3 of the present invention;

[0026] Figure 4 This is a flowchart of a blockchain node consensus method provided in Embodiment 4 of the present invention;

[0027] Figure 5 This is a schematic diagram of the structure of a blockchain node consensus device according to Embodiment 5 of the present invention;

[0028] Figure 6 This is a schematic diagram of the structure of an electronic device that implements the blockchain node consensus method of this invention. Detailed Implementation

[0029] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0030] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0031] Example 1

[0032] Figure 1 This is a flowchart of a blockchain node consensus method provided in Embodiment 1 of the present invention. This embodiment is applicable to node consensus in large-scale blockchain node scenarios. The method can be executed by a blockchain node consensus device, which can be implemented in hardware and / or software. The blockchain node consensus device can be configured in an electronic device, such as... Figure 1 As shown, the method includes:

[0033] S110. Obtain the node health value of each blockchain node in the blockchain network in this consensus.

[0034] The blockchain network can be a consortium blockchain, a public blockchain, or a private blockchain, among other types. A large number of blockchain nodes can exist within a blockchain network.

[0035] The initial health value of each blockchain node in the blockchain network can be preset by relevant technical personnel. For example, it can be set according to the business attributes of the blockchain node. Business attributes could include factors such as industry status or influence.

[0036] It's important to note that after each consensus is reached, some blockchain nodes in the network have updated their health values. Therefore, in subsequent consensus processes, the blockchain nodes participating in the consensus node set are different. In other words, the blockchain nodes in the consensus node set change each time, thus avoiding the use of fixed blockchain nodes to achieve consensus every time.

[0037] S120. Determine the consensus node set based on the health values ​​of each node and the pre-generated distributed verifiable random number; wherein the consensus node set includes at least one target consensus node.

[0038] The distributed verifiable random number is used to increase the randomness of the selection of the target consensus node within the consensus node set. The target consensus node can be any blockchain node used to participate in this round of consensus.

[0039] For example, a verifiable random number can be generated randomly using a distributed VRF (verifiable random function) based on a multi-participant random number generation BLS algorithm.

[0040] For example, a consensus node set can be determined based on a pre-trained node generation network model, using the health values ​​of each node and distributed verifiable random numbers. The node generation network model can be trained by relevant technical personnel using historical node health values ​​and distributed verifiable random numbers as a sample training set. The consensus node set includes at least one target consensus node participating in this round of consensus.

[0041] It should be noted that by introducing distributed verifiable random numbers in the process of determining the consensus node set, the randomness of the target consensus nodes participating in this round of consensus can be ensured, and the unknowability of the target consensus nodes for each blockchain node can be ensured, thereby ensuring the security of the consensus process.

[0042] S130. Generate and verify transaction blocks through the target consensus node in the consensus node set to obtain the block consensus result.

[0043] A transaction block can be generated from any target consensus node in the consensus node set, and the other target consensus nodes in the consensus node set, excluding the target consensus node that generated the transaction block, can verify the transaction block. The selection method for the target consensus node used to generate the transaction block can be either to select the first target consensus node sequentially from the consensus node set as the target consensus node for this round of transaction block generation, or to randomly select any target consensus node from the consensus node set as the target consensus node for this round of transaction block generation. This embodiment does not limit this method.

[0044] For example, the target consensus node in the consensus node set used to generate and verify transaction blocks is designated as the block generation node; the other target consensus nodes in the consensus node set used for transaction block verification, excluding the block generation node, are designated as block verification nodes. Consensus can be reached based on a pre-defined consensus algorithm using the block generation node and the block verification node to obtain the block consensus result. The consensus algorithm can be pre-defined by relevant technical personnel. For example, the consensus algorithm could be the PBFT consensus algorithm.

[0045] In one specific embodiment, a block generating node packages transactions from the transaction pool to obtain a transaction block, and signs the transaction block using its own private key to obtain a block signature. The block generating node sends the transaction block and block signature to the block verification module for block verification. The block verification node verifies the legality of the block signature, and after the block signature verification is successful, it verifies the transactions within the transaction block. If the verification is successful, the transaction block is stored on its local disk, indicating that the consensus result for this round of blocks has been successfully verified and the transaction block has been confirmed. If the block verification node fails to verify the signature or transactions of the transaction block, it does not store it locally, indicating that the consensus result for this round of blocks has been failed and the transaction block has not been confirmed.

[0046] S140. Based on the block consensus results, implement the creation of transaction blocks in the blockchain network.

[0047] For example, if the block consensus result is a verification failure, a new block generation node is selected from the consensus node set to generate the transaction block. The newly selected block generation node then regenerates the transaction block for this round of consensus, and other target consensus nodes verify the transaction block.

[0048] If the block consensus result is successful, the block verification node broadcasts the block to other blockchain nodes in the blockchain network, excluding the consensus node set, to send the transaction block and verification result to other blockchain nodes. The other blockchain nodes then store the transaction block on their local disks, thus realizing the creation of the transaction block in the blockchain network.

[0049] This invention's embodiment obtains the node health value of each blockchain node in the blockchain network during the current consensus process; determines a consensus node set based on each node's health value and a pre-generated distributed verifiable random number; generates and verifies transaction blocks through the blockchain nodes in the consensus node set to obtain a block consensus result; and implements the production of transaction blocks in the blockchain network based on the block consensus result. This technical solution improves consensus speed and efficiency in large-scale blockchain networks by determining the consensus node set and using target consensus nodes within that set to complete the current consensus. Furthermore, determining the consensus node set based on each node's health value and a pre-generated distributed verifiable random number enhances the randomness of the target consensus nodes within the determined set, ensuring the unknowability of the target consensus nodes for each blockchain node, thereby improving the security of the consensus process.

[0050] Example 2

[0051] Figure 2This is a flowchart of a blockchain node consensus method provided in Embodiment 2 of the present invention. This embodiment is based on the above-mentioned technical solutions and has been optimized, improved and refined at a deeper level.

[0052] Furthermore, the step "determine the consensus node set based on the health value of each node and the pre-generated distributed verifiable random number" is refined into "generate the target random number for this iteration number based on the distributed verifiable random number and the health value of each node; determine the target consensus node for this iteration number based on the target random number and the health value of each node; generate the consensus node set based on the target consensus node for different iteration numbers" to improve the generation method of the consensus node set.

[0053] like Figure 2 As shown, the method includes the following specific steps:

[0054] S210. Obtain the node health value of each blockchain node in the blockchain network in this consensus.

[0055] S220. Generate the target random number for this iteration based on the distributed verifiable random number and the health value of each node.

[0056] It should be noted that, in order to ensure the randomness of the target consensus nodes participating in each round of consensus, multiple target consensus nodes can be generated through multiple iterations, thereby ensuring the randomness of the target consensus nodes in each iteration, and thus ensuring the randomness of the generated consensus node set including at least one target consensus node.

[0057] For example, a distributed verifiable random number can be used as the random seed for the current iteration number; the random number distribution range can be determined based on the health value of each node. For example, the sum of the health values ​​of each node can be used as the upper limit of the random number distribution range, and zero can be used as the lower limit of the random number distribution range. Any random number can be randomly selected from the random number distribution range as the target random number for the current iteration number.

[0058] In one optional embodiment, generating a target random number for the current iteration number based on a distributed verifiable random number and the health value of each node includes: generating a random seed for the current iteration number based on the distributed verifiable random number; generating a random distribution interval for the current iteration number based on the health value of each node; and generating the target random number for the current iteration number based on the random seed and the random distribution interval.

[0059] The random seed is used to increase the randomness of the generated target consensus node. The method of generating the random seed is related to the number of iterations and the target random number generated in each iteration.

[0060] Optionally, a random seed for the current iteration number is generated based on a distributed verifiable random number, including: if the current iteration number is the first iteration, then the distributed verifiable random number is used as the random seed for the current iteration number; if the current iteration number is not the first iteration, then the target random number of the previous iteration number is used as the random seed for the current iteration number.

[0061] Based on the health values ​​of each node, a random distribution interval is generated for the current iteration number. For example, if the set of blockchain nodes in the blockchain network is N = {n1, n2, ..., n}... m}, where m represents the number of blockchain nodes in the blockchain network. Correspondingly, if the set of node health values ​​for each blockchain node is W = {w1, w2, ..., w...} m}, then the random distribution interval can be 0 to sum(w1+w2+…+w m Based on the random seed, generate a random number distributed within a random range, which will be used as the target random number for this iteration.

[0062] It should be noted that since each iteration yields a target consensus node for that iteration number, to improve the accuracy of the generated target consensus nodes—that is, to increase the probability of selecting blockchain nodes with higher node health values—it is necessary to remove the node health values ​​of blockchain nodes already identified as target consensus nodes during each generation of the random distribution interval for the current iteration number. This ensures the accuracy of the target consensus nodes generated in subsequent iterations.

[0063] In one optional embodiment, a random distribution interval for the current iteration number is generated based on the health values ​​of each node, including: taking the blockchain nodes that have not been identified as the target consensus nodes as the remaining consensus nodes for the current iteration number; and generating a random distribution interval for the current iteration number based on the node health values ​​of the remaining consensus nodes.

[0064] For example, in this iteration, the blockchain nodes that were not identified as target consensus nodes in previous iterations are determined, and these unidentified blockchain nodes are considered as the remaining consensus nodes in this iteration. A random distribution interval for the local iteration is generated based on the sum of the node health values ​​of the remaining consensus nodes.

[0065] Specifically, if the set of node health values ​​for blockchain nodes is W = {w1, w2, ..., w...} m In this iteration, the blockchain nodes corresponding to node health values ​​w1 and w2 have already been identified as target consensus nodes in previous iterations. Therefore, the remaining consensus nodes in this iteration are w3, w4, ..., wm Therefore, the random distribution interval for this iteration number can be 0 to sum(w3+w4+…+w). m ).

[0066] S230. Based on the target random number and the health value of each node, determine the target consensus node for this iteration.

[0067] For example, the target consensus node for the current iteration number can be determined by comparing the target random number with the health value of each node.

[0068] In one optional embodiment, determining the target consensus node for the current iteration number based on the target random number and the health value of each node includes: taking the blockchain nodes that have not been determined as the target consensus node as the remaining consensus nodes for the current iteration number; and determining the target consensus node for the current iteration number based on the target random number and the node health value of each remaining consensus node.

[0069] It should be noted that, in order to avoid duplicate selection of the target consensus node, the blockchain node that has been identified as the target consensus node can be removed, and the removed blockchain node can be used as the remaining consensus node in the local iteration.

[0070] For example, the target consensus node for the current iteration can be determined based on the relationship between the node health values ​​of the remaining consensus nodes in the local iteration and the target random number. For instance, the first blockchain node whose health value is less than the target random number could be chosen as the target consensus node for the current iteration.

[0071] To further improve the accuracy of the target consensus node determined in each iteration, the target consensus node in the current iteration can be selected by determining the difference between the node health value and the target random number.

[0072] In one optional embodiment, determining the target consensus node for the current iteration number based on the target random number and the node health values ​​of each remaining consensus node includes: sequentially traversing the node health values ​​of the remaining consensus nodes and determining the difference between the target random number and the currently traversed node health value; if the difference is not greater than the currently traversed node health value, then the blockchain node corresponding to the currently traversed node health value is determined as the target consensus node for the current iteration number; if the difference is greater than the currently traversed node health value, then the target random number is updated to the difference, and the next node health value is traversed until the target consensus node for the current iteration number is obtained.

[0073] For example, the remaining consensus nodes' health values ​​are iterated sequentially, and the difference between the target random number and the currently iterated node's health value is determined. Specifically, this difference can be obtained by subtracting the currently iterated node's health value from the target random number. If the difference is not greater than the currently iterated node's health value, the blockchain node corresponding to the currently iterated node's health value is determined as the target consensus node for this iteration. If the difference is greater than the currently iterated node's health value, the difference is assigned to the target random number, i.e., the target random number is updated to the difference; the iteration continues to traverse the next node's health value; the difference between the target random number and the next iterated node's health value is determined; and based on the relationship between the difference and the next iterated node's health value, it is determined whether to determine the blockchain node corresponding to the next iterated node's health value as the target consensus node for this iteration, until the target consensus node for this iteration is obtained, at which point the iteration terminates.

[0074] S240. Generate a consensus node set based on the target consensus node under different iteration numbers.

[0075] For example, target consensus nodes are generated for different numbers of iterations, resulting in a consensus node set. The number of iterations corresponds to the number of target consensus nodes in the consensus node set. For instance, n iterations result in n target consensus nodes in the consensus node set. The number of iterations or the number of target consensus nodes can be preset by relevant technical personnel according to actual needs.

[0076] S250. Generate and verify transaction blocks through the target consensus node in the consensus node set to obtain the block consensus result.

[0077] S260. Based on the block consensus results, implement the creation of transaction blocks in the blockchain network.

[0078] The technical solution of this embodiment generates a target random number for the current iteration number based on a distributed verifiable random number and the health value of each node; determines the target consensus node for the current iteration number based on the target random number and the health value of each node; and generates a consensus node set based on the target consensus nodes for different iteration numbers. This further improves the randomness of the target consensus nodes in the generated consensus node set, thereby ensuring that each blockchain node participating in the consensus is random rather than fixed, thus improving the reliability and security of each node consensus process.

[0079] Example 3

[0080] Figure 3 This is a flowchart of a blockchain node consensus method provided in Embodiment 3 of the present invention. This embodiment is based on the above-mentioned technical solutions and has been optimized, improved and refined at a deeper level.

[0081] Furthermore, the step "generating and verifying transaction blocks through blockchain nodes in the consensus node set to obtain block consensus results" is refined into "selecting a target consensus node from the consensus node set as a block generation node; processing transactions through the block generation node to obtain transaction blocks; verifying the transaction blocks through block verification nodes other than the block generation nodes in the consensus node set to obtain block consensus results; if there are verification errors in the block consensus results, then reselecting a block generation node from the consensus node set" to improve the method for determining block consensus results.

[0082] like Figure 3 As shown, the method includes the following specific steps:

[0083] S310. Obtain the node health value of each blockchain node in the blockchain network in this consensus.

[0084] S320. Determine the consensus node set based on the health values ​​of each node and the pre-generated distributed verifiable random number; wherein the consensus node set includes at least one target consensus node.

[0085] S330. Select any target consensus node from the consensus node set as the block generation node.

[0086] For example, target consensus nodes can be selected sequentially from the consensus node set as block generation nodes, where each target consensus node has a sequence number identifier, and the block generation node can be selected based on the sequence number identifier. Optionally, any target consensus node can also be randomly selected from the consensus node set as a block generation node.

[0087] S340. Process transactions through the block generation node to obtain transaction blocks.

[0088] For example, transactions in the transaction pool for this consensus can be packaged by a block generation node to obtain a transaction block.

[0089] S350. Through the block generation nodes in the consensus node set, block verification nodes other than the block generation nodes verify the transaction blocks and obtain the block consensus result.

[0090] For example, a transaction block can be verified through a block verification node to obtain a block consensus result. The block verification node can be any target consensus node in the consensus node set other than the block generating node.

[0091] It should be noted that, in order to further improve the accuracy of transaction block verification and thus improve the accuracy of the block consensus result, the transaction block can be verified multiple times to obtain the block consensus result.

[0092] In one optional embodiment, the transaction block is verified by block verification nodes other than the block generating nodes in the consensus node set to obtain the block consensus result. This includes: verifying the signature of the pre-preparation message including the transaction block through each block verification node; if the signature verification passes, verifying the transaction block through each block verification node; if the block verification passes, sending preparation messages to other block verification nodes in the consensus node set through each block verification node, and determining the initial voting result of the transaction block based on the number of preparation messages received; if the initial vote passes, sending confirmation messages to other block verification nodes in the consensus node set through each block verification node, and determining the secondary voting result of the transaction block based on the number of confirmation messages received; wherein the block consensus result includes at least one of the signature verification result, block verification result, initial voting result, and secondary voting result.

[0093] For example, a block generating node can sign the generated transaction block to obtain a transaction block signature; and send a pre-preparation message, including the transaction block and its signature, to each block validator node. Each block validator node verifies the signature of the pre-preparation message. If the signature verification passes, the block validator node sends a preparation message to all other block validators except itself to conduct an initial vote on the transaction block, obtaining the initial voting result. When a block validator node receives a preset number of consistent preparation messages, it sends confirmation messages to all other block validators except itself to conduct a secondary vote on the transaction block, obtaining the secondary voting result. When a block validator node receives a preset number of consistent confirmation messages, it executes the transactions within the transaction block and writes the transaction block and transaction execution results to disk, indicating successful consensus execution. The preset number can be pre-set by relevant technical personnel. For example, the preset number can be 2f+1, where f is the number of nodes allowed to fail.

[0094] The block consensus result includes at least one of the following: signature verification result, block verification result, initial voting result, and secondary voting result.

[0095] S360. If there is a verification error in the block consensus result, a new block generation node will be selected from the consensus node set.

[0096] The verification error result can be at least one of the following: signature verification error result, block verification error result, initial voting error result, and secondary voting error result.

[0097] For example, if there is a verification error in the block consensus result, a new block generation node is selected from the consensus node set, and a new transaction block is generated to obtain the block consensus result.

[0098] S370. Based on the consensus results, the transaction block is generated in the blockchain network.

[0099] It should be noted that once the block generating node and block validating node write the transaction block and execution result to disk, it means that the transaction block has been confirmed. The transaction block, along with the verification and voting results for the transaction block, is then broadcast to all blockchain nodes in the blockchain network.

[0100] It should be noted that each consensus outcome may involve block generation and verification nodes that fail to execute, as well as block generation and verification nodes that succeed. Therefore, the node health value of each target consensus node in the consensus node set can be updated based on the block production results of the transaction blocks in this consensus. Furthermore, updating the node health value allows for dynamic updates to the blockchain node health values, preventing the target consensus nodes from being the same in each consensus node set.

[0101] In one optional embodiment, the node health value of each target consensus node in the consensus node set is updated based on the block production result of the transaction block.

[0102] Optionally, based on the block production result of the transaction block, update the node health value of each target consensus node in the consensus node set, including: if block production is successful, increase the node health value of each target consensus node in the consensus node set; if block production fails, decrease the node health value of each target consensus node in the consensus node set.

[0103] If block production is successful, the health value of each target consensus node in the consensus node set is increased. For example, the health value of the block-generating node that successfully produces a block may increase by 5%, and the health value of the block-verifying node that successfully produces a block may increase by 3%; alternatively, both the block-generating node and the block-verifying node may increase by 5%. This embodiment does not impose any restrictions on this.

[0104] If block production fails, the node health value of each target consensus node in the consensus node set is reduced. For example, the node health value of the block-generating node that successfully produces a block can be reduced by 5%, and the node health value of the block-verifying node that successfully produces a block can be reduced by 3%; alternatively, both the node health value of the block-generating node and the block-verifying node that successfully produces a block can be reduced by 5%. This embodiment does not impose any restrictions on this.

[0105] For example, the percentage increase or decrease in the node health value of the consensus node set in the case of successful or failed block production can be preset by relevant technical personnel. Specifically, if block production is successful, the weight of the block-generating node and block-verifying node that successfully produced the block is increased by 50% of the difference from the highest health value. For example, if the highest health value is m and the current node health value is a, the node health value can be increased to a + (ma) * 50%. If block production fails, the health value of the block-generating node and block-verifying node set that failed to produce the block is reduced by 50% of the difference from the lowest health value. For example, if the lowest health value is n and the current node health value is a, the node health value can be reduced to a - (an) * 50%.

[0106] This embodiment's technical solution selects a target consensus node from the consensus node set as the block generation node; processes transactions through the block generation node to obtain transaction blocks; verifies the transaction blocks through block verification nodes other than the block generation node in the consensus node set to obtain the block consensus result; if there are verification errors in the block consensus result, a new block generation node is selected from the consensus node set. This solution improves the generation and verification methods of transaction blocks and enhances the accuracy of determining the block consensus result by determining the block generation node used to generate the transaction blocks, and by using the determined block verification node to verify the transaction blocks.

[0107] Example 4

[0108] Figure 4 This is a flowchart illustrating a blockchain node consensus method provided in Embodiment 4 of the present invention. Based on the above embodiments, this embodiment provides a preferred example.

[0109] like Figure 4 As shown, the method includes the following specific steps:

[0110] S401. Obtain the node health value of each blockchain node in the blockchain network in this consensus.

[0111] S402. Generate a random seed for the current iteration number based on distributed verifiable random numbers.

[0112] For example, if this iteration is the first iteration, then a distributed verifiable random number is used as the random seed for this iteration; if this iteration is not the first iteration, then the target random number of the previous iteration is used as the random seed for this iteration.

[0113] S403. Select the blockchain nodes that have not been identified as the target consensus node from among the blockchain nodes as the remaining consensus nodes in this iteration.

[0114] S404. Based on the node health values ​​of the remaining consensus nodes, generate a random distribution interval for this iteration number.

[0115] S405. Based on the random seed and the random distribution interval, generate the target random number for this iteration.

[0116] S406. Iterate through the remaining consensus nodes' health values ​​in sequence and determine the difference between the target random number and the currently iterated node's health value.

[0117] S407. If the difference is not greater than the health value of the currently traversed node, then the blockchain node corresponding to the health value of the currently traversed node is determined as the target consensus node for this iteration.

[0118] S408. If the difference is greater than the health value of the currently traversed node, then update the target random number to the difference and continue traversing the next node health value until the target consensus node for this iteration number is obtained.

[0119] S409. Generate a consensus node set based on the target consensus node under different iteration numbers.

[0120] S410. Select any target consensus node from the consensus node set as the block generation node, and use the target consensus nodes other than the block generation node in the consensus node set as block verification nodes.

[0121] S411. Process transactions through the block generation node to obtain transaction blocks.

[0122] S412. The pre-prepared message, including the transaction block, is signed and verified by the block verification node.

[0123] S413. If the signature verification passes, the transaction block is verified by the block verification node.

[0124] S414. If the block verification passes, the block verification node sends a preparation message to other block verification nodes in the consensus node set, and determines the initial voting result of the transaction block based on the number of preparation messages received.

[0125] S415. If the initial vote passes, the block verification node sends confirmation messages to other block verification nodes in the consensus node set, and the result of the second vote of the transaction block is determined by the number of confirmation messages received.

[0126] The block consensus result includes at least one of the following: signature verification result, block verification result, initial voting result, and secondary voting result.

[0127] S416. If there is a verification error in the block consensus result, a new block generation node shall be selected from the consensus node set.

[0128] S417. Based on the block consensus results, implement the creation of transaction blocks in the blockchain network.

[0129] S418. Based on the block production results of the transaction block, update the node health value of each target consensus node in the consensus node set.

[0130] For example, if block production is successful, the node health value of each target consensus node in the consensus node set is increased; if block production fails, the node health value of each target consensus node in the consensus node set is decreased.

[0131] Example 5

[0132] Figure 5 This is a schematic diagram of a blockchain node consensus device provided in Embodiment 5 of the present invention. The blockchain node consensus device provided in this embodiment of the present invention is applicable to node consensus in large-scale blockchain node scenarios. This blockchain node consensus device can be implemented in hardware and / or software, such as… Figure 5 As shown, the device specifically includes: a node health value acquisition module 501, a consensus node set determination module 502, a transaction block generation module 503, and a block production module 504. Among them,

[0133] The node health value acquisition module 501 is used to acquire the node health value of each blockchain node in the blockchain network during this consensus.

[0134] The consensus node set determination module 502 is used to determine the consensus node set based on the health value of each node and a pre-generated distributed verifiable random number; wherein the consensus node set includes at least one target consensus node;

[0135] The transaction block generation module 503 is used to generate and verify transaction blocks through the target consensus node in the consensus node set, and obtain the block consensus result;

[0136] The block generation module 504 is used to generate the transaction block in the blockchain network based on the block consensus result.

[0137] This invention's embodiment obtains the node health value of each blockchain node in the blockchain network during the current consensus process; determines a consensus node set based on each node's health value and a pre-generated distributed verifiable random number; generates and verifies transaction blocks through the blockchain nodes in the consensus node set to obtain a block consensus result; and produces a transaction block in the blockchain network based on the block consensus result. This technical solution improves consensus speed in large-scale blockchain scenarios by determining the consensus node set and using target consensus nodes within that set to complete the current consensus. Furthermore, by determining the consensus node set based on each node's health value and a pre-generated distributed verifiable random number, the randomness of each target consensus node within the determined consensus node set is increased, ensuring that the target consensus node is unknown to each blockchain node, thereby enhancing the security of the consensus process.

[0138] Optionally, the consensus node set determination module 502 includes:

[0139] The target random number generation unit is used to generate a target random number for the current iteration number based on the distributed verifiable random number and the health value of each node.

[0140] The target consensus node determination unit is used to determine the target consensus node for the current iteration number based on the target random number and the health value of each node.

[0141] The consensus node set generation unit is used to generate the consensus node set based on the target consensus node under different iteration numbers.

[0142] Optionally, the target random number generation unit includes:

[0143] The random seed generation subunit is used to generate a random seed for the current iteration number based on the distributed verifiable random number.

[0144] The random distribution interval generation sub-unit is used to generate the random distribution interval for the current iteration number based on the health values ​​of each node.

[0145] The target random number generation subunit is used to generate a target random number for the current iteration number based on the random seed and the random distribution interval.

[0146] Optionally, the random seed generation subunit is specifically used for:

[0147] If this iteration is the first iteration, then the distributed verifiable random number will be used as the random seed for this iteration.

[0148] If this iteration is not the first iteration, then the target random number of the previous iteration will be used as the random seed for this iteration.

[0149] Optionally, the random distribution interval generation sub-unit is specifically used for:

[0150] The blockchain nodes that were not identified as the target consensus nodes in each of the aforementioned blockchain nodes are taken as the remaining consensus nodes in this iteration.

[0151] Based on the node health values ​​of the remaining consensus nodes, a random distribution interval is generated for this iteration number.

[0152] Optionally, the target consensus node determination unit includes:

[0153] The remaining consensus node determination subunit is used to identify the blockchain nodes that have not been determined as the target consensus node in each of the blockchain nodes as the remaining consensus nodes in this iteration.

[0154] The target consensus node determination subunit is used to determine the target consensus node for the current iteration number based on the target random number and the node health value of each of the remaining consensus nodes.

[0155] Optionally, the target consensus node determining sub-unit is specifically used for:

[0156] The node health values ​​of the remaining consensus nodes are traversed sequentially, and the difference between the target random number and the currently traversed node health value is determined.

[0157] If the difference is not greater than the health value of the currently traversed node, then the blockchain node corresponding to the health value of the currently traversed node is determined as the target consensus node for this iteration.

[0158] If the difference is greater than the health value of the currently traversed node, the target random number is updated to the difference, and the traversal continues to the next node health value until the target consensus node for this iteration number is obtained.

[0159] Optionally, the transaction block generation module 503 includes:

[0160] A block generation node determination unit is used to select any target consensus node from the consensus node set as a block generation node;

[0161] A transaction block generation unit is used to process transactions through the block generation node to obtain transaction blocks.

[0162] The block consensus result determination unit is used to verify the transaction block through block verification nodes other than the block generation node in the consensus node set to obtain the block consensus result;

[0163] The block generation node reselection unit is used to reselect a block generation node from the consensus node set if there is a verification error in the block consensus result.

[0164] Optionally, the block consensus result determination unit includes:

[0165] The signature verification subunit is used to perform signature verification on the pre-prepared message including the transaction block through the block verification node;

[0166] The block verification subunit is used to perform block verification on the transaction block through the block verification node if the signature verification passes.

[0167] The initial voting result determination subunit is used to send a preparation message to other block verification nodes in the consensus node set through the block verification node if the block verification passes, and to determine the initial voting result of the transaction block based on the number of preparation messages received.

[0168] The secondary voting result determination subunit is used to send confirmation messages to other block verification nodes in the consensus node set through the block verification node if the initial vote passes, and to determine the secondary voting result of the transaction block by the number of confirmation messages received.

[0169] The block consensus result includes at least one of the following: signature verification result, block verification result, initial voting result, and secondary voting result.

[0170] Optionally, the device further includes:

[0171] The node health value update module is used to update the node health value of each target consensus node in the consensus node set according to the block production result of the transaction block.

[0172] Optionally, the node health value update module includes:

[0173] The node health value increment unit is used to increase the node health value of each target consensus node in the consensus node set if block production is successful.

[0174] The node health value reduction unit is used to reduce the node health value of each target consensus node in the consensus node set if block production fails.

[0175] The blockchain node consensus device provided in the embodiments of the present invention can execute the blockchain node consensus method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0176] Example 6

[0177] Figure 6 A schematic diagram of an electronic device 60 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0178] like Figure 6 As shown, the electronic device 60 includes at least one processor 61 and a memory, such as a read-only memory (ROM) 62 and a random access memory (RAM) 63, communicatively connected to the at least one processor 61. The memory stores computer programs executable by the at least one processor. The processor 61 can perform various appropriate actions and processes based on the computer program stored in the ROM 62 or loaded into the RAM 63 from storage unit 68. The RAM 63 may also store various programs and data required for the operation of the electronic device 60. The processor 61, ROM 62, and RAM 63 are interconnected via a bus 64. An input / output (I / O) interface 65 is also connected to the bus 64.

[0179] Multiple components in electronic device 60 are connected to I / O interface 65, including: input unit 66, such as keyboard, mouse, etc.; output unit 67, such as various types of monitors, speakers, etc.; storage unit 68, such as disk, optical disk, etc.; and communication unit 69, such as network card, modem, wireless transceiver, etc. Communication unit 69 allows electronic device 60 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0180] Processor 61 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 61 include, but are not limited to, central processing unit (CPU), graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 61 performs the various methods and processes described above, such as blockchain node consensus methods.

[0181] In some embodiments, the blockchain node consensus method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 68. In some embodiments, part or all of the computer program may be loaded into and / or installed on electronic device 60 via ROM 62 and / or communication unit 69. When the computer program is loaded into RAM 63 and executed by processor 61, one or more steps of the blockchain node consensus method described above may be performed. Alternatively, in other embodiments, processor 61 may be configured to execute the blockchain node consensus method by any other suitable means (e.g., by means of firmware).

[0182] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0183] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0184] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0185] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0186] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0187] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0188] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0189] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A blockchain node consensus method, characterized in that, include: Obtain the node health value of each blockchain node in the blockchain network in this consensus; Generate a random seed for the current iteration number based on pre-generated distributed verifiable random numbers; The blockchain nodes that were not identified as target consensus nodes in the previous iteration are taken as the remaining consensus nodes in the current iteration. Based on the sum of the node health values ​​of the remaining consensus nodes, a random distribution interval is generated for this iteration number; Based on the random seed and the random distribution interval, generate the target random number for the current iteration number; The node health values ​​of the remaining consensus nodes are traversed sequentially, and the difference between the target random number and the currently traversed node health value is determined. If the difference is not greater than the health value of the currently traversed node, then the blockchain node corresponding to the health value of the currently traversed node is determined as the target consensus node for this iteration. The target consensus node in this iteration is the blockchain node used to participate in this round of consensus; If the difference is greater than the health value of the currently traversed node, then the target random number is updated to the difference, and the next node health value is traversed until the target consensus node for this iteration number is obtained; A consensus node set is generated based on the target consensus node at different iteration numbers; wherein the consensus node set includes at least one target consensus node; By using the target consensus node in the consensus node set, a transaction block is generated and verified to obtain the block consensus result; Based on the consensus result of the block, the transaction block is generated in the blockchain network.

2. The method according to claim 1, characterized in that, The step of generating a random seed for the current iteration number based on the distributed verifiable random number includes: If this iteration is the first iteration, then the distributed verifiable random number will be used as the random seed for this iteration. If this iteration is not the first iteration, then the target random number of the previous iteration will be used as the random seed for this iteration.

3. The method according to any one of claims 1-2, characterized in that, The process of generating and verifying transaction blocks through the target consensus node in the consensus node set to obtain the block consensus result includes: Select any target consensus node from the set of consensus nodes as the block generation node; Transaction blocks are obtained by processing transactions through the block generation node. The transaction block is verified by block verification nodes other than the block generation nodes in the consensus node set, and the block consensus result is obtained. If there is a verification error in the block consensus result, a new block generation node will be selected from the consensus node set.

4. The method according to claim 3, characterized in that, The step of verifying the transaction block through block verification nodes other than the block generation nodes in the consensus node set to obtain the block consensus result includes: The block verification node performs signature verification on the prepared message, which includes the transaction block. If the signature verification passes, the transaction block is then verified by the block verification node. If the block verification passes, the block verification node sends a preparation message to other block verification nodes in the consensus node set, and the initial voting result of the transaction block is determined by the number of preparation messages received. If the initial vote passes, the block verification node sends a confirmation message to other block verification nodes in the consensus node set, and the second vote result of the transaction block is determined by the number of confirmation messages received. The block consensus result includes at least one of the following: signature verification result, block verification result, initial voting result, and secondary voting result.

5. The method according to claim 1, characterized in that, The method further includes: Based on the block production result of the transaction block, update the node health value of each target consensus node in the consensus node set.

6. The method according to claim 5, characterized in that, The step of updating the node health value of each target consensus node in the consensus node set according to the block production result of the transaction block includes: If block production is successful, the node health value of each target consensus node in the consensus node set is increased; If block production fails, the node health value of each target consensus node in the consensus node set is reduced.

7. A blockchain node consensus device, characterized in that, include: The node health value acquisition module is used to acquire the node health value of each blockchain node in the blockchain network during this consensus process. The consensus node set determination module is used to generate a random seed for the current iteration number based on a pre-generated distributed verifiable random number; to identify blockchain nodes that were not identified as target consensus nodes in the previous iteration number as remaining consensus nodes for the current iteration number; to generate a random distribution range for the current iteration number based on the sum of the node health values ​​of the remaining consensus nodes; to generate a target random number for the current iteration number based on the random seed and the random distribution range; and to sequentially traverse the node health values ​​of the remaining consensus nodes and determine the difference between the target random number and the currently traversed node health value. If the difference is not greater than the health value of the currently traversed node, then the blockchain node corresponding to the health value of the currently traversed node is determined as the target consensus node for this iteration. The target consensus node in this iteration is the blockchain node used to participate in this round of consensus; If the difference is greater than the health value of the currently traversed node, then the target random number is updated to the difference, and the next node health value is traversed until the target consensus node for this iteration number is obtained; A consensus node set is generated based on the target consensus node at different iteration numbers; wherein the consensus node set includes at least one target consensus node; The transaction block generation module is used to generate and verify transaction blocks through the blockchain nodes in the consensus node set to obtain the block consensus result; The block generation module is used to generate the transaction block in the blockchain network based on the block consensus result.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the blockchain node consensus method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the blockchain node consensus method according to any one of claims 1-6.

Images