A consensus method, blockchain node

Abstract

One or more embodiments of the specification provide a consensus method and a blockchain node, the method is applied to any target consensus node in a blockchain system, comprising: receiving a first message or a second message broadcasted by a consensus node in the blockchain system; wherein the first message contains a transaction list proposed by the consensus node; the second message is used to declare that the consensus node sending the second message does not propose a transaction list in the current round of consensus; determining the number of consensus nodes in the blockchain system that meet a preset condition; wherein the preset condition includes that the transaction list proposed by the consensus node has been consensus passed; or, the second message sent by the consensus node has been received; if the number of consensus nodes in the blockchain system that meet the preset condition reaches a preset threshold, broadcasting a third message to other consensus nodes; wherein the third message is used to declare that no longer accepts the transaction list proposed by other consensus nodes except the consensus nodes meeting the preset condition.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a consensus method and a blockchain node. Background Technology

[0002] In a blockchain system, different participants can establish a distributed blockchain network through deployed nodes. A decentralized (or multi-centralized) distributed ledger, constructed using a chain-like block structure, is stored on each node (or most nodes, such as consensus nodes) in the distributed blockchain network. Such a blockchain system needs to address the consistency and correctness of the ledger data across multiple decentralized (or multi-centralized) nodes. Each node runs a blockchain program, and under a certain fault-tolerance design, a consensus mechanism ensures that all loyal nodes have the same transactions, thereby guaranteeing consistent execution results for the same transactions across all loyal nodes. The transactions and execution results are then packaged into blocks.

[0003] Current mainstream consensus protocols include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT) algorithm, Honey Badger Byzantine Fault Tolerance (HoneyBadgerBFT) algorithm, etc.

[0004] Among the consensus protocols listed above, there are both asynchronous and non-asynchronous consensus protocols. For example, the PBFT protocol is a semi-synchronous protocol, while the HoneyBadgerBFT algorithm is an asynchronous protocol.

[0005] Because asynchronous protocols are applicable to asynchronous networks, where messages between nodes can be delayed arbitrarily but will eventually arrive, asynchronous consensus protocols are currently more widely used than non-asynchronous consensus protocols. Summary of the Invention

[0006] This specification proposes a consensus method for a blockchain system, applicable to any target consensus node in the blockchain system, including:

[0007] Receive a first message or a second message broadcast by a consensus node in the blockchain system; wherein the first message contains a list of transactions proposed by the consensus node; and the second message is used to declare that the consensus node that sent the second message will not propose a list of transactions in this round of consensus.

[0008] Determine the number of consensus nodes in the blockchain system that meet preset conditions; wherein, the preset conditions include that the transaction list proposed by the consensus node has been agreed upon; or, the second message sent by the consensus node has been received;

[0009] If the number of consensus nodes in the blockchain system that meet the preset conditions does not reach the preset threshold, consensus processing is performed on the transaction list contained in the received first message; if the number of consensus nodes in the blockchain system that meet the preset conditions reaches the preset threshold, a third message is broadcast to other consensus nodes; wherein, the third message is used to declare that transaction lists proposed by consensus nodes other than those that meet the preset conditions will no longer be accepted.

[0010] This specification also proposes a blockchain system, including:

[0011] Receive a first message or a second message broadcast by a consensus node in the blockchain system; wherein the first message contains a list of transactions proposed by the consensus node; and the second message is used to indicate to the consensus node that sent the second message not to propose a list of transactions in this round of consensus.

[0012] Determine the number of consensus nodes in the blockchain system that meet preset conditions; wherein, the preset conditions include that the transaction list proposed by the consensus node has been agreed upon; or, the second message sent by the consensus node has been received;

[0013] If the number of consensus nodes in the blockchain system that meet the preset conditions does not reach the preset threshold, consensus processing is performed on the list of transactions proposed in this round of consensus; conversely, if the number of consensus nodes in the blockchain system that meet the preset conditions reaches the preset threshold, a third message is broadcast to other consensus nodes; wherein, the third message is used to declare that transaction lists proposed by consensus nodes other than those meeting the preset conditions will no longer be accepted.

[0014] In the above embodiments, by allowing consensus nodes to broadcast a second message to other consensus nodes during the transaction proposal phase of the consensus protocol, declaring that they have no transactions to propose in this round of consensus, those consensus nodes without transactions to propose no longer need to propose empty proposals during the transaction proposal phase, thereby avoiding the waste of computing power and bandwidth resources. Furthermore, since the number of consensus nodes that have received the second message in a round of consensus will also serve as the trigger condition for the consensus protocol's pass mechanism, this method allows consensus nodes without transactions to propose no longer to propose empty proposals, yet still able to continue pushing the pass mechanism for consensus proposals without affecting the activity of the consensus protocol. Attached Figure Description

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

[0016] Figure 1 This is a schematic diagram of the conventional stage of a practical Byzantine fault-tolerant algorithm in one embodiment of this specification;

[0017] Figure 2 This is a schematic diagram of the view switching stage of a practical Byzantine fault-tolerant algorithm in one embodiment of this specification;

[0018] Figure 3 This is a schematic diagram of the honey badger Byzantine fault-tolerant algorithm in one embodiment of this specification;

[0019] Figure 4 This is a flowchart of a consensus method in a blockchain system according to one embodiment of this specification;

[0020] Figure 5 This is a schematic diagram of a consensus algorithm in one embodiment of this specification;

[0021] Figure 6 This is a schematic diagram of a consensus algorithm in one embodiment of this specification;

[0022] Figure 7 This is a schematic diagram of a consensus algorithm in one embodiment of this specification;

[0023] Figure 8 This is a schematic diagram of a consensus algorithm in one embodiment of this specification. Detailed Implementation

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

[0025] Currently, mainstream consensus protocols can generally be categorized into two types: asynchronous consensus protocols and non-asynchronous consensus protocols.

[0026] For example, the PBFT protocol is a semi-synchronous protocol, while the HoneyBadgerBFT algorithm is an asynchronous protocol.

[0027] Taking PBFT as an example, in the PBFT algorithm, all replicas operate in a succession of configuration process called a view. In a view, one replica acts as the primary node, and the others as backup nodes. Views are consecutively numbered integers. The primary node is calculated using the formula p = v mod |R|, where v is the view number, p is the replica number, and |R| is the number of replicas. The algorithm assumes that if at most f replicas (nodes) fail, a total of at least 3f+1 replicas can guarantee safety and liveness in the asynchronous system. To ensure data consistency and fault tolerance for all replicas, a certain number of replicas are needed, typically the majority of nodes in the distributed system, forming the majority (Quorum). For example, when the total number of nodes n is 3f+1 (n = 3f+2 or n = 3f generally does not improve fault tolerance), the Quorum is 2f+1. Thus, for a distributed system with four nodes, any three nodes can form a Quorum.

[0028] PBFT consists of two phases: the Normal Case Phase and the View Change Phase.

[0029] Please see Figure 1 , Figure 1 This is a flowchart of the Normal Case Phase process.

[0030] The Normal Case Phase mainly includes three stages: PRE-PREPARE, PREPARE, and COMMIT. Node 3, for example, could represent a node that has crashed. Figure 1 (Represented by ×). When the primary node fails, a view change process needs to be initiated to adjust the state and replace the primary node when a system failure occurs (e.g., after the view is changed, Replica 1 becomes the primary node).

[0031] Please see Figure 2 , Figure 2 This is a diagram illustrating the View Change Phase. If the master node goes offline or acts maliciously without broadcasting client requests, the client can set a timeout mechanism. If the timeout occurs, the client can broadcast a request message to all replica nodes. If a replica node detects that the master node is malicious or offline, it can also initiate a View Change phase to replace the master node (often simply called "master replacement"). Furthermore, the three-phase consensus process (PRE-PREPARE, PREPARE, and COMMIT) may fail due to the master node making an incorrect proposal, or the PREPARE and COMMIT phases may fail to reach a consensus on the required number of quorum members (e.g., 2f+1 out of 3f+1 nodes, also known as the quorum). In these cases, a View Change phase may also be initiated to replace the master node.

[0032] PBFT is a semi-synchronous protocol, meaning it assumes the network is initially asynchronous but can synchronize at a certain point. The simplest way to get different nodes in the network to reach consensus on the same proposal is to set a master node to unify the opinions of all nodes. Timers can be used to prevent the master node from failing. In PBFT, if the Normal Case Phase is not completed within a finite time, Backups will initiate a ViewChange Phase to replace the master node. PBFT keeps the master node in one location; all requests can be sent to the master node first, and then broadcast to other consensus nodes. Besides introducing additional latency in sending requests to the master node, the master node's ingress and egress bandwidth can also become a performance bottleneck.

[0033] In single-master-node protocols like PBFT, only the master node can initiate consensus proposals within a single consensus process; other nodes lack the ability to do so. Alternatively, if other nodes also have proposals, they must be forwarded to the master node, which then initiates the proposal on their behalf. The former approach is unfair to the consensus nodes' power in constructing blocks, while the latter, although allowing backup nodes to propose, increases the pressure on the master node's outgoing bandwidth. Neither approach is particularly suitable for scenarios where most consensus nodes need to initiate consensus proposals.

[0034] In contrast, the HoneyBadgerBFT algorithm (often abbreviated as HBBFT) is an asynchronous protocol. Asynchronous protocols are suitable for asynchronous networks, meaning that messages between nodes in this network can be arbitrarily delayed, but will eventually arrive. HoneyBadgerBFT eliminates timers, instead using messages to drive the protocol's execution. Furthermore, all nodes in the HoneyBadgerBFT algorithm are equal; there is no distinction between master and backup nodes, and therefore no process of switching masters. Asynchronous network consensus protocols like HBBFT lack the concept of a master node; each node can propose requests and attempt to construct blocks. Therefore, asynchronous network protocols alleviate the issues of fairness and single-node bottlenecks to some extent.

[0035] Please see Figure 2 , Figure 3 This is a flowchart of the HoneyBadger BFT algorithm for a single node angle.

[0036] In fact, as mentioned earlier, all nodes in the HoneyBadgerBFT algorithm are peers, meaning that all nodes can execute. Figure 3 The process is shown below. Figure 3 As shown, from a single node's perspective, HoneyBadgerBFT mainly consists of two phases: Reliable Broadcast (RBC) and Asynchronous Binary Agreement (ABA, also known as "01 Asynchronous Binary Consensus"). In addition, there is the Asynchronous Common Subset (ACS) protocol built upon RBC and ABA. The RBC phase includes at least three rounds of message interaction: Rval, Echo, and Ready. The ABA phase includes at least three rounds of message interaction: BVAL, AUX, and Coin. RBC uses these three rounds of message interaction to ensure reliable proposal broadcasting. ABA first conducts two rounds of voting (BVAL and AUX messages), and then uses a coin toss to unify the consensus among nodes' proposals, thus bypassing the network synchronization requirements of semi-synchronous protocols.

[0037] A single HoneyBadgerBFT consensus process involves an RBC phase and at least one ABA phase. In a favorable scenario, there's a 1 / 2 probability that the current HoneyBadgerBFT consensus process can be completed, requiring six rounds to reach consensus. Furthermore, there's a 1 / 4 probability that it will enter another ABA phase, such as... Figure 3 In the second ABA process (represented by rounds 7, 8, and 9), there is a 1 / 4 probability that it will end in the second round, and there is at least a 1 / 4 probability that the current HoneyBadgerBFT consensus process can be terminated. Thus, it takes 9 rounds to complete a consensus. After the second ABA process, there is an overall 1 / 8 probability that it will enter another ABA process... and so on.

[0038] In summary, HoneyBadgerBFT includes at least one RBC (three rounds) and one ABA (three rounds). If the voting results of the ABA are inconsistent with the coin-throwing results, the protocol will enter a new round of ABA (at least three additional rounds).

[0039] It is evident that the token-throwing mechanism introduced by HoneyBadgerBFT introduces uncertainty into the consensus rounds, which may lead to increased consensus delays.

[0040] Furthermore, for a final generated block (corresponding to one epoch), a node can run one ACS and n RBCs + n ABAs, where n is the number of consensus nodes. One RBC and ABA corresponds to the consensus proposal initiated by the node itself, and the other (n-1) RBCs and ABAs correspond to consensus proposals initiated by the other (n-1) nodes. In other words, for one epoch, while a node initiates a consensus proposal, it also works to complete consensus proposals initiated by other nodes. Thus, for a node, after at least (nf) RBCs have been completed, it sends the completion status of these RBCs (indicated by a Ready message) to the ACS, which then initializes the corresponding ABA and starts the corresponding ABA process. If, after at least (nf) consensus proposals have completed their ABAs, the remaining consensus proposals have not yet completed their RBCs, they will be initialized to 0, and the ABA process corresponding to that proposal will be executed. From a global perspective, at least (nf) nodes will execute the same consensus process described above (the process of at least (nf) different nodes initiating proposals), and finally the ACS will collect the ABA results of each proposal, sort the proposals with an ABA result of 1 according to a certain rule, and output them.

[0041] In the process described above, unlike PBFT, a stronger proposal requirement is imposed on each participating node. That is, each participating node must initiate a proposal in every epoch, regardless of whether it actually has a proposal. If a node does not actually have a proposal, it still needs to initiate an empty proposal request (this empty proposal request can be encrypted in RBC, so other nodes cannot determine the content of the proposal, preventing malicious nodes from selectively assigning inputs or outputs during the BA process because they can see the content of the proposal). Even if the node is a failed node and cannot issue a proposal, a space must still be reserved for the corresponding proposal in the ACS of other nodes. Specifically, after each of the other nodes has executed at least a Quorum of ABAs and all consensus is 1 (1 indicates vote approval), if the ACS has not yet received a Quorum of Ready messages for the RBC phase corresponding to this node's proposal, it needs to initialize the ABA value corresponding to this node's proposal to 0 (0 indicates vote disapproval), and then enter the ABA process. Thus, other nodes also need to cooperate to complete the ABA process for the proposal corresponding to this failed node.

[0042] It is evident that traditional asynchronous consensus protocols, such as HoneyBadgerBFT, typically employ a block identifier to identify the block to be agreed upon, and all consensus nodes jointly initiate a block building process for the block corresponding to that identifier.

[0043] Using this traditional block-building method, for any consensus node, its own consensus process for a block proposal requires waiting for and cooperating with other consensus nodes to complete their consensus on the same block proposal. Even a consensus node without a proposal still needs to propose an empty consensus proposal, resulting in a significant waste of resources (computing power, bandwidth).

[0044] To address the issue of traditional asynchronous consensus protocols, such as HoneyBadgerBFT, failing to quickly and efficiently complete the consensus process and output consensus results using the aforementioned traditional block-building method, the block-building method of these asynchronous consensus protocols can be redesigned. Instead of using block identifiers to identify the blocks to be reached for consensus, the timestamp corresponding to the moment the consensus proposal is initiated can be used to identify the blocks to be reached for consensus.

[0045] Alternatively, instead of using the block building method where all consensus nodes jointly propose a block for the block corresponding to the block identifier, each consensus node can independently propose a block based on the timestamp of its proposal. Only after consensus is reached can the transaction lists of each consensus node's proposal be sorted according to the timestamp order, and then the order of the sorted transactions can be used to determine which block each consensus node's proposed transaction list belongs to.

[0046] For example, the consensus protocol that redesigned the block formation method could be the MyTumbler consensus protocol. Unlike the HoneyBadgerBFT consensus protocol, MyTumbler merges the last two rounds of the RBC process and the first two rounds of the ABA process in the HoneyBadgerBFT consensus protocol. Under certain conditions, this can be shortened to three rounds to complete a consensus. The three rounds of interaction involve Val, ENDORSE, and Prom messages. The Val, ENDORSE, and Prom messages no longer carry the block number to be agreed upon; instead, they carry the timestamp of the consensus proposal. When all the transaction lists proposed by various consensus nodes pass consensus within a certain period, the transaction lists proposed by each consensus node are sorted according to the order of their timestamps, and the order determines which block each node's proposed transaction list belongs to.

[0047] By redesigning the traditional block formation method to identify blocks to be agreed upon based on timestamps, each node's proposal can form a block independently, and the consensus results are sorted according to timestamps. This ensures that the relative position of the blocks is determined when a consensus proposal is initiated, without losing the right to construct blocks.

[0048] Moreover, for failed nodes that cannot propose consensus, as long as the number of normally functioning nodes reaches the Quorum, the process of generating consensus results does not need to be like in HoneyBadgerBFT, where the initial ABA value (i.e., voting value) corresponding to the failed node's proposal is set to 0 before entering the ABA process. Instead, the failed node can be skipped, and there is no need to wait for the failed node to initiate a consensus proposal or cooperate with the failed node to complete the consensus, which can greatly reduce the consensus latency.

[0049] In practical applications, whether it is a consensus protocol based on block identifiers for transaction proposals, such as HoneyBadgerBFT, or a consensus protocol based on timestamps, such as MyTumbler, a pass mechanism for consensus proposals is usually introduced in order to improve consensus efficiency.

[0050] The so-called pass mechanism refers to the fact that in a certain round of consensus, if a sufficient number of proposals for the target block have been passed by consensus, then the consensus nodes in the blockchain network will no longer accept proposals from the remaining nodes.

[0051] For example, taking the HoneyBadgerBFT algorithm as an example, in the ABA stage of the HoneyBadgerBFT algorithm, if it is determined that Quorum proposals for the target block have been agreed upon, the votes for the proposals of the remaining nodes (i.e., the initial ABA value) can be forcibly assigned to 0 (indicating disapproval) and then the algorithm can enter the subsequent ABA stage to indicate that it will no longer accept proposals from the remaining nodes.

[0052] For example, taking the MyTumbler algorithm, if a consensus node has reached consensus on a transaction list at a certain time t, it can broadcast a PASS message carrying the timestamp corresponding to time t. Having passed time t, it will no longer accept transaction lists proposed before time t. For instance, the PASS message from a consensus node essentially expresses a commitment to vote 0 (disapproval) for transaction lists proposed before time t, or to no longer process such lists. Once each consensus node has collected at least a quorum of PASS messages (including its latest broadcast), it can calculate the minimum timestamp carried in these PASS messages to use as the timestamp corresponding to the critical moment. Thus, each consensus node can confirm that at least a quorum of consensus nodes have passed the critical moment, thereby reaching a consensus on that critical moment. Subsequently, each consensus node will no longer accept transaction lists proposed by other consensus nodes before that critical moment t. For example, it will vote 0 (indicating disapproval) on the list of transactions proposed before the critical moment t, or it will no longer process the list of transactions proposed before the critical moment t.

[0053] However, both HoneyBadgerBFT and Mytumbler can "suspend" some nodes' proposals for the target block through the pass mechanism described above, but they still need joint and continuous proposals from all nodes to maintain the algorithm's liveness.

[0054] For example, the HoneyBadgerBFT algorithm requires all nodes to participate in the construction of blocks. After at least a quorum of nodes' proposals for the block have been agreed upon, the remaining nodes, even if they have no transactions to propose, still need to propose an empty proposal (usually a list of transactions) for the block. The votes of each node for the proposals of the remaining nodes (i.e., the initial ABA value) will be forcibly assigned to 0 before entering the subsequent ABA stage to ensure that all nodes have participated in the proposal for the block.

[0055] In the MyTumbler algorithm, each node needs to wait to receive a Quorum of Pass messages before it can determine the timestamp corresponding to the critical moment by calculating the minimum value of the timestamps carried in these Pass messages. This also means that once the nodes fail to collect a Quorum of Pass messages, the MyTumbler algorithm will completely lose its activity. Therefore, this also means that in the MyTumbler algorithm, nodes that do not have transactions to propose are usually required to propose an empty proposal for the block.

[0056] It is evident that, in order to maintain the algorithm's liveness, both HoneyBadgerBFT and Mytumbler typically require nodes that do not have transactions to propose to also propose an empty proposal, which results in a significant waste of resources (computing power, bandwidth).

[0057] In view of this, this specification proposes a new asynchronous consensus protocol design that can maintain the activity of the consensus protocol and continue to drive the execution of the consensus proposal pass mechanism even when consensus nodes that do not need to propose empty proposals no longer need to propose them.

[0058] Please see Figure 4 , Figure 4 This specification illustrates a consensus method in a blockchain system, which can be applied to any target consensus node in the blockchain system and includes the following execution process:

[0059] Step 402: Receive a first message or a second message broadcast by a consensus node in the blockchain system; wherein the first message contains a list of transactions proposed by the consensus node; and the second message is used to indicate to the consensus node that sent the second message that it will not propose a list of transactions in this round of consensus.

[0060] The consensus protocol proposed in this specification is also an asynchronous consensus algorithm. In an asynchronous consensus protocol, all consensus nodes participating in the consensus process are equal in role; there is no distinction between master and backup nodes. Any consensus node can not only initiate consensus proposals but also participate in the consensus process of proposals initiated by other consensus nodes.

[0061] The asynchronous consensus protocols proposed in this specification can also include the following two categories:

[0062] The first type of asynchronous consensus algorithm uses block identifiers to identify the blocks to be agreed upon; for example, it could be an asynchronous consensus algorithm represented by HBBFT. The second type of asynchronous consensus algorithm uses the timestamp corresponding to the moment the consensus proposal was initiated to identify the blocks to be agreed upon. For example, it could be an asynchronous consensus algorithm represented by MyTumbler.

[0063] For any consensus node in a blockchain network to initiate a consensus proposal, it can broadcast a first message to other consensus nodes in the blockchain system. This first message is specifically used to initiate the consensus proposal and may include a list of transactions proposed by that consensus node.

[0064] In one embodiment shown, if the asynchronous consensus protocol proposed in this specification is a consensus protocol for proposing transactions based on block identifiers, then the first message may include the block identifier of the target block to be reached for consensus; and the list of transactions proposed by the consensus node for the target block.

[0065] For example, the asynchronous consensus protocol proposed in this specification could be an improved version of the existing MyTumbler consensus protocol, which proposes consensus based on timestamps, and a new MyTumbler consensus protocol that proposes transactions based on block identifiers (e.g., the MyTumbler-Seq protocol). Based on this improved MyTumbler consensus protocol, the first message can be called a PROPOSE message. This PROPOSE message may include the block identifier (e.g., block number) of the target block, and a list of transactions packaged by the consensus node. For example, this list of transactions could be labeled m0, and m0 may include a set {tx} consisting of a series of transactions. 01 ,tx 02 , ..., tx 0n}, tx 0n This represents the nth transaction in m0.

[0066] The format of a PROPOSE message can be represented as follows:<PROPOSE:sender,n,payload> The sender is the node identifier of the consensus node that sends the PROPOSE message, n is the block identifier (e.g., block number) of the block to be agreed upon, and payload is the content of the proposal, which may include a list of transactions packaged by the consensus node.

[0067] In addition, the first message may also include the signature of the consensus node that sent the first message on m0, for example, denoted as sig. 00 Generally, the consensus node can directly sign m0 using its own private key to obtain sig. 00Alternatively, one can first perform a hash calculation on m0 to obtain a hash value (i.e., a digest value), and then sign the hash value using one's own private key to obtain sig. 00 Alternatively, you can use your own private key to directly sign the data including m0 and ts0, or sign the hash value of the data including m0 and ts0.

[0068] In one embodiment shown, if the asynchronous consensus protocol proposed in this specification is a consensus protocol based on timestamps for making consensus proposals, then the first message may include the timestamp corresponding to the moment the consensus proposal was initiated; and the list of transactions proposed by the consensus node.

[0069] For example, the asynchronous consensus protocol proposed in this specification could be the MyTumbler consensus protocol, which proposes consensus based on timestamps. Based on the MyTumbler consensus protocol, this first message can be called a VAL message. This VAL message can include the timestamp corresponding to the moment the consensus proposal was initiated, and a list of transactions packaged by the consensus node. For example, this list of transactions can also be labeled m, where m can include a set {tx1, tx2, ..., tx3} consisting of a series of transactions. n This represents the nth transaction in m.

[0070] The format of a VAL message can be represented as follows:<VAL:sender,T,payload> Where sender is the node identifier of the consensus node that sends the VAL message, T is the timestamp corresponding to the moment the consensus was initiated, and payload is the content of the proposal, which may contain a list of transactions packaged by the consensus node.

[0071] In this specification, a second message can be introduced in addition to the first message mentioned above during the transaction proposal stage. Thus, during the transaction proposal stage, in addition to proposing its own packaged transaction list by broadcasting a first message to other consensus nodes in the blockchain system, a consensus node can also broadcast a second message to other consensus nodes in the blockchain system if there are no transactions to propose.

[0072] Specifically, the second message mentioned above is used to declare that it will not propose a list of transactions in this round of consensus.

[0073] It should be noted that the content contained in the second message mentioned above may differ depending on whether the asynchronous consensus protocol is a consensus protocol for proposing transactions based on block identifiers or a consensus protocol for proposing consensus based on timestamps.

[0074] In one embodiment shown, if the asynchronous consensus protocol proposed in this specification is a consensus protocol for proposing transactions based on block identifiers, then the second message may include the block identifier of the target block to be reached, which is used to instruct the consensus node that sends the second message not to propose a list of transactions for the target block corresponding to the block identifier.

[0075] For example, taking the aforementioned asynchronous consensus protocol as an example, and specifically an improved version of the MyTumbler consensus protocol that proposes transactions based on block identifiers, based on block identifiers, the second message in this improved MyTumbler consensus protocol can be called a SKIP message. This SKIP message may include the block identifier (e.g., block number) of the target block.

[0076] The format of this SKIP message can be represented as follows:<SKIP:sender,n> Where sender is the node identifier of the consensus node that sent the SKIP message, and n is the block identifier (e.g., block number) of the block to be agreed upon.

[0077] In addition, the second message may also include the signature of the consensus node that sent the second message.

[0078] In one embodiment shown, if the asynchronous consensus protocol proposed in this specification is a consensus protocol that proposes consensus based on timestamps, then the second message may include a key timestamp to indicate that the consensus node sending the second message does not propose a list of transactions at the time corresponding to the key timestamp.

[0079] For example, the asynchronous consensus protocol proposed in this specification could be the MyTumbler consensus protocol, which proposes consensus based on timestamps. Based on the MyTumbler consensus protocol, this second message can also be called a SKIP message. This SKIP message may include a key timestamp.

[0080] The format of this SKIP message can be represented as follows:<SKIP:sender,t> Where sender is the node identifier of the consensus node that sent the SKIP message, and t is the key timestamp.

[0081] In addition, the second message may also include the signature of the consensus node that sent the second message.

[0082] It should be noted that the aforementioned key timestamps refer to the timestamps corresponding to the moments when no transactions need to be proposed, as confirmed by the consensus nodes.

[0083] For example, for an honest node, the aforementioned key timestamp could specifically be the timestamp corresponding to the moment when all transactions in its local transaction pool have been reached through consensus and uploaded to the blockchain, as determined by the honest node. However, for a malicious node, the aforementioned key timestamp could be a timestamp maliciously specified by the malicious node; in this case, the malicious node would maliciously claim that at the time corresponding to that timestamp, it has no transactions to propose (in reality, there may be transactions in the transaction pool at that time that have not yet initiated consensus).

[0084] In the aforementioned asynchronous consensus protocol, the timing for a consensus node to broadcast a second message to other consensus nodes can be defined as sending the second message to other consensus nodes only when it is determined that there are no transactions to be proposed in the local transaction pool.

[0085] In this scenario, consensus nodes in a blockchain system can determine whether there are any transactions to be proposed in their local transaction pool. For example, in practical applications, consensus nodes can periodically check whether there are any transactions to be proposed in their local transaction pool based on a certain period (such as the block generation period). If it is determined that there are no transactions to be proposed in the local transaction pool, for example, if all transactions in the local transaction pool have been consensus-agreed and uploaded to the chain, then the consensus node can broadcast a second message to other consensus nodes to declare that it has no transactions to propose.

[0086] Of course, malicious nodes may not follow this rule. Instead, if they determine that there are still transactions to be proposed in their local transaction pool, they may also broadcast a second message to other consensus nodes. For example, a malicious node might send both a first message to propose a list of transactions and a second message to declare that it has no transactions to propose.

[0087] In one embodiment shown, the second message may specifically be broadcast by a consensus node in the blockchain system when it receives the first message broadcast by other consensus nodes and determines that there is no transaction to be proposed in its local transaction pool.

[0088] In this scenario, after receiving the first message broadcast by other consensus nodes, a consensus node in the blockchain system can determine whether there is a transaction to be proposed in its local transaction pool. If there is no transaction to be proposed in the local transaction pool, it can then broadcast a second message to other consensus nodes to declare that it has no transaction to propose.

[0089] For example, taking the asynchronous consensus protocol proposed in this specification as a consensus protocol based on timestamps for consensus proposal, after receiving the first message containing timestamp t broadcast by other consensus nodes, if a consensus node determines that there is no transaction to be proposed in its local transaction pool, it can continue to broadcast a second message to other consensus nodes to declare that the consensus node has no transaction to propose at the current moment.

[0090] It should be noted that if the transmission delay between the consensus node that sends the first message and the consensus node that receives the first message is ignored, the consensus node that receives the first message can use the timestamp t contained in the first message as the key timestamp contained in the second message that is about to be sent.

[0091] Of course, if the transmission delay between the consensus node that sends the first message and the consensus node that receives the first message is too large to be ignored, the consensus node that receives the first message can also use the local timestamp corresponding to the moment when it is determined that there is no transaction to be proposed in the local transaction pool as the key timestamp in the second message to be sent.

[0092] In one embodiment shown, as previously described, the second message may carry a signature. For any consensus node, after receiving a second message broadcast by other consensus nodes in the blockchain system, it can verify the signature of the second message; if the signature verification of the second message passes, it can further broadcast the second message to other consensus nodes in the blockchain system, thereby disseminating the second message it received to other consensus nodes.

[0093] In this way, the second message received by the consensus node can be fully disseminated to other consensus nodes, and it can also prevent malicious nodes from receiving the second message sent by other consensus nodes and then failing to continue broadcasting the second message to other consensus nodes.

[0094] Step 404: Determine whether the number of consensus nodes in the blockchain system that meet the preset conditions has reached the preset threshold; wherein, the preset conditions include that the transaction list proposed by the consensus node has been agreed upon; or, the second message sent by the consensus node has been received.

[0095] The asynchronous consensus protocol proposed in this specification can also incorporate the pass mechanism mentioned above to improve consensus efficiency. That is, in a certain round of consensus, if a sufficient number of proposals have already passed, the consensus nodes in the blockchain network will no longer accept proposals from the remaining nodes. The consensus node receiving the first message can verify its correctness; for example, it can use the public key that sent the first message to verify the signature in the first message. If the signature passes verification, the received first message can be confirmed as correct. Once the consensus node that received the first message has completed its verification and confirmed its correctness, it can then further determine whether the aforementioned pass mechanism has met its triggering conditions.

[0096] In practical applications, the triggering condition for the aforementioned pass mechanism (i.e., the preset condition in step 404) is typically whether the number of proposals that have been agreed upon in a certain round of consensus has reached a threshold. That is, the pass mechanism is usually driven by the event that "the number of proposals that have been agreed upon in a round of consensus has reached a threshold." The value of this threshold may differ in different asynchronous consensus protocols.

[0097] For example, taking the HoneyBadgerBFT algorithm, the threshold mentioned above usually refers to the Quorum. In the ABA phase of the HoneyBadgerBFT algorithm, if it is determined that Quorum proposals for the target block have already been agreed upon, the votes for the remaining nodes' proposals (i.e., the initial ABA value) can be forcibly set to 0 (indicating disapproval) before proceeding to the subsequent ABA phase, indicating that proposals from the remaining nodes will no longer be accepted.

[0098] For example, taking the MyTumbler algorithm as an example, the threshold mentioned above in the MyTumbler algorithm usually refers to a configurable threshold S. In the MyTumbler algorithm, for any consensus node, after confirming that proposals made by S different consensus nodes in the blockchain system before the time corresponding to the key timestamp have been agreed upon, it can broadcast a PASS message carrying that key timestamp to declare that it will no longer accept proposals made by other consensus nodes outside of these S consensus nodes before that key timestamp.

[0099] In this specification, since there are no consensus nodes that need to propose transactions, it is no longer necessary to propose empty proposals during the proposal phase of this asynchronous consensus protocol. Therefore, to prevent consensus nodes from ceasing to propose empty proposals and affecting the activity of the asynchronous consensus protocol, the triggering conditions of the aforementioned pass mechanism introduced in the asynchronous consensus protocol can be extended. That is, the events that drive the aforementioned pass mechanism can be extended.

[0100] In a consensus round, the triggering condition for the extended pass mechanism described above could be:

[0101] The number of consensus nodes that have reached a preset threshold for the proposed transaction list has been approved by consensus; or, the number of consensus nodes that have received the second message sent by it has reached a preset threshold.

[0102] In other words, during a consensus round, in addition to using "whether the number of consensus nodes that have reached a preset threshold for the proposed transaction list has been approved" as the trigger condition for the pass mechanism, "whether the number of consensus nodes that have received the aforementioned second message has reached a preset threshold" can also be used as the trigger condition for the pass mechanism. In other words, besides being driven by the event of "whether the number of consensus nodes that have reached a preset threshold for the proposed transaction list has been approved," it is also driven by the event of "whether the number of consensus nodes that have received the aforementioned second message has reached a preset threshold."

[0103] It should be noted that when the asynchronous consensus protocols proposed in this specification are respectively a consensus protocol for proposing transactions based on block identifiers and a consensus protocol for proposing consensus based on timestamps, the triggering conditions of the extended pass mechanism mentioned above may differ to some extent.

[0104] For example, in one embodiment shown, if the asynchronous consensus protocol proposed in this specification is a consensus protocol for transaction proposals based on block identifiers, then the triggering condition for the extended pass mechanism described above could be:

[0105] The number of consensus nodes that have reached a preset threshold for the transaction list proposed for the target block to be agreed upon; or, the number of consensus nodes that have received the second message sent by the node containing the block identifier of the target block has reached a preset threshold.

[0106] In another embodiment shown, if the asynchronous consensus protocol proposed in this specification is a consensus protocol that proposes consensus based on timestamps, then the triggering condition for the extended pass mechanism described above can be:

[0107] The number of consensus nodes whose proposed transaction list has been agreed upon at any time after the time when the consensus proposal was initiated reaches a preset threshold; or, a second message sent by the node has been received, and the key timestamp contained in the second message is the timestamp corresponding to any time after the time when the consensus proposal was initiated.

[0108] As explained above, the extended pass mechanism adds a new trigger condition to the existing ones, effectively relaxing the trigger conditions. In a consensus round, even if a consensus node has no transactions to propose, it no longer needs to propose an empty proposal during the proposal phase of this asynchronous consensus protocol. The pass mechanism can still be triggered by the event of whether the number of consensus nodes that have received the second message sent by the node has reached a preset threshold, thus maintaining the liveness of the consensus protocol.

[0109] For example, under normal circumstances, if no consensus node needs to propose a transaction, and the proposal phase of the asynchronous consensus protocol no longer requires proposing an empty proposal, the number of consensus nodes whose proposed transaction list has been approved in a single consensus round may never reach the preset threshold. This would prevent the consensus protocol from triggering the aforementioned pass mechanism, causing the consensus protocol to lose its activity. However, based on the extended triggering conditions of the aforementioned pass mechanism, even if no consensus node needs to propose a transaction and the proposal phase of the asynchronous consensus protocol no longer requires proposing an empty proposal, the pass mechanism can still be triggered by determining whether the number of consensus nodes that have received the aforementioned second message has reached the preset threshold. Clearly, based on the extended triggering conditions of the aforementioned pass mechanism, the consensus protocol can still be kept active even when consensus nodes with no transactions need to propose a transaction no longer need to propose an empty proposal.

[0110] It is important to emphasize that the second message broadcast by the consensus node mentioned above is not functionally equivalent to an empty proposal put forward by the consensus node. The second message itself is only used to declare that the consensus node has no transactions to propose in this round of consensus and to trigger the execution of the aforementioned pass mechanism. Furthermore, this second message does not participate in the consensus process of the consensus protocol itself.

[0111] In this specification, when a consensus node receiving the first message determines whether the pass mechanism has met the triggering conditions, it can specifically obtain the number of consensus nodes that meet the preset conditions in this round of consensus. These preset conditions correspond to the triggering conditions and may specifically include the consensus node's proposed transaction list having been approved; or, the second message sent by the consensus node having been received. That is, for a consensus node, if its proposed transaction list has been approved, or if the second message sent by the consensus node has been received, then the consensus node can be considered to have met the preset conditions.

[0112] Accordingly, the number of consensus nodes that meet the preset conditions in this round of consensus obtained by the consensus node that received the first message can specifically include the first number of consensus nodes whose proposed transaction list has been agreed upon in this round of consensus, or the second number of consensus nodes that have received the second message sent by them in this round of consensus.

[0113] Then, the consensus node that receives the first message can determine whether the first or second quantity obtained has reached a preset threshold, in order to decide whether the pass mechanism has met the triggering condition. At this time, as long as either the first or the second quantity reaches the preset threshold, the pass mechanism can be considered to have met the triggering condition; conversely, if neither the first nor the second quantity reaches the preset threshold, the pass mechanism can be considered to have failed to meet the triggering condition.

[0114] Specifically, when obtaining the first number of consensus nodes whose proposed transaction list has been approved in this round of consensus, it can be achieved by counting the number of consensus nodes in the blockchain system whose proposed transaction list has been output as a consensus result (i.e., consensus has been approved).

[0115] For example, in practical applications, each consensus node receiving the aforementioned first message can typically create a consensus instance locally corresponding to the transaction list contained in that first message. Specifically, this consensus instance refers to an algorithm instance that performs consensus processing on the transaction list proposed by a consensus node based on the consensus algorithm disclosed in this specification. Each consensus node can initiate a consensus process for the transaction list contained in the first message by running this consensus instance locally. When counting the number of consensus nodes whose proposed transaction lists have been output as consensus results in the blockchain system, the count can be made of the number of locally created consensus instances corresponding to the transaction lists proposed by other consensus nodes for the target block, among which those consensus instances have already obtained execution results.

[0116] It should be noted that the aforementioned preset threshold can be a configurable threshold. In practical applications, this preset threshold can be flexibly configured based on the number of fault-tolerant nodes f supported by the consensus protocol adopted by the blockchain system.

[0117] For example, in one embodiment shown, the blockchain system can support switching between a conservative mode and an optimistic mode. In conservative mode, the aforementioned preset threshold corresponds to a larger value range. If the blockchain system switches to optimistic mode, the preset threshold range can be [1, f]; if the blockchain system switches to conservative mode, the preset threshold range can be [f+1, nf]; where f represents the number of fault-tolerant nodes supported by the consensus protocol used by the blockchain system; and n represents the total number of consensus nodes in the blockchain system (e.g., 3f+1).

[0118] Step 406: If the number of consensus nodes in the blockchain system that meet the preset conditions does not reach the preset threshold, perform consensus processing on the list of transactions proposed in this round of consensus; if the number of consensus nodes in the blockchain system that meet the preset conditions reaches the preset threshold, broadcast a third message to other consensus nodes; wherein, the third message is used to declare that it will no longer accept the list of transactions proposed by consensus nodes other than the consensus nodes that meet the preset conditions.

[0119] In this specification, if a consensus node that receives the first message above determines that either the first quantity or the second quantity mentioned above has reached a preset threshold, it can be considered that the above pass mechanism has met the triggering condition. At this time, the consensus node can broadcast a third message to other consensus nodes.

[0120] Specifically, the third message is used to declare that it will no longer accept transaction proposals from consensus nodes other than those that meet the above-mentioned preset conditions.

[0121] It should be noted that the content contained in the third message mentioned above may differ depending on whether the asynchronous consensus protocol is a consensus protocol for proposing transactions based on block identifiers or a consensus protocol for proposing consensus based on timestamps.

[0122] In one embodiment shown, if the asynchronous consensus protocol proposed in this specification is a consensus protocol for transaction proposal based on block identifiers, the third message may include the block identifier of the target block to be consensused, used to declare that transaction lists proposed by consensus nodes other than those meeting the preset conditions for the target block will no longer be processed; or, the consensus result of the transaction lists proposed by consensus nodes other than those meeting the preset conditions for the target block will be output as consensus failure.

[0123] For example, taking the aforementioned asynchronous consensus protocol as an example, and specifically an improved version of the original MyTumbler consensus protocol that proposes consensus based on timestamps, this third message can be called a pass message. This pass message may include the block identifier (e.g., block number) of the target block.

[0124] At this point, the format of the PASS message can be represented as follows:<PASS:sender,n,EB> Where sender is the node identifier of the consensus node that sends the PASS message; n is the block identifier (e.g., block number) of the block to be agreed upon; EB represents the list of transactions proposed for the target block by consensus nodes that meet preset conditions and are voted and approved by the consensus node that sent the PASS message; for example, it could be the list of transactions proposed for the target block that the consensus node that sent the PASS message voted and approved after the last time it sent the PASS message.

[0125] In addition, the third message may also include the signature of the consensus node that sent the third message.

[0126] In one embodiment shown, if the asynchronous consensus protocol proposed in this specification is a consensus protocol based on timestamps for consensus proposal, the third message may include the timestamp corresponding to the moment the consensus proposal was initiated (i.e., the timestamp carried in the first message), to declare that the transaction list proposed by other consensus nodes other than the consensus nodes that meet the above preset conditions before the moment corresponding to the timestamp will no longer be processed; or, the consensus result of the transaction list proposed by other consensus nodes other than the consensus nodes that meet the preset conditions before the moment corresponding to the timestamp will be output as consensus failure.

[0127] For example, the asynchronous consensus protocol proposed in this specification could be the MyTumbler consensus protocol, which proposes consensus based on timestamps. Based on the MyTumbler consensus protocol, this third message can also be called a PASS message. This PASS message can include the timestamp corresponding to the moment the consensus proposal was initiated, as carried in the first message above.

[0128] At this point, the format of the PASS message can be represented as follows:<PASS:sender,T,EB> Where sender is the node identifier of the consensus node that sends the PASS message; T is the timestamp corresponding to the moment the consensus was initiated (i.e., the timestamp contained in the first received message); EB represents the list of transactions proposed for the target block by consensus nodes that meet preset conditions and are voted and approved by the consensus node that sent the PASS message; for example, it could be the list of transactions proposed for the target block that the consensus node that sent the PASS message voted and approved after the last time it sent the PASS message.

[0129] In one embodiment shown, after the consensus node that received the first message determines that the pass mechanism has met the triggering conditions, in addition to broadcasting a third message to other consensus nodes, the consensus node can also broadcast a second message containing a vote indicating that it does not approve of the transaction list contained in the received first message to other consensus nodes.

[0130] In this way, when the first message sent by a consensus node is received, if the above-mentioned pass mechanism has met the triggering conditions, the transaction list for the target block proposal contained in the first message will no longer be accepted, and the transaction list for the target block proposal contained in the first message will be voted as unapproved, thereby speeding up the consensus process.

[0131] In one embodiment shown, any consensus node can not only broadcast and send a third message to other consensus nodes, but also receive a third message broadcast by other consensus nodes.

[0132] After collecting at least a quorum of third messages from different consensus nodes, any consensus node can obtain a list of transactions related to the target block proposal contained in the collected at least a quorum of third messages from different consensus nodes (i.e., the EB in the PASS message mentioned above). For example, it can take the union of the transaction lists contained in the at least a quorum of third messages from different consensus nodes to generate a larger transaction list. Then, it can stop processing the transaction list related to the target block proposal that is not included in the aforementioned at least a quorum of third messages; or, it can output the consensus result of the transaction list related to the target block proposal that is not included in the at least a quorum of third messages as a consensus failure. For example, it can directly output the execution result of the locally created consensus instance corresponding to the transaction list that is not included in the at least a quorum of third messages as a consensus failure (e.g., outputting 0).

[0133] In this specification, if a consensus node that receives the first message determines that neither the first quantity nor the second quantity mentioned above has reached the preset threshold, it can assume that the pass mechanism has not been triggered. At this time, the consensus node can create a consensus instance locally corresponding to the transaction list contained in the first message, run the consensus instance locally, and initiate a consensus process for the transaction list contained in the first message.

[0134] It should be noted that the consensus process performed on the transaction list contained in the first message usually depends on the specific type of consensus protocol used by the blockchain system. Different types of consensus protocols will usually have some differences in the process of reaching consensus on the transaction list.

[0135] The following example will illustrate in detail the process of reaching consensus on the above list of transactions.

[0136] In this embodiment, the consensus protocol used by the blockchain system can be an improved version of the original MyTumbler consensus protocol, which proposes consensus based on timestamps, and a new MyTumbler consensus protocol that proposes transactions based on block identifiers (for example, it can be called the MyTumbler-Seq protocol).

[0137] Based on the MyTumbler-Seq protocol, the first message mentioned above can be called a PROPOSE message.

[0138] For example, from the perspective of Node0 initiating a consensus proposal, the interaction process can be as follows: Figure 5As shown. Node0 can broadcast a PROPOSE to Node1, Node2, and Node3 to initiate a consensus proposal for a target block. This PROPOSE message may include the block identifier (e.g., block number) of the target block, and a list of transactions packaged by Node0. For example, this list of transactions may be labeled m0, and m0 may include a set {tx} consisting of a series of transactions. 01 ,tx 02 , ..., tx 0n}, tx 0n This represents the nth transaction in m0.

[0139] Upon receiving the first message, the consensus node, while running the created consensus instance, initiates a consensus process on the transaction list in that first message. Each round of consensus voting can include at least two rounds of message interaction:

[0140] In the first round of message exchange, the consensus node that receives the first message can broadcast the fourth message to other consensus nodes.

[0141] Specifically, the fourth message is used for consensus voting on the transaction list contained in the first message. This fourth message may include the votes of the consensus node that sent it regarding the transaction list in the first message. Alternatively, it may also include the block identifier of the target block to be agreed upon.

[0142] For example, please continue to see Figure 5 In the first round of message exchange, after receiving the PROPOSE message (i.e., the first message) broadcast by Node 1, Node 2, and Node 3 can each broadcast a fourth message to the other consensus nodes. This fourth message can be called the ENDORSE message. The ENDORSE message can include a vote on the list of transactions proposed by Node 0 for the target block.

[0143] In one embodiment shown, the ENDORSE message can be formatted as follows:<ENDORSE:sender,n,b> Where sender is the node identifier of the consensus node that initiates the proposal for block n (i.e., the node identifier of the consensus node that sends the above PROPOSE message), n is the block identifier of the block to be agreed upon (e.g., the block number), and b is the voting content of the consensus node that sends the ENDORSE message regarding the transaction list proposed by sender to block n (i.e., the transaction list contained in the above PROPOSE message).

[0144] It should be noted that in practical applications, the consensus process for the transaction list contained in the PROPOSE message often requires multiple rounds of voting to achieve consensus. Therefore, the format of the ENDORSE message can also include the rounds in which consensus is reached on the transaction list. These rounds typically represent the rounds of consensus voting on the same transaction list. For example, in this case, the format of the ENDORSE message can be represented as follows:<ENDORSE:sender,n,b,r> ; where r represents the round of consensus voting for the list of transactions proposed by the sender to block n. The meanings of the other parameters in the ENDORSE format are the same as those in the PROPOSE message mentioned earlier, and will not be repeated here.

[0145] In one embodiment shown, the voting content included in the ENDORSE message can specifically be a vote value for the proposed list of transactions. This vote value typically includes a first preset value indicating approval of the transaction list and a second preset value indicating disapproval. For example, 1 can represent approval of the transaction list, and 0 can represent disapproval.

[0146] In practical applications, to distinguish between the first round of consensus voting and other rounds, in the first round of consensus voting on the transaction list, the digest value (e.g., hash value) of the transaction list can be used to represent the vote value for approving the transaction list, and the aforementioned second preset value can be used to represent the vote value for disapproving the transaction list. In other rounds of consensus voting on the transaction list, the first preset value can still be used to represent approval of the transaction list, and the aforementioned second preset value can be used to represent disapproval of the transaction list.

[0147] For example, if r=0 represents the first round of consensus on the transaction list, then the format of the ENDORSE message exchanged between consensus nodes during the first round of consensus can be represented as follows:<ENDORSE:sender,n,h / 0,r=0> Where h represents the summary value of the above transaction list. h / 0 indicates that the vote value for the above transaction list contained in the ENDORSE message is h or 0. In other rounds of consensus on the transaction list, the format of the ENDORSE message exchanged between consensus nodes can be represented as follows:<ENDORSE:sender,n,0 / 1,r> 0 / 1 indicates that the vote value for the above list of transactions contained in the ENDORSE message is 1 or 0.

[0148] It should be noted that in the first round of message exchange, Node0 may not participate in broadcasting the fourth message; only Node1, Node2, and Node3 may broadcast the fourth message to the other consensus nodes. This is because Node0's initiation of the consensus proposal in the first round inherently indicates that Node0 approves of the transaction list contained in the first message.

[0149] It is also important to emphasize that during the first round of message interaction, consensus nodes can change their voting results and vote again, i.e., send multiple ENDORSE messages containing different voting content. For example, Node1 can initially send an ENDORSE message containing the hash value of the transaction list to indicate its approval of the transaction list in the consensus proposal, and subsequently send an ENDORSE message with the content of 0 to indicate its disapproval of the transaction list in the consensus proposal. Similarly, Node2 can initially send an ENDORSE message with the content of 0 to indicate its disapproval of the transaction list in the consensus proposal, and subsequently send an ENDORSE message with the hash value of the transaction list to indicate its approval of the transaction list in the consensus proposal.

[0150] In addition, the fourth message may also include a signature of the transaction list.

[0151] As mentioned earlier, in the first round of message interaction, the consensus node that receives the first message can continue to broadcast the fourth message to other consensus nodes to conduct consensus voting on the list of transactions proposed for the target block contained in the first message. In the second round of message interaction, the consensus node that receives the fourth message can collect votes from different consensus nodes on the list of transactions contained in the first message.

[0152] For example, in one instance, during the second round of message interaction, each consensus node that receives the ENDORSE message can collect ENDORSE messages from different consensus nodes that contain the same round number r and the same sender and n, and then further obtain the votes contained in the collected ENDORSE messages.

[0153] In the second round of message interaction, for any consensus node that receives the fourth message, if it has collected at least Quorum votes from different consensus nodes indicating approval of the above transaction list, and has not broadcast different votes for the transaction list, it can continue to broadcast the fifth message to other consensus nodes.

[0154] The specific number corresponding to Quorum typically depends on the total number of consensus nodes in the blockchain network. For example, if the total number of consensus nodes n in the blockchain network is 3f+1, where f represents the number of fault-tolerant nodes supported by the consensus protocol used by the blockchain system, then the number corresponding to Quorum could be 2f+1.

[0155] The aforementioned fifth message specifically promises not to change the vote on the transaction list. In other words, the consensus node that broadcasts the fifth message will not change its voting results in subsequent rounds of voting and will maintain the same voting content as in the first round.

[0156] Since the fifth message is sent after collecting at least a quorum of votes from different consensus nodes indicating their approval of the aforementioned transaction list, it can also include these votes. In the next round of voting, the consensus node that sent the fifth message needs to maintain its vote in favor of the transaction list.

[0157] For example, please continue to see Figure 5 In the second round of message interaction, after Node1, Node2, and Node3 broadcast the ENDORSE message to other consensus nodes, Node0, Node1, Node2, and Node3 can all begin collecting the voting content for the aforementioned transactions contained in the ENDORSE messages sent by other consensus nodes. If they have collected at least Quorum votes from different consensus nodes indicating their approval of the aforementioned transaction list, and have not broadcast different votes for this transaction list themselves, they will continue to broadcast a fifth message to other consensus nodes. This fifth message can be called a PROM message. The PROM message may include a vote indicating approval of the transaction list proposed by Node0.

[0158] In one embodiment shown, the format of the PROM message can be represented as follows:<PROM:sender,n,b,r> ; where b represents the vote value that approves the above transaction list. The meanings of the other parameters in the format of this PROM message are the same as those in the previously mentioned ENDORSE and PROPOSE messages, and will not be repeated here.

[0159] In addition, the fifth message may also include a signature of the transaction list, which will not be elaborated further.

[0160] In one embodiment shown, during the second round of message interaction, for any consensus node that receives the second message, if it has collected at least Quorum votes from different consensus nodes indicating approval of the aforementioned transaction list, and has itself broadcast different votes for the transaction list, it can continue to broadcast the sixth message to other consensus nodes.

[0161] It should be noted that, unlike the fifth message, the sixth message no longer carries the function of promising not to change the vote on the transaction list. In other words, the consensus node that broadcasts the sixth message can change its vote in subsequent rounds of voting. For example, in the first round of voting, a vote of 1 indicates approval of the transaction list, while in the next round, the vote can be changed to 0, indicating disapproval.

[0162] Since the sixth message is sent after collecting at least a quorum of votes from different consensus nodes indicating their approval of the aforementioned transaction list, it can also include these votes. In the next round of voting, the consensus node that sent the sixth message can change its vote to approve the transaction list.

[0163] For example, please continue to see Figure 5 In the second round of message interaction, after Node1, Node2, and Node3 broadcast the ENDORSE message to other consensus nodes, Node0, Node1, Node2, and Node3 can all begin collecting the votes on the aforementioned transaction list contained in the ENDORSE messages sent by other consensus nodes. If they have collected at least Quorum votes from different consensus nodes indicating their approval of the transaction list, and have themselves broadcast different votes for that transaction list, they will continue to broadcast a sixth message to other consensus nodes. This sixth message can be called a COMMIT message. The COMMIT message may also include a vote indicating approval of the transaction list proposed by Node0.

[0164] In one embodiment shown, the format of the COMMIT message can be represented as follows:<PROM:sender,n,b,r> ; where b represents the vote value that approves the above list of transactions. The meanings of the other parameters in the format of this COMMIT message are the same as those in the previously mentioned ENDORSE and PROPOSE messages, and will not be repeated here.

[0165] In addition, the sixth message may also include a signature of the transaction list, which will not be elaborated further.

[0166] It is important to emphasize that each of the at least Quorum-sized consensus nodes in a blockchain network can perform the two rounds of message interaction mentioned above to reach consensus on the list of transactions proposed by other consensus nodes.

[0167] For example, the above Figure 5 The embodiment described is the consensus interaction process from the perspective of Node0 initiating a consensus proposal. Figure 5 The consensus interaction process from the perspective of Node1, Node2, and Node3 initiating consensus proposals can be found in [link to relevant documentation]. Figure 6 , 7 As shown in Figure 8. (Comprehensive) Figure 5-8 From a holistic perspective, the process of reaching consensus on a specific target block within a blockchain network can be... Figure 5-8 The superposition of.

[0168] Each consensus node runs a consensus instance locally corresponding to the transaction list proposed by a certain consensus node. During the consensus process of the transaction list proposed by that consensus node, after executing the second round of message interaction mentioned above and broadcasting the fifth message and the sixth message mentioned above to other consensus nodes, it can collect the fifth message or the fifth message mentioned above broadcast by other consensus nodes.

[0169] For example, in one instance, after broadcasting a PROM message or COMMIT message to other consensus nodes, it is also possible to collect PROM messages or COMMIT messages from different consensus nodes that have the same round number r and the same sender and n.

[0170] Then, based on the collected fifth or sixth message mentioned above, it can be determined whether each node has reached a consensus vote on the above transaction list.

[0171] If any consensus node collects at least Quorum fifth messages from different consensus nodes containing votes indicating approval of the transaction list, it can be determined that Quorum of consensus nodes in the blockchain network have voted to approve the transaction list and promised not to change the voting results. In this case, the transaction list can be output as at least a portion of the consensus result of the target block corresponding to the aforementioned block identifier. The output transaction list at this time is the execution result of the aforementioned consensus instance.

[0172] In this way, under certain conditions, the consensus process can be shortened to two rounds to complete one consensus, and binary consensus can be avoided during the consensus process.

[0173] In one implementation shown, if any consensus node collects at least a Quorum of messages from different consensus nodes, but the collected messages include the sixth message in addition to the fifth message mentioned above, it can be determined that the number of consensus nodes in the blockchain network who voted to approve the transaction list and promised not to change the voting results has not reached a Quorum. In this case, a binary consensus protocol can be run to achieve binary consensus on the set of votes contained in the at least a Quorum of collected messages. For example, a common binary consensus protocol could be a public coin-flipping algorithm.

[0174] It should be noted that for a consensus node that has collected at least Quorum messages from different consensus nodes, the voting values ​​in the fifth and sixth messages contained in the at least Quorum messages it has collected may or may not be the same.

[0175] In other words, for this consensus node, regardless of whether the voting values ​​in the fifth and sixth messages contained in the at least Quorum messages it receives are the same, it can trigger the execution of the binary consensus protocol to achieve binary consensus on the set of votes contained in the at least Quorum messages.

[0176] In one implementation shown, for a given consensus instance, if it is determined that a binary consensus protocol needs to be run to perform binary consensus on the set of votes contained in at least the Quorum messages collected, an additional round of message interaction can be added on top of the two rounds of message interaction mentioned above.

[0177] In this case, if any consensus node collects at least Quorum messages from different consensus nodes, but the collected messages contain not only the fifth message mentioned above but also the sixth message mentioned above, then it can continue to broadcast the seventh message to other consensus nodes.

[0178] Specifically, the seventh message is used to propagate the vote set contained in at least a quorum of messages collected by each consensus node to other consensus nodes. This seventh message may include the vote set contained in the collected quorum of messages.

[0179] For example, this seventh message can be referred to as a CON message. In one embodiment shown, the format of the COMMIT message can be represented as follows:<CON:sender,n,br,r> ; where br represents the set of votes contained in at least Quorum messages collected. The meanings of the other parameters in the format of this CON message are the same as those in the previously mentioned ENDORSE and PROPOSE messages, and will not be repeated here.

[0180] After broadcasting the seventh message to other consensus nodes, each consensus node can also collect the seventh messages broadcast by other consensus nodes. After collecting at least Quorum seventh messages from different consensus nodes, it can calculate the union of the vote sets contained in the above at least Quorum seventh messages to obtain the target vote set, and then run the binary consensus protocol to perform binary consensus on the target vote set.

[0181] In one embodiment shown, if a consensus is reached through binary consensus on the votes in the aforementioned voting set that indicate approval of the aforementioned transaction list, then the transaction list can be output as at least a portion of the consensus result for the target block corresponding to the aforementioned block identifier. The output transaction list at this time represents the execution result of the aforementioned consensus instance.

[0182] Conversely, if the binary consensus fails to reach an agreement on the votes in the aforementioned voting set that indicate approval of the aforementioned transaction list, the first and second rounds of message interactions mentioned above can be re-executed to perform the next round of consensus voting for the transaction list corresponding to that consensus instance, until the execution result of the relevant consensus instance is obtained.

[0183] It should be noted that the specific type of binary consensus protocol used by the consensus nodes is not limited in this specification; for example, it could be a public coin toss algorithm. The process of calculating binary consensus on the aforementioned voting set based on the public coin toss algorithm typically depends on the technology used to implement the algorithm in practical applications, and will not be detailed here. Those skilled in the art can refer to relevant technical records; for example, the aforementioned public coin algorithm could be a public coin algorithm implemented based on threshold signature technology.

[0184] In this specification, for any consensus node, once the consensus process described above has been completed for the transaction list proposed by each consensus node for the target block, the consensus node can also obtain the transaction list proposed by each consensus node for the target block as the consensus result output, and summarize the obtained transaction list into a transaction set for constructing the target block. Then, the transactions in this transaction set can be sorted, and the target block can be constructed based on the sorted transaction set.

[0185] The sorting method used when sorting the transactions in the above transaction set is not specifically limited in this specification;

[0186] For example, in one embodiment shown, the hash value of each transaction in the transaction set can be calculated, and the transactions in the target transaction set can be sorted based on the hash value;

[0187] This sorting method allows transactions to be sorted based on their content.

[0188] In another embodiment shown, the transactions in the transaction set can be merged with the transaction set individually to calculate a hash value; that is, each transaction and the transaction set are merged as a whole to calculate a hash value, and then the transactions in the transaction set are sorted based on the calculated hash value.

[0189] If the former method of sorting transactions based on hashes of transaction content is adopted, the transaction sender can intervene in the hash value calculated based on the transaction content by adjusting the transaction content, in order to find a smaller hash value, thereby securing a higher ranking position for the transaction in the target block for priority execution.

[0190] If the latter method is adopted, which involves merging each transaction in the transaction set with the transaction set individually to calculate a hash value, and then sorting the transactions in the transaction set based on the hash value, the transaction sender cannot predict the content of the entire transaction set and therefore cannot interfere with the final calculated hash value. This fundamentally eliminates the possibility of adjusting transaction content to give a transaction a higher ranking position in the target block for priority execution.

[0191] In the above technical solution, by allowing consensus nodes to broadcast a second message to other consensus nodes during the transaction proposal phase of the consensus protocol, it can declare that it has no transactions to propose in this round of consensus. This means that consensus nodes that have no transactions to propose do not need to propose empty proposals during the transaction proposal phase, thereby avoiding the waste of computing power and bandwidth resources.

[0192] Moreover, since the number of consensus nodes that have received the second message sent by it in a round of consensus will also serve as the trigger condition for the pass mechanism of the consensus protocol, in this way, consensus nodes that do not have transactions to propose can still continue to push the pass mechanism for consensus proposals without needing to propose empty proposals, without affecting the activity of the consensus protocol.

[0193] For example, under normal circumstances, if there are no consensus nodes that need to propose transactions, and there is no need to propose empty proposals during the proposal phase of the asynchronous consensus protocol, it may result in the number of consensus nodes whose proposed transaction list has been approved in a round of consensus never reaching the preset threshold. This would prevent the consensus protocol from triggering the aforementioned pass mechanism, causing the consensus protocol to lose its activity.

[0194] Based on the extended triggering conditions of the aforementioned pass mechanism, even if a consensus node has no transactions to propose and no longer needs to propose an empty proposal during the proposal phase of the asynchronous consensus protocol, the pass mechanism can still be triggered by determining whether the number of consensus nodes that have received the second message sent by it has reached a preset threshold. Clearly, based on the extended triggering conditions of the aforementioned pass mechanism, the consensus protocol can remain active even when consensus nodes with no transactions to propose no longer need to propose empty proposals.

[0195] This application also provides an embodiment of a blockchain system, including:

[0196] Receive a first message or a second message broadcast by a consensus node in the blockchain system; wherein the first message contains a list of transactions proposed by the consensus node; and the second message is used to declare that the consensus node that sent the second message will not propose a list of transactions in this round of consensus.

[0197] Determine the number of consensus nodes in the blockchain system that meet preset conditions; wherein, the preset conditions include that the transaction list proposed by the consensus node has been agreed upon; or, the second message sent by the consensus node has been received;

[0198] If the number of consensus nodes in the blockchain system that meet the preset conditions does not reach the preset threshold, consensus processing is performed on the transaction list contained in the received first message; if the number of consensus nodes in the blockchain system that meet the preset conditions reaches the preset threshold, a third message is broadcast to other consensus nodes; wherein, the third message is used to declare that transaction lists proposed by consensus nodes other than those that meet the preset conditions will no longer be accepted.

[0199] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using a hardware physical module. For example, a Programmable Logic Device (PLD) (e.g., a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program a digital system themselves to "integrate" it onto a PLD, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0200] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0201] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this specification does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments may be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0202] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0203] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in the same or more software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0204] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0205] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0206] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0207] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0208] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0209] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0210] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0211] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0212] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0213] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of these embodiments. Various modifications and variations can be made to these embodiments by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A consensus method in a blockchain system, applied to any target consensus node in the blockchain system, comprising: Receive a first message or a second message broadcast by a consensus node in the blockchain system; wherein the first message contains a list of transactions proposed by the consensus node; and the second message is used to declare that the consensus node that sent the second message will not propose a list of transactions in this round of consensus. Determine the number of consensus nodes in the blockchain system that meet preset conditions; wherein, the preset conditions include that the transaction list proposed by the consensus node has been agreed upon; or, the second message sent by the consensus node has been received; If the number of consensus nodes in the blockchain system that meet the preset conditions does not reach the preset threshold, consensus processing is performed on the transaction list contained in the received first message; if the number of consensus nodes in the blockchain system that meet the preset conditions reaches the preset threshold, a third message is broadcast to other consensus nodes; wherein, the third message is used to declare that transaction lists proposed by consensus nodes other than those that meet the preset conditions will no longer be accepted.

2. The method as described in claim 1, wherein the second message carries a signature; The method further includes: Verify the signature of the second message received from the consensus node in the blockchain system; If the signature verification for the second message passes, the second message is then broadcast to other consensus nodes in the blockchain system.

3. The method as described in claim 2, broadcasting the second message to other consensus nodes in the blockchain system, comprising: Upon receiving the first message broadcast by other consensus nodes in the blockchain system, and determining that there are no transactions to be proposed in the local transaction pool, the second message is broadcast to the other consensus nodes in the blockchain system.

4. The method as described in claim 1, wherein the preset threshold is a configurable threshold.

5. The method as described in claim 4, wherein the blockchain system supports switching between a conservative mode and an optimistic mode; wherein, If the blockchain system switches to optimistic mode, the preset threshold value ranges from [1, f]; if the blockchain system switches to conservative mode, the preset threshold value ranges from [f+1, nf]; where f represents the number of fault-tolerant nodes supported by the consensus protocol adopted by the blockchain system; and n represents the total number of consensus nodes in the blockchain system.

6. The method as described in claim 3, wherein the consensus protocol used by the blockchain system is a consensus protocol for proposing transactions based on block identifiers; The first message contains the block identifier of the target block to be consensus-reached; And, the list of transactions proposed by the consensus node for the target block; The second message contains the block identifier of the target block, used to instruct the consensus node that sent the second message not to propose a list of transactions for the target block; The preset conditions include: the consensus node's proposed transaction list for the target block has been approved by consensus; or, the second message containing the block identifier of the target block has been received from the consensus node. The third message contains the block identifier of the target block, and is used to declare that the transaction list proposed by other consensus nodes for the target block, except for consensus nodes that meet the preset conditions, will no longer be processed. Alternatively, the consensus result of the transaction list proposed by consensus nodes other than those that meet the preset conditions for the target block can be output as a consensus failure.

7. The method as described in claim 6, wherein the consensus protocol used by the blockchain system is the MyTumbler consensus protocol, which proposes transactions based on block identifiers.

8. The method as described in claim 3, wherein the consensus protocol used by the blockchain system is a consensus protocol based on timestamps for consensus proposal; The first message contains a timestamp corresponding to the moment the consensus proposal was initiated; And, the list of transactions proposed by the consensus node; The second message contains a key timestamp indicating that the consensus node that sent the second message does not propose a list of transactions at the time corresponding to the key timestamp. The preset conditions include: the transaction list proposed by the consensus node at any time after the time of initiating the consensus proposal has been agreed upon; or, a second message sent by the consensus node has been received, and the key timestamp contained in the second message is the timestamp corresponding to any time after the time of initiating the consensus proposal. The third message includes a timestamp corresponding to the moment the consensus proposal was initiated, used to declare that transaction lists proposed by consensus nodes other than those meeting the preset conditions before the time corresponding to the timestamp will no longer be processed; or, the consensus result of the transaction list proposed by consensus nodes other than those meeting the preset conditions before the time corresponding to the timestamp will be output as consensus failure.

9. The method as described in claim 8, wherein the consensus protocol used by the blockchain is the MyTumbler consensus protocol.

10. A blockchain system, comprising: Receive a first message or a second message broadcast by a consensus node in the blockchain system; wherein the first message contains a list of transactions proposed by the consensus node; and the second message is used to indicate to the consensus node that sent the second message not to propose a list of transactions in this round of consensus. Determine the number of consensus nodes in the blockchain system that meet preset conditions; wherein, the preset conditions include that the transaction list proposed by the consensus node has been agreed upon; or, the second message sent by the consensus node has been received; If the number of consensus nodes in the blockchain system that meet the preset conditions does not reach the preset threshold, consensus processing is performed on the list of transactions proposed in this round of consensus; conversely, if the number of consensus nodes in the blockchain system that meet the preset conditions reaches the preset threshold, a third message is broadcast to other consensus nodes; wherein, the third message is used to declare that transaction lists proposed by consensus nodes other than those meeting the preset conditions will no longer be accepted.

Images