Block chain consensus method and device, electronic equipment, storage medium and program product

Abstract

The invention discloses a block chain consensus method and related products, and the method comprises the steps: obtaining a transaction number of a to-be-consensus block in response to a proposal message of a proposal node for the to-be-consensus block, and obtaining a network quality parameter between the current proposal node and the proposal node; determining an initial proposal capability value of the proposal node according to the transaction quantity and the network quality parameter, adding the initial proposal capability value to a pre-voting message, and returning the pre-voting message to the proposal node, so that the proposal node fuses the initial proposal capability values from different consensus nodes to obtain a reference proposal capability value; and receiving a reference proposal capability value and a pre-voting message returned by the proposal node, and performing consensus according to the received pre-voting message to obtain a consensus result, the reference proposal capability value being used for determining the proposal node of the next round of consensus, and the probability that the proposal node is determined as the proposal node in the next round of consensus being positively correlated with the reference proposal capability value. Compared with the prior art, the consensus performance of the whole block chain network can be improved.

Description

Technical Field

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

[0002] Consensus mechanisms are fundamental to the proper functioning of blockchain systems. Consensus is the process of reaching agreement. Each node in a blockchain system stores a copy of the distributed ledger (i.e., the blockchain). The consensus process in a blockchain system is the process of maintaining consistency across these distributed ledgers.

[0003] In related technologies, the Byzantine fault-tolerant consensus mechanism is usually used to achieve blockchain consensus. Each block needs to go through three stages: proposal, pre-voting, and pre-submission. The consensus process is presided over by the proposal node (or master node), making the consensus efficiency of the blockchain closely related to the capabilities of the proposal node.

[0004] Currently, after a consensus is completed, the Byzantine Fault Tolerant consensus mechanism switches to another node in sequence to become the proposal node to preside over the next consensus process. This means that nodes of all capabilities in the blockchain have the same probability of being determined as proposal nodes, thereby affecting the overall consensus performance of the blockchain network. Summary of the Invention

[0005] The embodiments of the present application provide a blockchain consensus method, a blockchain consensus device, an electronic device, a computer-readable storage medium, and a computer program product, which can improve the overall consensus performance of the blockchain network.

[0006] First, the blockchain consensus method provided by this application includes:

[0007] In response to a proposal message from a proposal node in the blockchain network regarding a block to be agreed upon, obtain the number of transactions in the block to be agreed upon, and obtain the current network quality parameters between the proposal node and the proposal node;

[0008] Determine the initial proposal capacity value of the proposal node based on the number of transactions and network quality parameters, and add the initial proposal capacity value to the pre-voting message;

[0009] Return the pre-voting message to the proposal node. The pre-voting message is used by the proposal node to integrate the initial proposal capability values ​​from different consensus nodes in the blockchain network to obtain the reference proposal capability value of the proposal node.

[0010] Receive the reference proposal capability value returned by the proposal node, as well as the pre-voting messages from other consensus nodes in the blockchain network, and reach consensus on the consensus block based on the received pre-voting messages to obtain the consensus result;

[0011] Among them, the reference proposal capability value is used to determine the proposal node for the next round of consensus, and the probability of a proposal node being determined as a proposal node in the next round of consensus is positively correlated with the reference proposal capability value.

[0012] Secondly, the blockchain consensus method provided by this application may also include:

[0013] Generate a proposal message for the block to be agreed upon and send it to the consensus node in the blockchain network. The proposal message is used to instruct the consensus node to obtain the transaction number of the block to be agreed upon, as well as the network quality parameters between the consensus node and the proposal node. Based on the transaction number and network quality parameters, the consensus node determines the initial proposal capability value of the proposal node, adds it to the pre-voting message, and returns it to the proposal node.

[0014] Receive pre-voting messages returned by different consensus nodes in the blockchain network, and integrate the initial proposal capability values ​​from different consensus nodes in the blockchain network to obtain the reference proposal capability value;

[0015] Aggregate pre-voting messages from different consensus nodes in the blockchain network to obtain a pre-voting message set;

[0016] The pre-voting message set and the reference proposal capability value are returned to different consensus nodes. The pre-voting message set is used by the consensus nodes to reach consensus on the consensus block and obtain the consensus result. The reference proposal capability value is used to determine the proposal node for the next round of consensus. The probability of the proposal node being determined as the proposal node in the next round of consensus is positively correlated with the reference proposal capability value.

[0017] Thirdly, the blockchain consensus device provided by this application includes:

[0018] A data acquisition module is used to respond to a proposal message from a proposal node in the blockchain network regarding a block to be agreed upon, obtain the number of transactions in the block to be agreed upon, and obtain the current network quality parameters between the proposal node and the proposal node;

[0019] The capability determination module is used to determine the initial proposal capability value of the proposal node based on the number of transactions and network quality parameters, and add the initial proposal capability value to the pre-voting message;

[0020] The first data transmission module is used to return the pre-voting message to the proposal node. The pre-voting message is used by the proposal node to integrate the initial proposal capability values ​​from different consensus nodes in the blockchain network to obtain the reference proposal capability value of the proposal node;

[0021] The block consensus module is used to receive the reference proposal capability value returned by the proposal node and the pre-voting messages of other consensus nodes in the blockchain network, and to reach a consensus on the consensus block based on the received pre-voting messages to obtain the consensus result;

[0022] Among them, the reference proposal capability value is used to determine the proposal node for the next round of consensus, and the probability of a proposal node being determined as a proposal node in the next round of consensus is positively correlated with the reference proposal capability value.

[0023] Optionally, in one embodiment, the network quality parameter includes at least one of the following: a waiting time for receiving a proposal message, a current network delay between the proposal node and the proposal node, and an available bandwidth between the proposal node and the proposal node; the capacity determination module is configured to determine an initial proposal capacity value of the proposal node based on the number of transactions and at least one of the waiting time, the network delay, and the available bandwidth;

[0024] Among them, the initial proposal capacity value is positively correlated with the number of transactions, negatively correlated with the waiting time, negatively correlated with the network delay, and positively correlated with the available bandwidth.

[0025] Optionally, in one embodiment, the capacity determination module is used to perform a division operation on the transaction quantity and the waiting time to obtain a division result; determine a subtraction compensation value for the division result based on the network delay, and the subtraction compensation value is positively correlated with the network delay; determine an addition compensation value for the division result based on the available bandwidth, and the addition compensation value is positively correlated with the available bandwidth; and compensate the division result based on the subtraction compensation value and the addition compensation value to obtain the initial proposal capacity value of the proposal node.

[0026] Optionally, in one embodiment, the blockchain consensus device provided by the present application also includes a node determination module, which is used to divide the numerical intervals corresponding to different nodes and in sequence according to the reference proposal capability values ​​corresponding to different nodes in the blockchain network, wherein the range of the numerical interval is positively correlated with the reference proposal capability value; randomly determine the index value of the new proposal node, and determine the node corresponding to the numerical interval including the index value as the new proposal node.

[0027] Optionally, in one embodiment, the node determination module is used to obtain the block hash value of the block to be agreed upon, and determine the index value of the new proposal node based on the block hash value.

[0028] Optionally, in one embodiment, the node determination module is used to determine the sum of the reference proposal capability values ​​corresponding to all nodes in the blockchain network; and perform a division operation on the block hash value and the sum value, and determine the remainder obtained by the division operation as the index value of the new proposal node.

[0029] Optionally, in one embodiment, the node determination module is also used to obtain the stored fused proposal capability value of the proposal node, which is obtained by fusion based on the historical reference proposal capability value of the proposal node; and to update the reference proposal capability value of the proposal node based on the fused proposal capability value.

[0030] Optionally, in one embodiment, the node determination module is used to divide the initial numerical intervals corresponding to different nodes and consecutively according to the reference proposal capability values ​​corresponding to different nodes in the blockchain network; and adjust the initial numerical intervals of different nodes according to the cumulative number of proposals of different nodes in the blockchain network to obtain numerical intervals of different nodes that are consecutively.

[0031] Fourthly, the blockchain consensus device provided by this application may further include:

[0032] The proposal generation module is used to generate a proposal message for the block to be agreed upon and send the proposal message to the consensus node in the blockchain network. The proposal message is used to instruct the consensus node to obtain the transaction number of the block to be agreed upon and the network quality parameters between the consensus node and the proposal node. Based on the transaction number and network quality parameters, the initial proposal capability value of the proposal node is determined and added to the pre-voting message and returned to the proposal node.

[0033] The capability fusion module is used to receive pre-voting messages returned by different consensus nodes in the blockchain network, and fuse the initial proposal capability values ​​from different consensus nodes in the blockchain network to obtain the reference proposal capability value;

[0034] The message aggregation module is used to aggregate pre-voting messages from different consensus nodes in the blockchain network to obtain a pre-voting message set;

[0035] The second data transmission module is used to return the pre-voting message set and the reference proposal capability value to different consensus nodes. The pre-voting message set is used by the consensus nodes to reach consensus on the consensus block and obtain the consensus result. The reference proposal capability value is used to determine the proposal node for the next round of consensus, and the probability of the proposal node being determined as the proposal node in the next round of consensus is positively correlated with the reference proposal capability value.

[0036] Optionally, in one embodiment, the capability fusion module is used to determine the fusion weights corresponding to different consensus nodes in the blockchain network; based on the fusion weights corresponding to different consensus nodes, the initial proposal capability values ​​from different consensus nodes are fused to obtain a reference proposal capability value.

[0037] In the fifth aspect, the electronic device provided in this application includes a memory and a processor, the memory stores a computer program, and the processor is used to run the computer program in the memory to implement the steps in the blockchain consensus method provided in this application.

[0038] In a sixth aspect, the computer-readable storage medium provided in this application stores a computer program, which is suitable for execution by a processor to implement the steps in the blockchain consensus method provided in this application.

[0039] In the seventh aspect, the computer program product provided by this application includes a computer program or instructions, which, when executed by a processor, implement the steps in the blockchain consensus method provided by this application.

[0040] The technical solution for blockchain consensus provided by this application improves the current Byzantine fault-tolerant consensus mechanism, wherein the pre-voting stage of the Byzantine fault-tolerant consensus mechanism is changed into two pre-voting sub-stages. In the first pre-voting sub-stage, the consensus node responds to the proposal message of the proposal node in the blockchain network for the block to be agreed upon, obtains the number of transactions of the block to be agreed upon, and obtains the network quality parameters between the current and the proposal node, and determines the initial proposal capability value of the proposal node based on the obtained number of transactions and network quality parameters, and adds the initial proposal capability value to the return value proposal node in the pre-voting message. In the second pre-voting sub-stage, the proposal node fuses the initial proposal capability values ​​from different consensus nodes in the blockchain network to obtain a reference proposal capability value, and returns the reference proposal capability value together with the received pre-voting message to the consensus node in the blockchain network. Compared with the conventional pre-voting stage of the Byzantine fault-tolerant consensus mechanism, in the improved pre-voting stage of the technical solution of the present application, in addition to being able to obtain pre-voting messages from other consensus nodes for subsequent consensus processes, the consensus node can also obtain a reference proposal capability value that reflects the proposal capability of the node in the blockchain network as a proposal node. Therefore, on the premise of completing the consensus process normally, the proposal node for the next round of consensus can be determined based on the additional reference proposal capability value obtained, where the probability of a node being determined as a proposal node is positively correlated with its corresponding reference proposal capability value. In this way, nodes with strong proposal capabilities have a greater probability of being determined as proposal nodes, thereby shortening the time spent in the proposal stage, and then shortening the overall time spent in the consensus process, and ultimately achieving the purpose of improving the overall consensus performance of the blockchain network. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0042] Figure 1a This is a schematic diagram of the blockchain network in the embodiment of the present application;

[0043] Figure 1b It is a schematic diagram of the blockchain in the embodiment of the present application;

[0044] Figure 1c This is a diagram of the consensus process of the current Byzantine fault-tolerant consensus mechanism;

[0045] Figure 1d This is a flowchart of a blockchain consensus method provided by an embodiment of the present application;

[0046] Figure 1e This is an example diagram of the proposal capability mapping maintained by the node in the embodiment of the present application;

[0047] Figure 1f Schematic diagram of the consensus process of the improved Byzantine fault-tolerant consensus mechanism in the embodiment of the present application;

[0048] Figure 2 This is another flowchart of the blockchain consensus method provided by an embodiment of the present application;

[0049] Figure 3 This is a schematic diagram of the structure of the blockchain consensus device provided by an embodiment of the present application;

[0050] Figure 4 This is another structural diagram of the blockchain consensus device provided in an embodiment of the present application;

[0051] Figure 5 It is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0052] It should be noted that the principles of this application are illustrated by implementing them in an appropriate computing environment. The following description is based on the illustrated specific embodiments of this application and should not be considered as limiting other specific embodiments not described in detail herein.

[0053] In the following description of this application, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it can be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict.

[0054] In the following description of this application, the terms "first\second\third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0055] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

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

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

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

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

[0060] Each node in a blockchain network has a corresponding node identifier. Furthermore, each node in the blockchain network can store the node identifiers of other nodes in the network, allowing it to subsequently broadcast generated blocks to other nodes in the blockchain network based on those identifiers. Each node maintains a node identifier list, storing the node name and node identifier in the corresponding list. A node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node.

[0061] Each node in the blockchain network stores the same blockchain. The blockchain consists of multiple blocks, see Figure 1b The blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores the input information feature value, version number, timestamp and difficulty value, and the block body stores the input information; the next block of the genesis block uses the genesis block as the parent block, and the next block also includes a block header and a block body. The block header stores the input information feature value of the current block, the block header feature value, version number, timestamp and difficulty value of the parent block, and so on, so that the block data stored in each block in the blockchain is associated with the block data stored in the parent block, ensuring the security of the input information in the block.

[0062] It should be noted that whether a new block can be added to the blockchain depends on whether the nodes in the blockchain network can reach a consensus on the new block. Typically, at least one round of consensus is required at a certain block height in the blockchain. The block height is used to represent the number of blocks connected to the blockchain and can be used to indicate the block's position in the blockchain. For example, the block height of the genesis block in the blockchain defaults to 0, the block height of the first block after the genesis block is 1 (this first block can be simply referred to as block 1), the block height of the second block after the genesis block is 2 (this second block can be simply referred to as block 2), and so on. The consensus process at a certain block height in the blockchain refers to the process of reaching consensus on the blocks to be added to the blockchain system when the blockchain is at that certain block height. If the consensus on the block to be added to the blockchain is successful, the block is added to the blockchain, and the block height of the blockchain is increased by 1. For example, the consensus process at block height 27 of the blockchain refers to the process of reaching consensus on the blocks to be added to the blockchain system when the blockchain is at block height 27. If the consensus on the block is successful, the block is added to the blockchain, causing the block height of the blockchain to increase from 27 to 28.

[0063] The consensus process for blocks depends on the consensus algorithm used by the blockchain network. The technical solution provided in this application involves a Byzantine fault-tolerant consensus mechanism, aiming to improve the overall consensus performance of the blockchain network.

[0064] Please refer to Figure 1c Currently, a round of consensus process based on the Byzantine fault-tolerant consensus mechanism is divided into three consensus stages according to the execution order:

[0065] During the proposal phase, the proposal node in the blockchain network packages the blocks to generate a proposal message, which is then sent to the consensus node in the blockchain network for verification. The proposal node is sequentially served by the nodes in the blockchain network and is responsible for presiding over the consensus process. The consensus node is the node in the blockchain network that participates in the consensus process in addition to the proposal node.

[0066] In the pre-voting phase, the consensus node pre-votes on the proposal message. Pre-voting refers to the process of whether to agree to pre-vote on the consensus block. If it agrees to pre-vote on the consensus block, a pre-voting message is generated and sent to the proposal node and other consensus nodes, indicating that they agree to add the block to the blockchain.

[0067] In the pre-submission phase, the proposal node / consensus node performs pre-submission processing. Pre-submission processing refers to the process of whether to agree to pre-submit the consensus block. If the consensus block is agreed to be pre-submitted, it means that the block is confirmed to be added to the blockchain.

[0068] To improve the overall consensus performance of a blockchain network, embodiments of the present application provide a blockchain consensus method, a blockchain consensus device, an electronic device, a computer-readable storage medium, and a computer program product. By improving the pre-voting phase of the Byzantine Fault Tolerant consensus mechanism, the probability of high-capability nodes being determined as proposal nodes is increased, while the probability of low-capability nodes being determined as proposal nodes is reduced, thereby improving the overall consensus performance of the blockchain network. The blockchain consensus method can be executed by the blockchain consensus device, or by an electronic device incorporating the blockchain consensus device.

[0069] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without making creative efforts are within the scope of protection of this application.

[0070] Please refer to Figure 1d , Figure 1d This is a flowchart of the blockchain consensus method provided by the embodiment of the present application. In the following embodiments, the electronic device executes the blockchain consensus method as a consensus node, such as Figure 1d As shown, the process of the blockchain consensus method provided by this application is as follows:

[0071] In 110, in response to a proposal message of a proposal node in the blockchain network for a block to be agreed upon, the number of transactions of the block to be agreed upon is obtained, and a current network quality parameter between the proposal node and the proposal node is obtained.

[0072] A proposal node, also known as a master node, is a node in a blockchain network that is designated to preside over the consensus process. All nodes in a blockchain network can be designated as proposal nodes.

[0073] Consensus nodes, also known as slave nodes, are nodes in a blockchain network that participate in the consensus process, excluding proposal nodes. For example, a blockchain network consists of nodes A, B, C, D, and E. If node A is determined to host the consensus process, then node A is the proposal node, and nodes B, C, D, and E are consensus nodes.

[0074] A pending consensus block refers to a block obtained by the proposing node by packaging transactions in the transaction pool during the current consensus cycle, and requires consensus to be reached before it can be uploaded to the blockchain. For example, during the consensus process at block height 10, node A in the blockchain network is determined to be the proposing node. Node A (the proposing node) packages a total of 10,000 transactions, resulting in the pending consensus block for that consensus process. It should be noted that the block packaging method can be implemented by referring to relevant technologies and will not be elaborated here.

[0075] According to the Byzantine Fault Tolerant consensus mechanism, after a proposal node obtains a block to be agreed upon by packaging transactions in the transaction pool, it generates a proposal message corresponding to that block and sends it to the consensus nodes in the blockchain network. The proposal message includes data such as the block to be agreed upon and the consensus status, which includes information such as the current block height, the current consensus round, and the currently locked block. It should be noted that the proposal message is generated according to the specifications of the Byzantine Fault Tolerant consensus mechanism and will not be further elaborated here.

[0076] In an embodiment of the present application, the electronic device acts as a consensus node in the blockchain network and receives a proposal message for the block to be agreed upon initiated by the proposal node in the blockchain network. In response to the proposal message, the electronic device parses the received proposal message and obtains the transaction number of the packaged transactions of the block to be agreed upon.

[0077] In addition, the electronic device also obtains the network quality parameters between the electronic device and the proposal node according to the configured network quality parameter evaluation strategy. There is no specific restriction on the configuration of the network quality parameter evaluation strategy here, and it can be configured by technical personnel in this field according to actual needs.

[0078] Exemplarily, the configured network quality parameter evaluation strategy is to select at least one of the following as the network quality parameter between the electronic device and the proposal node:

