CN113873030A

CN113873030A - Block chain consensus method, consensus node and electronic equipment

Info

Publication number: CN113873030A
Application number: CN202111124497.4A
Authority: CN
Inventors: 廖校均
Original assignee: Alipay Hangzhou Information Technology Co Ltd; Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd; Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2021-09-24
Filing date: 2021-09-24
Publication date: 2021-12-31

Abstract

The embodiment of the specification provides a block chain consensus method, a consensus node and electronic equipment. The method comprises the following steps: the leader node executes an RBC protocol on a first transaction set in the self transaction pool, uses an erasure code algorithm to split the first transaction set into N data blocks corresponding to the common identification nodes of the block chain, and sends the corresponding data blocks to each follower node based on the Rval message. The follower node executes an RBC protocol, forwards the data block received from the Rval message to other follower nodes through Echo messages, and restores the received data block to a first transaction set based on an erasure code algorithm after receiving N-2f Echo messages. The leader node initiates a consensus proposal of merkel tree proofs for all data blocks of the first set of transactions based on the RAFT protocol. And the leader node and the follower node match the transactions corresponding to the acquaintance Mercker tree certification from the respective first transaction sets so as to execute the block writing operation on the transactions.

Description

Block chain consensus method, consensus node and electronic equipment

Technical Field

The present disclosure relates to the field of data processing technologies, and in particular, to a block chain consensus method, a block chain consensus node, and an electronic device.

Background

Based on the characteristics of the blockchain, in the consensus protocol of replication and fault-tolerant RAFT, proposed data for each round of consensus proposals is packaged by a leader node and synchronously transmitted to follower nodes of the blockchain. Assuming that the number of consensus nodes of the block chain is N (both the leader node and the follower node belong to the consensus nodes), for a round of consensus proposal, the leader node needs to send N-1 pieces of proposal data, which creates a significant overhead on the network bandwidth of the leader node.

With the explosive growth of future block chain services, to obtain higher throughput, consensus of more data needs to be achieved in unit time, the burden on the leader node is greater, and the consensus efficiency is reduced. For this reason, a technical solution capable of reducing the bandwidth overhead of the leader node initiating the consensus proposal is needed.

Disclosure of Invention

An embodiment of the present disclosure provides a block chain consensus method, a consensus node, and an electronic device, which can complete block chain consensus with a smaller bandwidth overhead at a leader node side.

In order to achieve the above object, the embodiments of the present specification are implemented as follows:

in a first aspect, a method for identifying a blockchain is provided, including:

a leader node of a block chain executes a reliable broadcast transmission (RBC) protocol on a first transaction set in a transaction pool of the leader node, so that an erasure code algorithm is used to split the first transaction set into N data blocks corresponding to common identification nodes of the block chain, and corresponding data blocks are sent to each follower node of the block chain based on a Rval message, wherein the data blocks split by the first transaction set correspond to a Mercker tree certificate calculated based on the erasure code algorithm, and N is the number of common identification nodes of the block chain;

the follower node executes the RBC protocol to forward the corresponding data blocks received from the Rval message to other follower nodes through Echo messages, and after receiving N-2f Echo messages, restores the received data blocks to the first transaction set based on the erasure code algorithm, where f is a consensus node fault-tolerant number of the block chain;

the leader node, after executing the RBC protocol on the first transaction set, executing a copy and fault tolerant RAFT protocol on the mercker tree proofs of all data blocks of the first transaction set to initiate a consensus proposal for the mercker tree proofs of all data blocks of the first transaction set;

the follower node responding to the consensus proposal based on the RAFT protocol to complete consensus of Mercker tree proofs for all data blocks of the first transaction set;

after the acquaintance tree proofs of all the data blocks of the first transaction set are identified, the leader node and the follower node match the corresponding transaction of the acquaintance tree proofs which reach the identification from the respective first transaction sets, so as to execute a block writing operation on the matched transaction.

In a second aspect, a block chain consensus method is provided, including:

a leader node executing a reliable broadcast transmission RBC protocol on a first transaction set in a transaction pool of the leader node to split the first transaction set into N data blocks corresponding to consensus nodes of the block chain using an erasure code algorithm, and sending corresponding data blocks to each follower node of the block chain based on Rval messages, such that follower nodes execute the RBC protocol, forwarding the corresponding data blocks received from the Rval messages to other follower nodes via Echo messages, and broadcasting Ready messages to the block chain after receiving N-f Echo messages, and after receiving 2f +1 Ready messages, reducing the received data blocks into the first transaction set based on the erasure code algorithm, wherein the data blocks into which the first transaction set is split correspond to a mercker tree certificate calculated based on the erasure code algorithm, n is the number of the consensus nodes of the block chain, and f is the fault-tolerant number of the consensus nodes of the block chain;

the leader node, after executing the RBC protocol on the first transaction set, executing a copy and fault tolerant RAFT protocol on the mercker tree proofs of all data blocks of the first transaction set to initiate a consensus proposal for the mercker tree proofs of all data blocks of the first transaction set, such that the follower node responds to the consensus proposal based on the RAFT protocol to complete consensus for the mercker tree proofs of all data blocks of the first transaction set;

after the acquaintance tree certificates of all the data blocks of the first transaction set are agreed, the leader node matches the transaction corresponding to the acquaintance tree certificate from the first transaction set so as to execute a writing block operation on the matched transaction.

In a third aspect, a block chain consensus method is provided, including:

a follower node of a block chain receives a data block corresponding to a follower node transmitted by a leader node of the block chain when the leader node executes an RBC protocol, wherein the data block corresponding to the follower node is a reliable broadcast transmission RBC protocol executed by the leader node on a first transaction set in a transaction pool of the leader node, so that the first transaction set is split into N data blocks corresponding to common identification nodes of the block chain by using an erasure code algorithm and transmitted to the follower node based on a Rval message;

the follower node executes the RBC protocol, forwards the corresponding data block received from the Rval message to other follower nodes through Echo messages, and restores the received data block to the first transaction set based on the erasure code algorithm after receiving N-2f Echo messages, wherein f is the fault-tolerant number of the common identification node of the block chain;

after the leader node performs a copy and fault tolerant RAFT protocol on the Mercker tree proofs of all data blocks of the first transaction set to initiate a consensus proposal for the Mercker tree proofs of all data blocks of the first transaction set, the follower node responds to the consensus proposal based on the RAFT protocol to complete the consensus for the Mercker tree proofs of all data blocks of the first transaction set;

after the acquaintance of the mercker trees of all the data blocks of the first transaction set is proved to be known, the follower node matches the transaction corresponding to the acquaintance mercker tree from the restored first transaction set so as to execute writing block operation on the matched transaction.

In a fourth aspect, a consensus node of a blockchain is provided, including:

a first RBC execution module, wherein the leader node executes a reliable broadcast transmission RBC protocol on a first transaction set in the transaction pool of the leader node, so as to split the first transaction set into N data blocks corresponding to common identification nodes of the block chain by using an erasure code algorithm, and sends the corresponding data blocks to each follower node of the block chain based on a Rval message, so that the follower node executes the RBC protocol, forwards the corresponding data blocks received from the Rval message to other follower nodes by using an Echo message, and after receiving N-2f Echo messages, restores the received data blocks to the first transaction set based on the erasure code algorithm, wherein the data blocks into which the first transaction set is split correspond to mercker tree certificates calculated based on the erasure code algorithm, N is the number of common identification nodes of the block chain, f is the fault tolerance number of the consensus node of the block chain;

a first RAFT execution module that, after executing the RBC protocol on the first transaction set, the leader node performs a copy and fault tolerant RAFT protocol on the Mercker tree proofs of all data blocks of the first transaction set to initiate a consensus proposal for the Mercker tree proofs of all data blocks of the first transaction set, such that the follower node responds to the consensus proposal based on the RAFT protocol to complete consensus of the Mercker tree proofs for all data blocks of the first transaction set;

and the first writing block module is used for matching the transaction corresponding to the Mercker tree certificate reaching the consensus from the first transaction set after the Mercker tree certificates of all the data blocks of the first transaction set complete the consensus so as to execute writing block operation on the matched transaction.

In a fifth aspect, an electronic device is provided comprising: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being executed by the processor to:

a reliable broadcast transmission RBC protocol is performed on a first set of deals in the leader node's deal pool, to split the first set of transactions into N data blocks corresponding to common nodes of the chain of blocks using an erasure coding algorithm, and sends corresponding data blocks to each follower node of the block chain based on the Rval message, so that the follower node executes the RBC protocol, the corresponding data block received from the Rval message is forwarded to other follower nodes by Echo message, and after receiving N-2f Echo messages, restoring the received data blocks to the first transaction set based on the erasure coding algorithm, the data blocks divided by the first transaction set correspond to a Mercker tree certificate calculated based on the erasure code algorithm, N is the number of common identification nodes of the block chain, and f is the fault-tolerant number of the common identification nodes of the block chain;

after executing the RBC protocol on the first transaction set, executing a replication and fault tolerant RAFT protocol on the merkel tree proofs of all data blocks of the first transaction set to initiate a consensus proposal for the merkel tree proofs of all data blocks of the first transaction set, such that the follower node responds to the consensus proposal based on the RAFT protocol to complete the consensus for the merkel tree proofs of all data blocks of the first transaction set;

after the acquaintance tree certificates of all the data blocks of the first transaction set are identified, matching the transaction corresponding to the acquaintance tree certificate from the first transaction set so as to execute a writing block operation on the matched transaction.

In a sixth aspect, a computer readable storage medium is provided, having a computer program stored thereon, which when executed by a processor, performs the steps of:

In a seventh aspect, a consensus node of a blockchain is provided, including:

a receiving module, configured to receive a data block corresponding to a follower node sent by a leader node of the block chain when executing an RBC protocol, where the data block corresponding to the follower node is a reliable broadcast transmission RBC protocol executed by the leader node on a first transaction set in a transaction pool of the leader node, so as to split the first transaction set into N data blocks corresponding to common identification nodes of the block chain by using an erasure coding algorithm, and send the data block to the follower node based on a Rval message;

the second RBC execution module executes the RBC protocol, forwards the corresponding data block received from the Rval message to other follower nodes through Echo messages, restores the received data block to the first transaction set based on an erasure code algorithm after receiving N-2f Echo messages, and restores the received data block to the first transaction set based on the erasure code algorithm, wherein f is a fault tolerance number of a common identification node of the block chain;

a second RAFT execution module that, after the leader node executes a copy and fault tolerant RAFT protocol on the Mercker tree proofs of all data blocks of the first set of transactions to initiate a consensus proposal for the Mercker tree proofs of all data blocks of the first set of transactions, responds to the consensus proposal based on the RAFT protocol to complete consensus for the Mercker tree proofs of all data blocks of the first set of transactions;

and the second writing block module is used for matching the transaction corresponding to the acquaintance-reached tacher tree certificate from the restored first transaction set after the acquaintance tree certificates of all the data blocks in the first transaction set are identified, so as to execute writing block operation on the matched transaction.

In an eighth aspect, an electronic device is provided comprising: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being executed by the processor to:

receiving a data block corresponding to a follower node transmitted by a leader node of the block chain when executing an RBC protocol, wherein the data block corresponding to the follower node is a reliable broadcast transmission RBC protocol executed by the leader node on a first transaction set in a transaction pool of the leader node, so as to split the first transaction set into N data blocks corresponding to common identification nodes of the block chain by using an erasure coding algorithm, and transmitting the data block to the follower node based on a Rval message;

executing the RBC protocol, forwarding the corresponding data block received from the Rval message to other follower nodes through Echo messages, broadcasting Ready messages to the blockchain after receiving N-f Echo messages, and restoring the received data block into the first transaction set based on the erasure code algorithm after receiving 2f +1 Ready messages, wherein f is the fault-tolerant number of the common identification node of the blockchain;

after the leader node performs a copy and fault tolerant RAFT protocol on the Mercker tree proofs of all data blocks of the first transaction set to initiate a consensus proposal for the Mercker tree proofs of all data blocks of the first transaction set, responding to the consensus proposal based on the RAFT protocol to complete the consensus for the Mercker tree proofs of all data blocks of the first transaction set;

after the acquaintance of the mercker tree certificates of all the data blocks of the first transaction set are identified, matching the transaction corresponding to the acquaintance merker tree certificates from the restored first transaction set, and executing writing block operation on the matched transaction.

In a ninth aspect, there is provided a computer readable storage medium having a computer program stored thereon, the computer program when executed by a processor implementing the steps of:

The scheme of the embodiment of the specification realizes consensus through an RBC protocol and a RAFT protocol. In the RBC protocol stage, the leader node splits a transaction set serving as proposed data into data blocks corresponding to follower nodes by using an erasure code transmission mechanism of the RBC protocol, and transmits the split data blocks to the corresponding follower nodes, and then the follower nodes forward each other so as to share the transmission of the proposed data, so that the transmission fault tolerance is realized by using smaller network bandwidth and storage space cost of the leader node. In the RAFT protocol stage, the leader node takes the Mercker tree certificate of the data block of the RBC protocol result as a consensus object to initiate a consensus proposal, so that the Mercker tree certificate achieving consensus is matched back to the corresponding transaction to complete the block writing operation.

Drawings

In order to more clearly illustrate the embodiments of the present specification or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, it is obvious that the drawings in the following description are only some embodiments described in the embodiments of the present specification, and for those skilled in the art, other drawings can be obtained according to the drawings without any creative efforts.

Fig. 1 is a schematic flowchart of a block chain consensus method provided in an embodiment of the present disclosure.

Fig. 2 is a first structural diagram of a consensus node provided in an embodiment of the present disclosure.

Fig. 3 is a second structural diagram of a consensus node provided in an embodiment of the present disclosure.

Fig. 4 is a schematic structural diagram of an electronic device provided in an embodiment of this specification.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all of the embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step should fall within the scope of protection of the present specification.

As previously described, in existing RAFT protocol consensus, the proposed data for each round of consensus proposals is packaged by the leader node and synchronously transmitted to follower nodes of the block chain. Assuming that the number of consensus nodes of the blockchain is N, for a round of consensus proposals, the leader node needs to send N-1 proposals of data, which creates a significant overhead on the network bandwidth of the leader node. With the explosive growth of future block chain services, to obtain higher throughput, consensus of more data needs to be achieved in unit time, the burden on the leader node is greater, and the consensus efficiency is reduced. In view of the above, this document aims to provide a technical solution that can implement block chain consensus with less bandwidth overhead of a leader node to meet the growing demand of future block chain services.

Fig. 1 is a flowchart illustrating a block chain consensus method according to an embodiment of the present disclosure. The method shown in fig. 1 may be performed by a corresponding apparatus below, comprising the steps of:

s102, a leader node of a block chain executes a reliable broadcast transmission RBC protocol on a first transaction set in a transaction pool of the leader node, so that the first transaction set is divided into N data blocks corresponding to common identification nodes of the block chain by using an erasure code algorithm, and the corresponding data blocks are sent to all follower nodes of the block chain based on a Rval message, wherein the data blocks divided by the first transaction set correspond to a Merck tree certificate calculated based on the erasure code algorithm, and N is the number of the common identification nodes of the block chain.

Erasure Coding (EC) is a method of data fault-tolerant protection that segments data into segments, expands, encodes, and stores redundant data blocks in different locations, such as disks, storage nodes, or other geographic locations. From a data function perspective, the protection provided by erasure codes can be given by the following formula: x is represented by k + y. The variable x "represents the value of the original data or symbol. The variable "y" represents the value of an extra or redundant symbol added after a failure that provides protection. The variable "x" represents the total value of the symbols created after the erasure coding process. For example, in one EC 10/16 configuration, there would be 6 additional symbols (variable m) added to the 10 original symbols (variable k). These 16 data segments (variable n) may be spread over 16 drives, nodes or geographical locations, while the original file may be reconstructed from 10 verification segments. That is, the original file can be restored even if 6 drives, nodes, or geographic locations are lost or unavailable. It can be seen that the erasure code only needs redundancy with a small amount of data to achieve restoration of data.

In this embodiment of the present specification, the leader node executes the RBC protocol in order to synchronize the first transaction set (subsequently as proposal data) that needs to be commonly recognized in its own transaction pool to the follower node of the blockchain summary using erasure coding techniques. Based on an erasure code technology, after splitting a transaction set in a self transaction pool into data blocks corresponding to all common identification nodes, a leader node only needs to send the data blocks corresponding to follower nodes to each follower node. That is, in the synchronization process, the data volume sent by the leader node is only the data volume of one transaction set.

S104, the follower node executes an RBC protocol to forward the corresponding data block received from the Rval message to other follower nodes through Echo messages, and after N-2f Echo messages are received, the received data block is restored to a first transaction set based on an erasure code algorithm, wherein f is a common identification node fault-tolerant number of the block chain.

It should be understood that, when the leader node of the embodiments of the present specification executes the RBC protocol, the follower node is provided with the data block corresponding to the follower node only through the Rval message. In order to obtain a complete first transaction set, in this step, each follower node of the block chain also needs to forward the corresponding data block to other follower nodes through Echo messages of the RBC protocol. When any follower node receives N-2f Echo messages (indicating that enough data blocks based on the erasure coding algorithm to recover the first transaction set are collected), it attempts to recover the first intersection to achieve data synchronization of the first intersection.

It can be seen that, in the process of transmitting the first transaction set by using the erasure coding algorithm based on the RBC protocol, the follower node also consumes the network bandwidth to assist the leader node in forwarding the data block corresponding to the follower node, thereby sharing the transmission pressure of the leader node side.

S106, after the RBC protocol is executed on the first transaction set, the leader node executes a copy and fault tolerant RAFT protocol on the Mercker tree proofs of all the data blocks of the first transaction set to initiate a consensus proposal of the Mercker tree proofs of all the data blocks of the first transaction set.

It should be understood that the consensus proposal of the merkel tree proof of all data blocks of the first transaction set. The result is generated by the leader node executing the RBC protocol and belongs to the execution result of the RBC protocol. The merkel tree proof specifically refers to a root hash value of the merkel tree, and the data block can be represented by the merkel tree proof with a smaller data amount. That is, in this step, when the leader node proves that the RAFT protocol is executed on the merkel trees of all the data blocks of the first transaction set, the amount of data transmitted by the RAFT protocol can be saved.

S108, the follower node responds to the consensus proposal based on RAFT protocol to complete the consensus of the Mercker tree proofs for all data blocks of the first transaction set.

It should be understood that in the embodiments of the present description, the common knowledge object of the RAFT protocol is proved by replacing the traditional transaction set data with the merkel tree, but the common knowledge principle is not changed, so that the common knowledge can be completed by using the traditional RAFT protocol logic.

S110, after the Mercker tree proofs of all the data blocks in the first transaction set are identified, the leader node and the follower node match the transactions corresponding to the Mercker tree proofs which reach the identification from the respective first transaction sets, so as to execute block writing operation on the matched transactions.

Compared with the traditional RAFT protocol, since the consensus object is replaced by the merkel tree certificate from the transaction set data, what is determined by the RAFT protocol result is the merkel tree certificate achieving the consensus, and it is required that the leader node and the follower node re-match the corresponding transactions from the respective determined transaction sets, and then perform the block writing operation on the matched transactions (also understood as the transactions achieving the consensus).

It should be understood here that the first transaction set on the follower node side is synchronized by the leader node performing the RBC protocol, while the first transaction set on the leader node side itself is derived from the transaction pool of the target consensus node.

The method of the embodiments of the present description achieves consensus through the RBC protocol and the RAFT protocol. In the RBC protocol stage, the leader node splits a transaction set serving as proposed data into data blocks corresponding to follower nodes by using an erasure code transmission mechanism of the RBC protocol, and transmits the split data blocks to the corresponding follower nodes, and then the follower nodes forward each other so as to share the transmission of the proposed data, so that the transmission fault tolerance is realized by using smaller network bandwidth and storage space cost of the leader node. In the RAFT protocol stage, the leader node takes the Mercker tree certificate of the data block of the RBC protocol result as a consensus object to initiate a consensus proposal, so that the Mercker tree certificate achieving consensus is matched back to the corresponding transaction to complete the block writing operation.

The following describes in detail the consensus method of the examples of the present specification.

In the method according to the embodiment of the present disclosure, the common-identity node of the block chain implements a transaction common-identity uplink based on the RBC protocol + RAFT protocol. Here, the number of common nodes of the block chain is set to be N, and the fault-tolerant number of common nodes of byzantine is set to be f, where N > is 3f + 1.

The RAFT protocol divides the consensus nodes into three types, namely Leader, Follower, and Candidate:

a Leader: the method is responsible for synchronous management of the logs, processing requests from clients and keeping the relation with Follower for heartBeat (heartBeat);

follower: all the consensus nodes are in a Follower state when just started; responding to a log synchronization request of a Leader; responding to the Candidate request, and forwarding the transaction requesting to the Follower to the Leader;

candidate: and the RAFT is responsible for voting, when the RAFT is just started, a node is converted from the Follower to the Candidate to initiate voting, and after the Leader is enumerated, the node is converted from the Candidate to the Leader state.

Furthermore, the RAFT protocol divides time into tenure periods (Term) of any different length. The expiration period is indicated by consecutive numbers. The beginning of each session is an election (election) and one or more Candidates will attempt to become a Leader. If a Candidate wins the election, it will act as a Leader for the remainder of the tenure.

The corresponding consensus process is as follows:

RBC protocol stage:

the leader node selects a plurality of trades to be commonly known from the trading pool of the leader node to form a first trading set.

The leader node splits the first transaction set into N ordered data blocks in one-to-one correspondence with the consensus nodes of the blockchain according to the consensus sequence using an erasure coding algorithm. Here, each data block includes at least one transaction in the first transaction set, and corresponds to a merck tree certificate (root hash) calculated by an erasure code algorithm.

For ease of understanding, assuming that the blockchain is provided with 6 consensus nodes (the rest are follower nodes) including the leader node, and the trades in the first transaction set are 20, i.e., tx1 to tx20, the first transaction set can be split into 6 data blocks, i.e., root hash 1 to root hash 6. Correspondingly, the merkel tree certificate and transaction correspondence is as follows:

root hash 1:{tx1，tx2，tx3，tx4}

root hash 2:{tx5，tx6，tx7}

root hash 3:{tx8，tx9，tx10}

root hash 4:{tx11，tx12，tx13}

root hsh 5:{tx14，tx15，tx16}

root hash 6:{tx17，tx18，tx19，tx20}

then, the leader node Rval message sends the corresponding data block to each follower node of the block chain.

Here consensus node 1 is taken as leader node. If the consensus node 2 corresponds to the data block of which the Mercker tree proves to be the root hash 2, the Rval message sent by the consensus node 1 to the consensus node 2 carries the Mercker tree prove root hash 2; similarly, if the consensus node 3 corresponds to a data block of which the merkel tree certificate is root hash 3, the Rval message sent by the consensus node 1 to the consensus node 3 carries the merkel tree certificate root hash 3; … … the consensus node 6 corresponds to the data block of which the merkel tree certificate is root hash 6, then the Rval message sent by the consensus node 1 to the consensus node 6 carries the merkel tree certificate root hash 6.

After receiving the Rval message of the leader node, the follower node forwards the tachr tree certificate in the Rval message to other follower nodes through Echo messages.

For example, the consensus node 2 sends Echo messages carrying root hash 2 to the consensus nodes 1, 3, 4, 5, 6; the consensus node 3 sends an Echo message … … carrying the root hash 3 to the consensus nodes 1, 2, 4, 5 and 6; the consensus node 6 sends Echo messages carrying the root hash 6 to the consensus nodes 1, 2, 3, 4, 5.

After receiving N-2f Echo messages, any follower node attempts to restore the received data blocks (data blocks in Rval messages sent by the leader node and data blocks in Echo messages sent by other follower nodes) back to the first transaction set using an erasure code algorithm and reconstructs the mercker tree of the first transaction set to verify whether the reconstructed mercker tree is consistent with the received mercker tree certificate. If so, a Ready message is broadcast to the blockchain.

In addition, on the basis, if the data blocks obtained from the Echo message and the Rval message are not enough to restore the first transaction set, any follower node can also obtain the data blocks in the Rval message received by other follower nodes from other follower nodes to try to restore the first transaction set.

Then, for each consensus node, when f +1 identical Ready messages from different nodes are received, judging whether the consensus node broadcasts the Ready messages or not, and if not, broadcasting the Ready messages; when 2f +1 Ready messages from different consensus nodes are received, it means that the correct first set of trades is received, i.e. the leader node correctly synchronizes the first set of trades in its own trading pool to the follower node.

Here, the leader node locally maintains a consensus execution queue for holding the Mercker tree certificates to be known. After splitting the first transaction set into N data blocks, the leader node sequentially adds the N data blocks split into the first transaction set to a consensus execution queue of the leader node.

After the RBC protocol stage is finished, the leader node selects the Mercker tree certificate as a consensus object in sequence from the consensus execution queue to initiate a consensus proposal of the RAFT protocol. It should be appreciated that if the merkel tree proofs in the consensus execution queue exceed the maximum number of merkel tree proofs supported by one consensus proposal, the leader node may choose to initiate at least two rounds of consensus proposals to agree on merkel tree proofs in the consensus execution queue.

RAFT protocol stage:

first, the leader node initiates a consensus proposal by certifying the Mercker tree of the data blocks of the first set of deals as proposal data. The consensus process comprises the following steps:

the leader node copies the merkel tree proof of each data block of the first transaction set to the follower node for storage in a Log distribution attempt. In addition, the Log also includes a command, a corresponding term number and an Index of the Log. Additional information in these Log logs assists followers in determining Log legitimacy and subsequent data synchronization security logic.

The Log is copied to the follower node and takes effect without representing the command contained in the Log, and the copied Log needs to go through a commit (commit) process. When the Leader confirms that the Log Log is successfully copied by a plurality of consensus nodes, the instructions contained in the Log Log can be formally submitted to be effective.

When the Leader node considers that the data reliability is guaranteed (provided that the replication is completed on a majority of the nodes), the Leader then notifies other cognizant nodes (including itself) to commit (i.e., execute in) the instruction in their respective state machines. As long as the state machine transition logic of each consensus node is guaranteed to be consistent, and the executed instructions are also consistent (including in sequence), the state consistency among all RAFT nodes can be guaranteed, so that consensus is achieved.

After all the Mercker tree proofs in the consensus execution queue of the leader node are agreed, the leader node and the follower node match the transactions corresponding to the Mercker tree proofs achieving the consensus from the respective first transaction sets, so as to execute block writing operation on the matched transactions.

For convenience of understanding, assuming that the mercker trees of root hash 1 and root hash 5 prove to agree, the leader node and follower node perform a block-writing operation on the deal { tx1, tx2, tx3, tx4} corresponding to root hash 1 and the deal { tx14, tx15, tx16} corresponding to root hsh 5, that is, the deals { tx1, tx2, tx3, tx4 tx14, tx15, tx16} complete the uplink.

The above is an introduction to a round of RBC protocol + RAFT protocol. It should be understood that after the acquaintance trees of all the data blocks of the first transaction set prove that the consensus is completed, if the block chain does not replace the tenure of the RAFT protocol (i.e., the leader node is not replaced), the leader node may further continue to execute a new round of the RBC protocol on the second transaction set in the transaction pool of the leader node (the second transaction set is the transaction set in which the RBC protocol has not been executed by the leader node in the transaction pool of the leader node), and then, for the acquaintance trees of the data blocks into which the second transaction set is split, prove that the consensus proposal of the RAFT protocol is initiated to complete the uplink of the second transaction set.

In addition, on the basis, the leader node may perform data persistence on the consensus execution queue local to the leader node, and if the leader node goes down, the consensus execution queue of the leader node may be restored to a state before the restart based on the persistent data of the leader node after the restart.

The above is a description of the method of the embodiments of the present specification. It will be appreciated that appropriate modifications may be made without departing from the principles outlined herein, and such modifications are intended to be included within the scope of the embodiments herein.

Corresponding to the above consensus method shown in fig. 1, an embodiment of the present specification further provides a consensus node of a block chain.

Fig. 2 is a block diagram of a consensus node 200 according to an embodiment of the present disclosure, including:

a first RBC executing module 210, where a leader node executes a reliable broadcast transmission RBC protocol on a first transaction set in a transaction pool of the leader node, so as to split the first transaction set into N data blocks corresponding to common identification nodes of the block chain by using an erasure code algorithm, and send the corresponding data blocks to each follower node of the block chain based on a Rval message, so that the follower node executes the RBC protocol, forwards the corresponding data blocks received from the Rval message to other follower nodes by using an Echo message, and after receiving N-2f Echo messages, restores the received data blocks to the first transaction set based on the erasure code algorithm, where the data blocks into which the first transaction split set corresponds to a computed kirer tree certificate based on the erasure code algorithm, where N is the number of common identification nodes of the block chain, f is the fault tolerance number of the consensus node of the block chain;

a first RAFT execution module 220, said leader node performing a copy and fault tolerant RAFT protocol on the mercker tree proofs of all data blocks of said first transaction set after performing said RBC protocol on said first transaction set to initiate a consensus proposal for the mercker tree proofs of all data blocks of said first transaction set, such that said follower node responds to said consensus proposal based on said RAFT protocol to complete the consensus for the mercker tree proofs of all data blocks of said first transaction set;

the first writing block module 230, after the acquaintance tree certificates of all the data blocks of the first transaction set complete the consensus, matches the transaction corresponding to the acquaintance tree certificate from the first transaction set by the leader node, so as to perform a writing block operation on the matched transaction.

The consensus node in the embodiment of the present specification realizes consensus through the RBC protocol and the RAFT protocol. In the RBC protocol stage, an erasure code transmission mechanism of the RBC protocol is utilized to split a transaction set serving as proposed data into data blocks corresponding to follower nodes, the split data blocks are sent to the corresponding follower nodes, and the follower nodes forward each other so as to share the transmission of the proposed data, so that the transmission fault tolerance is realized with smaller network bandwidth and storage space overhead of the leader nodes. In the RAFT protocol stage, the leader node takes the Mercker tree certificate of the data block of the RBC protocol result as a consensus object to initiate a consensus proposal, so that the Mercker tree certificate achieving consensus is matched back to the corresponding transaction to complete the block writing operation.

Optionally, the consensus node of the embodiment of the present specification further includes:

a queue maintenance module, configured to, after the first RBC execution module 210 splits the first transaction set into N data blocks corresponding to the consensus node of the block chain using an erasure code algorithm, add the N data blocks split into the first transaction set to the consensus execution queue of the leader node in sequence; correspondingly, the first RAFT execution module 220 may select the merkel tree certificates of the data blocks of the first transaction set in order from the consensus execution queue to initiate at least one round of consensus proposition until the merkel tree certificates of all the data blocks of the first transaction set complete consensus.

Optionally, the first RBC execution module 210 and the first RAFT execution module 220 are in a serial relationship.

After the acquiescence of the merkel trees of all the data blocks of the first transaction set proves to be completed, if the block chain does not change the tenure of the RAFT protocol, the first RBC executing module 210 executes a new round of RBC protocol on a second transaction set in the transaction pool of the leader node, wherein the second transaction set refers to a transaction set in the transaction pool of the leader node on which the RBC protocol has not been executed by the leader node.

Optionally, the consensus execution queue of the leader node serves as persistent data for the leader node. If the leader node is restarted, the queue maintenance module may further restore the consensus execution queue of the leader node to a state before restarting, based on the persistent data of the leader node.

Optionally, when the RAFT protocol is executed on the merkel tree proofs of all data blocks of the first transaction set, the leader node sends the merkel tree proofs as the current round of consensus objects to other consensus nodes based on a Pre-prefix message of the RAFT protocol.

Obviously, the consensus node of the present specification embodiment may be an execution subject of the leader node in the method shown in fig. 1, and can implement the corresponding function of the leader node in the method shown in fig. 1. Since the principle is the same, the detailed description is omitted here.

Corresponding to the above consensus method shown in fig. 1, an embodiment of the present specification further provides a consensus node of a block chain. Fig. 3 is a block diagram of a consensus node 300 according to an embodiment of the present disclosure, including:

a receiving module 310, configured to receive a data block corresponding to a follower node sent by a leader node of the block chain when executing an RBC protocol, where the data block corresponding to the follower node is a reliable broadcast transmission RBC protocol executed by the leader node on a first transaction set in a transaction pool of the leader node, so as to split the first transaction set into N data blocks corresponding to common identification nodes of the block chain by using an erasure coding algorithm, and send the data block to the follower node based on a Rval message;

a second RBC executing module 320, configured to execute the RBC protocol, forward the corresponding data block received from the Rval message to other follower nodes through Echo messages, and after receiving N-2f Echo messages, reduce the received data block to the first transaction set based on an erasure code algorithm, and reduce the received data block to the first transaction set based on the erasure code algorithm, where f is a fault-tolerant number of a common identification node of the block chain;

a second RAFT execution module 330 that, after the leader node executes a copy and fault tolerant RAFT protocol on the merkel tree proofs of all data blocks of the first trading set to initiate a consensus proposal for the merkel tree proofs of all data blocks of the first trading set, responds to the consensus proposal based on the RAFT protocol to complete consensus on the merkel tree proofs of all data blocks of the first trading set;

after the acquaintance tree certificates of all the data blocks of the first transaction set are agreed, the follower node matches the transaction corresponding to the acquaintance tree certificate from the restored first transaction set, so as to perform a block writing operation on the matched transaction.

The consensus node in the embodiment of the present specification realizes consensus through the RBC protocol and the RAFT protocol. In the RBC protocol stage, the leader node splits a transaction set serving as proposed data into data blocks corresponding to follower nodes by using an erasure code transmission mechanism of the RBC protocol, and transmits the split data blocks to the corresponding follower nodes, and then the follower nodes forward each other so as to share the transmission of the proposed data, so that the transmission fault tolerance is realized by using smaller network bandwidth and storage space cost of the leader node. In the RAFT protocol stage, the leader node takes the Mercker tree certificate of the data block of the RBC protocol result as a consensus object to initiate a consensus proposal, so that the Mercker tree certificate achieving consensus is matched back to the corresponding transaction to complete the block writing operation.

Obviously, the consensus node of the present specification may serve as an execution subject of the follower node in the method shown in fig. 1, and thus can implement the corresponding function of the follower node in the method shown in fig. 1. Since the principle is the same, the detailed description is omitted here.

Fig. 4 is a schematic structural diagram of an electronic device according to an embodiment of the present disclosure. Referring to fig. 4, at a hardware level, the electronic device includes a processor, and optionally further includes an internal bus, a network interface, and a memory. The Memory may include a Memory, such as a Random-Access Memory (RAM), and may further include a non-volatile Memory, such as at least 1 disk Memory. Of course, the electronic device may also include hardware required for other services.

The processor, the network interface, and the memory may be connected to each other via an internal bus, which may be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, an EISA (Extended Industry Standard Architecture) bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one double-headed arrow is shown in FIG. 4, but that does not indicate only one bus or one type of bus.

And the memory is used for storing programs. In particular, the program may include program code comprising computer operating instructions. The memory may include both memory and non-volatile storage and provides instructions and data to the processor.

The processor reads a corresponding computer program from the nonvolatile memory into the memory and then runs the computer program to form a consensus device of the block chain on a logic level, wherein the consensus device can be used as a leader node of the block chain or belongs to a component in a consensus main section. The processor is used for executing the program stored in the memory and is specifically used for executing the following operations:

Or the processor reads a corresponding computer program from the nonvolatile memory into the memory and then runs the computer program to form a consensus device of the block chain on a logic level, wherein the consensus device can be used as a follower node of the block chain or belongs to a component in a consensus backup node. The processor is used for executing the program stored in the memory and is specifically used for executing the following operations:

receiving a data block corresponding to a follower node sent by a leader node of the block chain when executing an RBC protocol, wherein the data block corresponding to the follower node is a reliable broadcast transmission RBC protocol executed by the leader node on a first transaction set in a transaction pool of the leader node, so as to split the first transaction set into N data blocks corresponding to common identification nodes of the block chain by using an erasure coding algorithm, and sending the data block to the follower node based on a Rval message.

Executing the RBC protocol, forwarding the corresponding data block received from the Rval message to other follower nodes through Echo messages, broadcasting Ready messages to the blockchain after receiving N-f Echo messages, and restoring the received data block into the first transaction set based on the erasure code algorithm after receiving 2f +1 Ready messages, wherein f is the fault tolerance number of the common identification node of the blockchain.

After the leader node performs a copy and fault tolerant RAFT protocol on the Mercker tree proofs of all data blocks of the first transaction set to initiate a consensus proposal for the Mercker tree proofs of all data blocks of the first transaction set, responding to the consensus proposal based on the RAFT protocol to complete the consensus for the Mercker tree proofs of all data blocks of the first transaction set.

The consensus method as disclosed above in the embodiment of fig. 1 of the present specification may be applied to or implemented by a processor. The processor may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware in a processor or instructions in the form of software. The Processor may be a general-purpose Processor, including a Central Processing Unit (CPU), a Network Processor (NP), and the like; but also Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components. The various methods, steps and logic blocks disclosed in the embodiments of the present specification may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with the embodiments of the present specification may be embodied directly in a hardware decoding processor, or in a combination of hardware and software modules in the decoding processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium is located in a memory, and a processor reads information in the memory and completes the steps of the method in combination with hardware of the processor.

It should be understood that the electronic device of the embodiments of the present specification may implement the functions of the embodiment shown in fig. 1 of the leader node or the follower node, and details are not described herein.

Of course, besides the software implementation, the electronic device in this specification does not exclude other implementations, such as logic devices or a combination of software and hardware, and the like, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.

Furthermore, the present specification embodiments also propose a computer-readable storage medium storing one or more programs, the one or more programs including instructions.

When executed by a portable electronic device including multiple application programs, the instructions enable the portable electronic device to perform the method of the embodiment shown in fig. 1, and are specifically configured to perform the following steps corresponding to the leader node:

a reliable broadcast transmission RBC protocol is performed on a first set of deals in the leader node's deal pool, to split the first set of transactions into N data blocks corresponding to common nodes of the chain of blocks using an erasure coding algorithm, and sends corresponding data blocks to each follower node of the block chain based on the Rval message, so that the follower node executes the RBC protocol, the corresponding data block received from the Rval message is forwarded to other follower nodes by Echo message, and after receiving N-2f Echo messages, restoring the received data blocks to the first transaction set based on the erasure coding algorithm, the data blocks divided by the first transaction set correspond to a mercker tree certificate calculated based on the erasure code algorithm, N is the number of common identification nodes of the block chain, and f is the fault tolerance number of the common identification nodes of the block chain.

After the RBC protocol is executed for the first transaction set, performing a replication and fault tolerant RAFT protocol on the merkel tree proofs of all data blocks of the first transaction set to initiate a consensus proposal for the merkel tree proofs of all data blocks of the first transaction set, such that the follower node responds to the consensus proposal based on the RAFT protocol to complete the consensus for the merkel tree proofs of all data blocks of the first transaction set.

Alternatively, the above instructions, when executed by a portable electronic device comprising a plurality of application programs, can cause the portable electronic device to perform the method of the embodiment shown in fig. 1, and specifically to perform the following steps corresponding to the follower node:

It should be understood that the above-mentioned instructions, when executed by a portable electronic device comprising a plurality of application programs, enable the leader node or follower node described above to implement the functions of the embodiment shown in fig. 1, and will not be described in detail herein.

As will be appreciated by one skilled in the art, embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, the description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

The above description is only an example of the present specification, and is not intended to limit the present specification. Various modifications and alterations to this description will become apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present specification should be included in the scope of the claims of the present specification. Moreover, all other embodiments obtained by a person skilled in the art without making any inventive step shall fall within the scope of protection of this document.

Claims

1. A method for block chain consensus, comprising:

2. The method of claim 1, further comprising:

after the leader node splits the first transaction set into N data blocks corresponding to the consensus nodes of the block chain by using an erasure code algorithm, sequentially adding the N data blocks split into the first transaction set into N data blocks into a consensus execution queue of the leader node;

the leader node, after executing the RBC protocol on the first transaction set, executing a copy and fault tolerant RAFT protocol on the mercker tree proofs of all data blocks of the first transaction set to initiate a consensus proposal for the mercker tree proofs of all data blocks of the first transaction set, comprising:

the leader node selects the merkel tree proofs of the data blocks of the first transaction set in order from the consensus execution queue of the leader node to initiate at least one round of consensus proposition until the merkel tree proofs of all the data blocks of the first transaction set complete consensus.

3. The method of claim 1, wherein the first and second light sources are selected from the group consisting of,

the leader node serially executes the RBC protocol and the RAFT protocol, the method further comprising:

after the acquiescence of all the data blocks of the first transaction set proves to be completed with consensus, if the block chain does not change the tenure of the RAFT protocol, the leader node executes the RBC protocol on a second transaction set in the transaction pool of the leader node, wherein the second transaction set refers to a transaction set in the transaction pool of the leader node on which the RBC protocol has not been executed by the leader node.

4. The method of claim 2, wherein the first and second light sources are selected from the group consisting of,

the consensus execution queue of the leader node as persisted data for the leader node, the method further comprising:

and if the leader node is restarted, based on the persistent data of the leader node, restoring the consensus execution queue of the leader node to the state before restarting.

5. The method of claim 2, wherein the first and second light sources are selected from the group consisting of,

the leader node, when executing the RAFT protocol on the Mercker tree proofs of all data blocks of the first transaction set, sends the Mercker tree proofs serving as the current round of consensus objects to other consensus nodes based on the Log logs of the RAFT protocol.

6. A method for block chain consensus, comprising:

7. A method for block chain consensus, comprising:

8. A consensus node of a blockchain, comprising:

9. An electronic device includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being executed by the processor to:

10. A computer-readable storage medium having a computer program stored thereon, which when executed by a processor, performs the steps of:

11. A consensus node of a blockchain, comprising:

12. An electronic device includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being executed by the processor to:

13. A computer-readable storage medium having a computer program stored thereon, which when executed by a processor, performs the steps of: