A consensus method, system, node and electronic device for blockchain

Abstract

The embodiments of this specification provide a consensus method, system, node and electronic device of a blockchain. The method includes: when the consensus master node initiates the current round of consensus, the consensus master node splits the proposed data of the current round of consensus into data blocks corresponding to the consensus backup nodes based on the erasure code algorithm, and the blockchain adopts the TendermintBFT Byzantine protocol for consensus. In the Propose phase, the consensus master node sends the split data blocks to the corresponding consensus backup nodes through the Propose message. The consensus backup node that receives the data block performs erasure code verification on the data block provided by the master node, so that in the Pre-vote phase, the data block with successful erasure code verification is broadcast to other consensus backup nodes through the pre-vote message. Based on the erasure code algorithm, the consensus backup node restores the data blocks in the pre-vote messages obtained from at least N-2f back to the proposed data, so that in the Pre-commit phase, the consensus logic is executed on the restored proposed data to complete the consensus, where N is the number of consensus nodes in the blockchain, f is the fault tolerance number of the consensus node, and N is greater than or equal to 3f+1.

Description

Technical Field

[0001] This document belongs to the field of blockchain technology, and in particular to a blockchain consensus method, system, node and electronic device. Background Art

[0002] At present, many blockchain systems use the Byzantine Fault Tolerant (BFT) algorithm to achieve consensus. TendermintBFT is one of the commonly used Byzantine Fault Tolerant protocols. In the TendermintBFT protocol, before executing the consensus, the consensus master node needs to send the proposal data (transaction set) to the consensus backup node. In order to ensure that the transmission of the proposal data is fault-tolerant, the consensus master node needs to send redundant proposal data. However, redundant proposal data will cause the consensus master node to occupy too much network bandwidth and storage space during the consensus stage.

[0003] To this end, there is an urgent need for an optimization solution for the TendermintBFT protocol that can effectively reduce the network bandwidth and storage space overhead during the consensus process. Summary of the invention

[0004] The purpose of the embodiments of this specification is to provide a blockchain consensus method, system, node and electronic device, which can reduce the network bandwidth and storage space overhead in the TendermintBFT protocol consensus process.

[0005] In order to achieve the above purpose, the embodiments of this specification are implemented as follows:

[0006] First, a blockchain consensus method is provided, including:

[0007] When the consensus round is initiated, the consensus master node of the blockchain splits the proposed data of the consensus round into data blocks corresponding to the consensus backup nodes of the blockchain based on the erasure code algorithm, wherein the blockchain adopts the TendermintBFT Byzantine protocol for consensus;

[0008] In the Propose phase of the TendermintBFT protocol, the consensus master node sends the data blocks split from the proposed data to the corresponding consensus backup nodes in the blockchain through a Propose message;

[0009] The consensus backup node that receives the data block performs erasure code verification on the data block provided by the consensus master node, so as to broadcast the data block with successful erasure code verification to other consensus backup nodes through pre-vote messages in the Pre-vote phase of the TendermintBFT protocol;

[0010] Based on the erasure code algorithm, the consensus backup node restores the data blocks obtained from at least N-2f pre-vote messages back to the proposed data, so as to execute the consensus logic of the TendermintBFT protocol on the restored proposed data in the Pre-commit phase of the TendermintBFT protocol to complete this round of consensus, where N is the number of consensus nodes of the blockchain, f is the fault tolerance number of consensus nodes set by the TendermintBFT protocol, and N is greater than or equal to 3f+1.

[0011] In a second aspect, a blockchain system is provided, including: a consensus master node and a consensus backup node; wherein:

[0012] When initiating this round of consensus, the consensus master node splits the proposed data of this round of consensus into data blocks corresponding to the consensus backup nodes of the blockchain based on the erasure code algorithm, wherein the blockchain adopts the TendermintBFT Byzantine protocol for consensus;

[0013] In the Propose phase of the TendermintBFT protocol, the consensus master node sends the data blocks split from the proposed data to the corresponding consensus backup nodes in the blockchain through a Propose message;

[0014] The consensus backup node that receives the data block performs erasure code verification on the data block provided by the consensus master node, so as to broadcast the data block with successful erasure code verification to other consensus backup nodes through pre-vote messages in the Pre-vote phase of the TendermintBFT protocol;

[0015] Based on the erasure code algorithm, the consensus backup node restores the data blocks obtained in at least N-2f pre-vote messages back to the proposed data, so as to execute the consensus logic of the TendermintBFT protocol on the restored proposed data in the Pre-commit phase of the TendermintBFT protocol to complete this round of consensus, where N is the number of consensus nodes of the blockchain, f is the fault tolerance number of consensus nodes set by the TendermintBFT protocol, and N is greater than or equal to 3f+1.

[0016] In a third aspect, a blockchain node is provided, including:

[0017] The erasure code module, when the current round of consensus is initiated, if the blockchain node to which it belongs is the consensus master node, splits the proposed data of this round of consensus into data blocks corresponding to the consensus backup nodes of the blockchain based on the erasure code algorithm, wherein the blockchain adopts the TendermintBFT Byzantine protocol for consensus;

[0018] The sending module, if the blockchain node to which it belongs is a consensus master node, in the Propose phase of the TendermintBFT protocol, sends the data blocks split from the proposed data to the corresponding consensus backup node in the blockchain through a Propose message;

[0019] The verification module performs erasure code verification on the data blocks provided by the consensus master node if the blockchain node to which it belongs is a consensus backup node, so as to broadcast the data blocks with successful erasure code verification to other consensus backup nodes through pre-vote messages in the Pre-vote phase of the TendermintBFT protocol;

[0020] The restoration module, if the blockchain node to which it belongs is a consensus backup node, will restore the data blocks in at least N-2f pre-vote messages back to the proposed data based on the erasure code algorithm, so as to execute the consensus logic of the TendermintBFT protocol on the restored proposed data in the Pre-commit phase of the TendermintBFT protocol to complete this round of consensus, where N is the number of consensus nodes of the blockchain, f is the fault tolerance number of consensus nodes set by the TendermintBFT protocol, and N is greater than or equal to 3f+1.

[0021] In a fourth aspect, an electronic device is provided, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is executed by the processor:

[0022] When this round of consensus is initiated, if it is the consensus master node, the proposed data of this round of consensus is split into data blocks corresponding to the consensus backup nodes of the blockchain based on the erasure code algorithm, wherein the blockchain adopts the TendermintBFT Byzantine protocol for consensus;

[0023] If it is used as a consensus backup node, in the Propose phase of the TendermintBFT protocol, the data blocks split from the proposed data are sent to the corresponding consensus backup nodes in the blockchain through Propose messages;

[0024] If it is a consensus backup node, it performs erasure code verification on the data blocks provided by the consensus master node, so that in the Pre-vote phase of the TendermintBFT protocol, the data blocks that have successfully passed the erasure code verification are broadcast to other consensus backup nodes through pre-vote messages;

[0025] If it acts as a consensus backup node, based on the erasure code algorithm, it will restore the data blocks in at least N-2f pre-vote messages back to the proposed data, so as to execute the consensus logic of the TendermintBFT protocol on the restored proposed data in the Pre-commit phase of the TendermintBFT protocol to complete this round of consensus, where N is the number of consensus nodes of the blockchain, f is the fault tolerance number of consensus nodes set by the TendermintBFT protocol, and N is greater than or equal to 3f+1.

[0026] In a fifth aspect, a computer readable storage medium is provided, wherein a computer program is stored on the computer readable storage medium, and when the computer program is executed by a processor, the following steps are implemented:

[0027] When this round of consensus is initiated, if it is the consensus master node, the proposed data of this round of consensus is split into data blocks corresponding to the consensus backup nodes of the blockchain based on the erasure code algorithm, wherein the blockchain adopts the TendermintBFT Byzantine protocol for consensus;

[0028] If it is used as a consensus backup node, in the Propose phase of the TendermintBFT protocol, the data blocks split from the proposed data are sent to the corresponding consensus backup nodes in the blockchain through Propose messages;

[0029] If it is a consensus backup node, it performs erasure code verification on the data blocks provided by the consensus master node, so that in the Pre-vote phase of the TendermintBFT protocol, the data blocks that have successfully passed the erasure code verification are broadcast to other consensus backup nodes through pre-vote messages;

[0030] If it acts as a consensus backup node, based on the erasure code algorithm, it will restore the data blocks in at least N-2f pre-vote messages back to the proposed data, so as to execute the consensus logic of the TendermintBFT protocol on the restored proposed data in the Pre-commit phase of the TendermintBFT protocol to complete this round of consensus, where N is the number of consensus nodes of the blockchain, f is the fault tolerance number of consensus nodes set by the TendermintBFT protocol, and N is greater than or equal to 3f+1.

[0031] Based on the scheme of the embodiment of this specification, when executing the consensus of TendermintBFT, the consensus master node of the blockchain uses the erasure code algorithm to split the proposed data into data blocks corresponding to the consensus backup nodes, and sends the split data blocks to the corresponding consensus backup nodes. Afterwards, the consensus backup node performs erasure code verification on the data blocks provided by the consensus master node based on the erasure code technology, and forwards the data blocks to other consensus backup nodes after the verification is successful, so that after obtaining a certain number of data blocks, each consensus backup node of the blockchain can restore the obtained data blocks back to the proposed data through the erasure code algorithm to execute the consensus logic on the proposed data. In the whole scheme, the consensus master node only needs to send the corresponding data blocks to the consensus backup node, and the consensus backup nodes forward their respective data blocks to each other, thereby amortizing the transmission of the proposed data, and realizing the fault tolerance of the transmission of the proposed data with a smaller network bandwidth and storage space overhead. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the embodiments of this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0033] Figure 1 A flowchart of a consensus method for a blockchain provided in an embodiment of this specification.

[0034] Figure 2 A schematic diagram of the structure of the blockchain system provided in the embodiments of this specification.

[0035] Figure 3 A schematic diagram of the structure of a blockchain node provided in an embodiment of this specification.

[0036] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this specification. DETAILED DESCRIPTION

[0037] 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 embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this specification.

[0038] As mentioned above, under the current consensus mechanism of the TendermintBFT protocol, the consensus master node needs to send redundant proposal data to each consensus backup node so that the consensus backup node can execute consensus logic on the proposal data. Redundant proposal data will occupy too much network bandwidth and storage space of the consensus master node. To this end, this document aims to provide an optimization solution for the TendermintBFT protocol, which can effectively reduce the network bandwidth and storage space occupied by the consensus master node to transmit proposal data during the consensus process.

[0039] Figure 1 It is a flow chart of the consensus method of the blockchain embodiment of this specification. Figure 1 The method shown can be performed by the corresponding device below, including the following steps:

[0040] S102, when the consensus master node of the blockchain initiates this round of consensus, the proposed data of this round of consensus is split into data blocks corresponding to the consensus backup nodes of the blockchain based on the erasure code algorithm, wherein the blockchain adopts the TendermintBFT Byzantine protocol for consensus.

[0041] Erasure coding (EC) is a method of data fault tolerance protection that divides data into fragments, expands and encodes redundant data blocks, and stores them in different locations, such as disks, storage nodes, or other geographical locations. From a data function perspective, the protection provided by erasure coding can be expressed as follows: n = k + m. The variable "k" represents the value of the original data or symbol. The variable "m" represents the value of the additional or redundant symbols added to provide protection after the failure. The variable "n" represents the total value of the symbols created after the erasure coding process. For example, in an EC 10 / 16 configuration, 6 additional symbols (variable m) are added to the 10 original symbols (variable k). These 16 data fragments (variable n) can be spread across 16 drives, nodes, or geographical locations, and the original file can be reconstructed from the 10 verified fragments. In other words, even if 6 drives, nodes, or geographical locations are lost or unavailable, the original file can still be recovered. It can be seen that erasure coding only requires a small amount of redundancy to achieve data recovery.

[0042] In the embodiment of the present specification, erasure coding technology is used to split the proposed data to be consensus into data blocks corresponding to the consensus backup nodes, which are subsequently saved by the consensus backup nodes.

[0043] S104, in the Propose phase of the TendermintBFT protocol, the consensus master node sends the data blocks split into by the proposed data to the corresponding consensus backup nodes in the blockchain through the Propose message.

[0044] In the Propose phase of the traditional TendermintBFT protocol, the consensus master node sends the full amount of redundant proposal data to each consensus backup node through the Propose message. However, this step uses the erasure coding algorithm to send only the corresponding data blocks to the consensus backup node, which can effectively reduce the transmission overhead of the consensus master node.

[0045] It should be noted here that the proposed data can be split into multiple data blocks that correspond to the consensus backup nodes of the blockchain one by one; or, the number of the proposed data is less than the number of consensus backup nodes of the blockchain, and one consensus backup node corresponds to at most one data block. Therefore, in this step, the consensus master node can but does not necessarily send data blocks to each consensus backup node of the blockchain, which depends on the algorithm setting of the erasure code.

[0046] S106, the consensus backup node that receives the data block performs erasure code verification on the data block provided by the consensus master node, so that in the Pre-vote phase of the TendermintBFT protocol, the data block that has successfully passed the erasure code verification is broadcast to other consensus backup nodes through pre-vote messages.

[0047] Specifically, the data blocks into which the proposed data is split correspond to the Merkle tree path information obtained based on the erasure code algorithm. The consensus master node also sends the Merkle tree path information matching the data blocks into which the proposed data is split to the corresponding consensus backup node in the blockchain through the Propose message. In this step, the consensus backup node that receives the data block reconstructs the Merkle tree for the data block provided by the consensus master node based on the erasure code algorithm. If the Merkle tree path information provided by the consensus node matches the reconstructed Merkle tree, the erasure code verification succeeds, otherwise the erasure code verification fails.

[0048] In addition, as a preferred solution, if the proposed data of this round of consensus has been initiated in the previous round of consensus, it means that the consensus backup node has cached the proposed data when executing the previous round of consensus. At this time, this step can directly perform a faster matching check on the data block provided by the consensus master node based on the cached proposed data to replace the erasure code check. If the proposed data of this round of consensus has not been initiated in the previous round of consensus, the consensus backup node that receives the data block will perform an erasure code check on the data block provided by the consensus master node.

[0049] S108, based on the erasure coding algorithm, the consensus backup node restores the data blocks obtained from at least N-2f pre-vote messages back to the proposed data, so as to execute the consensus logic of the TendermintBFT protocol on the restored proposed data in the Pre-commit phase of the TendermintBFT protocol to complete this round of consensus, where N is the number of consensus nodes in the blockchain, f is the fault tolerance number of consensus nodes set by the TendermintBFT protocol, and N is greater than or equal to 3f+1.

[0050] Among them, N-2f is the minimum number of data blocks required to restore the proposed data.

[0051] Specifically, in this step, if the consensus backup node restores the proposed data based on the erasure coding algorithm, then in the Pre-vote stage, a Pre-commit message is broadcast to other consensus nodes of the blockchain; wherein, when this round of consensus generates Nf Pre-commit messages, the proposed data reaches a consensus.

[0052] based on Figure 1 From the consensus method shown, it can be known that: in the scheme of the embodiment of this specification, when the consensus master node of the blockchain executes the consensus of TendermintBFT, it uses the erasure code algorithm to split the proposed data into data blocks corresponding to the consensus backup nodes, and sends the split data blocks to the corresponding consensus backup nodes. Afterwards, the consensus backup node performs erasure code verification on the data blocks provided by the consensus master node based on the erasure code technology, and forwards the data blocks to other consensus backup nodes after the verification is successful, so that after each consensus backup node of the blockchain obtains a certain number of data blocks, it can restore the obtained data blocks back to the proposed data through the erasure code algorithm to execute the consensus logic on the proposed data. In the whole scheme, the consensus master node only needs to send the corresponding data blocks to the consensus backup node, and the consensus backup nodes forward their respective data blocks to each other, thereby amortizing the transmission of the proposed data, and realizing the fault tolerance of the transmission of the proposed data with a smaller network bandwidth and storage space overhead.

[0053] The consensus method of the embodiment of this specification is introduced in detail below.

[0054] In the method of the embodiment of this specification, the blockchain performs consensus based on the TendermintBFT protocol. Assume that the number of consensus nodes in the blockchain is N, the number of Byzantine consensus node fault tolerance is f, and N>=3f+1. The corresponding consensus process is as follows:

[0055] The proposing node in the blockchain initializes the consensus height hp and other parameters based on the current consensus block height. It initiates this round of consensus for the current consensus height. The consensus includes the following stages:

[0056] Propose phase:

[0057] Each consensus node determines whether to serve as the consensus master node for this round of consensus based on the information consensus height hp and consensus round roundp initiated by this round of consensus.

[0058] If it is the consensus master node, it obtains the proposed data (first check whether there is cached data in the previous round, if so, use the cached data; if not, obtain new proposed data), then perform (N-2f, N) erasure coding on the proposed data, and obtain the data block corresponding to the consensus backup node and the Merkle tree path information of the data block (that is, the root hash value calculated by the erasure coding); then in the Propose phase, through the Propose message<Propose,hp,roundp,r,bi,si,-1> The data blocks split into by the proposed data are sent to the corresponding consensus backup nodes in the blockchain. Among them, i represents the i-th consensus backup node, si is the data block corresponding to the i-th consensus backup node, and bi is the Merkle tree merkle path information for the i-th consensus backup node.

[0059] If it is a consensus backup node, it will wait to collect Propose message data and when it receives the Propose message sent by the consensus master node,<Propose,hp,roundp,r,bi,si,-1> When a message is sent, the information in the Propose message is verified. It should be understood that the verification of the information in the Propose message includes: performing erasure code verification based on si and bi.

[0060] Pre-vote stage:

[0061] If the Propose message passes verification, the pre-vote message is broadcast to other consensus backup nodes.<Pre-vote,hp,roundp,r,bi,si> If the Propose message fails verification, the pre-vote nil message is broadcast to other consensus backup nodes.<Pre-vote,hp,roundp,nil,nil,nil> Message, here pre-vote nil message is used to vote for empty blocks.

[0062] Among them, when any consensus backup node receives NF valid Pre-vote messages: use at least si in N-2f Pre-vote messages to calculate the erasure code and restore the proposed data.

[0063] Pre-commit stage:

[0064] If any consensus node obtains valid proposal data, it will broadcast the Pre-commit message to other consensus nodes.<Precommit,hp,roundp,r> Otherwise, broadcast the Pre-commit nil message. The reason why the consensus backup node broadcasts the Pre-commit nil message may be that the consensus backup node has not collected NF Pre-vote messages, or the consensus backup node has collected NF Pre-vote messages but has not restored the valid proposal data through erasure code calculation.

[0065] Among them, when this round of consensus generates Nf Pre-commit messages, the proposed data reaches a consensus that has been passed. When this round of consensus generates f Pre-commit nil messages, the proposed data directly determines that the consensus has not been passed.

[0066] In summary, the method of the embodiment of this specification integrates data fault-tolerant transmission based on erasure codes into the TendermintBFT protocol. Compared with the traditional TendermintBFT protocol, it does not add additional signaling overhead, but significantly improves the transmission efficiency of the proposed data. For the TendermintBFT protocol consensus, the consensus efficiency is improved.

[0067] The above is an introduction to the method of the embodiment of this specification. It should be understood that appropriate changes can be made without departing from the above principles, and these changes should also be regarded as the protection scope of the embodiment of this specification.

[0068] With the above Figure 1 Corresponding to the consensus method shown, the embodiment of this specification also provides a blockchain system. Figure 2 2 is a structural diagram of a blockchain system 200 according to an embodiment of the present specification, including: a consensus master node 210 and multiple consensus backup nodes 220. Among them:

[0069] When the current round of consensus is initiated, the consensus master node 210 splits the proposed data of the current round of consensus into data blocks corresponding to the consensus backup nodes 220 of the blockchain based on the erasure code algorithm, wherein the blockchain adopts the TendermintBFT Byzantine protocol for consensus;

[0070] The consensus master node 210 sends the data blocks split from the proposed data to the corresponding consensus backup node 220 in the blockchain through a Propose message during the Propose phase of the TendermintBFT protocol;

[0071] The consensus backup node 220 that receives the data block performs erasure code verification on the data block provided by the consensus master node 210, so as to broadcast the data block with successful erasure code verification to other consensus backup nodes 220 through a pre-vote message in the Pre-vote phase of the TendermintBFT protocol;

[0072] Based on the erasure code algorithm, the consensus backup node 220 restores the data blocks obtained in at least N-2f pre-vote messages back to the proposed data, so as to execute the consensus logic of the TendermintBFT protocol on the restored proposed data in the Pre-commit phase of the TendermintBFT protocol to complete this round of consensus, where N is the number of consensus nodes of the blockchain, f is the fault tolerance number of consensus nodes set by the TendermintBFT protocol, and N is greater than or equal to 3f+1.

[0073] In the blockchain system of this embodiment, when executing the consensus of TendermintBFT, the consensus master node 210 uses the erasure code algorithm to split the proposed data into data blocks corresponding to the consensus backup node 220, and sends the split data blocks to the corresponding consensus backup node 220. Afterwards, the consensus backup node 220 performs erasure code verification on the data blocks provided by the consensus master node 210 based on the erasure code technology, and forwards the data blocks to other consensus backup nodes 220 after the verification is successful, so that after obtaining a certain number of data blocks, each consensus backup node 220 of the blockchain can restore the obtained data blocks back to the proposed data through the erasure code algorithm to execute the consensus logic on the proposed data. In the whole scheme, the consensus master node 210 only needs to send the corresponding data blocks to the consensus backup node 220, and the consensus backup nodes 220 forward their respective data blocks to each other, thereby amortizing the transmission of the proposed data, and realizing the fault tolerance of the transmission of the proposed data with a smaller network bandwidth and storage space overhead.

[0074] Optionally, if the erasure code check fails for the consensus backup node 220 that receives the data block, a pre-vote nil message is broadcast to other consensus nodes in the Pre-vote phase of the TendermintBFT protocol, and the pre-vote nil message is used to vote for an empty block.

[0075] Optionally, in the Pre-vote phase of the TendermintBFT protocol, the consensus backup node 220 restores the data blocks in the obtained pre-vote message back to the proposed data based on the erasure coding algorithm, including: after the consensus backup node 220 obtains at least Nf Prevote messages including those provided by itself, the consensus backup node 220 restores the data blocks in the obtained Prevote message to the proposed data based on the erasure coding algorithm.

[0076] Optionally, the consensus backup node 220 executes the consensus logic of the TendermintBFT protocol on the restored proposal data in the Pre-vote phase of the TendermintBFT protocol, including: if the consensus backup node 220 restores the proposal data based on the erasure code algorithm, then in the Pre-vote phase of the TendermintBFT protocol, broadcasting a Pre-commit message to other consensus nodes of the blockchain; wherein, when this round of consensus generates Nf Pre-commit messages, the proposal data reaches a consensus of approval.

[0077] Optionally, if the consensus backup node 220 fails to restore the proposed data, a Pre-commit nil message is broadcast to other consensus nodes of the blockchain during the Pre-vote phase of the TendermintBFT protocol; wherein, when f Pre-commit nil messages are generated in this round of consensus, the proposed data directly determines that a consensus has not been reached.

[0078] Optionally, the data blocks into which the proposed data is split correspond to Merkle tree path information obtained based on the erasure code algorithm, and the consensus master node 210 also sends the Merkle tree path information matching the data blocks into which the proposed data is split to the corresponding consensus backup node 220 in the blockchain through a Propose message; the consensus backup node 220 that receives the data block performs an erasure code check on the data block provided by the consensus master node 210, including: the consensus backup node 220 that receives the data block performs a Merkle tree reconstruction on the data block provided by the consensus master node 210 based on the erasure code algorithm; if the Merkle tree path information provided by the consensus node matches the reconstructed Merkle tree, the erasure code check succeeds, otherwise the erasure code check fails.

[0079] Optionally, the consensus backup node 220 that receives the data block performs erasure code verification on the data block provided by the consensus master node 210, including: if the proposed data was not initiated in the previous round of consensus, the consensus backup node 220 that receives the data block performs erasure code verification on the data block provided by the consensus master node 210; otherwise, directly using the proposed data cached in the previous round of consensus to perform a matching verification on the data block provided by the consensus master node 210, instead of performing an erasure code verification.

[0080] Obviously, the blockchain system of the embodiment of this specification can be used as the above Figure 1 The execution body of the consensus method shown in Figure 1 The functions realized are as follows. Since the principles are the same, they will not be described in detail in this article.

[0081] With the above Figure 1 Corresponding to the consensus method shown, the embodiment of this specification also provides a blockchain node. Figure 3 It is a structural diagram of a blockchain node 300 according to an embodiment of this specification, including:

[0082] The erasure code module 310, when the current round of consensus is initiated, if the blockchain node to which it belongs is the consensus master node, splits the proposed data of the current round of consensus into data blocks corresponding to the consensus backup nodes of the blockchain based on the erasure code algorithm, wherein the blockchain adopts the TendermintBFT Byzantine protocol for consensus;

[0083] The sending module 320, if the blockchain node is a consensus master node, sends the data blocks split from the proposed data to the corresponding consensus backup node in the blockchain through a Propose message in the Propose phase of the TendermintBFT protocol;

[0084] The verification module 330 performs erasure code verification on the data block provided by the consensus master node if the blockchain node to which it belongs is a consensus backup node, so as to broadcast the data block with successful erasure code verification to other consensus backup nodes through pre-vote messages in the Pre-vote phase of the TendermintBFT protocol;

[0085] The restoration module 340, if the blockchain node to which it belongs is a consensus backup node, will restore the data blocks in at least N-2f pre-vote messages back to the proposed data based on the erasure code algorithm, so as to execute the consensus logic of the TendermintBFT protocol on the restored proposed data in the Pre-commit phase of the TendermintBFT protocol to complete this round of consensus, where N is the number of consensus nodes of the blockchain, f is the fault tolerance number of the consensus nodes set by the TendermintBFT protocol, and N is greater than or equal to 3f+1.

[0086] Obviously, the blockchain node of the embodiment of this specification can be Figure 1 The consensus master node or consensus backup node in the consensus method shown, so that the consensus method can be implemented in Figure 1 The functions realized are as follows. Since the principles are the same, they will not be described in detail in this article.

[0087] Figure 4 This is a schematic diagram of the structure of an electronic device according to an embodiment of this specification. Figure 4 At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and a memory. The memory may include a memory, such as a high-speed random access memory (RAM), and may also include a non-volatile memory (non-volatile memory), such as at least one disk storage. Of course, the electronic device may also include hardware required for other services.

[0088] The processor, network interface and memory can be interconnected through an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 4 Only one bidirectional arrow is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0089] The memory is used to store the program. Specifically, the program may include a program code, and the program code includes a computer operation instruction. The memory may include a memory and a non-volatile memory, and provides instructions and data to the processor.

[0090] The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it, forming a consensus device at the logical level. The consensus device can be the consensus master node or consensus backup node of the above-mentioned blockchain system, or a component of the consensus master node or consensus backup node of the above-mentioned blockchain system. The processor executes the program stored in the memory and is specifically used to perform the following operations:

[0091] When this round of consensus is initiated, if it is the consensus master node, the proposed data of this round of consensus is split into data blocks corresponding to the consensus backup nodes of the blockchain based on the erasure code algorithm, wherein the blockchain adopts the TendermintBFT Byzantine protocol for consensus;

[0092] If it is used as a consensus backup node, in the Propose phase of the TendermintBFT protocol, the data blocks split from the proposed data are sent to the corresponding consensus backup nodes in the blockchain through Propose messages;

[0093] If it is a consensus backup node, it performs erasure code verification on the data blocks provided by the consensus master node, so that in the Pre-vote phase of the TendermintBFT protocol, the data blocks that have successfully passed the erasure code verification are broadcast to other consensus backup nodes through pre-vote messages;

[0094] If it acts as a consensus backup node, based on the erasure code algorithm, it will restore the data blocks in at least N-2f pre-vote messages back to the proposed data, so as to execute the consensus logic of the TendermintBFT protocol on the restored proposed data in the Pre-commit phase of the TendermintBFT protocol to complete this round of consensus, where N is the number of consensus nodes of the blockchain, f is the fault tolerance number of consensus nodes set by the TendermintBFT protocol, and N is greater than or equal to 3f+1.

[0095] The above is as in this manual Figure 1The consensus method disclosed in the illustrated embodiment can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in the processor or instructions in the form of software. The above processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of this specification can be implemented or executed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in the embodiments of this specification can be directly embodied as a hardware decoding processor for execution, or can be executed by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium mature in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

[0096] It should be understood that the electronic device of the embodiment of this specification can implement the above consensus method in Figure 1 The functions of the embodiments shown in the figure are the same and will not be described in detail herein.

[0097] Of course, in addition to software implementation, the electronic device of this specification does not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc., that is to say, the executor of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0098] In addition, the embodiments of the present specification also provide a computer-readable storage medium, which stores one or more programs, wherein the one or more programs include instructions, which, when executed by a portable electronic device including a plurality of application programs, enable the portable electronic device to execute Figure 1 The method of the embodiment shown is specifically used to perform the following method:

[0099] When this round of consensus is initiated, if it is the consensus master node, the proposed data of this round of consensus is split into data blocks corresponding to the consensus backup nodes of the blockchain based on the erasure code algorithm, wherein the blockchain adopts the TendermintBFT Byzantine protocol for consensus;

[0100] If it is used as a consensus backup node, in the Propose phase of the TendermintBFT protocol, the data blocks split from the proposed data are sent to the corresponding consensus backup nodes in the blockchain through Propose messages;

[0101] If it is a consensus backup node, it performs erasure code verification on the data blocks provided by the consensus master node, so that in the Pre-vote phase of the TendermintBFT protocol, the data blocks that have successfully passed the erasure code verification are broadcast to other consensus backup nodes through pre-vote messages;

[0102] If it acts as a consensus backup node, based on the erasure code algorithm, it will restore the data blocks in at least N-2f pre-vote messages back to the proposed data, so as to execute the consensus logic of the TendermintBFT protocol on the restored proposed data in the Pre-commit phase of the TendermintBFT protocol to complete this round of consensus, where N is the number of consensus nodes of the blockchain, f is the fault tolerance number of consensus nodes set by the TendermintBFT protocol, and N is greater than or equal to 3f+1.

[0103] Those skilled in the art will appreciate that the embodiments of this specification may be provided as methods, systems or computer program products. Therefore, this specification may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0104] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0105] The above are only embodiments of this specification and are not intended to limit this specification. For those skilled in the art, this specification may be subject to various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included in the scope of the claims of this specification. In addition, all other embodiments obtained by ordinary technicians in this field without creative work shall fall within the scope of protection of this document.

Claims

1. A consensus method for a blockchain, comprising: When the consensus round is initiated, the consensus master node of the blockchain splits the proposed data of the consensus round into data blocks corresponding to the consensus backup nodes of the blockchain based on the erasure code algorithm, wherein the blockchain adopts the TendermintBFT Byzantine protocol for consensus; In the Propose phase of the TendermintBFT protocol, the consensus master node sends the data blocks split from the proposed data to the corresponding consensus backup nodes in the blockchain through a Propose message; The consensus backup node that receives the data block performs erasure code verification on the data block provided by the consensus master node, so as to broadcast the data block with successful erasure code verification to other consensus backup nodes through pre-vote messages in the Pre-vote phase of the TendermintBFT protocol; Based on the erasure code algorithm, the consensus backup node restores the data blocks in at least N-2f pre-vote messages to the proposed data, so as to execute the consensus logic of the TendermintBFT protocol on the restored proposed data in the Pre-commit phase of the TendermintBFT protocol to complete this round of consensus, wherein N is the number of consensus nodes of the blockchain, f is the fault tolerance number of consensus nodes set by the TendermintBFT protocol, and N is greater than or equal to 3f+1; if the consensus backup node fails to restore the proposed data, then in the Pre-vote phase of the TendermintBFT protocol, a Pre-commit nil message is broadcast to other consensus nodes of the blockchain; and if the erasure code verification fails for the consensus backup node that receives the data block, then in the Pre-vote phase of the TendermintBFT protocol, a pre-vote nil message is broadcast to other consensus nodes; wherein, when f Pre-commit nil messages are generated in this round of consensus, the proposed data directly determines that the consensus has not been reached; and the pre-vote nil message is used to vote for empty blocks.

2. The method according to claim 1, In the Pre-vote phase of the TendermintBFT protocol, the consensus backup node restores the data blocks in the obtained pre-vote message back to the proposed data based on the erasure coding algorithm, including: After obtaining at least Nf Prevote messages including the one provided by itself, the consensus backup node quickly restores the data in the obtained Prevote messages into the proposed data based on the erasure code algorithm.

3. The method according to claim 2, The consensus backup node executes the consensus logic of the TendermintBFT protocol on the restored proposal data in the Pre-vote phase of the TendermintBFT protocol, including: If the consensus backup node restores the proposed data based on the erasure coding algorithm, then in the Pre-vote phase of the TendermintBFT protocol, a Pre-commit message is broadcast to other consensus nodes of the blockchain; wherein, when this round of consensus generates Nf Pre-commit messages, the proposed data reaches a consensus of approval.

4. The method according to any one of claims 1 to 3, The data blocks into which the proposed data is split correspond to the Merkle tree path information obtained based on the erasure code algorithm, and the consensus master node also sends the Merkle tree path information matched by the data blocks into which the proposed data is split to the corresponding consensus backup node in the blockchain through a Propose message; The consensus backup node that receives the data block performs erasure code verification on the data block provided by the consensus master node, including: The consensus backup node that receives the data block reconstructs the Merkle tree for the data block provided by the consensus master node based on the erasure code algorithm. If the Merkle tree path information provided by the consensus master node matches the reconstructed Merkle tree, the erasure code verification succeeds, otherwise the erasure code verification fails.

5. The method according to any one of claims 1 to 3, further comprising: The consensus backup node that receives the data block performs erasure code verification on the data block provided by the consensus master node, including: If the proposed data was not initiated in the previous round of consensus, the consensus backup node that receives the data block performs erasure code verification on the data block provided by the consensus master node. Otherwise, the proposed data cached in the previous round of consensus is directly used to perform a matching verification on the data block provided by the consensus master node instead of erasure code verification.

6. A blockchain system, comprising: Consensus master node and consensus backup node; among them: When initiating this round of consensus, the consensus master node splits the proposed data of this round of consensus into data blocks corresponding to the consensus backup nodes of the blockchain based on the erasure code algorithm, wherein the blockchain adopts the TendermintBFT Byzantine protocol for consensus; In the Propose phase of the TendermintBFT protocol, the consensus master node sends the data blocks split from the proposed data to the corresponding consensus backup nodes in the blockchain through a Propose message; The consensus backup node that receives the data block performs erasure code verification on the data block provided by the consensus master node, so as to broadcast the data block with successful erasure code verification to other consensus backup nodes through pre-vote messages in the Pre-vote phase of the TendermintBFT protocol; Based on the erasure code algorithm, the consensus backup node restores the data blocks in at least N-2f pre-vote messages to the proposed data, so as to execute the consensus logic of the TendermintBFT protocol on the restored proposed data in the Pre-commit phase of the TendermintBFT protocol to complete this round of consensus, wherein N is the number of consensus nodes of the blockchain, f is the fault tolerance number of consensus nodes set by the TendermintBFT protocol, and N is greater than or equal to 3f+1; if the consensus backup node fails to restore the proposed data, then in the Pre-vote phase of the TendermintBFT protocol, a Pre-commit nil message is broadcast to other consensus nodes of the blockchain; and if the erasure code verification fails for the consensus backup node that receives the data block, then in the Pre-vote phase of the TendermintBFT protocol, a pre-vote nil message is broadcast to other consensus nodes; wherein, when f Pre-commit nil messages are generated in this round of consensus, the proposed data directly determines that the consensus has not been reached; and the pre-vote nil message is used to vote for empty blocks.

7. A blockchain node, comprising: The erasure code module, when the current round of consensus is initiated, if the blockchain node to which it belongs is the consensus master node, splits the proposed data of this round of consensus into data blocks corresponding to the consensus backup nodes of the blockchain based on the erasure code algorithm, wherein the blockchain adopts the TendermintBFT Byzantine protocol for consensus; The sending module, if the blockchain node to which it belongs is a consensus master node, in the Propose phase of the TendermintBFT protocol, sends the data blocks split from the proposed data to the corresponding consensus backup node in the blockchain through a Propose message; The verification module performs erasure code verification on the data blocks provided by the consensus master node if the blockchain node to which it belongs is a consensus backup node, so as to broadcast the data blocks with successful erasure code verification to other consensus backup nodes through pre-vote messages in the Pre-vote phase of the TendermintBFT protocol; The restoration module, if the blockchain node to which it belongs is a consensus backup node, restores the data blocks in at least N-2f pre-vote messages to the proposed data based on the erasure code algorithm, so as to execute the consensus logic of the TendermintBFT protocol on the restored proposed data in the Pre-commit phase of the TendermintBFT protocol to complete this round of consensus, wherein N is the number of consensus nodes of the blockchain, f is the fault tolerance number of consensus nodes set by the TendermintBFT protocol, and N is greater than or equal to 3f+1; if the consensus backup node fails to restore the proposed data, then in the Pre-vote phase of the TendermintBFT protocol, a Pre-commit nil message is broadcast to other consensus nodes of the blockchain; and if the consensus backup node that receives the data block fails the erasure code verification, then in the Pre-vote phase of the TendermintBFT protocol, a pre-vote nil message is broadcast to other consensus nodes; wherein, when f Pre-commit nil messages are generated in this round of consensus, the proposed data directly determines that the consensus has not been passed; the pre-vote The nil message is used to vote for an empty block.

8. An electronic device comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is executed by the processor: When this round of consensus is initiated, if it is the consensus master node, the proposed data of this round of consensus is split into data blocks corresponding to the consensus backup nodes of the blockchain based on the erasure coding algorithm, where the blockchain adopts the TendermintBFT Byzantine protocol for consensus; If it is used as a consensus backup node, in the Propose phase of the TendermintBFT protocol, the data blocks split from the proposed data are sent to the corresponding consensus backup nodes in the blockchain through Propose messages; If it is a consensus backup node, it performs erasure code verification on the data blocks provided by the consensus master node, so that in the Pre-vote phase of the TendermintBFT protocol, the data blocks that have successfully passed the erasure code verification are broadcast to other consensus backup nodes through pre-vote messages; If it is used as a consensus backup node, based on the erasure code algorithm, the data blocks in the obtained pre-vote messages of at least N-2f are restored back to the proposed data, so as to execute the consensus logic of the TendermintBFT protocol on the restored proposed data in the Pre-commit phase of the TendermintBFT protocol to complete this round of consensus, wherein N is the number of consensus nodes of the blockchain, f is the fault tolerance number of consensus nodes set by the TendermintBFT protocol, and N is greater than or equal to 3f+1; if the consensus backup node fails to restore the proposed data, then in the Pre-vote phase of the TendermintBFT protocol, a Pre-commit nil message is broadcast to other consensus nodes of the blockchain; and if the consensus backup node that receives the data block fails the erasure code verification, then in the Pre-vote phase of the TendermintBFT protocol, a pre-vote nil message is broadcast to other consensus nodes; wherein, when f Pre-commit nil messages are generated in this round of consensus, the proposed data directly determines that the consensus has not been passed; the pre-vote nil message is used to vote for empty blocks.

9. A computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the following steps: When this round of consensus is initiated, if it is the consensus master node, the proposed data of this round of consensus will be split into data blocks corresponding to the consensus backup nodes of the blockchain based on the erasure coding algorithm, where: The blockchain adopts TendermintBFT Byzantine protocol for consensus; If it is used as a consensus backup node, in the Propose phase of the TendermintBFT protocol, the data blocks split from the proposed data are sent to the corresponding consensus backup nodes in the blockchain through Propose messages; If it is a consensus backup node, it performs erasure code verification on the data blocks provided by the consensus master node, so that in the Pre-vote phase of the TendermintBFT protocol, the data blocks that have successfully passed the erasure code verification are broadcast to other consensus backup nodes through pre-vote messages; If it is used as a consensus backup node, based on the erasure code algorithm, the data blocks in the obtained pre-vote messages of at least N-2f are restored back to the proposed data, so as to execute the consensus logic of the TendermintBFT protocol on the restored proposed data in the Pre-commit phase of the TendermintBFT protocol to complete this round of consensus, wherein N is the number of consensus nodes of the blockchain, f is the fault tolerance number of consensus nodes set by the TendermintBFT protocol, and N is greater than or equal to 3f+1; if the consensus backup node fails to restore the proposed data, then in the Pre-vote phase of the TendermintBFT protocol, a Pre-commit nil message is broadcast to other consensus nodes of the blockchain; and if the consensus backup node that receives the data block fails the erasure code verification, then in the Pre-vote phase of the TendermintBFT protocol, a pre-vote nil message is broadcast to other consensus nodes; wherein, when f Pre-commit nil messages are generated in this round of consensus, the proposed data directly determines that the consensus has not been passed; the pre-vote nil message is used to vote for empty blocks.

Images