[0079] The waiting time for an electronic device to receive a proposal message after entering the proposal phase as a consensus node. The waiting time is negatively correlated with network quality, meaning the longer the waiting time, the worse the network quality.

[0080] The network delay between the electronic device acting as the consensus node and the proposal node is negatively correlated with network quality, that is, the greater the network delay, the worse the network quality;

[0081] The available bandwidth between the electronic device acting as the consensus node and the proposal node. Here, the available bandwidth refers to the bandwidth between the two that can be used for the consensus process. The available bandwidth is positively correlated with the network quality. That is, the larger the available bandwidth, the better the network quality.

[0082] In 120 , an initial proposal capability value of the proposal node is determined based on the transaction quantity and the network quality parameter, and the initial proposal capability value is added to the pre-voting message.

[0083] It is understandable that the time spent in the proposal phase accounts for the majority of the time spent in the entire consensus process. If nodes with stronger proposal capabilities can be preferentially selected as proposal nodes, the time spent in the proposal phase will be effectively shortened, thereby effectively shortening the time spent in the entire consensus process, thereby improving the overall consensus performance of the blockchain network. With the priority selection of nodes with stronger proposal capabilities as proposal nodes, the proposal capabilities of nodes in the blockchain network are evaluated in the embodiments of this application.

[0084] It should be noted that the higher the hardware configuration of the proposal node, the faster it packages transactions, the more transactions in the corresponding block to be agreed upon, and the higher the proposal capability. In addition, the worse the network quality between the electronic device serving as the consensus node and the proposal node, the longer it takes for the proposal node to send the proposal message to the consensus node, and the lower the proposal capability. Accordingly, after the electronic device serving as the consensus node obtains the number of transactions in the block to be agreed upon and the network quality parameters between the electronic device and the proposal node, it further determines the initial proposal capability value of the proposal node according to the configured proposal capability evaluation strategy and the obtained number of transactions and network quality parameters. There is no specific limitation on the configuration of the proposal capability evaluation strategy here, and it can be configured by those skilled in the art according to actual needs.

[0085] In addition to determining the initial proposal capability value of the proposal node, the electronic device, as a consensus node, also performs pre-voting processing according to the Byzantine Fault Tolerant consensus mechanism and generates corresponding pre-voting messages. For details, please refer to the specifications of the Byzantine Fault Tolerant consensus mechanism for the generation of pre-voting messages, which will not be detailed here.

[0086] Unlike the current Byzantine Fault Tolerant consensus mechanism, in the embodiments of this application, the electronic device, acting as a consensus node, after determining the initial proposal capability value of the proposal node, also adds the determined initial proposal capability value to the generated pre-voting message. The method for adding the initial proposal capability value is not specifically limited here and can be selected by those skilled in the art based on actual needs.

[0087] Optionally, in one embodiment, the network quality parameter includes at least one of the following: the waiting time for receiving the proposal message, the current network delay between the proposal node and the proposal node, and the current available bandwidth between the proposal node and the proposal node. The initial proposal capacity value of the proposal node is determined based on the number of transactions and the network quality parameter, including:

[0088] The initial proposal capacity value of the proposal node is determined based on the number of transactions and at least one of the waiting time, network latency, and available bandwidth.

[0089] In an embodiment of the present application, the electronic device serves as a consensus node and can determine the initial proposal capability value of the proposal node based on the obtained number of transactions of the block to be consensus and some or all of the obtained network quality parameters, with the constraints that the initial proposal capability value is positively correlated with the number of transactions, the initial proposal capability value is negatively correlated with the waiting time, the initial proposal capability value is negatively correlated with the network delay, and the initial proposal capability value is positively correlated with the available bandwidth. The above method of determining the initial proposal capability value can be determined by those skilled in the art according to actual needs, and no specific restrictions are made here.

[0090] For example, when only the waiting time is selected to determine the initial proposal capability value, it is determined according to the following formula:

[0091] Cap = Con / t;

[0092] Among them, Cap represents the initial proposal capacity value, Con represents the number of transactions awaiting consensus, and t represents the waiting time for the electronic device as a consensus node from entering the proposal stage to receiving the proposal message for the block to be agreed upon.

[0093] Optionally, in one embodiment, the initial proposal capability value of the proposal node is determined based on the number of transactions and at least one of the waiting time, network latency, and available bandwidth, including:

[0094] Divide the transaction quantity and the waiting time to obtain the division result;

[0095] Determine a subtraction compensation value for the division result according to the network delay, where the subtraction compensation value is positively correlated with the network delay;

[0096] determining an additive compensation value for the division result according to the available bandwidth, where the additive compensation value is positively correlated with the available bandwidth;

[0097] The division result is compensated according to the subtraction compensation value and the addition compensation value to obtain the initial proposal capability value of the proposal node.

[0098] In an embodiment of the present application, an optional method for determining the initial proposal capability value of a proposal node is provided, wherein the electronic device, as a consensus node, first divides the transaction quantity and the waiting time to obtain a division result; then, a subtraction compensation value for the division result is further determined based on the network delay, and the subtraction compensation value is positively correlated with the network delay, and is used to perform subtraction compensation on the division result, and an addition compensation value for the division result is further determined based on the available bandwidth, and the addition compensation value is positively correlated with the available bandwidth, and is used to perform addition compensation on the division result; finally, the division result is compensated according to the determined subtraction compensation value and addition compensation value, and the compensated division result is used as the initial proposal capability value of the proposal node. It should be noted that the embodiment of the present application does not impose any specific restrictions on the method for determining the addition compensation value and the subtraction compensation value. It is constrained that the subtraction compensation value is positively correlated with the network delay and the addition compensation value is positively correlated with the available bandwidth, and can be determined by those skilled in the art according to actual needs.

[0099] For example, the above process of determining the initial proposal capability value of the proposal node can be expressed as:

[0100] Cap = Con / ta*Del+b*Wid;

[0101] Wherein, Cap represents the initial proposal capacity value of the proposal node, Con represents the number of transactions in the block to be agreed upon, t represents the waiting time for the electronic device as a consensus node from entering the proposal stage to receiving the proposal message for the block to be agreed upon, a represents the subtraction compensation coefficient, Del represents the network delay between the electronic device as a consensus node and the proposal node, b represents the addition compensation coefficient, and Wid represents the available bandwidth between the electronic device as a consensus node and the proposal node. It should be noted that the subtraction compensation coefficient a and the addition compensation coefficient b can be determined by those skilled in the art based on expert knowledge and / or prior knowledge and are not specifically limited here.

[0102] In 130, the pre-voting message is returned to the proposal node. The pre-voting message is used by the proposal node to fuse the initial proposal capability values ​​from different consensus nodes in the blockchain network to obtain the reference proposal capability value of the proposal node.

[0103] It should be noted that, unlike the current Byzantine fault tolerance mechanism, the electronic device as a consensus node does not send the pre-voting message with the initial proposal capability value added to all other nodes in the blockchain network, but only sends it to the proposal node. In the embodiment of the present application, the consensus nodes in the blockchain network will each determine the initial proposal capability value of the proposal node in the same way as described above, and add it to the pre-voting message generated by itself, and return it to the proposal node. In this way, ideally, the proposal node will receive the pre-voting messages returned by all consensus nodes in the blockchain network, and these pre-voting messages will add the initial proposal capability value of the proposal node determined by each consensus node.

[0104] To ensure the normal progress of the consensus process, after the number of pre-voting messages received by a proposal node reaches a threshold, it integrates the initial proposal capacity values ​​from consensus nodes in the blockchain network to obtain a reference proposal capacity value for the proposal node. The threshold value can be set by those skilled in the art based on practical needs. For example, the threshold value can be set to 2n / 3+1, where n represents the number of nodes in the blockchain network, as referenced by the Byzantine Fault Tolerant consensus mechanism. The method for integrating the initial proposal capacity values ​​is not specifically limited and can be configured by those skilled in the art based on practical needs.

[0105] In an embodiment of the present application, after the proposal node obtains the reference proposal capability value by fusing the initial proposal capability values ​​from different consensus nodes in the blockchain network, it returns the reference proposal capability value together with the received pre-voting message to the consensus node in the blockchain network. For example, the blockchain network includes nodes A, B, C, D and E, where node A is determined to be the proposal node, and nodes B, C, D and E are consensus nodes. Proposal node A receives pre-voting messages from consensus nodes B, C, D and E. Proposal node A parses the initial proposal capability values ​​from the pre-voting messages of the aforementioned consensus nodes and fuses them into the reference proposal capability value. The pre-voting messages from consensus nodes C, D and E are stripped of the added initial proposal capability value and returned together with the reference proposal capability value. The pre-voting messages from consensus nodes B, consensus nodes D, and consensus nodes E are returned to consensus node B together with the reference proposal capability value after removing the added initial proposal capability value. The pre-voting messages from consensus nodes B, consensus nodes C, and consensus nodes E are returned to consensus node D together with the reference proposal capability value after removing the added initial proposal capability value. The pre-voting messages from consensus nodes B, consensus nodes C, and consensus nodes E are returned to consensus node E together with the reference proposal capability value after removing the added initial proposal capability value.

[0106] In 140, the reference proposal capability value returned by the proposal node and the pre-voting messages of other consensus nodes in the blockchain network are received, and consensus is performed on the consensus block based on the received pre-voting messages to obtain a consensus result; wherein, the reference proposal capability value is used to determine the proposal node for the next round of consensus, and the probability of the proposal node in the current consensus process being determined as the proposal node in the next round of consensus is positively correlated with the reference proposal capability value.

[0107] As described above, the electronic device, acting as a consensus node, will receive the reference proposal capability value returned by the proposal node, as well as pre-voting messages from other consensus nodes in the blockchain network. At this point, the electronic device, acting as a consensus node, has received pre-voting messages from other consensus nodes in the blockchain network, effectively completing the pre-voting phase of the Byzantine Fault Tolerant consensus mechanism. Following the Byzantine Fault Tolerant consensus mechanism specifications, the electronic device can then proceed to the pre-commit phase, completing consensus on the pending consensus block and obtaining the corresponding consensus result. If consensus on the pending consensus condition is reached, the pending consensus condition is added to the blockchain network.

[0108] According to the technical solutions described above in the embodiments of the present application, each node in the blockchain network will obtain the reference proposal capability values ​​of all nodes as proposal nodes. Among them, for nodes that have not yet been determined as proposal nodes, their reference proposal capability values ​​can be configured to preset initial values ​​(which can be configured by technicians in this field according to actual needs, without specific restrictions here, for example, it can be configured to 100).

[0109] As described above, the reference proposal capability value of a node can reflect the node's ability to make proposals as a proposal node. Accordingly, in the embodiment of the present application, the reference proposal capability value of the node is used to determine the proposal node, wherein the probability of the node being determined as a proposal node is positively correlated with the reference proposal capability value corresponding to the node. The method of determining the proposal node can be configured by those skilled in the art according to actual needs.

[0110] It can be understood that the reference proposal capability value obtained in the current consensus process reflects the proposal capability of the proposal node in the current consensus process. In the next round of consensus, the probability of the proposal node in the current consensus process being determined as a proposal node is positively correlated with its reference proposal capability value.

[0111] Optionally, in one embodiment, an optional method of determining a proposal node based on a reference proposal capability value of a node is provided, wherein consensus is performed on the consensus block based on the received pre-voting message, and after a consensus result is obtained, the method further includes:

[0112] According to the reference proposal capability values ​​corresponding to different nodes in the blockchain network, the corresponding value intervals are divided into consecutive intervals;

[0113] The index value of the new proposal node is randomly determined, and the node corresponding to the numerical interval including the index value is determined as the new proposal node.

[0114] Based on the relevant description of the above technical solution, it can be understood that when any node in the blockchain network is determined to be a proposal node to preside over the consensus process, it will obtain a reference proposal capability value for that node as a proposal node, which is used to reflect the proposal capability of that node as a proposal node. In this way, each node in the blockchain network will obtain the reference proposal capability value of all nodes in the blockchain network as proposal nodes.

[0115] In an embodiment of the present application, in order to better maintain the reference proposal capability values ​​of different nodes in the blockchain network, all nodes in the blockchain network each maintain a mapping of node proposal capabilities, where the key of the mapping is the node identifier of the node in the blockchain network, and the value includes the reference proposal capability value of the node indicated by the node identifier, and all nodes update the mapping they maintain based on the reference proposal capability value of the node determined as the proposal node during each consensus process.

[0116] Please refer to Figure 1e ,There are four nodes in the blockchain network, namely node A (node ​​identifier is nodeid1), node B (node ​​identifier is nodeid2), node C (node ​​identifier is nodeid3) and node D (node ​​identifier is nodeid4). The mapping of node proposal capabilities maintained by the four nodes is the same, such as Figure 1e As shown in the figure, when the nodes in the blockchain network have not completed the first consensus process, the reference proposal capability value of each node in the blockchain network is configured to be 100 by default. Assuming that node A is determined as the proposal node in the first consensus process, and the reference proposal capability value of node A is determined to be 200 during this consensus process, the four nodes in the blockchain network will update the reference proposal capability value of node A in the mapping they maintain to 200.

[0117] After completing the previous round of consensus process, the electronic device, as a consensus node, determines the proposal node for the next round of consensus process according to the proposal node determination method provided in the embodiment of the present application.

[0118] As a node in the blockchain network, the electronic device first obtains the reference proposal capability value corresponding to each node in the blockchain network from the maintained proposal capability mapping, and uses the positive correlation between the range of the numerical interval and the reference proposal capability value as a constraint. According to the reference proposal capability value corresponding to each node in the blockchain network, the numerical interval corresponding to different nodes and continuous in sequence is divided.

[0119] For example, a blockchain network includes three nodes, namely node A, node B, and node C, where the reference proposal capability value of node A is 100, the reference proposal capability value of node B is 200, and the reference proposal capability value of node C is 300. The numerical interval of the divided node A is [1, 100], the numerical interval of the divided node B is [101, 300], and the numerical interval of the divided node C is [310, 600].

[0120] Then, according to the configured index value determination strategy, the index value of the new proposal node is randomly determined. The index value determined by the index value determination strategy is constrained to fall within a range of values. The index value determination strategy can be configured by those skilled in the art based on actual needs.

[0121] As described above, after randomly determining the index value of the new proposal node, the electronic device, as a node in the blockchain network, determines the numerical interval into which the index value falls, and determines the node corresponding to the interval into which the index value falls as the new proposal node, that is, the node corresponding to the numerical interval including the index value is determined as the new proposal node.

[0122] It can be understood that the index value of the new proposal node is randomly determined, and the numerical range corresponding to different nodes is positively correlated with its reference proposal capability value. That is, the larger the reference proposal capability value of a node in the blockchain network, the larger the range of the numerical range allocated to the node. Therefore, the probability that the index value falls into the numerical range of the node is greater, and the probability that the node is determined as a new proposal node is greater.

[0123] Optionally, in one embodiment, an index value determination strategy is provided, wherein the index value of a new proposal node is randomly determined, including:

[0124] Get the block hash value of the block to be consensus, and determine the index value of the new proposal node based on the block hash value.

[0125] In an embodiment of the present application, when determining the index value of a new proposal node, the electronic device, acting as a node in a blockchain network, first obtains the block hash value of the block to be agreed upon during the previous consensus process and then performs a preset mathematical operation based on the obtained block hash value to obtain an index value that falls within the numerical range of a node in the blockchain network. With the constraint that the result of the mathematical operation on the block hash value falls within the numerical range of a node in the blockchain network, those skilled in the art can configure the above preset mathematical operation according to actual needs.

[0126] It can be understood that the block hash value is obtained by hashing the block and is random. Further, by performing a preset mathematical operation on the block hash value of the consensus block, the index value of the new proposal node obtained is also random.

[0127] In one embodiment, an optional preset mathematical operation method is further provided, wherein the index value of the new proposal node is determined according to the block hash value, including:

[0128] Determine the sum of the reference proposal capability values ​​corresponding to all nodes in the blockchain network;

[0129] Divide the block hash value and the sum value, and use the remainder obtained from the division as the index value of the new proposal node.

[0130] When determining the index value of the new proposal node based on the obtained block hash value, the sum of the reference proposal capability values ​​corresponding to all nodes in the blockchain network is first calculated. Then, the obtained block hash value is divided by the above sum, and the remainder obtained by the division operation is determined as the index value of the new proposal node, which can be expressed as:

[0131] proposerIndex=blockHash mod Sum;

[0132] Among them, proposerIndex represents the index value of the new proposal node, blockHash represents the obtained block hash value, and Sum represents the sum of the reference proposal capability values ​​corresponding to all nodes in the blockchain network.

[0133] In other embodiments, the historical block hash value corresponding to the historical consensus process before the last consensus process can also be obtained, and the index value of the new proposal node can be determined in the same manner as above.

[0134] Optionally, in one embodiment, before dividing the reference proposal capability values ​​corresponding to different nodes in the blockchain network into consecutive value intervals, the method further includes:

[0135] Get the stored proposal node's fused proposal capability value, which is obtained by fusion based on the proposal node's historical reference proposal capability value;

[0136] Update the reference proposal capability value of the proposal node according to the fusion proposal capability value.

[0137] In an embodiment of the present application, the proposal capability map maintained by the node in the blockchain network does not store the originally determined reference proposal capability value, but rather a fused proposal capability value that integrates the historical reference proposal capability values ​​when the node was determined as a proposal node during the historical consensus process.

[0138] As a node in the blockchain network, the electronic device first obtains the stored fusion proposal capability value of the proposal node in the previous round of consensus process before dividing the numerical interval. The fusion proposal capability value is obtained by fusing the historical reference proposal capability value of the historical consensus process before the previous round of consensus process of the proposal node; then, the reference proposal capability value of the proposal node is further updated according to the obtained fusion proposal capability value.

[0139] Among them, the electronic device, as a node in the blockchain network, can determine the first weight of the configured fusion proposal capability value and the second weight of the configured reference proposal capability value, use the weighted sum of the two as the updated reference proposal capability value, and store the updated reference proposal capability value as the new fusion proposal capability value in the maintained proposal capability map. There is no specific limitation on the configuration of the first weight and the second weight here, and those skilled in the art can configure them according to actual needs, such as

[0140] The following uses node A as an example:

[0141] Assume that node A is determined as the proposal node in the previous round of consensus process, and before the previous round of consensus process, node A was determined as the proposal node in four consensus processes, that is, the previous round of consensus process was the fifth consensus process in which node A was determined as the proposal node. The reference proposal capability values ​​of node A determined by these five consensus processes are Cap1', Cap2', Cap3', Cap4', and Cap5' respectively.

[0142] After completing the first consensus process of node A as a proposal node, the reference proposal capability value Cap1' of node A determined in the first consensus process is directly stored as the fused proposal capability value in the proposal capability map;

[0143] After completing the second consensus process of node A as a proposal node, the fused proposal capability value at this time is Cap1'. The reference proposal capability value Cap2' determined in the second consensus process is updated based on the fused proposal capability value Cap1', expressed as NewCap2'=W1*Cap1'+W2*Cap2', where NewCap2' represents the reference proposal capability value updated in the second consensus process of node A, and NewCap2' is stored in the proposal capability map as the new fused proposal capability value of node A;

[0144] After the third consensus process of node A as a proposal node is completed, the fused proposal capability value at this time is NewCap2'. The reference proposal capability value Cap3' determined in the third consensus process is updated based on the fused proposal capability value NewCap2', expressed as NewCap3'=W1*NewCap2'+W2*Cap3'. NewCap3' represents the reference proposal capability value of node A after the third consensus process, and NewCap3' is stored as the new fused proposal capability value of node A in the proposal capability map;

[0145] After completing the fourth consensus process of node A as a proposal node, the fused proposal capability value at this time is NewCap3'. The reference proposal capability value Cap4' determined in the fourth consensus process is updated based on the fused proposal capability value NewCap3', expressed as NewCap4'=W1*NewCap3'+W2*Cap4', where NewCap4' represents the reference proposal capability value of node A after the fourth consensus process, and NewCap4' is stored in the proposal capability map as the new fused proposal capability value of node A;

[0146] After completing the fifth consensus process of node A as a proposal node, the fusion proposal capability value at this time is NewCap4', and the reference proposal capability value Cap5' determined in the fifth consensus process is updated according to the fusion proposal capability value NewCap4', which is expressed as NewCap5'=W1*NewCap4'+W2*Cap5', where NewCap5' represents the reference proposal capability value of node A after the fifth consensus process is updated, and NewCap5' is stored in the proposal capability map as the new fusion proposal capability value of node A.

[0147] It should be noted that in the embodiment of the present application, the reference proposal capability value used to divide the numerical interval is actually a fusion of the reference proposal capability value determined by a node as a proposal node in the last consensus process and the fused proposal capability value before the last consensus process in the above manner, and the reference proposal capability value used to divide the numerical interval is stored as a new fused proposal capability value.

[0148] Optionally, in one embodiment, based on the reference proposal capability values ​​corresponding to different nodes in the blockchain network, consecutive numerical intervals corresponding to different nodes are divided, including:

[0149] According to the reference proposal capability values ​​corresponding to different nodes in the blockchain network, the initial value intervals corresponding to different nodes are divided and sequentially divided;

[0150] According to the cumulative number of proposals of different nodes in the blockchain network, the initial numerical range of different nodes is adjusted to obtain the numerical range of different nodes in sequence.

[0151] In an embodiment of the present application, the electronic device serves as a node in the blockchain network. First, the initial numerical intervals corresponding to different nodes and consecutively arranged are divided according to the reference proposal capability values ​​corresponding to different nodes in the blockchain network; then, according to the cumulative number of proposals of different nodes in the blockchain network, the initial numerical intervals of different nodes are adjusted to obtain numerical intervals of different nodes consecutively arranged.

[0152] Among them, the electronic device, as a node in the blockchain network, can determine the adjustment direction (including increase or decrease) and adjustment size of the initial numerical range of the node based on the cumulative number of proposals of the node. For example, the median of the cumulative number of proposals of all nodes in the blockchain network can be determined, and the adjustment direction of the nodes with a cumulative number of proposals greater than the median can be determined to be increase, and the adjustment direction of the nodes with a cumulative number of proposals less than the median can be determined to be increase. The adjustment size of these nodes is determined based on the constraint that the adjusted numerical ranges are sequentially continuous. The initial numerical range of the node corresponding to the median is not adjusted and is directly used as the numerical range of the node.

[0153] For example, the initial numerical intervals of nodes A, B, and C are [1, 100], [101, 200], and [201, 300] respectively. According to the cumulative number of proposals of nodes A, B, and C, the adjustment direction of node A is determined to be shrinking, and the adjustment size is 10. The cumulative number of proposals of node B is the median and is not adjusted. The adjustment direction of node C is increasing, and the adjustment size is 10. After the adjustment, the numerical interval of node A is [11, 100], the numerical interval of node B is [101, 200], and the numerical interval of node C is [201, 310].

[0154] It should be noted that in the above embodiments, each node in the blockchain network divides the numerical interval according to the same numerical interval division method, and determines the new proposal node according to the same index value determination method, so as to ensure that the new proposal node ultimately determined by each node is the same.

[0155] Please refer to Figure 1f, the technical solution for blockchain consensus provided by this application improves the current Byzantine fault-tolerant consensus mechanism, wherein the pre-voting stage of the Byzantine fault-tolerant consensus mechanism is changed into two pre-voting sub-stages. In the first pre-voting sub-stage, the consensus node responds to the proposal message of the proposal node in the blockchain network for the block to be agreed upon, obtains the number of transactions of the block to be agreed upon, and obtains the network quality parameters between the current and the proposal node, and determines the initial proposal capability value of the proposal node based on the obtained number of transactions and network quality parameters, and adds the initial proposal capability value to the return value in the pre-voting message of the proposal node. In the second pre-voting sub-stage, the proposal node fuses the initial proposal capability values ​​from different consensus nodes in the blockchain network to obtain a reference proposal capability value, and returns the reference proposal capability value together with the received pre-voting message to the consensus node in the blockchain network. Compared with the conventional pre-voting stage of the Byzantine fault-tolerant consensus mechanism, in the improved pre-voting stage of the technical solution of the present application, in addition to being able to obtain pre-voting messages from other consensus nodes for subsequent consensus processes, the consensus node can also obtain a reference proposal capability value that reflects the proposal capability of the node in the blockchain network as a proposal node. Therefore, on the premise of completing the consensus process normally, the proposal node for the next round of consensus can be determined based on the additional reference proposal capability value obtained, where the probability of a node being determined as a proposal node is positively correlated with its corresponding reference proposal capability value. In this way, nodes with strong proposal capabilities have a greater probability of being determined as proposal nodes, thereby shortening the time spent in the proposal stage, and then shortening the overall time spent in the consensus process, and ultimately achieving the purpose of improving the overall consensus performance of the blockchain network.

[0156] Please refer to Figure 2 , Figure 2 This is another flowchart of the blockchain consensus method provided by this application. In the following embodiments, the electronic device executes the blockchain consensus method as a proposal node, such as Figure 2 As shown, the process of the blockchain consensus method provided by this application can also be as follows:

[0157] In 210, a proposal message for the block to be agreed upon is generated and sent to a consensus node in the blockchain network. The proposal message is used to instruct the consensus node to obtain the number of transactions of the block to be agreed upon, as well as the network quality parameters between the consensus node and the proposal node. Based on the number of transactions and the network quality parameters, the initial proposal capability value of the proposal node is determined and added to the pre-voting message and returned to the proposal node.

[0158] A proposal node, also known as a master node, is a node in a blockchain network that is designated to preside over the consensus process. All nodes in a blockchain network can be designated as proposal nodes.

[0159] Consensus nodes, also known as slave nodes, are nodes in a blockchain network that participate in the consensus process, excluding proposal nodes. For example, a blockchain network consists of nodes A, B, C, D, and E. If node A is determined to host the consensus process, then node A is the proposal node, and nodes B, C, D, and E are consensus nodes.

[0160] In the embodiment of the present application, the electronic device acts as a proposal node, and according to the specifications of the Byzantine fault-tolerant consensus mechanism, it packages the transactions in the transaction pool to obtain a block to be agreed upon. The block to be agreed upon refers to the block obtained by the proposal node by packaging the transactions in the transaction pool during the current consensus cycle, and it is necessary to reach a consensus to be put on the chain. For example, in the consensus process of block height 10 of the blockchain, node A in the blockchain network is determined to be the proposal node. Node A (the proposal node) packages a total of 10,000 transactions to obtain the block to be agreed upon during the consensus process. It should be noted that the method of packaging the blocks can be implemented with reference to the relevant technology, which will not be elaborated here.

[0161] In response to receiving the block to be agreed upon, the electronic device, acting as a proposal node, generates a proposal message for the block to be agreed upon, following the specifications of the Byzantine Fault Tolerant consensus mechanism, and sends it to the consensus nodes in the blockchain network. The proposal message includes data such as the block to be agreed upon and the consensus status. The consensus status includes information such as the current block height, the current consensus round, and the currently locked block.

[0162] It should be noted that the technical solution provided in the embodiment of the present application is to improve the pre-voting stage of the Byzantine fault-tolerant consensus mechanism.

[0163] Different from the current Byzantine fault-tolerant consensus mechanism, in the embodiment of the present application, the proposal message is used to instruct the consensus node to obtain the number of transactions of the block to be agreed upon, as well as to obtain the network quality parameters between the current node and the proposal node, and based on the number of transactions and the network quality parameters, determine the initial proposal capability value of the proposal node and add it to the pre-voting message and return it to the proposal node.

[0164] In other words, after receiving a proposal message from a proposal node for a block to be agreed upon, the consensus node in the blockchain network responds to the proposal message, obtains the number of transactions in the block to be agreed upon, and obtains the current network quality parameters between the consensus node and the proposal node. Based on the obtained number of transactions and network quality parameters, the consensus node determines the initial proposal capability value of the proposal node, adds it to the pre-voting message and returns it to the proposal node, rather than sending it to other consensus nodes in the blockchain network.

[0165] Among them, the consensus node can directly parse the received proposal message to obtain the transaction number of the transactions to be packaged in the consensus block.

[0166] In addition, the consensus node can obtain the network quality parameters between the current and the proposal node according to the configured network quality parameter evaluation strategy. There is no specific restriction on the configuration of the network quality parameter evaluation strategy here, and it can be configured by technical personnel in this field according to actual needs.

[0167] Exemplarily, the configured network quality parameter evaluation strategy is to select at least one of the following as the network quality parameter between the consensus node and the proposal node:

[0168] The waiting time for a consensus node to receive a proposal message after entering the proposal phase. The waiting time is negatively correlated with network quality; that is, the longer the waiting time, the worse the network quality.

[0169] The network delay between the consensus node and the proposal node. Network delay is negatively correlated with network quality. That is, the greater the network delay, the worse the network quality.

[0170] The available bandwidth between the consensus node and the proposal node. Here, available bandwidth refers to the bandwidth between the two that can be used for the consensus process. Available bandwidth is positively correlated with network quality. That is, the larger the available bandwidth, the better the network quality.

[0171] It should be noted that the higher the hardware configuration of the proposal node, the faster it packages transactions, the more transactions in the corresponding consensus block it packages, and the higher its proposal capacity. In addition, the worse the network quality between the consensus node and the proposal node, the longer it takes the proposal node to send the proposal message to the consensus node, and the lower the proposal capacity. Accordingly, after obtaining the number of transactions in the consensus block and the current network quality parameters between the consensus node and the proposal node, the consensus node further determines the initial proposal capacity value of the proposal node according to the configured proposal capacity evaluation strategy based on the obtained transaction number and network quality parameters. There is no specific limitation on the configuration of the proposal capacity evaluation strategy here, and it can be configured by those skilled in the art according to actual needs.

[0172] For example, the consensus node can determine the initial proposal capacity value of the proposal node based on the number of transactions of the block to be consensus obtained, and some or all of the network quality parameters obtained, with the constraints that the initial proposal capacity value is positively correlated with the number of transactions, the initial proposal capacity value is negatively correlated with the waiting time, the initial proposal capacity value is negatively correlated with the network delay, and the initial proposal capacity value is positively correlated with the available bandwidth. The above method of determining the initial proposal capacity value can be determined by those skilled in the art according to actual needs, and no specific restrictions are made here.

[0173] In 220 , pre-voting messages returned by different consensus nodes in the blockchain network are received, and the initial proposal capability values ​​from different consensus nodes in the blockchain network are integrated to obtain a reference proposal capability value.

[0174] As mentioned above, consensus nodes in a blockchain network don't send pre-voting messages with their determined initial proposal capability values ​​to other consensus nodes. Instead, they send them to the proposing node. Accordingly, the electronic device acting as a proposing node will receive pre-voting messages from different consensus nodes in the blockchain network. Ideally, a proposing node will receive pre-voting messages from all consensus nodes in the blockchain network, each of which includes the initial proposal capability values ​​determined by each consensus node.

[0175] To ensure the normal progress of the consensus process, after the number of pre-voting messages received by a proposal node reaches a threshold, it integrates the initial proposal capacity values ​​from consensus nodes in the blockchain network to obtain a reference proposal capacity value for the proposal node. The threshold value can be set by those skilled in the art based on practical needs. For example, the threshold value can be set to 2n / 3+1, where n represents the number of nodes in the blockchain network, as referenced by the Byzantine Fault Tolerant consensus mechanism. The method for integrating the initial proposal capacity values ​​is not specifically limited and can be configured by those skilled in the art based on practical needs.

[0176] Optionally, in one embodiment, initial proposal capability values ​​from different consensus nodes in the blockchain network are integrated to obtain a reference proposal capability value, including:

[0177] Determine the corresponding fusion weights of different consensus nodes in the blockchain network;

[0178] According to the fusion weights corresponding to different consensus nodes, the initial proposal capability values ​​from different consensus nodes are fused to obtain the reference proposal capability value.

[0179] The embodiment of the present application further provides an optional fusion method for reference proposal capability values. Among them, the electronic device acts as a proposal node, and determines the fusion weights corresponding to different consensus nodes in the blockchain network according to the configured weight determination strategy. Then, according to the fusion weights corresponding to different consensus nodes, the initial proposal capability values ​​from different consensus nodes are fused to obtain the reference proposal capability value of the proposal node. There is no specific restriction on the configuration of the weight determination strategy here, and it can be configured by those skilled in the art according to actual needs. For example, the weight determination strategy is configured as: w i =1 / m, where w i represents the fusion weight of the i-th consensus node, and m represents the number of consensus nodes in the blockchain network.

[0180] Optionally, in one embodiment, determining the fusion weights corresponding to different consensus nodes in the blockchain network includes:

[0181] Obtain the network fluctuation level of each consensus node;

[0182] According to the network fluctuation degree of each consensus node, the corresponding fusion weight of different consensus nodes in the blockchain network is determined. The fusion weight is negatively correlated with the network fluctuation degree.

[0183] In an embodiment of the present application, the electronic device serves as a proposal node and first evaluates the network fluctuation degree of each consensus node. For example, the electronic device serves as a proposal node and can determine the network fluctuation degree of each consensus node based on at least one of the network delay change rate and the available bandwidth change rate of each consensus node within a historical time interval, wherein the network delay change rate is positively correlated with the network fluctuation degree, and the available bandwidth change rate is positively correlated with the network fluctuation degree.

[0184] As mentioned above, after obtaining the network fluctuation degree of each consensus node, the electronic device as a proposal node further determines the corresponding fusion weights of different consensus nodes in the blockchain network based on the network fluctuation degree of each consensus node, where the fusion weight is constrained to be negatively correlated with the network fluctuation degree, that is, the greater the network fluctuation degree of the consensus node, the smaller the corresponding fusion weight.

[0185] In 230, pre-voting messages from different consensus nodes in the blockchain network are aggregated to obtain a pre-voting message set.

[0186] In addition, in order to ensure a better consensus process, the proposal node also aggregates the pre-voting messages from different consensus nodes in the blockchain network into a pre-voting message set.

[0187] In 240, the pre-voting message set and the reference proposal capability value are returned to different consensus nodes. The pre-voting message set is used by the consensus nodes to reach consensus on the consensus block and obtain the consensus result. The reference proposal capability value is used to determine the proposal node for the next round of consensus, and the probability of the proposal node being determined as the proposal node in the next round of consensus is positively correlated with the reference proposal capability value.

[0188] As mentioned above, after aggregating the pre-voting message set and fusing the reference proposal capability value, the proposal node further returns the aggregated pre-voting message set and the fusing reference proposal capability value to different consensus nodes in the blockchain network.

[0189] For example, a blockchain network includes nodes A, B, C, D, and E, where A is identified as a proposal node and nodes B, C, D, and E are consensus nodes. Proposal node A receives pre-voting messages from consensus nodes B, C, D, and E. Proposal node A parses the initial proposal capability values ​​from the pre-voting messages of the aforementioned consensus nodes and merges them into a reference proposal capability value. The pre-voting messages from consensus nodes C, D, and E are aggregated into a pre-voting message set, which is then returned together with the reference proposal capability value. Consensus node B removes the added initial proposal capability value from the pre-voting messages from consensus node B, consensus node D, and consensus node E, aggregates them into a pre-voting message set, and returns them together with the reference proposal capability value to consensus node C; removes the added initial proposal capability value from the pre-voting messages from consensus node B, consensus node C, and consensus node E, aggregates them into a pre-voting message set, and returns them together with the reference proposal capability value to consensus node D; and removes the added initial proposal capability value from the pre-voting messages from consensus node B, consensus node C, and consensus node D, aggregates them into a pre-voting message set, and returns them together with the reference proposal capability value to consensus node E.

[0190] Among them, the pre-voting message set is used by consensus nodes to reach consensus on the consensus block and obtain the consensus result.

[0191] When a consensus node receives the pre-voting message set from the proposal node, it is equivalent to receiving the pre-voting messages from other consensus nodes in the blockchain network, which is equivalent to completing the pre-voting phase of the Byzantine Fault Tolerant consensus mechanism. According to the specifications of the Byzantine Fault Tolerant consensus mechanism, it can enter the pre-commit phase, complete the consensus on the consensus block, and obtain the corresponding consensus result. If a consensus is reached on the consensus situation, the consensus situation will be added to the blockchain network.

[0192] In addition, the reference proposal capability value is used to determine the proposal node for the next round of consensus, and the probability of a proposal node being determined as a proposal node in the next round of consensus is positively correlated with the reference proposal capability value.

[0193] According to the technical solutions described above in the embodiments of the present application, each node in the blockchain network will obtain the reference proposal capability values ​​of all nodes as proposal nodes. Among them, for nodes that have not yet been determined as proposal nodes, their reference proposal capability values ​​can be configured to preset initial values ​​(which can be configured by technicians in this field according to actual needs, without specific restrictions here, for example, it can be configured to 100).

[0194] As described above, the reference proposal capability value of a node can reflect the node's ability to make proposals as a proposal node. Accordingly, in the embodiment of the present application, the reference proposal capability value of the node is used to determine the proposal node, wherein the probability of the node being determined as a proposal node is positively correlated with the reference proposal capability value corresponding to the node. The method of determining the proposal node can be configured by those skilled in the art according to actual needs.

[0195] It can be understood that the reference proposal capability value obtained in the current consensus process reflects the proposal capability of the proposal node in the current consensus process. In the next round of consensus, the probability of the proposal node in the current consensus process being determined as the proposal node is positively correlated with its reference proposal capability value.

[0196] To facilitate better implementation of the blockchain consensus method for consensus nodes provided in this application, the present application also provides a corresponding blockchain consensus device. The meanings of the terms herein are the same as those in the blockchain consensus method for consensus nodes described above. For specific implementation details, please refer to the description in the embodiment of the blockchain consensus method for consensus nodes described above.

[0197] Please refer to Figure 3 , Figure 3 This is a structural diagram of a blockchain consensus device provided in an embodiment of the present application. The blockchain consensus device may include a data acquisition module 310, a capability determination module 320, a first data transmission module 330, and a block consensus module 340, wherein:

[0198] The data acquisition module 310 is used to respond to the proposal message of the proposal node in the blockchain network for the block to be agreed upon, obtain the number of transactions in the block to be agreed upon, and obtain the current network quality parameters between the proposal node and the proposal node;

[0199] Capacity determination module 320, used to determine the initial proposal capacity value of the proposal node based on the number of transactions and network quality parameters, and add the initial proposal capacity value to the pre-voting message;

[0200] The first data transmission module 330 is used to return the pre-voting message to the proposal node. The pre-voting message is used by the proposal node to integrate the initial proposal capability values ​​from different consensus nodes in the blockchain network to obtain the reference proposal capability value of the proposal node;

[0201] The block consensus module 340 is used to receive the reference proposal capability value returned by the proposal node and the pre-voting messages of other consensus nodes in the blockchain network, and to reach a consensus on the consensus block based on the received pre-voting messages to obtain a consensus result;

[0202] Among them, the reference proposal capability value is used to determine the proposal node for the next round of consensus, and the probability of a proposal node being determined as a proposal node in the next round of consensus is positively correlated with the reference proposal capability value.

[0203] Optionally, in one embodiment, the network quality parameter includes at least one of the following: a waiting time for receiving a proposal message, a current network delay between the proposal node and the proposal node, and an available bandwidth between the proposal node and the proposal node. The capacity determination module 320 is configured to determine an initial proposal capacity value of the proposal node based on the number of transactions and at least one of the waiting time, the network delay, and the available bandwidth.

[0204] Among them, the initial proposal capacity value is positively correlated with the number of transactions, negatively correlated with the waiting time, negatively correlated with the network delay, and positively correlated with the available bandwidth.

[0205] Optionally, in one embodiment, the capacity determination module 320 is used to perform a division operation on the transaction quantity and the waiting time to obtain a division result; determine a subtraction compensation value for the division result based on the network delay, and the subtraction compensation value is positively correlated with the network delay; determine an addition compensation value for the division result based on the available bandwidth, and the addition compensation value is positively correlated with the available bandwidth; and compensate the division result based on the subtraction compensation value and the addition compensation value to obtain the initial proposal capacity value of the proposal node.

[0206] Optionally, in one embodiment, the blockchain consensus device provided by the present application also includes a node determination module, which is used to divide the numerical intervals corresponding to different nodes and in sequence according to the reference proposal capability values ​​corresponding to different nodes in the blockchain network, wherein the range of the numerical interval is positively correlated with the reference proposal capability value; randomly determine the index value of the new proposal node, and determine the node corresponding to the numerical interval including the index value as the new proposal node.

[0207] Optionally, in one embodiment, the node determination module is used to obtain the block hash value of the block to be agreed upon, and determine the index value of the new proposal node based on the block hash value.

[0208] Optionally, in one embodiment, the node determination module is used to determine the sum of the reference proposal capability values ​​corresponding to all nodes in the blockchain network; and perform a division operation on the block hash value and the sum value, and determine the remainder obtained by the division operation as the index value of the new proposal node.

[0209] Optionally, in one embodiment, the node determination module is also used to obtain the stored fused proposal capability value of the proposal node, which is obtained by fusion based on the historical reference proposal capability value of the proposal node; and to update the reference proposal capability value of the proposal node based on the fused proposal capability value.

[0210] Optionally, in one embodiment, the node determination module is used to divide the initial numerical intervals corresponding to different nodes and consecutively according to the reference proposal capability values ​​corresponding to different nodes in the blockchain network; and adjust the initial numerical intervals of different nodes according to the cumulative number of proposals of different nodes in the blockchain network to obtain numerical intervals of different nodes that are consecutively.

[0211] To facilitate better implementation of the audience-side blockchain consensus method provided in this application, the present application embodiment also provides a corresponding blockchain consensus device. The meanings of the terms are the same as those in the above-mentioned audience-side blockchain consensus method. For specific implementation details, please refer to the description in the above method embodiment.

[0212] Please refer to Figure 4 , Figure 4 This is another structural diagram of the blockchain consensus device provided in an embodiment of the present application. The blockchain consensus device may include a proposal generation module 410, a capability fusion module 420, a message aggregation module 430 and a second data transmission module 440, wherein:

[0213] Proposal generation module 410 is used to generate a proposal message for the block to be agreed upon and send the proposal message to the consensus node in the blockchain network. The proposal message is used to instruct the consensus node to obtain the transaction number of the block to be agreed upon and the network quality parameters between the consensus node and the proposal node. Based on the transaction number and network quality parameters, the consensus node determines the initial proposal capability value of the proposal node, adds it to the pre-voting message, and returns it to the proposal node.

[0214] A capability fusion module 420 is configured to receive pre-voting messages returned by different consensus nodes in the blockchain network, and fuse the initial proposal capability values ​​from different consensus nodes in the blockchain network to obtain a reference proposal capability value;

[0215] A message aggregation module 430 is used to aggregate pre-voting messages from different consensus nodes in the blockchain network to obtain a pre-voting message set;

[0216] The second data transmission module 440 is used to return the pre-voting message set and the reference proposal capability value to different consensus nodes. The pre-voting message set is used by the consensus nodes to reach consensus on the consensus block and obtain the consensus result. The reference proposal capability value is used to determine the proposal node for the next round of consensus, and the probability of the proposal node being determined as the proposal node in the next round of consensus is positively correlated with the reference proposal capability value.

[0217] Optionally, in one embodiment, the capability fusion module 420 is used to determine the fusion weights corresponding to different consensus nodes in the blockchain network; based on the fusion weights corresponding to different consensus nodes, the initial proposal capability values ​​from different consensus nodes are fused to obtain a reference proposal capability value.

[0218] The specific implementation of each of the above modules can be found in the previous embodiments and will not be described again here.

[0219] An embodiment of the present application also provides an electronic device, including a memory and a processor, wherein the processor is configured to execute the steps of the blockchain consensus method provided in this embodiment by calling a computer program stored in the memory.

[0220] Please refer to Figure 5 , Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0221] The electronic device may include one or more processors 101, one or more computer-readable storage media memories 102, a power supply 103, an input unit 104, and other components. It will be understood by those skilled in the art that Figure 5 The electronic device structure shown in the figure does not constitute a limitation of the electronic device, and may include more or fewer components than shown in the figure, or combine certain components, or arrange components differently.

[0222] Processor 101 is the control center of the electronic device. It connects all parts of the electronic device using various interfaces and circuits. It executes software programs and / or modules stored in memory 102 and accesses data stored in memory 102 to perform various functions of the electronic device and process data. Optionally, processor 101 may include one or more processing cores. Alternatively, processor 101 may integrate an application processor and a modem processor. The application processor primarily handles the operating system, user interface, and application programs, while the modem processor primarily handles wireless communications. It is understood that the modem processor may not be integrated into processor 101.

[0223] The memory 102 can be used to store software programs and modules. The processor 101 executes various functional applications and data processing by running the software programs and modules stored in the memory 102. The memory 102 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 102 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage device. Accordingly, the memory 102 may also include a memory controller to provide the processor 101 with access to the memory 102.

[0224] The electronic device also includes a power supply 103 for supplying power to various components. Optionally, the power supply 103 can be logically connected to the processor 101 via a power management system, thereby enabling the power management system to manage charging, discharging, and power consumption. The power supply 103 can also include one or more DC or AC power supplies, a recharging system, a power failure detection circuit, a power converter or inverter, a power status indicator, and other arbitrary components.

[0225] The electronic device may further include an input unit 104, which may be configured to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0226] Although not shown, the electronic device may also include a display unit, an image acquisition component, etc., which will not be described in detail here. Specifically, in this embodiment, when the electronic device acts as a consensus node, the processor 101 loads the executable code corresponding to one or more computer programs into the memory 102, and the processor 101 executes the steps of the blockchain consensus method for consensus nodes provided in this application, such as:

[0227] In response to a proposal message from a proposal node in the blockchain network regarding a block to be agreed upon, obtain the number of transactions in the block to be agreed upon, and obtain the current network quality parameters between the proposal node and the proposal node;

[0228] Determine the initial proposal capacity value of the proposal node based on the number of transactions and network quality parameters, and add the initial proposal capacity value to the pre-voting message;

[0229] Return the pre-voting message to the proposal node. The pre-voting message is used by the proposal node to integrate the initial proposal capability values ​​from different consensus nodes in the blockchain network to obtain the reference proposal capability value of the proposal node.

[0230] Receive the reference proposal capability value returned by the proposal node, as well as the pre-voting messages from other consensus nodes in the blockchain network, and reach consensus on the consensus block based on the received pre-voting messages to obtain the consensus result;

[0231] Among them, the reference proposal capability value is used to determine the proposal node for the next round of consensus, and the probability of a proposal node being determined as a proposal node in the next round of consensus is positively correlated with the reference proposal capability value.

[0232] In addition, when the electronic device acts as a proposal node, the processor 101 loads the executable code corresponding to one or more computer programs into the memory 102, and the processor 101 executes the steps of the blockchain consensus method for the proposal node provided in this application, such as:

[0233] Generate a proposal message for the block to be agreed upon and send it to the consensus node in the blockchain network. The proposal message is used to instruct the consensus node to obtain the transaction number of the block to be agreed upon, as well as the network quality parameters between the consensus node and the proposal node. Based on the transaction number and network quality parameters, the consensus node determines the initial proposal capability value of the proposal node, adds it to the pre-voting message, and returns it to the proposal node.

[0234] Receive pre-voting messages returned by different consensus nodes in the blockchain network, and integrate the initial proposal capability values ​​from different consensus nodes in the blockchain network to obtain the reference proposal capability value;

[0235] Aggregate pre-voting messages from different consensus nodes in the blockchain network to obtain a pre-voting message set;

[0236] The pre-voting message set and the reference proposal capability value are returned to different consensus nodes. The pre-voting message set is used by the consensus nodes to reach consensus on the consensus block and obtain the consensus result. The reference proposal capability value is used to determine the proposal node for the next round of consensus. The probability of the proposal node being determined as the proposal node in the next round of consensus is positively correlated with the reference proposal capability value.

[0237] It should be noted that the electronic device provided in the embodiment of the present application and the blockchain consensus method in the above embodiment have the same concept. The specific implementation process is detailed in the above related embodiments and will not be repeated here.

[0238] This application also provides a computer-readable storage medium having a computer program stored thereon. When the stored computer program is executed on a processor of an electronic device provided in an embodiment of this application, the processor of the electronic device implements the steps of the blockchain consensus method provided in this application. The storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0239] The present application also provides a computer program product, which includes a computer program. When the computer program is executed on the processor of the electronic device provided in the embodiment of the present application, the processor of the electronic device implements the steps in the blockchain consensus method provided in the present application.

[0240] The blockchain consensus method, blockchain consensus device, electronic device, computer-readable storage medium and computer program product provided by this application are introduced in detail above. Specific examples are used herein to illustrate the principles and implementation methods of this application. The description of the above embodiments is only used to help understand the method of this application and its core ideas. At the same time, for those skilled in the art, according to the ideas of this application, there may be changes in the specific implementation methods and application scopes. In summary, the content of this specification should not be understood as limiting this application.

[0241] It should be noted that when the above embodiments of this application are applied to specific products or technologies, the relevant user data is involved, and the user's permission or consent must be obtained, and the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

Claims

1. A blockchain consensus method, applicable to consensus nodes, characterized in that: include: In response to a proposal message from a proposal node in the blockchain network regarding a block to be agreed upon, obtaining the number of transactions in the block to be agreed upon and obtaining a current network quality parameter between the proposal node and the proposal node; Determine an initial proposal capability value of the proposal node based on the transaction quantity and the network quality parameter, and add the initial proposal capability value to the pre-voting message; Returning the pre-voting message to the proposal node, where the pre-voting message is used by the proposal node to fuse the initial proposal capability values ​​from different consensus nodes in the blockchain network to obtain a reference proposal capability value of the proposal node; Receive the reference proposal capability value returned by the proposal node and the pre-voting messages of other consensus nodes in the blockchain network, and reach consensus on the block to be agreed upon based on the received pre-voting messages to obtain a consensus result; The reference proposal capability value is used to determine the proposal node for the next round of consensus, and the probability of the proposal node being determined as the proposal node in the next round of consensus is positively correlated with the reference proposal capability value.

2. The blockchain consensus method according to claim 1, characterized in that: The network quality parameter includes at least one of the following: the waiting time for receiving the proposal message, the current network delay between the proposal node and the proposal node, and the current available bandwidth between the proposal node and the proposal node. The determining of the initial proposal capability value of the proposal node based on the transaction quantity and the network quality parameter includes: Determining an initial proposal capability value of the proposal node based on the number of transactions and at least one of the waiting time, the network delay, and the available bandwidth; Among them, the initial proposal capability value is positively correlated with the transaction quantity, the initial proposal capability value is negatively correlated with the waiting time, the initial proposal capability value is negatively correlated with the network delay, and the initial proposal capability value is positively correlated with the available bandwidth.

3. The blockchain consensus method according to claim 2, characterized in that: The determining, based on the number of transactions and at least one of the waiting time, the network delay, and the available bandwidth, of the initial proposal capability value of the proposal node includes: Performing a division operation on the transaction amount and the waiting time to obtain a division result; determining a subtraction compensation value for the division result according to the network delay, wherein the subtraction compensation value is positively correlated with the network delay; determining an additive compensation value for the division result according to the available bandwidth, wherein the additive compensation value is positively correlated with the available bandwidth; The division result is compensated according to the subtraction compensation value and the addition compensation value to obtain an initial proposal capability value of the proposal node.

4. The blockchain consensus method according to claim 1, characterized in that: After the consensus result is obtained by performing consensus on the block to be agreed upon based on the received pre-voting message, the method further includes: According to the reference proposal capability values ​​corresponding to different nodes in the blockchain network, a numerical interval corresponding to different nodes is divided and sequentially and consecutively assigned, wherein the range of the numerical interval is positively correlated with the reference proposal capability value; An index value of a new proposal node is randomly determined, and a node corresponding to a numerical interval including the index value is determined as a new proposal node.

5. The blockchain consensus method according to claim 4, characterized in that: The randomly determining the index value of the new proposal node includes: Obtain the block hash value of the block to be agreed upon, and determine the index value of the new proposal node based on the block hash value.

6. The blockchain consensus method according to claim 5, characterized in that: Determining the index value of the new proposal node according to the block hash value includes: Determine the sum of the reference proposal capability values ​​corresponding to all nodes in the blockchain network; A division operation is performed on the block hash value and the sum value, and a remainder obtained by the division operation is determined as the index value of the new proposal node.

7. The blockchain consensus method according to claim 4, characterized in that: Before dividing the reference proposal capability values ​​corresponding to different nodes in the blockchain network into consecutive numerical intervals corresponding to different nodes, the method further includes: Obtaining a stored fusion proposal capability value of the proposal node, where the fusion proposal capability value is obtained by fusion of historical reference proposal capability values ​​of the proposal node; The reference proposal capability value of the proposal node is updated according to the fusion proposal capability value.

8. The blockchain consensus method according to claim 4, characterized in that: According to the reference proposal capability values ​​corresponding to different nodes in the blockchain network, the numerical intervals corresponding to different nodes are divided into consecutive intervals, including: According to the reference proposal capability values ​​corresponding to different nodes in the blockchain network, initial value intervals corresponding to different nodes are divided and sequentially divided; According to the cumulative number of proposals of different nodes in the blockchain network, the initial numerical ranges of different nodes are adjusted to obtain numerical ranges of different nodes in sequence.

9. A blockchain consensus method, applicable to a proposal node, characterized in that: include: Generate a proposal message for the block to be agreed upon, and send the proposal message to the consensus node in the blockchain network. The proposal message is used to instruct the consensus node to obtain the transaction number of the block to be agreed upon, as well as the current network quality parameters between the consensus node and the proposal node. Based on the transaction number and the network quality parameters, the consensus node determines the initial proposal capability value of the proposal node, adds it to the pre-voting message, and returns it to the proposal node. Receive pre-voting messages returned by different consensus nodes in the blockchain network, and fuse the initial proposal capability values ​​from different consensus nodes in the blockchain network to obtain a reference proposal capability value; Aggregating pre-voting messages from different consensus nodes in the blockchain network to obtain a pre-voting message set; The pre-voting message set and the reference proposal capability value are returned to different consensus nodes. The pre-voting message set is used by the consensus nodes to reach consensus on the block to be agreed upon and obtain a consensus result. The reference proposal capability value is used to determine the proposal node for the next round of consensus, and the probability of the proposal node being determined as the proposal node in the next round of consensus is positively correlated with the reference proposal capability value.

10. The blockchain consensus method according to claim 9, characterized in that: The initial proposal capability values ​​from different consensus nodes in the blockchain network are integrated to obtain a reference proposal capability value, including: Determine the fusion weights corresponding to different consensus nodes in the blockchain network ； According to the fusion weights corresponding to different consensus nodes, the initial proposal capability values ​​from different consensus nodes are fused to obtain the reference proposal capability value.

11. A blockchain consensus device, suitable for a consensus node, characterized in that: include: A data acquisition module is configured to respond to a proposal message from a proposal node in the blockchain network regarding a block to be agreed upon, obtain the number of transactions in the block to be agreed upon, and obtain a current network quality parameter between the proposal node and the proposal node; a capability determination module, configured to determine an initial proposal capability value of the proposal node based on the transaction quantity and the network quality parameter, and add the initial proposal capability value to the pre-voting message; A first data transmission module is configured to return the pre-voting message to the proposal node, where the pre-voting message is used by the proposal node to fuse initial proposal capability values ​​from different consensus nodes in the blockchain network to obtain a reference proposal capability value of the proposal node; A block consensus module is configured to receive the reference proposal capability value returned by the proposal node and pre-voting messages from other consensus nodes in the blockchain network, and to reach a consensus on the block to be agreed upon based on the received pre-voting messages to obtain a consensus result; The reference proposal capability value is used to determine the proposal node for the next round of consensus, and the probability of the proposal node being determined as the proposal node in the next round of consensus is positively correlated with the reference proposal capability value.

12. A blockchain consensus device, suitable for a proposal node, characterized in that: include: A proposal generation module is configured to generate a proposal message for a block to be agreed upon and send the proposal message to a consensus node in the blockchain network. The proposal message is configured to instruct the consensus node to obtain the number of transactions in the block to be agreed upon and the network quality parameters between the consensus node and the proposal node. The proposal node determines an initial proposal capability value for the proposal node based on the number of transactions and the network quality parameters, adds the value to a pre-voting message, and returns the result to the proposal node. A capability fusion module is configured to receive pre-voting messages returned by different consensus nodes in the blockchain network, and fuse the initial proposal capability values ​​from different consensus nodes in the blockchain network to obtain a reference proposal capability value; A message aggregation module, configured to aggregate pre-voting messages from different consensus nodes in the blockchain network to obtain a pre-voting message set; The second data transmission module is used to return the pre-voting message set and the reference proposal capability value to different consensus nodes. The pre-voting message set is used by the consensus nodes to reach consensus on the block to be agreed upon and obtain a consensus result. The reference proposal capability value is used to determine the proposal node for the next round of consensus, and the probability of the proposal node being determined as the proposal node in the next round of consensus is positively correlated with the reference proposal capability value.

13. An electronic device, characterized in that: The electronic device comprises a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program in the memory when the electronic device is configured as a consensus node to implement the steps in the blockchain consensus method according to any one of claims 1 to 8; or executes the computer program in the memory when the electronic device is configured as a proposal node to implement the steps in the blockchain consensus method according to claim 9 or 10.

14. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which is suitable for execution by a processor to implement the steps in the blockchain consensus method according to any one of claims 1 to 10.

15. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the blockchain consensus method according to any one of claims 1 to 10 are implemented.

Images