WO2023056975A1 - 共识方法和区块链系统 - Google Patents

共识方法和区块链系统 Download PDF

Info

Publication number
WO2023056975A1
WO2023056975A1 PCT/CN2022/124131 CN2022124131W WO2023056975A1 WO 2023056975 A1 WO2023056975 A1 WO 2023056975A1 CN 2022124131 W CN2022124131 W CN 2022124131W WO 2023056975 A1 WO2023056975 A1 WO 2023056975A1
Authority
WO
WIPO (PCT)
Prior art keywords
consensus
node
message
nodes
proposals
Prior art date
Application number
PCT/CN2022/124131
Other languages
English (en)
French (fr)
Inventor
刘盛云
邓福喜
闫莺
徐文博
Original Assignee
支付宝(杭州)信息技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 支付宝(杭州)信息技术有限公司 filed Critical 支付宝(杭州)信息技术有限公司
Publication of WO2023056975A1 publication Critical patent/WO2023056975A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/604—Tools and structures for managing or administering access control systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6227—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database where protection concerns the structure of data, e.g. records, types, queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures

Definitions

  • the embodiments of this specification belong to the field of blockchain technology, and in particular relate to a consensus method and a blockchain system.
  • Blockchain is a new application model of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm.
  • the data blocks are combined into a chained data structure in a sequentially connected manner in chronological order, and a non-tamperable and unforgeable distributed ledger is cryptographically guaranteed. Due to the characteristics of the blockchain such as decentralization, immutable information, and autonomy, the blockchain also has more and more applications.
  • the purpose of the present invention is to provide a consensus method and blockchain system, including: an embodiment of the consensus method in the blockchain system, including: the first consensus node broadcasts the first message, and the first message includes the consensus proposal The transaction set, time stamp and signature of the first consensus node; the consensus node that received the first message broadcasts the second message, and the second message includes the vote and signature on the transaction set; the vote includes the transaction The summary value of the set; after the consensus node receiving the second message collects at least Quorum unanimous votes from different consensus nodes, it broadcasts the fourth message to other consensus nodes; the fourth message includes the critical moment, which is the first Timestamp in the message; after any consensus node collects at least Quorum number of fourth messages from different nodes, it will no longer process other consensus proposals with timestamps before the critical moment or for the consensus proposals before the critical moment Consensus proposal voted not to pass.
  • An embodiment of a consensus method in a blockchain system comprising: a first consensus node broadcasts a first message, and the first message includes a consensus proposed transaction set, a time stamp, and a signature of the first consensus node; receiving the first consensus node The consensus node of the first message broadcasts the second message, which includes voting and signatures on the transaction set; the vote includes the summary value of the transaction set; the consensus node receiving the second message collects at least Quorum After unanimous votes from different consensus nodes, if they have not broadcast different votes for the proposal, then broadcast the third message, the third message includes the summary value, the collected signature set and the key moment, the key The moment is the timestamp in the first message; after any consensus node collects at least Quorum number of third messages from different nodes, it will no longer process other consensus proposals with timestamps before the critical moment or Consensus proposals before the critical moment are voted not to pass.
  • a consensus method in a block chain system comprising: a first consensus node broadcasts a first message, the first message includes a consensus proposed transaction set, a time stamp, and a signature of the first consensus node; receiving the first message
  • the consensus node broadcasts the second message, which includes the vote and signature on the transaction set; the vote includes the summary value of the transaction set;
  • the consensus node that receives the second message collects at least Quorum from After the unanimous votes of different consensus nodes, if they have not broadcast different votes for the proposal, broadcast the third message, the third message includes the digest value and the collected signature set;
  • the consensus node receiving the second message After collecting at least Quorum unanimous votes from different consensus nodes, if it has not broadcast different votes for the proposal, broadcast the third message, the third message includes the digest value and the collected signature set; consensus After the node collects at least Quorum third messages from different nodes indicating that the vote is passed, it outputs the transaction set corresponding to the summary value as the consensus result sorted by the timestamp
  • An embodiment of a consensus method in a blockchain system comprising: a first consensus node broadcasts a first message, and the first message includes a consensus proposed transaction set, a time stamp, and a signature of the first consensus node; receiving the first consensus node
  • the consensus node of the first message broadcasts the second message, which includes voting and signatures on the transaction set; the vote includes the summary value of the transaction set;
  • the consensus node receiving the second message collects at least Quorum After unanimous votes from different consensus nodes, if they have not broadcast different votes for the proposal, broadcast the third message, the third message includes the digest value and the collected signature set;
  • the consensus node collects at least Quorum After a third message from different nodes indicating that the vote is passed, the transaction set corresponding to the summary value is output as the consensus result sorted by the timestamp;
  • the consensus node is based on the historical consensus results in the cooperation mode and Switch between competition modes, among them: cooperation mode: After the consensus node receiving the second message collects at least Quor
  • An embodiment of a consensus method in a blockchain system comprising: a first consensus node broadcasts a first message, and the first message includes a consensus proposed transaction set, a time stamp, and a signature of the first consensus node; receiving the first consensus node The consensus node of the first message broadcasts the second message, which includes voting and signatures on the transaction set; the vote includes the summary value of the transaction set; the consensus node receiving the second message collects at least Quorum After unanimous votes from different consensus nodes, if they have not broadcast different votes for the proposal, then broadcast the third message, the third message includes the summary value, the collected signature set and the key moment, the key The time is the timestamp in the first message; the consensus node switches between the cooperation mode and the competition mode according to the historical consensus results, wherein: cooperation mode: any consensus node collects at least Quorum number from different nodes After the third message of , no other consensus proposals with timestamps before the critical moment will be processed or the consensus proposals before the critical moment will be voted not to pass; competition mode
  • Fig. 1 is a schematic diagram of a conventional stage of a practical Byzantine fault-tolerant algorithm in an embodiment
  • Fig. 2 is a schematic diagram of the view switching stage of the practical Byzantine fault-tolerant algorithm in an embodiment
  • Fig. 3 is a schematic diagram of the honey badger Byzantine fault-tolerant algorithm in an embodiment
  • Fig. 4 is a flowchart of the consensus algorithm in an embodiment of this specification.
  • Fig. 5 is a schematic diagram of a consensus algorithm in an embodiment of this specification.
  • Fig. 6 is a schematic diagram of a consensus algorithm in an embodiment of this specification.
  • Fig. 7 is a schematic diagram of a consensus algorithm in an embodiment of this specification.
  • Fig. 8 is a schematic diagram of a consensus algorithm in an embodiment of this specification.
  • Fig. 9 is a schematic diagram of a consensus algorithm in an embodiment of this specification.
  • Fig. 10 is a schematic diagram of a consensus algorithm in an embodiment of this specification.
  • FIG 11 is a distribution diagram of consensus nodes in an embodiment of this specification.
  • FIG. 12 is a flowchart of the consensus method in an embodiment of this specification.
  • Figure 13 is a schematic diagram of a consensus method in an embodiment of this specification.
  • Fig. 14 is a schematic diagram of a consensus method in an embodiment of this specification.
  • nodes In the blockchain system, different participants can establish a distributed blockchain network through the deployed nodes (Nodes).
  • Nodes A decentralized (or multi-centered) distributed ledger constructed using a chained block structure is stored on each node (or most nodes, such as consensus nodes) in the distributed blockchain network.
  • Such a blockchain system needs to solve the problem of the consistency and correctness of the respective ledger data on multiple decentralized (or multi-centered) nodes.
  • Each node runs a blockchain program. Under the design of certain fault-tolerant requirements, the consensus mechanism is used to ensure that all loyal nodes have the same transaction, so as to ensure that all loyal nodes have the same execution results for the same transaction, and will Transactions and execution results are packaged to generate blocks.
  • the current mainstream consensus mechanisms include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT) ) algorithm, Honey Badger Byzantine Fault Tolerance (HoneyBadgerBFT) algorithm, etc.
  • POW Proof of Work
  • POS Proof of Stake
  • DPOS Delegated Proof of Stake
  • PBFT Practical Byzantine Fault Tolerance
  • HoneyBadgerBFT Honey Badger Byzantine Fault Tolerance
  • the algorithm assumes that when at most f replicas (ie, nodes) fail, if there are at least 3f+1 replicas in total, security and liveness can be guaranteed to be provided in an asynchronous system.
  • a set of a certain number of copies is required, which is generally a collection of most nodes in a distributed system, forming a majority (Quorum).
  • the Quorum is 2f+1. In this way, for a distributed system containing four nodes, any three nodes can form a Quorum.
  • PBFT includes two processes, Normal Case Phase and View Change Phase.
  • Figure 1 is a flow chart of the Normal Case Phase (normal phase) process.
  • the Normal Case Phase mainly includes three phases: PRE-PREPARE (pre-preparation), PREPARE (preparation) and COMMIT (commitment).
  • node 3 can represent a downtime node (indicated by ⁇ in Figure 1), for example.
  • FIG. 2 is a schematic diagram of View Change Phase (view switching). If the master node goes offline or does evil and does not broadcast the client's request, etc., the client can set a timeout mechanism. If it times out, the client can broadcast the request message to all replica nodes.
  • the replica node After the replica node detects that the master node is malicious or goes offline, it can also initiate the View Change protocol phase to replace the master node (often referred to as "master change").
  • master change the three-stage consensus process of PRE-PREPARE, PREPARE and COMMIT may fail due to the wrong proposal initiated by the master node, or the PREPARE and COMMIT stages may not reach the number of Quorum (such as 2f+1 of 3f+1 nodes, Also known as the quorum), the consensus cannot be completed. In these cases it is also possible to initiate the View Change protocol phase to replace the master node.
  • the PBFT protocol is a partial synchronous protocol, which is characterized by assuming that the network is asynchronous at the beginning, but it can be synchronized from a certain moment. To allow different nodes to reach a consensus on the same proposal in the network, the easiest way is to set up a master node, and the master node will unify the opinions of each node. By setting the timer, you can prevent the master node from making mistakes. In PBFT, if the Normal Case Phase is not completed within a limited time, Backups will be triggered to initiate the View Change Phase to replace the primary node. PBFT fixes the master node in one position, and all requests can be sent to the master node first, and then broadcast to other consensus nodes by the master node. In addition to introducing additional latency in sending requests to the master node, the ingress and egress bandwidth of the master node can also become a performance bottleneck.
  • the HoneyBadgerBFT (also often abbreviated as HBBFT) algorithm belongs to an asynchronous (asynchronous) protocol.
  • Asynchronous protocols are suitable for asynchronous networks, that is, messages between nodes in this network can be delayed arbitrarily, but will eventually arrive. The timer is removed from HoneyBadgerBFT, and the execution of the protocol is driven by messages.
  • all nodes in the HoneyBadgerBFT algorithm are equal, there is no distinction between master nodes and backup nodes, and there is no process of changing masters.
  • Asynchronous network consensus protocols such as HBBFT have no concept of master nodes. Each node can propose a request and try to construct a block. Therefore, asynchronous network protocols alleviate the problems of fairness and single-node bottlenecks to a certain extent.
  • FIG 3 is a flow chart of the single node angle of the HoneyBadgerBFT algorithm.
  • all nodes in the HoneyBadgerBFT algorithm are peers, that is, all nodes can execute the process shown in Figure 3.
  • HoneyBadgerBFT mainly includes two stages, namely Reliable Broadcast (RBC) and Asynchronous Binary Agreement (ABA, asynchronous binary agreement, also known as "01 Asynchronous consensus").
  • RBC Reliable Broadcast
  • ABA Asynchronous Binary Agreement
  • ABA asynchronous binary agreement
  • ACS Asynchronous Common Subset
  • the RBC phase includes at least three rounds of message interaction of Rval, Echo, and Ready
  • the ABA phase includes at least three rounds of message interaction of Bval, Aux, and Coin.
  • RBC uses three rounds of message exchanges to ensure reliable proposal broadcasting. ABA first conducts two rounds of voting (Bval and AUX messages), and then uses Coin toss (Coin) to unify the proposals of each node, thereby bypassing the network synchronization requirements of the semi-synchronous protocol.
  • a HoneyBadgerBFT consensus must go through the RBC phase and at least one ABA phase. In the best case, there is a probability of 1/2 that the HoneyBadgerBFT consensus process can be ended. In this way, it takes 6 rounds to complete a consensus.
  • HoneyBadgerBFT includes at least one RBC (three rounds) and one ABA (three rounds). If the ABA voting result is inconsistent with the coin toss result, the protocol enters a new round of ABA (at least three additional rounds). Tossing coins brings uncertainty to the rounds of consensus and may increase delays.
  • a node can run an ACS and n RBCs+n ABAs, where n is the number of consensus nodes, and one of the RBCs and ABAs corresponds to the one initiated by itself.
  • Consensus proposal, other (n-1) RBCs and ABAs correspond to consensus proposals initiated by other (n-1) nodes. That is to say, for an epoch, when a node initiates a consensus proposal, it will also cooperate to complete the consensus proposal initiated by other nodes.
  • At least (n-f) nodes will perform the same above-mentioned consensus process (at least (n-f) different nodes initiate the proposal process), and finally the ACS will collect the ABA results of each proposal according to certain rules Output the proposals whose ABA result is 1 after sorting.
  • the ACS needs to give the node’s proposal the corresponding The initial value of ABA is assigned as 0, and then enters the ABA process. In this way, other nodes also need to cooperate to complete the ABA process corresponding to the proposal of the failed node.
  • This application provides an embodiment of a consensus algorithm, as shown in Figure 4, which specifically includes: S41: [First round]
  • the first consensus node broadcasts the first message, and the first message includes the consensus proposed transaction set, timestamp and the first A signature of a consensus node.
  • a consensus algorithm in this application may include 3 rounds of interaction. Similar to HBBFT, the consensus algorithm of the embodiment shown in Figure 5 is also an asynchronous protocol, that is, it is assumed that messages between nodes in the network can be delayed arbitrarily, but will eventually arrive. Similarly, the timer is also removed in the embodiment in Figure 5, and the execution of the protocol is driven by messages; at the same time, all nodes can be peer-to-peer, there is no distinction between the master node and the backup node, and any consensus node can initiate consensus Proposals, each consensus node can also participate in the consensus process where other nodes propose consensus proposals. The result of a consensus can include the sum of the transaction sets in the consensus proposal proposed by all nodes in this consensus and obtained at least the same number of Quorum votes.
  • Node 0 can initiate a consensus proposal, which can include a packaged transaction set, for example, marked as m 0 , m 0 can include a series of transaction sets ⁇ tx 01 , tx 02 ,..., tx 0n ⁇ . Further, Node 0 may broadcast the first message to other consensus nodes, such as to Node 1 , Node 2 and Node 3 as shown in FIG. 5 .
  • the broadcasted first message may include the transaction set m 0 proposed by the consensus of Node 0 . This message may be called a Val message.
  • this message may also include the signature of the first consensus node on m 0 , for example, denoted as sig 00 .
  • the first consensus node Node 0 can directly sign m 0 with its own private key to obtain sig 00 , or perform hash calculation on m 0 first to obtain the hash value (that is, the digest value), and then use its own The private key signs the hash value to obtain sig 00 , and can also use its own private key to directly sign the data including m 0 and ts 0 or sign the hash value of the data including m 0 and ts 0 .
  • a timestamp may also be included in the first message. This timestamp can be the physical time before or after the first consensus node broadcasts the first message, and can be determined by a local clock. If each consensus node 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.
  • RTT can generally represent the total time elapsed from the time a sender sends data to the receiver in the network until the sender receives an acknowledgment from the receiver. .
  • ⁇ can be half of RTT.
  • the format of the Val message can be like ⁇ ts 0 ,m 0 ,sig 00 >, where ts 0 can represent the timestamp when Node 0 initiates the consensus proposal, and m 0 can represent the transaction set in the consensus proposal.
  • the sig 00 can be that Node 0 uses its own private key to sign the data including ts 0 and m 0 , or it can first perform hash calculation on m 0 to obtain the hash value, and then use its own private key to sign The hash value and the data including ts 0 are signed to obtain sig 00 . You can also use your own private key to directly sign the data including m 0 and ts 0 or the data including m 0 and ts 0 hash value to sign.
  • the consensus nodes that received the first message can verify the correctness of the received first message. For example, Node 1 may use the public key of Node 0 to verify the signature of Node 0 in the first message. If the verification is passed, go to S43.
  • the consensus node that has received the first message may broadcast the second message.
  • Node 1 , Node 2 , and Node 3 respectively broadcast the second message to other consensus nodes.
  • the second message broadcast by the consensus node may include a vote on the consensus proposal initiated by Node 0 .
  • Node 1 , Node 2 , and Node 3 can broadcast the second message to inform other consensus nodes of their vote on the consensus proposal, and the vote can be to express approval or disapproval of the message set in the consensus proposal.
  • the consensus node that receives the Val message can calculate the hash value of the consensus-proposed transaction set in the Val message.
  • the consensus node approves the transaction set proposed by Node 0 in this consensus, it can broadcast the hash value in the second round of message interaction.
  • the consensus node does not approve the transaction set proposed by Node 0 in this consensus, it can broadcast 0 in the second round of message interaction. This broadcasted second message may be denoted as Bval.
  • 1 is used to indicate that the proposal represented by the hash value is approved or approved
  • 0 is used to indicate that the proposal represented by the hash value is not voted. Approved or not, it's just a simple change.
  • Node 0 does not need to participate in the broadcast, because Node 0 initiates a consensus proposal in the first round, which itself can represent Node 0 ’s approval of the message set in the consensus proposal, so that in the second round Node 1 , Node 2 , and Node 3 may respectively broadcast the second message to other consensus nodes.
  • consensus nodes can change their views and vote again, that is, send out multiple different Bval messages.
  • Node 1 can send a Bval message whose content is the hash value of the transaction set for the first time to express approval of the transaction set in the consensus proposal, and then can send a Bval message with a content of 0 again to indicate approval of the transaction set in the consensus proposal.
  • Disapproval of the set of transactions in the consensus proposal can be sent.
  • Node 2 can send a Bval message with content 0 for the first time to indicate disapproval of the transaction set in the consensus proposal, and then send a Bval message with the content of the hash value of the transaction set again to indicate An endorsement of the set of transactions in the consensus proposal.
  • the second message may also include a signature on the set of transactions.
  • the consensus node that receives the first message at the end of the first round can verify the correctness of the received first message, for example, Node 1 verifies whether the signature of Node 0 is correct.
  • the consensus node receiving the first message can use its own private key to sign the transaction set in the first message. For example, Node 1 signs the transaction set m 0 in the first message to obtain sig 10 ; it may also be that Node 1 first signs the hash value of m 0 to obtain sig 10 .
  • the format of the Bval message can be such as ⁇ ts 0 , hash, sig 10 >, where ts 0 can be ts 0 in the received Val message, and hash is the hash value of m 0 , indicating that the voting opinion for m 0 is agree.
  • the sig 10 may also be the signature of the data including ts 0 and m 0 using its own private key.
  • Node 2 After receiving the Val message from Node 0 , Node 2 can similarly calculate the hash value of m 0 in the Val message, sign the hash value with its own private key to obtain sig 20 , and then broadcast the Bval message.
  • the Bval message may include the calculated hash value and the signature sig 20 , or may include ts 0 , the hash value, and the signature sig 20 .
  • Node 3 After receiving the Val message from Node 0 , Node 3 can similarly calculate the hash value of m 0 in the Val message, sign the hash value with its own private key to obtain sig 30 , and then broadcast the Bval message.
  • the Bval message may include the calculated hash value and signature sig 30 , or may include ts 0 , hash value, and signature sig 20 .
  • the consensus nodes in the second round broadcast the second message, so that at the end of the second round, the consensus nodes that received the second message can collect the votes in the second message, and then broadcast the third message.
  • the Val message broadcast by Node 0 can include m 0 , so that at the end of the first round, Node 1 can calculate the hash value of m 0 included in the Val message, so that the statistics can be compared with the second Whether the hash value of m 0 in the Bval message broadcast by Node 1 in the round is the same, and whether it is the same as the hash value of m 0 sent by Node 2 and Node 3 received in the second round, and then whether it is collected At least Quorum of consistent hash values from different consensus nodes.
  • Node 2 and Node 3 are similar to Node 1 and will not be repeated here.
  • the consensus node can also collect the signatures of different nodes at the end of the second round, as mentioned earlier.
  • the number of votes collected in the second round can be counted by signing. For example, if Node 1 collects the same hash value signed by sig 10 , sig 20 , and sig 30 , it means that there are 3 votes for the hash.
  • the uniqueness of the message can also be determined through the secure transmission channel established between the consensus nodes, and then the number of messages can be determined.
  • the secure transmission channel is established, for example, by technologies such as message authentication code (Message Authentication Code, MAC) and secure transport layer protocol (Transport Layer Security, TTL).
  • Node 1 For Node 1 , if at least Quorum of consistent hash values from different consensus nodes are collected, and it has not broadcast 0 (that is, different votes) for the proposal m 0 , then broadcast the third message.
  • the third message can be recorded as a Prom message, which means that it promises not to change its opinion on the proposal m 0 .
  • the hash value of m 0 can indicate approval, and 0 can indicate disapproval.
  • Node 1 has not broadcast 0 for the proposal m 0 , which means that it has not disapproved the proposal m 0.
  • other forms other than 0 can be used to express this disapproval.
  • Node 2 and Node 3 are also similar.
  • the third broadcast message may include the collected votes for m 0 , such as the hash values and signatures collected in the first and second rounds above.
  • the format of the Prom message can be such as ⁇ ts 0 , hash, ⁇ signature collection>>.
  • Node 0 assuming that Node 0 collects Node 1 in the second round, and the votes in the Bval messages broadcast by Node 2 and Node 3 respectively are all hash values of the transaction set m 0 , so that Node 1 .
  • the signatures of Node 2 and Node 3 on m 0 are votes of sig 10 , sig 20 , and sig 30 respectively, and the Val message broadcast by Node 0 in the first round also includes its own vote for m 0
  • the signature of 0 (or the hash value of m 0 ) is the hash value of sig 00 .
  • the Prom message broadcast by Node 0 in the third round may include the hash value and the collected hash value and signature set that different nodes express approval for the proposed transaction set m 0 .
  • the signature set is, for example, sig 00 , sig 10 , sig 20 , sig 30 .
  • Node 1 collects in the second round that the votes in the Bval messages broadcast by Node 2 and Node 3 are all the hash values of the transaction set m 0
  • Node 2 and Node 3 respectively collect
  • the signature of m 0 (or the hash value of m 0 ) is the vote of sig 20 and sig 30
  • the Val message broadcast by Node 0 in the first round also includes its signature on m 0 (or the hash value of m 0 ) is a vote of sig 00
  • the Bval message broadcast by Node 1 in the second round also includes the vote that its signature on m 0 (or the hash value of m 0 ) is sig 10 .
  • the Prom message broadcast by Node 1 in the third round may include the hash value and the collected hash value and signature set that different nodes approve of the proposed transaction set m 0
  • the signature set includes, for example, sig 00 , sig 10 , sig 20 , sig 30 .
  • Node 2 and Node 3 are also similar to Node 1 .
  • the above signature set can also be replaced by an aggregate signature or a threshold signature.
  • consensus nodes that have received Prom messages can count the number of collected Prom messages.
  • the condition for the consensus node to send the Prom message in the third round is that at least Quorum unanimous votes from different consensus nodes have been collected in the second round, and it has not broadcast different votes for the proposal, which is equivalent to the second round
  • the consensus node confirms that a total of at least Quorum number of consensus nodes (including itself) votes for the proposal m 0 .
  • Node 0 collects at least Quorum consistent digest values in the first round and the second round, and then, the Prom message broadcast by Node 0 in the third round may include the hash value and the collected different nodes for the
  • the proposed transaction set m 0 represents the approved hash value and signature set, and the signature set includes, for example, sig 00 , sig 10 , sig 20 , and sig 30 .
  • Node 1 collects at least Quorum consistent digest values in the first round and the second round, and then, the Prom message broadcast by Node 1 in the third round may include the hash value and the collected different nodes for the
  • the proposed transaction set m 0 represents the approved hash value and signature set, and the signature set includes, for example, sig 00 , sig 10 , sig 20 , and sig 30 .
  • Node 2 and Node 3 are also similar to Node 1 .
  • Node 0 can collect at least Quorum Prom messages. Through at least Quorum Prom messages, Node 0 can confirm that each of at least Quorum consensus nodes has collected at least Quorum number of votes for the proposed transaction set m 0 , and each consensus node that sends Prom messages has Commitment will not change the point of view of the vote, so that Node 0 can further complete this consensus.
  • the delay caused by the consensus process is greatly reduced.
  • it is equivalent to combining the last two rounds of the RBC process and the first two rounds of the ABA process in the HBBFT by using the forward-looking voting and digital signature technology, thereby shortening the required rounds.
  • the forward-looking voting refers to voting in the second round of Bval in the above embodiment, while HBBFT needs to vote in the fourth round of 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 embodiment.
  • the aforementioned m 0 may correspond to ts 0 as mentioned above.
  • Node 0 may initiate two different first messages in parallel or successively.
  • Node 0 may initiate the above three rounds of m 4 (corresponding to hash 4 ) in parallel or before/after.
  • m 4 corresponds to ts 4 , ts 4 >ts 0 .
  • the node Node 0 that initiates the consensus proposal and the nodes Node 1 , Node 2 , and Node 3 that participate in the consensus output the consensus results can be sorted according to the order of timestamps, so that the consensus result m 0 is ranked before m 4 .
  • the finally generated block corresponding to m 0 has a block height smaller than the block corresponding to m 4 .
  • Each of the consensus nodes with at least the number of Quorum in the blockchain system can be used as the first consensus node to perform the above-mentioned first to third round processes.
  • the above-mentioned embodiment in FIG. 5 can be extended to be executed by Node 0 , Node 1 , Node 2 and Node 3 .
  • Node 1 , Node 2 , and Node 3 respectively execute as the first consensus node, which can also be shown in Figures 6, 7, and 8. In this way, it can be a superposition of Figures 5, 6, 7, and 8 from an overall perspective.
  • the transaction set that Node 0 initiates a consensus proposal is m 0 and the time stamp is ts 0
  • the transaction set that Node 1 initiates a consensus proposal is m 1 and the time stamp is ts 1
  • the transaction set that Node 2 initiates a consensus proposal is m 2
  • the timestamp is ts 2
  • the transaction set that Node 3 initiates a consensus proposal is m 3 and the timestamp is ts 3
  • m 0 can correspond to hash 0
  • m 1 can correspond to hash 1
  • m 2 can correspond to hash 2
  • the local consensus results of Node 0 , Node 1 , Node 2 and Node 3 are all m 0 , m 2 , m 1 , m 3 , that is, sorted by timestamp result.
  • m 0 , m 2 , m 1 , and m 3 may respectively correspond to a final block.
  • the above sorting can be performed after the ACS protocol of the consensus node collects the consensus results. Specifically, ACS can collect the results of each consensus proposal and sort the consensus results according to the timestamp of each consensus proposal and output them.
  • Sorting according to the timestamp considering the transmission delay fully takes into account the time when the consensus ends, that is, the order of generating blocks is as consistent as possible with the completion order of the consensus results.
  • the relative position of the corresponding block on the blockchain can be determined when the consensus proposal is proposed. Moreover, for a final generated block, which contains a consensus proposal, which 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 output quickly. This also eliminates the need to wait for the consensus completion of other consensus proposals during the generation of a consensus result. For consensus nodes without proposals, there is no need to propose consensus proposals whose content is actually empty, which reduces the consumption of network bandwidth.
  • the process of generating consensus results does not need to enter the ABA process after the timeout assignment is 0 as in HBBFT, but can be skipped. Failure nodes, which can greatly reduce the consensus delay.
  • a certain number of error nodes can be tolerated.
  • f error nodes can be tolerated among the consensus nodes whose total n is 3f+1, and the Quorum is 2f+1.
  • Node 3 is a failure node.
  • Node 0 broadcasts a Val message.
  • the format of the Val message can be ⁇ ts 0 , m 0 ,sig 00 >, where ts 0 can represent the timestamp when Node 0 initiates a consensus proposal, and m 0 Can represent a collection of transactions in a consensus proposal.
  • the sig 00 can be that Node 0 uses its own private key to sign the data including ts 0 and m 0 , or it can first perform hash calculation on m 0 to obtain the hash value, and then use its own private key to sign The hash value and the data including ts 0 are signed to obtain sig 00 . You can also use your own private key to directly sign the data including m 0 and ts 0 or the data including m 0 and ts 0 hash value to sign.
  • the consensus nodes that received the Val message can verify the correctness of the received Val message.
  • Node 1 can use the public key of Node 0 to verify the signature sig 00 of Node 0 in the first message, and if it passes the verification, enter the second round.
  • Node 2 can use the public key of Node 0 to verify the signature sig 00 of Node 0 in the first message, and if it passes the verification, it will enter the second round.
  • Node 3 is the failure node.
  • the consensus node that received the Val message broadcasts a Bval message, which includes the vote and signature for the transaction set m 0 ; the vote includes the hash value of the transaction set m 0 . Since Node 3 is a failed node, it does not respond, that is, it will not broadcast the Bval message, and Node 1 and Node 2 broadcast the Bval message to other consensus nodes respectively.
  • the Bval message broadcast by Node 1 includes, for example, the hash value of m 0 and the signature sig 10 of the hash value of m 0 by Node 1 using its own private key.
  • the Bval message can also be ⁇ ts 0 , hash, sig 10 >, where sig 10 can be Node 1 's signature on the data including the hash values of ts 0 and m 0 with its own private key.
  • Node 2 After Node 2 receives the Val message from Node 0 , similarly, it can also calculate the hash value of m 0 in the Val message, and use its own private key to sign the hash value and ts 0 to get sig 20 , and then broadcast Bval news.
  • the consensus nodes that received the Bval message can collect votes in Bval.
  • the votes in the Bval message are collected at the end of the second round, and the votes in the Bval messages broadcast by Node 1 and Node 2 respectively include the hash value of the transaction set m 0 , and Node 0 is in the first
  • the Val message broadcast in the round is also m 0
  • its corresponding hash is also the hash value of m 0
  • the Bval messages broadcast by Node 1 and Node 2 respectively include their respective signatures sig 10 and sig 20
  • the vote in the Bval message broadcast by Node 2 at the end of the second round is the hash value of m 0 and sig 20
  • the vote in the Bval message broadcast by Node 1 in the second round is also the hash value and sig 10
  • the m 0 in the Val message sent by Node 0 received in the first round also has the same hash value and sig 00
  • Node 1 collects 3 consistent hash values in this round, which satisfies the number of Quorum .
  • the vote in the Bval message broadcast by Node 1 at the end of the second round is the hash value of m 0 and sig 10
  • the vote in the Bval message broadcast by Node 2 in the second round is also the hash value and sig 20
  • the m 0 in the Val message sent by Node 0 received in the first round also has the same hash value and sig 00
  • Node 2 collects 3 consistent hash values in this round, which satisfies the number of Quorum .
  • the consensus node receiving the Bval message collects at least Quorum consistent hash values from different consensus nodes, if it has not broadcast 0 for the proposal, it broadcasts a Prom message, which includes the hash value along with the collected signature.
  • the Prom message broadcast by Node 0 in the third round may include the hash value and the collected hash value and signature set that different nodes approve of the proposed transaction set m 0 , and the signature set is sig 00 , sig 10 , sig 20 .
  • the Prom message broadcast by Node 1 in the third round it may include the hash value and the collected hash value and signature set that different nodes approve of the proposed transaction set m 0 , and the signature set is also sig 00 , sig 10 , sig 20 .
  • the Prom message broadcast by Node 20 in the third round may include the hash value and the collected hash value and signature set that different nodes approve of the proposed transaction set m 0 , and the signature set is also sig 00 , sig 10 , sig 20 .
  • the consensus node that received the Prom message counts the number of collected Prom messages. If at least Quorum Prom messages from different nodes are collected, the transaction set m 0 corresponding to the hash value is taken as the consensus result output.
  • Node 0 collects 3 Proms, and it can be confirmed that each of at least 3 consensus nodes (satisfying Quorum) has collected at least 3 votes (satisfying Quorum) that approve the proposed transaction set m 0 , and each consensus node that sends the Prom message promises not to change the voting point of view, so that Node 0 can further complete this consensus, that is, output the transaction set m 0 corresponding to the hash value as the consensus result.
  • Node 1 and Node 2 are also similar, that is, Node 1 and Node 2 also output the transaction set m 0 corresponding to the hash value as the consensus result.
  • Node 2 broadcasts the Val message.
  • the format of the Val message can be ⁇ ts 2 , m 2 , sig 22 >, and finally Node 2 outputs the transaction set m 2 as the consensus result.
  • Node 0 and Node 1 are similar, that is, Node 0 and Node 1 also output the transaction set m 2 as the consensus result.
  • each consensus node can sort the two consensus results according to the timestamp, and the sorting results are m 0 and m 2 , and for the two blocks finally generated, the block height corresponding to m 0 is smaller , the block height corresponding to m 2 is larger.
  • the relative position of the corresponding block on the blockchain is determined when the consensus proposal is proposed. Moreover, for a final generated block, which contains a consensus proposal, which 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 output quickly. This also eliminates the need to wait for the consensus completion of other consensus proposals during the generation of a consensus result. For consensus nodes without proposals, there is no need to propose consensus proposals whose content is actually empty, which reduces the consumption of network bandwidth.
  • the process of generating consensus results does not need to enter the ABA process after the timeout assignment is 0 as in HBBFT, but can be skipped. Failure nodes, which can greatly reduce the consensus delay.
  • HBBFT HBBFT
  • 3 of the 4 nodes located in Europe can form a Quorum, and they can complete the RBC process in more than 30ms, and can complete the ABA process in another 30ms.
  • the proposal initiated by Node CN is always executed slowly, so the RBC process proposed by Node CN has a high probability that it will not be completed before the end of the ABA process of the other three nodes, so the proposal of Node CN is assigned an initial value in ABA
  • the middle assignment is 0, so Node CN 's proposal often cannot be included in the generated block (the probability is greater than 1/2 according to the coin toss result), which means that Node CN often loses the construction right of the block.
  • a large delay will slow down the consensus process.
  • the proposal of each node can be separately formed into a block (generated block), and the consensus results are sorted according to the timestamp, which can ensure that without losing the right to construct the block, The relative position of the block is determined when the consensus is proposed.
  • the consensus results can be sorted according to the actual proposal requirements and in the order of timestamps.
  • there is no proposed consensus node and there is no need to initiate a proposal with empty content, which can reduce the consumption of network bandwidth.
  • the above embodiments are sorted according to the timestamps considering the transmission delay, fully considering the time when the consensus ends, that is, to keep the order of generating blocks consistent with the completion order of the consensus results as much as possible.
  • the order is m CN ⁇ m UK ⁇ m DE , but this is not consistent with the generation of consensus results, so it is unreasonable, otherwise the consensus results that are completed first need to wait for the consensus results that are completed later.
  • the generation order of blocks will be lengthened. After considering the transmission delay, the completion order of the consensus result is the same as the timestamp with high probability, so the generation order of the blocks will not be protracted.
  • the second message and the third message have the same timestamp as the first message, and this timestamp can be used to identify the consensus process of the same proposal without introducing other identifiers, thus saving The amount of data in the protocol process.
  • each consensus has a sequence number to identify the sequence of messages in this consensus.
  • the sequence number can be densely increasing, for example, arranged like 1, 2, 3, 4, ..., n.
  • the Pre-prepare message initiated by the consensus master node contains a sequence number with a value of 3.
  • subsequent Prepare messages and Commit messages all contain the same sequence number with a value of 3. Therefore, after the end of this consensus, each consensus node can determine the order of the results of this consensus among the multiple consensus results before and after. This order can generally be used to determine the order in which consensus nodes execute consensus results and generate blocks.
  • the consensus node can arrange to execute or form a block after the consensus result with a sequence number value of 2. Subsequently, the consensus master node can increase the value of the sequence number by 1, that is, change it to 4, so as to initiate a Pre-prepare message with a sequence number of 4 in the next consensus. Correspondingly, in the subsequent Prepare message and Commit message, The value of sequence number is 4. Similarly, for the consensus result with a sequence number value of 4, the consensus node can arrange to execute or form a block after the consensus result with a sequence number value of 3. Subsequently, the consensus master node can increase the value of the sequence number by 1, that is, change it to 5, .... In this way, it can be guaranteed that each consensus node executes the same consensus result in the same order, thereby ensuring the consistency of blocks generated on each consensus node.
  • the relative position of the corresponding block on the blockchain is determined by means of a timestamp, and 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, so that the consensus result can be quickly output.
  • the timestamp is relatively loose, and does not have the dense increment feature of the sequence number, so the execution order of the blocks cannot be strictly guaranteed. For example, for a consensus node, it may have completed the consensus result with a time stamp of 80.5ms, the consensus result of 100.8ms and the consensus result of 135.2ms.
  • the relative execution order of these three consensus results can be determined by the time stamp block sequence, however, 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, the time stamp is Unsure. 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 generated Consistency of blocks. In order to ensure the consistency of blocks generated on each consensus node, each consensus node needs to execute the same consensus results in the same order. Therefore, a mechanism is needed to ensure that each consensus node executes the same consensus result in the same order.
  • each consensus node processes messages in a FIFO (First Input First Output) manner.
  • the first-in-first-out queue is a traditional sequential execution method, and the second instruction is executed after the instruction that enters first is completed first.
  • the sequential transmission of messages may also be guaranteed through the TCP protocol.
  • TCP provides reliable data transmission, avoiding retransmission of data packets, reverse sequence or even loss of data packets.
  • the consensus node can push the number of the message into the network transport layer every time it sends a message.
  • the network transport layer adopts the TCP protocol, and sends the TCP data packets converted by the upper layer protocol to the receiver in order, and waits for the receiver to confirm the TCP data packet within a specific period of time. If the consensus node does not receive an acknowledgment from the receiver within a specific time period, the TCP data packet is resent. If the receiver returns an acknowledgment to the TCP packet within a certain period of time, the consensus node sends the next TCP packet. This cycle continues until the sending of the upper layer protocol data is completed. Once the receiver receives all the TCP data packets of an upper-layer protocol message, it can perform a cyclic redundancy check (Cyclic Redundancy Check, CRC).
  • CRC Cyclic Redundancy Check
  • these data packets will be reorganized into a data stream in the correct order and passed to the upper layer.
  • the protocol is processed and the TCP data packet of the upper layer protocol with the next sequence number is sent.
  • Secure Sockets Layer Secure Sockets Layer
  • SSL Secure Sockets Layer
  • TLS Transport Layer Security
  • This application also provides an embodiment, which can be shown in Figure 12, including: S121: [First round] The first consensus node broadcasts the first message, which includes the transaction set proposed by the consensus, the timestamp and the first The signature of the consensus node; S123: [Second round] The consensus node that received the first message broadcasts the second message, the second message includes the vote and signature on the transaction set; the vote includes the transaction set S125: [Third round] After the consensus node receiving the second message collects at least Quorum unanimous votes from different consensus nodes, if it has not broadcast different votes for the proposal, it will broadcast the second Three messages, the third message includes the digest value and the collected signature set; S127: After the consensus node collects at least Quorum third messages from different nodes indicating that the vote is passed, the transaction set corresponding to the digest value Output as a consensus result sorted by said timestamp.
  • the first consensus node Node 0 can locally maintain a sequence of key moments ⁇ t 01 , t 02 ,... ⁇ , in the process of S121-S127, when a certain key moment t passes, Node 0 can broadcast a fourth message to indicate that it has passed this critical moment, as shown in FIG. 13 .
  • a fourth message is, for example, a Pass(t) message.
  • the message name Pass indicates that the message is a message indicating that a certain critical moment has passed, and the parameter t included therein is the critical moment.
  • Pass(t 02 ) is broadcast.
  • Node 1 can also locally maintain a key moment sequence ⁇ t 11 ,t 12 ,... ⁇ , in the process of S121-S127 (from a local point of view, it can also be in S121-S125 , which will not be repeated below), when a certain critical moment t passes, Node 1 can broadcast a fourth message to indicate that it has passed this critical moment, here, for example, Pass(t 12 ) is broadcast.
  • Node 2 is also similar. For example, it maintains a key moment sequence ⁇ t 21 , t 22 ,... ⁇ locally.
  • Node 2 can A fourth message is broadcast to indicate that the critical moment has passed.
  • Pass(t 24 ) is broadcast.
  • Node 3 is also similar. It maintains a time sequence ⁇ t 31 , t 32 ,... ⁇ locally.
  • Node 3 can broadcast a The fourth message is to indicate that the critical moment has passed.
  • Pass(t 33 ) is broadcast.
  • the above contents are shown in Figure 14 together.
  • the sequence of key moments shown in Figures 13 and 14 can be more dense or sparse, which is not limited here.
  • Consensus nodes participating in the consensus can each maintain the key moment sequence locally.
  • the key moment sequences maintained locally by the consensus nodes participating in the consensus can be the same, not exactly the same, or completely different.
  • Negotiate or synchronize For completely different situations, it can be determined by each node participating in the consensus according to the local clock, so that there is no need for a centralized method to send a sequence of critical moments for each node participating in the consensus, or by the nodes participating in the consensus.
  • each consensus node can be a centralized way to send a sequence of key moments for each node participating in the consensus, and then each consensus node adds a certain number of other key moments on this basis, or it can be negotiated between the nodes participating in the consensus Or synchronize part of the sequence of key moments, and then each consensus node adds a certain number of other key moments on this basis; of course, it is also possible for each node participating in the consensus to determine the sequence of key moments according to the local clock and then partially coincide.
  • the consensus node broadcasts the Pass(t) message. In addition to indicating that it has passed the critical moment t, it can also express a commitment. After the commitment, the vote for the proposal whose timestamp is less than the critical moment t is 0, or no longer process the time stamp. Consensus proposals before the critical moment t. In this way, after the consensus node collects at least Quorum Pass(t) messages (including its own latest broadcast Pass(t) message), it can obtain the key moments in these messages, such as at least Quorum of the fourth message. Minimal juncture.
  • the consensus node can confirm that at least Quorum consensus nodes have passed the critical moment t, so that it can vote for "the consensus proposal with the timestamp less than t will be voted as 0" or "no longer process the consensus proposal with the timestamp less than t" agree.
  • a FIFO-like effect can also be achieved indirectly by broadcasting the Pass message and executing according to the agreed content of the commitment.
  • the consensus proposal that has not been voted before the critical moment t may fail to pass the consensus, or may not be processed even if it passes the vote. ; If the consensus cannot be passed or not processed, the transaction set corresponding to the consensus proposal cannot be included in the block.
  • the latest Pass message is because the same node may successively broadcast a plurality of Pass messages at different critical moments. In this way, for receiving multiple Pass messages at different critical moments from the same node, the latest critical moment can be taken .
  • the above-mentioned broadcast Pass message can be completed with the participation of at least Quorum consensus nodes.
  • each consensus node broadcasts Pass messages, and any consensus node can receive at least (Quorum-1) Pass messages from other consensus nodes, plus the Pass messages broadcast by itself, and can collect at least Quorum of Pass messages information.
  • the consensus nodes participating in the consensus maintain the sequence of key moments locally, and the key moments 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 part of the key moment sequences locally, the key moments in the latest Pass message broadcast by each consensus node may be the same or different.
  • the consensus node receiving the Val message broadcasts a Bval message, and the Bval message includes the vote and signature for the transaction set proposed by the consensus in the first message.
  • the critical moment t is the timestamp in the Val message in this consensus, for example This timestamp is ts.
  • the Pass(ts) message can be broadcast to other consensus nodes.
  • any consensus node collects Pass(ts) of at least the number of Quorum, it can no longer process other consensus proposals with time stamps before the critical time ts or vote no for the consensus proposals before the critical time ts. pass.
  • time stamp of the Val message in other consensus times that is smaller than the ts, vote for Bval(0), and 0 often means failure in the voting of the consensus algorithm.
  • nodes of at least Quorum that its timestamp is later than the critical moment ts, so it votes for 0 in Bval(0), and the behind timestamp Consensus proposals will not be included in newly generated blocks.
  • the consensus nodes of Quorum can execute the consensus blocks corresponding to the ts in chronological order.
  • the said The transaction set corresponding to the summary value is output as the consensus result sorted by the timestamp. In this way, the order of completion of the consensus results can be guaranteed.
  • the consensus node receiving the second message collects at least Quorum unanimous votes from different consensus nodes, if it has not broadcast different votes for the proposal, it will broadcast the third message, the third message includes The digest value and the collected signature set; after the consensus node collects at least Quorum third messages from different nodes, it can output the transaction set corresponding to the digest value as the consensus result sorted by the timestamp.
  • the Pass message is broadcast in the third message without additionally broadcasting the fourth message, which can save the number of messages that need to be transmitted by the protocol.
  • the consensus node receiving the second message collects at least Quorum unanimous votes from different consensus nodes, if it has not broadcast different votes for the proposal, it will broadcast the third message, the third message includes all The digest value, the collected signature set and the key moment, the key moment is the timestamp in the first message.
  • the consensus node collects the third message from different nodes with at least Quorum quantity, it will no longer process other consensus proposals with timestamps before the critical moment or vote for consensus proposals before the critical moment. Fail.
  • the consensus node collects at least Quorum third messages from different nodes, it can also output the transaction set corresponding to the digest value as the consensus result sorted by the timestamp.
  • the above scheme can be called "cooperative mode", because such a scheme can complete the consensus quickly. Moreover, this method can directly rely on the timestamp in the first message that initiates the consensus proposal, without requiring the consensus node to maintain the key moment sequence locally, which reduces the implementation cost and complexity.
  • this application presents an embodiment of a "competition mode" consensus method, still referring to the embodiment in Figure 4-14 to illustrate the specific timing of sending the Pass message.
  • At least f+1 different consensus nodes may act as the first consensus node to initiate consensus proposals and broadcast Val messages.
  • each of at least f+1 different consensus nodes broadcasts the Val message as the first consensus node
  • at least 2f other consensus nodes cooperate to complete this consensus. In this way, the number of nodes participating in the consensus is 2f+1, reaching the number of Quorum.
  • Any node participating in the consensus confirms that there are f+1 consensus proposals proposed by different consensus nodes that are consensused as 1.
  • a stronger condition can be to confirm that there are f+1 consecutive consensus proposals proposed by different consensus nodes that are consensus is 1. The above is agreed to be 1, and the stronger condition can be that the output is the consensus result.
  • At least 2f+1 (Quorum) different consensus nodes may respectively serve as the first consensus node to initiate a consensus proposal and broadcast a Val message.
  • each of at least 2f+1 different consensus nodes acts as the first consensus node to broadcast the Val message
  • at least other 2f consensus nodes cooperate to complete this consensus. In this way, the number of nodes participating in the consensus is 2f+1, which also reaches the number of Quorum.
  • Any node participating in the consensus confirms that there are 2f+1 consensus proposals proposed by different consensus nodes that are consensused as 1.
  • a stronger condition can be to confirm that there are 2f+1 consecutive consensus proposals proposed by different consensus nodes that are consensus is 1.
  • the above is agreed to be 1, and the stronger condition can be that the output is the consensus result.
  • consensus nodes can switch between cooperative and competitive modes. Specifically, the consensus nodes can switch between the cooperation mode and the competition mode according to the historical consensus results.
  • the consensus node can switch to the competition mode after confirming that the first number of consensus proposals from different nodes are rejected by consensus.
  • the first number is f+1.
  • the consensus node can switch to the competition mode after confirming that there are f+1 consensus proposals from different nodes that are agreed to be rejected. It is confirmed that there are f+1 consensus proposals from different nodes that have been rejected by consensus, indicating that at least one consensus proposal proposed by a loyal node has been rejected by consensus, indicating that the previous model is more radical, or there are Byzantine nodes. Therefore, adjust to the competition mode and set the critical moment farther away from the current, so as to allow more consensus proposals to pass the consensus, but the side effect is that some consensus results may not be able to determine the order quickly. A stronger condition may be to confirm that there is a first number of consecutive consensus proposals from different nodes that are agreed to be rejected.
  • the consensus node can switch to the cooperation mode after confirming that there is a second number of consensus proposals from different nodes passing the consensus/output as the consensus result.
  • the second number is 2f+1 or Quorum.
  • the consensus node can switch to the cooperation mode after confirming that there are 2f+1 or Quorum of consensus proposals from different nodes that pass the consensus/output as the consensus result. It is confirmed that there are 2f+1 consensus proposals from different nodes that pass the consensus/output as the consensus result, indicating that the consensus proposals proposed by at least f+1 loyal nodes are passed by consensus, indicating that the previous model is relatively loose or does not exist Byzantine nodes.
  • the present application also provides an embodiment of a block chain system, including: the first consensus node broadcasts a first message, the first message includes the transaction set proposed by the consensus, the timestamp and the signature of the first consensus node; receiving the first consensus node The consensus node of the first message broadcasts the second message, which includes voting and signatures on the transaction set; the vote includes the summary value of the transaction set; the consensus node receiving the second message collects at least Quorum After unanimous votes from different consensus nodes, broadcast the fourth message to other consensus nodes; the fourth message includes the critical moment, which is the timestamp in the first message; any consensus node collects at least Quorum number from After the fourth message from a different node, other consensus proposals whose timestamps are before the critical moment are not processed or voted not to pass the consensus proposals before the critical moment.
  • the present application also provides an embodiment of a block chain system, including: the first consensus node broadcasts a first message, the first message includes the transaction set proposed by the consensus, the timestamp and the signature of the first consensus node; receiving the first consensus node The consensus node of the first message broadcasts the second message, which includes voting and signatures on the transaction set; the vote includes the summary value of the transaction set; the consensus node receiving the second message collects at least Quorum After unanimous votes from different consensus nodes, if they have not broadcast different votes for the proposal, then broadcast the third message, the third message includes the summary value, the collected signature set and the key moment, the key The moment is the timestamp in the first message; after any consensus node collects at least Quorum number of third messages from different nodes, it will no longer process other consensus proposals with timestamps before the critical moment or Consensus proposals before the critical moment are voted not to pass.
  • the present application also provides an embodiment of a block chain system, including: the first consensus node broadcasts a first message, the first message includes the transaction set proposed by the consensus, the timestamp and the signature of the first consensus node; receiving the first consensus node The consensus node of the first message broadcasts the second message, which includes voting and signatures on the transaction set; the vote includes the summary value of the transaction set; the consensus node receiving the second message collects at least Quorum After unanimous votes from different consensus nodes, if they have not broadcast different votes for the proposal, broadcast the third message, the third message includes the digest value and the collected signature set; After the consensus node collects at least Quorum unanimous votes from different consensus nodes, if it has not broadcast different votes for the proposal, it broadcasts a third message, which includes the digest value and the collected signature set ; After the consensus node collects at least Quorum third messages from different nodes indicating that the vote is passed, the transaction set corresponding to the summary value is output as the consensus result sorted by the timestamp; at least
  • the present application also provides an embodiment of a block chain system, including: the first consensus node broadcasts a first message, the first message includes the transaction set proposed by the consensus, the timestamp and the signature of the first consensus node; receiving the first consensus node The consensus node of the first message broadcasts the second message, which includes voting and signatures on the transaction set; the vote includes the summary value of the transaction set; the consensus node receiving the second message collects at least Quorum After unanimous votes from different consensus nodes, if they have not broadcast different votes for the proposal, broadcast the third message, the third message includes the digest value and the collected signature set; the consensus node collects at least Quorum After a third message from different nodes indicating that the vote is passed, the transaction set corresponding to the summary value is output as the consensus result sorted by the timestamp; the consensus node is based on the historical consensus results in the cooperation mode and Switch between competition modes, among them: cooperation mode: After the consensus node receiving the second message collects at least Quorum unanimous votes from different consensus nodes, it
  • the present application also provides an embodiment of a block chain system, including: the first consensus node broadcasts a first message, the first message includes the transaction set proposed by the consensus, the timestamp and the signature of the first consensus node; receiving the first consensus node The consensus node of the first message broadcasts the second message, which includes voting and signatures on the transaction set; the vote includes the summary value of the transaction set; the consensus node receiving the second message collects at least Quorum After unanimous votes from different consensus nodes, if they have not broadcast different votes for the proposal, then broadcast the third message, the third message includes the summary value, the collected signature set and the key moment, the key The time is the timestamp in the first message; the consensus node switches between the cooperation mode and the competition mode according to the historical consensus results, wherein: cooperation mode: any consensus node collects at least Quorum number from different nodes After the third message of , no other consensus proposals with timestamps before the critical moment will be processed or the consensus proposals before the critical moment will be voted not to pass; competition mode: at
  • the improvement of a technology can be clearly distinguished as an improvement in hardware (for example, improvements in circuit structures such as diodes, transistors, and switches) or improvements in software (improvement in method flow).
  • improvements in circuit structures such as diodes, transistors, and switches
  • improvements in software improvement in method flow
  • the improvement of many current method flows can be regarded as the direct improvement of the hardware circuit structure.
  • Designers almost always get the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be realized by hardware physical modules.
  • a programmable logic device Programmable Logic Device, PLD
  • PLD Programmable Logic Device
  • FPGA Field Programmable Gate Array
  • HDL Hardware Description Language
  • ABEL Advanced Boolean Expression Language
  • AHDL Altera Hardware Description Language
  • HDCal JHDL
  • Lava Lava
  • Lola MyHDL
  • PALASM RHDL
  • VHDL Very-High-Speed Integrated Circuit Hardware Description Language
  • Verilog Verilog
  • the controller may be implemented in any suitable way, for example the controller may take the form of a microprocessor or processor and a computer readable medium storing computer readable program code (such as software or firmware) executable by the (micro)processor , logic gates, switches, Application Specific Integrated Circuit (ASIC), programmable logic controllers, and embedded microcontrollers, examples of controllers include but are not limited to the following microcontrollers: ARC625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the control logic of the memory.
  • ASIC Application Specific Integrated Circuit
  • controller in addition to realizing the controller in a purely computer-readable program code mode, it is entirely possible to make the controller use logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded The same function can be realized in the form of a microcontroller or the like. Therefore, such a controller can be regarded as a hardware component, and the devices included in it for realizing various functions can also be regarded as structures within the hardware component. Or even, means for realizing various functions can be regarded as a structure within both a software module realizing a method and a hardware component.
  • the systems, devices, modules, or units described in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions.
  • a typical implementation device is a server system.
  • the computer that realizes the functions of the above embodiments can 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 , media players, navigation devices, email devices, game consoles, tablet computers, wearable devices, or any combination of these devices.
  • one or more embodiments of the present specification provide the operation steps of the method described in the embodiment or the flowchart, more or fewer operation steps may be included based on conventional or non-inventive means.
  • the sequence of steps enumerated in the embodiments is only one of the execution sequences of many steps, and does not represent the only execution sequence.
  • the methods shown in the embodiments or drawings can be executed sequentially or in parallel (such as a parallel processor or multi-thread processing environment, or even a distributed data processing environment).
  • These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture comprising instruction means, the instructions
  • the device realizes the function specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.
  • a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • Memory may include non-permanent storage in computer-readable media, in the form of random access memory (RAM) and/or nonvolatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer readable media.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash random access memory
  • Computer-readable media including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information.
  • 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 Disc (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 computing devices.
  • computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.
  • one or more embodiments of this specification 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 employ a computer program embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein. The form of the product.
  • program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
  • program modules may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.
  • program modules may be located in both local and remote computer storage media including storage devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Bioethics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Automation & Control Theory (AREA)
  • Databases & Information Systems (AREA)
  • Hardware Redundancy (AREA)

Abstract

一种共识方法和区块链系统。其中，该共识方法包括：第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，广播第四消息至其它共识节点；第四消息中包括关键时刻，其为第一消息中的时间戳；任一共识节点在收集到至少Quorum数量的来自于不同节点的第四消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。

Description

共识方法和区块链系统 技术领域
本说明书实施例属于区块链技术领域，尤其涉及一种共识方法和区块链系统。
背景技术
区块链(Blockchain)是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链系统中按照时间顺序将数据区块以顺序相连的方式组合成链式数据结构，并以密码学方式保证的不可篡改和不可伪造的分布式账本。由于区块链具有去中心化、信息不可篡改、自治性等特性，区块链也有着越来越多的应用。
发明内容
本发明的目的在于提供一种共识方法、区块链系统，包括：一种区块链系统中的共识方法实施例，包括：第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，广播第四消息至其它共识节点；第四消息中包括关键时刻，其为第一消息中的时间戳；任一共识节点在收集到至少Quorum数量的来自于不同节点的第四消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
一种区块链系统中的共识方法实施例，包括：第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值、收集到的签名集合和关键时刻，所述关键时刻为第一消息中的时间戳；任一共识节点在收集到至少Quorum数量的来自于不同节点的第三消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
通过上述实施例，可以较快的完成共识。
一种区块链系统中的共识方法，包括：第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值、收集到的签名集合；接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值以及收集到的签名集合；共识节点收集到至少Quorum个来自于不同节点的表示投票通过的第三消息后，将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出；至少f+1个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有f+1数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这f+1个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；或，至少Quorum个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有Quorum数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这Quorum个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
通过上述实施例，有利于保证整个系统是可用的，具有活性。
一种区块链系统中的共识方法实施例，包括：第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值以及收集到的签名集合；共识节点收集到至少Quorum个来自于不同节 点的表示投票通过的第三消息后，将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出；共识节点根据历史的共识结果情况在所述合作模式和竞争模式之间切换，其中：合作模式：接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，广播第四消息至其它共识节点；第四消息中包括关键时刻，其为第一消息中的时间戳；任一共识节点在收集到至少Quorum数量的来自于不同节点的第四消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；竞争模式：至少f+1个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有f+1数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这f+1个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；或，至少Quorum个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有Quorum数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这Quorum个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
一种区块链系统中的共识方法实施例，包括：第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值、收集到的签名集合和关键时刻，所述关键时刻为第一消息中的时间戳；共识节点根据历史的共识结果情况在所述合作模式和竞争模式之间切换，其中：合作模式：任一共识节点在收集到至少Quorum数量的来自于不同节点的第三消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；竞争模式：至少f+1个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有f+1数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这f+1个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；或，至少Quorum个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有Quorum数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这Quorum个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
附图说明
为了更清楚地说明本说明书实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1是一实施例中实用拜占庭容错算法常规阶段的示意图；
图2是一实施例中实用拜占庭容错算法视图切换阶段的示意图；
图3是一实施例中蜜獾拜占庭容错算法的示意图；
图4是本说明书一实施例中共识算法的流程图；
图5是本说明书一实施例中共识算法的示意图；
图6是本说明书一实施例中共识算法的示意图；
图7是本说明书一实施例中共识算法的示意图；
图8是本说明书一实施例中共识算法的示意图；
图9是本说明书一实施例中共识算法的示意图；
图10是本说明书一实施例中共识算法的示意图；
图11是本说明书一实施例中共识节点分布图；
图12是本说明书一实施例中共识方法的流程图；
图13是本说明书一实施例中共识方法的示意图；
图14是本说明书一实施例中共识方法的示意图。
具体实施方式
为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本说明书保护的范围。
区块链系统中，不同参与方通过部署的节点(Node)可以建立一个分布式的区块链网络。利用链式区块结构构造的去中心化(或称为多中心化)的分布式账本，保存于分布式的区块链网络中的每个节点(或大多节点上，如共识节点)上。这样的区块链系统需要解决去中心化(或多中心化)的多个节点上各自的账本数据的一致性和正确性的问题。每个节点上都运行着区块链程序，在一定容错需求的设计下，通过共识(consensus)机制保证所有忠诚节点具有相同的交易，从而保证所有忠诚节点对相同交易的执行结果一致，并将交易及执行结果打包生成区块。当前主流的共识机制包括：工作量证明(Proof of Work，POW)、股权证明(Proof of Stake，POS)、委任权益证明(Delegated Proof of Stake，DPOS)、实用拜占庭容错(Practical Byzantine Fault Tolerance，PBFT)算法，蜜獾拜占庭容错(HoneyBadgerBFT)算法等。
以PBFT为例，该算法是Miguel Castro(卡斯特罗)和Barbara Liskov(利斯科夫)在1999年提出来的，解决了原始拜占庭容错算法效率不高的问题，将算法复杂度由指数级降低到多项式级，使得拜占庭容错算法在实际系统应用中变得可行。该论文发表在1999年的操作系统设计与实现国际会议上(OSDI99)。PBFT算法中，所有的副本(replica)在一个被称为视图(View)的轮换过程(succession of configuration)中运行。在某个视图中，一个副本作为主节点(primary)，其他的副本作为备份节点(backups)。视图是连续编号的整数。主节点由公式p＝v mod|R|计算得到，这里v是视图编号，p是副本编号，|R|是副本集合的个数。该算法中假设，当最多存在f个副本(即节点)失效时，如果存在总数为至少3f+1个副本，就能保证在异步系统中提供安全性和活性。为了能够确保所有副本的数据一致性要求和容错要求，需要的一定数量副本的集合，一般是分布式系统中的大多数节点构成的集合，构成大多数(Quorum)。例如在总节点数n为3f+1(n＝3f+2或n＝3f的情况一般不会对容错效果带来提升)的情况下，Quorum为2f+1。这样，对于包含四个节点的分布式系统，任意三个节点可以构成一个Quorum。
PBFT包括Normal Case Phase和View Change Phase两个过程，图1为Normal Case Phase(常规阶段)过程的流程图。Normal Case Phase中主要包括PRE-PREPARE(预准备)、PREPARE(准备)和COMMIT(提交)三个阶段，其中3号节点例如可以表示宕机的节点(图1中以×表示)。当主节点失效的时候(图2中以×表示，如更换视图前主节点Primary也就是Replica 0(副本0)失效)就需要启动视图更换(view change)过程，从而在系统存在故障时进行状态调整，更换新的主节点(如更换视图后Replica 1为主节点Primary)。图2为View Change Phase(视图切换)的示意图。如果主节点掉线或者作恶而不广播客户端的请求等，客户端可以设置超时机制。如果超时的话，客户端可以向所有副本节点广播请求消息。副本节点检测出主节点作恶或者下线后，也可以发起View Change协议阶段，以更换主节点(经常简称为“换主”)。此外，也可能由于主节点发起错误的提议导致PRE-PREPARE、PREPARE和COMMIT三阶段共识过程失败，或者，PREPARE、COMMIT阶段可能达不成Quorum数量(如3f+1个节点中的2f+1个，也称为法定数量)的一致，也都无法完成共识。这些情况下也可能发起View Change协议阶段，以更换主节点。
PBFT协议属于半同步(partial synchronous)协议，其特点是假设网络一开始是异步的，但是能够从某一时刻开始同步。要在网络中让不同节点对同一提议达成共识，最简便的方式是设置主节点，由主节点来统一各个节点的意见。通过设置定时器，可以防止主节点出错。PBFT中，如果在有限时间内没有完成Normal Case Phase，会触发Backups发起View Change Phase，以更换主节点。PBFT将主节点固定在一个位置，所有请求都可以先发送到主节点，再由主节点广播到其他共识节点。除了引入额外的、将请求发送到主节点的延迟之外，主节点的出入口带宽也可能成为性能瓶颈。
PBFT这类单主节点类型的协议，在同一次共识中只有主节点能够发起共识提议，其它节点没有能力发起共识提议。或者，如果其它节点也有提议，就需要将提议转发至主节点，由主节点代为发起提议。前者对于共识节点构造区块的权力是不公平的，后者虽然备份节点也可以提议，但是会增加主节点出口带宽的压力。对于大多共识节点都需要发起共识提议的情况，两者都不是特别适合。
与此相对的，HoneyBadgerBFT(也常简称为HBBFT)算法属于一种异步(asynchronous)协议。异步协议适用于异步网络，也就是这个网络中节点间的消息可以被任意延迟，但最终会到达。HoneyBadgerBFT中去掉了定时器，而是通过消息来驱动协议的执行。同时，HoneyBadgerBFT算法中所有节点都是对等的，没有主节点和备份节点之分，也就没有换主的过程。HBBFT等异步网络共识协议无主节点的概念，各节点都可提议请求，尝试构造区块，因此异步网络协议在一定程度上缓解了公平性和单节点瓶颈的问题。
图3为HoneyBadgerBFT算法单节点角度的流程图。实际上，如前所述，HoneyBadgerBFT算法中所有节点都是对等的，也就是说，所有节点都可以执行图3所示的流程。如图3所示，从单节点的视角来看，HoneyBadgerBFT主要包括两个阶段，分别为可靠广播(Reliable BroadCast,RBC)和异步共识(Asynchronous Binary Agreement,ABA，异步二进制协议，也称为“01异步共识”)。此外，还有RBC和ABA之上的异步公共子集(Asynchronous Common Subset，ACS)协议。RBC阶段至少包括Rval、Echo、Ready三轮消息交互，ABA阶段至少包括Bval、Aux和Coin三轮消息交互。RBC使用三轮消息交互保证可靠的提议广播。ABA首先进行两轮投票(Bval和AUX消息)，然后借助抛硬币(Coin)对各节点的提议统一认识，从而绕开半同步协议对网络同步的要求。一次HoneyBadgerBFT共识，要经过RBC阶段和至少一次ABA阶段。最好的情况下，存在1/2的概率可以结束本次HoneyBadgerBFT共识过程，这样，需要经过6个轮次完成一次共识。此外，有1/4概率会进入再一次的ABA过程，如图3中第二次ABA过程(7、8、9轮次表示的ABA过程)，有1/4概率会在第二轮结束，且存在至少1/4的概率可以结束本次HoneyBadgerBFT共识过程，这样，需要经过9个轮次完成一次共识。在第二次ABA过程后，整体上有1/8的概率会进入再一次的ABA过程……以此类推。
综上所述，HoneyBadgerBFT至少包括一次RBC(三轮)和一次ABA(三轮)，如果ABA的投票结果与抛币结果不一致，协议进入新一轮的ABA(至少额外三轮)。抛币给共识的轮次带来不确定性，可能增加延迟。
另外，对于一个最终生成的区块(对应一个epoch)来说，一个节点可以运行一个ACS和n个RBC+n个ABA，n为共识节点个数，且其中1个RBC和ABA对应自身发起的共识提议，其它(n-1)个RBC和ABA对应其它(n-1)个节点发起的共识提议。也就是说，对于一个epoch来说，一个节点发起共识提议的同时，也会配合完成其它节点发起的共识提议。这样，对于一个节点来说，至少(n-f)个RBC结束后会将这些RBC已经完成的情况(通过Ready消息表示)发至ACS，进而由ACS为对应的ABA赋初值，启动对应的ABA过程。在至少(n-f)个共识提议完成ABA之后如果剩余的共识提议仍未完成RBC，则会被赋初值为0，进而执行该提议对应的ABA过程。从全局的视角来看，至少(n-f)个节点会执行相同的上述共识过程(至少(n-f)个不同节点发起提议的过程)，并最终由ACS来收集各个提议的ABA结果后按照某种规则对ABA结果为1的提议排序后输出。
上述的过程中，与PBFT相反的，对各个参与共识的节点提出了较强的提议要求，即参与共识的节点需要在每一个epoch中都发起提议，不论这个节点是否真的有提议。如果这个节点实际上没有提议，也需要发起一个内容为空的提议请求(RBC中可以对这个空的提议请求加密，这样其他节点并不能确定这个提议的内容，以避免恶意节点因能看到提议中的内容而有选择的在BA过程中赋值输入或输出)。即使这个节点是失效节点，无法发出提议，那么在其他节点的ACS中仍然要给这个节点对应的提议留出位置。具体的，在其他节点中的每一个执行完至少Quorum个ABA且均共识为1后，如果还没有收到这个节点的提议对应RBC阶段的Quorum个Ready消息，ACS需要给这个节点的提议对应的ABA初值赋为0，进而进入ABA过程。这样，其它节点还需要配合完成这个失效节点对应提议的ABA过程。
本申请提供一种共识算法实施例，如图4所示，具体包括：S41：【第一轮】第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名。
本申请一种共识算法实施例中，可以包括3轮的交互。与HBBFT类似的，图5所示实施例的共识算法，也属于一种异步协议，即假设网络中节点间的消息可以被任意延迟，但最终会到达。类似的，图5实施例中也去掉了定时器，通过消息来驱动协议的执行；同时，所有节点可以都是对等的，没有主节点和备份节点之分，任一共识节点都可以发起共识提议，每一个共识节点也都可以参与其他节点提起共识提议的共识过程。一次共识的结果，可以包括本次共识中所有节点提起且获得至少Quorum数量投票一致的共识提议中的交易集合的总和。
以一个节点的视角来看，例如以Node 0发起共识提议的视角来看，交互过程如图5所示。在一次共识中，Node 0可以发起共识提议，这个共识提议中可以包括打包的交易集合，例如标记为m 0，m 0中可以包括一系列的交易构成的集合{tx 01，tx 02，…，tx 0n}。进而，Node 0可以广播第一消息至其它共识节点，如图5中广播至Node 1、Node 2和Node 3。广播的第一消息中可以包括Node 0的共识提议的交易集合m 0。这个消息可以称为Val消息。
此外，这个消息还可以包括第一共识节点对m 0的签名，例如记为sig 00。一般地，第一共识节点Node 0可以用自身的私钥对m 0直接签名，得到sig 00，也可以是先对m 0进行hash计算，得到hash值(即摘要值)，进而再用自身的私钥对该hash值签名，从而得到sig 00，还可以是用自身的私钥对m 0和ts 0在内的数据直接进行签名或对m 0和ts 0在内的数据的hash值进行签名。
第一消息中还可以包括时间戳。这个时间戳可以是第一共识节点广播第一消息时或之前的物理时间，可以由本地时钟确定。如果区块链网络中的各个共识节点能够做到相对准确的时钟同步，第一消息中的时间戳也是接收到该第一消息的节点中相对准确的时间。
考虑到节点之间可能存在一定的物理距离，因此消息的传播存在不可忽略的延迟，因此，第一消息中包括的时间戳，可以基于第一共识节点广播第一消息时或之前的物理时间以及网络传输时延确定。例如在一个包括4个共识节点的区块链网络中，第一共识节点到其它三个共识节点的平均传输时延或最大传输时延为Δ，则第一消息中的时间戳为ts 0＝t 0+Δ，其中t 0可以是第一共识节点广播第一消息的本地物理时间。这个Δ可以由RTT(Round-Trip Time，往返时延)来确定，RTT一般可以表示网络中从一个发送端发送数据至接收端开始，到该发送端收到来自该接收端的确认总共经历的时间。一般的，Δ可以是RTT的一半。对于第一共识节点与其它三个共识节点之间的RTT不同的情况，可以取三个Δ的平均值，或者取三个Δ的最大值，具体如
Figure PCTCN2022124131-appb-000001
或者Δ＝max(Δ 1，Δ 2，Δ 3)。
Val消息的格式可以如<ts 0,m 0,sig 00>，其中ts 0可以表示Node 0发起共识提议的时间戳，m 0可以表示共识提议中的交易集合。所述sig 00，可以是Node 0采用自身私钥对包括ts 0和m 0在内的数据的签名，也可以是先对m 0进行hash计算，得到hash值，进而再用自身的私钥对该hash值和ts 0在内的数据进行签名，从而得到sig 00，还可以是用自身的私钥对m 0和ts 0在内的数据直接进行签名或对m 0和ts 0在内的数据的hash值进行签名。
S43：【第二轮】接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合m 0的摘要值。
在第一轮的末尾，接收到第一消息的共识节点可以验证接收到的第一消息的正确性。例如，Node 1可以采用Node 0的公钥对第一消息中的Node 0的签名进行验证。如果通过验证，则进入S43。
S43，具体如图5中，接收到第一消息的共识节点可以广播第二消息。第二轮次的消息交互中，Node 1、Node 2、Node 3各自分别广播第二消息至其它共识节点。共识节点广播的第二消息中，可以包括对Node 0发起的共识提议的投票。
例如，Node 1、Node 2、Node 3可以通过广播第二消息来告诉其他共识节点自身对共识提议的投票，投票可以是对共识提议中的消息集合表示认可或者不认可。具体的，在第一轮的末尾，收到Val消息的共识节点，可以计算Val消息中共识提议的交易集合的hash值。进而，如果共识节点认可该次共识中Node 0提议的交易集合，可以在第2轮次的消息交互中广播该hash值。相反的，如果共识节点不认可该次共识中Node 0提议的交易集合，可以在第2轮次的消息交互中广播0。这个广播的第二消息可以记为Bval。此外，也可以是在第2轮次的消息交互中广播该hash值的同时，用1来表示对该hash值代表的提议投票认可或通过，用0来表示对该hash值代表的提议投票不认可或不通过，这只是简单的变化。
本轮次中，Node 0可以不参与广播，这是因为Node 0在第一轮次中发起共识提议，本身即可以代表Node 0对共识提议中的消息集合是认可的，从而第二轮次中可以由Node 1、Node 2、Node 3分别广播第二消息至其它共识节点。
需要说明的是，共识节点可以更改自己的观点并再次投票，即发出多个不同的Bval消息。例如，Node 1可以首次发出内容是所述交易集合的hash值的Bval消息，以表示对所述共识提议中的交易集合的认可，而后续可以再次发送内容是0的Bval消息，以表示对所述共识提议中的交易集合的不认可。再例如，Node 2可以首次发出内容是0的Bval消息，以表示对所述共识提议中的交易集合的不认可，而后续可以再次发出内容是所述交易集合的hash值的Bval消息，以表示对所述共识提议中的交易集合的认可。
此外，第二消息中还可以包括对所述交易集合的签名。前述提到，在第一轮的末尾接收到第一消息的共识节点可以验证接收到的第一消息的正确性，例如Node 1验证Node 0的签名是否正确。进而，接收到第一消息的共识节点，可以用自己的私钥对第一消息中的交易集合进行签名。例如Node 1对第一消息中的交易集合m 0进行签名，得到sig 10；也可以是Node 1先对m 0的hash值签名，从而得到sig 10。
类似的，Bval消息的格式可以如<ts 0,hash,sig 10>，其中ts 0可以是收到的Val消息中的ts 0，hash为m 0的hash值，表示对m 0的投票观点是认同。则所述sig 10，也可以是采用自身私钥对包括ts 0和m 0在内的数据的签名。类似的，也可以是对m 0的hash值和ts 0在内的数据进行签名，从而得到sig 10，还可以是用自身的私钥对ts 0和hash在内的数据的hash值进行签名。
Node 2收到Node 0发来的Val消息后，类似的，也可以计算Val消息中的m 0的hash值，并采用自身私钥对该hash值签名得到sig 20，进而也可以广播Bval消息。Bval消息中可以包括计算得到的hash值以及签名sig 20，也可以是包括ts 0、hash值以及签名sig 20。
Node 3收到Node 0发来的Val消息后，类似的，也可以计算Val消息中的m 0的hash值，并采用自身私钥对该hash值签名得到sig 30，进而也可以广播Bval消息。Bval消息中可以包括计算得到的hash值以及签名sig 30，也可以是包括ts 0、hash值以及签名sig 20。
S45：【第三轮】接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值以及收集到的签名。
第二轮中的共识节点广播第二消息，这样，在第二轮的末尾，接收到第二消息的共识节点可以收集第二消息中的投票，进而广播第三消息。
例如Node 0，在第二轮的末尾可以收集Bval消息中的投票。假设Node 0收集到Node 1，Node 2、Node 3分别广播的Bval消息中的投票都是所述交易集合m 0的hash值，且Node 0在第一轮中广播的Val消息中也是m 0，其对应的hash显然也是m 0的hash值，则Node 0在本轮次中收集到至少Quorum个一致的摘要值(例如此时f＝1，Quorum＝3，实际收集到4)。
例如Node 1，在第二轮的末尾可以收集Bval消息中的投票，假设Node 1收集到Node 2、Node 3分别广播的第二消息中的投票都是所述交易集合m 0的hash值，且Node 1在第二轮中广播的第二消息中的投票如果也是所述交易集合m 0的hash值(也表示对所述交易集合的认可)，且在第一轮中接收到的Node 0发出的Val消息中的m 0也是同样的hash值，则Node 1在本轮次中收集到至少Quorum个一致的摘要值(例如此时f＝1，Quorum＝3，实际收集到4)。需要说明的是，第一轮中，Node 0广播的Val消息中可以包括m 0，这样在第一轮的末尾Node 1可以计算Val消息中包括的m 0的hash值，从而可以统计与第二轮中Node 1广播的Bval消息中的m 0的hash值是否相同，以及是否与第二轮中接收到的Node 2和Node 3发来的m 0的hash值是否相同，进而得出是否收集到至少Quorum个来自于不同共识节点的一致的hash值。
Node 2和Node 3与Node 1类似，不再赘述。
此外，共识节点还可以在第二轮末尾收集到不同节点的签名，如前所述。通过签名可以统计第二轮中收集到的投票的数量。例如Node 1收集到分别有sig 10、sig 20、sig 30签名的同一hash值，则说明对该hash共有3个表示认可的投票。当然，也可以通过共识节点之间建立的安全传输通道来确定消息的唯一性，进而确定消息的数量。所述安全传输通道例如通过消息认证码(Message Authentication Code，MAC)、安全传输层协议(Transport Layer  Security，TTL)之类的技术创建。
对于Node 1，如果收集到至少Quorum个来自于不同共识节点的一致的hash值，且自身针对该提议m 0没有广播过0(即不同的投票)，则广播第三消息。第三消息可以记为Prom消息，意思是承诺不会对提议m 0更改观点。如前所述，m 0的hash值可以表示认可，0可以表示不认可。Node 1针对该提议m 0没有广播过0，是指没有对提议m 0持有过不认可的观点，当然也可以用0以外的其它形式表示这种不认可。Node 2和Node 3也是类似的。
广播的第三消息中，可以包括收集到的对m 0的投票，例如上述第一轮和第二轮中收集到的hash值和签名。
Prom消息的格式可以如<ts 0,hash,<签名集合>>。
例如Node 0，假设Node 0在第二轮中收集到Node 1，Node 2、Node 3分别广播的Bval消息中的投票都是所述交易集合m 0的hash值，这样也就收集到Node 1、Node 2和Node 3各自分别对m 0(或m 0的hash值)的签名是sig 10、sig 20、sig 30的投票，且Node 0在第一轮中广播的Val消息中也包括自身对m 0(或m 0的hash值)的签名为sig 00的hash值。这样，Node 0在本轮次中收集到至少Quorum个一致的摘要值(例如此时Quorum＝3)。进而，Node 0在第三轮中广播的Prom消息中，可以包括该hash值以及收集到的不同节点针对该提议的交易集合m 0表示认可的hash值及签名集合，签名集合例如为sig 00、sig 10、sig 20、sig 30。
例如，假设Node 1在第二轮中收集到Node 2、Node 3分别广播的Bval消息中的投票都是所述交易集合m 0的hash值，这样也就收集到Node 2和Node 3各自分别对m 0(或m 0的hash值)的签名是sig 20、sig 30的投票，且Node 0在第一轮中广播的Val消息中也包括其对m 0(或m 0的hash值)的签名是sig 00的投票，且Node 1在第二轮中广播的Bval消息中也包括其对m 0(或m 0的hash值)的签名是sig 10的投票。这样，Node 1在第一轮和第二轮中收集到至少Quorum个一致的摘要值(例如此时Quorum＝3)和不同节点的签名。进而，Node 1在第三轮中广播的Prom消息中，可以包括该hash值以及收集到的不同节点针对该提议的交易集合m 0表示认可的hash值及签名集合，签名集合例如包括sig 00、sig 10、sig 20、sig 30。
Node 2和Node 3也类似于Node 1。
需要说明的是，上述签名集合，也可以用聚合签名或门限签名替代。
S47：共识节点收集到至少Quorum个来自于不同节点的第三消息后，将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出。
第三轮执行后，接收到Prom消息的共识节点可以统计收集的Prom消息的数量。共识节点在第三轮中发出Prom消息的条件是第二轮中收集到至少Quorum个来自于不同共识节点的一致的投票，且自身针对该提议没有广播过不同的投票，即相当于第二轮末尾该共识节点确认总计至少Quorum数量的共识节点(包括自身)对该提议m 0的投票都是认同的。但是，第二轮结束之后还不能马上输出共识结果，而是还需要观察其他节点是否也是在第二轮末尾收集到至少Quorum数量的对提议m 0的表示认同的投票，因此需要通过第三轮的Prom消息来确认，并且通过该Prom消息承诺自身不会再针对同一提议m 0的表示不同的观点。
例如Node 0在第一轮和第二轮中收集到至少Quorum个一致的摘要值，进而，Node 0在第三轮中广播的Prom消息中，可以包括该hash值以及收集到的不同节点针对该提议的交易集合m 0表示认可的hash值及签名集合，签名集合例如包括sig 00、sig 10、sig 20、sig 30。
例如Node 1在第一轮和第二轮中收集到至少Quorum个一致的摘要值，进而，Node 1在第三轮中广播的Prom消息中，可以包括该hash值以及收集到的不同节点针对该提议的交易集合m 0表示认可的hash值及签名集合，签名集合例如包括sig 00、sig 10、sig 20、sig 30。
Node 2和Node 3也类似于Node 1。
这样，通过第三轮，例如Node 0可以收集到至少Quorum个Prom消息。通过至少Quorum个Prom消息，Node 0可以确认至少Quorum个共识节点中的每一个都收集到了对该提议的交易集合m 0表示认可的至少Quorum数量的投票，且发出Prom消息的每一个共识节点都承诺不再会更改投票的观点，这样，Node 0可以进一步完成本次共识。
上述实施例中，首先，可以在一定前提下缩短至3个轮次完成一次共识，相对于HBBFT 中的至少6轮，大大降低了共识过程带来的延迟。实际上，本申请实施例中，相当于采用前瞻投票和数字签名技术将HBBFT中RBC过程的后两轮和ABA过程的前两轮进行了合并，从而缩短了所需的轮次。所述前瞻投票，是指上述实施例中第二轮次的Bval中进行投票，而HBBFT在ABA过程中需要在第四轮次的Bval中才投票。所述数字签名，指上述实施例中第一轮次和第二轮次中采用的数字签名。
此外，上述的m 0，如前所述，可以对应ts 0。实际上，Node 0可以并行或先后发起两个不同的第一消息。例如，Node 0在发起m 0(对应hash 0)的上述三轮过程中，可以并行或在前/在后发起m 4(对应hash 4)的上述三轮过程。假设m 4对应ts 4，ts 4＞ts 0。则发起共识提议的节点Node 0和参与共识的节点Node 1、Node 2和Node 3在输出共识结果时，可以按照时间戳的先后顺序排序，这样，共识结果m 0排在m 4之前。相应的，最终生成的m 0对应的区块，其区块高度小于m 4对应的区块。
所述区块链系统中的至少Quorum数量的共识节点中的每一个，都可以作为第一共识节点执行上述第一轮至第三轮的过程。例如，上述图5的实施例，可以扩展到由Node 0、Node 1、Node 2和Node 3均执行。Node 1、Node 2和Node 3各自分别作为第一共识节点执行，也可以如图6、7、8中所示。这样，从整体的视角来看可以是图5、6、7、8的叠加。其中，例如Node 0发起共识提议的交易集合为m 0且时间戳为ts 0，Node 1发起共识提议的交易集合为m 1且时间戳为ts 1、Node 2发起共识提议的交易集合为m 2且时间戳为ts 2，Node 3发起共识提议的交易集合为m 3且时间戳为ts 3，这样，m 0可以对应hash 0，m 1可以对应hash 1，m 2可以对应hash 2，m 3可以对应hash 3。假设ts 3＞ts 1＞ts 2＞ts 0，则Node 0、Node 1、Node 2和Node 3各自本地的共识结果均为m 0、m 2、m 1、m 3，即按照时间戳排序的结果。m 0、m 2、m 1、m 3可以分别对应一个最终的区块。上述排序，可以由共识节点的ACS协议收集共识结果后进行。具体的，ACS可以收集各个共识提议的结果后按照各个共识提议的时间戳来排序共识结果并输出。
按照考虑传输时延的时间戳排序，充分考虑了共识结束的时间，即尽可能的将生成区块的顺序与共识结果的完成顺序保持一致。
这样，通过上述方式，可以在共识提议被提出时即确定对应的区块在区块链上的相对位置。而且，对于一个最终生成的区块来说，其包含一个共识提议，即对应一个共识结果的产生过程，则该共识结果不需要等待其它共识提议的结果，能够快速输出共识结果。这也就省去了在一个共识结果的生成过程中需要等待、配合其它共识提议的共识完成。对于没有提议的共识节点，也不必提出内容实际为空的共识提议，降低了网络带宽的消耗。对于无法提出共识提议的失效节点，上述实施例中只要正常工作的节点达到Quorum数量，则生成共识结果的过程并不需要HBBFT中那样超时赋值为0后再进入ABA过程，而是可以跳过该失效节点，从而可以大大降低共识的时延。
本申请实施例中，与PBFT和HBBFT类似，可以容忍一定数量的错误节点，例如是总数n为3f+1的共识节点中可以容错f个错误节点，Quorum为2f+1。以下给出一个存在f(f＝1)个失效节点的例子。
例如，如图9和图10叠加的情况，假设Node 3为失效节点。
如图9所示：第一轮中，Node 0广播Val消息，Val消息的格式可以如<ts 0,m 0,sig 00>，其中ts 0可以表示Node 0发起共识提议的时间戳，m 0可以表示共识提议中的交易集合。所述sig 00，可以是Node 0采用自身私钥对包括ts 0和m 0在内的数据的签名，也可以是先对m 0进行hash计算，得到hash值，进而再用自身的私钥对该hash值和ts 0在内的数据进行签名，从而得到sig 00，还可以是用自身的私钥对m 0和ts 0在内的数据直接进行签名或对m 0和ts 0在内的数据的hash值进行签名。
第一轮的末尾，接收到Val消息的共识节点可以验证接收到的Val消息的正确性。具体的，Node 1可以采用Node 0的公钥对第一消息中的Node 0的签名sig 00进行验证，如果通过验证，则进入第二轮。类似的，Node 2可以采用Node 0的公钥对第一消息中的Node 0的签名sig 00进行验证，如果通过验证，则进入第二轮。而Node 3为失效节点。
第二轮中，接收到所述Val消息的共识节点广播Bval消息，Bval消息中包括对所述交易集合m 0的投票和签名；所述投票包括所述交易集合m 0的hash值。由于Node 3是失效节点，因此不响应，即不会广播Bval消息，而由Node 1、Node 2分别广播Bval消息至其它共 识节点。Node 1广播的Bval消息例如包括m 0的hash值和Node 1采用自身的私钥对m 0的hash值的签名sig 10。此外，Bval消息也可以是如<ts 0,hash,sig 10>，则其中的sig 10可以是Node 1用自身私钥对包括ts 0和m 0的hash值在内的数据的签名。
Node 2收到Node 0发来的Val消息后，类似的，也可以计算Val消息中的m 0的hash值，并采用自身私钥对该hash值和ts 0签名得到sig 20，进而也可以广播Bval消息。
第二轮的末尾，接收到Bval消息的共识节点可以收集Bval中的投票。对于Node 0，在第二轮的末尾收集Bval消息中的投票，收集到Node 1，Node 2分别广播的Bval消息中的投票都包括所述交易集合m 0的hash值，且Node 0在第一轮中广播的Val消息中也是m 0，其对应的hash也是m 0的hash值，且Node 1，Node 2分别广播的Bval消息中包括各自的签名sig 10和sig 20，Node 0在第一轮中广播的Val消息中也包括签名sig 00，则Node 0在第二轮末尾收集到总计3个一致的hash值(此时f＝1，Quorum＝3)。对于Node 1，在第二轮的末尾收集Node 2广播的Bval消息中的投票是m 0的hash值和sig 20，且Node 1在第二轮中广播的Bval消息中的投票也是hash值及sig 10，且在第一轮中接收到的Node 0发出的Val消息中的m 0也是同样的hash值以及sig 00，则Node 1在本轮次中收集到3个一致的hash值，满足Quorum数量。对于Node 2，在第二轮的末尾收集Node 1广播的Bval消息中的投票是m 0的hash值和sig 10，且Node 2在第二轮中广播的Bval消息中的投票也是hash值及sig 20，且在第一轮中接收到的Node 0发出的Val消息中的m 0也是同样的hash值以及sig 00，则Node 2在本轮次中收集到3个一致的hash值，满足Quorum数量。
第三轮中，接收到Bval消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的hash值后，如果自身针对该提议没有广播过0，则广播Prom消息，Prom消息包括所述hash值以及收集到的签名。
例如，Node 0在第三轮中广播的Prom消息中，可以包括该hash值以及收集到的不同节点针对该提议的交易集合m 0表示认可的hash值及签名集合，签名集合为sig 00、sig 10、sig 20。Node 1在第三轮中广播的Prom消息中，可以包括该hash值以及收集到的不同节点针对该提议的交易集合m 0表示认可的hash值及签名集合，签名集合也是sig 00、sig 10、sig 20。Node 20在第三轮中广播的Prom消息中，可以包括该hash值以及收集到的不同节点针对该提议的交易集合m 0表示认可的hash值及签名集合，签名集合也是sig 00、sig 10、sig 20。
第三轮执行后，接收到Prom消息的共识节点统计收集的Prom消息的数量，如果收集到至少Quorum个来自于不同节点的Prom消息后，将所述hash值对应的交易集合m 0作为共识结果输出。
对于Node 0，在第三轮结束后收集到Node 1和Node 2广播的Prom消息，且自身也广播过Prom消息，因此总计收集到3个Prom消息。
类似的对于Node 1，在第三轮结束后收集到Node 0和Node 2广播的Prom消息，且自身也广播过Prom消息，因此总计收集到3个Prom消息。
类似的对于Node 2，在第三轮结束后收集到Node 0和Node 1广播的Prom消息，且自身也广播过Prom消息，因此总计收集到3个Prom消息。
通过第三轮，Node 0收集到3个Prom，可以确认至少3个共识节点中的每一个(满足Quorum)都收集到了对该提议的交易集合m 0表示认可的至少3个投票(满足Quorum)，且发出Prom消息的每一个共识节点都承诺不再会更改投票的观点，这样，Node 0可以进一步完成本次共识，即将所述hash值对应的交易集合m 0作为共识结果输出。Node 1、Node 2也类似，即Node 1、Node 2也将所述hash值对应的交易集合m 0作为共识结果输出。
类似的，如图10所示过程，Node 2广播Val消息，Val消息的格式可以如<ts 2,m 2,sig 22>，最终Node 2将交易集合m 2作为共识结果输出。Node 0、Node 1也类似，即Node 0、Node 1也将交易集合m 2作为共识结果输出。
假设m 0的时间戳为ts 0，m 2的时间戳为ts 2，且ts 2＞ts 0，则Node 0、Node 1和Node 2各自在本地都产生两个共识结果。每个共识节点都可以按照时间戳对这两个共识结果排序，则排序结果为m 0、m 2，对于最终生成的两个区块来说，m 0对应的区块的区块高度较小，m 2对应的区块的区块高度较大。
在上述实施例中，在共识提议被提出时即确定对应的区块在区块链上的相对位置。而 且，对于一个最终生成的区块来说，其包含一个共识提议，即对应一个共识结果的产生过程，则该共识结果不需要等待其它共识提议的结果，能够快速输出共识结果。这也就省去了在一个共识结果的生成过程中需要等待、配合其它共识提议的共识完成。对于没有提议的共识节点，也不必提出内容实际为空的共识提议，降低了网络带宽的消耗。对于无法提出共识提议的失效节点，上述实施例中只要正常工作的节点达到Quorum数量，则生成共识结果的过程并不需要HBBFT中那样超时赋值为0后再进入ABA过程，而是可以跳过该失效节点，从而可以大大降低共识的时延。
在实际的区块链应用中，上述实施例针对特定的情形有更为重要的意义。如图11所示，例如组成一个联盟链的4个节点分别部署于不同的国家，Node UK位于英国，Node DE位于德国，Node FR位于法国，Node CN位于中国。显然的，位于欧洲的Node UK，Node DE和Node FR三个节点之间的通信时延较小，而这三个节点与位于亚洲的Node CN通信时延较大。假设Node UK，Node DE和Node FR三个节点之间的通信时延均为10ms，这三个欧洲节点与Node CN的通信时延均为80ms。如果采用HBBFT，这4个节点中位于欧洲的3个节点即可以构成Quorum，且其在30ms多的时间内内均能完成RBC过程，在另外的30ms多的时间内均能完成ABA过程，而Node CN发起的提议由于总是较慢的执行，这样，Node CN的提议的RBC过程有较大概率在其它三个节点的ABA过程结束前仍然没有完成，因此Node CN的提议在ABA赋初值中赋值为0，从而Node CN的提议经常无法被纳入生成的区块中(按照抛币结果有大于1/2的概率)，相当于Node CN经常失去对区块的构造权。而且，即使Node CN拥有对区块的构造权，较大的延迟也会拖慢一次共识的过程。
而采用本申请上述实施例的共识方案，每个节点的提议可以单独成块(生成区块)，且共识结果按照时间戳排序，这样可以保证在不失去区块构造权的情况下，在发起共识提议时即确定成块的相对位置。特别是对于失效节点，无须等待其发起共识提议，其它节点也就不需要配合其完成共识。换句话说，可以按照实际的提议需求，并按照时间戳的顺序对完成共识的结果排序。此外，没有提议的共识节点，也不需要发起实际内容为空的提议，从而可以降低网络带宽的消耗。
如前所述，上述实施例按照考虑传输时延的时间戳排序，充分考虑了共识结束的时间，即尽可能的将生成区块的顺序与共识结果的完成顺序保持一致。假设Node UK，Node DE和Node CN均发起共识提议，Node UK发起共识提议的本地物理时间为60ms，则其第一消息的时间戳ts UK＝60+10＝70ms，Node DE发起共识提议的本地物理时间为70ms，则第一消息的其时间戳ts DE＝70+10＝80ms，Node CN发起共识提议的本地物理时间为10ms，则其第一消息的时间戳ts CN＝10+80＝90ms。如果按照本地物理时间排序，则顺序是m CN→m UK→m DE，但这与共识结果的产生并不相符，因此并不合理，否则先完成的共识结果需要等待后完成的共识结果，区块的生成顺序会被拖长。考虑传输时延后，共识结果的完成顺序与时间戳大概率相同，因此区块的生成顺序不会被拖长。
特别的，针对同一提议，第二消息和第三消息中具有与第一消息中相同的时间戳，该时间戳可以用于标识相同提议的共识过程，而不需要引入其它的标识，从而可以节省协议过程的数据量。
在PBFT中，每一次共识都有一个sequence number来标识本次共识的消息的序列。该sequence number可以是致密递增的，例如像1，2，3，4，...，n这样排列。具体的，例如在一次共识中，共识主节点发起的Pre-prepare消息中包含值为3的sequence number。在本次共识中后续的Prepare消息和Commit消息中，都包含该相同的值为3的sequence number。从而，本次共识结束后，各个共识节点可以确定本次共识的结果在前后的多个共识结果中的顺序。这个顺序一般可以用于确定共识节点执行共识结果和生成的区块的顺序。对于本次sequence number值为3的共识结果，共识节点可以安排其在sequence number值为2的共识结果之后执行或成块。后续，共识主节点可以对sequence number的值增1，即变更为4，从而在下一次共识中发起sequence number的值为4的Pre-prepare消息，相应地，在后续的Prepare消息和Commit消息中，sequence number的值为4。类似的，对于sequence number值为4的共识结果，共识节点可以安排其在sequence number值为3的共识结果之后执行或成块。后续，共识主节点可以对sequence number的值增1，即变更为5，......。这样，可以保证各共识节点按照相同的顺序执行相同的共识结果，从而保证各个共识节点上生成的区块的一致性。
HBBFT中也是类似的，存在相同作用的sequence number。
而上述图4-11实施例中的共识算法中，在共识提议被提出时即通过时间戳的方式确定对应的区块在区块链上的相对位置，一个最终生成的区块包含一个共识提议，这样，该共识结果不需要等待其它共识提议的结果，从而能够快速输出共识结果。而时间戳是比较松散的，并不具有sequence number的致密递增特性，也就无法严格保证区块的执行顺序。例如，对于一个共识节点来说，其可能已完成时间戳为80.5ms的共识结果，100.8ms的共识结果和135.2ms的共识结果，这三个共识结果可以通过时间戳来确定相对的执行顺序后成块顺序，但是，80.5ms的共识结果和100.8ms的共识结果之间是否还有其它共识结果，100.8ms的共识结果和135.2ms的共识结果之间是否还有其它共识结果，通过时间戳是无法确定的。如果另外的某个共识节点具有一个时间戳处于80.5ms和100.8ms之间的共识结果，或者具有一个时间戳处于100.8ms和135.2ms之间的共识结果，则不同共识节点之间难以保证生成的区块的一致。为了保证各个共识节点上生成的区块的一致性，各共识节点需要按照相同的顺序执行相同的共识结果。因此，需要一种机制来保障各共识节点按照相同的顺序执行相同的共识结果。
本申请提供的一种实施例中，各共识节点通过FIFO(First Input First Output，先入先出)方式处理消息。先入先出队列是一种传统的按序执行方法，先进入的指令先完成后，才执行第二条指令。为了保证正确共识节点之间的消息满足FIFO，可以通过为每一个发送的消息编号，并要求接收者按编号顺序处理请求的方式实现。也可以通过TCP协议来保障消息的顺序化传输。TCP提供了可靠的数据传输，避免数据包的重传、顺序的颠倒甚至或者数据包的丢失。共识节点可以在每次发送消息时，将消息编号后压进网络传输层。网络传输层采用TCP协议，并将由上层协议转化的TCP数据包按照顺序发送至接收方，并在一个特定的时长内等待接收方对这个TCP数据包的确认。如果所述共识节点在一个特定时长内没有收到接收方的确认，则重新发送该TCP数据包。如果接收方在特定时长内对该TCP数据包返回了确认，共识节点发送下一TCP数据包。如此循环，直至完成上层协议数据的发送。接收方一旦收到一个上层协议消息的全部TCP数据包后，可以进行循环冗余校验(Cyclic Redundancy Check，CRC)，如果正确则将这些数据包按正确的顺序重组成数据流并传递到高层协议进行处理，并发送下一序号的上层协议的TCP数据包。此外，也可以采用安全套接字层(Secure Sockets Layer，SSL)/安全传输层协议(Transport Layer Security，TLS)通信来保证实现FIFO。
本申请还提供一种实施例，可以如图12所示，包括：S121：【第一轮】第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；S123：【第二轮】接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；S125：【第三轮】接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值以及收集到的签名集合；S127：共识节点收集到至少Quorum个来自于不同节点的表示投票通过的第三消息后，将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出。
例如，第一共识节点Node 0可以在本地维护一个关键时刻序列{t 01,t 02,......}，在上述S121-S127的过程中，当经过某个关键时刻t时，Node 0可以广播一个第四消息，以表明自己经过了这一关键时刻，如图13所示。这样的第四消息例如为Pass(t)消息，消息名Pass表明该消息是表示经过某个关键时刻的消息，其中包括的参数t即为该关键时刻。这里例如广播的是Pass(t 02)。
类似的，Node 1也可以在本地维护一个关键时刻序列{t 11,t 12,......}，在上述S121-S127的过程中(从局部来看，也可以是在S121-S125的过程中，以下不再重复)，当经过某个关键时刻t时，Node 1可以广播一个第四消息，以表明自己经过了这一关键时刻，这里例如广播的是Pass(t 12)。Node 2也类似的，例如在本地维护一个关键时刻序列{t 21,t 22,......}，在上述S121-S127的过程中，当经过某个关键时刻t时，Node 2可以广播一个第四消息，以表明自己经过了这一关键时刻，这里例如广播的是Pass(t 24)。Node 3也类似的，在本地维护一个时刻序列{t 31,t 32,......}，在上述S121-S127的过程中，当经过某个关键时刻t时，Node 3可以广播一个第四消息，以表明自己经过了这一关键时刻，这里例如广播的是Pass(t 33)。上述内容一并如图14所示。图13、14中所示的关键时刻序列，可以更为稠密或稀疏，这里并不做限定。
参与共识的共识节点，可以是各自在本地维护关键时刻序列。参与共识的共识节点各 自在本地维护的关键时刻序列，可以相同，也可以不完全相同，还可以是完全不相同。对于完全相同的情形，往往需要通过中心化的方式为每一参与共识的节点发送关键时刻序列，或者由参与共识的节点之间协商或同步。对于完全不相同的情形，则可以是由参与共识的各节点自身按照本地时钟来确定，从而不需要中心化的方式为每一参与共识的节点发送关键时刻序列，或者由参与共识的节点之间协商或同步。至于不完全相同的情形，可以是中心化的方式为每一参与共识的节点发送关键时刻序列，之后各共识节点在此基础上增加一定数量的其它关键时刻，或者由参与共识的节点之间协商或同步部分关键时刻序列，之后各共识节点在此基础上增加一定数量的其它关键时刻；当然，也可以是由参与共识的各节点自身按照本地时钟来确定关键时刻序列后发生部分重合的情况。
共识节点广播Pass(t)消息，除了表明自身已经经过关键时刻t，还可以表示一种承诺，承诺之后对于时间戳小于关键时刻t的提议投票为0，或者是不再处理所述时间戳在所述关键时刻t之前的共识提议。这样，共识节点收集到至少Quorum个Pass(t)消息后(包括自身最新广播的Pass(t)消息)，可以得到这些消息中的关键时刻，该关键时刻例如是至少Quorum个第四消息中的最小关键时刻。从而，该共识节点可以确认至少Quorum个共识节点都经过了该关键时刻t，从而可以对“此后将时间戳小于t的共识提议投票为0”或“不再处理时间戳小于t的共识提议”达成一致。这样，通过广播Pass消息和按照达成一致的承诺内容执行，也可以间接达到类似FIFO的效果，不过该关键时刻t之前尚未投票的共识提议可能将无法通过共识，也可能即使通过投票也无法被处理；如果无法通过共识或不被处理，该共识提议对应的交易集合也就无法被收录进区块中。所述最新Pass消息，是因为同一节点可能先后广播多个不同关键时刻的Pass消息，这样，对于接收到同一节点发来的多个不同关键时刻的Pass消息来说，可以取最新的那个关键时刻。
上述广播Pass消息，可以至少由Quorum个共识节点参与完成。这样，每一共识节点广播Pass消息，则任一共识节点可以接收其它共识节点发来的至少(Quorum-1)数量的Pass消息，加上自身广播的Pass消息，可以收集齐至少Quorum数量的Pass消息。参与共识的共识节点各自在本地维护关键时刻序列，则各共识节点广播的最新的Pass消息中的关键时刻可能相同，也可能不同。即使参与共识的共识节点各自在本地维护关键时刻序列相同或部分相同，各共识节点广播的最新的Pass消息中的关键时刻可能相同，也可能不同。而参与共识的共识节点各自在本地维护关键时刻序列完全不同的情况，则各共识节点广播的最新的Pass消息中的关键时刻一定不同。如果收集齐的至少Quorum数量的最新Pass消息中的关键时刻相同，则可以对“此后将时间戳小于t的共识提议投票为0”或“不再处理时间戳小于t的共识提议”达成一致。如果收集齐的至少Quorum数量的Pass消息中的关键时刻不同，例如上述例子中的Node 0～Node 3收集的4个(此时Quorum＝3)最新的Pass消息中的关键时刻分别是Pass(t 02)、Pass(t 12)、Pass(t 24)和Pass(t 33)，而其中最小的是t 02，则可以对“此后将时间戳小于t 02的共识提议投票为0”或“不再处理时间戳小于t 02的共识提议”达成一致。
以下提供一种共识方法实施例，结合图4-14实施例来说明发送Pass消息的具体时机。
在图4-14对应的实施例中，接收到所述Val消息的共识节点广播Bval消息，Bval消息中包括对第一消息中共识提议的交易集合的投票和签名。
接收到Bval消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，可以认为已经经过了关键时刻t，该关键时刻t即为本次共识中Val消息中的时间戳，例如该时间戳为ts。进而，可以广播Pass(ts)消息至其它共识节点。
进而，任一共识节点在收集到至少Quorum数量的Pass(ts)后，可以不再处理其它时间戳在所述关键时刻ts之前的共识提议或者对所述关键时刻ts之前的共识提议投票为不通过。例如，对于其它次共识中Val消息的时间戳小于所述ts的，对其投票Bval(0)，0在共识算法的投票中经常表示不通过。这样，对于任何新的时间戳落后的共识提议，都有至少Quorum的共识节点认为其时间戳晚于所述关键时刻ts，从而对其在Bval(0)中投票为0，该时间戳落后的共识提议将不会被包含新生成的区块上。这样，至少Quorum的共识节点可以按照时间顺序执行已共识的所述ts对应的区块。广播第四消息时如果存在共识中的更早时间戳的已完成投票的共识提议，即已完成Bval轮次的共识提议，则完成该更早时间戳的共识提议的共识后，再将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出。这样才能保证共识结果的完成顺序。
另一方面，接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值以及收集到的签名集合；共识节点收集到至少Quorum个来自于不同节点的第三消息后，可以将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出。
作为替换方案，将Pass消息置入第三消息中广播，而不需要另外广播第四消息，这样可以节省协议需要传输的消息的数量。具体的，接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值、收集到的签名集合和关键时刻，所述关键时刻为第一消息中的时间戳。进而，任一共识节点在收集到至少Quorum数量的来自于不同节点的第三消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。类似的，共识节点收集到至少Quorum个来自于不同节点的第三消息后，还可以将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出。
上述方案可以称为“合作模式”，因为这样的方案可以较快的完成共识。而且，这种方式可以直接依赖发起共识提议的第一消息中的时间戳，而不需要共识节点在本地维护关键时刻序列，降低了实现成本和复杂度。
上述关于合作模式的方案，虽然可以较快的完成共识，但存在一定的风险。例如，如果存在恶意节点，其在忠诚节点提出共识提议后立即提起一个更晚时间戳的共识提议，由于忠诚节点的共识提议还没有进入或尚未完成本申请前述共识方法实施例中的第二轮次，因此如果恶意节点提出的更晚时间戳的共识提议先完成第二轮次的话，则忠诚节点的共识提议最终将被共识为0，即投票不通过，或不被处理。这样，忠诚节点发起的共识提议将有可能由于恶意节点的攻击而被过滤掉。即使不存在恶意攻击，而是网络延迟或者时钟偏移突然增大的情况，也可以导致某些区块由于晚于预期时间到达其他节点，而被共识为0或不能被处理。
基于此，本申请给出一种“竞争模式”的共识方法实施例，仍然结合图4-14实施例来说明发送Pass消息的具体时机。
在图4-14对应的一个实施例中，可以是至少f+1个不同共识节点分别作为第一共识节点发起共识提议，广播Val消息。在至少f+1个不同共识节点中的每一个作为第一共识节点广播Val消息的共识过程中，至少有其它2f个共识节点配合来完成本次共识。这样，参与共识的节点为2f+1个，达到Quorum数量。
在这个过程中，当任一参与共识的节点确认有f+1个由不同共识节点提出的共识提议被共识为1(即通过共识，意味着将输出为共识结果)，可以确认其中至少有1个忠诚节点的共识提议被共识为1，从而可以将这f+1个共识提议中最早的时间戳作为关键时刻。这是因为，按照拜占庭容错模型，总量为3f+1的共识节点中至多可以容错f个拜占庭节点(例如恶意节点，无响应的节点)。那么，有f+1个由不同共识节点提出的共识提议被共识为1，则其中至少有1个是忠诚节点提出的共识提议，说明忠诚节点的共识提议没有被完全过滤掉。这也说明整个系统是可用的，具有活性(分布式系统中liveness的概念)。进而，该共识节点可以不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
任一参与共识的节点确认有f+1个由不同共识节点提出的共识提议被共识为1，更强的条件可以是确认有f+1个连续的且由不同共识节点提出的共识提议被共识为1。上述被共识为1，更强的条件可以是输出为共识结果。
在图4-14对应的另一个实施例中，可以是至少2f+1(Quorum)个不同共识节点分别作为第一共识节点发起共识提议，广播Val消息。在至少2f+1个不同共识节点中的每一个作为第一共识节点广播Val消息的共识过程中，至少有其它2f个共识节点配合来完成本次共识。这样，参与共识的节点为2f+1个，也达到Quorum数量。
在这个过程中，当任一参与共识的节点确认有2f+1(这里表示Quorum数量，其它容错模型的共识算法中Quorum可能不是2f+1)个由不同共识节点提出的共识提议被共识为1，可以确认其中至少有f+1个忠诚节点的共识提议被共识为1，从而可以将这2f+1个共 识提议中最早的时间戳作为关键时刻。这是因为，按照拜占庭容错模型，总量为3f+1的共识节点中至多可以容错f个拜占庭节点(例如恶意节点，无响应的节点)。那么，有2f+1个由不同共识节点提出的共识提议被共识为1，则其中至少有f+1个是忠诚节点提出的共识提议，说明忠诚节点的共识提议没有被完全过滤掉，且忠诚节点必然是占上风的。这也说明整个系统是可用的，具有活性。进而，该共识节点可以不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
任一参与共识的节点确认有2f+1个由不同共识节点提出的共识提议被共识为1，更强的条件可以是确认有2f+1个连续的且由不同共识节点提出的共识提议被共识为1。上述被共识为1，更强的条件可以是输出为共识结果。
在一个实施例中，共识节点可以在合作模式和竞争模式之间切换。具体的，共识节点可以根据历史的共识结果情况在所述合作模式和竞争模式之间切换。
共识节点可以在确认有第一数量的来自于不同节点的共识提议被共识为不通过后，切换到竞争模式。例如，第一数量为f+1，这样，共识节点可以在确认有f+1数量的来自于不同节点的共识提议被共识为不通过后，切换到竞争模式。确认有f+1数量的来自于不同节点的共识提议被共识为不通过，说明至少有1个忠诚节点提出的共识提议被共识为不通过，说明之前的模式比较激进，或者存在拜占庭节点。因此，调整到竞争模式，将关键时刻设的离当前更远，从而允许更多的共识提议能够通过共识，但副作用是可能导致一些共识结果无法较快的确定顺序。更强的条件可以是确认有第一数量连续的来自于不同节点的共识提议被共识为不通过。
共识节点可以在确认有第二数量的来自于不同节点的共识提议通过共识/输出为共识结果后，切换到合作模式。例如，第二数量为2f+1或Quorum，这样，共识节点可以在确认有2f+1或Quorum数量的来自于不同节点的共识提议通过共识/输出为共识结果后，切换到合作模式。确认有2f+1数量的来自于不同节点的共识提议通过共识/输出为共识结果，说明至少有f+1个忠诚节点提出的共识提议被共识为通过，说明之前的模式比较宽松，或者不存在拜占庭节点。因此，调整到合作模式，将关键时刻设的离当前更近，从而利于共识结果更快速的确定顺序，但副作用是可能导致一些由于网络延迟或时钟便宜较大确定情况下某些共识提议被过滤掉，或者相对来说更容易被恶意节点发起过滤攻击。更强的条件可以是确认有第二数量连续的来自于不同节点的共识提议通过共识/输出为共识结果。
本申请还提供一种区块链系统实施例，包括：第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，广播第四消息至其它共识节点；第四消息中包括关键时刻，其为第一消息中的时间戳；任一共识节点在收集到至少Quorum数量的来自于不同节点的第四消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
本申请还提供一种区块链系统实施例，包括：第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值、收集到的签名集合和关键时刻，所述关键时刻为第一消息中的时间戳；任一共识节点在收集到至少Quorum数量的来自于不同节点的第三消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
本申请还提供一种区块链系统实施例，包括：第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值、收集到的签名集合；接收到第二消息的共识节点收集到至少Quorum 个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值以及收集到的签名集合；共识节点收集到至少Quorum个来自于不同节点的表示投票通过的第三消息后，将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出；至少f+1个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有f+1数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这f+1个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；或，至少Quorum个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有Quorum数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这Quorum个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
本申请还提供一种区块链系统实施例，包括：第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值以及收集到的签名集合；共识节点收集到至少Quorum个来自于不同节点的表示投票通过的第三消息后，将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出；共识节点根据历史的共识结果情况在所述合作模式和竞争模式之间切换，其中：合作模式：接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，广播第四消息至其它共识节点；第四消息中包括关键时刻，其为第一消息中的时间戳；任一共识节点在收集到至少Quorum数量的来自于不同节点的第四消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；竞争模式：至少f+1个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有f+1数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这f+1个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；或，至少Quorum个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有Quorum数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这Quorum个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
本申请还提供一种区块链系统实施例，包括：第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值、收集到的签名集合和关键时刻，所述关键时刻为第一消息中的时间戳；共识节点根据历史的共识结果情况在所述合作模式和竞争模式之间切换，其中：合作模式：任一共识节点在收集到至少Quorum数量的来自于不同节点的第三消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；竞争模式：至少f+1个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有f+1数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这f+1个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；或，至少Quorum个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有Quorum数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这Quorum个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。 因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable Gate Array，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language)等，目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为服务器系统。当然，本申请不排除随着未来计算机技术的发展，实现上述实施例功能的计算机例如可以为个人计算机、膝上型计算机、车载人机交互设备、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
虽然本说明书一个或多个实施例提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或终端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境，甚至为分布式数据处理环境)。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下，并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。例如若使用到第一，第二等词语用来表示名称，而并不表示任何特定的顺序。
为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书一个或多个时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
本发明是参照根据本发明实施例的方法、装置(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机 程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储、石墨烯存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
本领域技术人员应明白，本说明书一个或多个实施例可提供为方法、系统或计算机程序产品。因此，本说明书一个或多个实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书一个或多个实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本说明书一个或多个实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书一个或多个实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
以上所述仅为本说明书一个或多个实施例的实施例而已，并不用于限制本说明书一个或多个实施例。对于本领域技术人员来说，本说明书一个或多个实施例可以有各种更改和变化。凡在本说明书的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在权利要求范围之内。

Claims (37)

  1. 一种区块链系统中的共识方法，包括：
    第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；
    接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；
    接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，广播第四消息至其它共识节点；第四消息中包括关键时刻，其为第一消息中的时间戳；
    任一共识节点在收集到至少Quorum数量的来自于不同节点的第四消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
  2. 如权利要求1所述的方法，还包括：
    接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值以及收集到的签名集合；
    共识节点收集到至少Quorum个来自于不同节点的表示投票通过的第三消息后，将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出。
  3. 如权利要求2所述的方法，广播第四消息时如果存在共识中的更早时间戳的已完成投票的共识提议，则完成该更早时间戳的共识提议的共识后，再将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出。
  4. 如权利要求1所述的方法，所述时间戳基于第一共识节点广播第一消息时或之前的物理时间以及网络传输时延确定。
  5. 如权利要求4所述的方法，所述网络传输时延包括第一共识节点与其它共识节点的网络传输时延的平均值或最大值。
  6. 如权利要求1或2所述的方法，在同一次共识过程中，所述区块链系统中的至少Quorum数量的共识节点参与共识，且其中至少一个共识节点作为第一共识节点执行权利要求1的方法。
  7. 如权利要求1或2所述的方法，至少一个共识节点作为第一共识节点执行权利要求1的方法所产生的至少两个共识结果，按照所述时间戳顺序生成区块。
  8. 如权利要求1或2所述的方法，至少两个共识节点分别作为第一共识节点执行权利要求1的方法所产生的至少两个共识结果，按照所述时间戳顺序生成区块。
  9. 一种区块链系统中的共识方法，包括：
    第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；
    接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；
    接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值、收集到的签名集合和关键时刻，所述关键时刻为第一消息中的时间戳；
    任一共识节点在收集到至少Quorum数量的来自于不同节点的第三消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
  10. 如权利要求9所述的方法，还包括：
    共识节点收集到至少Quorum个来自于不同节点的表示投票通过的第三消息后，将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出。
  11. 如权利要求10所述的方法，广播第三消息时如果存在共识中的更早时间戳的已完成投票的共识提议，则完成该更早时间戳的共识提议的共识后，再将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出。
  12. 如权利要求9所述的方法，所述时间戳基于广播所述共识提议的共识节点广播包含所述共识提议的消息时或之前的物理时间以及网络传输时延确定。
  13. 如权利要求12所述的方法，所述网络传输时延包括所述广播共识提议的共识节点与其它共识节点的网络传输时延的平均值或最大值。
  14. 如权利要求9所述的方法，在同一次共识过程中，所述区块链系统中的至少Quorum数量的共识节点参与共识，且其中至少一个共识节点作为所述广播共识提议的共识节点执行共识过程。
  15. 如权利要求9或10所述的方法，至少一个共识节点作为所述广播共识提议的共识节点执行共识过程所产生的至少两个共识结果，按照所述时间戳顺序生成区块。
  16. 如权利要求9或10所述的方法，至少两个共识节点分别作为所述广播共识提议的共识节点执行共识过程所产生的至少两个共识结果，按照所述时间戳顺序生成区块。
  17. 一种区块链系统中的共识方法，包括：
    第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；
    接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；
    接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值、收集到的签名集合；
    接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值以及收集到的签名集合；
    共识节点收集到至少Quorum个来自于不同节点的表示投票通过的第三消息后，将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出；
    至少f+1个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有f+1数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这f+1个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；或，
    至少Quorum个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有Quorum数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这Quorum个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
  18. 如权利要求17所述的方法，其中，所述任一参与共识的节点确认有f+1个由不同共识节点提出的共识提议通过共识/输出为共识结果，包括：
    所述任一参与共识的节点确认有连续f+1个由不同共识节点提出的共识提议通过共识/输出为共识结果。
  19. 如权利要求17所述的方法，其中，所述任一参与共识的节点确认有Quorum个由不同共识节点提出的共识提议通过共识/输出为共识结果，包括：
    所述任一参与共识的节点确认有Quorum个连续的且由不同共识节点提出的共识提议通过共识/输出为共识结果。
  20. 一种区块链系统中的共识方法，包括：
    第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；
    接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；
    接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值以及收集到的签名集合；
    共识节点收集到至少Quorum个来自于不同节点的表示投票通过的第三消息后，将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出；
    共识节点能够在合作模式和竞争模式之间切换，其中：
    合作模式：接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，广播第四消息至其它共识节点；第四消息中包括关键时刻，其为第一消息中的时间戳；任一共识节点在收集到至少Quorum数量的来自于不同节点的第四消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；
    竞争模式：至少f+1个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有f+1数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这f+1个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；或，至少Quorum个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有Quorum数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这 Quorum个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
  21. 如权利要求20所述的方法，其中，所述任一参与共识的节点确认有f+1个由不同共识节点提出的共识提议通过共识/输出为共识结果，包括：
    所述任一参与共识的节点确认有连续f+1个由不同共识节点提出的共识提议通过共识/输出为共识结果。
  22. 如权利要求20所述的方法，其中，所述任一参与共识的节点确认有Quorum个由不同共识节点提出的共识提议通过共识/输出为共识结果，包括：
    所述任一参与共识的节点确认有Quorum个连续的且由不同共识节点提出的共识提议通过共识/输出为共识结果。
  23. 一种区块链系统中的共识方法，包括：
    第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；
    接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；
    接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值、收集到的签名集合和关键时刻，所述关键时刻为第一消息中的时间戳；
    共识节点能够在合作模式和竞争模式之间切换，其中：
    合作模式：任一共识节点在收集到至少Quorum数量的来自于不同节点的第三消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；
    竞争模式：至少f+1个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有f+1数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这f+1个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；或，至少Quorum个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有Quorum数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这Quorum个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
  24. 如权利要求23所述的方法，其中，所述任一参与共识的节点确认有f+1个由不同共识节点提出的共识提议通过共识/输出为共识结果，包括：
    所述任一参与共识的节点确认有连续f+1个由不同共识节点提出的共识提议通过共识/输出为共识结果。
  25. 如权利要求23所述的方法，其中，所述任一参与共识的节点确认有Quorum个由不同共识节点提出的共识提议通过共识/输出为共识结果，包括：
    所述任一参与共识的节点确认有Quorum个连续的且由不同共识节点提出的共识提议通过共识/输出为共识结果。
  26. 如权利要求23-25任一项所述的方法，所述共识节点能够在合作模式和竞争模式之间切换，包括：
    共识节点能够根据历史的共识结果情况在所述合作模式和竞争模式之间切换。
  27. 如权利要求26所述的方法，所述共识节点能够根据历史的共识结果情况在所述合作模式和竞争模式之间切换，包括：
    所述共识节点在确认有第一数量的来自于不同节点的共识提议被共识为不通过后，切换到竞争模式。
  28. 如权利要求27所述的方法，所述共识节点在确认有第一数量的来自于不同节点的共识提议被共识为不通过，包括：
    所述共识节点在确认有第一数量连续的来自于不同节点的共识提议被共识为不通过。
  29. 如权利要求27或28所述的方法，所述第一数量为f+1。
  30. 如权利要求26所述的方法，所述共识节点能够根据历史的共识结果情况在所述合作模式和竞争模式之间切换，包括：
    所述共识节点在确认有第二数量的来自于不同节点的共识提议通过共识/输出为共识结果后，切换到合作模式。
  31. 如权利要求30所述的方法，所述共识节点在确认有第二数量的来自于不同节点的共识提议通过共识/输出为共识结果，包括：
    所述共识节点在确认有第二数量连续的来自于不同节点的共识提议通过共识/输出为共识结果。
  32. 如权利要求31所述的方法，所述第二数量为2f+1或Quorum。
  33. 一种区块链系统，包括：
    第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；
    接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；
    接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，广播第四消息至其它共识节点；第四消息中包括关键时刻，其为第一消息中的时间戳；
    任一共识节点在收集到至少Quorum数量的来自于不同节点的第四消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
  34. 一种区块链系统，包括：
    第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；
    接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；
    接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值、收集到的签名集合和关键时刻，所述关键时刻为第一消息中的时间戳；
    任一共识节点在收集到至少Quorum数量的来自于不同节点的第三消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
  35. 一种区块链系统，包括：
    第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；
    接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；
    接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值、收集到的签名集合；
    接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值以及收集到的签名集合；
    共识节点收集到至少Quorum个来自于不同节点的表示投票通过的第三消息后，将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出；
    至少f+1个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有f+1数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这f+1个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；或，
    至少Quorum个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有Quorum数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这Quorum个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
  36. 一种区块链系统，包括：
    第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；
    接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；
    接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值以及收集到的签名集合；
    共识节点收集到至少Quorum个来自于不同节点的表示投票通过的第三消息后，将所述摘要值对应的交易集合作为按照所述时间戳排序的共识结果输出；
    共识节点根据历史的共识结果情况在所述合作模式和竞争模式之间切换，其中：
    合作模式：接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，广播第四消息至其它共识节点；第四消息中包括关键时刻，其为第一消息中的时间戳；任一共识节点在收集到至少Quorum数量的来自于不同节点的第四消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；
    竞争模式：至少f+1个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有f+1数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这f+1个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；或，至少Quorum个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有Quorum数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这Quorum个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
  37. 一种区块链系统，包括：
    第一共识节点广播第一消息，第一消息中包括共识提议的交易集合、时间戳和第一共识节点的签名；
    接收到所述第一消息的共识节点广播第二消息，第二消息中包括对所述交易集合的投票和签名；所述投票包括所述交易集合的摘要值；
    接收到第二消息的共识节点收集到至少Quorum个来自于不同共识节点的一致的投票后，如果自身针对该提议没有广播过不同的投票，则广播第三消息，第三消息包括所述摘要值、收集到的签名集合和关键时刻，所述关键时刻为第一消息中的时间戳；
    共识节点根据历史的共识结果情况在合作模式和竞争模式之间切换，其中：
    合作模式：任一共识节点在收集到至少Quorum数量的来自于不同节点的第三消息后，不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；
    竞争模式：至少f+1个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有f+1数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这f+1个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过；或，至少Quorum个不同共识节点分别作为第一共识节点执行上述共识过程中，任一参与共识的节点确认有Quorum数量的来自于不同节点的共识提议通过共识/输出为共识结果后，将这Quorum个共识提议中最早的时间戳作为关键时刻，并不再处理其它时间戳在所述关键时刻之前的共识提议或者对所述关键时刻之前的共识提议投票为不通过。
PCT/CN2022/124131 2021-10-09 2022-10-09 共识方法和区块链系统 WO2023056975A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111175151.7A CN113609515B (zh) 2021-10-09 2021-10-09 一种共识方法、区块链系统
CN202111175151.7 2021-10-09

Publications (1)

Publication Number Publication Date
WO2023056975A1 true WO2023056975A1 (zh) 2023-04-13

Family

ID=78343385

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/124131 WO2023056975A1 (zh) 2021-10-09 2022-10-09 共识方法和区块链系统

Country Status (2)

Country Link
CN (2) CN114817949A (zh)
WO (1) WO2023056975A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114817949A (zh) * 2021-10-09 2022-07-29 支付宝(杭州)信息技术有限公司 一种共识方法、区块链系统
CN114782047B (zh) * 2021-12-29 2023-06-30 张海滨 数据共识方法及分布式系统
WO2024059926A1 (en) * 2022-09-20 2024-03-28 Huawei Technologies Canada Co., Ltd. Method and system for creating a distributed ledger of verified vehicle transactions
CN116455904B (zh) * 2023-06-12 2023-09-05 湖南天河国云科技有限公司 基于异步网络去中心化的区块链共识方法及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210026842A1 (en) * 2019-07-24 2021-01-28 Vmware, Inc. Flexible byzantine fault tolerant protocol using message delay upper bound for client commit decision
CN112507019A (zh) * 2020-11-20 2021-03-16 南京航空航天大学 一种基于智能合约的pbft共识系统及方法
CN113283892A (zh) * 2021-05-26 2021-08-20 北京航空航天大学 一种基于投票机制的PoSearch与PBFT融合共识算法
CN113609515A (zh) * 2021-10-09 2021-11-05 支付宝(杭州)信息技术有限公司 一种共识方法、区块链系统

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110708163B (zh) * 2019-09-10 2022-08-02 杭州秘猿科技有限公司 一种区块链的共识方法、装置、系统和电子设备
CN111522822A (zh) * 2020-07-03 2020-08-11 支付宝(杭州)信息技术有限公司 一种区块链共识方法、装置及电子设备

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210026842A1 (en) * 2019-07-24 2021-01-28 Vmware, Inc. Flexible byzantine fault tolerant protocol using message delay upper bound for client commit decision
CN112507019A (zh) * 2020-11-20 2021-03-16 南京航空航天大学 一种基于智能合约的pbft共识系统及方法
CN113283892A (zh) * 2021-05-26 2021-08-20 北京航空航天大学 一种基于投票机制的PoSearch与PBFT融合共识算法
CN113609515A (zh) * 2021-10-09 2021-11-05 支付宝(杭州)信息技术有限公司 一种共识方法、区块链系统
CN114817949A (zh) * 2021-10-09 2022-07-29 支付宝(杭州)信息技术有限公司 一种共识方法、区块链系统

Also Published As

Publication number Publication date
CN114817949A (zh) 2022-07-29
CN113609515A (zh) 2021-11-05
CN113609515B (zh) 2022-02-18

Similar Documents

Publication Publication Date Title
WO2023056975A1 (zh) 共识方法和区块链系统
WO2023056976A1 (zh) 共识方法、区块链系统和共识节点
WO2023056958A1 (zh) 共识方法、区块链系统和共识节点
WO2023056974A1 (zh) 共识方法、区块链系统和共识节点
WO2023056964A1 (zh) 共识方法、区块链系统和共识节点
CN114401150B (zh) 区块链网络中加入节点的方法和区块链系统
Yin et al. HotStuff: BFT consensus in the lens of blockchain
Yin et al. HotStuff: BFT consensus with linearity and responsiveness
WO2023056967A1 (zh) 共识方法、区块链系统和共识节点
WO2023056966A1 (zh) 共识方法、区块链系统和共识节点
CN114726517A (zh) 一种区块链上产生随机数种子的方法、系统和共识节点
CN114640451A (zh) 区块链上实现分布式密钥生成的方法、系统和共识节点
CN114338040A (zh) 一种区块链节点的分组多链三次共识方法
WO2023193783A1 (zh) 区块链共识方法及区块链副本装置
WO2024092936A1 (zh) 一种区块链上实现分布式密钥生成的方法、系统和节点
WO2024092935A1 (zh) 一种区块链上实现分布式密钥生成的方法、系统和节点
KR20230046085A (ko) 블록체인 네트워크를 위한 효율적인 듀얼모드 합의 프로토콜
Hood et al. Partitionable asynchronous cryptocurrency blockchain
CN115174090A (zh) 区块链共识方法及装置
Giridharan et al. Motorway: Seamless high speed BFT
CN116846906A (zh) 一种共识方法、区块链节点
CN116846907A (zh) 一种共识方法、区块链节点
CN116846912A (zh) Pbft算法中的视图切换方法、共识节点和区块链系统
CN116484417A (zh) 区块链系统中的交易提议方法、共识节点和区块链系统
CN116823463A (zh) 区块链系统中的交易提议方法、共识节点和区块链系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22877989

Country of ref document: EP

Kind code of ref document: A1