CN111147261B - Method and system for using HotStuff consensus algorithm in block chain - Google Patents
Method and system for using HotStuff consensus algorithm in block chain Download PDFInfo
- Publication number
- CN111147261B CN111147261B CN201911414474.XA CN201911414474A CN111147261B CN 111147261 B CN111147261 B CN 111147261B CN 201911414474 A CN201911414474 A CN 201911414474A CN 111147261 B CN111147261 B CN 111147261B
- Authority
- CN
- China
- Prior art keywords
- block
- node
- stage
- certificate
- submission
- 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.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
- H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Abstract
The invention discloses a method and a system for using a HotStuff consensus algorithm in a block chain, wherein the method comprises the following steps: initiating a proposal through a leader node, broadcasting the proposal to a copy node, and generating a prepared certificate; the leader node broadcasts the prepared certificate to the replica node to generate a pre-submitted certificate; the leader node broadcasts the pre-submitted certificate to the replica nodes to generate submitted certificates; the leader node broadcasts the submission certificate to the replica nodes, and all the replica nodes execute the proposal; restarting the nodes according to the flow table and the block data table; and carrying out initial starting of the nodes according to the flow table and the block data table. The invention adds the steps of initial node starting and node restarting, improves the completeness of the engineering process, perfects the normal operation of the block chain system, can ensure the data integrity of the consensus certification process, is convenient for the synchronization and verification of the subsequent node data, and can be widely applied to the technical field of block chains.
Description
Technical Field
The invention relates to the technical field of block chains, in particular to a method and a system for using a HotStuff consensus algorithm in a block chain.
Background
The HotStuff algorithm is a PBFT-type consensus algorithm for a block chain, for example, the consensus algorithm adopted by the block chain project Libra of Facebook is based on the HotStuff algorithm, and the communication complexity and the calculation complexity of the algorithm are reduced to O (n) through aggregation signature and pipeline design.
Under the HotStuff algorithm, the consensus of each block is divided into four stages: preparation phase (Prepare), Pre-Commit phase (Pre-Commit), Commit phase (Commit), decision phase (Decode), wherein the first three phases are all essentially implemented by "voting" action, i.e. a vote is made in each of the preparation, Pre-Commit and Commit phases, and if and only if the vote count exceeds 2/3 of the total number of nodes, the consensus of the phase is successful, and the next phase is entered. The voting result of each stage is expressed by QC (Quorum certificate). In the pipeline design, the "voting" action of the consensus phases of the adjacent blocks is multiplexed, that is, the Pre-Commit phase of the first block completes the Prepare phase of the second block at the same time, the Commit phase of the first block completes the Pre-Commit phase of the second block and the Prepare phase of the third block at the same time, the divide phase of the first block is the Commit phase of the second block, the Pre-Commit phase of the third block and the Prepare phase of the fourth block at the same time, and so on, the adjacent blocks use the block hash value as the direction relation. In a specific pipeline design, a consensus process is composed of a plurality of rounds, each round is called a View (View), each View has a Leader node, the same action is repeated in each View, namely the Leader node of each View broadcasts the voting result in the last View and the proposed block of the current stage to other nodes at the same time, and the Leader in the current View collects the voting result of the current stage and then sends the voting result to the Leader node of the next round. Each vote represents a "vote" of the proposed chunk and the ancestor chunk (traced back through the hash value), i.e., either confirming the voting result or confirming the submission.
In the HotStuff consensus algorithm, if and only if a block reaches the delete stage, the block is truly consensus-completed. While each block needs to go through four stages to be finally identified, in the hot stuff algorithm in the prior art, only the implementation of the process of initial startup and normal operation of the distributed system using the algorithm is provided, but there is no processing method for restarting all the nodes of the distributed system. In an actual situation, especially in a federation chain in a block chain, there is a problem of node restart, and if there is no consideration for node restart, there is an incomplete situation in the engineering process, which eventually results in that the whole block chain system cannot operate normally.
Disclosure of Invention
In view of the above, embodiments of the present invention provide a method and system for using a HotStuff consensus algorithm in a blockchain, which can perform a node restart and a node initial start.
A first aspect of the invention provides a method of using a hot stuff consensus algorithm in a blockchain, comprising a preparation phase, a pre-commit phase, a commit phase and a decision phase; wherein the content of the first and second substances,
the preparation phase comprises: initiating a proposal through a leader node, broadcasting the proposal to a replica node, and generating a prepared certificate; the pre-commit phase includes: the leader node broadcasts the prepared certificate to the replica node to generate a pre-submitted certificate;
the commit phase includes: the leader node broadcasts the pre-submitted certificate to the replica nodes to generate submitted certificates;
the decision phase comprises: the leader node broadcasts the submission certificate to the replica nodes, and all the replica nodes execute the proposal;
when the block is in a pre-submission stage, storing the block into the flow meter in a persistent mode; when the block is in the decision stage, storing the block into a block data table in a persistent mode;
restarting the nodes according to the flow table and the block data table;
and carrying out initial starting of the nodes according to the flow table and the block data table.
Further, the initiating, by the leader node, a proposal and broadcasting the proposal to the replica node to generate a provisioning certificate includes:
determining a leader node in a verifiable random manner;
initiating a proposal through the leader node;
broadcasting the proposal to all replica nodes in a block chain;
the copy node feeds back first signature information to the leader node according to the validity of the proposal;
and packaging the first signature information of all the replica nodes to obtain a prepared certificate.
Further, the leader node broadcasting the preliminary certificate to a replica node, generating a pre-submitted certificate, comprising:
the leader node broadcasts the prepared certificate to all replica nodes;
the duplicate node feeds back second signature information to the leader node according to the validity of the preparation certificate;
and packaging the second signature information of all the replica nodes to obtain a pre-submitted certificate.
Further, the leader node broadcasting the pre-submitted certificate to a replica node, generating a submitted certificate, including:
the leader node broadcasts the pre-submitted certificate to all replica nodes;
the copy node feeds back third signature information to the leader node according to the validity of the pre-submitted certificate;
and packaging the third signature information of all the replica nodes to obtain a submission certificate.
Further, the leader node broadcasts the submission credential to the replica nodes, and all replica nodes execute the proposal, including:
the leader node broadcasts the submission certificate to all replica nodes;
and the replica node determines that the proposal has agreed in the block chain according to the validity of the submitted certificate, and executes the proposal.
Further, the restarting the node according to the flow table and the block data table includes:
reading the information of the block which is newly in the decision stage from the block data table;
reading the information of the corresponding blocks in the pre-submission stage and the submission stage from the flow chart according to the information of the blocks;
generating a blank block to replace the block which is newly in the preparation stage;
and the number of the first and second groups,
the nodes synchronize data based on the blocks of the commit, pre-commit and preparation phases and participate in consensus after completion.
Further, the node performs data synchronization based on the blocks of the commit phase, the pre-commit phase and the prepare phase and participates in the step of consensus after completion, including:
if the block chain has the nodes which are in the consensus, directly synchronizing the latest block in the submission stage, the pre-submission stage and the preparation stage and all the executed block data, and then participating in the consensus process;
if there is no node in the block chain that is being identified, then the block chain is identified directly based on the pre-commit stage, the commit stage, and the prepare stage.
Further, the performing initial start of the node according to the flow table and the block data table includes:
when only the node which is started for the first time exists in the block chain:
generating three creating blocks; the first created block is used as a block of a decision stage, the second created block is used as a block of a submission stage, and the third created block is used as a block of a pre-submission stage; generating a blank block as a block in a preparation stage; according to the three created blocks and the blank block, then executing a step of restarting the node according to the flow table and the block data table;
when a node which is not started for the first time exists in the block chain:
and synchronizing the block data on the non-initial starting node by the initial starting node in the block chain, and then executing the step of restarting the node according to the flow table and the block data table.
In a second aspect, an embodiment of the present invention further provides a system for using a HotStuff consensus algorithm in a blockchain, including:
the preparation module is used for initiating a proposal through the leader node, broadcasting the proposal to the replica node and generating a preparation certificate;
the pre-submission module is used for broadcasting the prepared certificate to the copy node by the leader node to generate a pre-submission certificate;
the submitting module is used for leading the node to broadcast the pre-submitted certificate to the copy node to generate a submitted certificate;
the decision module is used for leading the node to broadcast the submitted certificate to the replica nodes, and all the replica nodes execute the proposal;
when the block is in a pre-submission stage, storing the block into the flow meter in a persistent mode; when the block is in the decision stage, storing the block into a block data table in a persistent mode;
the restarting module is used for restarting the node according to the flow table and the block data table;
and the initial starting module is used for carrying out initial starting on the nodes according to the flow table and the block data table.
In a third aspect, an embodiment of the present invention further provides a system for using a HotStuff consensus algorithm in a blockchain, where the system includes:
at least one processor;
at least one memory for storing at least one program;
when executed by the at least one processor, cause the at least one processor to implement the method.
In a fourth aspect, the present invention also provides a storage medium having stored therein processor-executable instructions, which when executed by a processor, are configured to perform the method.
One or more of the above-described embodiments of the present invention have the following advantages: the embodiment of the invention adds the steps of node initial start and node restart under the process of the HotStuff consensus algorithm, improves the completeness in the engineering process, and perfects the normal operation of the whole block chain system; in addition, the invention is additionally provided with the flow table and the block data table, so that the data integrity in the consensus certification process can be ensured, and the synchronization and the verification of the subsequent node data are facilitated.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.
FIG. 1 is a schematic view of a HotStuff consensus algorithm pipeline;
FIG. 2 is a flow chart of the HotStuff consensus algorithm;
FIG. 3 is a schematic diagram of data persistence in a consensus process;
fig. 4 is a flowchart of the HotStuff consensus node start-up process.
Detailed Description
The invention will be further explained and explained with reference to the drawings and the embodiments in the description. The step numbers in the embodiments of the present invention are set for convenience of illustration only, the order between the steps is not limited at all, and the execution order of each step in the embodiments can be adaptively adjusted according to the understanding of those skilled in the art.
In the consensus process, each node needs to perform subsequent consensus operations by depending on the latest decision block, commit block, pre-commit block, and preparation block, where the four blocks correspond to the four consensus stages, i.e., the decision, commit, pre-commit, and preparation, respectively, and if the embodiment of the present application assumes that n is 3f +1 nodes, the operation steps performed in the four stages in the consensus process are as follows, referring to fig. 1 and 2:
s1: preparatory phase (Prepare): selecting a Leader node (Leader) according to a verifiable random mode, wherein the Leader is responsible for proposing a Proposal (Propusal) and broadcasting the Propusal to all other copy nodes (Replica); after receiving the Proposal, if the validity is confirmed, other copy nodes (Replica) use a private key of the Replica to sign the Proposal and send the Proposal to the Leader, wherein one signature (namely, the first signature information) represents one vote, and if the Proposal is confirmed to be illegal, the signature is ignored; after receiving the signatures of at least n-f nodes aiming at the Proposal proposed in the Prepare, the Leader packs the n-f signatures into a Quorum Certificate (Quorum Certificate), referred to as QC for short, and the QC generated in the Prepare stage is also referred to as a preparatory Certificate (PrepareQC);
s2: pre-commit phase (Pre-commit): the Leader broadcasts the prepareQC to all the Replicas, and after the Replicas receive the prepareQC, if the PrepareQC is confirmed to be legal, the PrepareQC is signed by using a private key and the signature is sent to the Leader. After receiving at least n-f signatures for PrepareQC (i.e., the second signature information), the Leader packages the signatures into a new QC, which is also called a pre-commit QC (precommit QC);
s3: commit phase (Commit): the Leader broadcasts PreCommitQC to all Replicas, after the Replica receives the PreCommitQC, if the PreCommitQC is confirmed to be legal, the PreCommitQC is signed by using a private key, and the signature is sent to the Leader. After receiving at least n-f signatures for PreCommitQC (i.e. third signature information), the Leader packages the signatures into a new QC, which is also called CommitQC at this stage;
s4: decision stage (Decide): the Leader broadcasts CommitQC to all Replicas, which, after receiving CommitQC, if validated, indicates that the Proposal in the Prepare phase has agreed to the consensus and executes the transaction in the Proposal.
The consensus process is further improved in a 'pipeline' mode in the HotStuff consensus algorithm, and the improvement mode is as follows:
1. each of the plurality of Propusals is assigned a previous Propusal, each of the plurality of Propusals corresponds to a block in the block chain, and each of the plurality of blocks is assigned a parent block;
2. the whole consensus process consists of continuous rounds, each round doing the same action: the Leader proposes a Proposal, packs and broadcasts the Proposal and QC generated in the previous round to the Replica, the Replica node signs the Proposal by a private key after confirming the legality of the Prousal and the QC, the Leader collects at least n-f signatures and packs the signatures into a general certificate (Generic QC), and the general certificate is the QC in the next round of Leader broadcasting;
3. logically, the QC generated in each round is PrepareQC of the previous round of the propofol, and is also precompimittqc of the previous round of the propofol, and is also commit QC of the previous round of the propofol, and the pointing relationship is specified by the previous propofol specified in the propofol, so whether and when the commit QC of one of the propofol in the logic is generated can be determined by backtracking, and if the Replica receives a commit QC corresponding to the propofol in the logic, the propofol is executed;
referring to fig. 1 and 2, it can be seen in the design of "pipeline" that whether a block (i.e. the propofol in the context of a block chain) has achieved consensus needs to rely on the genericqcs of the following two blocks and their respective two blocks to prove that these blocks need to be properly stored in order to ensure that the node can operate properly at the initial startup or restart, as follows:
1. when a block is in the Pre-commit stage, referring to fig. 3, the block is persisted to a "flow meter", so-called flow meter, where the block in the flow meter is not necessarily eventually determined, but is the basis for subsequent consensus by the node;
2. when a block is in a delete stage, persisting the block into a 'block data table', wherein data in the data table indicates that deterministic consistency is achieved; the block data table stores all the blocks themselves that have achieved consensus.
3. When the node is restarted, the block data of the latest defect is read from the block data table, and then the adjacent block data in the Pre-Commit stage and the Commit stage are read from the pipeline table according to the block data, and an empty block is generated to replace the latest block in the Prepare stage. At this time, the node may face two situations:
a) the other nodes which are commonly known exist in the system, at this time, the restarting node only needs to synchronize all the block data of the node which is already deleted and the block data of the current prefix, Pre-Commit and Commit of the other nodes, because the block which is only in the prefix stage in the HotStuff can be easily discarded, the 'empty block' does not influence the subsequent common knowledge of the restarting node;
b) after the synchronization of the states is completed, the states of all nodes are the same except for the block of the Prepare, but according to the consensus process algorithm of the HotStuff, the Leader node only proposes a new block based on the block in the Pre-commit stage and then performs subsequent consensus, so that the 'empty block' does not influence the subsequent consensus of the restarted node.
4. When a node is initially started, referring to fig. 4, there are also two cases:
a) the system is a node which is started for the first time, the system appoints to generate three created blocks (including a first created block, a second created block and a third created block) at the time, the three created blocks are determined in a development stage by using a mode written in codes, the legality is determined without 'voting' of the node, the first created block serves as a block which is newly determined, the second created block and the third created block serve as blocks in a Commit stage and a Pre-Commit stage respectively, then the node is regenerated into an empty block to serve as a block in a Prepare stage, the state of the node can be consistent with that of a restart node in the node 3 at the time, and subsequent processing logic is also consistent;
b) if the system has a node which is not started for the first time, the node which is started for the first time directly synchronizes all the block data of the node which has been divided with the block data of Commit, Pre-Commit and Prepare, after the synchronization is completed, the state of the node is consistent with the restart of the node in 3, and the subsequent processing logic is consistent.
The embodiment of the invention also provides a system for using the HotStuff consensus algorithm in the block chain, which comprises the following steps:
the preparation module is used for initiating a proposal through the leader node, broadcasting the proposal to the replica node and generating a preparation certificate;
the pre-submission module is used for leading the node to broadcast the prepared certificate to the replica node and generating a pre-submission certificate;
the submitting module is used for leading the node to broadcast the pre-submitted certificate to the replica node and generating a submitted certificate;
a decision module for the leader node to broadcast the submission certificate to the replica nodes, and for all replica nodes to execute the proposal;
when the block is in a pre-submission stage, storing the block into the flow meter in a persistent mode; when the block is in the decision stage, storing the block into a block data table in a persistent mode;
the restarting module is used for restarting the node according to the flow table and the block data table;
and the initial starting module is used for carrying out initial starting on the nodes according to the flow table and the block data table.
The embodiment of the invention also provides a system for using the HotStuff consensus algorithm in the block chain, which comprises the following steps:
at least one processor;
at least one memory for storing at least one program;
when executed by the at least one processor, cause the at least one processor to implement the method.
Embodiments of the present invention also provide a storage medium having stored therein processor-executable instructions, which when executed by a processor, are configured to perform the method.
In conclusion, the invention perfects the engineering realization of the HotStuff consensus algorithm under the block chain from two aspects: one is to improve the processing logic of the initial start of the node, the restart of the node and the normal participation of the node in consensus, so that the HotStuff algorithm can be really used by landing; on the other hand, due to the pipeline design of the HotStuff consensus algorithm, whether a block achieves consensus or not needs to be proved by subsequent block data, the integrity of the latest consensus of Commit blocks is guaranteed by additionally designing a flow meter, and meanwhile, the block data in the block data table are all known and have no conflict bifurcation, so that the subsequent node data synchronization and verification are facilitated.
In alternative embodiments, the functions/acts noted in the block diagrams may occur out of the order noted in the operational illustrations. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved. Furthermore, the embodiments presented and described in the flow charts of the present invention are provided by way of example in order to provide a more thorough understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed and in which sub-operations described as part of larger operations are performed independently.
Furthermore, although the present invention is described in the context of functional modules, it should be understood that, unless otherwise stated to the contrary, one or more of the described functions and/or features may be integrated in a single physical device and/or software module, or one or more functions and/or features may be implemented in a separate physical device or software module. It will also be appreciated that a detailed discussion of the actual implementation of each module is not necessary for an understanding of the present invention. Rather, the actual implementation of the various functional modules in the apparatus disclosed herein will be understood within the ordinary skill of an engineer given the nature, function, and interrelationships of the modules. Accordingly, those skilled in the art can, using ordinary skill, practice the invention as set forth in the claims without undue experimentation. It is also to be understood that the specific concepts disclosed are merely illustrative of and not intended to limit the scope of the invention, which is to be determined from the appended claims along with their full scope of equivalents.
In the description herein, references to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., mean that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the invention. In this specification, the schematic representations of the terms used above do not necessarily refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.
While embodiments of the invention have been shown and described, it will be understood by those of ordinary skill in the art that: various changes, modifications, substitutions and alterations can be made to the embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.
While the preferred embodiments of the present invention have been illustrated and described, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims.
Claims (7)
1. A method for using a HotStuff consensus algorithm in a blockchain is characterized by comprising a preparation phase, a pre-submission phase, a submission phase and a decision phase; wherein the content of the first and second substances,
the preparation phase comprises: initiating a proposal through a leader node, broadcasting the proposal to a replica node, and generating a prepared certificate;
the pre-commit phase includes: the leader node broadcasts the prepared certificate to the replica node to generate a pre-submitted certificate;
the commit phase includes: the leader node broadcasts the pre-submitted certificate to the replica nodes to generate submitted certificates;
the decision phase comprises: the leader node broadcasts the submission certificate to the replica nodes, and all the replica nodes execute the proposal;
when the block is in a pre-submission stage, storing the block into the flow meter in a persistent mode; when the block is in the decision stage, storing the block into a block data table in a persistent mode;
restarting the nodes according to the flow table and the block data table;
according to the flow table and the block data table, performing initial starting of the nodes;
the restarting the node according to the flow table and the block data table comprises:
reading the information of the block which is at the decision stage from the block data table;
reading the information of the blocks of the corresponding pre-submission stage and submission stage from the flow table according to the information of the blocks;
generating a blank block to replace the block which is newly in the preparation stage;
and the number of the first and second groups,
the nodes perform data synchronization based on the blocks in the submission stage, the pre-submission stage and the preparation stage and participate in consensus after completion;
the node performs data synchronization based on the blocks in the commit stage, the pre-commit stage and the prepare stage and participates in the step of consensus after completion, and the method comprises the following steps:
if the block chain has the nodes which are in the consensus, directly synchronizing the latest submission stage, the pre-submission stage and the preparation stage blocks and all executed block data, and then participating in the consensus process;
if no node which is in common identification exists in the block chain, common identification is directly carried out on the blocks in the pre-submission stage, the submission stage and the preparation stage;
the performing initial start of the node according to the flow table and the block data table includes:
when only the node started for the first time exists in the block chain:
generating three creating blocks; the first generation block is used as a block of a decision stage, the second generation block is used as a block of a submission stage, and the third generation block is used as a block of a pre-submission stage; generating a blank block as a block in a preparation stage; according to the three created blocks and the blank block, then executing a step of restarting the node according to the flow table and the block data table;
when a node which is not started for the first time exists in the block chain:
and synchronizing the block data on the non-initial starting node by the initial starting node in the block chain, and then executing the step of restarting the node according to the flow table and the block data table.
2. The method for using the hot stuff consensus algorithm in a blockchain according to claim 1, wherein the generating of the preliminary certificate by the leader node initiating the proposal and broadcasting the proposal to the replica nodes comprises:
determining a leader node in a verifiable random manner;
initiating a proposal through the leader node;
broadcasting the proposal to all replica nodes in a block chain;
the replica node feeds back first signature information to the leader node according to the validity of the proposal;
and packaging the first signature information of all the replica nodes to obtain a prepared certificate.
3. The method of claim 1, wherein the leader node broadcasts the preliminary certificate to replica nodes to generate pre-submitted certificates, comprising:
the leader node broadcasts the prepared certificate to all replica nodes;
the duplicate node feeds back second signature information to the leader node according to the validity of the preparation certificate;
and packaging the second signature information of all the replica nodes to obtain a pre-submitted certificate.
4. The method of claim 1, wherein the leader node broadcasts the pre-submitted certificate to replica nodes to generate submitted certificates, comprising:
the leader node broadcasts the pre-submitted certificate to all replica nodes;
the replica node feeds back third signature information to the leader node according to the validity of the pre-submitted certificate;
and packaging the third signature information of all the replica nodes to obtain a submission certificate.
5. A method for using the HotStuff consensus algorithm in a blockchain as claimed in claim 1, wherein the leader node broadcasts the commit certificate to duplicate nodes, the proposal being performed by all duplicate nodes comprising:
the leader node broadcasts the submission certificate to all replica nodes;
and the replica node determines that the proposal has agreed in the block chain according to the legality of the submitted certificate, and executes the proposal.
6. A system for using the HotStuff consensus algorithm in a blockchain, comprising:
the preparation module is used for initiating a proposal through the leader node, broadcasting the proposal to the replica node and generating a preparation certificate;
the pre-submission module is used for leading the node to broadcast the prepared certificate to the replica node and generating a pre-submission certificate;
the submitting module is used for leading the node to broadcast the pre-submitted certificate to the replica node and generating a submitted certificate;
a decision module for the leader node to broadcast the submission certificate to the replica nodes, and for all replica nodes to execute the proposal;
when the block is in a pre-submission stage, storing the block into the flow meter in a persistent mode; when the block is in the decision stage, storing the block into a block data table in a persistent mode;
the restarting module is used for restarting the node according to the flow table and the block data table;
the initial starting module is used for carrying out initial starting on the nodes according to the flow table and the block data table;
the restart module is specifically configured to: reading the information of the block which is newly in the decision stage from the block data table; reading the information of the corresponding blocks in the pre-submission stage and the submission stage from the flow chart according to the information of the blocks; generating a blank block to replace the block which is newly in the preparation stage; the nodes perform data synchronization based on the blocks in the submission stage, the pre-submission stage and the preparation stage and participate in consensus after completion;
if the block chain has the nodes which are commonly identified, directly synchronizing the latest block in the submission stage, the pre-submission stage and the preparation stage and all the executed block data, and then participating in the common identification process;
if no node which is in the consensus exists in the block chain, the consensus is started directly on the basis of the blocks in the pre-submission stage, the submission stage and the preparation stage;
the primary starting module is specifically configured to: when only the node started for the first time exists in the block chain: generating three creating blocks; the first created block is used as a block of a decision stage, the second created block is used as a block of a submission stage, and the third created block is used as a block of a pre-submission stage; generating a blank block as a block of a preparation stage; according to the three created blocks and the blank block, then executing a step of restarting the node according to the flow table and the block data table; when a node which is not started for the first time exists in the block chain: and synchronizing the block data on the non-primary starting node by the primary starting node in the block chain, and then executing the step of restarting the node according to the flow table and the block data table.
7. A system for using the HotStuff consensus algorithm in a blockchain, comprising:
at least one processor;
at least one memory for storing at least one program;
when executed by the at least one processor, cause the at least one processor to implement the method of any one of claims 1-5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911414474.XA CN111147261B (en) | 2019-12-31 | 2019-12-31 | Method and system for using HotStuff consensus algorithm in block chain |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911414474.XA CN111147261B (en) | 2019-12-31 | 2019-12-31 | Method and system for using HotStuff consensus algorithm in block chain |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111147261A CN111147261A (en) | 2020-05-12 |
| CN111147261B true CN111147261B (en) | 2022-07-12 |
Family
ID=70522644
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911414474.XA Active CN111147261B (en) | 2019-12-31 | 2019-12-31 | Method and system for using HotStuff consensus algorithm in block chain |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111147261B (en) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112182113A (en) * | 2020-10-23 | 2021-01-05 | 网易（杭州）网络有限公司 | Block chain consensus method, system, electronic device and storage medium |
| CN112991067B (en) * | 2021-04-28 | 2021-08-03 | 支付宝(杭州)信息技术有限公司 | Block chain consensus method, device and system |
| CN112887436B (en) * | 2021-04-28 | 2021-08-03 | 支付宝(杭州)信息技术有限公司 | Consensus method, consensus node and block chain system of pipeline mode |
| CN114047899B (en) * | 2022-01-12 | 2022-03-18 | 南京金宁汇科技有限公司 | View synchronization method and system of block chain |
| CN115052017A (en) * | 2022-06-14 | 2022-09-13 | 上海交通大学 | Layered consensus method and system based on dynamic reputation mechanism in Internet of vehicles environment |
| CN115186035B (en) * | 2022-09-13 | 2022-11-22 | 腾讯科技（深圳）有限公司 | Block processing method, related system, storage medium and server |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107368507A (en) * | 2017-03-28 | 2017-11-21 | 阿里巴巴集团控股有限公司 | A kind of common recognition method and device based on block chain |
| CN108182635A (en) * | 2017-12-18 | 2018-06-19 | 深圳前海微众银行股份有限公司 | Block chain common recognition method, system and computer readable storage medium |
| CN108667614A (en) * | 2018-04-19 | 2018-10-16 | 上海分布信息科技有限公司 | A kind of Byzantine failure tolerance method and its realize system |
| CN110032436A (en) * | 2019-04-04 | 2019-07-19 | 杭州秘猿科技有限公司 | Support the block chain of pause and starting common recognition method, system and electronic equipment |
| CN110618841A (en) * | 2019-09-10 | 2019-12-27 | 杭州秘猿科技有限公司 | Internal loose coupling consensus method and system and electronic equipment |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8627135B2 (en) * | 2010-08-14 | 2014-01-07 | Teradata Us, Inc. | Management of a distributed computing system through replication of write ahead logs |
-
2019
- 2019-12-31 CN CN201911414474.XA patent/CN111147261B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107368507A (en) * | 2017-03-28 | 2017-11-21 | 阿里巴巴集团控股有限公司 | A kind of common recognition method and device based on block chain |
| CN108182635A (en) * | 2017-12-18 | 2018-06-19 | 深圳前海微众银行股份有限公司 | Block chain common recognition method, system and computer readable storage medium |
| CN108667614A (en) * | 2018-04-19 | 2018-10-16 | 上海分布信息科技有限公司 | A kind of Byzantine failure tolerance method and its realize system |
| CN110032436A (en) * | 2019-04-04 | 2019-07-19 | 杭州秘猿科技有限公司 | Support the block chain of pause and starting common recognition method, system and electronic equipment |
| CN110618841A (en) * | 2019-09-10 | 2019-12-27 | 杭州秘猿科技有限公司 | Internal loose coupling consensus method and system and electronic equipment |
Non-Patent Citations (1)
| Title |
|---|
| HotStuff: BFT Consensus with Linearity and Responsiveness;Maofan Yin等;《In 2019 ACM Symposium on Principles of Distributed Computing (PODC 19)》;20190802;第347-356页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111147261A (en) | 2020-05-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111147261B (en) | Method and system for using HotStuff consensus algorithm in block chain | |
| CN114401150B (en) | Method for adding node in blockchain network and blockchain system | |
| CN110730204B (en) | Method for deleting nodes in block chain network and block chain system | |
| Chan et al. | Streamlet: Textbook streamlined blockchains | |
| CN108683539B (en) | Block chain network management method, block chain network management device, block chain network management medium and electronic equipment | |
| CN110399424B (en) | Block generation method, block generation device, block chain node and storage medium | |
| CN110417502B (en) | Block chain link point clock consensus method and device | |
| CN109981565B (en) | Block chain platform based on Meta-BFT consensus mechanism and implementation method | |
| Abraham et al. | Efficient synchronous byzantine consensus | |
| Yanovich et al. | Exonum: Byzantine fault tolerant protocol for blockchains | |
| CN113630257B (en) | Consensus method, block chain system and consensus node | |
| CN113610531B (en) | Consensus method, block chain system and consensus node | |
| CN114584312B (en) | Consensus method, block chain system and consensus node | |
| CN113132401B (en) | Block chain-based data processing method and device | |
| CN113630258B (en) | Consensus method, block chain system and consensus node | |
| CN113761071B (en) | Consensus method, block chain system and consensus node | |
| CN112348518B (en) | Block chain transaction certification method and device | |
| Bentov et al. | The Sleepy Model of Consensus. | |
| Saltini | IBFT liveness analysis | |
| CN113630259B (en) | Consensus method, block chain system and consensus node | |
| CN115225639A (en) | Changing method and device of consensus trusted cluster, computer equipment and medium | |
| CN114936253A (en) | Block chain consensus method and device, electronic equipment and storage medium | |
| Lewis-Pye et al. | Fever: Optimal responsive view synchronisation | |
| CN111061813B (en) | Method, apparatus and computing device for data synchronization in blockchain network | |
| CN113254526A (en) | Block chain consensus method, device and 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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |