A consensus method, blockchain system

Abstract

A consensus method and a blockchain system, the consensus method comprising: a first consensus node broadcasting a first message, the first message comprising a set of transactions of a consensus proposal, a timestamp and a signature of the first consensus node; a consensus node receiving the first message broadcasting a second message, the second message comprising a vote on the set of transactions and a signature; the vote comprising a digest value of the set of transactions; a consensus node receiving the second message broadcasting a fourth message to other consensus nodes upon collecting at least Quorum consistent votes from different consensus nodes; the fourth message comprising a critical time, which is the timestamp in the first message; any consensus node upon collecting at least Quorum fourth messages from different nodes, no longer processing or voting against a consensus proposal whose timestamp is before the critical time.

Description

TECHNICAL FIELD

[0001] The embodiment of the present specification belongs to the technical field of blockchains, and particularly relates to a consensus method and a blockchain system. BACKGROUND

[0002] A blockchain is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism and encryption algorithm. In a blockchain system, data blocks are combined into a chain-type data structure in a sequential manner according to time sequence, and a distributed ledger is ensured to be unalterable and unforgeable by means of cryptography. Due to the characteristics of decentralization, unalterable information and autonomy, the blockchain has more and more applications. SUMMARY

[0003] The purpose of the present application is to provide a consensus method and a blockchain system, comprising:

[0004] A consensus method in a blockchain system embodiment comprises:

[0005] A first consensus node broadcasts a first message, and the first message comprises a transaction set proposed by consensus, a timestamp and a signature of the first consensus node;

[0006] A consensus node receiving the first message broadcasts a second message, and the second message comprises a vote on the transaction set and a signature; the vote comprises an abstract value of the transaction set;

[0007] After a consensus node receiving the second message collects at least Quorum consistent votes from different consensus nodes, the consensus node broadcasts a fourth message to other consensus nodes; the fourth message comprises a critical moment, which is the timestamp in the first message;

[0008] Any consensus node, after collecting at least Quorum fourth messages from different nodes, no longer processes consensus proposals or votes for consensus proposals before the critical moment.

[0009] A consensus method in a blockchain system embodiment comprises:

[0010] A first consensus node broadcasts a first message, and the first message comprises a transaction set proposed by consensus, a timestamp and a signature of the first consensus node;

[0011] A consensus node receiving the first message broadcasts a second message, and the second message comprises a vote on the transaction set and a signature; the vote comprises an abstract value of the transaction set;

[0012] If the consensus node receiving the second message collects at least Quorum consistent votes from different consensus nodes and has not broadcast a different vote for the proposal, the consensus node broadcasts a third message, the third message including the digest value, the collected set of signatures, and a critical time, the critical time being the timestamp in the first message;

[0013] Any consensus node, after collecting at least Quorum third messages from different nodes, no longer processes or votes as not passed for consensus proposals with timestamps before the critical time.

[0014] Through the above embodiment, consensus can be completed faster.

[0015] A consensus method in a blockchain system, comprising:

[0016] A first consensus node broadcasts a first message, the first message including a set of transactions of a consensus proposal, a timestamp, and a signature of the first consensus node;

[0017] A consensus node receiving the first message broadcasts a second message, the second message including a vote for the set of transactions and a signature; the vote including a digest value of the set of transactions;

[0018] If the consensus node receiving the second message collects at least Quorum consistent votes from different consensus nodes and has not broadcast a different vote for the proposal, the consensus node broadcasts a third message, the third message including the digest value and the collected set of signatures;

[0019] If the consensus node receiving the second message collects at least Quorum consistent votes from different consensus nodes and has not broadcast a different vote for the proposal, the consensus node broadcasts a third message, the third message including the digest value and the collected set of signatures;

[0020] After the consensus node collects at least Quorum third messages from different nodes indicating that the vote is passed, the consensus node outputs the set of transactions corresponding to the digest value as a consensus result ordered according to the timestamp;

[0021] In the consensus process performed by at least f+1 different consensus nodes as the first consensus node, any node participating in consensus confirms that there are f+1 consensus proposals from different nodes passed through consensus / output as consensus results, and the earliest timestamp in the f+1 consensus proposals is taken as a critical time, and other consensus proposals with timestamps before the critical time are no longer processed or voted as not passed for the consensus proposals with timestamps before the critical time; or

[0022] When at least Quorum different consensus nodes execute the above-mentioned consensus process as the first consensus node respectively, any consensus participating node confirms that Quorum consensus proposals from different nodes pass the consensus / output as the consensus result, and then takes the earliest timestamp in the Quorum consensus proposals as the key moment, and no longer processes or votes for the consensus proposals before the key moment.

[0023] Through the above-mentioned embodiments, it is beneficial to ensure that the entire system is available and active.

[0024] A consensus method embodiment in a blockchain system includes:

[0025] The first consensus node broadcasts a first message, and the first message includes a consensus proposal transaction set, a timestamp, and a signature of the first consensus node;

[0026] The consensus node receiving the first message broadcasts a second message, and the second message includes a vote on the transaction set and a signature; the vote includes an abstract value of the transaction set;

[0027] After the consensus node receiving the second message collects at least Quorum consistent votes from different consensus nodes, if it has not broadcast a different vote for the proposal, it broadcasts a third message, and the third message includes the abstract value and a collected signature set;

[0028] After the consensus node collects at least Quorum third messages from different nodes indicating that the vote passes, the consensus node outputs the transaction set corresponding to the abstract value as the consensus result according to the timestamp;

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

[0030] Cooperation mode: after the consensus node receiving the second message collects at least Quorum consistent votes from different consensus nodes, it broadcasts a fourth message to other consensus nodes; the fourth message includes a key moment, which is the timestamp in the first message; any consensus node, after collecting at least Quorum fourth messages from different nodes, no longer processes or votes for the consensus proposals before the key moment as not passing;

[0031] The competition mode: at least f+1 different consensus nodes respectively as the first consensus node execute the above consensus process, any node participating in the consensus confirms that there are f+1 consensus proposals from different nodes passing the consensus / output as the consensus result, and the earliest timestamp in the f+1 consensus proposals is taken as the key moment, and other consensus proposals with timestamps before the key moment are no longer processed or voted as not passed; or, at least Quorum different consensus nodes respectively as the first consensus node execute the above consensus process, any node participating in the consensus confirms that there are Quorum consensus proposals from different nodes passing the consensus / output as the consensus result, and the earliest timestamp in the Quorum consensus proposals is taken as the key moment, and other consensus proposals with timestamps before the key moment are no longer processed or voted as not passed.

[0032] A consensus method embodiment in a blockchain system, comprising:

[0033] The first consensus node broadcasts a first message, and the first message includes a transaction set of the consensus proposal, a timestamp, and a signature of the first consensus node;

[0034] The consensus node receiving the first message broadcasts a second message, and the second message includes a vote on the transaction set and a signature; the vote includes a digest value of the transaction set;

[0035] After the consensus node receiving the second message collects at least Quorum consistent votes from different consensus nodes, if it has not broadcast a different vote for the proposal, it broadcasts a third message, and the third message includes the digest value, a collected signature set, and a key moment, and the key moment is the timestamp in the first message;

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

[0037] The cooperation mode: any consensus node collects at least Quorum third messages from different nodes, and no longer processes or votes as not passed for other consensus proposals with timestamps before the key moment;

[0038] The competition mode is: at least f+1 different consensus nodes respectively as the first consensus node execute the above consensus process, any node participating in the consensus confirms that there are f+1 consensus proposals from different nodes passing the consensus / output as the consensus result, and the earliest timestamp in the f+1 consensus proposals is taken as the key moment, and other consensus proposals with timestamps before the key moment are no longer processed or voted as not passed; or, at least Quorum different consensus nodes respectively as the first consensus node execute the above consensus process, any node participating in the consensus confirms that there are Quorum consensus proposals from different nodes passing the consensus / output as the consensus result, and the earliest timestamp in the Quorum consensus proposals is taken as the key moment, and other consensus proposals with timestamps before the key moment are no longer processed or voted as not passed. BRIEF DESCRIPTION OF DRAWINGS

[0039] In order to more clearly illustrate the technical solutions of the embodiments of the present specification, the drawings needed in the embodiment description will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments described in the present specification, and other drawings can also be obtained according to these drawings without creative labor for those skilled in the art.

[0040] Figure 1 FIG. 1 is a schematic diagram of a conventional phase of a practical Byzantine fault tolerance algorithm in an embodiment;

[0041] Figure 2 FIG. 2 is a schematic diagram of a view switching phase of a practical Byzantine fault tolerance algorithm in an embodiment;

[0042] Figure 3 FIG. 3 is a schematic diagram of a practical Byzantine fault tolerance algorithm in an embodiment;

[0043] Figure 4 FIG. 4 is a flowchart of a consensus algorithm in an embodiment of the present specification;

[0044] Figure 5 FIG. 5 is a schematic diagram of a consensus algorithm in an embodiment of the present specification;

[0045] Figure 6 FIG. 6 is a schematic diagram of a consensus algorithm in an embodiment of the present specification;

[0046] Figure 7 FIG. 7 is a schematic diagram of a consensus algorithm in an embodiment of the present specification;

[0047] Figure 8 FIG. 8 is a schematic diagram of a consensus algorithm in an embodiment of the present specification;

[0048] Figure 9is a schematic diagram of a consensus algorithm in an embodiment of the present specification;

[0049] Figure 10 is a schematic diagram of a consensus algorithm in an embodiment of the present specification;

[0050] Figure 11 is a distribution diagram of a consensus node in an embodiment of the present specification;

[0051] Figure 12 is a flowchart of a consensus method in an embodiment of the present specification;

[0052] Figure 13 is a schematic diagram of a consensus method in an embodiment of the present specification;

[0053] Figure 14 is a schematic diagram of a consensus method in an embodiment of the present specification. DETAILED DESCRIPTION

[0054] In order for those skilled in the art to better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described below in conjunction with the drawings in the embodiments of the present specification. Obviously, the described embodiments are only part of the embodiments of the present specification, not all the embodiments. Based on the embodiments in the present specification, all other embodiments obtained by those of ordinary skill in the art without creative labor should be within the scope of protection of the present specification.

[0055] In a blockchain system, different participants can establish a distributed blockchain network through deployed nodes. A decentralized (or multi-centralized) distributed ledger constructed by a chain structure of blocks is saved on each node (or on most nodes, such as consensus nodes) in the distributed blockchain network. Such a blockchain system needs to solve the consistency and correctness of the ledger data on each node of the decentralized (or multi-centralized) distributed ledger. Each node runs a blockchain program, and under the design of a certain fault tolerance requirement, a consensus mechanism is used to ensure that all loyal nodes have the same transaction, so as to ensure that the execution results of the same transaction by all loyal nodes are consistent, and the transaction and execution result are packaged to generate a block. Current mainstream consensus mechanisms include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT) algorithm, HoneyBadgerBFT algorithm, etc.

[0056] PBFT, for example, was proposed by Miguel Castro and Barbara Liskov in 1999, which solved the problem of low efficiency of the original Byzantine fault-tolerant algorithm, reduced the algorithm complexity from exponential to polynomial, and made the Byzantine fault-tolerant algorithm feasible in practical system applications. The paper was published in the 1999 International Conference on Operating Systems Design and Implementation (OSDI99). In the PBFT algorithm, all replicas run in a succession of configurations called views. In a view, one replica acts as the primary, and the others act as backups. The view is a consecutive integer. The primary is calculated by the formula p = v mod |R|, where v is the view number, p is the replica number, and |R| is the number of replicas. The algorithm assumes that when at most f replicas (i.e. nodes) fail, if there are at least 3f+1 replicas, it can guarantee security and liveness in an asynchronous system. In order to ensure the data consistency requirements and fault tolerance requirements of all replicas, a certain number of replica sets are required, which is generally a set of majority nodes in a distributed system, forming a Quorum. For example, in the case of total node number n = 3f+1 (n = 3f+2 or n = 3f generally does not bring improvement to fault tolerance effect), the Quorum is 2f+1. In this way, for a distributed system containing four nodes, any three nodes can form a Quorum.

[0057] PBFT includes Normal Case Phase and View Change Phase processes, Figure 1 is a flowchart of the Normal Case Phase process. Normal Case Phase mainly includes PRE-PREPARE, PREPARE, and COMMIT stages, where node 3, for example, can represent a down node (indicated by × in Figure 1 When the primary node fails (indicated by × in Figure 2 , such as Replica 0 (Replica 0) failing before the view is changed), the view change process needs to be started, so that the state is adjusted when the system fails, and a new primary node is replaced (such as Replica 1 being the primary node Primary after the view is changed). Figure 2Fig. 1 is a schematic diagram of the ViewChange Phase. If the primary node is offline or malicious and does not broadcast the client's request, etc., the client can set a timeout mechanism. If the timeout occurs, the client can broadcast the request message to all replica nodes. After detecting that the primary node is malicious or offline, the replica node can also initiate the View Change protocol phase to replace the primary node (often referred to as "change master"). In addition, the PRE-PREPARE, PREPARE and COMMIT three-phase consensus process may fail due to the primary node initiating an incorrect proposal, or the PREPARE and COMMIT phases may not reach a quorum number (e.g. 2f+1 nodes in 3f+1 nodes, also known as the quorum), and consensus cannot be completed. In these cases, the View Change protocol phase can also be initiated to replace the primary node.

[0058] PBFT protocol belongs to a partial synchronous protocol, which assumes that the network is initially asynchronous, but can be synchronized from a certain time. To reach consensus among different nodes on the same proposal in the network, the simplest way is to set a primary node to unify the opinions of each node. By setting a timer, the primary node can be prevented from making mistakes. In PBFT, if the Normal Case Phase is not completed within a limited time, the ViewChange Phase will be triggered to replace the primary node. PBFT fixes the primary node in one position, and all requests can be sent to the primary node first, and then broadcast to other consensus nodes by the primary node. In addition to introducing an additional delay to send the request to the primary node, the ingress and egress bandwidth of the primary node can also become a performance bottleneck.

[0059] PBFT and other single-primary protocols can only have the primary node initiate consensus proposals in the same consensus, and other nodes have no ability to initiate consensus proposals. Or, if other nodes also have proposals, the proposals need to be forwarded to the primary node for the primary node to initiate the proposals. The former is unfair to the power of block construction of consensus nodes, and the latter, although backup nodes can also propose, will increase the pressure on the egress bandwidth of the primary node. For the case where most consensus nodes need to initiate consensus proposals, neither of the two is particularly suitable.

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

[0061] Figure 3 This is a flowchart of the HoneyBadger BFT algorithm from a single-node perspective. In fact, as mentioned earlier, all nodes in the HoneyBadger BFT algorithm are peers, meaning that all nodes can execute. Figure 3 The process is shown below. Figure 3 As shown, from a single node's perspective, HoneyBadgerBFT mainly consists of two phases: Reliable Broadcast (RBC) and Asynchronous Binary Agreement (ABA, also known as "01 Asynchronous Consensus"). In addition, there is the Asynchronous Common Subset (ACS) protocol built upon RBC and ABA. The RBC phase includes at least three rounds of message interaction: Rval, Echo, and Ready. The ABA phase includes at least three rounds of message interaction: Bval, Aux, and Coin. RBC uses these three rounds of message interaction to ensure reliable proposal broadcasting. ABA first conducts two rounds of voting (Bval and AUX messages), and then uses a coin toss to unify the proposals of all nodes, thus bypassing the network synchronization requirements of semi-synchronous protocols. A single HoneyBadgerBFT consensus requires the RBC phase and at least one ABA phase. In the best-case scenario, there is a 1 / 2 probability that the current HoneyBadgerBFT consensus process can be completed, meaning it requires six rounds to achieve consensus. In addition, there is a 1 / 4 probability that it will enter another ABA process, such as Figure 3There is a 1 / 4 probability that the second ABA process (ABA processes represented by 7, 8, 9 rounds) will end at the second round, and there is at least a 1 / 4 probability that the HoneyBadgerBFT consensus process can end this time, so it takes 9 rounds to complete a consensus. After the second ABA process, there is a 1 / 8 probability that the whole process will enter another ABA process... and so on.

[0062] In summary, HoneyBadgerBFT includes at least one RBC (three rounds) and one ABA (three rounds), and if the voting result of ABA is inconsistent with the coin throwing result, the protocol enters a new round of ABA (at least three additional rounds). The round of consensus by coin throwing brings uncertainty and may increase the delay.

[0063] In addition, for a final block (corresponding to an epoch), a node can run an ACS and n RBCs + n ABAs, n is the number of consensus nodes, and 1 RBC and ABA correspond to the consensus proposal initiated by itself, and the other (n-1) RBCs and ABAs correspond to the consensus proposals initiated by the other (n-1) nodes. That is, for an epoch, a node initiates a consensus proposal while also completing the consensus proposals initiated by other nodes. In this way, for a node, at least (n-f) RBCs will be completed (indicated by the Ready message) and sent to the ACS, and then the ACS will assign initial values to the corresponding ABAs to start the corresponding ABA process. After at least (n-f) consensus proposals complete ABA, if the remaining consensus proposals have not completed RBC, they will be assigned an initial value of 0, and then the ABA process corresponding to the proposal will be executed. From a global perspective, at least (n-f) nodes will execute the same consensus process (at least (n-f) different nodes initiate the proposal process), and the ACS will eventually collect the ABA results of each proposal, sort the ABA results of the proposals with a value of 1 according to certain rules, and output the sorted results.

[0064] In the above process, contrary to PBFT, a strong proposal requirement is proposed for each node participating in consensus, that is, the node participating in consensus needs to initiate a proposal in each epoch, regardless of whether the node actually has a proposal. If the node actually has no proposal, it also needs to initiate a proposal request with empty content (the empty proposal request can be encrypted in RBC, so that other nodes cannot determine the content of the proposal to avoid malicious nodes selectively assigning input or output in the BA process because they can see the content of the proposal). Even if the node is a failed node and cannot send a proposal, the node's corresponding proposal still needs to be left a position in the ACS of other nodes. Specifically, after each of the other nodes performs at least Quorum ABA and all of them are consensus as 1, if the node's proposal corresponding to the RBC stage has not received Quorum Ready messages, the ACS needs to assign the node's proposal corresponding to the ABA initial value as 0, and then enter the ABA process. In this way, other nodes also need to cooperate to complete the ABA process of the proposal corresponding to the failed node.

[0065] The present application provides a consensus algorithm embodiment, as shown in the specific embodiments, which specifically includes: Figure 4

[0066] S41:

First round

[0067] In an embodiment of the consensus algorithm of the present application, three rounds of interaction can be included. Similar to HBBFT, Figure 5 the consensus algorithm of the embodiment shown also belongs to an asynchronous protocol, that is, it is assumed that the messages between nodes in the network can be arbitrarily delayed, but will eventually arrive. Similarly, Figure 5 the timer is also removed in the embodiment, and the execution of the protocol is driven by messages; at the same time, all nodes can be equal, without the distinction between master nodes and backup nodes, and any consensus node can initiate a consensus proposal, and each consensus node can also participate in the consensus process of the consensus proposal initiated by other nodes. The result of a consensus can include the sum of the transaction sets in the consensus proposals initiated by all nodes in this consensus and obtaining at least Quorum number of votes.

[0068] From the perspective of a node, for example, from the perspective of Node0 initiating a consensus proposal, the interaction process is as shown in Figure 5 In a consensus, Node0 can initiate a consensus proposal, which can include a packaged transaction set, for example, marked as m0, which can include a set of a series of transactions {tx 01 , tx 02 ,..., tx 0n ​Node0 can broadcast the first message to other consensus nodes, such as Figure 5 Node1, Node2 and Node3. The broadcasted first message can include the transaction set m0 of the consensus proposal of Node0. This message can be referred to as Val message.

[0069] In addition, the message can also include the signature of the first consensus node on m0, denoted as sig 00 Generally, the first consensus node Node0 can directly sign m0 with its private key to obtain sig 00 , or first hash m0 to obtain a hash value (i.e. digest value), and then sign the hash value with its private key to obtain sig 00 , or directly sign the data including m0 and ts0 with its private key or sign the hash value of the data including m0 and ts0.

[0070] The first message can also include a timestamp. The timestamp can be the physical time when or before the first consensus node broadcasts the first message, which can be determined by the local clock. If the consensus nodes in the blockchain network can achieve relatively accurate clock synchronization, the timestamp in the first message is also the relatively accurate time in the node receiving the first message.

[0071] Considering that there can be a certain physical distance between nodes, the propagation of messages has a non-negligible delay, therefore, the timestamp included in the first message can be determined based on the physical time when or before the first consensus node broadcasts the first message and the network transmission delay. For example, in a blockchain network including 4 consensus nodes, the average transmission delay or the maximum transmission delay of the first consensus node to the other three consensus nodes is Δ, then the timestamp in the first message is ts0=t0+Δ, where t0 can be the local physical time when the first consensus node broadcasts the first message. This Δ can be determined by RTT (Round-Trip Time), which generally represents the total time experienced from the sending end sending data to the receiving end in the network to the sending end receiving the confirmation from the receiving end. Generally, Δ can be half of RTT. For the case that the RTT between the first consensus node and the other three consensus nodes is different, the average of the three Δ or the maximum of the three Δ can be taken, specifically as or Δ=max(Δ1, Δ2, Δ3).

[0072] The format of Val message can be as follows: <ts0, m0, sig 00, wherein ts0 can represent the timestamp when Node0 initiates the consensus proposal, and m0 can represent the transaction set in the consensus proposal. The sig 00 may be the signature of Node0 on the data including ts0 and m0 using its own private key, or can be that m0 is first hashed to obtain a hash value, and then the signature of Node0 on the data including the hash value and ts0 using its own private key is obtained, so as to obtain sig 00 may also be the signature of Node0 on the data including m0 and ts0 using its own private key or the hash value of the data including m0 and ts0.

[0073] S43: The consensus node receiving the first message broadcasts a second message, and the second message includes the vote and signature on the transaction set; the vote includes the digest value of the transaction set m0.

[0074] At the end of the first round, the consensus node receiving the first message can verify the correctness of the received first message. For example, Node1 can verify the signature of Node0 in the first message using the public key of Node0. If the verification is passed, S43 is entered.

[0075] S43, specifically as Figure 5 The consensus node receiving the first message can broadcast a second message. In the second round of message interaction, Node1, Node2, and Node3 broadcast second messages to other consensus nodes respectively. The second message broadcast by the consensus node can include the vote on the consensus proposal initiated by Node0.

[0076] For example, Node1, Node2, and Node3 can tell other consensus nodes their votes on the consensus proposal by broadcasting the second message, and the vote can be to approve or disapprove the transaction set in the consensus proposal. Specifically, at the end of the first round, the consensus node receiving the Val message can calculate the hash value of the transaction set in the consensus proposal in the Val message. Then, if the consensus node approves the transaction set proposed by Node0 in this consensus, it can broadcast the hash value in the second round of message interaction. On the contrary, if the consensus node does not approve the transaction set proposed by Node0 in this consensus, it can broadcast 0 in the second round of message interaction. This broadcasted second message can be denoted as Bval. In addition, 1 can be used to represent the approval or pass of the vote on the proposal represented by the hash value, and 0 can be used to represent the disapproval or not pass of the vote on the proposal represented by the hash value, which is only a simple change.

[0077] In this round, Node0 can not participate in the broadcast, because Node0 initiates the consensus proposal in the first round, and itself can represent that the set of messages in the consensus proposal is approved, so in the second round, Node1, Node2, and Node3 can broadcast the second message to other consensus nodes, respectively.

[0078] It should be noted that the consensus node can change its own opinion and vote again, that is, send multiple different Bval messages. For example, Node1 can first send a Bval message with the content being the hash value of the set of transactions to indicate approval of the set of transactions in the consensus proposal, and then send a Bval message with the content being 0 again to indicate disapproval of the set of transactions in the consensus proposal. For another example, Node2 can first send a Bval message with the content being 0 to indicate disapproval of the set of transactions in the consensus proposal, and then send a Bval message with the content being the hash value of the set of transactions again to indicate approval of the set of transactions in the consensus proposal.

[0079] In addition, the second message can also include a signature of the set of transactions. As mentioned before, the consensus node receiving the first message at the end of the first round can verify the correctness of the received first message, for example, Node1 verifies whether the signature of Node0 is correct. Further, the consensus node receiving the first message can sign the set of transactions in the first message with its own private key. For example, Node1 signs the set of transactions m0 in the first message to obtain sig 10 . It can also be that Node1 first signs the hash value of m to obtain sig 10 .

[0080] Similarly, the format of the Bval message can be <ts0, hash, sig 10 >, where ts0 can be ts0 in the received Val message, hash is the hash value of m0, indicating that the voting opinion of m0 is approval. The sig 10 may also be a signature of the data including ts0 and m0 with its own private key. Similarly, it can also be a signature of the data including the hash value of m0 and ts0 to obtain sig 10 . It can also be a hash value of the data including ts0 and hash signed with its own private key.

[0081] After receiving the Val message sent by Node0, Node2 can also calculate the hash value of m0 in the Val message, and sign the hash value with its own private key to obtain sig 20, and the signature sig 20 , and the signature sig 20 .

[0082] Node3 receives the Val message sent by Node0, and similarly, it can calculate the hash value of m0 in the Val message, and sign the hash value with its own private key to obtain sig 30 , and further broadcast the Bval message. The Bval message can include the calculated hash value and the signature sig 30 , or include ts0, the hash value and the signature sig 20 .

[0083] S45: In the third round, if the consensus node receiving the second message collects at least Quorum consistent votes from different consensus nodes, and if the consensus node has not broadcasted a different vote for the proposal, the consensus node broadcasts a third message, and the third message includes the digest value and the collected signatures.

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

[0085] For example, Node0 can collect the votes in the Bval message at the end of the second round. Assuming that Node0 collects the votes in the Bval messages broadcasted by Node1, Node2 and Node3, and the votes are all the hash value of the transaction set m0, and Node0 broadcasted the Val message in the first round is also m0, and the corresponding hash value is obviously the hash value of m0, then Node0 collects at least Quorum consistent digest values (for example, f=1, Quorum=3, and actually 4 are collected) in this round.

[0086] For example, Node1, at the end of the second round, can collect the votes in the Bval message. Assuming that Node1 collects the votes in the second message broadcasted by Node2 and Node3 respectively are the hash value of the transaction set m0, and the vote in the second message broadcasted by Node1 in the second round is also the hash value of the transaction set m0 (also indicating the approval of the transaction set), and the m0 in the Val message sent by Node0 received in the first round is also the same hash value, then Node1 collects at least Quorum consistent digest values in this round (for example, f = 1, Quorum = 3, and actually 4 are collected). It should be noted that in the first round, the Val message broadcasted by Node0 can include m0, so that at the end of the first round, Node1 can calculate the hash value of m0 included in the Val message, so as to count whether the hash value of m0 in the Bval message broadcasted by Node1 in the second round is the same as the hash value of m0 in the Val message broadcasted by Node0 in the first round, and whether the hash value of m0 in the Bval message broadcasted by Node1 in the second round is the same as the hash value of m0 in the Val message broadcasted by Node2 and Node3 in the second round, and then whether at least Quorum consistent hash values from different consensus nodes are collected.

[0087] Node2 and Node3 are similar to Node1 and will not be repeated.

[0088] In addition, the consensus node can also collect the signatures of different nodes at the end of the second round, as described above. The number of votes collected in the second round can be counted by the signature. For example, Node1 collects sig 10 , sig 20 , and sig 30 of the same hash value, which means that there are 3 votes indicating approval for the hash. Of course, 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 created by technologies such as Message Authentication Code (MAC), Transport Layer Security (TTL), etc.

[0089] For Node1, if it collects at least Quorum consistent hash values from different consensus nodes and has not broadcasted 0 (i.e. different vote) for the proposal m0, it broadcasts a third message. The third message can be denoted as Prom message, meaning a promise not to change the opinion for the proposal m0. As mentioned before, the hash value for m0 can represent an approval, and 0 can represent a disapproval. Node1 has not broadcasted 0 for the proposal m0 means that it has not held a disapproval opinion for the proposal m0, and of course, other forms can be used to represent the disapproval. Node2 and Node3 are similar.

[0090] The third message broadcasted can include the collected votes for m0, such as the hash values and signatures collected in the first and second rounds.

[0091] The format of the Prom message can be <ts0, hash, <signature set>>.

[0092] For example, Node0, assuming that Node0 collects the votes in the Bval messages broadcasted by Node1, Node2, Node3 in the second round are all hash values of the transaction set m0, so it collects the signatures of Node1, Node2 and Node3 for m (or hash value of m0) are sig 10 , sig 20 , sig 30 respectively, and the hash value of the signature of Node0 for m0 (or hash value of m0) in the Val message broadcasted by Node0 in the first round is sig 00 . Thus, Node0 collects at least Quorum consistent hash values in this round (e.g. Quorum = 3 at this time). Further, the Prom message broadcasted by Node0 in the third round can include the hash value and the collected hash values and signature sets of different nodes representing approval for the proposed transaction set m0, such as sig 00 , sig 10 , sig 20 , sig 30 .

[0093] For example, assuming that Node1 collects the votes in the Bval messages broadcasted by Node2, Node3 in the second round are all hash values of the transaction set m0, so it collects the signatures of Node2 and Node3 for m0 (or hash value of m0) are sig 20 , sig 30Node0's vote, and Node0 also includes its signature sig 00 Node1's vote, and Node1 also includes its signature sig 10 Node1's vote. In this way, Node1 collects at least Quorum consistent hash values (e.g. Quorum = 3 at this time) and signatures of different nodes in the first and second rounds. Further, Node1 can include the hash value and the collected hash values and signature set of different nodes representing approval for the proposed transaction set m0 in the Prom message broadcast in the third round, and the signature set includes, for example, sig 00 , sig 10 , sig 20 , sig 30 .

[0094] Node2 and Node3 are similar to Node1.

[0095] It should be noted that the above signature set can also be replaced by an aggregated signature or a threshold signature.

[0096] S47: After the consensus node collects at least Quorum third messages from different nodes, the consensus node outputs the transaction set corresponding to the hash value as a consensus result sorted according to the timestamp.

[0097] After the third round is executed, the consensus node receiving the Prom message can count the number of collected Prom messages. The consensus node sends the Prom message in the third round on the condition that it collects at least Quorum consistent votes from different consensus nodes in the second round, and it does not broadcast a different vote for the proposal, that is, at the end of the second round, the consensus node confirms that at least Quorum consensus nodes (including itself) agree with the vote for the proposal m0. However, the consensus result cannot be output immediately after the second round ends, but it also needs to be observed whether other nodes also collect at least Quorum votes representing approval for the proposal m0 at the end of the second round, so it needs to be confirmed through the Prom message in the third round, and it promises that it will not express a different opinion for the same proposal m0 through the Prom message.

[0098] For example, Node0 collects at least Quorum consistent hash values in the first and second rounds, and further, Node0 can include the hash value and the collected hash values and signature set of different nodes representing approval for the proposed transaction set m0 in the Prom message broadcast in the third round, and the signature set includes, for example, sig 00, sig 10 , sig 20 , sig 30 .

[0099] For example, Node1 collects at least Quorum consistent digest values in the first round and the second round, and then, Node1 can include the hash value and the set of hash values and signatures that different nodes approve of the proposed transaction set m0 in the Prom message broadcasted in the third round, the set of signatures for example includes sig 00 , sig 10 , sig 20 , sig 30 .

[0100] Node2 and Node3 are similar to Node1.

[0101] In this way, through the third round, for example, Node0 can collect at least Quorum Prom messages. Through at least Quorum Prom messages, Node0 can confirm that each of at least Quorum consensus nodes collects at least Quorum number of votes that approve of the proposed transaction set m0, and each consensus node that sends the Prom message promises not to change the opinion of the vote any more, so Node0 can further complete this consensus.

[0102] In the above embodiment, firstly, the consensus can be completed in 3 rounds under certain conditions, which greatly reduces the delay caused by the consensus process compared with at least 6 rounds in HBBFT. In fact, in the embodiment of the present application, the last two rounds of RBC process and the first two rounds of ABA process in HBBFT are combined by using the foresight voting and digital signature technology, thereby shortening the required rounds. The foresight voting refers to the voting in the Bval of the second round in the above embodiment, while HBBFT needs to vote in the Bval of the fourth round 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.

[0103] In addition, m0 can correspond to ts0, as described above. In fact, Node0 can initiate two different first messages in parallel or in sequence. For example, Node0 can initiate the three-round process of m4 (corresponding to hash4) in parallel or before / after the three-round process of m0 (corresponding to hash0). Assuming that m4 corresponds to ts4, ts4 > ts0. When the nodes Node0 initiating the consensus proposal and the nodes Node1, Node2, and Node3 participating in the consensus output the consensus result, the nodes can be sorted according to the timestamps in chronological order, so that the consensus result m0 is placed before m4. Correspondingly, the block corresponding to the finally generated m0 has a block height less than the block corresponding to m4.

[0104] Each of the at least Quorum number of consensus nodes in the blockchain system can execute the above-mentioned first to third rounds of processes as a first consensus node. For example, the embodiments of the above-mentioned Figure 5 may be extended to be executed by Node0, Node1, Node2, and Node3. Node1, Node2, and Node3 each execute as a first consensus node, and can also be executed as shown in Figure 6 、 7 , 8. Thus, it can be a superposition of Figure 5 、 6 , 7, 8 from the overall perspective. For example, Node0 initiates a consensus proposal of a transaction set m0 and a timestamp ts0, Node1 initiates a consensus proposal of a transaction set m1 and a timestamp ts1, Node2 initiates a consensus proposal of a transaction set m2 and a timestamp ts2, and Node3 initiates a consensus proposal of a transaction set m3 and a timestamp ts3. Thus, m0 can correspond to hash0, m1 can correspond to hash1, m2 can correspond to hash2, and m3 can correspond to hash3. Assuming that ts3 > ts1 > ts2 > ts0, the local consensus results of Node0, Node1, Node2, and Node3 are m0, m2, m1, and m3, respectively, that is, the results sorted according to the timestamps. m0, m2, m1, and m3 can correspond to a final block, respectively. The above-mentioned sorting can be performed by the ACS protocol of the consensus node after collecting the consensus results. Specifically, the ACS can collect the results of each consensus proposal, sort the consensus results according to the timestamps of each consensus proposal, and output the sorted results.

[0105] The sorting according to the timestamps considering the transmission delay fully considers the time of the end of the consensus, that is, the order of generating the block is as consistent as possible with the order of completing the consensus result.

[0106] In this way, by the above manner, the relative position of the corresponding block on the block chain can be determined when the consensus proposal is proposed. Moreover, for a finally generated block, the consensus proposal included in the block corresponds to the generation process of a consensus result, and the consensus result does not need to wait for the results of other consensus proposals, and the consensus result can be quickly output. This also saves the need to wait for the completion of other consensus proposals in the generation process of a consensus result. For a consensus node without a proposal, it is not necessary to propose a consensus proposal with actual empty content, which reduces the consumption of network bandwidth. For a failed node that cannot propose a consensus proposal, in the above embodiment, as long as the number of normal working nodes reaches the Quorum number, the generation process of the consensus result does not need to be timed out to 0 and then enter the ABA process as in HBBFT, but can skip the failed node, thereby greatly reducing the latency of consensus.

[0107] In the embodiment of the present application, similar to PBFT and HBBFT, a certain number of error nodes can be tolerated, for example, f error nodes can be tolerated in a total of n=3f+1 consensus nodes, and the Quorum is 2f+1. An example of f (f=1) failed nodes is given below.

[0108] For example, as shown in Figure 9 and Figure 10 Superimposed, assuming that Node3 is a failed node.

[0109] As shown in Figure 9

[0110] In the first round, Node0 broadcasts the Val message, and the format of the Val message can be as follows: <ts0, m0, sig 00 , wherein ts0 can represent the timestamp of the consensus proposal initiated by Node0, and m0 can represent the transaction set in the consensus proposal. The sig 00 may be a signature of Node0 on the data including ts0 and m0 using its own private key, or a hash value of m0 can be calculated first, and then the hash value and ts0 are signed with the private key of Node0 to obtain the sig 00 , or the data including m0 and ts0 can be directly signed with the private key of Node0 or the hash value of the data including m0 and ts0.

[0111] At the end of the first round, the consensus nodes receiving the Val message can verify the correctness of the received Val message. Specifically, Node1 can use the public key of Node0 to verify the signature sig 00 ​Node 2 can verify the signature sig 00 Node 3 is a failed node, it does not respond, i.e. does not broadcast a Bval message.

[0112] In the second round, the consensus nodes receiving the Val message broadcast a Bval message, which includes a vote and a signature for the transaction set m0. The vote includes the hash value of the transaction set m0. Since Node 3 is a failed node, it does not respond, i.e. does not broadcast a Bval message, while Node 1 and Node 2 broadcast a Bval message to other consensus nodes respectively. The Bval message broadcast by Node 1 includes, for example, the hash value of m0 and a signature sig 10 Node 1 uses its private key for m0 and ts0. 10 >, where sig 10 is the signature of Node 1 for the data including ts0 and the hash value of m0.

[0113] Similarly, Node 2 can also calculate the hash value of m0 in the Val message and use its private key to sign the hash value and ts0 to obtain sig 20 , and then broadcast a Bval message.

[0114] At the end of the second round, the consensus nodes receiving the Bval message can collect the votes in the Bval. For Node 0, at the end of the second round, the votes in the Bval message are collected, which include the hash value of m0 broadcast by Node 1 and Node 2 respectively, and the signature sig 10 and sig 20 , and the signature sig 00 broadcast by Node 0 in the Val message in the first round. Therefore, Node 0 collects a total of 3 consistent hash values (f = 1, Quorum = 3) at the end of the second round. For Node 1, at the end of the second round, the votes in the Bval message broadcast by Node 2 include the hash value of m0 and sig 20 , and the votes in the Bval message broadcast by Node 1 in the second round also include the hash value and sig 10and m0 in the Val message sent by Node0 received in the first round is also the same hash value and sig 00 Then Node1 collects 3 consistent hash values in this round, which meets the Quorum number. For Node2, the votes in the Bval message broadcast by Node1 at the end of the second round are the hash value and sig of m0 10 , and the votes in the Bval message broadcast by Node2 in the second round are also the hash value and sig 20 , and m0 in the Val message sent by Node0 received in the first round is also the same hash value and sig 00 Then Node2 collects 3 consistent hash values in this round, which meets the Quorum number.

[0115] In the third round, if the consensus node receiving the Bval message collects at least Quorum consistent hash values from different consensus nodes and has not broadcast 0 for the proposal, it broadcasts a Prom message, and the Prom message includes the hash value and the collected signatures.

[0116] For example, the Prom message broadcast by Node0 in the third round can include the hash value and the hash values and signature sets of the transaction set m0 representing the approval of different nodes for the proposal, and the signature set is sig 00 , sig 10 , sig 20 . The Prom message broadcast by Node1 in the third round can include the hash value and the hash values and signature sets of the transaction set m0 representing the approval of different nodes for the proposal, and the signature set is also sig 00 , sig 10 , sig 20 . The Prom message broadcast by Node 20 in the third round can include the hash value and the hash values and signature sets of the transaction set m0 representing the approval of different nodes for the proposal, and the signature set is also sig 00 , sig 10 , sig 20 .

[0117] After the third round is executed, the consensus node receiving the Prom message counts the number of collected Prom messages, and if at least Quorum Prom messages from different nodes are collected, the transaction set m0 corresponding to the hash value is output as the consensus result.

[0118] For Node0, it collects 3 Prom messages broadcasted by Node1 and Node2 after the third round, and it also broadcasts a Prom message, so it collects 3 Prom messages in total.

[0119] Similarly, for Node1, it collects 3 Prom messages broadcasted by Node0 and Node2 after the third round, and it also broadcasts a Prom message, so it collects 3 Prom messages in total.

[0120] Similarly, for Node2, it collects 3 Prom messages broadcasted by Node0 and Node1 after the third round, and it also broadcasts a Prom message, so it collects 3 Prom messages in total.

[0121] Through the third round, Node0 collects 3 Proms, and it can confirm that each of the at least 3 consensus nodes (satisfying Quorum) collects at least 3 votes (satisfying Quorum) indicating approval of the proposed transaction set m0, and each consensus node that broadcasts a Prom message promises not to change the opinion of the vote any more, so Node0 can further complete this consensus, i.e., output the transaction set m0 corresponding to the hash value as the consensus result. Node1 and Node2 are similar, i.e., Node1 and Node2 also output the transaction set m0 corresponding to the hash value as the consensus result.

[0122] Similarly, as shown in the process of Figure 10 Node2 broadcasts a Val message, the format of the Val message can be as shown in <ts2, m2, sig 22 Finally, Node2 outputs the transaction set m2 as the consensus result. Node0 and Node1 are similar, i.e., Node0 and Node1 also output the transaction set m2 as the consensus result.

[0123] Suppose the timestamp of m0 is ts0 and the timestamp of m2 is ts2, and ts2>ts0, then Node0, Node1 and Node2 each locally generate two consensus results. Each consensus node can sort the two consensus results according to the timestamp, and the sorting result is m0, m2. For the two blocks finally generated, the block height of the block corresponding to m0 is smaller, and the block height of the block corresponding to m2 is larger.

[0124] In the above embodiments, the relative position of the corresponding block on the blockchain is determined when a consensus proposal is proposed. Furthermore, for a final generated block, which contains a consensus proposal (corresponding to the generation of a consensus result), this consensus result does not need to wait for the results of other consensus proposals and can be output quickly. This eliminates the need to wait for and coordinate with 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 with actually empty content, reducing network bandwidth consumption. For failed nodes unable to propose consensus proposals, in the above embodiments, as long as the number of normally functioning nodes reaches the Quorum, the process of generating a consensus result does not need to time out and assign a value of 0 before entering the ABA process as in HBBFT; instead, the failed node can be skipped, thereby significantly reducing consensus latency.

[0125] In practical blockchain applications, the above embodiments are of greater significance for specific situations. For example... Figure 11 As shown, for example, four nodes forming a consortium blockchain are deployed in different countries. UK Located in the UK, Node DE Located in Germany, Node FR Located in France, Node CN Located in China. Clearly, Node is located in Europe. UK Node DE and Node FR The communication latency between the three nodes is low, and these three nodes are connected to the Node located in Asia. CN The communication latency is relatively high. Assume Node... UK Node DE and Node FR The communication latency between the three nodes is 10ms. These three European nodes and Node CN The communication latency is 80ms. If HBBFT is used, the three nodes located in Europe out of these four nodes can form a Quorum, and each can complete the RBC process within a little over 30ms, and the ABA process within another 30ms. Meanwhile, Node... CN Since the initiated proposals are always executed relatively slowly, Node... CN The proposed RBC process has a high probability of not being completed before the ABA processes of the other three nodes finish, therefore Node CN The proposal is to assign a value of 0 in the initialization of ABA, thus Node CN The proposal is often not included in the generated block (there is a greater than 1 / 2 probability based on the coin toss result), which is equivalent to Node. CNoften lose the right to construct blocks. Moreover, even if Node CN owns the right to construct blocks, a larger delay will slow down the process of a consensus.

[0126] However, according to the consensus scheme of the above embodiments of the present application, the proposal of each node can be individually blocked (a block is generated), and the consensus result is sorted according to the timestamp, so that the relative position of the block is determined when the consensus proposal is initiated without losing the right to construct the block. In particular, for a failed node, it does not need to wait for it to initiate a consensus proposal, and other nodes also do not need to cooperate with it to complete the consensus. In other words, the completed consensus result can be sorted according to the actual proposal demand and the timestamp order. In addition, the consensus node without a proposal also does not need to initiate a proposal with an actual empty content, thereby reducing the consumption of network bandwidth.

[0127] As mentioned above, the above embodiments are sorted according to the timestamp considering the transmission delay, fully considering the time of the end of the consensus, that is, the order of the generated block is as consistent as possible with the completion order of the consensus result. Assuming that Node UK , Node DE and Node CN all initiate a consensus proposal, Node UK initiates a consensus proposal at a local physical time of 60 ms, then the timestamp ts UK of the first message is 60+10=70 ms, Node DE initiates a consensus proposal at a local physical time of 70 ms, then the timestamp ts DE of the first message is 70+10=90 ms, Node CN initiates a consensus proposal at a local physical time of 10 ms, then the timestamp ts cN of the first message is 10+80=90 ms. If sorted according to the local physical time, the order is m CN →m UK →m DE , but this does not match the generation of the consensus result, and therefore it is not reasonable, otherwise, the consensus result completed first needs to wait for the consensus result completed later, and the generation order of the block will be delayed. After considering the transmission delay, the completion order of the consensus result is probably the same as the timestamp, so the generation order of the block will not be delayed.

[0128] In particular, for the same proposal, the second message and the third message have the same timestamp as the first message, which can be used to identify the consensus process of the same proposal, without introducing other identifiers, thereby saving the data amount of the protocol process.

[0129] In PBFT, 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. Specifically, for example, in a consensus, the Pre-prepare message initiated by the consensus master node contains a sequence number with a value of 3. In the subsequent Prepare message and Commit message in this consensus, the same sequence number with a value of 3 is contained. Thus, after this consensus, each consensus node can determine the order of the result of this consensus in the sequence of multiple consensus results before and after. This order can generally be used to determine the order of the consensus nodes to execute the consensus result and generate blocks. For the consensus result with a sequence number value of 3, the consensus node can arrange it to be executed or blocked 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 to 4, so as to initiate the Pre-prepare message with a sequence number value of 4 in the next consensus. Correspondingly, in the subsequent Prepare message and Commit message, the sequence number value is 4. Similarly, for the consensus result with a sequence number value of 4, the consensus node can arrange it to be executed or blocked 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 to 5,.... In this way, each consensus node can be ensured to execute the same consensus result in the same order, thereby ensuring the consistency of the blocks generated on each consensus node.

[0130] In HBBFT, there is also a sequence number with the same effect.

[0131] And the above Figures 4-11In the consensus algorithm in the embodiments, the relative position of the corresponding block on the block chain is determined by means of a timestamp when the consensus proposal is proposed, a finally generated block contains a consensus proposal, so that the consensus result does not need to wait for the results of other consensus proposals, thereby being able to quickly output the consensus result. The timestamp is relatively loose and does not have the dense incremental property of the sequence number, so it cannot strictly guarantee the execution order of the blocks. For example, for a consensus node, it can have completed a consensus result with a timestamp of 80.5 ms, a consensus result with a timestamp of 100.8 ms and a consensus result with a timestamp of 135.2 ms. The three consensus results can be determined by the relative execution order and then the block order through the timestamp, but whether there are other consensus results between the consensus result with the timestamp of 80.5 ms and the consensus result with the timestamp of 100.8 ms, and whether there are other consensus results between the consensus result with the timestamp of 100.8 ms and the consensus result with the timestamp of 135.2 ms cannot be determined through the timestamp. If another consensus node has a consensus result with a timestamp between 80.5 ms and 100.8 ms, or has a consensus result with a timestamp between 100.8 ms and 135.2 ms, it is difficult to guarantee the consistency of the generated blocks between different consensus nodes. In order to guarantee the consistency of the generated blocks on each consensus node, each consensus node needs to execute the same consensus result in the same order. Therefore, a mechanism is needed to ensure that each consensus node executes the same consensus result in the same order.

[0132] In an embodiment provided in the present application, each consensus node processes messages in a FIFO (First Input First Output) manner. The FIFO queue is a traditional method of executing in order, where the first instruction entered is completed first, and then the second instruction is executed. In order to ensure that the messages between the correct consensus nodes meet the FIFO, each sent message can be numbered, and the receiver is required to process the request in order of the number. The TCP protocol can also be used to ensure the sequential transmission of messages. TCP provides reliable data transmission, avoiding retransmission, reversal of order, or loss of data packets. The consensus node can number the message and press it into the network transmission layer when sending the message each time. The network transmission layer uses the TCP protocol and sends the TCP packet converted by the upper layer protocol to the receiver in order, and waits for the receiver to confirm the TCP packet within a certain time. If the consensus node does not receive the confirmation of the receiver within a certain time, the TCP packet is resent. If the receiver returns the confirmation of the TCP packet within a certain time, the consensus node sends the next TCP packet. This cycle continues until the upper layer protocol data is sent. Once the receiver receives all the TCP packets of an upper layer protocol message, it can perform CRC (Cyclic Redundancy Check), and if correct, the data packets are reorganized into a data stream in the correct order and passed to the upper layer protocol for processing, and the next sequence number of the upper layer protocol TCP packet is sent. In addition, SSL / TLS communication can also be used to ensure the implementation of FIFO.

[0133] The present application also provides an embodiment, which can be as shown in Figure 12 , comprising:

[0134] S121: The first consensus node broadcasts a first message in the first round, and the first message includes a consensus proposed transaction set, a timestamp, and a signature of the first consensus node;

[0135] S123: The consensus node receiving the first message broadcasts a second message in the second round, and the second message includes a vote on the transaction set and a signature; the vote includes an abstract value of the transaction set;

[0136] S125: After the consensus node receiving the second message collects at least Quorum consistent votes from different consensus nodes, if it has not broadcast a different vote for the proposal, it broadcasts a third message, and the third message includes the abstract value and a collected signature set;

[0137] S127: After the consensus node collects at least Quorum third messages from different nodes indicating a vote of pass, the consensus node outputs the transaction set corresponding to the digest value as a consensus result ordered according to the timestamps.

[0138] For example, the first consensus node Node0 can locally maintain a sequence of critical instants {t 01 ,t 02 ,......}. During the above S121-S127, when a critical instant t is passed, Node0 can broadcast a fourth message to indicate that it has passed the critical instant, for example, Pass(t Figure 13 ). Such a fourth message is, for example, a Pass(t) message, where the message name Pass indicates that the message is a message indicating the passing of a critical instant, and the parameter t included in the message is the critical instant. Here, for example, Pass(t 02 ) is broadcast.

[0139] Similarly, Node1 can also locally maintain a sequence of critical instants {t 11 ,t 12 ,......}. During the above S121-S127 (from a local perspective, it can also be during S121-S125, which will not be repeated below), when a critical instant t is passed, Node1 can broadcast a fourth message to indicate that it has passed the critical instant, for example, Pass(t 12 ). Node2 also similarly locally maintains a sequence of critical instants {t 21 ,t 22 ,......}. During the above S121-S127, when a critical instant t is passed, Node2 can broadcast a fourth message to indicate that it has passed the critical instant, for example, Pass(t 24 ). Node3 also similarly locally maintains a sequence of critical instants {t 31 ,t 32 ,......}. During the above S121-S127, when a critical instant t is passed, Node3 can broadcast a fourth message to indicate that it has passed the critical instant, for example, Pass(t 33 ). The above is shown in Figure 14 . Figure 13 、 14 The sequence of critical instants shown in

[0140] The consensus nodes participating in the consensus can each maintain a local sequence of critical instants. The local sequences of critical instants maintained by the consensus nodes participating in the consensus can be the same, can not be completely the same, or can be completely different. For the case of being completely the same, it is often necessary to send the sequence of critical instants to each participating consensus node in a centralized manner, or to negotiate or synchronize between the participating consensus nodes. For the case of being completely different, each node participating in the consensus can determine the sequence of critical instants according to a local clock, so that it is not necessary to send the sequence of critical instants to each participating consensus node in a centralized manner, or to negotiate or synchronize between the participating consensus nodes. As for the case of not being completely the same, the sequence of critical instants can be sent to each participating consensus node in a centralized manner, and then each consensus node adds a certain number of other critical instants on this basis, or part of the sequence of critical instants is negotiated or synchronized between the participating consensus nodes, and then each consensus node adds a certain number of other critical instants on this basis; of course, it can also be the case that the sequence of critical instants is determined by each node participating in the consensus according to a local clock and then partially coincides.

[0141] The consensus node broadcasts the Pass(t) message, in addition to indicating that it has passed the critical instant t, it can also represent a commitment to vote 0 for proposals with timestamps less than the critical instant t thereafter, or to no longer process consensus proposals with timestamps before the critical instant t. In this way, after the consensus node collects at least Quorum Pass(t) messages (including the latest broadcast Pass(t) message of itself), it can obtain the critical instants in these messages, for example, the minimum critical instant in at least Quorum fourth messages. Therefore, the consensus node can confirm that at least Quorum consensus nodes have passed the critical instant t, so that it can reach an agreement on "voting 0 for consensus proposals with timestamps less than t thereafter" or "no longer processing consensus proposals with timestamps less than t". In this way, by broadcasting the Pass message and executing according to the agreed commitment content, the effect similar to FIFO can also be indirectly achieved, but consensus proposals that have not been voted before the critical instant t may not be able to pass the consensus, or even if they pass the vote, they may not be processed; if they cannot pass the consensus or are 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 can broadcast multiple Pass messages with different critical instants, so for multiple Pass messages with different critical instants received from the same node, the latest critical instant can be taken.

[0142] The aforementioned broadcast Pass message can be completed by at least Quorum consensus nodes. Thus, each consensus node broadcasting a Pass message can receive at least (Quorum-1) number of Pass messages from other consensus nodes, and combined with its own broadcast Pass message, it can collect at least Quorum number of Pass messages. Each participating consensus node maintains its own key moment sequence locally, so the key moments in the latest Pass messages broadcast by each consensus node may be the same or different. Even if the participating consensus nodes maintain the same or partially the same key moment sequence locally, the key moments in the latest Pass messages broadcast by each consensus node may still be the same or different. If the participating consensus nodes maintain completely different key moment sequences locally, then the key moments in the latest Pass messages broadcast by each consensus node will definitely be different. If the key moments in the latest Pass messages collected (at least Quorum number) are the same, then a consensus can be reached on either "voting 0 for consensus proposals with timestamps less than t thereafter" or "no longer processing consensus proposals with timestamps less than t". If the key moments in the collected Pass messages of at least the required Quorum number are different, for example, in the above example, the key moments in the four latest Pass messages collected by Node0 to Node3 (at this time, Quorum = 3) are Pass(t) 02 ), Pass(t) 12 ), Pass(t) 24 ) and Pass(t 33 ), and the smallest of them is t. 02 Then, it is possible to set the timestamp to be less than t afterward. 02 The consensus proposal vote is 0 or "No more processing timestamps less than t". 02 An agreement was reached on the "consensus proposal".

[0143] The following provides an embodiment of a consensus method, combined with Figures 4-14 The following examples illustrate the specific timing for sending the Pass message.

[0144] exist Figures 4-14 In a corresponding embodiment, the consensus node that receives the Val message broadcasts a Bval message, which includes votes and signatures on the transaction set proposed in the first message.

[0145] Once a consensus node that receives the Bval message has collected at least Quorum of consistent votes from different consensus nodes, it can be considered that a critical moment t has passed. This critical moment t is the timestamp in the Val message during this consensus process, for example, ts. Then, the Pass(ts) message can be broadcast to other consensus nodes.

[0146] Further, any consensus node can no longer process or vote as not passed for consensus proposals with time stamp before the critical time ts after collecting at least Quorum number of Pass(ts). For example, for other consensus with Val message with time stamp smaller than ts, vote Bval(0) for it, 0 often means not passed in voting of consensus algorithm. Thus, for any new consensus proposal with time stamp behind, at least Quorum number of consensus nodes think its time stamp is later than the critical time ts, thus vote 0 for it in Bval(0), the consensus proposal with time stamp behind will not be included in the newly generated block. Thus, at least Quorum number of consensus nodes can execute the blocks corresponding to the s of consensus in time sequence. If there is a consensus proposal with earlier time stamp that has completed voting in consensus, i.e. consensus proposal with completed Bval round, when broadcasting the fourth message, the consensus of the consensus proposal with earlier time stamp is completed, then output the transaction set corresponding to the digest value as the consensus result in time sequence of the time stamp. Thus, the completion order of consensus result is guaranteed.

[0147] On the other hand, if the consensus node receiving the second message collects at least Quorum number of consistent votes from different consensus nodes, and has not broadcasted different votes for the proposal itself, then broadcast the third message, the third message including the digest value and the collected signature set; after the consensus node collects at least Quorum number of third messages from different nodes, output the transaction set corresponding to the digest value as the consensus result in time sequence of the time stamp.

[0148] As an alternative, the Pass message is placed in the third message for broadcasting, without the need of broadcasting the fourth message additionally, thus saving the number of messages needed to be transmitted in the protocol. Specifically, if the consensus node receiving the second message collects at least Quorum number of consistent votes from different consensus nodes, and has not broadcasted different votes for the proposal itself, then broadcast the third message, the third message including the digest value, the collected signature set and the critical time, the critical time being the time stamp in the first message. Further, any consensus node can no longer process or vote as not passed for consensus proposals with time stamp before the critical time after collecting at least Quorum number of third messages from different nodes. Similarly, after collecting at least Quorum number of third messages from different nodes, the consensus node can also output the transaction set corresponding to the digest value as the consensus result in time sequence of the time stamp.

[0149] The above scheme can be referred to as a "cooperative mode", because such a scheme can complete consensus faster. Moreover, this way can directly rely on the timestamp in the first message initiating the consensus proposal, without the need for consensus nodes to maintain the sequence of critical moments locally, reducing the implementation cost and complexity.

[0150] The above scheme for the cooperative mode, although it can complete consensus faster, has certain risks. For example, if there is a malicious node that proposes a consensus proposal with a later timestamp immediately after a loyal node proposes a consensus proposal, since the consensus proposal of the loyal node has not entered or has not completed the second round in the aforementioned consensus method embodiments of the application, if the consensus proposal with a later timestamp proposed by the malicious node completes the second round first, the consensus proposal of the loyal node will eventually be 0, i.e. the vote is not passed or not processed. In this way, the consensus proposal initiated by the loyal node will have the risk of being filtered out due to the attack of the malicious node. Even if there is no malicious attack, but the network delay or the clock offset suddenly increases, it can also cause some blocks to be consensused as 0 or not processed due to arriving at other nodes later than expected.

[0151] Based on this, the present application gives a "competitive mode" consensus method embodiment, still in combination Figures 4-14 The specific timing of sending the Pass message is illustrated by an embodiment.

[0152] In Figures 4-14 In a corresponding embodiment, at least f+1 different consensus nodes can respectively initiate consensus proposals as first consensus nodes and broadcast Val messages. In the consensus process of each of the at least f+1 different consensus nodes broadcasting Val messages as first consensus nodes, at least other 2f consensus nodes cooperate to complete this consensus. In this way, the nodes participating in the consensus are 2f+1, reaching the Quorum quantity.

[0153] In this process, when any consensus participating node confirms that there are f+1 consensus proposals made by different consensus nodes being consensused as 1 (i.e. passed by consensus, meaning to be output as consensus result), it can be confirmed that at least one consensus proposal of a loyal node is consensused as 1, so that the earliest timestamp in the f+1 consensus proposals can be taken as the key moment. This is because, according to the Byzantine fault tolerance model, at most f Byzantine nodes (e.g. malicious nodes, unresponsive nodes) can be tolerated in a total of 3f+1 consensus nodes. Then, there are f+1 consensus proposals made by different consensus nodes being consensused as 1, at least one of which is a consensus proposal made by a loyal node, indicating that the consensus proposal of the loyal node has not been completely filtered out. This also indicates that the entire system is available and active (the concept of liveness in distributed systems). Further, the consensus node can no longer process or vote for consensus proposals with timestamps before the key moment.

[0154] A stronger condition for any consensus participating node to confirm that there are f+1 consensus proposals made by different consensus nodes being consensused as 1 can be to confirm that there are f+1 consecutive consensus proposals made by different consensus nodes being consensused as 1. The stronger condition for being consensused as 1 can be to be output as a consensus result.

[0155] In Figures 4-14 In a corresponding another embodiment, at least 2f+1 (Quorum) different consensus nodes can respectively initiate consensus proposals as first consensus nodes and broadcast Val messages. In the consensus process of each of the at least 2f+1 different consensus nodes broadcasting Val messages as first consensus nodes, at least other 2f consensus nodes cooperate to complete this consensus. In this way, the number of consensus participating nodes is 2f+1, which also reaches the Quorum number.

[0156] In this process, when any consensus participating node confirms that there are 2f+1 (here represents the Quorum number, Quorum in other fault-tolerant model consensus algorithm may not be 2f+1) consensus proposals proposed by different consensus nodes are consensused to 1, it can be confirmed that at least f+1 consensus proposals of loyal nodes are consensused to 1, so that the earliest timestamp in the 2f+1 consensus proposals can be taken as the key moment. This is because, according to the Byzantine fault-tolerant model, at most f Byzantine nodes (for example, malicious nodes, unresponsive nodes) can be tolerated in the total number of 3f+1 consensus nodes. Then, there are 2f+1 consensus proposals proposed by different consensus nodes are consensused to 1, at least f+1 of which are consensus proposals proposed by loyal nodes, indicating that the consensus proposals of loyal nodes have not been completely filtered out, and the loyal nodes must be in the ascendant. This also shows that the entire system is available and active. Further, the consensus node can no longer process or vote for the consensus proposals before the key moment.

[0157] The stronger condition can be that any consensus participating node confirms that there are 2f+1 consecutive consensus proposals proposed by different consensus nodes are consensused to 1. The above-mentioned consensused to 1, the stronger condition can be output as a consensus result.

[0158] In an embodiment, the consensus node can switch between the cooperation mode and the competition mode. Specifically, the consensus node can switch between the cooperation mode and the competition mode according to the historical consensus result.

[0159] The consensus node can switch to the competition mode after confirming that there are a first number of consensus proposals from different nodes are consensused to not pass. For example, the first number is f+1, so the consensus node can switch to the competition mode after confirming that there are f+1 consensus proposals from different nodes are consensused to not pass. Confirming that there are f+1 consensus proposals from different nodes are consensused to not pass indicates that at least one consensus proposal proposed by a loyal node is consensused to not pass, indicating that the previous mode is relatively aggressive or there are Byzantine nodes. Therefore, adjusting to the competition mode sets the key moment further away from the current time, thereby allowing more consensus proposals to pass consensus, but the side effect is that it may lead to some consensus results unable to determine the order quickly. The stronger condition can be that there are a first number of consecutive consensus proposals from different nodes are consensused to not pass.

[0160] The consensus node can switch to the cooperation mode after confirming that a second number of consensus proposals from different nodes pass the consensus and output the consensus result. For example, the second number is 2f+1 or Quorum. Thus, the consensus node can switch to the cooperation mode after confirming that 2f+1 or Quorum consensus proposals from different nodes pass the consensus and output the consensus result. The confirmation that 2f+1 consensus proposals from different nodes pass the consensus and output the consensus result indicates that at least f+1 consensus proposals from loyal nodes pass the consensus, which indicates that the previous mode is relatively loose or there is no Byzantine node. Therefore, the adjustment to the cooperation mode sets the critical moment closer to the current time, thereby facilitating the determination of the order of the consensus result more quickly. However, the side effect is that some consensus proposals may be filtered out due to network delay or a large clock bias in a certain case, or it is relatively easy to launch a filtering attack by a malicious node. The stronger condition can be to confirm that a second number of consecutive consensus proposals from different nodes pass the consensus and output the consensus result.

[0161] The application also provides a blockchain system embodiment, comprising:

[0162] The first consensus node broadcasts a first message, and the first message includes a transaction set of a consensus proposal, a timestamp, and a signature of the first consensus node;

[0163] The consensus node receiving the first message broadcasts a second message, and the second message includes a vote on the transaction set and a signature; the vote includes a digest value of the transaction set;

[0164] The consensus node receiving the second message broadcasts a fourth message to other consensus nodes after collecting at least Quorum consistent votes from different consensus nodes; the fourth message includes a critical moment, which is the timestamp in the first message;

[0165] Any consensus node no longer processes or votes against a consensus proposal before the critical moment after collecting at least Quorum fourth messages from different nodes.

[0166] The application also provides a blockchain system embodiment, comprising:

[0167] The first consensus node broadcasts a first message, and the first message includes a transaction set of a consensus proposal, a timestamp, and a signature of the first consensus node;

[0168] The consensus node receiving the first message broadcasts a second message, and the second message includes a vote on the transaction set and a signature; the vote includes a digest value of the transaction set;

[0169] If the consensus node receiving the second message collects at least Quorum consistent votes from different consensus nodes and has not broadcast a different vote for the proposal, the consensus node broadcasts a third message, the third message including the digest value, the collected set of signatures, and a critical time, the critical time being the timestamp in the first message;

[0170] Any consensus node, after collecting at least Quorum third messages from different nodes, no longer processes or votes as not passed for consensus proposals with timestamps before the critical time.

[0171] The application also provides a blockchain system embodiment, comprising:

[0172] The first consensus node broadcasts a first message, the first message including a set of transactions of a consensus proposal, a timestamp, and a signature of the first consensus node;

[0173] The consensus node receiving the first message broadcasts a second message, the second message including a vote for the set of transactions and a signature; the vote including a digest value of the set of transactions;

[0174] If the consensus node receiving the second message collects at least Quorum consistent votes from different consensus nodes and has not broadcast a different vote for the proposal, the consensus node broadcasts a third message, the third message including the digest value and the collected set of signatures;

[0175] If the consensus node receiving the second message collects at least Quorum consistent votes from different consensus nodes and has not broadcast a different vote for the proposal, the consensus node broadcasts a third message, the third message including the digest value and the collected set of signatures;

[0176] After the consensus node collects at least Quorum third messages from different nodes indicating that the vote is passed, the consensus node outputs the set of transactions corresponding to the digest value as a consensus result ordered according to the timestamp;

[0177] In the consensus process performed by at least f+1 different consensus nodes as the first consensus node, any node participating in the consensus confirms that there are f+1 consensus proposals from different nodes passed through consensus / output as consensus results, and the earliest timestamp in the f+1 consensus proposals is taken as a critical time, and other consensus proposals with timestamps before the critical time are no longer processed or voted as not passed for the consensus proposals with timestamps before the critical time; or,

[0178] When at least Quorum different consensus nodes execute the above-mentioned consensus process as the first consensus node respectively, any consensus participating node confirms that Quorum consensus proposals from different nodes pass the consensus / output as the consensus result, and then takes the earliest timestamp in the Quorum consensus proposals as the key moment, and no longer processes or votes for the consensus proposals before the key moment.

[0179] The application also provides a blockchain system embodiment, comprising:

[0180] The first consensus node broadcasts a first message, and the first message includes a transaction set of the consensus proposal, a timestamp, and a signature of the first consensus node;

[0181] The consensus node receiving the first message broadcasts a second message, and the second message includes a vote for the transaction set and a signature; the vote includes an abstract value of the transaction set;

[0182] After the consensus node receiving the second message collects at least Quorum consistent votes from different consensus nodes, if it has not broadcast a different vote for the proposal, it broadcasts a third message, and the third message includes the abstract value and a collected signature set;

[0183] After the consensus node collects at least Quorum third messages from different nodes indicating that the vote passes, the consensus node outputs the transaction set corresponding to the abstract value as the consensus result according to the timestamp;

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

[0185] Cooperation mode: after the consensus node receiving the second message collects at least Quorum consistent votes from different consensus nodes, it broadcasts a fourth message to other consensus nodes; the fourth message includes a key moment, which is the timestamp in the first message; any consensus node no longer processes or votes for the consensus proposals before the key moment after collecting at least Quorum fourth messages from different nodes;

[0186] The competition mode is that: at least f+1 different consensus nodes respectively perform the above consensus process as the first consensus node, and after any participating consensus node confirms that there are f+1 consensus proposals from different nodes passing the consensus / output as the consensus result, the earliest timestamp in the f+1 consensus proposals is taken as the key moment, and other consensus proposals with a timestamp before the key moment are no longer processed or voted as not passing; or, at least Quorum different consensus nodes respectively perform the above consensus process as the first consensus node, and after any participating consensus node confirms that there are Quorum consensus proposals from different nodes passing the consensus / output as the consensus result, the earliest timestamp in the Quorum consensus proposals is taken as the key moment, and other consensus proposals with a timestamp before the key moment are no longer processed or voted as not passing.

[0187] The application also provides a blockchain system embodiment, comprising:

[0188] The first consensus node broadcasts a first message, and the first message includes a transaction set of the consensus proposal, a timestamp, and a signature of the first consensus node;

[0189] The consensus node receiving the first message broadcasts a second message, and the second message includes a vote on the transaction set and a signature; the vote includes a digest value of the transaction set;

[0190] After the consensus node receiving the second message collects at least Quorum consistent votes from different consensus nodes, if it has not broadcast a different vote for the proposal, it broadcasts a third message, and the third message includes the digest value, a collected signature set, and a key moment, and the key moment is the timestamp in the first message;

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

[0192] The cooperation mode is that: after any consensus node collects at least Quorum third messages from different nodes, it no longer processes other consensus proposals with a timestamp before the key moment or votes for the other consensus proposals with a timestamp before the key moment as not passing;

[0193] The competition mode is: at least f+1 different consensus nodes respectively as the first consensus node executes the above consensus process, any node participating in the consensus confirms that there are f+1 consensus proposals from different nodes passing the consensus / output as the consensus result, then the earliest timestamp in the f+1 consensus proposals is taken as the key moment, and other consensus proposals with timestamps before the key moment are no longer processed or voted as not passing; or, at least Quorum different consensus nodes respectively as the first consensus node executes the above consensus process, any node participating in the consensus confirms that there are Quorum consensus proposals from different nodes passing the consensus / output as the consensus result, then the earliest timestamp in the Quorum consensus proposals is taken as the key moment, and other consensus proposals with timestamps before the key moment are no longer processed or voted as not passing.

[0194] In the 1990s, it was quite obvious to distinguish whether an improvement in a technology was in hardware (e.g., improvement in circuit structures of diodes, transistors, switches, etc.) or in software (improvement in method flow). However, as technology has evolved, many improvements in method flow today can be considered as direct improvements in hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structures by programming the improved method flow into hardware circuits. Therefore, it cannot be said that an improvement in a method flow cannot be implemented by hardware entity modules. For example, a programmable logic device (PLD) (e.g., a field programmable gate array (FPGA)) is an integrated circuit whose logic function is determined by user programming of the device. A digital system is "integrated" on a PLD by the designer programming it, rather than by asking a chip manufacturer to design and fabricate a custom integrated circuit chip. Moreover, instead of manually fabricating integrated circuit chips, this programming is now mostly implemented by "logic compiler" software, which is similar to software compilers used in program development, and the original code to be compiled is written in a specific programming language, which is called a hardware description language (HDL), and there are many such languages, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., and the most commonly used are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should be aware that, as long as the method flow is logically programmed in the above-mentioned hardware description languages and programmed into an integrated circuit, a hardware circuit implementing the logical method flow can be easily obtained.

[0195] The controller can be implemented in any suitable way, for example, the controller can take the form of, for example, 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, an application specific integrated circuit (ASIC), a programmable logic controller and an embedded microcontroller, examples of which include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that, in addition to being implemented in pure computer readable program code, the controller can equally well be implemented to perform the same functions using logic gates, switches, application specific integrated circuits, programmable logic controllers and embedded microcontrollers, by logically programming the method steps. The controller can thus be considered a hardware component, and the means included therein for performing various functions can be considered structures within the hardware component. Alternatively, or even additionally, the means for performing various functions can be considered both software modules implementing the method and structures within the hardware component.

[0196] The systems, apparatuses, modules or units illustrated by 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. Of course, the present application does not exclude that with the development of computer technology in the future, computers implementing the functions of the above embodiments can be personal computers, laptop computers, vehicle human-computer interaction devices, cellular phones, camera phones, smart phones, personal digital assistants, media players, navigation devices, email devices, game consoles, tablet computers, wearable devices, or combinations of any of these devices.

[0197] Although the method operations of the embodiments of the present specification are described in sequential order, some of the operations can in practical implementations be performed concurrently, in parallel, or in a different order. The above description of the embodiments of the present specification is provided as an example only and is not intended to be limiting. For example, the steps recited in the examples or flow charts can include more, fewer, or different steps than those described. The order in which the steps are presented is merely one example and is not intended to be limiting. The steps can be performed in an order different than presented, or performed in parallel, or in a different order, for example in a parallel processor or multi-threaded processing environment, or even in a distributed data processing environment. The terms "comprise", "comprising", or any other variation thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can also include other elements not expressly listed or inherent to such process, method, article, or apparatus. Exclusion of such elements is only present if it is expressly stated that these elements are excluded. For example, use of the terms "first", "second", or the like does not denote any order or importance, but rather the terms are used to distinguish one element from another.

[0198] For ease of description, the above apparatuses are described in various modules with different functions. Of course, when implementing one or more of the present specification, the functions of the modules can be implemented in one or more software and / or hardware, or the modules implementing the same function can be implemented by a combination of sub-modules or sub-units. The above-described apparatus embodiments are only illustrative, for example, the division of the units is only a logical function division, and in actual implementation, another division mode can be used, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the displayed or discussed each other can be indirect coupling or communication connection through some interface, device or unit, and can be electrical, mechanical or other forms.

[0199] The present application is described with reference to flowcharts and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, as well as combinations of flows and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing apparatus to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing apparatus produce a means for implementing the functions specified in the flowcharts and / or block diagrams. Figure 1 The functions of a flow or multiple flows and / or blocks Figure 1 The functions of a flow or multiple flows and / or blocks

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

[0201] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the Figure 1 function specified in the flow or flows and / or blocks Figure 1 Figure 1 of the block or blocks.

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

[0203] The memory can include non-persistent memory and / or volatile memory, such as random access memory (RAM) and / or cache memory, non-volatile memory, such as read-only memory (ROM), EPROM, and / or flash memory. The memory is an example of computer-readable media.

[0204] Computer-readable media includes permanent and non-permanent, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD), or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage, graphene storage, or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to computing devices. According to the definition herein, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

[0205] Those skilled in the art will appreciate that the one or more embodiments described herein can be provided as a method, a system or a computer program product. Accordingly, the one or more embodiments described herein can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the one or more embodiments described herein can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage devices, etc.) embodying computer readable code.

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

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

[0208] The above description is only some embodiments of the one or more embodiments described in this specification and is not intended to limit the one or more embodiments described in this specification. The one or more embodiments described in this specification can have various modifications and changes for those skilled in the art. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the specification shall be included in the scope of claims.

Claims

1. A consensus method in a blockchain system, comprising: broadcasting, by a first consensus node, a first message including a set of transactions of a consensus proposal, a timestamp, and a signature of the first consensus node; broadcasting, by a consensus node receiving the first message, a second message including a vote on the set of transactions and a signature; the vote including a digest value of the set of transactions; broadcasting, by a consensus node receiving the second message, a fourth message to other consensus nodes after collecting at least Quorum consistent votes from different consensus nodes; the fourth message including a critical time point, which is the timestamp in the first message; any consensus node, after collecting at least Quorum fourth messages from different nodes, no longer processing consensus proposals with a timestamp before the critical time point, or voting for the consensus proposals with a timestamp before the critical time point as not passed. 2.The method of claim 1, further comprising: broadcasting, by a consensus node receiving the second message, a third message including the digest value and a set of collected signatures after collecting at least Quorum consistent votes from different consensus nodes, if the consensus node has not broadcasted a different vote for the proposal; outputting, by a consensus node, the set of transactions corresponding to the digest value as a consensus result ordered by the timestamp after collecting at least Quorum third messages from different nodes indicating a vote pass. 3.The method of claim 2, wherein the set of transactions corresponding to the digest value is outputted as a consensus result ordered by the timestamp after the consensus of a consensus proposal with an earlier timestamp is completed if there is a consensus proposal with an earlier timestamp whose vote is completed. 4.The method of claim 1, wherein the timestamp is determined based on a physical time at or before the first consensus node broadcasts the first message and a network transmission delay. 5.The method of claim 4, wherein the network transmission delay includes an average or a maximum of network transmission delays between the first consensus node and other consensus nodes. 6.The method of claim 1 or 2, wherein at least Quorum consensus nodes in the blockchain system participate in a consensus in a same consensus process, and wherein at least one consensus node acts as the first consensus node to perform the method of claim 1. 7.The method of claim 1 or 2, wherein at least two consensus results generated by at least one consensus node acting as the first consensus node to perform the method of claim 1 are used to generate blocks in order of the timestamp. 8.The method of claim 1 or 2, wherein at least two consensus results generated by at least two consensus nodes acting as the first consensus node to perform the method of claim 1 are used to generate blocks in order of the timestamp. 9.The method of claim 1 or 2, wherein Quorum is 2f+1 when a total number of nodes in the blockchain system is 3f+1. 10.A consensus method in a blockchain system, comprising: The first consensus node broadcasts a first message, the first message including a transaction set of a consensus proposal, a timestamp, and a signature of the first consensus node; A consensus node receiving the first message broadcasts a second message, the second message including a vote on the transaction set and a signature; the vote including a digest value of the transaction set; Upon receiving the second message, a consensus node collects at least Quorum consistent votes from different consensus nodes, and if it has not broadcast a different vote for the proposal, broadcasts a third message including the digest value, a set of collected signatures, and a critical time, the critical time being the timestamp in the first message; Any consensus node upon collecting at least Quorum third messages from different nodes, stops processing consensus proposals or voting on consensus proposals with a timestamp before the critical time.

11. The method of claim 10, further comprising: Upon collecting at least Quorum third messages from different nodes indicating a vote pass, a consensus node outputs the transaction set corresponding to the digest value as a consensus result ordered by the timestamp.

12. The method of claim 11, wherein the transaction set corresponding to the digest value is output as a consensus result ordered by the timestamp after a consensus of a consensus proposal with an earlier timestamp is completed.

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

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

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

16. The method of claim 10 or 11, wherein at least two consensus results generated by at least one consensus node acting as the consensus node broadcasting the consensus proposal are used to generate blocks in an order of the timestamp.

17. The method of claim 10 or 11, wherein at least two consensus results generated by at least two consensus nodes acting as the consensus node broadcasting the consensus proposal are used to generate blocks in an order of the timestamp.

18. The method of claim 10 or 11, wherein Quorum is 2f+1 when a total number of nodes in the blockchain system is 3f+1.

19. A consensus method in a blockchain system, comprising: A first consensus node broadcasts a first message, the first message including a transaction set of a consensus proposal, a timestamp, and a signature of the first consensus node; The consensus node receiving the first message broadcasts a second message, and the second message includes a vote on the transaction set and a signature; the vote includes a digest value of the transaction set; After the consensus node receiving the second message collects at least Quorum consistent votes from different consensus nodes, if no different vote is broadcast by the consensus node itself for the proposal, a third message is broadcast, and the third message includes the digest value and a collected signature set; wherein, when the total number of nodes in the blockchain system is 3f+1, Quorum is 2f+1; 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 is output as a consensus result sorted according to the timestamp; In the consensus process performed by at least f+1 different consensus nodes as the first consensus node, any consensus participating node confirms that f+1 consensus proposals from different nodes are passed and output as consensus results, and then takes the earliest timestamp in the f+1 consensus proposals as a key moment, and no longer processes or votes for not passing the consensus proposals before the key moment; or, In the consensus process performed by at least Quorum different consensus nodes as the first consensus node, any consensus participating node confirms that Quorum consensus proposals from different nodes are passed and output as consensus results, and then takes the earliest timestamp in the Quorum consensus proposals as a key moment, and no longer processes or votes for not passing the consensus proposals before the key moment.

20. The method of claim 19, wherein, The any consensus participating node confirming that f+1 consensus proposals from different consensus nodes are passed and output as consensus results includes: The any consensus participating node confirming that f+1 consensus proposals from different consensus nodes are passed and output as consensus results includes:

21. The method of claim 19, wherein, The any consensus participating node confirming that Quorum consensus proposals from different consensus nodes are passed and output as consensus results includes: The any consensus participating node confirming that Quorum consensus proposals from different consensus nodes are passed and output as consensus results includes:

22. A consensus method in a blockchain system, comprising: A first consensus node broadcasts a first message, and the first message includes a transaction set of a consensus proposal, a timestamp, and a signature of the first consensus node; The consensus node receiving the first message broadcasts a second message, and the second message includes a vote on the transaction set and a signature; the vote includes a digest value of the transaction set; If the consensus node receiving the second message collects at least Quorum consistent votes from different consensus nodes, and the consensus node has not broadcast a different vote for the proposal, the consensus node broadcasts a third message, the third message including the digest value and the collected set of signatures; wherein, in the case that the total number of nodes in the blockchain system is 3f+1, Quorum is 2f+1; After the consensus node collects at least Quorum third messages from different nodes indicating that the vote is passed, the consensus node outputs the transaction set corresponding to the digest value as a consensus result sorted according to the timestamp; The consensus node can switch between a cooperation mode and a competition mode, wherein: Cooperation mode: after the consensus node receiving the second message collects at least Quorum consistent votes from different consensus nodes, the consensus node broadcasts a fourth message to other consensus nodes; the fourth message includes a critical time, which is the timestamp in the first message; any consensus node, after collecting at least Quorum fourth messages from different nodes, no longer processes or votes as not passed for consensus proposals with a timestamp before the critical time; Competition mode: in the case that at least f+1 different consensus nodes respectively execute the above consensus process as a first consensus node, any consensus node confirms that there are f+1 consensus proposals from different nodes that have passed consensus / output as a consensus result, and the consensus node takes the earliest timestamp of the f+1 consensus proposals as the critical time, and no longer processes or votes as not passed for consensus proposals with a timestamp before the critical time; or, in the case that at least Quorum different consensus nodes respectively execute the above consensus process as a first consensus node, any consensus node confirms that there are Quorum consensus proposals from different nodes that have passed consensus / output as a consensus result, and the consensus node takes the earliest timestamp of the Quorum consensus proposals as the critical time, and no longer processes or votes as not passed for consensus proposals with a timestamp before the critical time.

23. The method of claim 22, wherein, The any consensus node confirming that there are f+1 consensus proposals from different consensus nodes that have passed consensus / output as a consensus result includes: The any consensus node confirming that there are f+1 consensus proposals from different consensus nodes that have passed consensus / output as a consensus result includes:

24. The method of claim 22, wherein, The any consensus node confirming that there are Quorum consensus proposals from different consensus nodes that have passed consensus / output as a consensus result includes: The any consensus node confirming that there are Quorum consensus proposals from different consensus nodes that have passed consensus / output as a consensus result includes:

25. A consensus method in a blockchain system, comprising: A first consensus node broadcasts a first message, the first message including a transaction set of a consensus proposal, a timestamp, and a signature of the first consensus node; The consensus node receiving the first message broadcasts a second message, the second message including a vote on the set of transactions and a signature; the vote including a digest value of the set of transactions; The consensus node receiving the second message broadcasts a third message if it has not broadcast a different vote on the proposal, the third message including the digest value, a set of collected signatures, and a critical time, the critical time being the timestamp in the first message, after collecting at least Quorum consistent votes from different consensus nodes; The consensus node is capable of switching between a cooperative mode and a competitive mode, wherein: Cooperative mode: any consensus node, after collecting at least Quorum number of third messages from different nodes, no longer processes or votes as not passed for consensus proposals with a timestamp before the critical time; Competitive mode: any participating node confirms that there are f+1 number of consensus proposals from different nodes passed consensus / output as consensus results, and takes the earliest timestamp of the f+1 consensus proposals as the critical time, and no longer processes or votes as not passed for consensus proposals with a timestamp before the critical time, in the case that at least f+1 different consensus nodes execute the above consensus process as the first consensus node; or, any participating node confirms that there are Quorum number of consensus proposals from different nodes passed consensus / output as consensus results, and takes the earliest timestamp of the Quorum consensus proposals as the critical time, and no longer processes or votes as not passed for consensus proposals with a timestamp before the critical time, in the case that at least Quorum different consensus nodes execute the above consensus process as the first consensus node.

26. The method of claim 25, wherein, The any participating node confirming that there are f+1 consensus proposals from different consensus nodes passed consensus / output as consensus results includes: The any participating node confirming that there are f+1 consensus proposals from different consensus nodes passed consensus / output as consensus results includes:

27. The method of claim 25, wherein, The any participating node confirming that there are Quorum consensus proposals from different consensus nodes passed consensus / output as consensus results includes: The any participating node confirming that there are Quorum consensus proposals from different consensus nodes passed consensus / output as consensus results includes:

28. The method of any one of claims 25-27, the consensus node being capable of switching between a cooperative mode and a competitive mode, comprising: The consensus node is capable of switching between the cooperative mode and the competitive mode according to historical consensus result conditions.

29. The method of claim 28, the consensus node being capable of switching between the cooperative mode and the competitive mode according to historical consensus result conditions, comprising: The consensus node switches to the competitive mode after confirming that there are a first number of consensus proposals from different nodes passed consensus as not passed. 30.The method of claim 29, wherein the consensus node switches to the cooperative mode upon confirming that a first number of consensus proposals from different nodes are agreed to be rejected. 31.The method of claim 29 or 30, wherein the first number is f+1. 32.The method of claim 28, wherein the consensus node is capable of switching between the cooperative mode and the competitive mode according to historical consensus results, comprising: the consensus node switches to the cooperative mode upon confirming that a second number of consensus proposals from different nodes are agreed to be included in the consensus results. 33.The method of claim 32, wherein the consensus node switches to the cooperative mode upon confirming that a second number of consensus proposals from different nodes are agreed to be included in the consensus results, comprising: the consensus node switches to the cooperative mode upon confirming that a second number of consecutive consensus proposals from different nodes are agreed to be included in the consensus results. 34.The method of claim 33, wherein the second number is Quorum. 35.The method of claim 25, wherein Quorum is 2f+1 when the total number of nodes in the blockchain system is 3f+1. 36.A blockchain system, comprising: a first consensus node broadcasts a first message, the first message including a set of transactions of a consensus proposal, a timestamp, and a signature of the first consensus node; a consensus node receiving the first message broadcasts a second message, the second message including a vote on the set of transactions and a signature; the vote including a digest value of the set of transactions; a consensus node receiving the second message broadcasts a fourth message to other consensus nodes upon collecting at least Quorum number of consistent votes from different consensus nodes; the fourth message including a critical time, which is the timestamp in the first message; any consensus node stops processing consensus proposals or voting on consensus proposals before the critical time upon collecting at least Quorum number of fourth messages from different nodes. 37.The system of claim 36, further comprising: a consensus node receiving the second message broadcasts a third message including the digest value and a set of collected signatures upon collecting at least Quorum number of consistent votes from different consensus nodes if it has not broadcast a different vote on the proposal; a consensus node outputs the set of transactions corresponding to the digest value as consensus results ordered according to the timestamp upon collecting at least Quorum number of third messages from different nodes indicating a vote to be included. 38.The system of claim 36, wherein Quorum is 2f+1 when the total number of nodes in the blockchain system is 3f+1. 39.A blockchain system, comprising: a first consensus node broadcasts a first message, the first message including a set of transactions of a consensus proposal, a timestamp, and a signature of the first consensus node; ​ The consensus node receiving the first message broadcasts a second message, the second message including a vote on the transaction set and a signature; the vote including a digest value of the transaction set; The consensus node receiving the second message collects at least Quorum consistent votes from different consensus nodes, and if it has not broadcast a different vote for the proposal, broadcasts a third message including the digest value, the collected set of signatures, and a critical time, the critical time being the timestamp in the first message; Any consensus node, after collecting at least Quorum third messages from different nodes, no longer processes or votes against consensus proposals with a timestamp before the critical time.

40. A blockchain system comprising: A first consensus node broadcasts a first message, the first message including a transaction set of a consensus proposal, a timestamp, and a signature of the first consensus node; The consensus node receiving the first message broadcasts a second message, the second message including a vote on the transaction set and a signature; the vote including a digest value of the transaction set; The consensus node receiving the second message collects at least Quorum consistent votes from different consensus nodes, and if it has not broadcast a different vote for the proposal, broadcasts a third message including the digest value, the collected set of signatures; wherein Quorum is 2f+1 when the total number of nodes in the blockchain system is 3f+1; The consensus node, after collecting at least Quorum third messages from different nodes indicating a passed vote, outputs the transaction set corresponding to the digest value as a consensus result ordered by the timestamp; At least f+1 different consensus nodes each acting as the first consensus node in the consensus process described above, any participating consensus node, after confirming that there are f+1 consensus proposals from different nodes that have passed consensus / output as consensus results, takes the earliest timestamp among the f+1 consensus proposals as the critical time, and no longer processes or votes against consensus proposals with a timestamp before the critical time; or, At least Quorum different consensus nodes each acting as the first consensus node in the consensus process described above, any participating consensus node, after confirming that there are Quorum consensus proposals from different nodes that have passed consensus / output as consensus results, takes the earliest timestamp among the Quorum consensus proposals as the critical time, and no longer processes or votes against consensus proposals with a timestamp before the critical time.

41. A blockchain system comprising: A first consensus node broadcasts a first message, the first message including a transaction set of a consensus proposal, a timestamp, and a signature of the first consensus node; The consensus node receiving the first message broadcasts a second message, the second message including a vote on the transaction set and a signature; the vote including a digest value of the transaction set; The consensus node receiving the second message collects at least Quorum consistent votes from different consensus nodes, and if it has not broadcast a different vote for the proposal, broadcasts a third message including the digest value, the collected set of signatures, and a critical time, the critical time being the timestamp in the first message; After receiving the second message, if the consensus node has not broadcasted a different vote for the proposal, the consensus node broadcasts a third message including the digest value and the collected set of signatures after collecting at least Quorum consistent votes from different consensus nodes; wherein Quorum is 2f+1 when the total number of nodes in the blockchain system is 3f+1; After receiving the third message, the consensus node outputs the set of transactions corresponding to the digest value as a consensus result ordered according to the timestamp; The consensus node switches between the cooperation mode and the competition mode according to historical consensus results, wherein: Cooperation mode: After receiving the second message, the consensus node broadcasts a fourth message to other consensus nodes after collecting at least Quorum consistent votes from different consensus nodes; the fourth message includes a critical time, which is the timestamp in the first message; any consensus node stops processing or voting as not passed for consensus proposals before the critical time after collecting at least Quorum fourth messages from different nodes; Competition mode: After at least f+1 different consensus nodes execute the above consensus process as the first consensus node, any participating consensus node confirms that there are f+1 consensus proposals from different nodes passed consensus / output as consensus results, and the earliest timestamp of the f+1 consensus proposals is taken as the critical time, and other consensus proposals with a timestamp before the critical time are no longer processed or voted as not passed for the consensus proposals before the critical time; or, after at least Quorum different consensus nodes execute the above consensus process as the first consensus node, any participating consensus node confirms that there are Quorum consensus proposals from different nodes passed consensus / output as consensus results, and the earliest timestamp of the Quorum consensus proposals is taken as the critical time, and other consensus proposals with a timestamp before the critical time are no longer processed or voted as not passed for the consensus proposals before the critical time.

42. A blockchain system, comprising: A first consensus node broadcasts a first message including a set of transactions of a consensus proposal, a timestamp, and a signature of the first consensus node in the first message; After receiving the first message, a consensus node broadcasts a second message including a vote for the set of transactions and a signature in the second message; the vote includes a digest value of the set of transactions; After receiving the second message, if the consensus node has not broadcasted a different vote for the proposal, the consensus node broadcasts a third message including the digest value, the collected set of signatures, and a critical time, which is the timestamp in the first message, after collecting at least Quorum consistent votes from different consensus nodes; The consensus node switches between the cooperation mode and the competition mode according to historical consensus results, wherein: Cooperation mode: any consensus node, after collecting at least Quorum number of third messages from different nodes, no longer processes or votes as not passed for consensus proposals with timestamps before the key moment; Competition mode: in the above consensus process, any participating consensus node confirms that there are f+1 consensus proposals from different nodes passed consensus / output as consensus results, and the earliest timestamp of the f+1 consensus proposals is taken as the key moment, and other consensus proposals with timestamps before the key moment are no longer processed or voted as not passed; or, in the above consensus process, any participating consensus node confirms that there are Quorum consensus proposals from different nodes passed consensus / output as consensus results, and the earliest timestamp of the Quorum consensus proposals is taken as the key moment, and other consensus proposals with timestamps before the key moment are no longer processed or voted as not passed.

Images