CN114817949A

CN114817949A - Consensus method and block chain system

Info

Publication number: CN114817949A
Application number: CN202210316347.1A
Authority: CN
Inventors: 刘盛云; 邓福喜; 闫莺; 徐文博
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2021-10-09
Filing date: 2021-10-09
Publication date: 2022-07-29
Also published as: CN113609515A; WO2023056975A1; CN113609515B

Abstract

A consensus method and a block chain system are provided, the consensus method comprises: the first consensus node broadcasts a first message, wherein the first message comprises a transaction set of the consensus proposal, a timestamp and a signature of the first consensus node; the consensus node which receives the first message broadcasts a second message which comprises votes and signatures of the transaction set; the vote includes a summary value for the set of transactions; after the consensus node receiving the second message collects at least equal votes from different consensus nodes, broadcasting a fourth message to other consensus nodes; the fourth message comprises a key moment which is a time stamp in the first message; after collecting at least the fourth messages of the number of the Quorum from the different nodes, any consensus node does not process or vote to fail other consensus proposals before the critical moment.

Description

Consensus method and block chain system

Technical Field

The embodiment of the specification belongs to the technical field of block chains, and particularly relates to a consensus method and a block chain system.

Background

The Blockchain (Blockchain) is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. In the block chain system, data blocks are combined into a chain data structure in a sequential connection mode according to a time sequence, and a distributed account book which is not falsifiable and counterfeitable is ensured in a cryptographic mode. Due to the characteristics of decentralized, information non-falsifiable, and autonomy, the blockchain has more and more applications.

Disclosure of Invention

The invention aims to provide a consensus method and a block chain system, comprising the following steps:

an embodiment of a consensus method in a blockchain system comprises:

the first consensus node broadcasts a first message, wherein the first message comprises a transaction set of the consensus proposal, a timestamp and a signature of the first consensus node;

the consensus node receiving the first message broadcasts a second message, wherein the second message comprises votes and signatures of the transaction set; the vote includes a summary value for the set of transactions;

after the consensus node receiving the second message collects at least equal votes from different consensus nodes, broadcasting a fourth message to other consensus nodes; the fourth message comprises a key moment which is a time stamp in the first message;

after collecting at least the fourth messages of the number of the Quorum from the different nodes, any consensus node does not process or vote to fail other consensus proposals before the critical moment.

An embodiment of a consensus method in a blockchain system comprises:

after the consensus node receiving the second message collects at least Quorum consistent votes from different consensus nodes, if the consensus node does not broadcast different votes for the proposal, a third message is broadcast, wherein the third message comprises the digest value, the collected signature set and a key time, and the key time is a timestamp in the first message;

any consensus node, after collecting at least a Quorum number of third messages from different nodes, no longer processes or votes for failure other consensus proposals with timestamps before the critical moment.

Through the embodiment, consensus can be completed quickly.

A consensus method in a blockchain system, comprising:

after the consensus node receiving the second message collects at least Quorum consistent votes from different consensus nodes, if the consensus node does not broadcast different votes for the proposal, a third message is broadcast, and the third message comprises the digest value and the collected signature set;

after collecting at least Quorum consistent votes from different consensus nodes by the consensus node receiving the second message, if the consensus node does not broadcast different votes for the proposal, a third message is broadcasted, wherein the third message comprises the digest value and the collected signature set;

after the consensus node collects at least Quorum third messages which come from different nodes and represent the passing of the votes, the transaction set corresponding to the abstract value is output as a consensus result ordered according to the time stamps;

in the process that at least f +1 different consensus nodes respectively serve as first consensus nodes to perform the consensus, after any consensus node participating in the consensus confirms that f +1 consensus suggestions from different nodes pass the consensus/are output as consensus results, the earliest timestamp in the f +1 consensus suggestions is taken as a key moment, and consensus suggestions with other timestamps before the key moment are not processed or voted as not passing the consensus suggestions before the key moment; or the like, or a combination thereof,

in the process that at least Quorum different consensus nodes respectively serve as first consensus nodes to perform the consensus, after any node participating in the consensus confirms that the consensus proposals from different nodes with the quantity of Quorum pass the consensus/are output as the consensus result, the earliest timestamp in the Quorum consensus proposals is taken as a key time, and the consensus proposals with other timestamps before the key time are not processed or voted as not to pass the consensus proposals before the key time.

By the above embodiments it is advantageous to ensure that the entire system is usable and active.

An embodiment of a consensus method in a blockchain system comprises:

the consensus node switches between the cooperation mode and the competition mode according to historical consensus result conditions, wherein:

a cooperation mode: after the consensus node receiving the second message collects at least equal votes from different consensus nodes, broadcasting a fourth message to other consensus nodes; the fourth message comprises a key moment which is a time stamp in the first message; after collecting at least the fourth messages of the number of the Quorum from the different nodes, any consensus node does not process other consensus proposals with timestamps before the key moment or votes for failing to pass the consensus proposals before the key moment;

a competition mode: in the process that at least f +1 different consensus nodes respectively serve as first consensus nodes to perform the consensus, after any node participating in the consensus confirms that f +1 consensus proposals from different nodes pass the consensus/are output as a consensus result, the earliest timestamp in the f +1 consensus proposals is taken as a key moment, and consensus proposals with other timestamps before the key moment are not processed or voted to fail; or, in the process that at least the equal different consensus nodes respectively serve as the first consensus node to perform the consensus, after any node participating in the consensus confirms that the equal number of consensus proposals from different nodes pass the consensus/output as a consensus result, the earliest timestamp in the equal number of consensus proposals is taken as a key time, and the consensus proposals with other timestamps before the key time are not processed or voted as not to pass the consensus proposals before the key time.

An embodiment of a consensus method in a blockchain system comprises:

a cooperation mode: after collecting at least the number of the third messages from different nodes, any consensus node does not process other consensus proposals with timestamps before the key moment or votes for failing to pass the consensus proposals before the key moment;

Drawings

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

FIG. 1 is a diagram illustrating a conventional phase of a practical Byzantine fault tolerance algorithm in one embodiment;

FIG. 2 is a diagram illustrating a view switching phase of an embodiment of a practical Byzantine fault-tolerant algorithm;

FIG. 3 is a schematic diagram of an embodiment of badger Byzantine fault tolerance algorithm;

FIG. 4 is a flow chart of a consensus algorithm in one embodiment of the present description;

FIG. 5 is a schematic diagram of a consensus algorithm in one embodiment of the present description;

FIG. 6 is a schematic diagram of a consensus algorithm in one embodiment of the present description;

FIG. 7 is a schematic diagram of a consensus algorithm in one embodiment of the present description;

FIG. 8 is a schematic diagram of a consensus algorithm in one embodiment of the present description;

FIG. 9 is a schematic diagram of a consensus algorithm in one embodiment of the present description;

FIG. 10 is a schematic diagram of a consensus algorithm in one embodiment of the present description;

FIG. 11 is a graph of a consensus node distribution in an embodiment of the present disclosure;

FIG. 12 is a flow diagram of a consensus method in one embodiment of the present specification;

FIG. 13 is a schematic illustration of a consensus process in one embodiment of the subject specification;

FIG. 14 is a schematic diagram of a consensus process in an embodiment of the present disclosure.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the present specification, 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 a part of the embodiments of the present specification, and not all of the embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step should fall within the scope of protection of the present specification.

In the block chain system, different participants can establish a distributed block chain network through deployed nodes (nodes). A decentralized (or multi-centric) distributed book constructed using a chained blockchain structure is maintained at each node (or at most nodes, such as a consensus node) in the distributed blockchain network. Such a blockchain system needs to address the issue of consistency and correctness of the respective ledger data across multiple nodes that are decentralized (or multicenter). Each node runs a blockchain program, and under the design of certain fault tolerance requirements, all loyalty nodes are ensured to have the same transaction through a consensus (consensus) mechanism, so that the execution results of all loyalty nodes on the same transaction are ensured to be consistent, and the transaction and the execution results are packaged to generate a block. The current mainstream consensus mechanisms include: proof of Work (POW), Proof of stock (POS), Proof of commission rights (DPOS), Practical Byzantine Fault Tolerance (PBFT) algorithm, badger Byzantine Fault Tolerance (honeybadger bft) algorithm, and the like.

Taking PBFT as an example, the algorithm is proposed in 1999 by Miguel Castro (Castoterol) and Barbara Liskov (Rickov), solves the problem of low efficiency of the original Byzantine fault-tolerant algorithm, reduces the complexity of the algorithm from exponential level to polynomial level, and enables the Byzantine fault-tolerant algorithm to be feasible in practical system application. This paper was published at 1999 international conference on operating system design and implementation (OSDI 99). In the PBFT algorithm, all copies (replica) are run in a rotation process called View (View). In a certain view, one copy serves as a primary node (primary) and the other copies serve as backup nodes (backups). Views are consecutively numbered integers. The master node is calculated by 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. The assumption in this algorithm is that when there are at most f copies (i.e., nodes) that fail, if there are a total of at least 3f +1 copies, it is guaranteed that security and activity will be provided in the asynchronous system. In order to be able to ensure the data consistency requirements and fault tolerance requirements of all replicas, a set of a certain number of replicas, typically the set formed by most nodes in a distributed system, forms the majority (Quorum). For example, in the case where the total node number n is 3f +1 (the case where n is 3f +2 or n is 3f generally does not improve the fault tolerance effect), the Quorum is 2f + 1. Thus, for a distributed system containing four nodes, any three nodes can constitute one Quorum.

PBFT includes two processes, Normal Case Phase and View Change Phase, and FIG. 1 is a flow chart of the Normal Case Phase (conventional Phase) process. The Normal Case Phase mainly includes three phases of PRE-PREPARE, and COMMIT, where node number 3 may represent, for example, a down node (represented by x in fig. 1). When a Primary node fails (denoted by x in fig. 2, for example, before a view is changed, i.e., when a Primary node Primary, i.e., a replay 0 (copy 0) fails), a view change (view change) process needs to be started, so that a state adjustment is performed when a system has a failure, and a new Primary node is changed (for example, after a view is changed, a replay 1 is a Primary node Primary). FIG. 2 is a View of View Change Phase. The client may set a timeout mechanism if the master node drops or goes bad without broadcasting the client's request, etc. If timed out, the client may broadcast a request message to all replica nodes. After detecting that the master node is malicious or offline, the replica node may also initiate a View Change protocol stage to Change the master node (often referred to as "master Change"). In addition, the PRE-PREPARE, PREPARE and COMMIT three-stage consensus process may fail due to the proposal of the primary node initiating an error, or the PREPARE and COMMIT stages may not be consistent with the Quorum number (e.g., 2f +1 of 3f +1 nodes, also referred to as a Quorum number), and the consensus may not be completed. It is also possible in these cases to initiate a View Change protocol phase to replace the master node.

The PBFT protocol belongs to the semi-synchronous (partial synchronization) protocol, which is characterized by assuming that the network is asynchronous from the beginning, but can be synchronized from a certain time. To have different nodes agree on the same proposal in the network, the simplest way is to set up a master node, which unifies the opinions of the nodes. By setting the timer, the master node can be prevented from making mistakes. In PBFT, if the Normal Case Phase is not completed within a limited time, Backups is triggered to initiate View Change Phase to replace the master node. The PBFT fixes the primary node in one location and all requests can be sent to the primary node first and then broadcast by the primary node to other cognate 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.

In a single master node type protocol such as PBFT, only the master node can initiate a consensus proposal in the same consensus, and other nodes have no capability to initiate the consensus proposal. Alternatively, if there are proposals for other nodes, the proposals may need to be forwarded to the primary node, instead of initiating the proposals. The former is unfair to the power of the consensus node to construct the block, and the latter increases the pressure on the primary node egress bandwidth, although backup nodes may also suggest. Neither is particularly suitable for the case where most consensus nodes need to initiate a consensus proposal.

In contrast, the honeybadgebft (also often abbreviated HBBFT) algorithm belongs to an asynchronous (asynchronous) protocol. Asynchronous protocols are applicable to asynchronous networks, i.e., messages between nodes in such a network may be arbitrarily delayed, but eventually arrive. The timer is removed from the honeybadgebft and the execution of the protocol is driven by a message. Meanwhile, all nodes in the HoneyBadgerBFT algorithm are peer-to-peer, and no difference exists between a main node and a backup node, and a process of changing the main node is omitted. Asynchronous network consensus protocols such as HBBFT and the like have no concept of a main node, and all nodes can propose requests and try to construct blocks, so that the asynchronous network protocols relieve the problems of fairness and single-node bottleneck to a certain extent.

Fig. 3 is a flow chart of a single node angle of the honeybadgebft algorithm. In fact, as mentioned above, all nodes in the honeybadgerbt algorithm are peer-to-peer, that is, all nodes can execute the flow shown in fig. 3. As shown in fig. 3, from the perspective of a single node, the honeybadger bft mainly includes two stages, namely, Reliable BroadCast (RBC) and Asynchronous consensus (ABA, Asynchronous Binary protocol, also referred to as "01 Asynchronous consensus"). In addition, there is an Asynchronous Common Subset (ACS) protocol over RBC and ABA. The RBC stage at least comprises three rounds of message interaction of Rval, Echo and Ready, and the ABA stage at least comprises three rounds of message interaction of Bval, Aux and Coin. RBC guarantees reliable offer broadcasting using three rounds of message interaction. ABA first performs two rounds of voting (Bval and AUX messages) and then knows the proposal of each node uniformly by throwing a Coin (Coin), thereby bypassing the requirement of the semi-synchronous protocol for network synchronization. One HoneyBadgerBFT consensus goes through the RBC stage and at least one ABA stage. In the best case, the probability of 1/2 exists to end the HoneyBadgerBFT consensus process, so that one consensus needs to be completed through 6 rounds. In addition, there is a probability of 1/4 entering the next ABA process, for example, in the second ABA process (ABA process represented by 7, 8, and 9 rounds) in fig. 3, there is a probability of 1/4 ending in the second round, and there is a probability of at least 1/4 that can end the HoneyBadgerBFT consensus process, so that one consensus needs to be completed through 9 rounds. After the second ABA process, there is overall a probability of 1/8 going into the second ABA process … … and so on.

In summary, the honeybadgebft includes at least one RBC (three rounds) and one ABA (three rounds), and if the voting result of the ABA is inconsistent with the coin-throwing result, the protocol enters a new round of ABA (at least three additional rounds). Coin throws introduce uncertainty into the consensus rounds, possibly increasing delay.

In addition, for a finally generated block (corresponding to an epoch), one node can run an ACS and n RBCs + n ABAs, where n is the number of consensus nodes, and 1 RBC and ABA corresponds to a consensus proposal initiated by itself, and the other (n-1) RBCs and ABAs correspond to a consensus proposal initiated by the other (n-1) nodes. That is, for an epoch, a node initiates a consensus proposal and simultaneously completes consensus proposals initiated by other nodes. Thus, for a node, after at least (n-f) RBCs are finished, the condition that the RBCs are finished (indicated by Ready message) is sent to the ACS, and the ACS gives an initial value to the corresponding ABA, so that the corresponding ABA process is started. After at least (n-f) consensus suggestions complete ABA, if the rest consensus suggestions still do not complete RBC, the initial value is set to 0, and then the ABA process corresponding to the suggestions is executed. From the global perspective, at least (n-f) nodes execute the same consensus process (at least (n-f) different nodes initiate proposed processes), and finally the ACS collects all proposed ABA results and sorts the proposed ABA results with 1 according to some rule to output.

In the above process, contrary to PBFT, a strong proposal requirement is put on each node participating in consensus, i.e. the node participating in consensus needs to initiate a proposal in each epoch, regardless of whether the node really has a proposal or not. If the node does not actually propose, a proposal request with empty content needs to be initiated (the empty proposal request can be encrypted in the RBC, so that other nodes cannot determine the content of the proposal, and a malicious node can be prevented from selectively assigning value input or output in the BA process because the malicious node can see the content in the proposal). Even if this node is a failed node and cannot issue a proposal, the ACS of other nodes still has a position for the proposal corresponding to this node. Specifically, after each of the other nodes executes at least four ABAs, which are all commonly identified as 1, if the four Ready messages corresponding to the RBC stage proposed by the node have not been received, the ACS needs to assign 0 to the ABA initial value corresponding to the RBC stage proposed by the node, and then enters an ABA process. Thus, other nodes also need to cooperate to complete the ABA process for which this failed node corresponds to the proposal.

The present application provides an embodiment of a consensus algorithm, as shown in fig. 4, specifically including:

s41: the first consensus node broadcasts a first message including a set of transactions of the consensus proposal, a timestamp, and a signature of the first consensus node.

In an embodiment of the consensus algorithm, 3 rounds of interaction may be included. Similar to HBBFT, the consensus algorithm of the embodiment shown in fig. 5 also belongs to an asynchronous protocol, i.e. it is assumed that messages between nodes in the network can be delayed arbitrarily, but will eventually arrive. Similarly, the timer is removed in the embodiment of fig. 5, and the execution of the protocol is driven by the message; meanwhile, all the nodes can be peer-to-peer without the division of the main node and the backup node, any consensus node can initiate a consensus proposal, and each consensus node can also participate in the consensus process of other nodes for lifting the consensus proposal. The result of one consensus may include the sum of the transaction sets in the consensus proposal in which all nodes in the consensus pick up and obtain at least the Quorum number votes to agree.

From a Node point of view, e.g. in Node ₀ The interaction process from the perspective of initiating the consensus proposal is shown in fig. 5. In one consensus, Node ₀ A consensus proposal may be initiated, which may include a packaged set of transactions, e.g., marked m ₀ ，m ₀ May comprise a series of sets of transaction constituents { tx } ₀₁ ，tx ₀₂ ，...，tx _0n }. Further, Node ₀ The first message may be broadcast to other cognizant nodes, such as Node in FIG. 5 ₁ 、Node ₂ And Node ₃ . The Node may be included in the first message of the broadcast ₀ Is a consensus proposed transaction set m ₀ . This message may be referred to as a Val message.

In addition, the message may include the first cognate node pair m ₀ Signatures, e.g. sig ₀₀ . Generally, the first common Node ₀ Can use its own private key to pair m ₀ Direct signature to obtain sig ₀₀ Or m may be first aligned ₀ 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 self to obtain the sig ₀₀ It can also be a private key pair m ₀ And ts ₀ Directly signing or pairing data thereinm ₀ And ts ₀ The hash value of the data inside is signed.

A timestamp may also be included in the first message. This timestamp may be the physical time at or before the time the first message was broadcast by the first common node, which may be determined by a local clock. If each of the common nodes in the blockchain network can achieve relatively accurate clock synchronization, the timestamp in the first message is also a relatively accurate time in the node that received the first message.

Considering that there may be a certain physical distance between the nodes and therefore there is a non-negligible delay in the propagation of the message, the timestamp included in the first message may be determined based on the physical time at or before the first common node broadcasts the first message and the network transmission delay. For example, in a blockchain network including 4 consensus nodes, if the average or maximum transmission delay from the first consensus node to the other three consensus nodes is Δ, the timestamp in the first message is ts ₀ ＝t ₀ + Δ, where t ₀ May be the local physical time at which the first common node broadcasts the first message. This delta may be determined by RTT (Round-Trip Time), which may generally represent the total Time that elapses in a network from when a sender sends data to a receiver to when the sender receives an acknowledgement from the receiver. In general, Δ may be half the RTT. For the case that the RTT between the first common node and the other three common nodes is different, the average value of the three Δ values or the maximum value of the three Δ values may be taken, for example

Or Δ ═ max (Δ) ₁ ，Δ ₂ ，Δ ₃ )。

The format of the Val message may be as<ts ₀ ,m ₀ ,sig ₀₀ >Wherein ts is ₀ Can represent Node ₀ Timestamp, m, of the launch of the consensus proposal ₀ A set of transactions in the consensus offer may be represented. The sig ₀₀ Can be a Node ₀ Including ts with its own private key pair ₀ And m ₀ Of data withinThe signature can be m ₀ Performing hash calculation to obtain a hash value, and then using a private key thereof to perform hash value and ts ₀ Signing the data inside to obtain sig ₀₀ It can also be a private key pair m ₀ And ts ₀ Signing the data inside directly or on m ₀ And ts ₀ The hash value of the data inside is signed.

S43: a second message is broadcast by the consensus node receiving the first message, wherein the second message comprises votes and signatures for the transaction set; the vote includes the set of transactions m ₀ The digest value of (a).

At the end of the first round, the consensus node receiving the first message may verify the correctness of the received first message. For example, Node ₁ Node can be adopted ₀ Is to Node in the first message ₀ The signature of (2) is verified. If the verification is passed, S43 is entered.

S43, specifically as in fig. 5, the consensus node receiving the first message may broadcast the second message. In the second round of message interaction, Node ₁ 、Node ₂ 、Node ₃ Each broadcasting a second message to other consensus nodes. The second message broadcasted by the consensus Node may include the Node pair ₀ A vote of the initiated consensus proposal.

For example, Node ₁ 、Node ₂ 、Node ₃ The other consensus nodes may be told their vote for the consensus proposal by broadcasting a second message, which may be a vote of approval or disapproval of the message set in the consensus proposal. Specifically, at the end of the first round, the consensus node that received the Val message may calculate a hash value of the transaction set of the consensus proposal in the Val message. Further, if the Node of the consensus recognizes the Node of the consensus ₀ The proposed set of transactions may broadcast the hash value in the 2 nd round of messaging. Conversely, if the Node does not recognize the Node in the consensus ₀ The proposed transaction set, may broadcast 0 in the 2 nd round of message interaction. This second message of the broadcast may be denoted as Bval. In addition, the 2 nd round may be usedWhile the hash value is broadcast in the second message interaction, 1 is used to indicate that the vote for the proposal represented by the hash value is approved or passed, and 0 is used to indicate that the vote for the proposal represented by the hash value is not approved or passed, which is a simple change.

In this round, Node ₀ May not participate in the broadcast because the Node ₀ In the first round, the consensus proposal is initiated, and can represent the Node itself ₀ Is approved for the message set in the consensus proposal, so that the Node can be selected in the second round ₁ 、Node ₂ 、Node ₃ And respectively broadcasting the second message to other consensus nodes.

It should be noted that the consensus node may change its own view and vote again, i.e. send out a plurality of different Bval messages. For example, Node ₁ A Bval message whose content is the hash value of the transaction set may be sent for the first time to indicate approval of the transaction set in the consensus proposal, and then a Bval message whose content is 0 may be sent again to indicate disapproval of the transaction set in the consensus proposal. As another example, Node ₂ A Bval message whose content is 0 may be issued for the first time to indicate non-approval of the set of deals in the consensus proposal, and then a Bval message whose content is a hash value of the set of deals may be issued again to indicate approval of the set of deals in the consensus proposal.

In addition, a signature for the transaction set may be included in the second message. As mentioned above, the consensus Node that received the first message at the end of the first round may verify the correctness of the received first message, e.g. the Node ₁ Verifying Node ₀ Whether the signature of (2) is correct. Furthermore, the consensus node that receives the first message may sign the transaction set in the first message with its own private key. For example Node ₁ For transaction set m in first message ₀ Signing to obtain sig ₁₀ (ii) a Or Node ₁ Signing the hash value of m to obtain sig ₁₀ 。

Similarly, the format of the Bval message may be as follows<ts ₀ ,hash,sig ₁₀ >Wherein ts is ₀ Can beTs in received Val message ₀ Hash is m ₀ Hash value of (1), representing the pair m ₀ The voting viewpoint of (a) is acceptance. Then the sig ₁₀ Or may use its own private key pair to include ts ₀ And m ₀ Signature of the data within. Similarly, it can also be for m ₀ Hash value of and ts ₀ Signing the data inside to obtain sig ₁₀ It is also possible to use its own private key pair ts ₀ The hash value of the data including the hash is signed.

Node ₂ Receiving Node ₀ After sending Val message, similarly, m in Val message can also be calculated ₀ And signing the hash value by using a private key of the self to obtain the sig ₂₀ Further, a Bval message may also be broadcast. The Bval message may include the computed hash value and the signature sig ₂₀ May also include ts ₀ Hash value and signature sig ₂₀ 。

Node ₃ Receiving Node ₀ After sending Val message, similarly, m in Val message can also be calculated ₀ And signing the hash value by using a private key of the self to obtain the sig ₃₀ Further, a Bval message may also be broadcast. The Bval message may include the computed hash value and the signature sig ₃₀ May also include ts ₀ Hash value and signature sig ₂₀ 。

S45: third round the consensus node receiving the second message collects at least four consistent votes from different consensus nodes, and broadcasts a third message comprising the digest value and the collected signature if it has not broadcast a different vote for the proposal.

The consensus nodes in the second round broadcast the second message so that at the end of the second round, the consensus nodes receiving the second message can collect votes in the second message and broadcast a third message.

For example Node ₀ The votes in the Bval message may be collected at the end of the second round. Suppose Node ₀ Collect Node ₁ ，Node ₂ 、Node ₃ Broadcasting separatelyIs the transaction set m ₀ Hash value of, and Node ₀ M in the Val message broadcast in the first round ₀ Its corresponding hash is obviously also m ₀ The hash value of, then Node ₀ At least four consistent digest values were collected in this round (e.g., when f is 1, four is 3, and actually 4).

For example Node ₁ At the end of the second round, votes in the Bval message may be collected, assuming Node ₁ Collect Node ₂ 、Node ₃ The votes in the respectively broadcasted second messages are all the transaction set m ₀ Hash value of, and Node ₁ Votes in a second message broadcast in a second round, if also the transaction set m ₀ Hash value of (also representing an approval of the transaction set), and Node received in the first round ₀ M in outgoing Val message ₀ And the same hash value, then Node ₁ At least four consistent digest values were collected in this round (e.g., when f is 1, four is 3, and actually 4). It should be noted that, in the first round, Node ₀ M may be included in the broadcasted Val message ₀ Thus, at the end Node of the first round ₁ M included in the Val message can be calculated ₀ So as to count the Node in the second round ₁ M in broadcast Bval message ₀ Whether the hash value of the Node is the same as the hash value of the Node received in the second round ₂ And Node ₃ M from hair ₀ Whether the hash values are the same or not is judged, and whether at least Quorum consistent hash values from different consensus nodes are collected or not is further judged.

Node ₂ And Node ₃ And Node ₁ Similarly, no further description is given.

In addition, the consensus node may also collect signatures of different nodes at the end of the second round, as described above. The number of votes collected in the second round can be counted by signature. For example Node ₁ Respectively collected sigs ₁₀ 、sig ₂₀ 、sig ₃₀ The same hash value of the signature indicates that there are 3 votes representing approval for the hash. Of course, they may be obtained by copolymerizingAnd identifying a secure transmission channel established between the nodes to determine the uniqueness of the message and further determine the number of the message. The secure Transport channel is created by a technique such as a Message Authentication Code (MAC), a secure Transport Layer protocol (TTL), or the like.

For Node ₁ If at least Quorum consistent hash values from different consensus nodes are collected and for the proposal m itself ₀ If 0 has not been broadcast (i.e., a different vote), then a third message is broadcast. The third message may be denoted as a Prom message, meaning that the commitment is not to propose m ₀ And changing the viewpoint. As previously mentioned, m ₀ A hash value of (1) may indicate approval and 0 may indicate non-approval. Node ₁ For the proposal m ₀ No 0 was broadcast, meaning that there was no proposal m ₀ From the viewpoint of disapproval, it is needless to say that such disapproval may be expressed in a form other than 0. Node ₂ And Node ₃ And similarly.

In the third message of the broadcast, the collected pairs m can be included ₀ Such as the hash values and signatures collected in the first and second rounds described above.

The format of the Prom message may be as follows<ts ₀ ,hash,<Signature collection>>。

For example Node ₀ Suppose Node ₀ Node is collected in the second round ₁ ，Node ₂ 、Node ₃ The votes in the separately broadcast Bval messages are all the transaction set m ₀ The hash value of Node is collected ₁ 、Node ₂ And Node ₃ Each is respectively corresponding to m (or m) ₀ Hash value of) is sig ₁₀ 、sig ₂₀ 、sig ₃₀ And Node, and ₀ the self-pair m is also included in the Val message broadcast in the first round ₀ (or m) ₀ Hash value of) is sig ₀₀ The hash value of. Thus, the Node ₀ At least qurum consistent digest values were collected in this round (e.g., when qurum is 3). Further, Node ₀ In the Prom message broadcast in the third round, the hash value and the collected differences may be includedThe node's set m of transactions for the offer ₀ Representing approved hash values and signature sets, e.g. sig ₀₀ 、sig ₁₀ 、sig ₂₀ 、sig ₃₀ 。

For example, suppose Node ₁ Node is collected in the second round ₂ 、Node ₃ The votes in the separately broadcast Bval messages are all the transaction set m ₀ The hash value of Node is collected ₂ And Node ₃ Each is respectively to m ₀ (or m) ₀ Hash value of) is sig ₂₀ 、sig ₃₀ And Node, and ₀ its pair m is also included in the Val message broadcast in the first round ₀ (or m) ₀ Hash value of) is sig ₀₀ And Node, and ₁ its pair m is also included in the Bval message broadcast in the second round ₀ (or m) ₀ Hash value of) is sig ₁₀ The voting of (1). Thus, the Node ₁ At least four consistent digest values (e.g., where four is 3) and signatures of different nodes are collected in the first and second rounds. Further, Node ₁ In the Prom message broadcast in the third round, the hash value and the collected transaction set m for the offer from the different nodes may be included ₀ Representing approved hash values and signature sets, e.g. including sig ₀₀ 、sig ₁₀ 、sig ₂₀ 、sig ₃₀ 。

Node ₂ And Node ₃ Is also similar to Node ₁ 。

It should be noted that the signature set may be replaced by an aggregate signature or a threshold signature.

S47: and after the consensus node collects at least Quorum third messages from different nodes, outputting the transaction set corresponding to the digest value as a consensus result sequenced according to the time stamps.

After the third round of execution, the consensus node that received the Prom message may count the number of the collected Prom messages. The condition for the consensus node to send out the Prom message in the third round is that at least four consistent votes from different consensus nodes are collected in the second round and are directed to itselfThe proposal has not broadcast a different vote, i.e. it is equivalent to the end of the second round that the consensus node acknowledges a total of at least the number of Quorum's (including itself) for the proposal m ₀ Are all agreed upon. However, the consensus result cannot be output immediately after the second round is finished, and it needs to be observed whether other nodes collect at least the number of scores of the proposed m at the end of the second round ₀ Represents a agreed vote, and therefore needs to be confirmed by a third round of the Prom message, and the commitment by this Prom message is no longer for the same proposal m itself ₀ Represent different perspectives.

For example Node ₀ At least equal abstract values are collected in the first round and the second round, and then the Node ₀ In the Prom message broadcast in the third round, the hash value and the collected transaction set m of the different nodes representing approved hash values and signature sets, including sig for example, may be included ₀₀ 、sig ₁₀ 、sig ₂₀ 、sig ₃₀ 。

For example Node ₁ At least equal abstract values are collected in the first round and the second round, and then the Node ₁ In the Prom message broadcast in the third round, the hash value and the collected transaction set m of the different nodes representing approved hash values and signature sets, including sig for example, may be included ₀₀ 、sig ₁₀ 、sig ₂₀ 、sig ₃₀ 。

Node ₂ And Node ₃ Is also similar to Node ₁ 。

Thus, by a third round, e.g. Node ₀ At least Quorum Prom messages may be collected. Through at least Quorum Prom messages, Node ₀ It can be confirmed that each of at least the Quorum consensus nodes has collected a set m of transactions for the offer ₀ Indicating a number of votes approved for at least the number of votes, and each consensus Node issuing a Prom message promises no longer to alter the view of the votes, such that the Node ₀ The consensus can be further completed.

In the above embodiment, firstly, the number of rounds can be reduced to 3 on the premise that one consensus is completed, and compared with at least 6 rounds in HBBFT, the delay caused by the consensus process is greatly reduced. In fact, in the embodiment of the present application, it is equivalent to merge the last two rounds of the RBC process and the first two rounds of the ABA process in the HBBFT by using the look-ahead voting and digital signature techniques, so as to shorten the required rounds. The look-ahead voting refers to voting in the second round of the Bval in the above embodiment, and the HBBFT needs to vote in the fourth round of the Bval in the ABA process. The digital signature refers to the digital signature used in the first round and the second round in the above embodiments.

Further, m is as defined above ₀ May correspond to ts, as described above ₀ . In fact, Node ₀ Two different first messages may be initiated in parallel or one after the other. For example, Node ₀ At the initiation of m ₀ (corresponding hash) ₀ ) In the above three-round process, m can be initiated in parallel or before/after ₄ (corresponding hash) ₄ ) The above three-wheel process. Suppose m ₄ Corresponds to ts ₄ ，ts ₄ ＞ts ₀ . Then the Node initiating the consensus proposal ₀ And Node participating in consensus ₁ 、Node ₂ And Node ₃ When the consensus result is output, the consensus result m can be sorted according to the sequence of the timestamps, so that the consensus result m ₀ Is arranged at m ₄ Before. Accordingly, m is finally generated ₀ Corresponding block with block height less than m ₄ The corresponding block.

Each of the at least equal number of common nodes in the blockchain system may be used as the first common node to perform the first to third rounds of the above-described process. For example, the embodiment of FIG. 5 described above may be extended to a Node ₀ 、Node ₁ Node and Node ₃ Are all executed. Node ₁ 、Node ₂ And Node ₃ Each performing as a first common node, respectively, as also shown in fig. 6, 7, 8. Thus, from an overall perspective, there may be a superposition of fig. 5, 6, 7, 8. Wherein, for example, Node ₀ The set of transactions that initiate the consensus proposal is m ₀ And the timestamp is ts ₀ ，Node ₁ The set of transactions that initiate the consensus proposal is m ₁ And the timestamp is ts ₁ 、Node ₂ The set of transactions that initiate the consensus proposal is m ₂ And the timestamp is ts ₂ ，Node ₃ The set of transactions that initiate the consensus proposal is m ₃ And the timestamp is ts ₃ Thus, m is ₀ Can correspond to hash ₀ ，m ₁ Can correspond to hash ₁ ，m ₂ Can correspond to hash ₂ ，m ₃ Can correspond to hash ₃ . Suppose ts ₃ ＞ts ₁ ＞ts ₂ ＞ts ₀ Then Node ₀ 、Node ₁ 、Node ₂ And Node ₃ The local consensus results of each are m ₀ 、m ₂ 、m ₁ 、m ₃ I.e. the results sorted by time stamp. m is ₀ 、m ₂ 、m ₁ 、m ₃ May correspond to a final tile, respectively. The sorting may be performed after the ACS protocol of the consensus node collects the consensus results. Specifically, the ACS may collect the results of the respective consensus suggestions, sort the consensus results according to the timestamps of the respective consensus suggestions, and output the results.

According to the time stamp sorting considering the transmission delay, the time of the consensus ending is fully considered, namely, the sequence of the generated blocks is kept consistent with the completion sequence of the consensus result as much as possible.

Thus, in the manner described above, the relative position of the corresponding tile on the blockchain can be determined as soon as the consensus proposal is proposed. Moreover, for a block finally generated, which contains a consensus proposal, i.e. corresponds to the generation process of a consensus result, the consensus result does not need to wait for the results of other consensus proposals, and the consensus result can be rapidly output. This eliminates the need to wait for the consensus to be completed in conjunction with other consensus proposals during the generation of one consensus result. For the consensus nodes without proposals, the consensus proposal with the content being empty is not required to be proposed, and the consumption of network bandwidth is reduced. For the failed nodes which cannot provide the consensus proposal, as long as the normally working nodes reach the number of the scores in the embodiment, the process of generating the consensus result does not need to enter the ABA process after being assigned to 0 overtime as in the HBBFT, but can skip the failed nodes, thereby greatly reducing the consensus delay.

In the embodiment of the present application, similar to PBFT and HBBFT, a certain number of error nodes may be tolerated, for example, f error nodes may be tolerated in a common node with a total n of 3f +1, and qurum is 2f + 1. An example is given below where there are f (f ═ 1) failed nodes.

For example, as in the case of fig. 9 and fig. 10 superimposed, assume that Node ₃ Is a failed node.

As shown in fig. 9:

in the first round, Node ₀ The Val message is broadcast, and the format of the Val message can be as follows<ts ₀ ,m ₀ ,sig ₀₀ >Wherein ts is ₀ Can represent Node ₀ Timestamp, m, of the launch of the consensus proposal ₀ A set of transactions in the consensus offer may be represented. The sig ₀₀ Can be a Node ₀ Including ts with its own private key pair ₀ And m ₀ The signature of the data inside may be m ₀ Performing hash calculation to obtain a hash value, and then using a private key thereof to perform hash value and ts ₀ Signing the data inside to obtain sig ₀₀ It can also be a private key pair m ₀ And ts ₀ Signing the data inside directly or on m ₀ And ts ₀ The hash value of the data inside is signed.

At the end of the first round, the consensus node that received the Val message can verify the correctness of the received Val message. Specifically, Node ₁ Node can be adopted ₀ Is to Node in the first message ₀ Signature sig of ₀₀ And performing verification, and entering a second round if the verification is passed. Similarly, Node ₂ Node can be adopted ₀ Is to Node in the first message ₀ Signature sig of ₀₀ And performing verification, and entering a second round if the verification is passed. And Node ₃ Is a failed node.

In the second round, the consensus node receiving the Val message broadcasts a Bval message, wherein the Bval message comprises the transaction set m ₀ Voting and signing of (2); the vote includes the set of transactions m ₀ The hash value of. Since Node ₃ Is a failed Node and therefore does not respond, i.e. does not broadcast the Bval message, but is instead a Node ₁ 、Node ₂ Respectively broadcasting the Bval messages to other common identification nodes. Node ₁ The broadcast Bval message includes, for example, m ₀ Hash value of and Node ₁ Using its own private key pair m ₀ Signature sig of hash value of ₁₀ . In addition, the Bval message may be, for example<ts ₀ ,hash,sig ₁₀ >Then sig therein ₁₀ Can be Node ₁ Including ts with its own private key pair ₀ And m ₀ Signature of the data including the hash value of (d).

Node ₂ Receiving Node ₀ After sending Val message, similarly, m in Val message can also be calculated ₀ And the hash value and ts are matched by using the private key of the user ₀ Signature to obtain sig ₂₀ Further, a Bval message may also be broadcast.

At the end of the second round, the consensus node that received the Bval message may collect the votes in Bval. For Node ₀ And collecting votes in the Bval message at the end of the second round, and collecting the votes to the Node ₁ ，Node ₂ The votes in the respectively broadcast Bval messages all comprise the set of transactions m ₀ Hash value of, and Node ₀ M in the Val message broadcast in the first round ₀ Its corresponding hash is also m ₀ Hash value of, and Node ₁ ，Node ₂ The respectively broadcasted Bval message comprises respective signature sig ₁₀ And sig ₂₀ The Node also includes a signature sig in the Val message broadcast in the first round ₀₀ Then Node ₀ A total of 3 consistent hash values were collected at the end of the second round (when f is 1 and Quorum is 3). For Node ₁ Collecting Node at the end of the second round ₂ The vote in the broadcast Bval message is m ₀ Hash value and sig of ₂₀ And Node ₁ The votes in the Bval message broadcast in the second round are also hash values and sigs ₁₀ And Node received in the first round ₀ M in outgoing Val message ₀ Is also the same hash valueAnd sig ₀₀ Then Node ₁ 3 consistent hash values are collected in the round, and the number of the quadrum is met. For Node ₂ At the end of the second round, collect Node ₁ The vote in the broadcast Bval message is m ₀ Hash value and sig of ₁₀ And Node ₂ The votes in the Bval message broadcast in the second round are also hash values and sigs ₂₀ And Node received in the first round ₀ M in outgoing Val message ₀ The same hash value and sig ₀₀ Then Node ₂ 3 consistent hash values are collected in the round, and the number of the quadrum is met.

In the third round, after collecting at least four consistent hash values from different consensus nodes, the consensus node receiving the Bval message broadcasts a Prom message, wherein the Prom message comprises the hash values and the collected signatures, and if the consensus node does not broadcast 0 for the proposal.

For example, Node ₀ In the Prom message broadcast in the third round, the hash value and the collected transaction set m for the offer from the different nodes may be included ₀ Representing approved hash values and signature sets, a signature set being sig ₀₀ 、sig ₁₀ 、sig ₂₀ 。Node ₁ In the Prom message broadcast in the third round, the hash value and the collected transaction set m for the offer from the different nodes may be included ₀ Representing the approved hash value and the signature set, which is also sig ₀₀ 、sig ₁₀ 、sig ₂₀ 。Node ₂₀ In the Prom message broadcast in the third round, the hash value and the collected transaction set m for the offer from the different nodes may be included ₀ Representing the approved hash value and the signature set, which is also sig ₀₀ 、sig ₁₀ 、sig ₂₀ 。

After the third round of execution, the consensus node receiving the Prom messages counts the number of the collected Prom messages, and if at least Quorum Prom messages from different nodes are collected, the transaction set m corresponding to the hash value is used ₀ And outputting the result as a consensus result.

For Node ₀ In the third wheelAfter finishing collecting Node ₁ And Node ₂ The broadcasted Prom messages, and itself also the Prom messages, are broadcasted, so in total 3 Prom messages are collected.

Similar for Node ₁ After the third round, the Node is collected ₀ And Node ₂ The broadcasted Prom message, and itself also broadcasted the Prom message, thus totaling 3 Prom messages collected.

Similar for Node ₂ After the third round, the Node is collected ₀ And Node ₁ The broadcasted Prom message, and itself also broadcasted the Prom message, thus totaling 3 Prom messages collected.

By a third wheel, Node ₀ 3 proms are collected, it can be confirmed that each of at least 3 consensus nodes (which satisfy Quorum) has collected a set m of transactions for the proposal ₀ Indicating at least 3 votes approved (satisfying the query) and each consensus Node issuing the Prom message promises not to alter the view of the vote any more, such that the Node ₀ The consensus can be further completed, namely the transaction set m corresponding to the hash value ₀ And outputting the result as a consensus result. Node ₁ 、Node ₂ Also similarly, i.e. Node ₁ Node also collects the transaction set m corresponding to the hash value ₀ And outputting the result as a consensus result.

Similarly, as shown in the process of FIG. 10, Node ₂ The Val message is broadcast, and the format of the Val message can be as follows<ts ₂ ,m ₂ ,sig ₂₂ >Finally Node ₂ Aggregate transactions m ₂ And outputting the result as a consensus result. Node ₀ 、Node ₁ Also similarly, i.e. Node ₀ 、Node ₁ Also aggregate the transactions m ₂ And outputting the result as a consensus result.

Suppose m ₀ Has a time stamp of ts ₀ ，m ₂ Has a time stamp of ts ₂ And ts is ₂ ＞ts ₀ Then Node ₀ 、Node ₁ And Node ₂ Each producing two consensus results locally. Each consensus node can sort the two consensus results according to the timestamp, and the sorting result is m ₀ 、m ₂ To aFor the two blocks finally generated, m ₀ The block height of the corresponding block is small, m ₂ The block height of the corresponding block is larger.

In the above embodiment, the relative position of the corresponding block on the blockchain is determined when the consensus proposal is proposed. Moreover, for a block finally generated, which contains a consensus proposal, i.e. corresponds to the generation process of a consensus result, the consensus result does not need to wait for the results of other consensus proposals, and the consensus result can be rapidly output. This eliminates the need to wait for the consensus to be completed in conjunction with other consensus proposals during the generation of one consensus result. For the consensus nodes without proposals, the consensus proposal with the content being empty is not required to be proposed, and the consumption of network bandwidth is reduced. For the failed nodes which cannot provide the consensus proposal, as long as the normally working nodes reach the number of the scores in the embodiment, the process of generating the consensus result does not need to enter the ABA process after being assigned to 0 overtime as in the HBBFT, but can skip the failed nodes, thereby greatly reducing the consensus delay.

In practical blockchain applications, the above embodiments are more significant for specific situations. As shown in FIG. 11, for example, 4 nodes constituting a federation chain are respectively deployed in different countries, nodes _UK Located in great Britain, Node _DE Located in Germany, Node _FR Located in France, Node _CN Is located in China. Obviously, Node located in Europe _UK ，Node _DE And Node _FR The communication time delay between three nodes is small, and the three nodes and the nodes in Asia _CN The communication delay is large. Suppose Node _UK ，Node _DE And Node _FR The communication time delay among three nodes is 10ms, and the three European nodes and the Node _CN The communication delay of (2) is all 80 ms. If HBBFT is adopted, 3 nodes in Europe in the 4 nodes can form the Quorum, the RBC process can be completed in more than 30ms, the ABA process can be completed in more than 30ms, and the nodes _CN The proposal is initiated because it is always executed slower, so Node _CN Is provided withThe RBC process is not completed before the ABA process of other three nodes is finished with a larger probability, so that the Node _CN The proposal of (2) is assigned a value of 0 in the ABA initial value, thereby the Node _CN The proposal(s) often cannot be incorporated into the generated block (with a probability greater than 1/2 according to the coin-cast result), which corresponds to Node _CN Often losing construction rights to the block. Furthermore, even if Node _CN Having the right to construct blocks, a large delay can slow a consensus process.

With the consensus scheme of the above embodiment of the present application, the proposal of each node can be blocked (block generation) separately, and the consensus results are sorted according to the timestamp, so that it can be ensured that the relative position of the blocked proposal is determined when the consensus proposal is initiated without losing the block construction right. Especially for the failure node, the failure node does not need to wait for the failure node to initiate consensus proposal, and other nodes do not need to cooperate with the failure node to complete consensus. In other words, the results of the consensus may be ordered in the order of the timestamps, according to the actual proposed demand. In addition, no proposed consensus node is provided, and the proposal that the actual content is empty does not need to be initiated, so that the consumption of network bandwidth can be reduced.

As described above, the above embodiment fully considers the time when the consensus ends, i.e. the order of generating the blocks is consistent with the completion order of the consensus result as much as possible, according to the timestamp ordering considering the transmission delay. Suppose Node _UK ，Node _DE And Node _CN All initiate consensus proposals, Node _UK The local physical time to initiate the consensus proposal is 60ms, then the timestamp ts of its first message _UK ＝60+10＝70ms，Node _DE The local physical time of the origination of the consensus proposal is 70ms, then its timestamp ts of the first message _DE ＝70+10＝90ms，Node _CN The local physical time to initiate the consensus proposal is 10ms, then the timestamp ts of its first message _cN 10+80 ms 90 ms. If ordered by local physical time, the order is m _CN →m _UK →m _DE However, this is not consistent with the generation of consensus results, and therefore is not reasonable, otherwise the consensus results completed first need to wait for the consensus results to be completed later, and the region is not reasonableThe order of generation of the blocks may be lengthened. After considering the transmission delay, the completion sequence of the consensus result is approximately the same as the timestamp, so the generation sequence of the blocks is not lengthened.

In particular, for the same proposal, the second message and the third message have the same time stamp as in the first message, and the time stamp can be used for identifying the consensus process of the same proposal without introducing other identifications, so that the data volume of the protocol process can be saved.

In the PBFT, each consensus has a sequence number to identify the sequence of the message of the consensus. The sequence number may be dense incremental, such as, for example, arranged as 1, 2, 3, 4. Specifically, for example, in the first consensus, the Pre-prefix message initiated by the consensus master node includes a sequence number with a value of 3. The sequence number with the same value of 3 is included in both the prefix message and the Commit message following the consensus. Therefore, after the consensus is finished, each consensus node can determine the sequence of the results of the consensus in a plurality of preceding consensus results. This order may generally be used to determine the order in which the consensus node performs the consensus results and the generated tiles. For the consensus result with the sequence number value of 3, the consensus node can arrange to execute or block after the consensus result with the sequence number value of 2. Subsequently, the consensus master node may increase the value of sequence number by 1, i.e., change to 4, so as to initiate a Pre-preamble message with a value of 4 for sequence number in the next consensus, and accordingly, in the subsequent preamble message and Commit message, the value of sequence number is 4. Similarly, for the consensus result with the sequence number value of 4, the consensus node may arrange to perform or block after the consensus result with the sequence number value of 3. Subsequently, the consensus master node may increment the value of sequence number by 1, i.e., change to 5. Therefore, the consensus nodes can execute the same consensus results according to the same sequence, and the consistency of the blocks generated on the consensus nodes is guaranteed.

HBBFT is also similar, there is a sequence number for the same effect.

In the consensus algorithm in the embodiments of fig. 4-11, when a consensus proposal is proposed, i.e., the relative position of the corresponding block on the blockchain is determined by means of a timestamp, a final generated block contains a consensus proposal, so that the consensus result does not need to wait for the results of other consensus proposals, and thus the consensus result can be output quickly. The timestamps are relatively loose and do not have the dense increment property of sequence number, so that the execution order of the blocks cannot be strictly guaranteed. For example, for an consensus node, it may have completed a consensus result with a timestamp of 80.5ms, a consensus result of 100.8ms and a consensus result of 135.2ms, which may determine the relative execution order by the timestamp and then the blocking order, but whether there are other consensus results between the consensus result of 80.5ms and the consensus result of 100.8ms, and whether there are other consensus results between the consensus result of 100.8ms and the consensus result of 135.2ms, which cannot be determined by the timestamp. If another consensus node has a consensus result with a timestamp between 80.5ms and 100.8ms, or a consensus result with a timestamp between 100.8ms and 135.2ms, it is difficult to guarantee the consistency of the generated block between different consensus nodes. In order to ensure the consistency of the blocks generated on the respective consensus nodes, the respective consensus nodes need to perform the same consensus results in the same order. Therefore, a mechanism is needed to ensure that the consensus nodes perform the same consensus results in the same order.

In an embodiment provided by the present application, each consensus node processes a message in a FIFO (First Input First Output) manner. The FIFO is a traditional sequential execution method, in which an instruction entered first completes before executing a second instruction. To ensure that messages between correctly identified nodes meet the FIFO, this can be achieved by numbering each message sent and requiring the receiver to process the requests in the order of the numbering. Sequenced transmission of messages may also be guaranteed by the TCP protocol. TCP provides reliable data transmission, avoiding retransmission of data packets, reversal of order or even loss of data packets. The consensus node may number the message and push it into the network transport layer each time it sends the message. The network transmission layer adopts a TCP protocol, and transmits TCP data packets converted by the upper layer protocol to the receiver in sequence, and waits for the receiver to confirm the TCP data packets within a specific time length. And if the common node does not receive the confirmation of the receiver within a specific time length, the TCP data packet is retransmitted. And if the receiving party returns an acknowledgement to the TCP data packet within a specific time length, the common identification node sends the next TCP data packet. And the process is circulated until the transmission of the upper layer protocol data is completed. Once receiving all TCP packets of an upper layer protocol message, the receiving party may perform Cyclic Redundancy Check (CRC), and if correct, reassemble these data packets into a data stream according to the correct sequence and transmit the data stream to the upper layer protocol for processing, and send the TCP packet of the upper layer protocol with the next sequence number. In addition, Secure Sockets Layer (SSL)/Secure Transport Layer protocol (TLS) communication may also be used to ensure that the FIFO is implemented.

The present application further provides an embodiment, which may be as shown in fig. 12, comprising:

s121: a first consensus node broadcasts a first message comprising a set of transactions of the consensus proposal, a timestamp, and a signature of the first consensus node;

s123: a second message is broadcast by the consensus node receiving the first message, wherein the second message comprises votes and signatures for the transaction set; the vote includes a summary value for the set of transactions;

s125: a third round, after the consensus node receiving the second message collects at least four consistent votes from different consensus nodes, if it has not broadcast a different vote for the proposal itself, then it broadcasts a third message comprising the digest value and the collected signature set;

s127: and after the consensus node collects at least Quorum third messages which come from different nodes and represent the passing of the votes, outputting the transaction set corresponding to the abstract value as a consensus result ordered according to the time stamps.

For example, the first common Node ₀ A sequence of key moments t can be maintained locally ₀₁ ,t ₀₂ ,.. }, in the process of S121-S127, when a certain critical time t passes, the Node ₀ A fourth message may be broadcast to indicate that it has passed this critical moment, as shown in fig. 13. Such a fourth message is for example a Pass (t) message, the message name Pass indicating that the message is a message indicating that a certain critical time has passed, wherein the included parameter t is the critical time. Here, for example, Pass (t) is broadcast ₀₂ )。

Similarly, Node ₁ A key time sequence t can also be maintained locally ₁₁ ,t ₁₂ ,.. }, during the above S121-S127 (from local view, it may be during S121-S125, and the following description is not repeated), when a certain critical time t passes, Node ₁ A fourth message may be broadcast to indicate that it has passed this critical time, where for example, a Pass (t) is broadcast ₁₂ )。Node ₂ Similarly, for example, a sequence of key moments t is maintained locally ₂₁ ,t ₂₂ ,.. }, in the process of S121-S127, when a certain critical time t passes, the Node ₂ A fourth message may be broadcast to indicate that it has passed this critical time, where for example, a Pass (t) is broadcast ₂₄ )。Node ₃ Similarly, a time sequence t is maintained locally ₃₁ ,t ₃₂ ,.. }, in the process of S121-S127, when a certain critical time t passes, the Node ₃ A fourth message may be broadcast to indicate that it has passed this critical time, where for example, a Pass (t) is broadcast ₃₃ ). This is also shown in fig. 14. The sequences of key time shown in fig. 13 and 14 may be more dense or sparse, and are not limited herein.

The consensus nodes participating in consensus can be sequences of key time moments which are maintained locally by each of the consensus nodes. The sequences of the local maintenance key time points of the consensus nodes participating in the consensus may be the same, may not be the same, and may be different. For the same situation, it is often necessary to transmit the sequence of the key time for each node participating in the consensus in a centralized manner, or to negotiate or synchronize among the nodes participating in the consensus. For completely different situations, the nodes participating in the consensus may determine according to their own local clocks, so that a centralized manner is not required to send a sequence of key time for each node participating in the consensus, or the nodes participating in the consensus negotiate or synchronize with each other. As for the case of incomplete identity, the method may be that a centralized manner is used to send a key time sequence to each node participating in consensus, and then each consensus node adds a certain number of other key times on the basis, or each consensus node negotiates or synchronizes a part of key time sequences, and then each consensus node adds a certain number of other key times on the basis; of course, each node participating in consensus may determine the key time sequence according to the local clock and then partially coincide with each other.

The consensus node broadcasts a pass (t) message that, in addition to indicating itself that a critical time t has passed, may also represent a commitment, after which a vote for a proposal with a timestamp less than the critical time t is 0, or a consensus proposal with the timestamp before the critical time t is no longer processed. In this way, after the consensus node collects at least the qurum pass (t) messages (including the newly broadcasted pass (t) messages), the key time in the messages can be obtained, and the key time is, for example, the minimum key time in at least the qurum fourth messages. Thus, the consensus node can confirm that at least the Quorum consensus nodes have passed the critical time t, and can agree on "vote the consensus proposal with a timestamp less than t to 0 thereafter" or "no longer process the consensus proposal with a timestamp less than t". Thus, by broadcasting the Pass message and executing according to the agreed promised content, the effect similar to FIFO can be indirectly achieved, but the consensus proposal which has not voted before the key time t may not Pass the consensus and may not be processed even though the consensus proposal passes the voting; if the agreement fails or is not processed, the transaction set corresponding to the agreement offer cannot be recorded into the block. The latest Pass message is because the same node may broadcast the Pass messages of a plurality of different key moments in sequence, so that the latest key moment can be obtained for receiving the Pass messages of a plurality of different key moments sent by the same node.

The broadcast Pass message can be completed by participation of at least Quorum consensus nodes. In this way, each consensus node broadcasts the Pass messages, and any consensus node can receive at least (Quorum-1) number of Pass messages sent by other consensus nodes, and can collect at least the Quorum number of Pass messages together with the self-broadcasted Pass messages. The consensus nodes participating in consensus maintain the key time sequence locally, so that the key time in the latest Pass message broadcast by each consensus node may be the same or different. Even if the consensus nodes participating in the consensus maintain the same or partially same key time sequence locally, the key time in the latest Pass message broadcasted by each consensus node may be the same or different. And if the consensus nodes participating in consensus maintain completely different key time sequences in the local, the key time in the latest Pass message broadcasted by each consensus node is different. If the critical times in at least the Quorum number of the most recent Pass messages collected are the same, a consensus can be reached such as "vote 0 for consensus proposals with a timestamp less than t thereafter" or "no longer process consensus proposals with a timestamp less than t". If the critical times in collected at least equal number of Quorum Pass messages are different, such as the Node in the above example ₀ ～Node ₃ The key time in the 4 latest Pass messages collected (in this case, queue ═ 3) is Pass (t) ₀₂ )、Pass(t ₁₂ )、Pass(t ₂₄ ) And Pass (t) ₃₃ ) And the smallest of these is t ₀₂ Then "the timestamp will be less than t thereafter ₀₂ Is voted 0 "or" no longer processes the timestamp less than t ₀₂ The consensus proposal of (1) is "agreed upon.

A consensus method embodiment is provided below, which is combined with the embodiments of fig. 4-14 to illustrate specific timing for sending a Pass message.

In the embodiments corresponding to fig. 4-14, the consensus node that received the Val message broadcasts a Bval message that includes a vote and signature for the set of transactions that agreed to the proposal in the first message.

After the consensus node receiving the Bval message collects at least four consistent votes from different consensus nodes, it can be considered that a key time t has passed, where the key time t is a time stamp in the Val message in the current consensus, and for example, the time stamp is ts. Further, the pass (ts) message may be broadcast to other cognizant nodes.

Furthermore, after collecting at least the number of scores of pass (ts), any consensus node may not process any consensus proposals with time stamps before the critical time ts or vote as fail for the consensus proposals before the critical time ts. For example, for Val messages in other subcognitions for which the timestamp is less than ts, Bval (0), 0 often indicates a failure in the consensus algorithm's vote. Thus, for any new consensus proposal with a lagging timestamp, which is deemed by the consensus node of at least qurum to have a timestamp later than the critical time ts and thus voted 0 in Bval (0), will not be included on the newly generated tile. In this way, at least the Quorum's consensus node can execute the s-corresponding blocks that have been consensus in chronological order. And when the fourth message is broadcasted, if the consensus proposal of the earlier timestamp in the consensus is existed, namely the consensus proposal of the Bval round is completed, after the consensus proposal of the earlier timestamp is completed, the transaction set corresponding to the digest value is output as the consensus result sorted according to the timestamps. Thus, the completion sequence of the consensus result can be guaranteed.

On the other hand, after the consensus node receiving the second message collects at least four consistent votes from different consensus nodes, if the consensus node does not broadcast different votes for the proposal, a third message is broadcast, wherein the third message comprises the digest value and the collected signature set; after the consensus node collects at least four third messages from different nodes, the transaction sets corresponding to the digest values can be output as consensus results sorted according to the time stamps.

Alternatively, the Pass message is put into the third message for broadcasting, and the fourth message does not need to be broadcasted additionally, so that the number of messages which need to be transmitted by the protocol can be saved. Specifically, after the consensus node receiving the second message collects at least four consistent votes from different consensus nodes, if the consensus node does not broadcast different votes for the proposal, a third message is broadcast, wherein the third message includes the digest value, the collected signature set and a key time, and the key time is a timestamp in the first message. Furthermore, after collecting at least a Quorum number of third messages from different nodes, any consensus node does not process or vote to fail other consensus proposals with timestamps before the critical moment. Similarly, after the consensus node collects at least four third messages from different nodes, the transaction set corresponding to the digest value can be output as the consensus result sorted according to the timestamp.

The above scheme may be referred to as a "collaborative mode" because such a scheme may achieve consensus faster. Moreover, this approach can directly rely on the timestamp in the first message that initiates the consensus proposal, without requiring the consensus node to maintain the critical time sequence locally, reducing implementation cost and complexity.

The above scheme for the cooperative mode, although the consensus can be completed faster, has a certain risk. For example, if there is a malicious node that immediately raises a later time-stamped consensus proposal after the loyalty node proposes the consensus proposal, since the loyalty node's consensus proposal has not entered or completed the second round in the previous embodiments of the consensus method of the present application, the loyalty node's consensus proposal will eventually be agreed to 0, i.e., the vote fails, or is not processed, if the later time-stamped consensus proposal proposed by the malicious node completes the second round first. In this way, consensus proposals initiated by loyalty nodes will likely be filtered out due to attacks by malicious nodes. Even in the absence of a malicious attack, but in the event of a sudden increase in network delay or clock skew, some blocks may be perceived as 0 or may not be processed due to arriving at other nodes later than expected.

Based on this, the present application provides an embodiment of a "contention mode" consensus method, and still refers to the embodiments of fig. 4-14 to describe a specific time for sending a Pass message.

In one embodiment corresponding to fig. 4-14, it may be that at least f +1 different consensus nodes each initiate a consensus proposal, broadcasting a Val message, as the first consensus node. In the process that each of at least f +1 different consensus nodes is used as the first consensus node to broadcast the Val message, at least other 2f consensus nodes are matched to complete the consensus. Thus, the number of nodes participating in consensus is 2f +1, and the number of the nodes reaches the number of the Quorum.

In this process, when any node participating in the consensus confirms that f +1 consensus proposals made by different consensus nodes are commonly recognized as 1 (i.e. by the consensus, it means that the output is a consensus result), it can be confirmed that the consensus proposal of at least 1 loyalty node is commonly recognized as 1, so that the earliest timestamp in the f +1 consensus proposals can be used as the key moment. This is because, according to the byzantine fault tolerance model, at most f byzantine nodes (e.g., malicious nodes, non-responsive nodes) can be fault-tolerant among the common nodes whose total amount is 3f + 1. Then, f +1 consensus proposals made by different consensus nodes are known as 1, and at least 1 of them is the consensus proposal made by the loyalty node, which means that the consensus proposal of the loyalty node is not completely filtered out. This also indicates that the entire system is available with liveness (concept of liveness in distributed systems). Further, the consensus node may no longer process or vote to fail consensus proposals that have other timestamps before the critical moment.

Any node participating in consensus confirms that f +1 consensus proposals made by different consensus nodes are known to be 1, and a stronger condition may be that f +1 consecutive consensus proposals made by different consensus nodes are confirmed to be 1. The above is agreed to be 1, and a stronger condition may be that the output is an agreed result.

In another embodiment corresponding to fig. 4-14, it may be that at least 2f +1(Quorum) different consensus nodes respectively initiate a consensus proposal, broadcasting a Val message, as the first consensus node. In the process that each of at least 2f +1 different consensus nodes is used as the first consensus node to broadcast the Val message, at least other 2f consensus nodes are matched to complete the consensus. Thus, the number of nodes participating in consensus is 2f +1, and the number of the nodes also reaches the number of the Quorum.

In this process, when any node participating in the consensus confirms that 2f +1 (here, the number of the qualum is represented, and the qualum in the consensus algorithm of other fault-tolerant models may not be 2f +1) consensus proposals made by different consensus nodes are known as 1, it can be confirmed that the consensus proposal of at least f +1 loyalty nodes is known as 1, so that the earliest timestamp in the 2f +1 consensus proposals can be used as the key time. This is because, according to the byzantine fault tolerance model, at most f byzantine nodes (e.g., malicious nodes, non-responsive nodes) can be fault-tolerant among the common nodes whose total amount is 3f + 1. Then, 2f +1 consensus proposals made by different consensus nodes are known as 1, and at least f +1 of them are consensus proposals made by loyalty nodes, which means that the consensus proposals of loyalty nodes are not filtered out completely and the loyalty nodes are bound to be windy. This also indicates that the entire system is available and active. Further, the consensus node may no longer process or vote to fail consensus proposals that have other timestamps before the critical moment.

Any node participating in consensus confirms that 2f +1 consensus proposals made by different consensus nodes are known to be 1, and a stronger condition may be to confirm that 2f +1 consecutive consensus proposals made by different consensus nodes are known to be 1. The above is agreed to be 1, and a stronger condition may be that the output is an agreed result.

In one embodiment, the consensus node may switch between a cooperative mode and a contention mode. Specifically, the consensus node may switch between the cooperative mode and the contention mode according to a historical consensus result.

The consensus node may switch to the contention mode after confirming that a first number of consensus proposals from different nodes are agreed upon as failing. For example, the first number is f +1, so that the consensus node can switch to the contention mode after confirming that f +1 number of consensus proposals from different nodes are consensus-failed. Confirming that an f +1 number of consensus offers from different nodes are not recognized as passed, that at least 1 loyalty node proposes a consensus offer is not recognized as passed, that a previous pattern comparison is aggressive, or that a byzantine node is present. Thus, tuning to the competitive mode places the critical moments farther away from the current, allowing more consensus suggestions to pass consensus, but the side effect is a deterministic order that may not result in some consensus results being faster. A stronger condition may be to confirm that a first number of consecutive consensus suggestions from different nodes are agreed to fail.

The consensus node may switch to the cooperative mode after confirming that a second number of consensus proposals from different nodes are consensus results via consensus/output. For example, the second number is 2f +1 or Quorum, so that the consensus node can switch to the cooperative mode after confirming that there are 2f +1 or Quorum numbers of consensus proposals from different nodes as consensus results through consensus/output. Confirming that there are 2f +1 numbers of consensus offers from different nodes being consensus results through consensus/output, indicating that at least f +1 loyalty nodes offer consensus offers that were consensus results through, indicating a more relaxed pattern or the absence of byzantine nodes. Therefore, adjusting to the cooperative mode, the key time is set closer to the current, thereby facilitating a faster determination order of the consensus results, but the side effect is that some consensus suggestions may be filtered out in some larger determination cases due to network delay or clock cheapness, or relatively more easily be launched by a malicious node to filter attacks. A stronger condition may be to confirm that there is a second number of consecutive consensus proposals from different nodes as a consensus result by consensus/output.

The present application further provides an embodiment of a block chain system, comprising:

The present application further provides an embodiment of a block chain system, including:

after the consensus node collects at least Quorum third messages which come from different nodes and represent the passing of the votes, outputting a transaction set corresponding to the abstract value as a consensus result sorted according to the time stamps;

in the process that at least f +1 different consensus nodes respectively serve as first consensus nodes to perform the consensus, after any node participating in the consensus confirms that f +1 consensus proposals from different nodes pass the consensus/are output as a consensus result, the earliest timestamp in the f +1 consensus proposals is taken as a key moment, and consensus proposals with other timestamps before the key moment are not processed or voted to fail; or the like, or, alternatively,

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Hardware Description Language), traffic, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using 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, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, 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 for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a server system. Of course, this application does not exclude that with future developments in computer technology, the computer implementing the functionality of the above described embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, 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 approaches. The order of steps recited in the embodiments is merely one manner of performing the steps in a multitude of orders and does not represent the only order of execution. When an actual apparatus or end product executes, it may execute sequentially or in parallel (e.g., parallel processors or multi-threaded environments, or even distributed data processing environments) according to the method shown in the embodiment or 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, the presence of additional identical or equivalent elements in a process, method, article, or apparatus that comprises the recited elements is not excluded. For example, if the terms first, second, etc. are used to denote names, they do not denote any particular order.

For convenience of description, the above devices are described as being divided into various modules by functions, and are described separately. Of course, when implementing one or more of the present description, the functions of each module may be implemented in one or more software and/or hardware, or a module implementing the same function may be implemented by a combination of multiple sub-modules or sub-units, etc. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams 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 a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

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

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 computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, 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 that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

As will be appreciated by one skilled in the art, 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. Furthermore, one or more embodiments of the present description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

One or more embodiments of the present description 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 specification 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.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, as for the system embodiment, since it is substantially similar to the method embodiment, the description is relatively simple, and reference may be made to the partial description of the method embodiment for relevant points. In the description of the specification, reference to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," 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 specification. In this specification, the schematic representations of the terms used above are not necessarily intended to refer 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, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.

The above description is merely exemplary of one or more embodiments of the present disclosure and is not intended to limit the scope of one or more embodiments of the present disclosure. Various modifications and alterations to one or more embodiments described herein will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement or the like made within the spirit and principle of the present specification should be included in the scope of the claims.

Claims

1. A consensus method in a blockchain system, comprising:

after collecting at least the fourth messages of the number of the Quorum from the different nodes, any consensus node does not process other consensus proposals with time stamps before the key time, or votes for failing the consensus proposals before the key time.

2. The method of claim 1, further comprising:

and after the consensus node collects at least Quorum third messages which come from different nodes and represent the passing of the votes, outputting the transaction set corresponding to the abstract value as a consensus result ordered according to the time stamps.

3. The method as claimed in claim 2, wherein if there is a consensus proposal of the earlier timestamp in the consensus that has completed the vote when broadcasting the fourth message, after completing the consensus proposal of the earlier timestamp, the transaction set corresponding to the digest value is output as the consensus result sorted according to the timestamps.

4. The method of claim 1, the timestamp is determined based on a physical time at or before the first message was broadcast by the first common node and a network transmission delay.

5. The method of claim 4, wherein the network transmission delay comprises an average or a maximum of the network transmission delays of the first common node and the other common nodes.

6. The method of claim 1 or 2, wherein at least a number of the Quorum-number of the consensus nodes in the blockchain system participate in the consensus during the same consensus, and wherein at least one of the consensus nodes performs the method of claim 1 as the first consensus node.

7. The method of claim 1 or 2, wherein at least one consensus node is the first consensus node to perform at least two consensus results of the method of claim 1, the blocks being generated in the time-stamped order.

8. The method according to claim 1 or 2, wherein at least two consensus nodes are respectively used as the first consensus node to generate at least two consensus results generated by the method according to claim 1, and the blocks are generated according to the time stamp sequence.

9. The method of claim 1 or 2, wherein in the case that the total node number of the block chain system is 3f +1, the Quorum is 2f + 1.

10. A consensus method in a blockchain system, comprising:

11. The method of claim 10, further comprising:

12. The method as claimed in claim 11, wherein if there is a consensus proposal of the earlier timestamp in the consensus that has completed the vote when the third message is broadcast, after the consensus proposal of the earlier timestamp is completed, the transaction set corresponding to the digest value is output as the consensus result sorted according to the timestamps.

13. The method of claim 10, the timestamp is determined based on a physical time and a network transmission delay at or before a time at which a consensus node broadcasting the consensus proposal broadcasts a message containing the consensus proposal.

14. The method of claim 13, wherein the network transmission delay comprises an average or maximum value of network transmission delays of a consensus node broadcasting the consensus proposal and other consensus nodes.

15. The method of claim 10, wherein at least a Quorum number of consensus nodes in the blockchain system participate in a consensus process, and wherein at least one consensus node performs a consensus process as the consensus node broadcasting the consensus proposal.

16. The method according to claim 10 or 11, wherein at least one consensus node generates blocks in the time-stamped order as at least two consensus results from performing a consensus process by the consensus node broadcasting the consensus proposal.

17. The method according to claim 10 or 11, wherein at least two consensus nodes generate blocks in the time stamp order as at least two consensus results from performing a consensus process by the consensus node broadcasting the consensus proposal, respectively.

18. The method of claim 10 or 11, wherein in the case that the total node number of the block chain system is 3f +1, the Quorum is 2f + 1.

19. A consensus method in a blockchain system, comprising:

after the consensus node receiving the second message collects at least equal votes from different consensus nodes, if the consensus node does not broadcast different votes for the proposal, a third message is broadcast, wherein the third message comprises the digest value and the collected signature set;

after the consensus node receiving the second message collects at least equal votes from different consensus nodes, if the consensus node does not broadcast different votes for the proposal, a third message is broadcast, and the third message comprises the digest value and the collected signature set;

in the process that at least f +1 different consensus nodes respectively serve as first consensus nodes to perform the consensus, after any node participating in the consensus confirms that f +1 consensus proposals from different nodes pass the consensus/are output as a consensus result, the earliest timestamp in the f +1 consensus proposals is taken as a key moment, and consensus proposals with other timestamps before the key moment are not processed or voted to fail; or the like, or a combination thereof,

20. The method as claimed in claim 19, wherein the step of confirming that there are f +1 consensus proposals made by different consensus nodes as consensus result through consensus/output comprises:

and any node participating in consensus confirms that f +1 continuous consensus proposals proposed by different consensus nodes are consensus results through consensus/output.

21. The method of claim 19, wherein the step of confirming that there are equal consensus proposals made by different consensus nodes as a consensus result comprises:

the any node participating in the consensus confirms that there are Quorum consecutive consensus proposals proposed by different consensus nodes as the consensus result through consensus/output.

22. The method of claim 19, wherein the number of the total nodes in the blockchain system is 3f +1, and the number of the Quorum is 2f + 1.

23. A consensus method in a blockchain system, comprising:

the consensus node is capable of switching between a cooperative mode and a contention mode, wherein:

a cooperation mode: after collecting at least equal votes from different consensus nodes by the consensus node receiving the second message, broadcasting a fourth message to other consensus nodes; the fourth message comprises a key moment which is a time stamp in the first message; after collecting at least the fourth messages of the number of the Quorum from the different nodes, any consensus node does not process other consensus proposals with timestamps before the key moment or votes for failing to pass the consensus proposals before the key moment;

24. The method as claimed in claim 23, wherein the step of confirming that there are f +1 consensus proposals made by different consensus nodes as consensus result through consensus/output comprises:

25. The method of claim 23, wherein the step of confirming that there are equal consensus proposals made by different consensus nodes as a consensus result comprises:

26. The method of claim 23, wherein the number of the total nodes in the blockchain system is 3f +1, and the number of the Quorum is 2f + 1.

27. A consensus method in a blockchain system, comprising:

the first consensus node broadcasts a first message, wherein the first message comprises a transaction set of the consensus offer, a timestamp and a signature of the first consensus node;

a competition mode: in the process that at least f +1 different consensus nodes respectively serve as first consensus nodes to perform the consensus, after any node participating in the consensus confirms that f +1 consensus proposals from different nodes pass the consensus/are output as a consensus result, the earliest timestamp in the f +1 consensus proposals is taken as a key moment, and consensus proposals with other timestamps before the key moment are not processed or voted to fail; or, in the process that at least the Quorum different consensus nodes respectively serve as the first consensus node to perform the consensus, after any consensus proposal from different nodes with Quorum quantity is confirmed to be a consensus result through consensus/output, the earliest timestamp in the Quorum consensus proposals is taken as a key time, and consensus proposals with other timestamps before the key time are not processed or voted as not to pass the consensus proposals before the key time.

28. The method as claimed in claim 27, wherein the step of confirming that there are f +1 consensus proposals made by different consensus nodes as consensus result through consensus/output comprises:

29. The method of claim 27, wherein the step of confirming that there are equal consensus proposals made by different consensus nodes as a consensus result comprises:

30. The method of any one of claims 27-29, wherein the consensus node is capable of switching between a cooperative mode and a contention mode, comprising:

the consensus node can switch between the cooperation mode and the competition mode according to historical consensus result conditions.

31. The method of claim 30, wherein the consensus node is capable of switching between the cooperative mode and the contention mode based on historical consensus outcome conditions, comprising:

the consensus node switches to a contention mode after confirming that a first number of consensus proposals from different nodes are agreed upon as failed.

32. The method of claim 31, the consensus node being confirmed that a first number of consensus proposals from different nodes are consensus failed, comprising:

the consensus node is identified as failing after a first number of consecutive consensus proposals from different nodes.

33. The method of claim 31 or 32, wherein the first number is f + 1.

34. The method of claim 30, wherein the consensus node is capable of switching between the cooperative mode and the contention mode based on historical consensus outcome conditions, comprising:

the consensus node switches to a cooperative mode after confirming that a second number of consensus proposals from different nodes are consensus results via consensus/output.

35. The method of claim 34, the consensus node confirming that there is a second number of consensus proposals from different nodes as a consensus result by consensus/output, comprising:

the consensus node confirms that there is a second number of consecutive consensus proposals from different nodes as a consensus result by consensus/output.

36. The method of claim 35, wherein the second quantity is Quorum.

37. The method of claim 27, wherein the number of the total nodes of the blockchain system is 3f +1, and the number of the Quorum is 2f + 1.

38. A blockchain system, comprising:

after collecting at least equal votes from different consensus nodes by the consensus node receiving the second message, broadcasting a fourth message to other consensus nodes; the fourth message comprises a key moment which is a time stamp in the first message;

39. The system of claim 38, further comprising:

40. The system of claim 38, wherein in the case that the total number of nodes in the blockchain system is 3f +1, the Quorum is 2f + 1.

41. A blockchain system, comprising:

42. A blockchain system, comprising:

in the process that at least Quorum different consensus nodes respectively serve as first consensus nodes to perform the consensus, after any consensus node which participates in the consensus confirms that the consensus proposals from different nodes with the quantity of Quorum pass the consensus/output as a consensus result, the earliest timestamp in the Quorum consensus proposals is taken as a key time, and the consensus proposals with other timestamps before the key time are not processed or voted as not passing the consensus proposals before the key time.

43. A blockchain system, comprising:

the consensus node switches between a cooperation mode and a competition mode according to historical consensus result conditions, wherein:

44. A blockchain system, comprising: