WO2021244568A1

WO2021244568A1 - Method for consensus in blockchain, and system

Info

Publication number: WO2021244568A1
Application number: PCT/CN2021/097897
Authority: WO
Inventors: 李帅
Original assignee: 支付宝(杭州)信息技术有限公司
Priority date: 2020-06-05
Filing date: 2021-06-02
Publication date: 2021-12-09
Also published as: CN111600965A; CN111600965B

Abstract

Disclosed in the present description is a method for consensus in a blockchain and a system, the method comprising: in a blockchain, a consensus primary node initiates a target proposal with respect to data to undergo consensus, the target proposal including a root hash formed from the data to undergo consensus; the consensus main node uses a broadcast network client end of a present node, and broadcasts the data to undergo consensus to a consensus backup node in the blockchain; the consensus backup node that received the target proposal determines, for the broadcast network client end of the present node, whether data matching the root hash in the target proposal exists; if the consensus backup node that received the target proposal determines, for the broadcast network client end of the present node, data matching the root hash in the target proposal exists, performing a consensus operation on the target proposal.

Description

Consensus method and system in blockchain

Technical field

This document relates to the field of computer technology, in particular to a consensus method and system in the blockchain.

Background technique

At present, in the blockchain network, the nodes in the blockchain generally communicate with each other in a P2P direct connection. When a node in the blockchain needs to broadcast data to other nodes, this direct communication method will make the entire blockchain network have a relatively large demand for delay and bandwidth.

Summary of the invention

The embodiments of this specification provide a consensus method and system in the blockchain to solve the problem of communication between nodes in the existing blockchain through P2P direct connection, so that the entire blockchain network has a problem of delay and bandwidth. The demand is larger.

In order to solve the above technical problems, the embodiments of this specification are implemented as follows: First, a consensus method in the blockchain is proposed, including: the consensus master node initiates a target proposal for the consensus data in the blockchain, The target proposal includes the root hash composed of the data to be agreed; the consensus master node calls the broadcast network client of the node to broadcast the data to be agreed to the consensus backup node in the blockchain; receives the The consensus backup node proposed by the target determines whether the broadcast network client of this node has data matching the root hash in the target proposal; if the consensus backup node proposed by the target is received, if the broadcast network of this node is determined If the client has data that matches the root hash of the target proposal, then a consensus operation is performed on the target proposal.

In the second aspect, a blockchain system is proposed, including: a consensus master node, which initiates a target proposal for the data to be consensus in the blockchain, and the target proposal contains the root hash composed of the data to be consensus; and calls The broadcast network client of this node broadcasts the to-be-consensus data to the consensus backup node in the blockchain; the consensus backup node that receives the target proposal, determines whether the broadcast network client of this node is consistent with the target proposal If it is determined that the broadcast network client of this node has data that matches the root hash in the target proposal, then perform a consensus operation on the target proposal.

The embodiments of this specification adopt the above technical solutions to at least achieve the following technical effects: using the consensus method provided by the embodiments of this specification, the consensus master node initiates a target proposal for the data to be consensus in the blockchain, and calls the broadcast network of this node The client broadcasts the data to be consensus to the consensus backup node in the blockchain. The target proposal contains the root hash composed of the data to be consensus; the consensus backup node proposed by the target is received, and it is determined whether the broadcast network client of this node exists and The data that matches the root hash in the target proposal, and if it is determined that the broadcast network client of this node has data that matches the root hash in the target proposal, then a consensus operation is performed on the target proposal.

That is to say, when the consensus master node initiates a consensus operation, what is transmitted to the consensus backup node is the root hash of the consensus data proposed by the target, not the original data of the consensus data, and the broadcast network client in the consensus master node The terminal broadcasts the original data of the data to be consensus to the consensus backup node in the blockchain. On the one hand, because the root hash of the data to be consensus is directly transmitted between nodes, the transmission of root hash between nodes greatly saves the bandwidth occupied during data transmission compared with the original data; on the other hand, through the broadcast network Transmission of the original data of the data to be agreed also reduces the delay of data transmission.

Description of the drawings

The drawings described here are used to provide a further understanding of the specification and constitute a part of the specification. The exemplary embodiments and descriptions of the specification are used to explain the specification, and do not constitute an improper limitation of the specification. In the attached picture:

Figure 1 is a schematic diagram of the implementation process of a consensus method in a blockchain provided by an embodiment of this specification;

FIG. 2 is a schematic diagram of the consensus method in the blockchain provided by an embodiment of the specification applied in an actual scenario;

Fig. 3 is a schematic structural diagram of a blockchain system provided by an embodiment of this specification.

detailed description

In order to make the purpose, technical solutions and advantages of this document clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments of this specification and the corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this document, rather than all the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art without creative work shall fall within the protection scope of this document.

The technical solutions provided by the embodiments of this specification will be described in detail below with reference to the accompanying drawings.

As mentioned in the background art, in traditional blockchain networks, different nodes in the blockchain generally communicate in a P2P direct connection, that is, data transmission between nodes. When consensus operations on a certain proposal are required, nodes in the blockchain that participate in consensus operations on the proposal need to broadcast data to other nodes. However, this P2P direct communication method is generally unicast, which requires a relatively large delay and bandwidth for the entire blockchain network. In response to this scenario, the industry has developed a layer 0 blockchain expansion technology, including relay networks (such as Bitcoin FIBRE), or multicast networks (such as BDN). However, the existing layer 0 blockchain network is optimized for the transmission of blocks, and it does not help the consensus protocol itself.

In order to solve this problem, the embodiment of this specification proposes a consensus method in the blockchain. Using the consensus method provided in the embodiment of this specification, the consensus master node initiates a target proposal for the consensus data in the blockchain and calls The broadcast network client of this node broadcasts the consensus data to the consensus backup node in the blockchain. The target proposal contains the root hash composed of the consensus data; the consensus backup node proposed by the target is received, and the broadcast network of this node is determined Whether the client has data that matches the root hash of the target proposal, and if it is determined that the broadcast network client of this node has data that matches the root hash of the target proposal, then consensus operations are performed on the target proposal.

When the consensus master node initiates a consensus operation, what is transmitted to the consensus backup node is the root hash of the consensus data proposed by the target, not the original data of the consensus data, and the consensus is waiting for the consensus through the broadcast network client in the consensus master node. The original data of the data is broadcast to the consensus backup node in the blockchain. On the one hand, because the root hash of the data to be consensus is directly transmitted between nodes, the transmission of root hash between nodes greatly saves the bandwidth occupied during data transmission compared with the original data; on the other hand, through the broadcast network Transmission of the original data of the data to be agreed also reduces the delay of data transmission.

Specifically, the implementation flow diagram of a consensus method in a blockchain provided by one or more embodiments of this specification is shown in FIG. The target proposal of the target proposal contains the root hash of the data to be agreed.

It should be understood that the greater the amount of data transmitted between the consensus master node and the consensus backup node in the blockchain, the greater the consumption of network bandwidth and the greater the delay. In order to solve this problem in the embodiment of this specification, when the consensus master node initiates a target proposal for the consensus data in the blockchain, the consensus master node sends the root hash composed of the consensus data to the consensus backup node in the blockchain Since the root hash is usually a 32-byte data, this will greatly reduce the network bandwidth occupied by the direct data transmission between nodes, and at the same time reduce the data transmission delay.

It should be understood that, in order to ensure that the collection of transactions from the client terminal collected by the consensus master node from the transaction pool meets the conditions for initiating a consensus, the consensus master node in the embodiment of this specification can also initiate a target proposal for the data to be consensus Determine whether the collected transaction set meets the preset transaction collection conditions.

Optionally, the consensus master node initiates a target proposal for the consensus data in the blockchain, including: the consensus master node obtains the consensus data, and based on the consensus data, generates a target proposal containing the root hash of the consensus data ; If the consensus master node determines that the consensus data meets the preset transaction collection conditions, based on the consensus data, it generates a target proposal containing the root hash composed of the consensus data.

Wherein, the preset transaction collection conditions include at least one of the following: the number of transactions in the data to be agreed is greater than or equal to the preset number; the period for collecting transactions in the data to be agreed is greater than or equal to the specified collection period; the data to be agreed The size is greater than or equal to the specified capacity.

Wherein, the data to be agreed may include one or more transaction sets, and one transaction set includes one or more transaction data, and the data to be agreed may also be empty. It should be understood that when the consensus data is empty, the target proposal obtained by packaging the consensus data is also empty. When the consensus master node obtains the data to be consensus, the consensus master node can obtain one or more transaction sets from the transaction pool, and package the target proposal based on the one or more transaction sets. Specifically, in order to reduce the amount of data transmission between nodes, the target proposal is packaged based on one or more transaction sets, and the packaged target proposal may only include the root hash composed of one or more transaction sets.

Optionally, the consensus master node in the blockchain initiates a consensus algorithm corresponding to the target proposal for the data to be consensus, including at least one of the following: Practical Byzantine Fault Tolerance (PBFT) consensus algorithm; Hotstuff consensus algorithm; LibraBFT Consensus algorithm; Tendermint consensus algorithm.

The following takes the consensus algorithm in the blockchain as the PBFT consensus algorithm as an example to describe in detail the process of the consensus master node initiating a target proposal for the consensus data in the blockchain.

The consensus master node sends the PRE-PREPARE message proposed for the target and the signature of the PRE-PREPARE message to the consensus backup node in the blockchain. The format of the PRE-PREPARE message is <PRE-PREPARE, v, n, d >, where v is the view number of the target proposal, d is the root hash formed by one or more transaction sets corresponding to the target proposal, and n is [h, H] within a certain range.

Step 120: The consensus master node calls the broadcast network client of the node to broadcast the data to be consensus to the consensus backup node in the blockchain.

Among them, the broadcast network client is additionally set in the node based on the defect of the P2P transmission method between nodes in the embodiment of this specification, and the broadcast network client is used to transmit the original data of the data to be consensus to other nodes in the blockchain . When the broadcast network client performs data transmission, it does not occupy the network transmission bandwidth between nodes, and specifically transmits data via the broadcast network in the blockchain.

It should be understood that, in order to avoid the direct transmission of the original data of the data to be agreed between nodes and excessively occupy the network transmission bandwidth of the consensus master node, the original data of the data to be agreed in the embodiment of this specification is the root of the target proposal. The original data of one or more transaction sets in the corresponding data for consensus can be sent to the consensus backup in the blockchain by the broadcast network client in the consensus master node. The broadcast network client of the node. Specifically, the consensus master node can call the broadcast network client of the node to broadcast the data to be consensus to the broadcast network client of the consensus backup node in the blockchain.

Optionally, in order to reduce the transmission delay of the data to be agreed, the embodiment of this specification may pre-deploy a broadcast network in the blockchain. The broadcast network is used to transmit large-capacity data between nodes, and the broadcast network clients in each node The terminal is used to send and receive data transmitted in the broadcast network. Specifically, the consensus master node calls the broadcast network client of this node to broadcast the consensus data to the consensus backup node in the blockchain, including: the consensus master node sends the consensus data to the broadcast network client of the node; consensus The broadcast network client of the master node broadcasts the consensus data to the consensus backup node in the blockchain via the broadcast network of the blockchain.

Since the transmission of the data to be agreed through the broadcast network does not additionally occupy the network transmission bandwidth between nodes, the method provided by one or more embodiments of this specification can greatly reduce the amount of data directly communicated between nodes, thereby reducing the amount of data between nodes. Network transmission bandwidth requirements.

Step 130: Receive the consensus backup node proposed by the target, and determine whether the broadcast network client of this node has data matching the root hash in the target proposal.

Since the target proposal also includes the block number used to indicate that the consensus data corresponding to the target proposal will be written, that is, the current view of the target proposal, and the consensus data sent via the advertising network client also includes the identifier of the current view. Therefore, the consensus backup node that can receive the target proposal determines whether the broadcast network client of the node has data matching the root hash in the target proposal based on the view identifier in the target proposal. Specifically, the consensus backup node that receives the target proposal, determines whether the broadcast network client of this node has data that matches the root hash in the target proposal, including: the consensus backup node that receives the target proposal, corresponds to the target proposal The target view of the target view is obtained from the broadcast network client of this node corresponding to the transaction data of the target view; the consensus backup node that receives the target proposal, based on the transaction data corresponding to the target view, determines whether the broadcast network client of this node exists Data that matches the root hash in the target proposal.

Specifically, the consensus backup node that receives the target proposal, based on the transaction data corresponding to the target view, determines whether the broadcast network client of the node has data that matches the root hash in the target proposal. The transaction data of the view obtains the root hash formed by the transaction data corresponding to the target view, and then it is determined whether the root hash formed by the transaction data corresponding to the target view is consistent with the root hash carried in the target proposal.

If the root hash formed by the transaction data corresponding to the target view is consistent with the root hash carried in the target proposal, it indicates that the broadcast network client of this node has data that matches the root hash in the target proposal; and if The root hash formed by the transaction data corresponding to the target view is inconsistent with the root hash carried in the target proposal, indicating that the broadcast network client of this node does not have data that matches the root hash in the target proposal.

Optionally, the consensus backup node that receives the target proposal, determines whether the broadcast network client of this node has data that matches the root hash in the target proposal, including: the broadcast network client that receives the consensus backup node proposed by the target The end receives the consensus data from the consensus master node via the broadcast network; the consensus backup node that receives the target proposal determines whether the consensus data received by the broadcast network client of this node matches the root hash of the target proposal.

Optionally, after receiving the consensus backup node proposed by the target and determining whether the broadcast network client of this node has data matching the root hash in the target proposal, the method further includes: receiving the consensus backup proposed by the target The node, if it is determined that the broadcast network client of this node does not have data that matches the root hash in the target proposal, it will determine whether the broadcast network client of this node receives the target proposal for a preset period of time To the data that matches the root hash in the target proposal.

Among them, the preset time period is the upper limit of the preset timeout period. The consensus backup node that receives the target proposal, if it is determined that the broadcast network client of this node does not have data that matches the root hash in the target proposal, it will usually wait for a timeout period. If the broadcast network client cannot find the data that matches the root hash of the target proposal, it can initiate a view switching operation, that is, start a consensus operation on the next proposal proposed by the target.

Optionally, in order not to affect the consensus operation of the proposal after the target proposal, after receiving the consensus backup node of the target proposal, it is determined whether the broadcast network client of this node has data that matches the root hash in the target proposal, so The method further includes: the consensus backup node that receives the target proposal, if after receiving the target proposal for a preset time period, it is determined that the broadcast network client of the node does not have data that matches the root hash of the target proposal, The view switching operation is initiated.

Continue to use the consensus algorithm in the blockchain as the PBFT consensus algorithm as an example, describe in detail the consensus backup node that receives the target proposal, and determine whether the broadcast network client of this node has data that matches the root hash in the target proposal process.

After the consensus backup node receives the PRE-PREPARE message proposed for the target, it verifies the PRE-PREPARE message, mainly verifying the following: the consensus master node’s signature of the PRE-PREPARE message is correct, and the broadcast network client of its own node Whether there are one or more transaction sets that match d, whether n is in the interval [h, H], and whether the consensus backup node has received a PRE that is under the same v and numbered n but has a different signature -PREPARE information.

In step 140, the consensus backup node proposed by the target is received, and if it is determined that the broadcast network client of the node has data matching the root hash in the target proposal, then a consensus operation is performed on the target proposal.

Optionally, in order to write a block operation on the data to be consensus corresponding to the target proposal, after the consensus backup node that receives the target proposal performs the consensus operation on the target proposal, the method further includes: if the node in the blockchain receives A valid verification message from no less than 3f+1 nodes for the target proposal will generate a block recording the data to be consensus; where f is the maximum number of abnormal nodes allowed in the blockchain.

Continue to use the consensus algorithm in the blockchain as the PBFT consensus algorithm as an example to describe in detail the consensus backup node that receives the target proposal. If it is determined that the broadcast network client of this node has data that matches the root hash of the target proposal, The process of consensus operation on the target proposal.

After the consensus backup node passes the verification of the received PRE-PREPARE message, it sends a PRE-PREPARE message to other nodes in the blockchain, including the consensus master node, in the format of <PREPARE,v,n,d,i>message, v,n ,d,m have the same content as the above PRE-PREPARE message, i is the number of the current consensus backup node, and at the same time sign <PREPARE,v,n,d,i>; the consensus master node and other consensus backups in the blockchain After the node receives the PREPARE message, it mainly performs the following checks: whether the signature of the PREPARE message is correct, whether the node receiving the PREPARE message has received the n under the same view, and whether n is in the interval [h, H] , And whether d is the same as d in the received PRE-PREPARE message. If at least one verification fails, the message is discarded; if the consensus master node and other consensus backup nodes in the blockchain receive PREPARE messages from no less than 3f+1 nodes, and the verification is passed, the message is sent to the blockchain The other nodes in the node send the COMMIT message and the message signature in the format of <COMMIT,v,n,d,i>, where v,n,d,i are the same as the above PREPARE message content; the node in the blockchain receives the After the COMMIT message, verify the COMMIT message, mainly to verify the following items: whether the signature of the COMMIT message is correct, whether the n under the same view has been received, and whether there is a matching d in the transaction memory pool managed by it One or more transaction sets, whether n is in the interval [h, H].

The following takes the schematic diagram of the application of the consensus method in the blockchain shown in FIG. 2 in an actual scenario as an example to introduce the method provided in the embodiment of this specification in detail. As shown in FIG. 2, the blockchain network includes a consensus master. Nodes and multiple consensus backup nodes. For ease of description, the consensus backup node takes one of the consensus backup nodes as an example. It should be understood that in actual scenarios, the number of consensus backup nodes is usually multiple. The implementation process of the consensus method in the blockchain includes:

S1: After determining whether at least one transaction set collected by this node meets the preset transaction collection conditions, the consensus master node sends the at least one to the broadcast network client of the node when initiating a consensus proposal for the at least one transaction set. Transaction collection. The preset transaction collection conditions include, for example, whether the number of transactions in the at least one transaction set is greater than or equal to a preset number, whether the collection period of the at least one transaction set is greater than or equal to a specified collection period, and/or the at least one transaction Is the size of the collection greater than or equal to the specified capacity, etc.

S2. The consensus master node sends a pre-prepare message to the consensus backup node. The pre-prepare message contains the root hash of at least one transaction set and block metadata (used to indicate the view and area corresponding to the initiated consensus proposal). Block number).

S3: The broadcast network client in the consensus master node sends the at least one transaction set to the broadcast network, so that the broadcast network sends the at least one transaction set to the broadcast network client of the consensus backup node.

S4: The broadcast network sends the at least one transaction set to the broadcast network client of the consensus backup node.

S5. The consensus backup node obtains transaction data consistent with the block metadata in the pre-prepare message from the broadcast network client of the node, and determines whether the root hash corresponding to the obtained transaction data is the same as that in the pre-prepare message The root hashes are consistent. If they are consistent, continue the consensus operation on the consensus proposal, otherwise wait for the preset time period.

If after the preset time period, the consensus backup node still does not find the transaction data matching the root hash in the pre-prepare message from the broadcast network client of the node, it will initiate a view switch operation to download the consensus proposal. A proposal for consensus operation.

If the consensus backup node finds the transaction set corresponding to the block number to be written in the target proposal and is not in the managed transaction memory pool within the specified time period, execute S7, and continue to execute the target proposal after passing the verification If the consensus backup node does not find the transaction set corresponding to the block number to be written in the target proposal and not in the managed transaction memory pool within the specified time period, the view switching operation will be performed.

Using the consensus method provided in the embodiment of this specification, the consensus master node initiates a target proposal for the data to be agreed in the blockchain, and calls the broadcast network client of this node to broadcast the data to be agreed to the consensus backup node in the blockchain , The target proposal contains the root hash of the consensus data; the consensus backup node that receives the target proposal determines whether the broadcast network client of this node has data that matches the root hash in the target proposal, and if it is determined The broadcast network client of the node has data that matches the root hash in the target proposal, and then performs a consensus operation on the target proposal.

FIG. 3 is a schematic structural diagram of a blockchain system 300 provided by an embodiment of this specification. Please refer to FIG. 3, in a software implementation, the blockchain system 300 may include a consensus master node 310 and a plurality of consensus backup nodes 320, among which: the consensus master node 310 initiates a transaction for the consensus data in the blockchain A target proposal, the target proposal contains the root hash composed of the data to be agreed; and the broadcast network client that calls the node broadcasts the data to be agreed to the consensus backup node in the blockchain; the target proposal is received The consensus backup node 320 of this node determines whether the broadcast network client of this node has data that matches the root hash in the target proposal; and if it is determined that the broadcast network client of this node has the root hash in the target proposal For data matching the hash, a consensus operation is performed on the target proposal.

Based on the blockchain system provided by the embodiment of this specification, it can be known that when the consensus master node initiates a consensus operation, the root hash of the consensus data proposed by the target is transmitted to the consensus backup node, rather than the original data of the consensus data. And through the broadcast network client in the consensus master node, the original data of the data to be consensus is broadcast to the consensus backup node in the blockchain. On the one hand, because the root hash of the data to be consensus is directly transmitted between nodes, the transmission of root hash between nodes greatly saves the bandwidth occupied during data transmission compared with the original data; on the other hand, through the broadcast network Transmission of the original data of the data to be agreed also reduces the delay of data transmission.

Optionally, in an implementation manner, the consensus backup node 320 that has received the target proposal is configured to: based on the target view corresponding to the target proposal, obtain from the broadcast network client of the node corresponding to the Transaction data of the target view; based on the transaction data corresponding to the target view, determine whether the broadcast network client of this node has data that matches the root hash in the target proposal.

Optionally, in one embodiment, the consensus master node 310 is configured to: obtain the data to be agreed, and based on the data to be agreed, generate a root hash that contains the data to be agreed The target proposal; if it is determined that the data to be agreed upon meets a preset transaction collection condition, based on the data to be agreed, the target proposal including the root hash formed by the data to be agreed is generated.

Optionally, in an implementation manner, the consensus master node 310 is configured to: send the data to be agreed to the broadcast network client of the node; the broadcast network client of the consensus master node sends the The consensus data is broadcast to the consensus backup node in the blockchain via the broadcasting network of the blockchain.

Optionally, in an embodiment, after the consensus backup node 320 receiving the target proposal performs a consensus operation on the target proposal, if the consensus master node 310 or the consensus backup node 320 in the blockchain Receive valid verification messages from no less than 3f+1 nodes for the target proposal, then generate a block recording the data to be agreed; where f is the maximum number of abnormal nodes allowed in the blockchain .

Optionally, in an implementation manner, after receiving the consensus backup node 320 of the target proposal, after determining whether the broadcast network client of the node has data matching the root hash in the target proposal, it receives The consensus backup node 320 to the target proposal is also used to: if it is determined that the broadcast network client of this node does not have data that matches the root hash in the target proposal, then the target proposal is received After a preset period of time, it is determined whether the broadcast network client of the node receives data that matches the root hash in the target proposal.

Optionally, in an implementation manner, after receiving the consensus backup node 320 of the target proposal, after determining whether the broadcast network client of the node has data matching the root hash in the target proposal, it receives The consensus backup node 320 to the target proposal is also used to: if the target proposal is received for the preset time period, it is determined that the broadcast network client of this node does not have the root hash in the target proposal. If the matching data is matched, the view switching operation is initiated.

Optionally, in an implementation manner, the consensus algorithm used by the consensus master node to initiate a target proposal for the consensus data in the blockchain includes at least one of the following: a practical Byzantine fault-tolerant PBFT consensus algorithm; a Hotstuff consensus algorithm; LibraBFT Consensus algorithm; Tendermint consensus algorithm.

The blockchain system 300 can implement the methods of the method embodiments shown in FIGS. 1 to 2. For details, please refer to the consensus method in the blockchain of the embodiment shown in FIGS. 1 to 2, which will not be repeated here.

In short, the above descriptions are only preferred embodiments of this specification, and are not used to limit the protection scope of this specification. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of one or more embodiments of this specification shall be included in the protection scope of one or more embodiments of this specification.

The systems, devices, modules, or units explained in the foregoing embodiments may be specifically implemented by computer chips or entities, or implemented by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cell phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or Any combination of these devices.

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

It should also be noted that the terms "include", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or equipment including a series of elements includes not only those elements, but also Other elements that are not explicitly listed, or include elements inherent to such processes, methods, commodities, or equipment. If there are no more restrictions, the element defined by the sentence "including a..." does not exclude the existence of other identical elements in the process, method, commodity or equipment that includes the element.

The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, as for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for related parts, please refer to the part of the description of the method embodiment.

Claims

A consensus method in the blockchain, including:

The consensus master node initiates a target proposal for the data to be consensus in the blockchain, and the target proposal contains the root hash composed of the data to be consensus;

The consensus master node calls the broadcast network client of this node to broadcast the consensus data to the consensus backup node in the blockchain;

The consensus backup node that receives the target proposal, and determines whether the broadcast network client of the node has data that matches the root hash in the target proposal;

The consensus backup node that receives the target proposal, if it is determined that the broadcast network client of the node has data that matches the root hash in the target proposal, then performs a consensus operation on the target proposal.
The method according to claim 1, wherein the consensus backup node that receives the target proposal and determines whether the broadcast network client of the node has data matching the root hash in the target proposal includes:

The consensus backup node that receives the target proposal obtains transaction data corresponding to the target view from the broadcast network client of the node based on the target view corresponding to the target proposal;

The consensus backup node that receives the target proposal, based on the transaction data corresponding to the target view, determines whether the broadcast network client of the node has data that matches the root hash in the target proposal.
The method according to claim 1, wherein the consensus master node initiates a target proposal for the data to be agreed in the blockchain, including:

The consensus master node obtains the data to be agreed, and based on the data to be agreed, generates the target proposal including the root hash formed by the data to be agreed;

If the consensus master node determines that the data for consensus meets the preset transaction collection conditions, based on the data for consensus, the target proposal including the root hash formed by the data for consensus is generated.
The method according to claim 1, wherein the consensus master node calls the broadcast network client of the node to broadcast the data to be consensus to the consensus backup node in the blockchain, comprising;

The consensus master node sends the data to be agreed upon to the broadcast network client of the node;

The broadcast network client of the consensus master node broadcasts the to-be-consensus data to the consensus backup node in the blockchain via the broadcast network of the blockchain.
The method according to claim 4, the consensus backup node that receives the target proposal, and determines whether the broadcast network client of the node has data matching the root hash in the target proposal, comprising:

The broadcast network client that receives the consensus backup node proposed by the target receives the data to be agreed from the consensus master node via the broadcast network;

The consensus backup node that receives the target proposal determines whether the data to be consensus received by the broadcast network client of the node matches the root hash in the target proposal.
The method according to claim 1, after the consensus backup node that receives the target proposal performs a consensus operation on the target proposal, the method further comprises:

If a node in the blockchain receives a valid verification message proposed by no less than 3f+1 nodes for the target, a block recording the data to be agreed upon is generated; where f is the zone The maximum number of abnormal nodes allowed in the blockchain.
The method according to claim 1, after receiving the consensus backup node of the target proposal, and determining whether the broadcast network client of the node has data matching the root hash in the target proposal, the method further include:

The consensus backup node that receives the target proposal, if it is determined that the broadcast network client of this node does not have data that matches the root hash in the target proposal, it will wait for a preset time after receiving the target proposal After the segment, it is determined whether the broadcast network client of this node receives data that matches the root hash in the target proposal.
The method according to claim 7, after receiving the consensus backup node of the target proposal, and determining whether the broadcast network client of the node has data matching the root hash in the target proposal, the method further include:

The consensus backup node that receives the target proposal, if after receiving the target proposal for the preset time period, it is determined that the broadcast network client of this node does not have data that matches the root hash of the target proposal , The view switching operation is initiated.
According to the method according to any one of claims 1-8, the consensus algorithm that the consensus master node initiates in the blockchain for the target proposal of the consensus data includes at least one of the following:

Practical Byzantine fault-tolerant PBFT consensus algorithm;

Hotstuff consensus algorithm;

LibraBFT consensus algorithm;

Tendermint consensus algorithm.
A consensus system in the blockchain, including:

The consensus master node initiates a target proposal for the consensus data in the blockchain, the target proposal contains the root hash of the consensus data; and the broadcast network client calling this node broadcasts the consensus data to Consensus backup nodes in the blockchain;

The consensus backup node that receives the target proposal determines whether the broadcast network client of this node has data that matches the root hash in the target proposal; and if it is determined that the broadcast network client of this node exists and the If the root hash of the target proposal matches the data, the consensus operation is performed on the target proposal.