CN116846906A

CN116846906A - Consensus method and block chain link point

Info

Publication number: CN116846906A
Application number: CN202310801507.6A
Authority: CN
Inventors: 徐文博
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2023-06-30
Filing date: 2023-06-30
Publication date: 2023-10-03

Abstract

One or more embodiments of the present specification provide a consensus method, a blockchain node, applied to any target consensus node in a blockchain system, comprising: receiving a first message or a second message broadcast transmitted by a consensus node in the blockchain system; wherein the first message comprises a list of transactions proposed by the consensus node; the second message is used for stating that the consensus node sending the second message does not propose a transaction list in the round of consensus; determining the number of consensus nodes meeting preset conditions in a block chain system; wherein the preset condition comprises that the transaction list proposed by the consensus node is consensus-passed; or, a second message sent by the consensus node has been received; if the number of the consensus nodes meeting the preset conditions in the block chain system reaches a preset threshold, broadcasting a third message to other consensus nodes; wherein the third message is used for declaring that the transaction list proposed by the other consensus nodes except the consensus node meeting the preset condition is no longer accepted.

Description

Consensus method and block chain link point

Technical Field

The embodiment of the specification belongs to the technical field of blockchain, and particularly relates to a consensus method and a blockchain node.

Background

In a blockchain system, different participants can establish a distributed blockchain network through deployed nodes (nodes). The decentralized (or multicentric) distributed ledger constructed using the chain block structure is stored on each node (or on a large number of nodes, such as consensus nodes) in the distributed blockchain network. Such blockchain systems need to address the problem of consistency and correctness of ledger data on each of a plurality of nodes that are de-centralized (or multicentric). Each node is operated with a blockchain program, and under the design of certain fault tolerance requirements, all the loyalty nodes are guaranteed to have the same transaction through a consensus (consensus) mechanism, so that the consistency of the execution results of all the loyalty nodes on the same transaction is guaranteed, and the transaction and the execution results are packed to generate a block.

The consensus protocol of the current mainstream includes: proof of Work (POW), proof of equity (POS), proof of commission (Delegated Proof of Stake, DPOS), practical bayer fault tolerance (Practical Byzantine Fault Tolerance, PBFT) algorithm, melder bayer fault tolerance (honeybadger bft) algorithm, and the like.

Among the various consensus protocols listed above are both asynchronous and non-asynchronous. For example, the PBFT protocol belongs to the semi-synchronous (partial synchronous) protocol, while the honeybadger bft algorithm belongs to an asynchronous (asynchonous) protocol.

Because asynchronous protocols are applicable to asynchronous networks, i.e., messages between nodes in the network can be delayed arbitrarily but eventually reached, asynchronous consensus protocols are currently more widely used than non-asynchronous consensus protocols.

Disclosure of Invention

The specification provides a consensus method in a blockchain system, which is applied to any target consensus node in the blockchain system, and comprises the following steps:

receiving a first message or a second message broadcast transmitted by a consensus node in the blockchain system; wherein the first message contains a list of transactions proposed by the consensus node; the second message is used for declaring that the consensus node sending the second message does not propose a transaction list in the round of consensus;

determining the number of consensus nodes meeting preset conditions in the block chain system; wherein the preset condition comprises that the transaction list proposed by the consensus node is consensus-passed; or the second message sent by the consensus node is received;

if the number of the consensus nodes meeting the preset conditions in the blockchain system does not reach a preset threshold, performing consensus processing on the transaction list contained in the received first message; if the number of the consensus nodes meeting the preset condition in the block chain system reaches the preset threshold, broadcasting a third message to other consensus nodes; wherein the third message is used for declaring that the transaction list proposed by other consensus nodes except the consensus node meeting the preset condition is no longer accepted.

The present specification also proposes a blockchain system comprising:

receiving a first message or a second message broadcast transmitted by a consensus node in the blockchain system; wherein the first message contains a list of transactions proposed by the consensus node; the second message is used for indicating that the consensus node sending the second message does not propose a transaction list in the round of consensus;

if the number of the consensus nodes meeting the preset conditions in the blockchain system does not reach a preset threshold, performing consensus processing on a transaction list proposed in the received round of consensus; otherwise, if the number of the consensus nodes meeting the preset condition in the blockchain system reaches the preset threshold, broadcasting a third message to other consensus nodes; wherein the third message is used for declaring a transaction list proposed by other consensus nodes than the consensus node that no longer accepts the preset condition.

In the above embodiment, by allowing the consensus node to broadcast and send a second message to other consensus nodes in the transaction proposal phase of the consensus protocol, it is stated that there is no transaction that needs to be proposed in the round of consensus, so that those consensus nodes that do not need to be proposed in the transaction proposal phase can no longer need to propose empty proposals, thereby avoiding the waste of resources such as calculation power, bandwidth and the like. Moreover, since the number of consensus nodes which have received the second message sent by the consensus nodes in a round of consensus will also serve as a trigger condition for the pass mechanism of the consensus protocol, in this way, the pass mechanism proposed for the consensus can still be pushed continuously without affecting the activity of the consensus protocol in the case that no proposal is proposed by the consensus nodes which do not need to be proposed for a transaction.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings that are needed in the description of the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments described in the present disclosure, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic diagram of a conventional stage of a practical Bayesian fault tolerance algorithm in an embodiment of the present disclosure;

fig. 2 is a schematic diagram of a view switching phase of a practical bayer fault-tolerant algorithm according to an embodiment of the present disclosure;

FIG. 3 is a schematic diagram of a meld Bayesian fault tolerance algorithm in an embodiment of the present disclosure;

FIG. 4 is a flow chart of a consensus method in a blockchain system in an embodiment of the present disclosure;

FIG. 5 is a schematic diagram of a common algorithm in one embodiment of the present disclosure;

FIG. 6 is a schematic diagram of a common algorithm in one embodiment of the present disclosure;

FIG. 7 is a schematic diagram of a common algorithm in one embodiment of the present disclosure;

fig. 8 is a schematic diagram of a common algorithm in an embodiment of the present description.

Detailed Description

In order to make the technical solutions in the present specification better understood by those skilled in the art, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only some embodiments of the present specification, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are intended to be within the scope of the present disclosure.

The currently mainstream consensus protocols can generally comprise two types of asynchronous consensus protocols and non-asynchronous consensus protocols.

For example, the PBFT protocol belongs to the semi-synchronous (partial synchronous) protocol, while the honeybadger bft algorithm belongs to an asynchronous (asynchonous) protocol.

Taking PBFT as an example, in the PBFT algorithm, all copies (replicas) run in a rotation process (succession of configuration), called View. In a certain view, one copy acts as a primary node (primary) and the other copies act as backup nodes (backup). Views are integers numbered consecutively. The master node is calculated from the formula p=v mod|r|, where v is the view number, p is the copy number, and |r| is the number of copy sets. It is assumed in this algorithm that when there are at most f copies (i.e., nodes) to fail, if there are at least 3f+1 copies in total, it is guaranteed that security and activity are provided in an asynchronous system. In order to be able to ensure the data consistency requirements and fault tolerance requirements of all the replicas, the set of a certain number of replicas required, typically the set of most nodes in the distributed system, constitutes the majority (Quorum). For example, if the total node number n is 3f+1 (n=3f+2 or n=3f does not generally increase the fault tolerance effect), the number of quum is 2f+1. Thus, for a distributed system comprising four nodes, any three nodes may constitute a Quorum.

PBFT includes two processes, normal Case Phase and View Change Phase.

Referring to fig. 1, fig. 1 is a flow chart of a Normal Case Phase (conventional phase) process.

Normal Case Phase mainly comprises three stages of PRE-preparation, preparation and COMMIT, wherein node No. 3 may represent a down node (indicated by x in fig. 1), for example. When the Primary node fails, a view change process needs to be started, so that state adjustment is performed when the system has a fault, and a new Primary node is changed (for example, after the view is changed, the Primary node Primary is Replica 1).

Referring to fig. 2, fig. 2 is a schematic diagram of View Change Phase (view switching). The client may set a timeout mechanism if the master node drops or does not broadcast the client's request, etc. If timed out, the client may broadcast a request message to all duplicate nodes. After the duplicate node detects that the master node is bad or down, a View Change protocol phase may also be initiated to replace the master node (often referred to simply as "Change master"). In addition, the PRE-PREPARE, PREPARE and COMMIT three-phase consensus process may fail due to the main node initiating the wrong proposal, or the PREPARE, COMMIT phase may not be consistent with the number of Quorum (such as 2f+1 of 3f+1 nodes, also called Quorum), and the consensus cannot be completed. It is also possible in these cases to initiate the View Change protocol phase to replace the master node.

The PBFT protocol belongs to the semi-synchronous (partial synchronous) protocol, which is characterized by the assumption that the network is initially asynchronous, but can start to synchronize from a certain moment. To let different nodes agree on the same proposal in the network, the simplest way is to set up a master node, which unifies the ideas of the various nodes. By setting the timer, master node errors can be prevented. In PBFT, backups initiation View Change Phase is triggered to replace the master node if Normal Case Phase is not completed within a limited time. The PBFT secures the master node in one place and all requests may be sent to the master node before being broadcast by the master node to other consensus nodes. In addition to introducing additional delay in sending requests to the master node, the ingress and egress bandwidth of the master node may also become a performance bottleneck.

A single master node type protocol such as PBFT has only the master node capable of initiating a consensus proposal in the same consensus, and other nodes have no capability of initiating a consensus proposal. Alternatively, if other nodes also have a proposal, the proposal needs to be forwarded to the master node, which initiates the proposal instead. The former is unfair to the authority of the consensus node to construct blocks, while the latter may propose backup nodes, but increase the pressure of the primary node's egress bandwidth. Neither is particularly suitable for the case where most consensus nodes need to initiate a consensus proposal.

In contrast, the honeybadger bft (also commonly referred to as HBBFT) algorithm belongs to an asynchronous (asynchroous) protocol. Asynchronous protocols are applicable to asynchronous networks, i.e. messages between nodes in the network can be arbitrarily delayed but eventually arrive. The timer is removed from HoneyBadgerBFT and the protocol execution is driven by the message. Meanwhile, all nodes in the HoneyBadgerBFT algorithm are peer-to-peer, and no division of a main node and a backup node exists, so that a main exchanging process does not exist. The asynchronous network consensus protocol such as HBBFT has no concept of master node, each node can propose a request to try to construct a block, so that the asynchronous network protocol relieves the problems of fairness and single node bottleneck to a certain extent.

Referring to fig. 2, fig. 3 is a flowchart of a HoneyBadgerBFT algorithm single node angle.

In fact, as previously described, all nodes in the honeybadger bft algorithm are peer-to-peer, that is, all nodes may perform the flow shown in fig. 3. As shown in fig. 3, from a single-node perspective, honeyBadgerBFT mainly includes two phases, reliable BroadCast (RBC) and asynchronous consensus (Asynchronous Binary Agreement, ABA, asynchronous binary protocol, also referred to as "01 asynchronous binary consensus"). In addition, there is an asynchronous common subset (Asynchronous Common Subset, ACS) protocol over RBC and ABA. The RBC stage comprises at least Rval, echo, ready three message interactions, and the ABA stage comprises at least BVAL, AUX and Coin three message interactions. RBC use three rounds of message interactions to ensure reliable proposal broadcasting. ABA first performs two rounds of voting (BVAL and AUX messages) and then uniformly recognizes the proposals of each node by means of Coin casting (coi), thereby bypassing the requirement of the semi-synchronization protocol for network synchronization.

One HoneyBadgerBFT consensus goes through RBC stage and at least one ABA stage. In the preferred case, the HoneyBadgerBFT consensus process can be ended with a probability of 1/2, thus, a consensus needs to be completed after 6 rounds. In addition, there is a 1/4 probability that a further ABA process will be entered, such as the second ABA process (the ABA process represented by the 7, 8, 9 rounds in fig. 3), there is a 1/4 probability that the second round will end, and there is a probability that at least 1/4 can end the HoneyBadgerBFT consensus process, thus, 9 rounds are needed to complete a consensus. After the second ABA process, there is an overall probability of 1/8 that one would go into the next ABA process … … and so on.

In summary, honeybadger bft includes at least one RBC (three rounds) and one ABA (three rounds), and if the voting result of ABA is inconsistent with the coin casting result, the protocol goes into a new round of ABA (at least three additional rounds).

It can be seen that the coin-freed mechanism introduced by honeybadger bft brings uncertainty to the round of consensus, which may cause an increase in the delay of consensus.

In addition, for a final generated block (corresponding to an epoch), one node may run an ACS and n rbcs+n ABAs, n being the number of consensus nodes, and where 1 RBC and ABA correspond to self-initiated consensus proposals and the other (n-1) RBCs and ABAs correspond to other (n-1) node-initiated consensus proposals. That is, for one epoch, one node initiates a consensus proposal and, at the same time, cooperates with completing the consensus proposal initiated by other nodes. Thus, for a node, at least (n-f) RBCs will be sent to the ACS after they have completed (indicated by the Ready message), and the ACS will initialize the corresponding ABA, and the corresponding ABA process will be started. After at least (n-f) consensus offers complete ABA, if the rest of the consensus offers have not completed RBC, an initial value of 0 is assigned, and the ABA procedure corresponding to the offer is performed. From a global perspective, at least (n-f) nodes will perform the same consensus process (at least (n-f) different nodes initiate the proposed process), and finally the ACS collects the ABA results of each proposal, sorts the ABA results into 1 proposals according to a certain rule, and outputs the results.

In the above procedure, in contrast to PBFT, a strong proposal is made for each node participating in consensus, i.e. the node participating in consensus needs to initiate a proposal in each epoch, whether or not this node really has a proposal. If the node does not actually propose, it is also necessary to initiate a proposal request whose contents are empty (the empty proposal request may be encrypted in RBC so that other nodes cannot determine the contents of the proposal to avoid malicious nodes from selectively assigning inputs or outputs in the BA process because they can see the contents of the proposal). Even if this node is a failed node, no proposal can be made, and then the ACS of the other node still leaves a place for the proposal corresponding to this node. Specifically, after each of the other nodes completes execution of at least the number of ABAs and is commonly known as 1 (1 indicates voting approval), if no number of Ready messages of the number of ABAs corresponding to the proposal of the node in the RBC stage have been received yet, the ACS needs to assign an ABA initial value corresponding to the proposal of the node to 0 (0 indicates voting disapproval), and then enters into the ABA process. Thus, other nodes also need to coordinate to complete the ABA process that this failed node corresponds to the proposal.

It can be seen that, in the conventional asynchronous consensus protocol represented by honeybadger bft, a block identifier is generally used to define a block to be consensus, and all consensus nodes initiate a proposed block construction mode together for a block corresponding to the block identifier.

With the adoption of the traditional block building mode, for any consensus node, the consensus process of the proposal of the consensus node for the block needs to wait for and cooperate with the completion of the consensus of the proposal of other consensus nodes for the block. Even for a consensus node without proposal, a consensus proposal with empty content needs to be proposed, which causes waste of a lot of resources (calculation power, bandwidth).

In order to cope with the problems that the conventional block building mode cannot quickly and efficiently complete the consensus process and output the consensus result, the block building mode of the asynchronous consensus protocol can be redesigned, the block to be consensus is not definitely identified by block identification, but the block to be consensus is definitely identified by a timestamp corresponding to the moment of initiating the consensus proposal.

In addition, instead of adopting a block organization mode that all the consensus nodes commonly initiate the proposal for the block corresponding to the block identifier, each consensus node independently initiates the proposal based on the timestamp for initiating the consensus proposal, the proposed transaction list of each consensus node is ordered according to the sequence of the timestamp only after the consensus is completed, and then the block to which the proposed transaction list of each consensus node belongs is determined according to the ordered sequence.

For example, the above-mentioned consensus protocol with redesigned block construction mode may be myturner consensus protocol, unlike HoneyBadgerBFT consensus protocol, myturner consensus protocol combines the two following rounds of RBC process and the two preceding rounds of ABA process of HoneyBadgerBFT consensus protocol, and can shorten to 3 rounds to complete one consensus under certain conditions, and the three rounds of interaction messages are Val message, ENDORSE message and Prom message, respectively. In the Val message, both the ENDORSE message and the Prom message do not carry the block number to be consensus, but carry the timestamp of initiating the consensus proposal. When the transaction lists proposed by all the consensus nodes pass through consensus in a period of time, the sequence of the time stamps of the consensus proposals is initiated by all the consensus nodes, the transaction lists proposed by all the consensus nodes are ordered, and the block to which the transaction list proposed by all the consensus nodes belongs is determined according to the ordered sequence.

By redesigning the conventional block construction mode to a block to be commonly recognized based on a time stamp, the proposal of each node can be singly blocked (generated block), and the common recognition results are ordered according to the time stamp, so that the relative position of the blocked is determined when the common recognition proposal is initiated under the condition that the block construction right is not lost.

In addition, for the failure node which cannot propose the consensus proposal, as long as the number of nodes which normally work reaches the number of Quorum, the process of generating the consensus result does not need to enter the ABA process after the ABA initial value (namely the ticket throwing value) corresponding to the proposal of the failure node is assigned to 0 as in the HoneyBadgerBFT, but can skip the failure node, does not need to wait for the failure node to initiate the consensus proposal, and does not need to cooperate with the failure node to complete the consensus, thereby greatly reducing the delay of the consensus.

In practical applications, no matter the consensus protocol for performing transaction proposal based on block identification represented by honeybadges bft or the consensus protocol for performing consensus proposal based on time stamp represented by mytuner, a pass mechanism for consensus proposal is generally introduced to improve the consensus efficiency.

By pass mechanism, it is meant that in a round of consensus, if there are already enough proposals for the target block that have been commonly passed, then the consensus nodes in the blockchain network no longer accept the proposals for the remaining nodes.

For example, taking the honeybadger bft algorithm as an example, in the ABA stage of the honeybadger bft algorithm, if it is determined that there are already Quorum proposals for the target block that have been commonly passed, then the vote (i.e., the ABA initial value) of the proposal for the remaining node may be forcefully assigned to 0 (indicating disapproval) and then enter a subsequent ABA stage to indicate that the proposal for the remaining node is no longer received.

As another example, taking the myturner algorithm as an example, in the myturner algorithm, for any consensus node, if a transaction list at a certain time t has been commonly passed, the consensus node may broadcast a PASS message carrying a timestamp corresponding to the time t, and if the PASS message itself has passed the time t, the transaction list proposed before the time t will not be accepted; for example, the pass message from the consensus node actually expresses a commitment that either votes 0 (indicating no approval) on itself for the list of transactions proposed before the time t, or no longer processes the list of transactions proposed before the time t. When each consensus node collects at least a number of quantum Pass messages (including Pass messages that are broadcast most recently by itself), the minimum value of the time stamps carried in these Pass messages can be calculated as the time stamp corresponding to the key time. Thus, the individual consensus nodes can confirm that at least the Quorum number of consensus nodes have passed the moment of truth, thereby agreeing on the moment of truth. Subsequently, the individual consensus node will no longer accept the list of transactions proposed by the other consensus nodes before the moment t. For example, the list of transactions proposed before the moment of truth t will vote for 0 (indicating no approval) by itself or will not be processed.

However, both honeybridge bft and myturnpler, although some node proposals for target blocks may be "suspended" by the pass mechanism described above, a common and persistent proposal for all nodes is still required to maintain algorithm activity (liveness).

For example, the HoneyBadgerBFT algorithm requires all nodes to participate in the construction of a block, and when at least the proposal of the Quorum nodes for the block is commonly passed, the remaining nodes currently need to propose an empty proposal (typically a transaction list) for the block even though there is no proposal for the transaction, and the vote (i.e., ABA initial value) of the proposal of each node for the remaining nodes is forced to be assigned 0 and then enters the subsequent ABA stage, so as to ensure that all nodes participate in the proposal for the block.

In the myturner algorithm, after each node needs to wait for receiving the quantum Pass messages, the timestamp corresponding to the key moment can be determined by calculating the minimum value of the timestamps carried in the quantum Pass messages, which means that once each node can not collect the quantum Pass messages all the time, the myturner algorithm is completely deactivated; this also means, therefore, that in the myturner algorithm, nodes that do not have a transaction need to be proposed are also typically required to propose a null proposal for that block.

It can be seen that, in order to keep the algorithm active, both honeybridge bft and myturnpler generally require nodes that do not need to be proposed for transactions, and propose an empty proposal, which causes a great deal of resource (computational effort, bandwidth) waste.

In view of this, the present specification proposes a new asynchronous consensus protocol design that can continue to drive the execution of the pass mechanism of the consensus proposal while still maintaining the activity of the consensus protocol in the event that a consensus node that does not have a trade need to propose is no longer required to propose a null proposal.

Referring to fig. 4, fig. 4 is a flowchart illustrating a method of consensus in a blockchain system, which may be applied to any target consensus node in the blockchain system, including the following implementation:

step 402: receiving a first message or a second message broadcast transmitted by a consensus node in the blockchain system; wherein the first message contains a list of transactions proposed by the consensus node; the second message is used for indicating that the consensus node sending the second message does not propose a transaction list in the round of consensus;

the consensus protocol presented in this specification also belongs to an asynchronous consensus algorithm. In an asynchronous consensus protocol, all consensus nodes participating in the consensus may be peer-to-peer in role, with no division of primary and backup nodes. For any one consensus node, not only can a consensus proposal be initiated, but also the consensus process of proposals initiated by other consensus nodes can be participated.

The asynchronous consensus protocol proposed in the present specification may specifically also include the following two types:

a first type of asynchronous consensus algorithm adopts block identification to definitely identify blocks to be consensus; for example, an asynchronous consensus algorithm represented by HBBFT may be used. The second type of asynchronous consensus algorithm adopts a timestamp corresponding to the moment of initiating the consensus proposal to determine two types of algorithms such as blocks to be consensus. For example, an asynchronous consensus algorithm represented by mytuner may be used.

For any one of the consensus nodes in the blockchain network, if a consensus proposal needs to be initiated, a first message may be sent by broadcasting to other consensus nodes in the blockchain system. Wherein the first message is specifically for initiating a consensus proposal. In the first message, a list of transactions proposed by the consensus node may be included.

In one embodiment shown, if the asynchronous consensus protocol proposed in the present specification is a consensus protocol for making a transaction proposal based on a block identification, the first message may contain a block identification of a target block to be consensus; and the consensus node proposing the list of transactions for the target block.

For example, the asynchronous consensus protocol proposed in the present specification may be a myturner consensus protocol (for example, may be called myturner-Seq protocol) that is modified from the original myturner consensus protocol that performs consensus proposal based on time stamp. Based on the modified myturner consensus protocol, the first message may be referred to as a PROPOSE message. In the PROPOSE message, a tile identifier (e.g., a tile number) of the target tile may be included, and a transaction list packaged by the consensus node, e.g., the transaction list may be labeled m ₀ ，m ₀ May include a set of transactions { tx } ₀₁ ，tx ₀₂ ，...，tx _0n }，tx _0n Represents m ₀ N transaction of the (c).

The format of the PROPOSE message can be expressed as < PROPOSE: sender, n, payload >; where sender is the node identification of the consensus node sending the PROPOSE message, n is the block identification (e.g., block number) of the block to be consensus, payload is the proposed content, and payload may contain a transaction list packaged by the consensus node.

In addition, the first message may also include a consensus node pair m that sends the first message ₀ For example, recorded as sig ₀₀ . In general, the consensus node can use its own private key pair m ₀ Direct signature to obtain sig ₀₀ May be that m is first to ₀ Performing hash calculation to obtain a hash value (namely a digest value), and then signing the hash value by using a private key of the hash value to obtain sig ₀₀ It is also possible to use the private key pair m of the self ₀ And ts ₀ The data being signed directly or m ₀ And ts ₀ Hash value of data thereinAnd signing.

In one embodiment shown, if the asynchronous consensus protocol proposed in the present specification is a consensus protocol that makes a consensus proposal based on a time stamp, the first message may contain a time stamp corresponding to the time when the consensus proposal was initiated; and, the list of transactions proposed by the consensus node.

For example, the asynchronous consensus protocol presented in this specification may be a mytuner consensus protocol that makes consensus proposals based on time stamps. Based on the mytuner consensus protocol, this first message may be referred to as a VAL message. In the VAL message, a timestamp corresponding to the moment of initiation of the consensus proposal may be included, and a transaction list packaged by the consensus node, e.g. the transaction list may also be marked m, in which a set { tx ] of a series of transactions may be included ₁ ，tx ₂ ，...，tx ₃ }，tx _n Representing the nth transaction in m.

The format of the VAL message may be expressed as < VAL: sender, T, payload >; where sender is the node identification of the consensus node sending the VAL message, T is the timestamp corresponding to the moment when the consensus is initiated, payload is the proposed content, and payload may contain the transaction list packaged by the consensus node.

In the present description, a second message may be introduced on the basis of the first message at the stage of the transaction proposal. Thus, at the stage of transaction proposal, in addition to proposing a self-packed transaction list by broadcasting a first message to other consensus nodes in the blockchain system, a second message can also be broadcast to other consensus nodes in the blockchain system without requiring a proposed transaction.

Wherein the second message is specifically used for stating that the transaction list is not proposed in the consensus of the round.

Note that, when the asynchronous consensus protocol is a consensus protocol for making a transaction proposal based on a block identifier or a consensus protocol for making a consensus proposal based on a time stamp, the content included in the second message may have a certain difference.

In one embodiment, if the asynchronous consensus protocol proposed in the present specification is a consensus protocol for making a transaction proposal based on a block identifier, the second message may include a block identifier of a target block to be consensus, and the consensus node for sending the second message may be configured to instruct a non-proposal transaction list for the target block corresponding to the block identifier;

for example, still taking the above asynchronous consensus protocol as the above, a modified mytuneler consensus protocol for performing a transaction proposal based on block identification, which is modified with respect to the original mytuneler consensus protocol for performing a consensus proposal based on time stamps, is taken as an example, and based on the modified mytuneler consensus protocol, the second message may be referred to as a SKIP message. In the SKIP message, a block identification (such as a block number) of the target block may be included.

The format of this SKIP message may be expressed as < SKIP: sender, n >; where sender is the node identification of the consensus node that sent the SKIP message and n is the block identification (e.g., block number) of the block to be consensus.

The second message may also include a signature of the consensus node that sent the second message.

In one embodiment shown, if the asynchronous consensus protocol proposed in the present specification is a consensus protocol that makes a consensus proposal based on a time stamp, the second message may contain a key time stamp for indicating that the consensus node sending the second message does not propose a transaction list at a time corresponding to the key time stamp.

For example, the asynchronous consensus protocol presented in this specification may be a mytuner consensus protocol that makes consensus proposals based on time stamps. Based on the mytuner consensus protocol, this second message may also be referred to as SKIP message. In this SKIP message, a key timestamp may be included.

The format of this SKIP message may be expressed as < SKIP: sender, t >; where sender is the node identity of the consensus node that sent the SKIP message and t is the key timestamp.

The key time stamp refers to a time stamp corresponding to a time when the consensus node confirms that the proposed transaction is not required.

For example, for an honest node, the key timestamp may be specifically a timestamp corresponding to a time when the honest node determines that all transactions in the local transaction pool have commonly known the uplink. For a malicious node, the key timestamp may be a specified timestamp that the malicious node is malicious; in this case, the malicious node would maliciously claim that at the time corresponding to the timestamp, there is no transaction itself that needs to be proposed (in fact there may be a transaction in the pool at that time that has not yet initiated a consensus).

In the above asynchronous consensus protocol, the consensus node may be configured to broadcast a transmission opportunity to transmit the second message to other consensus nodes, and to transmit the second message to the other consensus nodes when it is determined that there is no transaction to be proposed in the local transaction pool.

In this case, the consensus node in the blockchain system may determine whether there is a transaction to be proposed in the local transaction pool; for example, in practice, the consensus node may periodically determine whether there is a transaction to be proposed in the local transaction pool based on a certain period (e.g., may be a block period). If it is determined that there are no more transactions in the local pool to be proposed, such as the transactions in the local pool have all been commonly known to be uplink, the node may broadcast a second message to the other nodes to declare that no proposed transactions are required.

Of course, this provision may not be followed for a malicious node, but the second message is also broadcast to other consensus nodes in case it is determined that there is still a transaction to be proposed in the local transaction pool. For example, a malicious node may send both a first message to propose a transaction list and a second message to declare that no proposed transaction list is required by itself.

In the illustrated embodiment, the second message may also be specifically a first message broadcast by a consensus node in the blockchain system, upon receipt of the other consensus node, and broadcast to the other consensus node upon determining that there is no transaction to be proposed in its local transaction pool.

In this case, the consensus node in the blockchain system may determine whether the local transaction pool has a transaction to be proposed after receiving the first message broadcast by the other consensus node; if there is no transaction to be proposed in the local transaction pool, a second message is broadcast to other consensus nodes to declare that no transaction itself needs to be proposed.

For example, taking the asynchronous consensus protocol proposed in the present specification as a consensus protocol for consensus proposal based on a time stamp, after receiving a first message containing a time stamp t broadcasted by other consensus nodes, the consensus node may, if it is determined that there is no transaction to be proposed in the local transaction pool, continue to broadcast a second message to other consensus nodes to declare that the consensus node does not need a proposed transaction at the current time.

It should be noted that, if the transmission delay between the consensus node that transmits the first message and the consensus node that receives the first message is ignored, the consensus node that receives the first message may use the timestamp t included in the first message as the key timestamp included in the second message to be transmitted.

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 large and cannot be ignored, the consensus node that receives the first message may also use the local timestamp corresponding to the time when it is determined that the transaction to be proposed does not exist in the local transaction pool as the key timestamp included in the second message to be sent.

In one embodiment shown, the second message may carry a signature, as previously described. For any consensus node, if a second message broadcast by other consensus nodes in the blockchain system is received, the signature of the second message can be verified; if the signature verification of the second message is passed, the second message can be further broadcast and sent to other consensus nodes in the blockchain system, so that the second message received by the second message can be further spread to other consensus nodes.

In this way, the second message received by the consensus node can be fully diffused to other consensus nodes, and the malicious node can be prevented from continuing to broadcast and send the second message to other consensus nodes after receiving the second message sent by other consensus nodes.

Step 404, determining whether the number of consensus nodes meeting a preset condition in the blockchain system reaches a preset threshold; wherein the preset condition comprises that the transaction list proposed by the consensus node is consensus-passed; or the second message sent by the consensus node is received;

the asynchronous consensus protocol proposed in the present specification may specifically also introduce the pass mechanism mentioned above to improve the consensus efficiency. That is, in a round of consensus, if enough proposals have been passed through the consensus, then the consensus nodes in the blockchain network no longer accept the proposals of the remaining nodes. The consensus node receiving the first message can verify the correctness of the received first message; for example, a public key that sent the first message may be used to verify a signature in the first message. If the signature passes verification, it may be determined that the received first message is the correct message. When the consensus node receiving the first message completes verification for the first message and confirms that the received first message is a correct message, it can further determine whether the pass mechanism meets the triggering condition.

In practical applications, the triggering condition of the pass mechanism (i.e., the preset condition in step 404) may be that in a round of consensus, it is generally known whether the number of proposals passed through has reached a threshold. That is, the pass mechanism is typically driven by the event that "the number of proposals that have been passed through in a round of consensus reaches a threshold". Wherein, in different asynchronous consensus protocols, the value of the threshold value can have a certain difference.

For example, taking the HoneyBadgerBFT algorithm as an example, the threshold mentioned above is generally referred to as qurum based on the HoneyBadgerBFT algorithm. In the ABA stage of the honeybadger bft algorithm, if it is determined that there have been quantium proposals for the target block that have been commonly passed, a vote (i.e., ABA initial value) of the proposal for the remaining nodes may be forced to a value of 0 (indicating disapproval) and then entered into a subsequent ABA stage to indicate that the proposal for the remaining nodes is no longer received.

As another example, taking the mytuner algorithm as an example, the threshold mentioned above based on the mytuner algorithm generally refers to a configurable threshold S. In the mytuner algorithm, for any consensus node, S (the value of S is typically a configurable threshold) in the acknowledgment blockchain system is different from the consensus node, and the proposal before the moment corresponding to the key timestamp has passed through, a PASS message carrying the key timestamp may be broadcast to declare that the proposals of other consensus nodes than the S consensus nodes are no longer accepted before the key timestamp.

In this specification, since there is no consensus node that a transaction needs to propose, in the proposal phase of the asynchronous consensus protocol, there may be no longer a need to propose an empty proposal; therefore, in order to avoid that the consensus node does not propose a null proposal any more, the activity of the asynchronous consensus protocol is affected, and the triggering condition of the pass mechanism introduced in the asynchronous consensus protocol can be expanded. That is, the events driving the pass mechanism described above are extended.

In a round of consensus, the trigger conditions of the pass mechanism after expansion can be:

the number of consensus nodes through which the proposed transaction list has been consensus passed reaches a preset threshold; or the number of consensus nodes that have received the second message they send reaches a preset threshold.

That is, in a round of consensus, in addition to "whether the number of consensus nodes through which the proposed transaction list has been commonly known reaches the preset threshold" may be used as the trigger condition of the pass mechanism, "whether the number of consensus nodes that have received the second message sent by the same reaches the preset threshold" may also be used as the trigger condition of the pass mechanism. In other words, in addition to being driven by the event of "whether the number of consensus nodes through which the proposed transaction list has been consensus passed reaches the preset threshold", it is driven by the event of "whether the number of consensus nodes that have received the above-described second message that they have transmitted reaches the preset threshold".

It should be noted that, when the asynchronous consensus protocol proposed in the present specification is a consensus protocol for making a transaction proposal based on a block identifier and a consensus protocol for making a consensus proposal based on a timestamp, there may be a certain difference in trigger conditions of the pass mechanism after expansion.

For example, in one embodiment shown, if the asynchronous consensus protocol proposed in the present specification is a consensus protocol for making a transaction proposal based on block identification, the triggering condition of the pass mechanism after expansion may be:

the number of consensus nodes through which the transaction list proposed for the target block to be consensus passes reaches a preset threshold; or the number of consensus nodes which have received the second message sent by the consensus nodes and containing the block identifier of the target block reaches a preset threshold.

In another embodiment shown, if the asynchronous consensus protocol proposed in the present specification is a consensus protocol for consensus proposal based on a timestamp, the triggering condition of the pass mechanism after expansion may be:

the number of consensus nodes through which the proposed transaction list has been consensus-passed at any time after the time of initiating the consensus proposal reaches a preset threshold; or the second message sent by the user is received, and the key time stamp contained in the second message is a time stamp corresponding to any time after the time of initiating the consensus proposal.

It is easy to understand from the above description that the trigger condition of the pass mechanism after expansion is added with a trigger condition based on the existing trigger condition, which is equivalent to relaxing the trigger condition of the pass mechanism. In a round of consensus, even if no consensus node needs to be proposed is transacted, in the proposal stage of the asynchronous consensus protocol, the proposal of the proposal is no longer needed to be proposed, and the trigger execution of the pass mechanism can still be driven through the event of whether the number of the consensus nodes which have received the second message sent by the consensus node reaches a preset threshold value, so that the activity of the consensus protocol can still be maintained.

For example, in a normal case, if there is no consensus node that needs to be proposed for a transaction, in the proposal phase of the asynchronous consensus protocol, it is no longer necessary to propose an empty proposal, which may result in that in a round of consensus, the number of consensus nodes through which the proposed transaction list has passed in consensus cannot always reach a preset threshold, so that the consensus protocol cannot always trigger the execution of the pass mechanism, resulting in inactivity of the consensus protocol. Based on the trigger condition of the pass mechanism after expansion, even if there is no consensus node to be proposed in the transaction, no empty proposal is required to be proposed in the proposal stage of the asynchronous consensus protocol, the trigger execution of the pass mechanism can be driven continuously by judging whether the number of the consensus nodes which have received the second message sent by the consensus node reaches a preset threshold. Obviously, based on the trigger condition of the pass mechanism after expansion, the activity of the consensus protocol can still be maintained under the condition that the consensus node which does not need to be proposed by the transaction is allowed to no longer need to propose an empty proposal.

It is emphasized that the above-mentioned second message broadcast by the consensus node is not functionally equivalent to a null proposal proposed by the consensus node. The second message itself is only used to state that the consensus node does not need the proposed transaction list in the consensus of the round and to drive the trigger execution of the pass mechanism, and the second message does not participate in the consensus process of the consensus protocol itself.

In the present specification, when determining whether the pass mechanism has met a triggering condition, the number of consensus nodes meeting a preset condition in the current round of consensus may be specifically obtained by the consensus node receiving the first message; the preset condition corresponds to the triggering condition, and specifically may include 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. That is, for a consensus node, the proposed transaction list passes through, or the consensus node receives the second message sent by the consensus node, the consensus node can be considered to meet the preset condition.

Correspondingly, the number of the consensus nodes meeting the preset condition in the consensus of the round, which is obtained by the consensus node receiving the first message, can be specifically included in the first number of the consensus nodes through which the proposed transaction list passes in the consensus of the round, or the second number of the consensus nodes which have received the second message sent by the consensus node in the consensus of the round.

Then, the consensus node receiving the first message may determine whether the obtained first number or the second number reaches a preset threshold, so as to determine whether the pass mechanism meets the triggering condition. At this time, as long as any one of the first number and the second number reaches the preset threshold, the pass mechanism can be considered to have satisfied a trigger condition; otherwise, if the first number and the second number do not reach the preset threshold, the pass mechanism may not meet the trigger condition.

Wherein, when obtaining the first number of consensus nodes through which the proposed transaction list has been commonly recognized in the consensus of the round, the method can be implemented by counting the number of the consensus nodes through which the proposed transaction list has been output (i.e. the consensus is passed) as a result of the consensus in the blockchain system.

For example, in practical applications, each consensus node that receives the first message may typically create a consensus instance locally corresponding to the transaction list included in the first message. The consensus example specifically refers to an algorithm example for performing consensus processing on a transaction list proposed by a certain consensus node based on a consensus algorithm disclosed in the specification. Each consensus node may initiate a consensus process for the list of transactions contained in the first message by running the consensus instance locally. In addition, when counting the number of consensus nodes that have outputted as a consensus result in the proposed transaction list in the blockchain system, the number of consensus instances that have obtained an execution result may be counted, in particular, among locally created consensus instances corresponding to the transaction list proposed by other respective consensus nodes for the target block.

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

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

Step 406: if the number of the consensus nodes meeting the preset conditions in the blockchain system does not reach a preset threshold, performing consensus processing on a transaction list proposed in the received round of consensus; if the number of the consensus nodes meeting the preset condition in the block chain system reaches the preset threshold, broadcasting a third message to other consensus nodes; wherein the third message is used for declaring a transaction list proposed by other consensus nodes than the consensus node that no longer accepts the preset condition.

In this specification, when the consensus node that receives the first message determines that either the first number or the second number reaches the preset threshold, the pass mechanism may be considered to satisfy the trigger condition, and the consensus node may broadcast a third message to other consensus nodes.

Wherein the third message is specifically used for declaring that the transaction list proposed by other consensus nodes except the consensus node meeting the preset condition is no longer accepted.

Note that, when the asynchronous consensus protocol is a consensus protocol for making a transaction proposal based on a block identifier or a consensus protocol for making a consensus proposal based on a time stamp, the content included in the third message may have a certain difference.

In one embodiment, if the asynchronous consensus protocol proposed in the present specification is a consensus protocol for making a transaction proposal based on a block identifier, the third message may include a block identifier of a target block to be consensus for declaring that a transaction list proposed by other consensus nodes than the consensus node meeting the preset condition is no longer processed for the target block; or outputting the consensus result of the transaction list proposed by other consensus nodes for the target block except the consensus node meeting the preset condition as a consensus failure.

For example, still taking the above asynchronous consensus protocol as the above, a modified mytuneler consensus protocol for performing a transaction proposal based on block identification, which is modified with respect to the original mytuneler consensus protocol for performing a consensus proposal based on a timestamp, is taken as an example, and based on the modified mytuneler consensus protocol, the third message may be referred to as a pass message. In the pass message, a block identification (e.g., block number) of the target block may be included.

The format of the PASS message may be expressed as < PASS: sender, n, EB >; wherein sender is the node identification of the consensus node that sent the PASS message; n is a block identification (e.g., block number) of the block to be identified; EB represents a list of transactions proposed by the consensus node meeting a preset condition for the target block, which are voted for by the consensus node sending the PASS message; for example, it may be that the consensus node that sent the PASS message votes for a list of transactions proposed for the target block after the last time the PASS message was sent.

The third message may also include a signature of the consensus node that sent the third message.

In one embodiment shown, if the asynchronous consensus protocol proposed in the present specification is a consensus protocol that makes a consensus proposal based on a timestamp, the third message may include a timestamp (i.e. a timestamp carried in the first message) corresponding to the time when the consensus proposal was initiated, for declaring that the list of transactions proposed by other consensus nodes than the consensus node meeting the above-mentioned preset condition is no longer processed before the time corresponding to the timestamp; or outputting the consensus result of the transaction list proposed by other consensus nodes except the consensus node meeting the preset condition before the moment corresponding to the time stamp as the consensus failure.

For example, the asynchronous consensus protocol presented in this specification may be a mytuner consensus protocol that makes consensus proposals based on time stamps. Based on the mytuner consensus protocol, this third message may also be referred to as PASS message. The PASS message may include a timestamp corresponding to the time of initiation of the consensus proposal carried in the first message.

The format of the PASS message may be expressed as < PASS: sender, T, EB >; wherein sender is the node identification of the consensus node that sent the PASS message; t is the timestamp corresponding to the moment when the consensus originated (i.e. the timestamp contained in the received first message); EB represents a list of transactions proposed by the consensus node meeting a preset condition for the target block, which are voted for by the consensus node sending the PASS message; for example, it may be that the consensus node that sent the PASS message votes for a list of transactions proposed for the target block after the last time the PASS message was sent.

In one embodiment shown, the consensus node that receives the first message may broadcast a second message to the other consensus nodes that includes a vote indicating a non-approval of the transaction list included in the received first message in addition to a third message to the other consensus nodes after determining that the pass mechanism meets the trigger condition.

In this way, when a first message sent by a certain consensus node is received, if the pass mechanism is determined to meet the trigger condition, the transaction list proposed for the target block contained in the first message is not accepted, and the transaction list vote proposed for the target block contained in the first message is not approved, so that the consensus process can be accelerated.

In one embodiment shown, for any of the consensus nodes, the third message broadcast by the other consensus nodes may be received in addition to the third message broadcast to the other consensus nodes.

Any consensus node, after collecting at least a number of third messages from different consensus nodes, may obtain a transaction list (i.e., EB in PASS message mentioned above) proposed for the target block contained in the collected at least a number of third messages from different consensus nodes; for example, the transaction lists included in the third message from the different consensus nodes of at least Quorum may be combined to generate a larger transaction list; then, the list of transactions proposed for the target block that are not contained in the at least a third message of Quorum may no longer be processed; or outputting the consensus result of the transaction list proposed for the target block, which is not included in the at least the third message, as a consensus failure. For example, the executing result of the locally created consensus instance corresponding to the transaction list not included in the at least quaternary third messages is directly output as a consensus failure (for example, output is 0).

In this specification, when it is determined that either the first number or the second number of the first message received does not reach the preset threshold, the consensus node may consider that the pass mechanism is not triggered, where the consensus node may locally create a consensus instance corresponding to the transaction list included in the first message, locally run the consensus instance, and initiate a consensus process for the transaction list included in the first message.

It should be noted that, the process of consensus performed on the transaction list included in the first message generally depends on the specific type of consensus protocol adopted by the blockchain system, and there is also a certain difference in the process of consensus between different types of consensus protocols on the transaction list.

The detailed process of consensus on the transaction list is described in detail below by way of a specific example.

In this embodiment, the consensus protocol adopted by the blockchain system may be a mytuner consensus protocol (for example, may be called mytuner-Seq protocol) that is modified from the original mytuner consensus protocol that performs a consensus proposal based on a timestamp to perform a transaction proposal based on a blockid.

Based on the myturnpleseq protocol, the first message may be referred to as a pro message.

For example, in Node ₀ From the perspective of initiating the consensus proposal, the interaction process may be as shown in fig. 5. Node ₀ Can be directed to Node ₁ 、Node ₂ And Node ₃ The broadcast transmits a PROPOSE to initiate consensus proposals for the target blocks. Wherein, in the PROPOSE message, the block identification (such as the block number) of the target block can be included, and the Node ₀ A packaged list of transactions, such as the list of transactions may be labeled m ₀ ，m ₀ May include a set of transactions { tx } ₀₁ ，tx ₀₂ ，...，tx _0n }，tx _0n Represents m ₀ N transaction of the (c).

The consensus node receiving the first message may perform at least two rounds of message interaction in the process of executing the created consensus instance and initiating consensus on the transaction list in the first message, where each round of consensus voting includes:

in a first round of message interaction, the consensus node that received the first message may broadcast a fourth message to other consensus nodes.

The fourth message is specifically configured to perform consensus voting for a transaction list included in the first message. In the fourth message, the consensus node sending the fourth message may be included to vote for a list of transactions contained in the first message. Of course, the fourth message may also include the block identifier of the target block to be identified.

For example, please continue to refer to fig. 5, in the first round of message interaction, node ₁ 、Node ₂ 、Node ₃ After receiving the post message (i.e., the first message) broadcast by the Node, each may broadcast a fourth message to the other consensus nodes, respectively. Wherein the fourth message may be referred to as an ENDORSE message. In the ENDORSE message, a Node pair can be included ₀ Voting of the transaction list for the target block proposal.

In one embodiment shown, the format of the ENDORSE message may be expressed as < ENDORSE: sender, n, b >; where sender is the node identification of the consensus node that sent the proposal for block n (i.e., the node identification of the consensus node that sent the aforementioned PROPOSE message), n is the block identification of the block to be consensus (e.g., the block number), and b is the voting content of the transaction list that the consensus node that sent the ENDORSE message proposed to block n for that sender (i.e., the transaction list contained in the aforementioned PROPOSE message that was received).

In practical applications, in the process of consensus of the transaction list included in the process of the process message, multiple rounds of voting may be generally required to complete the consensus of multiple rounds, so that the format of the ENDORSE message may also include rounds of consensus of the transaction list. This round may generally be used to represent a round of consensus voting on the same transaction list. For example, in this case, the format of the ENDORSE message may be expressed as < ENDORSE: sender, n, b, r >; where r represents the round of consensus voting for the transaction list proposed by sender to block n, the meaning of the other parameters in the format of the ENDORSE is the same as in the previously mentioned process message, and will not be described again.

In one embodiment shown, the voting content contained in the ENDORSE message may be, in particular, a voting value for a list of proposed transactions. The voting values may generally include a first preset value that indicates approval of the transaction list and a second preset value that does not approve the transaction list. For example, approval of the transaction list may be indicated by 1 and disapproval of the transaction list may be indicated by 0.

In practical applications, in order to distinguish the first round of consensus votes from the other rounds of consensus votes, the voting value that approves the transaction list may be represented by the summary value (such as a hash value) of the transaction list, and the voting value that does not approve the transaction list may be represented by the second preset value. While in the consensus votes for the other rounds of consensus of the transaction list, the first preset value may still be employed to represent approval of the transaction list; and using the second preset value to indicate that the transaction list is not approved.

For example, if r=0 is used to represent the first round of consensus for the transaction list, then the format of the ENDORSE messages interacted between the consensus nodes during the first round of consensus may be expressed as < ENDORSE: sender, n, h/0, r=0 >; where h represents the digest value of the transaction list. h/0 means that the vote value for the above transaction list contained in the ENDORSE message is h or 0. While the format of the ENDORSE messages interacted between the consensus nodes at other rounds of consensus for the transaction list may be expressed as < ENDORSE: sender, n,0/1, r >.0/1 means that the vote value for the above transaction list contained in the ENDORSE message is 1 or 0.

It should be noted that, in the first round of message interaction, node ₀ May not participate in broadcasting the fourth message, but only by Node ₁ 、Node ₂ 、Node ₃ The fourth messages are broadcast to other consensus nodes, respectively. This is because of Node ₀ Initiating a consensus proposal in a first round, which itself may represent a Node ₀ The list of transactions contained in the first message is approved.

It is also emphasized that in the first round of message interaction the consensus node may change its voting result and vote again, i.e. issue a number of ENDORSE messages containing different voting contents. For example Node ₁ An ENDORSE message whose content is the hash value of the transaction list may be sent for the first time to indicate approval of the transaction list in the consensus proposal, and then an ENDORSE message whose content is 0 may be sent again to indicate approval of the consensus proposalDisapproval of the transaction list in (a). For another example, node ₂ An ENDORSE message with a content of 0 may be sent for the first time to indicate disapproval of the transaction list in the consensus proposal, and then an ENDORSE message with a content of hash value of the transaction list may be sent again to indicate approval of the transaction list in the consensus proposal.

In addition, a signature to the transaction list may be included in the fourth message.

As previously described, in a first round of message interaction, the consensus node that received the first message may vote for the list of transactions for the target block proposal contained in the first message by continuing to broadcast a fourth message to other consensus nodes. In the second round of message interaction, the consensus node that receives the fourth message may collect votes from different consensus nodes for the transaction list contained in the first message.

For example, in one example, in a second round of message interaction, each consensus node that receives an ENDORSE message may collect ENDORSE messages from different consensus nodes that contain the same round r and contain the same sender and n, and then further obtain votes contained in the collected ENDORSE messages.

In a second round of message interaction, for any consensus node that receives the fourth message, if it collects at least a number of Quorum votes from different consensus nodes that represent approval of the transaction list, and does not itself broadcast a different vote for the transaction list, it may continue to broadcast the fifth message to other consensus nodes.

The specific number of Quort corresponds to, among other things, typically depends on the total number of consensus nodes in the blockchain network. For example, if the total node number n of consensus nodes in the blockchain network is 3f+1, f represents the number of fault-tolerant nodes supported by the consensus protocol employed by the blockchain system; the corresponding number of quium may be 2f+1.

The fifth message is specifically configured to promise not to change the vote for the transaction list, that is, the consensus node broadcasting the fifth message will not change the voting result of itself in the subsequent rounds of voting, and still maintain the same voting content as the first round of voting.

Since the fifth message is sent in case at least a number of votes from different consensus nodes indicating approval of the transaction list are collected, votes indicating approval of the transaction list may also be included in the fifth message. In the next round of voting, the consensus node that sent the fifth message needs to keep its voting result as a recognition of the transaction list.

For example, please continue to refer to fig. 5, in the second round of message interaction, node ₁ 、Node ₂ 、Node ₃ After broadcasting the ENDORSE message to other consensus nodes, node ₀ 、Node ₁ 、Node ₂ 、Node ₃ The collection of the voting content for the transaction contained in the ENDORSE message sent by the other consensus node may begin, and in the event that at least a number of votes from different consensus nodes are collected indicating approval of the transaction list, and that no different votes have been broadcast for the transaction list by itself, the broadcast of the fifth message to the other consensus nodes continues. Wherein the fifth message may be referred to as a PROM message. In the PROM message, a message indicating approval by Node ₀ Voting of proposed transaction lists.

In one embodiment shown, the format of the PROM message may be expressed as < PROM: sender, n, b, r >; where b represents the voting value that recognizes the transaction list, and the meaning of other parameters in the format of the PROM message is the same as the meaning of the aforementioned ENDORSE message and pro message, and will not be described again.

In addition, the fifth message may also include a signature on the transaction list, which is not described in detail.

In one embodiment shown, in a second round of message interaction, for any consensus node that receives the second message, if it collects at least a Quorum of votes from different consensus nodes indicating approval of the transaction list, and broadcasts a different vote for the transaction list itself, it may continue to broadcast a sixth message to other consensus nodes.

The sixth message has no function of promiseing to change the vote for the transaction list with respect to the fifth message, that is, the consensus node broadcasting the sixth message may change its voting result in the subsequent rounds of voting. For example, in a first round of voting, the voting result is 1, which represents a list of approved transactions, and in the next round of voting, the voting result may be changed to 0, which represents a list of non-approved transactions.

Since the sixth message is sent in case at least a number of votes from different consensus nodes indicating approval of the transaction list are collected, votes indicating approval of the transaction list may also be included in the sixth message. In the next round of voting, the consensus node that sent the sixth message may change the voting result to approve the transaction list.

For example, please continue to refer to fig. 5, in the second round of message interaction, node ₁ 、Node ₂ 、Node ₃ After broadcasting the ENDORSE message to other consensus nodes, node ₀ 、Node ₁ 、Node ₂ 、Node ₃ The collection of the voting contents of the transaction list contained in the ENDORSE message sent by the other consensus node may be started, and the broadcast of the sixth message to the other consensus nodes may be continued in case at least a number of votes from different consensus nodes indicating approval of the transaction list are collected and different votes have been broadcast for the transaction list itself. Wherein the sixth message may be referred to as a COMMIT message. In the COMMIT message, a message indicating approval by Node ₀ Voting of proposed transaction lists.

In one embodiment shown, the format of the COMMIT message may be expressed as < PROM: sender, n, b, r >; where b represents a voting value that recognizes the transaction list, and the meaning of other parameters in the format of the COMMIT message is the same as those in the aforementioned ENDORSE message and pro message, and will not be described again.

In addition, the sixth message may also include a signature on the transaction list, which is not described in detail.

It is emphasized that each of at least the number of Quorum consensus nodes in the blockchain network may perform the two rounds of message interaction mentioned above, consensus the list of transactions proposed by the other consensus nodes.

For example, the embodiment of FIG. 5 is a Node ₀ A consensus interaction process of consensus proposed perspectives is initiated. Wherein the Node in FIG. 5 ₁ 、Node ₂ And Node ₃ The consensus interaction procedure of initiating a viewing angle of the consensus proposal may be seen in fig. 6, 7, 8, respectively. 5-8, the process of consensus for a target block in the blockchain network from an overall perspective may be an overlay of FIGS. 5-8.

Each consensus node locally runs a consensus instance corresponding to a transaction list proposed by a certain consensus node, and in the process of consensus the transaction list proposed by the consensus node, after the second round of message interaction mentioned above is executed and the fifth message and the sixth message are broadcast and sent to other consensus nodes, the fifth message or the fifth message broadcast and sent by other consensus nodes can be collected;

For example, in one example, the PROM message or the COMMIT message may also be collected from different consensus nodes with the same included round r and the same included sender and n after the PROM message or the COMMIT message is broadcast to other consensus nodes.

Then, it may be determined whether each node agrees with the consensus vote of the transaction list based on the collected fifth message or the sixth message.

If any of the consensus nodes collects at least a number of Quorum's fifth messages from different consensus nodes including a vote indicating approval of the transaction list, then it may be determined that the vote approves the transaction list in the blockchain network and the consensus node promised to no longer alter the voting result reaches the number of Quorum's, the transaction list may be output as at least a portion of the consensus result for the target block corresponding to the block identification. The transaction list output at this time is the execution result of the consensus instance.

By the method, the consensus process can be shortened to 2 rounds to finish one consensus on the premise, and the triggering of binary consensus in the consensus process is avoided.

In one embodiment shown, if any of the consensus nodes collects at least a number of messages from different consensus nodes, but the collected messages include the sixth message in addition to the fifth message, then it may be determined that the voting in the blockchain network approves the transaction list, and the consensus node promised to no longer alter the voting result does not reach a number of Quorum, in which case a binary consensus protocol may be run to binary consensus the set of votes included in the collected at least number of Quorum messages. For example, a common binary consensus protocol such as may be a common coin tossing algorithm.

Note that, for a consensus node that collects at least a number of messages from different consensus nodes, the vote values in the fifth message and the sixth message included in the collected at least number of messages may be the same or different.

That is, for the consensus node, whether the voting values in the fifth message and the sixth message contained in the at least quum message received by the consensus node are the same or not, the binary consensus protocol can be triggered to run, so as to perform binary consensus on the voting sets contained in the at least quum messages.

In one embodiment, if it is determined that a binary consensus protocol needs to be run for a certain consensus instance, a round of message interaction can be added on the basis of the above-mentioned two rounds of message interaction.

In this case, if any consensus node collects at least a number of messages from different consensus nodes, but the collected messages include the sixth message in addition to the fifth message, then the seventh message may continue to be broadcast to other consensus nodes.

The seventh message is specifically configured to diffuse the voting set included in at least the Quorum messages collected by each consensus node to other consensus nodes. A collected set of votes contained in the at least quum messages may be included in the seventh message.

For example, the seventh message may be referred to as a CON message. In one embodiment shown, the format of the COMMIT message may be expressed as < CON: sender, n, br, r >; where br represents the set of votes contained in the collected at least number of quium messages, the meaning of the other parameters in the format of the CON message is the same as in the previously mentioned ENDORSE messages and pro messages, and will not be described in detail.

After each consensus node broadcasts and sends the seventh message to other consensus nodes, the seventh message broadcasted and sent by other consensus nodes can be collected, after collecting at least the seventh messages from different consensus nodes, the union of voting sets contained in the at least the seventh messages can be calculated to obtain a target voting set, and then a binary consensus protocol is operated to perform binary consensus on the target voting set.

In the illustrated embodiment, if the votes indicating approval of the transaction list in the vote set are agreed upon by the binary consensus, the transaction list may be output as at least a partial consensus result of the target block corresponding to the block identifier. The transaction list output at this time is the execution result of the consensus instance.

In contrast, if the binary consensus is passed, the votes in the voting set indicating approval of the transaction list are not agreed, at this time, the above-mentioned first round and second round of message interaction may be re-executed, and the consensus voting of the next round is executed for the transaction list corresponding to the consensus instance until the execution result of the relevant consensus instance is obtained.

The specific type of the binary consensus protocol adopted by the consensus node is not limited in the present specification; for example, a public coin-tossing algorithm may be used. The calculation process of binary consensus for the voting set based on the common coin-throwing algorithm generally depends on the technology adopted when the common coin-throwing algorithm is implemented in practical application, and is not described in detail in the specification, and a person skilled in the art can refer to the description in the related technology; for example, the public coin algorithm may be a public coin algorithm implemented based on a threshold signature technique.

In this specification, for any consensus node, when each consensus node completes the above-described consensus process for the transaction list proposed by the target block, the consensus node may further acquire the transaction list proposed by each consensus node for the target block as a result of the consensus, and aggregate the acquired transaction list into a transaction set for constructing the target block. The transactions in the set of transactions may then be ordered, and a target block may be constructed based on the ordered set of transactions.

The ordering method used in ordering the transactions in the transaction set is not particularly limited in the present specification;

for example, in one embodiment shown, the hash values of the transactions in the set of transactions may be calculated separately and the transactions in the set of target transactions may be ordered based on the hash values;

in this manner of ordering, transactions may be ordered based on the content of the transactions.

In another embodiment, the hash value may be calculated after data combination of the transaction set and the transaction set, respectively; i.e. each transaction is combined with the transaction set as a whole to calculate a hash value, and then the transactions in the transaction set are ordered based on the calculated hash value.

If the former transaction content-based hash is adopted to sort the transactions, for the transaction sender, intervention can be performed on the hash value calculated based on the transaction content by adjusting the transaction content so as to find a smaller hash value, thereby competing for a more front-sorted position in the target block for the transaction to be preferentially executed.

If the latter mode of respectively carrying out data combination on the transactions of the transaction set and then calculating a hash value and sequencing the transactions in the transaction set based on the hash value is adopted, the transaction sender cannot predict the content of the whole transaction set, so that the finally calculated hash value cannot be interfered, and the situation that the transaction is preferentially executed by competing a front sequencing position in a target block for a pen transaction through adjusting the transaction content is fundamentally avoided.

In the above technical solution, during the transaction proposal phase of the consensus protocol, the consensus node is allowed to broadcast and send a second message to other consensus nodes to declare that no proposal is required for the own transaction in the round of consensus, so that the consensus nodes which do not need to be proposed for the transaction can no longer need to propose empty proposals during the transaction proposal phase, thereby avoiding the waste of resources such as calculation power, bandwidth and the like.

Moreover, since the number of consensus nodes which have received the second message sent by the consensus nodes in a round of consensus will also be used as a trigger condition for the pass mechanism of the consensus protocol, in this way, the pass mechanism for the consensus proposal can be still pushed continuously by those consensus nodes which do not need to be proposed for a transaction without the need to propose an empty proposal, without affecting the activity of the consensus protocol.

For example, in a normal case, if there is no consensus node that needs to be proposed for a transaction, in the proposal phase of the asynchronous consensus protocol, it is no longer necessary to propose an empty proposal, which may result in that in a round of consensus, the number of consensus nodes through which the proposed transaction list has passed in consensus cannot always reach a preset threshold, so that the consensus protocol cannot always trigger the execution of the pass mechanism, resulting in inactivity of the consensus protocol.

Based on the trigger condition of the above-mentioned extended pass mechanism, even if there is no consensus node that needs to be proposed for a transaction, no empty proposal needs to be proposed in the proposal stage of the asynchronous consensus protocol, the trigger execution of the above-mentioned pass mechanism can be driven continuously by judging whether the number of consensus nodes that have received the above-mentioned second message sent by the above-mentioned node reaches a preset threshold. Obviously, based on the triggering condition of the above-mentioned pass mechanism after extension, the activity of the consensus protocol can still be maintained under the condition that the consensus node which is not allowed to trade and needs to propose is not required to propose an empty proposal any more.

The present application also provides a blockchain system embodiment, comprising:

In the 90 s of the 20 th century, improvements to one technology could clearly be distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable Gate Array, FPGA)) is an integrated circuit whose logic function is determined by the programming of the device by a user. A designer programs to "integrate" a digital system onto a PLD without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented with "logic compiler" software, which is similar to the software compiler used in program development and writing, and the original code before the compiling is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but not just one, but a plurality of kinds, 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, RHDL (Ruby Hardware Description Language), etc., VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog are most commonly used at present. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, 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 (Application Specific Integrated Circuit, ASIC), programmable logic controllers, and embedded microcontrollers, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller in a pure computer readable program code, it is well possible to implement the same functionality by logically programming the method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Such a controller may thus be regarded as a kind of hardware component, and means for performing various functions included therein may also be regarded as structures within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.

The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation device is a server system. Of course, this specification does not exclude that as future computer technology advances, the computer implementing the functions of the above-described embodiments may be, for example, a personal computer, a laptop computer, a car-mounted human-computer interaction device, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

Although one or more embodiments of the present description provide method operational steps as 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 recited in the embodiments is merely one way of performing the order of steps and does not represent a unique order of execution. When implemented in an actual device or end product, the instructions may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even in a distributed data processing environment) as illustrated by the embodiments or by the figures. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, it is not excluded that additional identical or equivalent elements may be present in a process, method, article, or apparatus that comprises a described element. For example, if first, second, etc. words are used to indicate a name, but not any particular order.

For convenience of description, the above devices are described as being functionally divided into various modules, respectively. Of course, when one or more of the present description is implemented, the functions of each module may be implemented in the same piece or pieces of software and/or hardware, or a module that implements the same function may be implemented by a plurality of sub-modules or a combination of sub-units, or the like. The above-described apparatus embodiments are merely illustrative, for example, the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other forms.

The present description is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the specification. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may 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 means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

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

The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer 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 technology, read only compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

One skilled in the relevant art will recognize that one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Moreover, one or more embodiments of the present description may take the form of a computer program product 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.

One or more embodiments of the present specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the present description may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments. In the description of the present specification, a description referring to terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present specification. In this specification, schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, the different embodiments or examples described in this specification and the features of the different embodiments or examples may be combined and combined by those skilled in the art without contradiction.

The foregoing is merely an example of one or more embodiments of the present specification and is not intended to limit the one or more embodiments of the present specification. Various modifications and alterations to one or more embodiments of this description will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, or the like, which is within the spirit and principles of the present specification, should be included in 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:

2. The method of claim 1, the second message carrying a signature;

the method further comprises the steps of:

verifying the signature of the second message received and sent by a consensus node in the blockchain system; if signature verification for the second message passes, the second message is further broadcast to other consensus nodes in the blockchain system.

3. The method according to claim 2,

upon determining that there is no transaction to be proposed in the local transaction pool, broadcasting the second message to other consensus nodes in the blockchain system, including:

upon receiving the first message broadcast by other consensus nodes in the blockchain system and determining that there is no transaction to be proposed in the local transaction pool, broadcast the second message to other consensus nodes in the blockchain system.

4. The method of claim 1, wherein the preset threshold is a configurable threshold.

5. The method of claim 4, the blockchain system supporting switching between a conservative mode and an optimistic mode; if the blockchain system is switched to an optimistic mode, the value range of S is [1, f ]; if the block chain system is switched to a conservative mode, the value range of S is [ f+1, n-f ]; wherein f represents the number of fault-tolerant nodes supported by a consensus protocol adopted by the blockchain system; the n represents a total number of consensus nodes in the blockchain system.

6. The method of claim 3, wherein the blockchain system employs a consensus protocol that is a consensus protocol for making transaction proposals based on blockwise identifications;

the first message comprises a block identifier of a target block to be consensus; and, the consensus node proposing the list of transactions for the target block;

the second message includes a block identifier of the target block for indicating that a consensus node sending the second message does not propose a transaction list for the target block;

the preset condition comprises that the consensus node has consensus passed for a transaction list proposed by the target block; or the second message which is sent by the consensus node and contains the block identifier of the target block is received;

the third message comprises a block identifier of the target block and is used for declaring that the transaction list proposed by other consensus nodes for the target block except the consensus node meeting the preset condition is not processed any more; or outputting the consensus result of the transaction list proposed by other consensus nodes for the target block except the consensus node meeting the preset condition as a consensus failure.

7. The method of claim 6, wherein the blockchain system employs a consensus protocol that is a myturner consensus protocol for making transaction proposals based on blockwise identification.

8. The method of claim 3, wherein the consensus protocol employed by the blockchain system is a consensus protocol that performs a consensus proposal based on a timestamp;

the first message comprises a timestamp corresponding to the moment of initiating the consensus proposal; and, the list of transactions proposed by the consensus node;

the second message comprises a key time stamp used for indicating that a consensus node sending the second message does not propose a transaction list at a moment corresponding to the key time stamp;

the preset condition comprises that the consensus node passes through a consensus of a proposed transaction list at any time after the time of initiating the consensus proposal; or a second message sent by the consensus node is received, and the key time stamp contained in the second message is a time stamp corresponding to any time after the time of initiating the consensus proposal;

the third message contains a timestamp corresponding to the time of initiating the consensus proposal, and is used for declaring that the transaction list proposed by other consensus nodes except the consensus node meeting the preset condition before the time corresponding to the timestamp is not processed any more; or outputting the consensus result of the transaction list proposed by other consensus nodes except the consensus node meeting the preset condition before the moment corresponding to the time stamp as the consensus failure.

9. The method of claim 8, wherein the blockchain employs a consensus protocol that is a mytuner consensus protocol.

10. A blockchain system, comprising: