CN111600965A - Consensus method and system in block chain - Google Patents
Consensus method and system in block chain Download PDFInfo
- Publication number
- CN111600965A CN111600965A CN202010506075.2A CN202010506075A CN111600965A CN 111600965 A CN111600965 A CN 111600965A CN 202010506075 A CN202010506075 A CN 202010506075A CN 111600965 A CN111600965 A CN 111600965A
- Authority
- CN
- China
- Prior art keywords
- consensus
- node
- data
- target
- target proposal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 54
- 230000000977 initiatory effect Effects 0.000 claims description 10
- 238000012795 verification Methods 0.000 claims description 6
- 230000002159 abnormal effect Effects 0.000 claims description 3
- 230000005540 biological transmission Effects 0.000 description 24
- 230000008569 process Effects 0.000 description 6
- 238000010586 diagram Methods 0.000 description 5
- 238000004891 communication Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 230000001413 cellular effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000012856 packing Methods 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The specification discloses a consensus method and a system in a block chain, wherein the method comprises the following steps: the consensus main node initiates a target proposal aiming at the data to be consensus in the block chain, wherein the target proposal comprises a root hash formed by the data to be consensus; the consensus main node calls a broadcast network client of the node to broadcast the data to be consensus to the consensus backup node in the block chain; receiving the consensus backup node of the target proposal, and determining whether a broadcast network client of the node has data matched with the root hash in the target proposal; and receiving the consensus backup node of the target proposal, and if the broadcast network client of the node is determined to have data matched with the root hash in the target proposal, performing consensus operation on the target proposal.
Description
Technical Field
The present invention relates to the field of computer technologies, and in particular, to a consensus method and system in a block chain.
Background
Currently, in a blockchain network, nodes in a blockchain generally communicate with each other in a P2P direct connection manner. When a certain node in the blockchain needs to broadcast data to other nodes, the direct connection communication mode can make the whole blockchain network have large requirements on time delay and bandwidth.
Disclosure of Invention
The embodiment of the specification provides a consensus method and a consensus system in a block chain, so as to solve the problem that the communication between nodes in the existing block chain is performed in a P2P direct connection mode, so that the requirement of the whole block chain network on time delay and bandwidth is large.
In order to solve the above technical problem, the embodiments of the present specification are implemented as follows:
in a first aspect, a consensus method in a block chain is provided, including:
the consensus main node initiates a target proposal aiming at the data to be consensus in the block chain, wherein the target proposal comprises a root hash formed by the data to be consensus;
the consensus main node calls a broadcast network client of the node to broadcast the data to be consensus to the consensus backup node in the block chain;
receiving the consensus backup node of the target proposal, and determining whether a broadcast network client of the node has data matched with the root hash in the target proposal;
and receiving the consensus backup node of the target proposal, and if the broadcast network client of the node is determined to have data matched with the root hash in the target proposal, performing consensus operation on the target proposal.
In a second aspect, a blockchain system is provided, including:
the consensus main node initiates a target proposal aiming at the data to be consensus in the block chain, wherein the target proposal comprises a root hash formed by the data to be consensus; calling a broadcast network client of the node to broadcast the data to be identified to the identified backup node in the block chain;
receiving the consensus backup node of the target proposal, and determining whether a broadcast network client of the node has data matched with the root hash in the target proposal; and if the broadcast network client of the node is determined to have data matched with the root hash in the target proposal, performing consensus operation on the target proposal.
The embodiment of the specification can achieve at least the following technical effects by adopting the technical scheme:
by adopting the consensus method provided by the embodiment of the specification, the consensus master node initiates a target proposal aiming at the data to be consensus in the block chain, and calls a broadcast network client of the node to broadcast the data to be consensus to the consensus backup node in the block chain, wherein the target proposal comprises a root hash formed by the data to be consensus; the method comprises the steps of receiving a consensus backup node of a target proposal, determining whether a broadcast network client of the node has data matched with a root hash in the target proposal, and performing consensus operation on the target proposal if the broadcast network client of the node is determined to have data matched with the root hash in the target proposal.
That is, when the consensus master node initiates the consensus operation, the root hash of the target proposed data to be consensus is transmitted to the consensus backup node instead of the original data of the data to be consensus, and the original data of the data to be consensus is broadcasted to the consensus backup node in the block chain through the broadcasting network client in the consensus master node. On the one hand, as the root hash of the data to be identified is directly transmitted between the nodes, the transmission of the root hash between the nodes greatly saves the bandwidth occupied by data transmission compared with the original data; on the other hand, the original data of the data to be identified are transmitted through the broadcast network, so that the time delay of data transmission is reduced.
Drawings
The accompanying drawings, which are included to provide a further understanding of the specification and are incorporated in and constitute a part of this specification, illustrate embodiments of the specification and together with the description serve to explain the specification and not to limit the specification in a non-limiting sense. In the drawings:
fig. 1 is a schematic flow chart illustrating an implementation of a consensus method in a block chain according to an embodiment of the present disclosure;
fig. 2 is a schematic diagram of a block chain consensus method applied to an actual scene according to an embodiment of the present disclosure;
fig. 3 is a schematic structural diagram of a blockchain system according to an embodiment of the present disclosure.
Detailed Description
In order to make the purpose, technical solutions and advantages of this document more clear, the technical solutions of this specification will be clearly and completely described below with reference to specific embodiments of this specification and the accompanying drawings. It is to be understood that the embodiments described are only a few embodiments of this document, and not all embodiments. All other embodiments obtained by a person skilled in the art without making any inventive step based on the embodiments in this description belong to the protection scope of this document.
The technical solutions provided by the embodiments of the present description are described in detail below with reference to the accompanying drawings.
As described in the background art, in a conventional blockchain network, different nodes in a blockchain generally communicate with each other in a P2P direct connection manner, that is, data transmission between the nodes is performed. When a consensus operation needs to be performed on a proposal, nodes in the blockchain that participate in the consensus operation on the proposal need to broadcast data to other nodes. However, the P2P direct communication method is generally unicast, which requires a large delay and bandwidth for the whole blockchain network. For such a scenario, a 0-layer blockchain expansion technology is developed in the industry, including a relay network (e.g., bitcoin FIBRE) or a multicast network (e.g., BDN). However, the existing layer-0 blockchain network is optimized for transmission of blocks, and does not help the consensus protocol itself.
In order to solve the problem, an embodiment of the present specification provides a consensus method in a block chain, where, by using the consensus method provided in the embodiment of the present specification, a consensus master node initiates a target proposal for data to be consensus in the block chain, and invokes a broadcast network client of the node to broadcast the data to be consensus to a consensus backup node in the block chain, where the target proposal includes a root hash formed by the data to be consensus; the method comprises the steps of receiving a consensus backup node of a target proposal, determining whether a broadcast network client of the node has data matched with a root hash in the target proposal, and performing consensus operation on the target proposal if the broadcast network client of the node is determined to have data matched with the root hash in the target proposal.
When the consensus master node initiates the consensus operation, the root hash of the target proposed data to be consensus is transmitted to the consensus backup node instead of the original data of the data to be consensus, and the original data of the data to be consensus is broadcasted to the consensus backup node in the block chain through the broadcasting network client in the consensus master node. On the one hand, as the root hash of the data to be identified is directly transmitted between the nodes, the transmission of the root hash between the nodes greatly saves the bandwidth occupied by data transmission compared with the original data; on the other hand, the original data of the data to be identified are transmitted through the broadcast network, so that the time delay of data transmission is reduced.
Specifically, an implementation flow diagram of a consensus method in a block chain provided in one or more embodiments of the present specification is shown in fig. 1, and includes:
in step 110, the consensus master node initiates a target proposal for the data to be consensus in the blockchain, wherein the target proposal comprises a root hash formed by the data to be consensus.
It should be understood that if the amount of data transmitted between the consensus primary node and the consensus backup node in the blockchain is larger, the consumption of network bandwidth is larger, and the delay is larger. In order to solve the problem, when the consensus master node initiates a target proposal for the data to be identified in the blockchain, the consensus master node sends a root hash formed by the data to be identified to the consensus backup node in the blockchain, and since the root hash is usually 32 bytes of data, the network bandwidth occupied by directly performing data transmission between the nodes is greatly reduced, and meanwhile, the time delay of the data transmission is reduced.
It should be understood that, in order to ensure that the consensus master node catches up the collected set of transactions from the client from the transaction pool to the condition for initiating consensus, the consensus master node in the embodiment of the present specification may further determine whether the collected set of transactions satisfies the preset transaction collection condition before initiating the target proposal for the data to be consensus.
Optionally, the consensus master node initiates a target proposal for the data to be consensus in the blockchain, including:
the consensus main node acquires data to be consensus and generates a target proposal containing a root hash formed by the data to be consensus based on the data to be consensus;
and if the consensus main node determines that the data to be consensus meets the preset transaction collection condition, generating a target proposal containing a root hash formed by the data to be consensus based on the data to be consensus.
Wherein the preset transaction collection condition comprises at least one of the following conditions:
the transaction quantity in the data to be identified is greater than or equal to a preset quantity;
the period for collecting the transactions in the data to be identified is greater than or equal to the designated collection period;
the size of the data to be identified is greater than or equal to the specified capacity.
The data to be identified can include one or more transaction sets, one transaction set includes one or more transaction data, and the data to be identified can also be null. It should be understood that when the data to be consensus is empty, the target offer resulting from the packing of the data to be consensus is also empty. The consensus master node obtains the data to be consensus, and specifically, the consensus master node may drag for one or more transaction sets in the transaction pool, and package the transaction sets based on the one or more transaction sets to obtain the target offer. Specifically, to reduce the data transmission amount between nodes, a target proposal is packaged based on one or more transaction sets, and the packaged target proposal can only contain a root hash formed by one or more transaction sets.
Optionally, the consensus main node initiates a consensus algorithm corresponding to the target proposal for the data to be consensus in the blockchain, wherein the consensus algorithm comprises at least one of the following:
a Practical Byzantine Fault Tolerance (PBFT) consensus algorithm;
the Hotstuff consensus algorithm;
the librafbt consensus algorithm;
enddermint consensus algorithm.
Taking the consensus algorithm in the blockchain as the PBFT consensus algorithm as an example, the process of the consensus master node initiating a target proposal for the data to be consensus in the blockchain is described in detail below.
The consensus primary node sends a PRE-PREPARE message for the target proposal and a signature of the PRE-PREPARE message to a consensus backup node in the block chain, wherein the format of the PRE-PREPARE message is < PRE-PREPARE, v, n, d >, v is the view number where the target proposal is located, d is a root hash formed by one or more transaction sets corresponding to the target proposal, and n is [ H, H ] within a certain range interval.
And 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 block chain.
In the embodiment of the present disclosure, a broadcast network client is additionally disposed in a node based on a defect of a transmission manner of P2P between nodes, and the broadcast network client is configured to transmit original data of data to be identified to other nodes in a block chain. When the broadcast network client transmits data, the broadcast network client does not occupy network transmission bandwidth between nodes, and particularly transmits the data through the broadcast network in the block chain.
It should be understood that, in order to avoid that the original data of the data to be identified directly occupies too much network transmission bandwidth of the main node for identifying together, in this embodiment, the original data of the data to be identified, that is, the original data of one or more transaction sets in the data to be identified corresponding to the root hash in the target offer, may be sent by the broadcast network client in the main node for identifying together to the broadcast network client of the backup node for identifying together in the block chain. Specifically, the consensus master node may invoke a 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 block chain.
Optionally, in order to reduce the transmission delay of the data to be identified, in this specification, a broadcast network may be deployed in a block chain in advance, where the broadcast network is used to transmit large-capacity data between nodes, and a broadcast network client in each node is used to send and receive the data transmitted in the broadcast network. Specifically, the method for broadcasting the data to be identified to the identified backup node in the block chain by using the identified master node to call the broadcast network client of the node includes:
the consensus master node sends the data to be consensus to the broadcast network client of the node;
and broadcasting the data to be identified to the identification backup node in the block chain by the broadcast network client of the identification master node through the broadcast network of the block chain.
Because the to-be-identified data is transmitted through the broadcast network without additionally occupying the network transmission bandwidth between the nodes, the method provided by one or more embodiments of the present disclosure can greatly reduce the data volume of direct communication between the nodes, thereby reducing the network transmission bandwidth requirement between the nodes.
Step 130, receiving the consensus backup node of the target proposal, and determining whether the broadcast network client of the node has data matched with the root hash in the target proposal.
Since the block number for indicating that the to-be-consensus data corresponding to the target offer is to be written, i.e. the current view of the target offer, is also included in the target offer, and the identification of the current view is also included in the to-be-consensus data sent via the advertising network client. Thus, the consensus backup node that may receive the target offer determines whether the broadcast network client of the node has data that matches the root hash in the target offer based on the view identification in the target offer. Specifically, the method for determining whether data matching a root hash in a target offer exists at a broadcast network client of a node after receiving a consensus backup node of the target offer includes:
the consensus backup node which receives the target proposal obtains transaction data corresponding to the target view from a broadcast network client of the node based on the target view corresponding to the target proposal;
and the consensus backup node receiving the target proposal determines whether the broadcast network client of the node has data matched with the root hash in the target proposal or not based on the transaction data corresponding to the target view.
Specifically, the consensus backup node receiving the target proposal determines whether data matched with the root hash in the target proposal exists at the broadcast network client of the node based on the transaction data corresponding to the target view, and first, the consensus backup node may obtain the root hash formed by the transaction data corresponding to the target view based on the transaction data corresponding to the target view, and then determine 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, indicating that the broadcast network client of the node has data matched with 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, the broadcast network client of the node does not have data matched with the root hash in the target proposal.
Optionally, the receiving a consensus backup node of the target offer, and determining whether data matching the root hash in the target offer exists at a broadcast network client of the node includes:
the broadcast network client side which receives the consensus backup node of the target proposal receives the data to be consensus from the consensus main node through the broadcast network;
and the consensus backup node receiving the target proposal determines whether the data to be consensus received by the broadcast network client of the node is matched with the root hash in the target proposal.
Optionally, after receiving the consensus backup node of the target offer and determining whether the broadcast network client of the node has data matching the root hash in the target offer, the method further includes:
and if the common recognition backup node of the target proposal is received, determining whether the broadcast network client of the node receives the data matched with the root hash in the target proposal after receiving the target proposal for a preset time period if the broadcast network client of the node does not have the data matched with the root hash in the target proposal.
The preset time period is the upper limit of the preset overtime time. If the broadcast network client of the node is determined not to have data matched with the root hash in the target proposal, the node usually waits for a timeout time, and after the timeout time, the broadcast network client of the node still cannot inquire the data matched with the root hash in the target proposal, and then view switching operation can be initiated, namely, the next proposal consensus operation for the target proposal is started.
Optionally, in order not to affect the proposed consensus operation after the target proposal, after receiving the consensus backup node of the target proposal, determining whether the broadcast network client of the node has data matching the root hash in the target proposal, the method further comprises:
and receiving the consensus backup node of the target proposal, and if the broadcast network client of the node is determined to have no data matched with the root hash in the target proposal after receiving the preset time period of the target proposal, initiating the view switching operation.
Continuing to use the example that the consensus algorithm in the blockchain is the PBFT consensus algorithm, the process of receiving the consensus backup node of the target offer and determining whether the broadcast network client of the node has data matching the root hash in the target offer will be described in detail.
After receiving the PRE-PREPARE message for the target proposal, the consensus backup node verifies the PRE-PREPARE message, mainly verifying the following: whether the signature of the PRE-PREPARE message by the consensus master node is correct, whether one or more transaction sets matched with d exist in the broadcast network client of the consensus master node, whether n is in the interval [ H, H ], and whether the consensus backup node has received a PRE-PREPARE message which is under the same v and is also n in number, but has a different signature.
Step 140, receiving the consensus backup node of the target offer, and if it is determined that the broadcast network client of the node has data matching the root hash in the target offer, performing consensus operation on the target offer.
Optionally, in order to perform a block writing operation on the data to be consensus-found corresponding to the target offer, after the consensus backup node that receives the target offer performs a consensus operation on the target offer, the method further includes:
if the nodes in the block chain receive effective verification messages aiming at the target proposal from not less than 3f +1 nodes, generating a block recording data to be identified; wherein f is the maximum number of abnormal nodes allowed in the block chain.
Continuing to use the example that the consensus algorithm in the blockchain is the PBFT consensus algorithm, the consensus backup node that receives the target offer is described in detail, and if it is determined that the broadcast network client of the node has data matching the root hash in the target offer, the consensus operation is performed on the target offer.
After the received PRE-PREPARE message is verified by the consensus backup node, sending a PREPARE message to other nodes in the block chain including the consensus primary node, wherein the message is in a format of < PREPARE, v, n, d, i >, m is the same as the content of the PRE-PREPARE message, i is the number of the current consensus backup node, and meanwhile, signing < PREPARE, v, n, d, i >;
after receiving the PREPARE message, the consensus primary node and other consensus backup nodes in the block chain mainly perform the following checks: whether the signature of the PREPARE message is correct, whether the node receiving the PREPARE message has received n under the same view, whether n is within the interval [ H, H ], and whether d is the same as d in the received PRE-PREPARE message. Discarding the message if at least one of the verifications fails;
if the common identification primary node and other common identification backup nodes in the block chain receive the PREPARE messages of not less than 3f +1 nodes and pass the verification, sending COMMIT messages and message signatures to other nodes in the block chain, wherein the format is < COMMIT, v, n, d, i >, and v, n, d, i have the same content as the PREPARE messages;
after receiving the COMMIT message, the nodes in the block chain verify the COMMIT message, and mainly check the following items: whether the signature of the COMMIT message is correct, whether n under the same view has been received, whether one or more transaction sets matched with d exist in a transaction memory pool managed by the COMMIT message, and whether n is in an interval [ H, H ].
The method provided in the embodiment of the present disclosure is described in detail below by taking an exemplary diagram of applying the consensus method in the blockchain shown in fig. 2 to an actual scene as an example, as shown in fig. 2, the blockchain network includes a consensus master node and a plurality of consensus backup nodes, for convenience of description, the consensus backup node takes one of the consensus backup nodes as an example, and it should be understood that in an actual scene, the number of the consensus backup nodes is usually multiple. The implementation process of the consensus method in the block chain comprises the following steps:
and S1, after determining whether the at least one transaction set collected by the node meets the preset transaction collection condition, the consensus master node sends the at least one transaction set to the broadcast network client of the node when initiating the consensus proposal for the at least one transaction set. Wherein the preset transaction collection condition includes, 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 whether the size of the at least one transaction set is greater than or equal to a specified capacity, etc.
S2, the consensus primary node sends a pre-prepare message to the consensus backup node, the pre-prepare message including a root hash of at least one transaction set and tile metadata (indicating a view and tile number corresponding to the initiated consensus proposal).
S3, the broadcast network client in the consensus master node sends the at least one transaction set to the broadcast network, such 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.
And S5, the consensus backup node acquires the transaction data consistent with the block metadata in the pre-prepare message from the broadcast network client of the node, determines whether the root hash corresponding to the acquired transaction data is consistent with the root hash in the pre-prepare message, if so, continues the consensus operation proposed for the consensus, otherwise, waits for a preset time period.
And if the consensus backup node still does not find the transaction data matched with the root hash in the pre-prepare message from the broadcast network client of the node after the preset time period, initiating a view switching operation and carrying out consensus operation on the next proposal of the consensus proposal.
If the consensus backup node inquires a transaction set which corresponds 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, S7 is executed, and after the consensus backup node passes the verification, consensus operation on the target proposal is continuously executed; and if the common identification backup node does not inquire the transaction set which corresponds to the block number to be written in the target proposal and is not in the managed transaction memory pool in the designated time period, executing view switching operation.
By adopting the consensus method provided by the embodiment of the specification, the consensus master node initiates a target proposal aiming at the data to be consensus in the block chain, and calls a broadcast network client of the node to broadcast the data to be consensus to the consensus backup node in the block chain, wherein the target proposal comprises a root hash formed by the data to be consensus; the method comprises the steps of receiving a consensus backup node of a target proposal, determining whether a broadcast network client of the node has data matched with a root hash in the target proposal, and performing consensus operation on the target proposal if the broadcast network client of the node is determined to have data matched with the root hash in the target proposal.
That is, when the consensus master node initiates the consensus operation, the root hash of the target proposed data to be consensus is transmitted to the consensus backup node instead of the original data of the data to be consensus, and the original data of the data to be consensus is broadcasted to the consensus backup node in the block chain through the broadcasting network client in the consensus master node. On the one hand, as the root hash of the data to be identified is directly transmitted between the nodes, the transmission of the root hash between the nodes greatly saves the bandwidth occupied by data transmission compared with the original data; on the other hand, the original data of the data to be identified are transmitted through the broadcast network, so that the time delay of data transmission is reduced.
Fig. 3 is a schematic structural diagram of a blockchain system 300 according to an embodiment of the present disclosure. Referring to fig. 3, in one software implementation, a blockchain system 300 may include a consensus primary node 310 and a plurality of consensus backup nodes 320, wherein:
the consensus master node 310 initiates a target proposal aiming at the data to be agreed in the blockchain, wherein the target proposal comprises a root hash formed by the data to be agreed; calling a broadcast network client of the node to broadcast the data to be identified to the identified backup node in the block chain;
the consensus backup node 320 receiving the target proposal determines whether the broadcast network client of the node has data matching with the root hash in the target proposal; and if the broadcast network client of the node is determined to have data matched with the root hash in the target proposal, performing consensus operation on the target proposal.
Based on the block chain system provided by the embodiments of the present specification, it can be known that:
when the consensus master node initiates the consensus operation, the root hash of the target proposed data to be consensus is transmitted to the consensus backup node instead of the original data of the data to be consensus, and the original data of the data to be consensus is broadcasted to the consensus backup node in the block chain through the broadcasting network client in the consensus master node. On the one hand, as the root hash of the data to be identified is directly transmitted between the nodes, the transmission of the root hash between the nodes greatly saves the bandwidth occupied by data transmission compared with the original data; on the other hand, the original data of the data to be identified are transmitted through the broadcast network, so that the time delay of data transmission is reduced.
Optionally, in an embodiment, the consensus backup node 320 that received the target proposal is configured to:
acquiring transaction data corresponding to the target view from a broadcast network client of the node based on the target view corresponding to the target offer;
determining whether data matching a root hash in the target offer exists at a broadcast network client of the node based on transaction data corresponding to the target view.
Optionally, in an embodiment, the consensus master node 310 is configured to:
acquiring the data to be identified, and generating the target proposal containing a root hash formed by the data to be identified based on the data to be identified;
and if the data to be identified meet the preset transaction collection condition, generating the target proposal containing the root hash formed by the data to be identified based on the data to be identified.
Optionally, in an embodiment, the consensus master node 310 is configured to:
sending the data to be identified to a broadcast network client of the node;
and the broadcast network client of the consensus master node broadcasts the data to be consensus to the consensus backup node in the block chain through the broadcast network of the block chain.
Optionally, in one embodiment, after the consensus backup node 320 that received 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 block chain receives valid verification messages from not less than 3f +1 nodes for the target proposal, generating a block recorded with the data to be identified; wherein f is the maximum number of abnormal nodes allowed in the block chain.
Optionally, in an embodiment, after receiving the target proposed consensus backup node 320 and determining whether the broadcast network client of the node has data matching the root hash in the target proposal, the target proposed consensus backup node 320 is further configured to:
if the broadcast network client of the node is determined not to have the data matched with the root hash in the target proposal, after the target proposal is received for a preset time period, determining whether the broadcast network client of the node receives the data matched with the root hash in the target proposal.
Optionally, in an embodiment, after receiving the target proposed consensus backup node 320 and determining whether the broadcast network client of the node has data matching the root hash in the target proposal, the target proposed consensus backup node 320 is further configured to:
and if the broadcast network client of the node is determined to have no data matched with the root hash in the target proposal after receiving the preset time period of the target proposal, initiating a view switching operation.
Optionally, in an embodiment, the consensus master node initiates a consensus algorithm adopted for the target proposal of the data to be consensus in the blockchain, wherein the consensus algorithm comprises at least one of the following:
a practical Byzantine fault-tolerant PBFT consensus algorithm;
the Hotstuff consensus algorithm;
the librafbt consensus algorithm;
enddermint consensus algorithm.
The block chain system 300 can implement the method of the embodiment of the method shown in fig. 1 to 2, and specifically refer to the consensus method in the block chain of the embodiment shown in fig. 1 to 2, which is not described again.
In short, the above description is only a preferred embodiment of the present disclosure, and is not intended to limit the scope of the present disclosure. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of one or more embodiments of the present disclosure should be included in the scope of protection of one or more embodiments of the present disclosure.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.
Claims (10)
1. A method of consensus in a blockchain, comprising:
the consensus main node initiates a target proposal aiming at the data to be consensus in the block chain, wherein the target proposal comprises a root hash formed by the data to be consensus;
the consensus main node calls a broadcast network client of the node to broadcast the data to be consensus to the consensus backup node in the block chain;
receiving the consensus backup node of the target proposal, and determining whether a broadcast network client of the node has data matched with the root hash in the target proposal;
and receiving the consensus backup node of the target proposal, and if the broadcast network client of the node is determined to have data matched with the root hash in the target proposal, performing consensus operation on the target proposal.
2. The method of claim 1, receiving a consensus backup node of the target proposal, determining whether a broadcast network client of the node has data matching a root hash in the target proposal, comprising:
the consensus backup node receiving the target proposal acquires transaction data corresponding to a target view from a broadcast network client of the node based on the target view corresponding to the target proposal;
and the consensus backup node receiving the target proposal determines whether the broadcast network client of the node has data matched with the root hash in the target proposal or not based on the transaction data corresponding to the target view.
3. The method of claim 1, the consensus master node initiating a target proposal for data to be consensus in a blockchain, comprising:
the consensus master node acquires the data to be consensus and generates the target proposal containing a root hash formed by the data to be consensus based on the data to be consensus;
and if the consensus master node determines that the data to be consensus meets a preset transaction collection condition, generating the target offer comprising a root hash formed by the data to be consensus based on the data to be consensus.
4. The method of claim 1, wherein the consensus master node invokes a broadcast network client of the node to broadcast the data to be consensus to consensus backup nodes in a blockchain, including;
the consensus main node sends the data to be consensus to a broadcast network client of the node;
and the broadcast network client of the consensus master node broadcasts the data to be consensus to the consensus backup node in the block chain through the broadcast network of the block chain.
5. The method of claim 4, wherein the consensus backup node receiving the target proposal determines whether the broadcast network client of the node has data matching the root hash in the target proposal, comprising:
a broadcast network client receiving the consensus backup node of the target proposal receives the data to be consensus from the consensus main node via the broadcast network;
and the consensus backup node receiving the target proposal determines whether the data to be consensus received by the broadcast network client of the node is matched with the root hash in the target proposal.
6. The method of claim 1, after receiving the consensus operation by the consensus backup node of the target offer on the target offer, the method further comprising:
if the nodes in the block chain receive valid verification messages aiming at the target proposal from not less than 3f +1 nodes, generating a block recorded with the data to be identified; wherein f is the maximum number of abnormal nodes allowed in the block chain.
7. The method of claim 1, after receiving the consensus backup node of the target proposal, determining whether the broadcast network client of the node has data matching the root hash in the target proposal, the method further comprising:
and receiving the consensus backup node of the target proposal, and if the broadcast network client of the node is determined to have no data matched with the root hash in the target proposal, determining whether the broadcast network client of the node receives the data matched with the root hash in the target proposal after receiving the target proposal for a preset time period.
8. The method of claim 7, after receiving the consensus backup node of the target proposal, determining whether the broadcast network client of the node has data matching the root hash in the target proposal, the method further comprising:
and receiving the consensus backup node of the target proposal, and if the broadcast network client of the node is determined to have no data matched with the root hash in the target proposal after receiving the preset time period of the target proposal, initiating a view switching operation.
9. The method according to any of claims 1-8, wherein the consensus master node initiating a consensus algorithm to be adopted for a target proposal for data to be consensus in a blockchain comprises at least one of:
a practical Byzantine fault-tolerant PBFT consensus algorithm;
the Hotstuff consensus algorithm;
the librafbt consensus algorithm;
enddermint consensus algorithm.
10. A consensus system in a blockchain, comprising:
the consensus main node initiates a target proposal aiming at the data to be consensus in the block chain, wherein the target proposal comprises a root hash formed by the data to be consensus; calling a broadcast network client of the node to broadcast the data to be identified to the identified backup node in the block chain;
receiving the consensus backup node of the target proposal, and determining whether a broadcast network client of the node has data matched with the root hash in the target proposal; and if the broadcast network client of the node is determined to have data matched with the root hash in the target proposal, performing consensus operation on the target proposal.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010506075.2A CN111600965B (en) | 2020-06-05 | 2020-06-05 | Consensus method and system in blockchain |
| PCT/CN2021/097897 WO2021244568A1 (en) | 2020-06-05 | 2021-06-02 | Method for consensus in blockchain, and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010506075.2A CN111600965B (en) | 2020-06-05 | 2020-06-05 | Consensus method and system in blockchain |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111600965A true CN111600965A (en) | 2020-08-28 |
| CN111600965B CN111600965B (en) | 2023-10-27 |
Family
ID=72190106
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010506075.2A Active CN111600965B (en) | 2020-06-05 | 2020-06-05 | Consensus method and system in blockchain |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN111600965B (en) |
| WO (1) | WO2021244568A1 (en) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112801794A (en) * | 2021-02-08 | 2021-05-14 | 网易（杭州）网络有限公司 | Transaction execution method and device, electronic equipment and storage medium |
| CN113254272A (en) * | 2021-06-09 | 2021-08-13 | 腾讯科技（深圳）有限公司 | Data processing method and device for block chain network, computer equipment and medium |
| CN113365229A (en) * | 2021-05-28 | 2021-09-07 | 电子科技大学 | Network time delay optimization method of multi-union chain consensus algorithm |
| CN113573255A (en) * | 2021-07-26 | 2021-10-29 | 上海点融信息科技有限责任公司 | Method, device and storage medium for consensus based on block chain |
| WO2021244568A1 (en) * | 2020-06-05 | 2021-12-09 | 支付宝(杭州)信息技术有限公司 | Method for consensus in blockchain, and system |
| CN113821569A (en) * | 2021-09-30 | 2021-12-21 | 广州智链未来科技有限公司 | Block chain consensus method and block chain |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114338673A (en) * | 2021-12-30 | 2022-04-12 | 马上消费金融股份有限公司 | Transaction data processing method, device, equipment, system and storage medium |
| CN114401271A (en) * | 2022-01-13 | 2022-04-26 | 中国人民解放军国防科技大学 | Test data tamper-proof method, block chain system and medium |
| CN114598475B (en) * | 2022-01-24 | 2022-11-01 | 浙江甲骨文超级码科技股份有限公司 | Byzantine fault-tolerant consensus method and system based on fabric |
Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101656618A (en) * | 2009-09-11 | 2010-02-24 | 中兴通讯股份有限公司 | Multimedia message broadcasting method and system based on structural Peer-to-Peer Network (PPN) |
| WO2014168428A1 (en) * | 2013-04-11 | 2014-10-16 | 엘지전자 주식회사 | Method for delivering optimum path including plurality of passage places and apparatus therefor |
| CN106878000A (en) * | 2017-03-06 | 2017-06-20 | 中钞***产业发展有限公司北京智能卡技术研究院 | A kind of alliance's chain common recognition method and system |
| CN107220130A (en) * | 2017-05-12 | 2017-09-29 | 北京众享比特科技有限公司 | A kind of information common recognition method realized at the node of block chain, apparatus and system |
| US20170344987A1 (en) * | 2016-05-24 | 2017-11-30 | Mastercard International Incorporated | Method and system for an efficient consensus mechanism for permssioned blockchains using bloom filters and audit guarantees |
| CN109327548A (en) * | 2018-11-27 | 2019-02-12 | 北京瑞卓喜投科技发展有限公司 | A kind of block chain update method and block chain more new system |
| US20190312928A1 (en) * | 2018-04-06 | 2019-10-10 | Datalogic Ip Tech S.R.L. | Systems and methods for consensus-based data security for networked devices |
| WO2020011284A2 (en) * | 2019-09-05 | 2020-01-16 | Alibaba Group Holding Limited | System and method for adding node in blockchain network |
| KR102079786B1 (en) * | 2018-10-25 | 2020-02-21 | 주식회사 팀그릿 | Method and system for providing sales broadcast using block-chain |
| GB202003658D0 (en) * | 2020-03-13 | 2020-04-29 | Nchain Holdings Ltd | Blockchain transaction double spend proof |
| CN111212126A (en) * | 2019-12-27 | 2020-05-29 | 百度在线网络技术（北京）有限公司 | Data transmission method, device, equipment and medium of block chain network |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2017091530A1 (en) * | 2015-11-24 | 2017-06-01 | Gartland & Mellina Group | Blockchain solutions for financial services and other transaction-based industries |
| CN108550038A (en) * | 2018-04-18 | 2018-09-18 | 杭州秘猿科技有限公司 | A kind of data dissemination system and method applied to block chain |
| US20200026699A1 (en) * | 2018-07-20 | 2020-01-23 | True Blockchain Technology Ltd. | Highly Performant Decentralized Public Ledger with Hybrid Consensus |
| CN109150598B (en) * | 2018-08-10 | 2021-09-03 | 上交所技术有限责任公司 | BFT consensus algorithm bandwidth utilization rate improvement method based on block slice |
| CN109379397B (en) * | 2018-08-31 | 2019-12-06 | 阿里巴巴集团控股有限公司 | Transaction consensus processing method and device based on block chain and electronic equipment |
| CN110798308A (en) * | 2019-10-31 | 2020-02-14 | 支付宝(杭州)信息技术有限公司 | Block chain signature method and system |
| CN111600965B (en) * | 2020-06-05 | 2023-10-27 | 支付宝(杭州)信息技术有限公司 | Consensus method and system in blockchain |
-
2020
- 2020-06-05 CN CN202010506075.2A patent/CN111600965B/en active Active
-
2021
- 2021-06-02 WO PCT/CN2021/097897 patent/WO2021244568A1/en active Application Filing
Patent Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101656618A (en) * | 2009-09-11 | 2010-02-24 | 中兴通讯股份有限公司 | Multimedia message broadcasting method and system based on structural Peer-to-Peer Network (PPN) |
| WO2014168428A1 (en) * | 2013-04-11 | 2014-10-16 | 엘지전자 주식회사 | Method for delivering optimum path including plurality of passage places and apparatus therefor |
| US20170344987A1 (en) * | 2016-05-24 | 2017-11-30 | Mastercard International Incorporated | Method and system for an efficient consensus mechanism for permssioned blockchains using bloom filters and audit guarantees |
| CN106878000A (en) * | 2017-03-06 | 2017-06-20 | 中钞***产业发展有限公司北京智能卡技术研究院 | A kind of alliance's chain common recognition method and system |
| CN107220130A (en) * | 2017-05-12 | 2017-09-29 | 北京众享比特科技有限公司 | A kind of information common recognition method realized at the node of block chain, apparatus and system |
| US20190312928A1 (en) * | 2018-04-06 | 2019-10-10 | Datalogic Ip Tech S.R.L. | Systems and methods for consensus-based data security for networked devices |
| KR102079786B1 (en) * | 2018-10-25 | 2020-02-21 | 주식회사 팀그릿 | Method and system for providing sales broadcast using block-chain |
| CN109327548A (en) * | 2018-11-27 | 2019-02-12 | 北京瑞卓喜投科技发展有限公司 | A kind of block chain update method and block chain more new system |
| WO2020011284A2 (en) * | 2019-09-05 | 2020-01-16 | Alibaba Group Holding Limited | System and method for adding node in blockchain network |
| CN111212126A (en) * | 2019-12-27 | 2020-05-29 | 百度在线网络技术（北京）有限公司 | Data transmission method, device, equipment and medium of block chain network |
| GB202003658D0 (en) * | 2020-03-13 | 2020-04-29 | Nchain Holdings Ltd | Blockchain transaction double spend proof |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2021244568A1 (en) * | 2020-06-05 | 2021-12-09 | 支付宝(杭州)信息技术有限公司 | Method for consensus in blockchain, and system |
| CN112801794A (en) * | 2021-02-08 | 2021-05-14 | 网易（杭州）网络有限公司 | Transaction execution method and device, electronic equipment and storage medium |
| CN112801794B (en) * | 2021-02-08 | 2022-04-15 | 网易（杭州）网络有限公司 | Transaction execution method and device, electronic equipment and storage medium |
| CN113365229A (en) * | 2021-05-28 | 2021-09-07 | 电子科技大学 | Network time delay optimization method of multi-union chain consensus algorithm |
| CN113365229B (en) * | 2021-05-28 | 2022-03-25 | 电子科技大学 | Network time delay optimization method of multi-union chain consensus algorithm |
| CN113254272A (en) * | 2021-06-09 | 2021-08-13 | 腾讯科技（深圳）有限公司 | Data processing method and device for block chain network, computer equipment and medium |
| CN113573255A (en) * | 2021-07-26 | 2021-10-29 | 上海点融信息科技有限责任公司 | Method, device and storage medium for consensus based on block chain |
| CN113821569A (en) * | 2021-09-30 | 2021-12-21 | 广州智链未来科技有限公司 | Block chain consensus method and block chain |
| CN113821569B (en) * | 2021-09-30 | 2024-02-06 | 广州智链未来科技有限公司 | Block chain consensus method and block chain |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2021244568A1 (en) | 2021-12-09 |
| CN111600965B (en) | 2023-10-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111600965A (en) | Consensus method and system in block chain | |
| JP6745884B2 (en) | Data synchronization method, device and system | |
| CN107153644B (en) | Data synchronization method and device | |
| CN108550038A (en) | A kind of data dissemination system and method applied to block chain | |
| WO2023016428A1 (en) | Byzantine fault tolerance method and apparatus, and electronic device and storage medium | |
| CN111478829B (en) | Pressure testing method, device and system for block chain network | |
| EP3812994A1 (en) | Data evidence preservation method and system based on multiple blockchain networks | |
| CN111401904B (en) | Consensus method and system in alliance chain | |
| CN111526216A (en) | Consensus method and system in alliance chain | |
| CN108228581B (en) | Zookeeper compatible communication method, server and system | |
| CN109144782B (en) | Data recovery method and device | |
| EP3813335A1 (en) | Service processing method and system based on alliance chain network | |
| WO2023016429A1 (en) | Binary consensus method and apparatus capable of revoting, electronic device, and storage medium | |
| CN111526165B (en) | Consensus method and system in alliance chain | |
| CN115277727A (en) | Data disaster recovery method, system, device and storage medium | |
| CN110909030A (en) | Information processing method and server cluster | |
| WO2017008658A1 (en) | Storage checking method and system for text data | |
| CN112258184B (en) | Method, apparatus, electronic device and readable storage medium for freezing blockchain network | |
| CN113592639B (en) | Block chain transaction deleting method and system | |
| CN114157670A (en) | Message transmission method and device | |
| CN115460300A (en) | Data processing method, TOE hardware and computer readable storage medium | |
| CN113691879A (en) | Video data processing method, electronic device, and computer-readable storage medium | |
| CN111741121A (en) | Method and system for processing junk information in block chain | |
| CN114338692B (en) | Data balancing method and device based on partitioned cluster expansion | |
| CN110502333B (en) | Access request processing method and cloud storage system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 40035942 Country of ref document: HK |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |