WO2023056964A1

WO2023056964A1 - Consensus method, blockchain system, and consensus node

Info

Publication number: WO2023056964A1
Application number: PCT/CN2022/124047
Authority: WO
Inventors: 刘盛云; 邓福喜; 闫莺; 徐文博
Original assignee: 支付宝(杭州)信息技术有限公司
Priority date: 2021-10-09
Filing date: 2022-10-09
Publication date: 2023-04-13
Also published as: CN113630258A; CN113630258B

Abstract

A consensus method, a blockchain system, and a consensus node. The consensus method comprises: a first consensus node generates, by using an erasure code, multiple data blocks from a transaction set proposed by a consensus; the first consensus node sends a first message to other consensus nodes; a consensus node receiving the first message broadcasts a second message, the second message comprising a received data block and a vote and a signature for the transaction set, and the vote comprising an abstract value of the transaction set; a consensus node receiving the second message broadcasts a third message after acquiring Quorum consistent votes from different consensus nodes, the third message comprising the abstract value and the acquired signature set; and the consensus node recovers the transaction set by using the erasure code at the end of a second round or a third round on the basis of the received data block, and after at least Quorum third messages from different nodes are acquired, uses the transaction set corresponding to the abstract value as at least part of a consensus result for output.

Description

Consensus methods, blockchain systems and consensus nodes

technical field

The embodiments of this specification belong to the field of blockchain technology, and in particular relate to a consensus method, a blockchain system, and consensus nodes.

Background technique

Blockchain is a new application model of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm. In the blockchain system, the data blocks are combined into a chained data structure in a sequentially connected manner in chronological order, and a non-tamperable and unforgeable distributed ledger is cryptographically guaranteed. Due to the characteristics of decentralization, non-tamperable information, and autonomy, the blockchain has also received more and more attention and application.

Contents of the invention

The purpose of the present invention is to provide a consensus method, blockchain system and consensus nodes, including: a consensus method in the blockchain system, including: the first round: the first consensus node uses the transaction set proposed by the consensus to correct Code deletion generates multiple data blocks; the first consensus node retains a copy of the data block, and sends the first message to other consensus nodes, and the first message sent to different consensus nodes includes different data blocks and the first consensus node The second round: the consensus node that received the first message broadcasts the second message, the second message includes the vote and signature on the transaction set; the vote includes the summary value of the transaction set; the second Three rounds: After the consensus node receiving the second message collects at least Quorum unanimous votes from different consensus nodes, it broadcasts the third message, which includes the data block, the digest value and the collected signature set; The data blocks broadcast by the first consensus node include the reserved data blocks, and the remaining consensus nodes broadcast the data blocks received in the first round; The erasure code restores the transaction set, and after collecting at least Quorum third messages from different nodes, outputs the transaction set corresponding to the digest value as at least a part of the consensus result.

A blockchain system, including consensus nodes, wherein: the first consensus node uses erasure codes to generate multiple data blocks from the transaction set proposed by the consensus; the first consensus node retains a copy of the data block, and sends the first message to other Consensus nodes, the first message sent to different consensus nodes includes different data blocks and the signature of the first consensus node; the consensus node that receives the first message broadcasts a second message, and the second message includes the signature for all The voting and signature of the transaction set; the vote includes the summary value of the transaction set; after the consensus node receiving the second message collects at least Quorum unanimous votes from different consensus nodes, it broadcasts the third message, and the second The third message includes the data block, the digest value and the collected signature set; wherein the data block broadcast by the first consensus node includes the reserved data block, and the remaining consensus nodes broadcast the data block received in the first round; the At the end of the third round, the consensus node uses the erasure code to restore the transaction set based on the received data block, and after collecting at least Quorum third messages from different nodes, the summary value corresponds to The set of transactions is output as at least part of the consensus result.

A consensus node in a blockchain system, comprising: a data block generation unit, used to generate multiple data blocks using erasure codes for a transaction set proposed by the consensus, and retain a copy of the data blocks; a first message broadcast unit, using When broadcasting the first message to other consensus nodes, the first messages sent to different consensus nodes include different data blocks and the signature of the first consensus node; the second message receiving unit is used to receive the second message, and the second The message includes a vote and a signature on the transaction set; the vote includes a summary value of the transaction set; the third message broadcast unit, when the second message receiving unit collects at least Quorum consistent Broadcast a third message after voting, the third message includes the reserved data block, the digest value and the collected signature set; the third message collection unit is used to collect the third message from different consensus nodes; the output unit After the third message collection unit collects at least Quorum third messages from different nodes, output the transaction set corresponding to the summary value as at least a part of the consensus result.

A consensus node in a blockchain system, comprising: a first message receiving unit, configured to receive a first message broadcast by the first consensus node, the first message including a data block of a proposed transaction set and the first consensus node signature; the second message broadcasting unit is configured to broadcast a second message after the first message receiving unit receives the first message, and the second message includes a vote and a signature on the transaction set; the vote includes all The summary value of the transaction set; the second message receiving unit is used to receive the second message, and the second message includes the vote and signature on the transaction set; the vote includes the summary value of the transaction set; the third message The broadcasting unit, when the second message receiving unit collects at least Quorum unanimous votes from different consensus nodes, broadcasts the third message, the third message includes the digest value and the collected signature set; the third message collecting unit , to collect third messages from different consensus nodes; the recovery unit, based on the data block received by the third message collection unit, restores the transaction set using the erasure code; the output unit, when the third message collection unit collects After at least Quorum third messages from different nodes, the transaction set corresponding to the summary value is output as at least a part of the consensus result.

In the above-mentioned embodiment, on the basis of shortening to 3 rounds to complete a consensus under a certain premise, the erasure code is used to generate several data blocks for the transaction proposed by the consensus, and the proposed consensus node does not need to transmit larger data packets to other Instead, different data blocks of the data packet are transmitted to different consensus nodes, which can reduce the amount of data transmitted by the network. Forwarding the data blocks sent by the proposed consensus nodes in the second round can make full use of the bandwidth resources between nodes in the network, thereby improving the performance of the consensus protocol as a whole.

Description of drawings

In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following will briefly introduce the drawings that need to be used in the description of the embodiments. Obviously, the drawings in the following description are only some embodiments recorded in this specification. , for those skilled in the art, other drawings can also be obtained according to these drawings without paying creative labor.

Fig. 1 is a schematic diagram of a conventional stage of a practical Byzantine fault-tolerant algorithm in an embodiment;

Fig. 2 is a schematic diagram of the view switching stage of the practical Byzantine fault-tolerant algorithm in an embodiment;

Fig. 3 is a schematic diagram of the honey badger Byzantine fault-tolerant algorithm in an embodiment;

Fig. 4 is a flowchart of the consensus algorithm in an embodiment of this specification;

Fig. 5 is a schematic diagram of a consensus algorithm in an embodiment of this specification;

Fig. 6 is a schematic diagram of a consensus algorithm in an embodiment of this specification;

Fig. 7 is a schematic diagram of a consensus algorithm in an embodiment of this specification;

Fig. 8 is a schematic diagram of a consensus algorithm in an embodiment of this specification;

Fig. 9 is a schematic diagram of a consensus algorithm in an embodiment of this specification;

FIG. 10 is an architecture diagram of a consensus node in an embodiment of this specification;

Fig. 11 is an architecture diagram of a consensus node in an embodiment of this specification;

Fig. 12 is a schematic diagram of an erasure code in an embodiment of this specification;

Fig. 13 is a schematic diagram of Merkle Tree in an embodiment of this specification;

Fig. 14 is a schematic diagram of Merkle Tree in an embodiment of this specification.

Detailed ways

In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described The embodiments are only some of the embodiments in this specification, not all of them. Based on the embodiments in this specification, all other embodiments obtained by persons of ordinary skill in the art without creative efforts shall fall within the protection scope of this specification.

In the blockchain system, different participants can establish a distributed blockchain network through the deployed nodes (Nodes). A decentralized (or multi-centered) distributed ledger constructed using a chained block structure is stored on each node (or most nodes, such as consensus nodes) in the distributed blockchain network. Such a blockchain system needs to solve the problem of the consistency and correctness of the respective ledger data on multiple decentralized (or multi-centered) nodes. Each node runs a blockchain program. Under the design of certain fault-tolerant requirements, the consensus mechanism is used to ensure that all loyal nodes have the same transaction, so as to ensure that all loyal nodes have the same execution results for the same transaction, and will Transactions and execution results are packaged to generate blocks. The current mainstream consensus mechanisms include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT) algorithm , Honey Badger Byzantine Fault Tolerance (HoneyBadgerBFT) algorithm, etc.

Taking PBFT as an example, this algorithm was proposed by Miguel Castro (Castro) and Barbara Liskov (Liskov) in 1999. It solved the problem of low efficiency of the original Byzantine fault-tolerant algorithm, and the complexity of the algorithm was changed from exponential to The level is reduced to the polynomial level, making the Byzantine fault-tolerant algorithm feasible in practical system applications. The paper was presented at the International Conference on Operating System Design and Implementation (OSDI99) in 1999. In the PBFT algorithm, all replicas run in a rotation process (succession of configuration) called View. In a certain view, one copy acts as the primary node (primary), and the other copies act as backup nodes (backups). Views are consecutively numbered integers. The primary node 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 replica sets. The algorithm assumes that when at most f replicas (ie, nodes) fail, if there are at least 3f+1 replicas in total, security and liveness can be guaranteed to be provided in an asynchronous system. A set of a certain number of copies required to ensure the data consistency and fault tolerance requirements of all copies is generally a collection of most nodes in a distributed system, forming a majority (Quorum). For example, when the total number of nodes n is 3f+1 (the case of n=3f+2 or n=3f generally does not improve the 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.

PBFT includes two processes, Normal Case Phase and View Change Phase. Figure 1 is a flow chart of the Normal Case Phase (normal phase) process. The Normal Case Phase mainly includes three phases: PRE-PREPARE (pre-preparation), PREPARE (preparation) and COMMIT (commitment). Among them, node 3 can represent a downtime node (indicated by × in Figure 1), for example. When the primary node fails (indicated by × in Figure 2, if the primary node Primary, that is, Replica 0 (copy 0) fails before changing the view), it is necessary to start the view change process, so as to adjust the state when the system is faulty , replace the new primary node (for example, Replica 1 is the primary node Primary after changing the view). Figure 2 is a schematic diagram of View Change Phase (view switching). If the master node goes offline or does evil and does not broadcast the client's request, etc., the client can set a timeout mechanism. If it times out, the client can broadcast the request message to all replica nodes. After the replica node detects that the master node is malicious or goes offline, it can also initiate the View Change protocol phase to replace the master node (often referred to as "master change"). In addition, the three-stage consensus process of PRE-PREPARE, PREPARE and COMMIT may fail due to the wrong proposal initiated by the master node, or the PREPARE and COMMIT stages may not reach the number of Quorum (such as 2f+1 of 3f+1 nodes, Also known as the quorum), the consensus cannot be completed. In these cases it is also possible to initiate the View Change protocol phase to replace the master node.

The PBFT protocol is a partial synchronous protocol, which is characterized by assuming that the network is asynchronous at the beginning, but it can be synchronized from a certain moment. To allow different nodes to reach a consensus on the same proposal in the network, the easiest way is to set up a master node, and the master node will unify the opinions of each node. By setting the timer, you can prevent the master node from making mistakes. In PBFT, if the Normal Case Phase is not completed within a limited time, Backups will be triggered to initiate the View Change Phase to replace the primary node. PBFT fixes the master node in one position, and all requests can be sent to the master node first, and then broadcast to other consensus nodes by the master node. In addition to introducing additional latency in sending requests to the master node, the ingress and egress bandwidth of the master node can also become a performance bottleneck. In contrast, the HoneyBadgerBFT (also often abbreviated as HBBFT) algorithm belongs to an asynchronous (asynchronous) protocol. Asynchronous protocols are suitable for asynchronous networks, that is, messages between nodes in this network can be delayed arbitrarily, but will eventually arrive. The timer is removed from HoneyBadgerBFT, and the execution of the protocol is driven by messages. At the same time, all nodes in the HoneyBadgerBFT algorithm are equal, there is no distinction between master nodes and backup nodes, and there is no process of changing masters. Asynchronous network consensus protocols such as HBBFT have no concept of master nodes. Each node can propose a request and try to construct a block. Therefore, asynchronous network protocols alleviate the problems of fairness and single-node bottlenecks to a certain extent.

Figure 3 is a flow chart of the single node angle of the HoneyBadgerBFT algorithm. In fact, as mentioned earlier, all nodes in the HoneyBadgerBFT algorithm are peers, that is, all nodes can execute the process shown in Figure 3. As shown in Figure 3, from the perspective of a single node, HoneyBadgerBFT mainly includes two stages, namely Reliable Broadcast (RBC) and Asynchronous Binary Agreement (ABA, asynchronous binary agreement, also known as "01 Asynchronous consensus"). The RBC phase includes at least three rounds of message interaction of Rval, Echo, and Ready, and the ABA phase includes at least three rounds of message interaction of Bval, Aux, and Coin. RBC uses three rounds of message exchanges to ensure reliable proposal broadcasting. ABA first conducts two rounds of voting (Bval and AUX messages), and then uses Coin toss (Coin) to unify the proposals of each node, thereby bypassing the network synchronization requirements of the semi-synchronous protocol. A HoneyBadgerBFT consensus must go through the RBC phase and at least one ABA phase. In the best case, there is a probability of 1/2 that the HoneyBadgerBFT consensus process can be ended. In this way, it takes 6 rounds to complete a consensus. In addition, there is a 1/4 probability that it will enter the ABA process again, as shown in Figure 3 for the second ABA process (the ABA process represented by

rounds

7, 8, and 9), and there is a 1/4 probability that it will end in the second round. And there is a probability of at least 1/4 that the HoneyBadgerBFT consensus process can be ended. In this way, it takes 9 rounds to complete a consensus. After the second ABA process, there is a 1/8 probability that the overall will enter the ABA process again...and so on.

To sum up, HoneyBadgerBFT includes at least one RBC (three rounds) and one ABA (three rounds). If the ABA voting result is inconsistent with the coin toss result, the protocol enters a new round of ABA (at least three additional rounds). Tossing coins brings uncertainty to the rounds of consensus and may increase delays.

This application provides an embodiment of a consensus algorithm, as shown in Figure 4, which specifically includes: S41: [First round] The first consensus node uses erasure codes to generate multiple data blocks from the transaction set proposed by the consensus; the first consensus node A copy of the data block is reserved, and a first message is sent to other consensus nodes. The first messages sent to different consensus nodes include different data blocks and signatures of the first consensus node.

In an embodiment of a consensus algorithm in this application, it may include 3 rounds of interaction. Similar to HBBFT, the consensus algorithm of the embodiment shown in Figure 5 is also an asynchronous protocol, that is, it is assumed that messages between nodes in the network can be delayed arbitrarily, but will eventually arrive. Similarly, the timer is also removed in the embodiment in Figure 5, and the execution of the protocol is driven by messages; at the same time, all nodes can be peer-to-peer, there is no distinction between the master node and the backup node, and any consensus node can initiate consensus Proposals, each consensus node can also participate in the consensus process where other nodes propose consensus proposals. The result of a consensus can include the sum of the transaction sets in the consensus proposal proposed by all nodes in this consensus and obtained at least the same number of Quorum votes.

From the perspective of a node, for example, from the perspective of Node ₀ initiating a consensus proposal, the interaction process is shown in Figure 5. In a consensus, Node ₀ can initiate a consensus proposal, which can include a packaged transaction set, for example, marked as m ₀ , m ₀ can include a series of transaction sets {tx ₀₁ , tx ₀₂ , .. .,tx _0n }. Furthermore, Node ₀ can generate multiple data blocks by adopting erasure coding (Erasure Coding) for the transaction set m ₀ proposed by the consensus. Generally, the number n of data blocks generated using erasure codes can be equal to the total number of consensus nodes. For example, in a blockchain system including 4 consensus nodes, Node ₀ uses erasure codes on m ₀ to generate 4 data blocks (data blocks), namely m ₀₀ , m ₀₁ , m ₀₂ , and m ₀₃ . For these four generated data blocks, they can have corresponding hash values respectively, for example, the hash value corresponding to m ₀₀ is hash ₀₀₀ , the corresponding hash value of m ₀₁ is hash ₀₀₁ , and the corresponding hash value of m ₀₂ is hash ₀₀₂ , m ₀₃ The corresponding hash value is hash ₀₀₃ , as shown in Figure 12. Erasure code is a coding error-tolerant technology, which was first used for data recovery in data transmission in the communication industry. By adding verification data to the original data, each split data is associated. In the case of a certain range of data errors, it can be recovered through erasure code technology. Data m can be generated into N data blocks through EC. In a commonly used design, the N data blocks generally include p data blocks after data m is split, and q data blocks for storing erasure codes are also added. In this way, the original data m can be restored through any p pieces of data in the p+q pieces.

Node ₀ can also build a Merkle Tree (Merkle tree, usually also called a Hash Tree) for the generated data block. As mentioned above, the hash values of the four data blocks m ₀₀ , m ₀₁ , m ₀₂ , and m ₀₃ are respectively hash ₀₀₀ , hash ₀₀₁ , hash ₀₀₂ , and hash ₀₀₃ . To construct the hash values in pairs, hash 00 , hash ₀₁ can be obtained _. . Among them, hash ₀₀ can be obtained by sequentially splicing hash ₀₀₀ and hash ₀₀₁ and calculating hash, and hash ₀₁ can be obtained by sequentially splicing hash ₀₀₂ and hash ₀₀₃ and calculating hash. Further, hash ₀₀ and hash ₀₁ can be sequentially concatenated to calculate hash, thereby obtaining hash ₀ . As shown in Figure 13.

Furthermore, for each data block, Node ₀ can generate a corresponding merkle proof (Merkle proof). For example, for m ₀₁ , the generated Merkle proof includes hash ₀₀₀ , hash ₀₁ , hash ₀ ; for m ₀₂ , the generated Merkle proof includes hash ₀₀₃ , hash ₀₀ , hash ₀ ; for m ₀₃ , the generated Merkle proof The proof includes hash ₀₀₂ , hash ₀₀ , and hash ₀ . It can be seen that the Merkle proof is an ordered set of hash values. Through such an ordered set, the hash value of the root node of the Merkle tree can be calculated.

The first consensus node sends a first message to other consensus nodes, and the first messages sent to different consensus nodes include different data blocks and corresponding Merkle certificates. The first consensus node Node ₀ can send the first message Val message to Node ₁ , the Val message can include the data block m ₀₁ , and include the Merkel proof hash ₀₀₀ , hash ₀₁ , and hash ₀ corresponding to the data block. Node ₀ can send the first message Val message to

The Val message may include the data block m ₀₂ , and include the Merkel proofs hash ₀₀₃ , hash ₀₀ , and hash ₀ corresponding to the data block. Node ₀ may send a first Val message to Node ₃ , and the Val message may include a data block m ₀₃ , and include the Merkle certificates hash ₀₀₂ , hash ₀₀ , and hash ₀ corresponding to the data block. As shown in Figure 5. The first consensus node may reserve a copy of the data block, for example, the above-mentioned data block m ₀₀ .

In addition, the Val message sent by Node ₀ to Node ₁ may also include the signature of Node ₀ , for example, marked as sig ₀₀ . Generally, Node ₀ can use its own private key to sign the payload (payload) part of the message. Here, for example, sign m ₀₁ and its corresponding Merkle certificate to obtain sig ₀₀ . In addition, Node ₀ may firstly perform hash calculation on the payload (payload) part of the message to obtain a hash value (that is, a digest value), and then sign the hash value with its own private key to obtain sig ₀₀ . The Val message sent by Node ₀ to other Nodes is similar and will not be repeated here.

The format of the Val message can be such as <r, m ₀₁ , the Merkel proof corresponding to m ₀₁ , sig ₀₀ >, where r can represent the rth consensus. For example, the consensus proposal for m ₀ here is the rth consensus, then the transaction set m ₁ of the next consensus proposal can correspond to the r+1th consensus. The sig ₀₀ may also be a signature of the data including r and m ₀₁ and their corresponding Merkle certificates using its own private key. Similarly, it is also possible to perform hash calculation on m ₀₁ and the corresponding Merkle certificate to obtain the hash value, and then use its own private key to sign the hash value and the data including r to obtain sig ₀₀ .

S43: [Second round] The consensus node that received the first message broadcasts a second message, the second message includes the vote and signature of the transaction set; the vote includes the digest value of the transaction set m ₀ .

At the end of the first round, the consensus nodes that received the first message can verify the correctness of the received first message. For example, Node ₁ may use the public key of Node ₀ to verify the signature of Node ₀ in the first message. In addition, the first message may further include a Merkle certificate corresponding to the received data block. In this way, at the end of the first round, the consensus node that received the first message can also verify the data block in the received first message and the corresponding Merkle proof. Specifically, at the end of the first round, the consensus node that receives the Val message can calculate the hash value of the consensus-proposed data block in the Val message. For example, Node ₁ receives the first consensus node

After the Val message is sent, the hash value of the data block m ₀₁ included in the Val message can be calculated, for example, hash ₀₀₁ . The received Val message, as mentioned above, also includes the merkle proof corresponding to the contained data block. For example, Node ₁ receives the Val message sent by the first consensus node Node ₀ , which also includes the Merkel proof hash ₀₀₀ , hash ₀₁ , and hash ₀ corresponding to data block m ₀₁ . The consensus node that receives the Val message can verify the correctness of the data through the Merkle proof contained in the Val message. For example, after Node ₁ obtains the hash value hash ₀₀₁ of m ₀₁ in the Val message through the aforementioned calculation, it further calculates together with the Merkel proof in the Val message, including calculating hash ₀₀₀ and hash ₀₀₁ to obtain hash′ ₀₀ , and then by Hash′ ₀₀ and hash ₀₁ are calculated to obtain hash′ ₀ , so whether m ₀₁ is correct is determined by comparing whether hash′ ₀ and hash ₀ are consistent. This is because, generally speaking, the probability of a hash collision is extremely low, and it is difficult for the initiator of the message to forge a series of hash values while maintaining the corresponding relationship between these hash values and data blocks. Therefore, if comparing hash' ₀ and hash ₀ are consistent, the subsequent processing can be entered; if not, the received Val message is not approved, that is, the data block contained therein is not approved.

If the verification is passed, go to S43. S43, as specifically shown in FIG. 5 , the consensus node that has received the first message may broadcast the second message. In the second round of message interaction, Node ₁ , Node ₂ , and Node ₃ respectively broadcast the second message to other consensus nodes. This broadcasted second message may be denoted as Bval.

Node ₁ , Node ₂ , and Node ₃ can tell other consensus nodes to vote on the consensus proposal initiated by Node ₀ by broadcasting the second message, and the vote can be to express approval or disapproval of the consensus proposal. If the consensus node approves the transaction set proposed by Node ₀ in this consensus, it can broadcast the hash value of the transaction set in the second round of message interaction, such as hash ₀ above. On the contrary, if the consensus node does not approve the transaction set proposed by Node ₀ in this consensus, it can broadcast 0 in the second round of message interaction.

In this round, Node ₀ does not need to participate in the broadcast, because Node ₀ initiates a consensus proposal in the first round, which itself can represent Node ₀ ’s approval of the message set in the consensus proposal, so that in the second round Node ₁ , Node ₂ , and Node ₃ may respectively broadcast the second message to other consensus nodes.

The second message broadcast by the consensus node may also include the Merkle proof corresponding to the data block broadcast in the third round. For example, in the first round, if the first consensus node generates a corresponding Merkel proof for each data block, and sends the Merkle proof together with the data block in the first message, in the first round At the end of , the consensus node that received the first message can receive the data block and the Merkle proof corresponding to the data block. In this way, in the second round, the second message broadcast by the consensus node may also include the Merkle proof corresponding to the data block. In addition, the second message may also include a signature on the set of transactions. As mentioned above, the consensus node that receives the first message at the end of the first round can verify the correctness of the received first message, for example, Node ₁ verifies whether the signature of Node ₀ is correct.

Similarly, the format of the Bval message can be <r, hash ₀ , sig ₁₀ >, where r can represent the rth consensus, and hash ₀ is the hash value of m ₀ , indicating that the voting point of view on m ₀ is agreed. Then the sig ₁₀ may also be the signature of the data including r and hash ₀ using its own private key. Similarly, it is also possible to perform hash calculation on the data including r and hash ₀ first to obtain a hash value, and then sign the hash value with its own private key to obtain sig ₁₀ .

After receiving the Val message from Node ₀ , Node ₂ can similarly verify whether the signature of Node ₀ is correct. If the verification is correct, Node ₂ can use its own private key to sign hash ₀ in the first message it receives, or use its own private key to sign data including r and hash ₀ , thereby obtaining sig ₂₀ , and then It is also possible to broadcast Bval messages. The Bval message can include r, hash ₀ and signature sig ₂₀ .

After receiving the Val message from Node ₀ , Node ₃ can similarly verify whether the signature of Node ₀ is correct. If the verification is correct, Node ₃ can use its own private key to sign hash ₀ in the first message it receives, or use its own private key to sign data including r and hash ₀ , thereby obtaining sig ₃₀ , and then It is also possible to broadcast Bval messages. The Bval message can include r, hash ₀ and signature sig ₃₀ .

S45: [Third round] After the consensus node receiving the second message collects at least Quorum consistent digest values from different consensus nodes, it broadcasts the third message. The third message includes the data block, the digest value and the collected Arrived signature.

The consensus nodes in the second round broadcast the second message Bval message, so that at the end of the second round, the consensus nodes that received the second message can collect the votes for the consensus proposal in the second message.

For example Node ₀ , at the end of the second round can collect votes in Bval messages. Assume that Node ₀ collects the votes in the Bval messages broadcast by Node ₁ , Node ₂ , and Node ₃ respectively, all of which are the hash values of the transaction set m ₀ , that is, hash ₀ , and Node ₀ broadcasts in the Val message in the first round If hash ₀ is also included, then Node ₀ has collected at least Quorum consistent digest values in this round (for example, at this time f=1, Quorum=3, and actually collected 4).

For example, Node ₁ can collect the votes in the Bval message at the end of the second round, assuming that the votes collected by Node ₁ in the second message broadcast by Node ₂ and Node ₃ are the hash value hash ₀ of the transaction set m ₀ , and if the vote in the second message broadcast by Node ₁ in the second round is also the hash value hash ₀ of the transaction set m ₀ (also means the approval of the transaction set), and received in the first round The Val message sent by Node ₀ also includes the same hash value hash ₀ , then Node ₁ has collected at least Quorum consistent summary values in this round (for example, at this time f=1, Quorum=3, actually collected 4 ).

Node ₂ and Node ₃ are similar to Node ₁ and will not be repeated here.

In addition, the consensus node can also collect the signatures of different nodes at the end of the second round, as mentioned earlier. The number of votes collected up to the second round can be counted by signing. For example, if Node ₁ collects sig ₁₀ (the Bval message broadcast by Node ₁ in the second round contains the vote of Node ₁ and is also collected and signed), sig ₂₀ and sig ₃₀ respectively include the same hash value, then it means There are 3 votes for approval of the hash (in addition, it can also include the signature sig ₀₀ of the same hash value received in the Val message sent by Node ₀ at the end of the first round, and a total of 4 signatures are collected for the same hash value) .

For Node ₁ , if at least Quorum consistent hash values from different consensus nodes are collected, the third message is broadcast. The third message can be recorded as a Prom message, which means that it promises not to change its opinion on the proposal m ₀ . As mentioned above, the hash value of m ₀ can indicate approval, and 0 can indicate disapproval. Node ₂ and Node ₃ are also similar.

The third broadcast message may include the collected votes for m ₀ , such as the hash values and signatures collected in the first and second rounds above.

Additionally, data blocks may be included in the broadcasted third message. Wherein, the data blocks broadcast by the first consensus node may include the data blocks reserved in the first round, and the remaining consensus nodes may broadcast the data blocks received in the first round. For example, in the third round, Node ₀ may include the data block m ₀₀ reserved in the first round in the broadcasted Prom message. In this way, for each consensus node other than Node ₀ , the data block can be collected at the end of the third round. For another example, if Node ₁ receives a data block m ₀₁ of the transaction set m ₀ sent by Node ₀ from the first round of Val messages, then Node ₁ can also include this data block in the Prom message broadcast in the third round m ₀₁ ; For Node ₂ , a data block m ₀₂ of the transaction set m ₀ sent by Node ₀ is received from the first round of Val message, then Node ₂ can also include this data block in the Prom message broadcast in the third round m ₀₂ ; For Node ₃ , a data block m ₀₃ of the transaction set m ₀ sent by Node ₀ is received from the first round of Val message, then Node ₃ can also include this data block in the Prom message broadcast in the third round m ₀₃ .

In addition, the third message may also include a Merkle certificate corresponding to the broadcast data block. The broadcast data block may be broadcast in the third message. In this way, the format of the Prom message can be such as <r, m ₀₁ , Merkel proof corresponding to m ₀₁ , hash ₀ , <signature set>>.

For example

Assume that Node ₀ collects Node ₁ in the second round, and the votes in the Bval messages broadcast by Node ₂ and Node ₃ are all hash values of the transaction set m ₀ , so that Node ₁ , Node ₂ and Node 3 are also collected. ₃ The signatures for m ₀ (or the hash value of m ₀ ) are votes of sig ₁₀ , sig ₂₀ , and sig ₃₀ respectively, and the Val message broadcast by Node ₀ in the first round also includes its own signature on m ₀ (or m 0 The hash value of ₀ ) is signed as the hash value of sig ₀₀ . In this way, Node ₀ collects at least Quorum consistent digest values in this round (for example, Quorum=3 at this time). Furthermore, the Prom message broadcast by Node ₀ in the third round may include the hash value and the collected hash value and signature set that different nodes express approval for the proposed transaction set m ₀ . The signature set is, for example, sig ₀₀ , sig ₁₀ , sig ₂₀ , sig ₃₀ .

For example, assuming that Node ₁ collects in the second round that the votes in the Bval messages broadcast by Node ₂ and Node ₃ are all the hash values of the transaction set m ₀ , so that Node ₂ and Node ₃ respectively collect The signature of m ₀ (or the hash value of m ₀ ) is the vote of sig ₂₀ and sig ₃₀ , and the Val message broadcast by Node ₀ in the first round also includes its signature on m ₀ (or the hash value of m ₀ ) is a vote of sig ₀₀ , and the Bval message broadcast by Node ₁ in the second round also includes the vote that its signature on m ₀ (or the hash value of m ₀ ) is sig ₁₀ . In this way, Node ₁ collects at least Quorum consistent digest values (for example, Quorum=3 at this time) and signatures of different nodes in the first round and the second round. Furthermore, the Prom message broadcast by Node ₁ in the third round may include the hash value and the collected hash value and signature set that different nodes approve of the proposed transaction set m ₀ , the signature set includes, for example, sig ₀₀ , sig ₁₀ , sig ₂₀ , sig ₃₀ .

Node ₂ and Node ₃ are also similar to Node ₁ .

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

S47: At the end of the third round, the consensus node uses the erasure code to restore the transaction set based on the received data block, and after collecting at least Quorum third messages from different nodes, the summary The transaction set corresponding to the value is output as at least part of the consensus result.

After the third round of execution, the consensus nodes that receive the Prom message can collect the data blocks in the Prom message.

For Node ₁ , a data block m ₀₀ of transaction set m ₀ sent by Node ₀ is received from the third round of Prom messages, and a data block of transaction set m ₀ sent by Node ₂ is received from the third round of Prom messages Block m ₀₂ , a data block m ₀₃ of the transaction set m ₀ sent by Node ₃ is received from the third round of Prom messages. Node ₁ also receives m ₀₁ from Node ₀ through the first round of Val messages. According to the settings of p and q in the erasure code as mentioned above (generally q is at least 1, and by the end of the third round, Node ₁ should receive at least p different data blocks), Node ₁ has relatively With a high probability, m ₀ can be decoded from m ₀₀ , m ₀₁ , m ₀₂ , and m ₀₃ , so that the complete proposed transaction set of Node ₀ can be recovered.

Similarly, for Node ₂ , a data block m ₀₀ of the transaction set m ₀ sent by Node ₀ is received from the third round of Prom messages, and the transaction set m ₀ sent by Node ₁ is received from the third round of Prom messages Receive a data block m ₀₁ of the transaction set _{m 03} _sent by Node ₃ from the third round of Prom messages. Node ₁ also receives m ₀₁ from Node ₀ through the first round of Val messages. According to the settings of p and q in the erasure code as mentioned above, Node ₂ has a high probability of being able to decode m ₀ from m ₀₀ , m ₀₁ , m ₀₂ , and m ₀₃ , so that the complete Node ₀ can be recovered The set of proposed transactions.

Similarly, for Node ₃ , a data block m ₀₀ of the transaction set m ₀ sent by Node ₀ is received from the third round of Prom messages, and the transaction set m ₀ sent by Node ₁ is received from the third round of Prom messages Receive a data block m ₀₁ of the transaction set _{m 01} _sent by Node ₂ from the third round of Prom messages. Through the first round of Val messages, Node ₃ also receives the m ₀₃ sent by Node ₀ . According to the settings of p and q in the erasure code as mentioned above, Node ₃ has a high probability of being able to decode m ₀ from m ₀₀ , m ₀₁ , m ₀₂ , and m ₀₃ , so that the complete Node ₀ can be recovered The set of proposed transactions.

In this way, at the end of the third round, the consensus node can use the erasure code to restore the transaction set based on the received data block.

As mentioned above, the second message or the third message broadcast by the consensus node may include the Merkle proof corresponding to the data block. In this way, at the end of the third round, the consensus node that received the data block can also combine the corresponding Merkle proof for verification. The original data can be recovered after passing the verification, that is, m ₀ can be obtained from the aforementioned decoding, and the complete proposed transaction set of Node ₀ can be recovered from it. Specifically, at the end of the third round, the consensus node that receives the Prom message can calculate the hash value of the data block in the Prom message. For example, after Node ₁ receives the Prom message sent by the first consensus node Node ₀ , it can calculate the hash value of the data block m ₀₀ included in the Prom message, for example, hash ₀₀₀ . As mentioned above, the Prom message sent by Node ₀ may also include the merkle proof corresponding to the contained data block m ₀₀ , for example including hash ₀₀₁ , hash ₀₁ , and hash ₀ . In this way, after Node ₁ obtains the hash value hash ₀₀₀ of m ₀₀ in the Prom message through the aforementioned calculation, it further calculates together with the Merkle proof, including calculating hash ₀₀₀ and hash ₀₀₁ to obtain hash′ ₀₀ , and then combining hash′ ₀₀ and Hash ₀₁ is calculated to get hash′ ₀ , so whether m ₀₀ is correct is determined by comparing whether hash′ ₀ is consistent with hash ₀ . This is because, generally speaking, the probability of a hash collision is extremely low, and it is difficult for the initiator of the message to forge a series of hash values while maintaining the corresponding relationship between these hash values and data blocks. Therefore, if comparing hash' ₀ and hash ₀ are consistent, you can enter subsequent processing; if they are not consistent, the received Prom message is not approved, that is, the data block contained therein is not approved.

For another example, when Node ₁ receives the Val message sent by the first consensus node Node ₀ , it may include the data block m ₀₁ and the corresponding Merkel proof hash ₀₀₀ , hash ₀₁ , and hash ₀ . The consensus node that receives the Val message can verify the correctness of the data through the Merkle proof contained in the Val message. For example, after Node ₁ obtains the hash value hash ₀₀₁ of m ₀₁ in the Val message through the aforementioned calculation, it further calculates together with the Merkel proof in the Val message, including calculating hash ₀₀₀ and hash ₀₀₁ to obtain hash′ ₀₀ , and then by Hash′ ₀₀ and hash ₀₁ are calculated to obtain hash′ ₀ , so whether m ₀₁ is correct is determined by comparing whether hash′ ₀ and hash ₀ are consistent. The Prom message broadcast by Node ₁ in the third round may include the data block m ₀₁ . In addition, Node ₁ may include the Merkel proof hash ₀₀₀ , hash ₀₁ , and hash ₀ corresponding to the data block m ₀₁ in the Bval message broadcast in the second round or the Prom message broadcast in the third round. At the end of the third round, Node ₀ , Node ₂ , and Node ₃ may all receive the data block m ₀₁ and the corresponding Merkle certificate from Node ₁ . Each of Node ₀ , Node ₂ , and Node ₃ can perform the above-mentioned verification process to verify the correctness of the data, and after passing the verification, enter the process of restoring the transaction set using erasure codes.

After the third round of execution, consensus nodes that have received Prom messages can count the number of collected Prom messages. The condition for the consensus node to send the Prom message in the third round is that at least Quorum unanimous votes from different consensus nodes have been collected in the second round, and it has not broadcast different votes for the proposal, which is equivalent to the second round At the end, the consensus node confirms that a total of at least Quorum number of consensus nodes (including itself) votes for the proposal m ₀ . However, after the end of the second round, the consensus result cannot be output immediately, but it is necessary to observe whether other nodes have also collected at least Quorum number of votes for the proposal m ₀ at the end of the second round, so it is necessary to pass the third round Prom message to confirm, and through the Prom message promise that it will not express different views on the same proposal m ₀ .

For example

Collect at least Quorum consistent digest values in the first and second rounds, and then, the Prom message broadcast by Node ₀ in the third round can include the hash value and the collected transactions of different nodes for the proposal The set m ₀ represents an approved hash value and signature set, and the signature set includes, for example, sig ₀₀ , sig ₁₀ , sig ₂₀ , and sig ₃₀ .

For example, Node ₁ collects at least Quorum consistent digest values in the first round and the second round, and then, the Prom message broadcast by Node ₁ in the third round may include the hash value and the collected different nodes for the The proposed transaction set m ₀ represents the approved hash value and signature set, and the signature set includes, for example, sig ₀₀ , sig ₁₀ , sig ₂₀ , and sig ₃₀ .

Node ₂ and Node ₃ are also similar to Node ₁ .

In this way, through the third round, for example, Node ₀ can collect at least Quorum Prom messages. Through Quorum Prom messages, Node ₀ can confirm that each of at least Quorum consensus nodes has collected at least Quorum number of votes to approve the proposed transaction set m ₀ , and each consensus node that sends Prom messages commits to The point of view of voting will not be changed, so that Node ₀ can further complete this consensus, that is, output the transaction set m ₀ corresponding to the summary value as at least a part of the consensus result. Node ₁ , Node ₂ and Node ₃ are also similar. Similarly, other consensus nodes such as Node ₁ , Node ₂ , and Node ₃ can further complete this consensus, that is, output the transaction set m ₀ corresponding to the digest value as at least a part of the consensus result.

The third round of Prom messages can add signatures. For example, the Prom message broadcast by Node ₁ in the third round may include Node ₁ 's signature of <r, hash, <signature set>> in the Prom message.

The above-mentioned way of generating Merkle Tree in Figure 13, generally for a binary Merkle Tree, the number of bottom leaf nodes is ²ⁿ . However, the number of data blocks generated by using erasure coding (Erasure Coding) is not necessarily 2 ⁿ . In this case, the hash of the last data block can be repeated several times to complete the 2 ⁿ leaf nodes of the Merkle Tree. For example, when there are 5 consensus nodes Node ₀ , Node ₁ , Node ₂ , Node ₃ , and Node ₄ in total, Node ₀ uses the erasure code to generate 5 data blocks m ₀₀ , m from the transaction set m ₀ proposed by the consensus ₀₁ , m ₀₂ , m ₀₃ , m ₀₄ , and the constructed Merkle Tree can be shown in Figure 14. The hash value corresponding to m ₀₀ is hash ₀₀₀₀ , the corresponding hash value to m ₀₁ is hash ₀₀₀₁ , and the corresponding hash value to m ₀₂ is hash ₀₀₀₂ , the hash value corresponding to m ₀₃ is hash ₀₀₀₃ , and the corresponding hash value to m ₀₄ is hash ₀₀₀₄ . The number of leaf nodes at the bottom layer is generally the smallest 2 ⁿ that is greater than the number of data blocks, where the number of data blocks is 5, 2 ⁿ =2 ³ =8. The extra 3 leaf nodes of the Merkle Tree can take the hash value corresponding to the last data block. As shown in the figure, hash _000s , hash ₀₀₀₆ and hash ₀₀₀₇ may all take the hash value of m ₀₄ . In this way, Merkle Tree and Merkle proof can also be constructed.

The above embodiment in FIG. 5 can be executed by Node ₀ in the figure, and can also be extended to be executed by Node ₀ , Node ₁ , Node ₂ and Node ₃ . In the case of the former, in fact, every consensus node that collects at least Quorum third messages from different nodes can output the transaction set corresponding to the summary value as the entire consensus result, except for Figure 5 Alternatively, any one of Figs. 6, 7, 8, and 9 may be used.

For the latter, that is, the case where Node ₀ , Node ₁ , Node ₂ , and Node ₃ are all executed, Figure 5 is from the perspective of Node ₀ , which initiates a consensus proposal. In fact, Node ₁ , Node ₂ , and Node ₃ Any one can also initiate a proposal, and other consensus nodes cooperate to complete the above-mentioned similar process, so that the whole is the superposition of Figures 5, 6, 7, 8, and 9.

For the latter case, for example, the transaction set of Node ₀ initiating the consensus proposal is m ₀ , the transaction set of Node ₁ initiating the consensus proposal is m ₁ , the transaction set of Node ₂ initiating the consensus proposal is m ₂ , and the transaction set of Node ₃ initiating the consensus proposal The set is m ₃ , so m ₀ can correspond to hash ₀ , m ₁ can correspond to hash ₁ , m ₂ can correspond to hash ₂ , and m ₃ can correspond to hash ₃ . If executed normally, the consensus output of each consensus node is {m ₀ , m ₁ , m ₂ , m ₃ } with high probability. As for the order of m ₀ , m ₁ , m ₂ , m ₃ in the output results, It can be sorted according to certain rules, for example, sorted according to the size order of the corresponding hash values.

In the above embodiment, under certain conditions, it can be shortened to 3 rounds to complete a consensus. Compared with at least 6 rounds in HBBFT, the delay caused by the consensus process is greatly reduced. In fact, in the embodiment of this application, it is equivalent to combining the last two rounds of the RBC process and the first two rounds of the ABA process in the HBBFT by using the forward-looking voting and digital signature technology, thereby shortening the required rounds. The forward-looking voting refers to voting in the second round of Bval in the above embodiment, while HBBFT needs to vote in the fifth round of Bval in the ABA process. The digital signature refers to the digital signature used in the first round and the second round in the above embodiment.

Moreover, using erasure codes to generate several data blocks for the transaction proposed by the consensus, the proposed consensus node does not need to transmit a larger data packet to each of the remaining consensus nodes, but transmits different data blocks of the data packet to different consensus nodes. nodes, which can reduce the amount of data transmitted by the network. Forwarding the data blocks sent by the proposed consensus nodes in the second round can make full use of the bandwidth resources between nodes in the network, thereby improving the performance of the consensus protocol as a whole.

The present application also provides an embodiment of a blockchain system, including consensus nodes, wherein: the first consensus node uses erasure codes to generate multiple data blocks from the transaction set proposed by the consensus; the first consensus node retains a copy of the data block, and Send the first message to other consensus nodes, and the first messages sent to different consensus nodes include different data blocks and the signature of the first consensus node; the consensus node that receives the first message broadcasts the second message, and the second consensus node receives the first message The second message includes the received data block, and includes votes and signatures on the transaction set; the vote includes the summary value of the transaction set; the consensus node that receives the second message collects at least Quorum from After unanimous voting by different consensus nodes, broadcast a third message, the third message includes the data block, the digest value and the collected signature set; wherein the data block broadcast by the first consensus node includes the reserved data block, The remaining consensus nodes broadcast the data blocks received in the first round; at the end of the third round, the consensus nodes use the erasure code to recover the transaction set based on the received data blocks, and collect at least Quorum After the third message from a different node, the transaction set corresponding to the summary value is output as at least a part of the consensus result.

Wherein, the first consensus node uses the erasure code to generate n data blocks from the transaction set proposed by the consensus, and the n is equal to the total number of consensus nodes.

Wherein, in the first round, the first consensus node generates a corresponding Merkel certificate for each data block, and the first message sent also includes the Merkel certificate; correspondingly, at the end of the first round, receiving The consensus node that received the first message also verifies the received data block and the Merkle proof; after passing the verification, it enters the second round.

Wherein, the broadcasted second message or the third message further includes the Merkle certificate corresponding to the broadcasted data block.

Wherein, in the third round, the third message broadcast by the first consensus node also includes the data blocks reserved in the first round.

Wherein, at the end of the third round, the consensus node that received the third message also verifies the received data block and the corresponding Merkle certificate; after the verification is passed, it enters the process of restoring the transaction set using erasure codes.

Wherein, in the same consensus process, each of at least Quorum number of consensus nodes in the blockchain system serves as the first consensus node.

The present application also provides an embodiment of a consensus node in a blockchain system. For example, the consensus node is the first consensus node. This embodiment can also be shown in FIG. The proposed transaction set uses erasure codes to generate multiple data blocks, and retains a copy of the data blocks; the first message broadcast unit 102 is used to broadcast the first message to other consensus nodes, which are distinguished in the blockchain system. For the remaining consensus nodes of the first consensus node, the first messages sent to different consensus nodes include different data blocks and the signature of the first consensus node; the second message receiving unit 103 is configured to receive the second message, The second message includes votes and signatures on the transaction set; the vote includes the summary value of the transaction set; the third message broadcast unit 104, when the second message receiving unit collects at least Quorum from different consensus nodes The third message is broadcast after the unanimous vote of the , the third message includes the reserved data block, the digest value and the collected signature set; the third message collection unit 105 is used to collect the third message from different consensus nodes Message; the output unit 106, after the third message collection unit collects at least Quorum third messages from different nodes, outputs the transaction set corresponding to the summary value as at least a part of the consensus result.

Wherein, the data block generation unit 101 generates n data blocks using erasure codes for the transaction set proposed by the consensus, where n is equal to the total number of consensus nodes.

The data block generating unit 101 also generates a corresponding Merkel certificate for each data block, and the first message sent by the first message broadcasting unit may also include the Merkel certificate.

The third broadcast message may also include the Merkle certificate corresponding to the reserved data block.

Wherein, a verification unit may also be included, configured to verify the data block in the third message and the corresponding Merkle certificate after the third message receiving unit receives the third message.

Wherein, the third message broadcast by the third message broadcasting unit may further include the data block reserved by the data block generating unit.

The present application also provides an embodiment of a consensus node in a blockchain system, as shown in Figure 11, including: a first message receiving unit 111, configured to receive the first message broadcast by the first consensus node, in the first message Including a data block of the proposed transaction set and the signature of the first consensus node; the second message broadcast unit 112, used to broadcast the second message after the first message receiving unit 111 receives the first message, in the second message Including votes and signatures on the transaction set; the vote includes a summary value of the transaction set; the second message receiving unit 113 is configured to receive a second message, the second message includes the vote on the transaction set and signature; the vote includes the summary value of the transaction set; the third message broadcast unit 114, when the second message receiving unit 112 collects at least Quorum unanimous votes from different consensus nodes, broadcasts the third message, the first The three messages include the digest value and the collected signature set; the third message collection unit 115 collects the third messages from different consensus nodes; the recovery unit 116 uses the data block received by the third message collection unit 115 based on the The erasure code restores the transaction set; the output unit 117, when the third message collection unit 115 collects at least Quorum third messages from different nodes, uses the transaction set corresponding to the digest value as the consensus result at least part of the output.

Wherein, the first message received by the first message receiving unit 111 also includes the Merkle certificate; correspondingly, the first message receiving unit 111 also verifies the received data block and the Merkle certificate.

Wherein, the second message or the third message further includes the Merkel certificate corresponding to the broadcast data block, and the third message receiving unit 113 also verifies the received data block and the corresponding Merkel certificate.

In the 1990s, the improvement of a technology can be clearly distinguished as an improvement in hardware (for example, improvements in circuit structures such as diodes, transistors, and switches) or improvements in software (improvement in method flow). However, with the development of technology, the improvement of many current method flows can be regarded as the direct improvement of the hardware circuit structure. Designers almost always get the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose logic function is determined by programming the device by the user. It is programmed by the designer to "integrate" a digital system on a PLD, instead of asking a chip manufacturer to design and make a dedicated integrated circuit chip. Moreover, nowadays, instead of making integrated circuit chips by hand, this kind of programming is mostly realized by "logic compiler (logic compiler)" software, which is similar to the software compiler used when program development and writing, but before compiling The original code of the computer must also be written in a specific programming language, which is called a hardware description language (Hardware Description Language, HDL), and there is not only one kind of HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language) , AHDL (Altera Hardware Description Language), Confluence, CUPL (Comell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., are currently the most commonly used The most popular are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. It should also be clear to those skilled in the art that only a little logical programming of the method flow in the above-mentioned hardware description languages and programming into an integrated circuit can easily obtain a hardware circuit for realizing the logic method flow.

The controller may be implemented in any suitable way, for example the controller may take the form of a microprocessor or processor and a computer readable medium storing computer readable program code (such as software or firmware) executable by the (micro)processor , logic gates, switches, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), programmable logic controllers and embedded microcontrollers, examples of controllers include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art also know that, in addition to realizing the controller in a purely computer-readable program code mode, it is entirely possible to make the controller use logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded The same function can be realized in the form of a microcontroller or the like. Therefore, such a controller can be regarded as a hardware component, and the devices included in it for realizing various functions can also be regarded as structures within the hardware component. Or even, means for realizing various functions can be regarded as a structure within both a software module realizing a method and a hardware component.

The systems, devices, modules, or units described in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, the present application does not exclude that with the development of future computer technology, the computer that realizes the functions of the above embodiments can be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant , media players, navigation devices, email devices, game consoles, tablet computers, wearable devices, or any combination of these devices.

Although one or more embodiments of the present specification provide the operation steps of the method described in the embodiment or the flowchart, more or fewer operation steps may be included based on conventional or non-inventive means. The sequence of steps enumerated in the embodiments is only one of the execution sequences of many steps, and does not represent the only execution sequence. When an actual device or terminal product is executed, the methods shown in the embodiments or drawings can be executed sequentially or in parallel (such as a parallel processor or multi-thread processing environment, or even a distributed data processing environment). The term "comprising", "comprising" or any other variation thereof is intended to cover a non-exclusive inclusion such that a process, method, product, or apparatus comprising a set of elements includes not only those elements, but also other elements not expressly listed elements, or also elements inherent in such a process, method, product, or apparatus. Without further limitations, it is not excluded that there are additional identical or equivalent elements in a process, method, product or device comprising said elements. For example, if the words first, second, etc. are used, they are used to indicate names and do not indicate any specific order.

For the convenience of description, when describing the above devices, functions are divided into various modules and described separately. Of course, when implementing one or more of this specification, the functions of each module can be realized in the same or more software and/or hardware, and the modules that realize the same function can also be realized by a combination of multiple submodules or subunits, etc. . The device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated. to another system, or some features may be ignored, or not implemented. In another point, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be in electrical, mechanical or other forms.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each procedure and/or block in the flowchart and/or block diagram, and a combination of procedures and/or blocks in the flowchart and/or block diagram can be realized by computer program instructions. These computer program instructions may be provided to a general purpose computer, special purpose computer, embedded processor, or processor of other programmable data processing equipment to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing equipment produce a An apparatus for realizing the functions specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture comprising instruction means, the instructions The device realizes the function specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions can also be loaded onto a computer or other programmable data processing device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby The instructions provide steps for implementing the functions specified in the flow chart or blocks of the flowchart and/or the block or blocks of the block diagrams.

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

Memory may include non-permanent storage in computer-readable media, in the form of random access memory (RAM) and/or nonvolatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer readable media.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information. Information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Flash memory or other memory technology, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, Magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission medium that can be used to store information that can be accessed by computing devices. As defined herein, computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.

Those skilled in the art should understand that one or more embodiments of this specification may be provided as a method, system or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of the present description may employ a computer program embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein. The form of the product.

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

Each embodiment in this specification is described in a progressive manner, the same and similar parts of each embodiment can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for relevant parts, refer to part of the description of the method embodiment. In the description of this specification, descriptions referring to the terms "one embodiment", "some embodiments", "example", "specific examples", or "some examples" mean that specific features described in connection with the embodiment or example , structures, materials or features are included in at least one embodiment or example of this specification. In this specification, the schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the described specific features, structures, materials or characteristics may be combined in any suitable manner in any one or more embodiments or examples. In addition, those skilled in the art can combine and combine different embodiments or examples and features of different embodiments or examples described in this specification without conflicting with each other.

The above description is only an example of one or more embodiments of this specification, and is not intended to limit one or more embodiments of this specification. For those skilled in the art, various modifications and changes may occur in one or more embodiments of this description. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this specification shall be included in the scope of the claims.

Claims

A consensus method in a blockchain system, comprising:

The first round: the first consensus node uses the erasure code to generate multiple data blocks from the transaction set proposed by the consensus; the first consensus node retains a data block, and sends the first message to other consensus nodes, and sends it to The first message includes the different data blocks and the signature of the first consensus node;

Second round: The consensus node that received the first message broadcasts a second message, the second message includes votes and signatures on the transaction set; the vote includes the summary value of the transaction set;

The third round: After the consensus node receiving the second message collects at least Quorum unanimous votes from different consensus nodes, it broadcasts the third message, which includes the data block, the digest value and the collected signature set ; Wherein the data blocks broadcast by the first consensus node include the reserved data blocks, and the remaining consensus nodes broadcast the data blocks received in the first round;

At the end of the third round, the remaining consensus nodes use the erasure code to restore the transaction set based on the received data block, and after collecting at least Quorum third messages from different nodes, the The transaction set corresponding to the summary value is output as at least part of the consensus result.
The method according to claim 1, wherein the first consensus node uses an erasure code to generate n data blocks from the transaction set proposed by the consensus, and said n is equal to the total number of consensus nodes.
The method according to claim 1, in the first round, the first consensus node generates a corresponding Merkel certificate for each data block, and the first message sent also includes the Merkel certificate;

Correspondingly, at the end of the first round, the consensus node that receives the first message also verifies the received data block and the Merkle proof; after passing the verification, it enters the second round.
The method according to claim 3, wherein the broadcasted second message or the third message further includes a Merkle certificate corresponding to the broadcasted data block.
The method according to claim 4, at the end of the third round, the consensus node receiving the third message also verifies the received data block and the corresponding Merkel proof; The code resumes the processing of transaction collections.
The method according to claim 1, further verifying the correctness of the third message at the end of the third round, comprising verifying that the signature set of the third message includes at least Quorum signatures.
The method of claim 1, the consensus nodes broadcasting the third message no longer change their voting views for the same proposed set of transactions.
The method according to any one of claims 1-7, wherein the signature set is replaced by an aggregate signature or a threshold signature.
The method according to claim 1, in the same consensus process, each of at least Quorum number of consensus nodes in the blockchain system executes the method of claim 1 as the first consensus node.
A blockchain system comprising consensus nodes, wherein:

The first consensus node uses the erasure code to generate multiple data blocks from the transaction set proposed by the consensus; the first consensus node retains a copy of the data block, and sends the first message to other consensus nodes, and sends it to the first message of different consensus nodes Including different said data blocks and the signature of the first consensus node;

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

After the consensus node receiving the second message collects at least Quorum unanimous votes from different consensus nodes, it broadcasts the third message, which includes the data block, the digest value and the collected signature set; where the first The data block broadcast by the consensus node includes the reserved data block, and the other consensus nodes broadcast the data block received in the first round;

At the end of the third round, the consensus node uses the erasure code to restore the transaction set based on the received data block, and after collecting at least Quorum third messages from different nodes, the summary The transaction set corresponding to the value is output as at least part of the consensus result.
A consensus node in a blockchain system, comprising:

The data block generation unit is used to generate multiple data blocks using erasure codes for the transaction set proposed by the consensus, and retain a copy of the data block;

The first message broadcasting unit is configured to broadcast the first message to other consensus nodes, and the first messages sent to different consensus nodes include different data blocks and signatures of the first consensus node;

The second message receiving unit is configured to receive a second message, the second message includes a vote and a signature on the transaction set; the vote includes a summary value of the transaction set;

The third message broadcasting unit broadcasts a third message when the second message receiving unit collects at least Quorum unanimous votes from different consensus nodes, the third message includes the reserved data block, the digest value and the collected collection of signatures;

A third message collection unit, configured to collect third messages from different consensus nodes;

The output unit, after the third message collection unit collects at least Quorum third messages from different nodes, outputs the transaction set corresponding to the summary value as at least a part of the consensus result.
The consensus node according to claim 11, wherein the data block generation unit generates n data blocks from the transaction set proposed by the consensus using an erasure code, and the n is equal to the total number of consensus nodes.
The consensus node according to claim 11, wherein the data block generating unit further generates a corresponding Merkel certificate for each data block, and the first message sent by the first message broadcasting unit further includes the Merkel certificate.
The consensus node according to claim 11, the broadcasted third message further includes the Merkle certificate corresponding to the reserved data block.
The consensus node according to claim 14, further comprising a verification unit, configured to verify the data block in the third message and the corresponding Merkle certificate after the third message receiving unit receives the third message.
The consensus node according to claim 11, the third message broadcast by the third message broadcasting unit further includes the data block reserved by the data block generating unit.
A consensus node in a blockchain system, comprising:

The first message receiving unit is configured to receive the first message broadcast by the first consensus node, the first message includes a data block of the proposed transaction set and the signature of the first consensus node;

The second message broadcasting unit is configured to broadcast a second message after the first message receiving unit receives the first message, the second message includes a vote and a signature on the transaction set; the vote includes the transaction set the digest value of

The second message receiving unit is configured to receive a second message, the second message includes a vote and a signature on the transaction set; the vote includes a summary value of the transaction set;

The third message broadcasting unit, when the second message receiving unit collects at least Quorum unanimous votes from different consensus nodes, broadcasts a third message, the third message includes the summary value and the collected signature set;

The third message collection unit collects third messages from different consensus nodes;

A recovery unit, based on the data block received by the third message collection unit, recovers the transaction set by using an erasure code;

The output unit outputs the transaction set corresponding to the summary value as at least a part of the consensus result after the third message collection unit collects at least Quorum third messages from different nodes.
The consensus node according to claim 17, the first message received by the first message receiving unit further includes a Merkel certificate;

Correspondingly, the first message receiving unit also verifies the received data block and the Merkle proof.
The consensus node according to claim 17, the second message or the third message also includes the Merkel certificate corresponding to the broadcast data block, and the third message collection unit also checks the received data block and the corresponding Merkel certificate authenticating.