CN114050904A - Consensus system and method based on two-level leader node fragmentation structure - Google Patents
Consensus system and method based on two-level leader node fragmentation structure Download PDFInfo
- Publication number
- CN114050904A CN114050904A CN202210024153.4A CN202210024153A CN114050904A CN 114050904 A CN114050904 A CN 114050904A CN 202210024153 A CN202210024153 A CN 202210024153A CN 114050904 A CN114050904 A CN 114050904A
- Authority
- CN
- China
- Prior art keywords
- leader node
- nodes
- node
- message
- consensus
- 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
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/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/3236—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 using cryptographic hash functions
- H04L9/3239—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 using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
-
- 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
- H04L9/3255—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 using group based signatures, e.g. ring or threshold signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
Abstract
The invention discloses a consensus system based on a two-level leader node fragmentation structure, which comprises: the block only comprises two layers of leader nodes in a generation period of the same block in a block chain, wherein the two layers of leader nodes comprise a strong leader node and a plurality of weak leader nodes; the system comprises a plurality of groups of different fragments and a weak leader node, wherein each group of fragments is obtained by dividing all nodes and comprises a plurality of leaf nodes and one weak leader node; and the data consensus module is used for realizing data consensus among the fragments. The strong leader node collects the transaction and proposes a new block, the weak leader node only needs to forward the message and is responsible for message communication in the fragments, the multi-level message confirmation mechanism is used for realizing the transmission and the consensus of the transaction information of the block, the network communication complexity between the nodes is only O (n), and the high consensus performance and the expandability are realized even if the number of the nodes participating in the consensus is increased.
Description
Technical Field
The invention belongs to the technical field of block chains, and particularly relates to a consensus system and method based on a two-level leader node fragmentation structure.
Background
Consensus algorithm (Consensus algorithm) refers to an algorithm that agrees the results of task execution by all participants in a multi-party collaborative environment. The consensus algorithm is mostly applied to ensuring data consistency of a distributed system, and the introduction of the consensus algorithm into a block chain is the earliest to solve the problem of block collision possibly occurring when a new transaction block is added into a hash chain table, namely the chain table bifurcation problem caused by adding a plurality of blocks into the hash chain table by different block creators at the same time.
To add a block to a blockchain system, it needs to pass through the consensus of each node of the blockchain, and the non-tamper property of the blockchain is also ensured by the consensus algorithm of the blockchain. The block chain is used as a decentralized distributed system, decision rights are dispersed in all nodes, trust is not needed among the nodes, and therefore, in order to achieve the purpose of common accounting, a consensus algorithm is needed to enable all the nodes to achieve the consistency of the block data effectiveness. The consensus algorithm, as a key technology in the blockchain, directly affects the transaction processing capability, expandability and security of the blockchain.
Current consensus algorithms include:
(1) practical Byzantine fault-tolerant algorithm
The Practical Byzantine Fault-tolerant algorithm (PBFT) is proposed to solve the problem of the Byzantine consistency, and although there are other commonly used algorithms for solving the problem of the Byzantine consistency, such as HQ, Zyzzyva, etc., the block chain technology mainly uses the Practical Byzantine Fault-tolerant algorithm to solve the problem of the data consistency in the block chain, and the Practical Byzantine Fault-tolerant algorithm operation diagram is shown in fig. 1.
The practical Byzantine fault-tolerant algorithm allows f = (n-1)/3 nodes to have errors on the premise of ensuring the activity (liveness) and the safety (safety) of the algorithm, wherein f is the number of the error nodes, and n is the total number of the nodes. Security refers to that the copy replication service satisfies linear consistency, and the distributed system performs operations atomically like a centralized system, i.e. all clients eventually receive replies to their requests as long as the number of failed copies does not exceed (n-1)/3 and the delay (t) does not increase indefinitely. An error occurs in one node, Replica 3, as shown in fig. 1. In the algorithm, nodes are divided into a main node and a replica node, and the relationship between the main node and the replica node is changed only when view change is carried out, so that the nodes are not equal to each other. In the figure, the Replica 0 is a master node, the Replica 1, the Replica 2 and the Replica 3 are all Replica nodes, and the Request indicates a Request sent by a client.
The practical Byzantine fault-tolerant algorithm removes two stages of requests and responses, and mainly comprises three stages: a pre-preparation phase, a preparation phase and a confirmation phase.
In the algorithm, the client only sends the request information to the main node, and the replica node cannot receive the corresponding information, so that the loyalty of the main node is relied on in the whole consistency process. In the response phase, both the primary node and the replica node respond, and the client selects a plurality of response results to determine the final result of the request. The pre-preparation stage is that the main node numbers the request received from the client and broadcasts the calculated data to each replica node; and the replica node judges the information such as message signature, abstract, view number and the like according to the information sent by the main node, and finally broadcasts the judgment result of the node to all other nodes. Since the phase is a consistency process initiated by the master node, the master node does not send decision information about the phase, and only the replica node broadcasts the decision information. The preparation phase is that all nodes broadcast the preparation message of the node after receiving the pre-preparation message, and then the nodes verify the signature of the preparation message and verify whether the view number is valid or not after receiving the preparation message. The preparation phase is complete after receiving 2f identical pre-preparation and preparation messages sent out from different nodes. After the preparation phase is completed, the confirmation phase firstly verifies the received information, and if the received information passes the verification, the confirmation phase broadcasts the confirmation information to other nodes and then enters the confirmation phase. After the node enters the confirmation stage, when receiving confirmation messages sent by other nodes, judging the message signature, verifying the validity of the view to which the message belongs, after receiving 2f +1 confirmation messages, finishing the confirmation stage, and feeding back the confirmation messages to the client, thereby finishing the whole algorithm process.
(2) HotStuff consensus algorithm
As shown in fig. 2, the HotStuff proposes a BFT-like consensus protocol for three-phase voting, which implements security, activity, and responsiveness characteristics. The message verification complexity of o (n) is achieved by introducing a threshold signature during the voting process. Hotstuff summarizes and contrasts the current mainstream BFT consensus protocol, and a mode for realizing the pipeline BFT consensus based on the classical BFT consensus is constructed.
The HotStuff is a consensus protocol based on views, wherein the views represent a consensus unit, and the consensus process is composed of views one after another. In one view, there is a certain leader to dominate the consensus agreement, and the consensus is reached through three-stage voting, and then the view is switched to the next view to continue the consensus. If an exception condition is encountered, a view time-out fails to agree, and a switch is made to the next view to continue agreeing. According to the consensus protocol of the Basic HotStuff Basic version, the confirmation of one block needs to enter the consensus of the next block after the three-stage voting is achieved. The pipeline HotStuff is a consensus protocol of the pipeline, and the consensus efficiency is improved. The Hot-Stuff adopts Linear View Change (LVC) to reduce the communication complexity in view change. In PBFT, when a view transition occurs, the new leader needs to broadcast the current stable checkpoint and provide commitment credentials for 2f +1 nodes, proving the legitimacy of the checkpoint with a communication complexity of O (n 4). Whereas in LVCs, the new leader need only broadcast one commitment credential. Other nodes determine the validity of the new leader only if they receive a checkpoint higher than the local stable checkpoint. In this case, if the new leader hides the higher checkpoint, the security of the protocol is not affected, but only penalized. By integrating the LVC and threshold signature technology, the final communication complexity of each round of Hot-Stuff is O (n2), and the HotStuff greatly improves the efficiency of the distributed consistency algorithm by utilizing the technologies of threshold signature, parallel pipeline processing, linear view conversion and the like.
However, the existing consensus algorithm has the following technical problems:
in traditional distributed system consensus algorithms such as PBFT and endrmint, consensus among nodes often needs to be achieved through n-n broadcasting and multiple message handshaking among the nodes, and as the number of nodes increases, the number of communication times among the nodes increases exponentially. In addition, data fragmentation is often not considered in the consensus among the nodes, and how to design a block chain formula algorithm supporting fragmentation makes the algorithm have better fragmentation consistency and expandability become a problem to be solved urgently.
The blockchain sharding technology was originally proposed in the field of traditional databases and is mainly used for optimization of large commercial databases. The concept is to divide the data in the large database into a plurality of data fragments (shards), and then store the data fragments in different servers respectively, so as to reduce the data access pressure of each server and improve the performance of the whole database system. In short, divide and conquer is the core idea of the slicing technique.
The idea of applying the fragmentation technique to a blockchain network is to divide the blockchain network having many nodes into several sub-networks, each sub-network comprising a part of the nodes, i.e. a "shard" (shard). Meanwhile, the transactions in the network are also divided into different segments to be processed, so that each node only needs to process a small part of the transmitted transactions, and different nodes can process the transactions in parallel, so that the concurrence of transaction processing and verification can be increased, and the throughput of the whole network is improved.
The fragmentation technology can be divided into three types according to different fragmentation mechanisms: network sharding (network sharding), transaction sharding (transaction sharding), state sharding (state sharding).
Although the fragmentation technology is one of the mainstream technologies used for solving the efficiency problem and the scalability problem in the current block chain, due to the lack of a mature consensus mechanism, the problems of lack of trust in the data interaction process, difficulty in interaction, poor data consistency and the like often exist among different fragments.
It is therefore desirable to devise a consensus system and method that is specific to a particular sharded structure.
Disclosure of Invention
The invention aims to provide a consensus system and a consensus method based on a two-layer leader node fragment structure, wherein a strong leader node collects a deal and proposes a new block through a threshold signature and the two-layer leader node structure, and a weak leader node only needs to forward messages and is responsible for message communication inside fragments, so that n-n message broadcasting among nodes is avoided, block deal information transmission and consensus are realized through a multi-layer message confirmation mechanism, the network communication complexity of the system is linearly increased, the network communication complexity among the nodes is only O (n), and even if the number of the nodes participating in consensus is increased, the consensus performance and expandability are high.
The invention provides a consensus system based on a two-level leader node fragment structure on one hand, which comprises:
the system comprises a block chain, wherein the same block in the block chain comprises leaf nodes and only two-level leader nodes in a generation period of the same block, the two-level leader nodes comprise a strong leader node and a plurality of weak leader nodes, the strong leader node collects transactions and proposes new blocks, and the weak leader nodes only need to forward messages of the strong leader node and are responsible for message communication in the segments;
the fragments are obtained by dividing all nodes, each group of fragments comprises a plurality of leaf nodes and one weak leader node, the nodes contained in the fragments of different groups do not have intersection, and the number of the nodes in each group of fragments is greater than or equal to the ratio of the number of all the nodes to the number of the groups; and
and the data consensus module is used for data consensus among the fragments.
Preferably, the strong leader node directly communicates with the weak leader node to realize interaction with different segments, and the strong leader node collects and verifies a partial threshold signature of a message from the weak leader node and collects intra-segment transaction information sent by the weak leader node to synthesize a block.
Preferably, the weak leader node communicates with the leaf nodes within the segment, collects the trades of the leaf nodes within the segment, and forwards the message sent by the strong leader node to the leaf nodes.
The second aspect of the invention provides a consensus method based on a two-level leader node fragment structure, which comprises the following steps:
and 4, a decision stage, namely after the weak leader node receives the threshold signature message from the strong leader node, performing second verification on the threshold signature, the height and the view, processing the transaction information on the block chain when the second verification is passed, and otherwise, returning consensus failure information.
Preferably, the step 2 comprises:
step 21, after receiving the preparation message, the weak leader node verifies the signature of the message by using a public key, judges whether the proposed block height and view are correct or not, and continues to step 22 if the verification is passed;
step 22, the weak leader node broadcasts the preparation message to the node in the segment where the weak leader node is located;
step 23, the leaf node receives the preparation message and verifies the height and the view;
step 24, if said height and said view pass said verification, said each leaf node sending a plurality of pre-commit messages to said weak leader node, respectively;
and 25, the weak leader node collects a plurality of transaction messages sent by a plurality of nodes in the segment, performs partial threshold signature on the transaction messages, synthesizes a pre-submission message corresponding to the segment, and sends the synthesized pre-submission message to the strong leader node.
Preferably, the step 3 comprises:
step 31, the strong leader node collects the pre-submission messages sent by the weak leader node set in all the segments, performs first verification on the threshold signature, the height and the view, and judges whether to generate a new block of the height and the view; if the first verification is passed, the pre-submitted message is considered to be valid, otherwise, the pre-submitted message is invalid;
step 32, for said valid pre-submitted messages, in the case where said strong leader node receives a first predetermined number of said pre-submitted messages and at least a second predetermined number of said leaf nodes agree to generate a new block containing predetermined trade information at said altitude and said view, said strong leader node synthesizes and broadcasts a threshold signature message;
and step 33, the strong leader node broadcasts the threshold signature message to the weak leader node set participating in the consensus.
Preferably, the first predetermined value is determined by a difference between the total number of nodes and the number of error nodes, and the second predetermined value is obtained by adding one to the number of error nodes.
Preferably, the step 4 comprises:
(1) when the verification of the threshold signature is passed and the verification of the height and the view is passed, the weak leader node forwards a threshold signature message to leaf nodes in the sub-slices, the leaf nodes reset the node message, wait for a timer, change the self-consensus state, execute corresponding trading in a trading pool, and update the block height, the view and the block chain structure of the leaf nodes;
(2) if the height and the view are verified but the threshold signature is verified, the leaf node needs to compare the height h of the leaf node with the height h of the leaf nodej ’Height h from the master nodei ’The size of (2):
a）hj ’= hi ’illustrating leaf node NjRequesting and Strong leader node NiGenerating blocks of different transactions at the same height, leaf node NjDeleting transaction Trans in transaction buffer pooljAnd synchronously trading Trans from the strong leader nodei；
b）hj ’< hi ’Explanation and Strong leader node NiIn contrast, the deletion is from height hj ’To a height hi ’The block information of (2) is required to download synchronous new block information from the main node and clear the point NjA transaction buffer pool.
A third aspect of the invention provides an electronic device comprising a processor and a communication circuit, the processor being connected to the communication circuit and configured to execute instructions to implement the method according to the second aspect.
A fourth aspect of the invention provides a computer readable storage medium storing a plurality of instructions readable by a processor and performing the method of the second aspect.
The block chain-based time hybrid queue fragmentation system, the block chain-based time hybrid queue fragmentation method and the electronic equipment have the following beneficial effects:
through the two-level leader node structure, the strong leader node fragments the nodes according to the communication time queue, the local optimal time communication efficiency in the fragments is realized, and the message transmission speed between the nodes is improved. The strong leader node is responsible for collecting transactions and proposing a new block, the weak leader node is responsible for receiving the message of the strong leader node and forwarding the message to the fragments, the data consistency is guaranteed, meanwhile, the bandwidth and the CPU computing performance of the strong leader node and the weak leader node are fully utilized, and the expandability of the system is improved.
Drawings
FIG. 1 is a diagram of a practical Byzantine fault tolerance algorithm PBFT operation according to the prior art;
FIG. 2 is a three-stage flow diagram of Basic HotStuff according to the prior art;
fig. 3 is a flowchart of a consensus method based on a two-level leader node sharding structure according to a preferred embodiment of the present invention.
Fig. 4 is a configuration diagram of an electronic apparatus according to a preferred embodiment of the present invention.
Detailed Description
The following detailed description of embodiments of the present invention is provided in connection with the accompanying drawings and examples. The following examples are intended to illustrate the invention but are not intended to limit the scope of the invention.
Example one
The embodiment provides a consensus system based on a two-level leader node fragmentation structure, which includes:
the system comprises a block chain, wherein the same block in the block chain comprises leaf nodes and only two-level leader nodes in a generation period of the same block, the two-level leader nodes comprise a strong leader node and a plurality of weak leader nodes, the strong leader node collects transactions and proposes new blocks, and the weak leader nodes only need to forward messages of the strong leader node and are responsible for message communication in the segments;
the fragments are obtained by dividing all nodes, each group of fragments comprises a plurality of leaf nodes and one weak leader node, the nodes contained in the fragments of different groups do not have intersection, and the number of the nodes in each group of fragments is greater than or equal to the ratio of the number of all the nodes to the number of the groups; and
and the data consensus module is used for data consensus among the fragments.
In a preferred embodiment, the strong leader node communicates directly with the weak leader node to achieve interaction with different segments, collects and verifies partial threshold signatures of messages from the weak leader node, and collects intra-segment transaction information sent by the weak leader node to synthesize a block.
In a preferred embodiment, the weak leader node communicates with the leaf nodes within the tile, collects the trades of the leaf nodes within the tile, and forwards the message sent by the strong leader node to the leaf nodes.
Example two
As shown in fig. 3, this embodiment provides a consensus method based on a two-level leader node fragment structure, which includes four stages:
stage one, preparation stage (Prepare Phase): the strong leader node sends a preparation message to other weak leader nodes participating in consensus, wherein the preparation message comprises proposed block height and view, and the strong leader node signs the preparation message by using a private key after binary serialization of the message; (ii) a
In this embodiment, assume node NiIs proposed to be of height hi ’View is vi ’The system comprises k different fragments, and the weak leader node set of the fragments is represented as<W1,W2,…,Wk>Suppose a weak leader node W1The inside of the segment contains<L1,L2,L3>Three leaf nodes. Strong leader node NiSending Prepare to other weak leader nodes participating in consensusiAnd preparing a message, requesting the weak leader node to forward to leaf nodes in the sub-slices and collecting transaction information in the leaf nodes, wherein the preparing message is represented as:
Preparei={Prepare,Sigi(vi ’,hi ’)}
Prepareiinformation including proposed block height hi ’And view vi ’After the strong leader node performs binary serialization on the message, the strong leader node uses the private key SKiThe message is signed.
Phase two, the pre-commit Phase (PreCommit Phase), includes:
step 21, after receiving the preparation message, the weak leader node verifies the signature of the message by using a public key, judges whether the proposed block height and view are correct, and enters the pre-submission stage if the verification is passed;
in this embodiment, the weak leader node<W1,W2,…,Wk>Receipt of PrepareiAfter preparing the message, the public key PK is usediVerify the signature of the message and determine the proposed block height hi ’And view vi ’If the verification is correct, the PreCommit phase is entered.
Step 22, the weak leader node broadcasts the preparation message to the node in the segment where the weak leader node is located;
with node W1The weak leader node W is explained by taking the fragment as an example1To the node in the segment where the node is<L1,L2,L3>Broadcasting PrepareiA message is prepared.
Step 23, the leaf node receives the preparation message and verifies the height and the view;
in this embodiment, leaf node L1After receiving the message, the same height hi ’And view vi ’Verifying to determine whether the height h should be generatedi ’And view vi ’The new block of (2).
Step 24, if the verification is passed, each leaf node respectively sends a plurality of pre-submission messages to the weak leader node;
in this embodiment, if the verification is passed, the leaf node L1To weak leader node W1Sending a Pre-commit message PreCommit1And a partial threshold signature is performed. Similarly, other nodes within a slice<L2,L3>To weak leader node W1Sending a Pre-commit message PreCommit2And PreCommit3。
PreCommitL=PartSigL(TransL,vL ’,hL ’)
Wherein, TransLRepresents a leaf node L1And collecting the transaction information ordered according to time sequence in the transaction pool.
And 25, the weak leader node collects a plurality of transaction messages sent by a plurality of nodes in the segment, performs partial threshold signature on the transaction messages, synthesizes a pre-submission message corresponding to the segment, and sends the synthesized pre-submission message to the strong leader node.
Weak leader node W1Collecting and slicing internal node<L1,L2,L3>All the transmitted transaction information is synthesized into the segmented pre-submission message PreCommit after signature verificationwAnd sent to the strong leader node.
Phase three, Commit Phase (Commit Phase):
step 31, the strong leader node collects the pre-submission messages sent by the weak leader node set in all the segments, verifies the threshold signature, the height and the view, and judges whether to generate a new block of the height and the view; if the verification is passed, the pre-commit message is considered valid, otherwise the pre-commit message is invalid.
In this embodiment, the strong leader node NiCollecting weak leader node sets in all segments<W1,W2,…,Wk>PreCommit transmittedWMessage, signature on threshold, height hi ’And view vi ’Verifying to determine whether the height h should be generatedi ’And view vi ’The strong leader node N only if the signature verification passesiConsider a pre-commit message PreCommitWIs effective.
Step 32, for valid said pre-commit messages, in the event that said strong leader node receives a first predetermined number of said valid pre-commit messages and at least a second predetermined number of said leaf nodes agree to generate a new block of predetermined trade information at said altitude and said view, said strong leader node synthesizes and broadcasts a threshold signature message. The first preset value is determined by the difference between the total number of nodes and the number of error nodes, and the second preset value is obtained by adding one to the number of error nodes.
In this embodiment, if strong leader node NiAt least a threshold t (t ≧ n-f) valid PreCommit is receivedWA message, f is the number of faulty nodes, n is the total number of nodes, andf+1voting agreement of each leaf node to hj ’Height, view vj ’Generating transaction information as TransjNew block of (2), strong leader node NiSynthesizing and broadcasting threshold signature CommitiA message.
Commiti=ThresholdSigi(Hash(Transi),vi ’,hi ’)
Step 33, the strong leader node broadcasts the threshold signature message to a weak leader node set participating in consensus;
in this embodiment, the strong leader node NiWill CommitiMessages are broadcast to a collection of weak leader nodes participating in consensus<W1,W2,…,Wk>. Strong leader node NiThe threshold signature can not be forged, and Commit with the threshold signature can not be forged by voting of leaf nodes which do not receive the threshold valueiMessage, and the weak leader node can verify the threshold signature message CommitiThe effectiveness of (c).
Stage four, determining stage (Decide Phase): after receiving the threshold signature message from the strong leader node, the weak leader node verifies the threshold signature, the height and the view; and processing according to the following conditions:
(1) when the signature passes the verification, the weak leader node forwards a threshold signature message to leaf nodes in the sub-slices, the leaf nodes reset the node message, wait for a timer, change the self-consensus state, execute corresponding trading in a trading pool, and update the block height, the view and the block chain structure of the leaf nodes.
In this embodiment, the weak leader node<W1,W2,…,Wk>Receive from the strong leader node NiCommit ofiAfter the message, sign threshold, height hi ’And view vi ’To carry outVerifying, and only when the signature verification is passed, the weak leader node forwards the threshold signature Commit to the leaf nodes in the sub-sliceiMessage, leaf node resets node message waiting timer, changes self-consensus state, executes Trans in transaction pooljThe block height, view and block chain structure of the leaf node are updated in response to the transaction.
(2) If the threshold signature verification passes, but the height hi ’And view vi ’If the verification fails, the leaf node NjNeed to compare the self-height hj ’Height h from the master nodei ’The size of (2):
a）hj ’= hi ’illustrating leaf node NjRequesting and Strong leader node NiGenerating blocks of different transactions at the same height, leaf node NjDeleting transaction Trans in transaction buffer pooljAnd synchronously trading Trans from the strong leader nodei。
b）hj ’< hi ’Explanation and Strong leader node NiIn contrast, the deletion is from height hj ’To a height hi ’The block information of (1). It is necessary to download the synchronized new tile information from the master node and clear the point NjA transaction buffer pool.
As shown in fig. 4, this embodiment further provides an electronic device, which includes a processor 301 and a communication circuit 302 connected to the processor 301, where the processor 301 stores therein a plurality of instructions, and the instructions can be loaded and executed by the processor, so that the processor 301 can execute the method according to the second embodiment.
The embodiment also provides a computer-readable storage medium, which stores a plurality of instructions for implementing the method according to the second embodiment.
The system, the method and the electronic equipment provided by the embodiment have the following beneficial effects:
through the two-level leader node structure, the strong leader node fragments the nodes according to the communication time queue, the local optimal time communication efficiency in the fragments is realized, and the message transmission speed between the nodes is improved. The strong leader node is responsible for collecting transactions and proposing a new block, the weak leader node is responsible for receiving the message of the strong leader node and forwarding the message to the fragments, the data consistency is guaranteed, meanwhile, the bandwidth and the CPU computing performance of the strong leader node and the weak leader node are fully utilized, and the expandability of the system is improved.
While preferred embodiments of the present invention have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all such alterations and modifications as fall within the scope of the invention. It will be apparent to those skilled in the art that various changes and modifications may be made in the present invention without departing from the spirit and scope of the invention. Thus, if such modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include such modifications and variations.
Claims (10)
1. A consensus system based on a two-level leader node sharding structure is characterized by comprising:
the system comprises a block chain, wherein the same block in the block chain comprises leaf nodes and only two-level leader nodes in a generation period of the same block, the two-level leader nodes comprise a strong leader node and a plurality of weak leader nodes, the strong leader node collects transactions and proposes new blocks, and the weak leader nodes only need to forward messages of the strong leader node and are responsible for message communication in the segments;
the fragments are obtained by dividing all nodes, each group of fragments comprises a plurality of leaf nodes and one weak leader node, the nodes contained in the fragments of different groups do not have intersection, and the number of the nodes in each group of fragments is greater than or equal to the ratio of the number of all the nodes to the number of the groups; and the data consensus module is used for data consensus among the fragments.
2. The consensus system as claimed in claim 1, wherein the strong leader node communicates directly with the weak leader node to interact with different segments, and wherein the strong leader node collects and verifies partial threshold signatures of messages from the weak leader node and collects intra-segment transaction information sent by the weak leader node for use in synthesizing a block.
3. The consensus system as claimed in claim 1, wherein the weak leader node communicates with the leaf nodes within the segment, collects transactions of the leaf nodes within the segment, and forwards the message sent by the strong leader node to the leaf nodes.
4. A consensus method based on a two-layer leader node sharding structure, for use in a consensus system based on a two-layer leader node sharding structure according to any one of claims 1 to 3, comprising:
step 1, a preparation phase, in which the strong leader node sends a preparation message to other weak leader nodes participating in consensus, the preparation message includes proposed block height and view, and the strong leader node signs the preparation message by using a private key after binary serialization of the message;
step 2, a pre-submission stage, configured to collect, by the weak leader node, multiple pieces of transaction information sent by multiple nodes in the segment, perform partial threshold signature on the transaction information, synthesize a pre-submission message corresponding to the segment, and send the synthesized pre-submission message to the strong leader node;
step 3, a submitting phase, which is used for the strong leader node to broadcast the message with the threshold signature to a weak leader node set participating in consensus;
and 4, a decision stage, namely after the weak leader node receives the threshold signature message from the strong leader node, performing second verification on the threshold signature, the height and the view, processing the transaction information on the block chain when the second verification is passed, and otherwise, returning consensus failure information.
5. The consensus method of claim 4, wherein said step 2 comprises:
step 21, after receiving the preparation message, the weak leader node verifies the signature of the message by using a public key, judges whether the proposed block height and view are correct or not, and continues to step 22 if the verification is passed;
step 22, the weak leader node broadcasts the preparation message to the node in the segment where the weak leader node is located;
step 23, the leaf node receives the preparation message and verifies the height and the view;
step 24, if said height and said view pass said verification, said each leaf node sending a plurality of pre-commit messages to said weak leader node, respectively;
and 25, the weak leader node collects a plurality of transaction messages sent by a plurality of nodes in the segment, performs partial threshold signature on the transaction messages, synthesizes a pre-submission message corresponding to the segment, and sends the synthesized pre-submission message to the strong leader node.
6. The consensus method of claim 4, wherein said step 3 comprises:
step 31, the strong leader node collects the pre-submission messages sent by the weak leader node set in all the segments, performs first verification on the threshold signature, the height and the view, and judges whether to generate a new block of the height and the view; if the first verification is passed, the pre-submitted message is considered to be valid, otherwise, the pre-submitted message is invalid;
step 32, for said valid pre-submitted messages, in the case where said strong leader node receives a first predetermined number of said pre-submitted messages and at least a second predetermined number of said leaf nodes agree to generate a new block containing predetermined trade information at said altitude and said view, said strong leader node synthesizes and broadcasts a threshold signature message;
and step 33, the strong leader node broadcasts the threshold signature message to the weak leader node set participating in the consensus.
7. The consensus method of claim 6, wherein the first predetermined value is determined as a difference between a total number of nodes and a number of faulty nodes, and wherein the second predetermined value is the number of faulty nodes plus one.
8. The consensus method of claim 4, wherein said step 4 comprises:
(1) when the verification of the threshold signature is passed and the verification of the height and the view is passed, the weak leader node forwards a threshold signature message to leaf nodes in the sub-slices, the leaf nodes reset the node message, wait for a timer, change the self-consensus state, execute corresponding trading in a trading pool, and update the block height, the view and the block chain structure of the leaf nodes;
(2) if the height and the view are verified but the threshold signature is verified, the leaf node needs to compare the height h of the leaf node with the height h of the leaf nodej ’Height h from the master nodei ’The size of (2):
a）hj ’= hi ’illustrating leaf node NjRequesting and Strong leader node NiGenerating blocks of different transactions at the same height, leaf node NjDeleting transaction Trans in transaction buffer pooljAnd synchronously trading Trans from the strong leader nodei；
b）hj ’< hi ’Explanation and Strong leader node NiIn contrast, the deletion is from height hj ’To a height hi ’Block information of (2) to be downloaded from the master nodeSynchronizing new block information and clearing point NjA transaction buffer pool.
9. An electronic device comprising a processor and communication circuitry, the processor coupled to the communication circuitry, the processor configured to execute instructions to implement the method of any of claims 4-8.
10. A computer-readable storage medium storing a plurality of instructions readable by a processor and performing the method of any one of claims 4-8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210024153.4A CN114050904B (en) | 2022-01-11 | 2022-01-11 | Consensus system and method based on two-level leader node fragmentation structure |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210024153.4A CN114050904B (en) | 2022-01-11 | 2022-01-11 | Consensus system and method based on two-level leader node fragmentation structure |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114050904A true CN114050904A (en) | 2022-02-15 |
| CN114050904B CN114050904B (en) | 2022-03-22 |
Family
ID=80213626
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210024153.4A Active CN114050904B (en) | 2022-01-11 | 2022-01-11 | Consensus system and method based on two-level leader node fragmentation structure |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114050904B (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114466034A (en) * | 2022-03-21 | 2022-05-10 | 北京航空航天大学 | Block chain consensus method based on anonymous main node |
| CN114726881A (en) * | 2022-04-12 | 2022-07-08 | 北京理工大学 | Block processing method, device and storage medium |
| CN114866562A (en) * | 2022-05-27 | 2022-08-05 | 山东省计算中心（国家超级计算济南中心） | Block chain consensus method and system for electric power energy system |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20200162261A1 (en) * | 2018-11-18 | 2020-05-21 | Ramachandran Iyer | System and method of blockchain consensus mechanism with custom hardware based on geographic distribution, density, node asset and reputation |
| CN112260836A (en) * | 2020-09-28 | 2021-01-22 | 电子科技大学 | Method for improving block chain throughput based on fragmentation technology |
| CN112910965A (en) * | 2021-01-18 | 2021-06-04 | 香港理工大学深圳研究院 | Method and system for submitting fragmented block chain down-across-fragmentation transaction |
| CN113254538A (en) * | 2021-06-17 | 2021-08-13 | 支付宝(杭州)信息技术有限公司 | Method for executing transaction in block chain and block chain link point |
-
2022
- 2022-01-11 CN CN202210024153.4A patent/CN114050904B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20200162261A1 (en) * | 2018-11-18 | 2020-05-21 | Ramachandran Iyer | System and method of blockchain consensus mechanism with custom hardware based on geographic distribution, density, node asset and reputation |
| CN112260836A (en) * | 2020-09-28 | 2021-01-22 | 电子科技大学 | Method for improving block chain throughput based on fragmentation technology |
| CN112910965A (en) * | 2021-01-18 | 2021-06-04 | 香港理工大学深圳研究院 | Method and system for submitting fragmented block chain down-across-fragmentation transaction |
| CN113254538A (en) * | 2021-06-17 | 2021-08-13 | 支付宝(杭州)信息技术有限公司 | Method for executing transaction in block chain and block chain link point |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114466034A (en) * | 2022-03-21 | 2022-05-10 | 北京航空航天大学 | Block chain consensus method based on anonymous main node |
| CN114726881A (en) * | 2022-04-12 | 2022-07-08 | 北京理工大学 | Block processing method, device and storage medium |
| CN114726881B (en) * | 2022-04-12 | 2023-05-16 | 北京理工大学 | Block processing method, device and storage medium |
| CN114866562A (en) * | 2022-05-27 | 2022-08-05 | 山东省计算中心（国家超级计算济南中心） | Block chain consensus method and system for electric power energy system |
| CN114866562B (en) * | 2022-05-27 | 2023-06-09 | 山东省计算中心（国家超级计算济南中心） | Block chain consensus method and system for electric power energy system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114050904B (en) | 2022-03-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN114050904B (en) | Consensus system and method based on two-level leader node fragmentation structure | |
| US20180308091A1 (en) | Fairness preserving byzantine agreements | |
| CN111311414A (en) | Block chain multi-party consensus method based on consistent hash algorithm | |
| CN111682942B (en) | Binary weighted Byzantine fault-tolerant consensus method applied to license chain | |
| CN113347164A (en) | Block chain-based distributed consensus system, method, device and storage medium | |
| Yu et al. | Improved blockchain consensus mechanism based on PBFT algorithm | |
| CN111582843A (en) | Block chain privacy transaction method based on aggregated signature | |
| He et al. | An improvement of consensus fault tolerant algorithm applied to alliance chain | |
| CN114338040B (en) | Block chain node grouping multi-chain three-time consensus method | |
| CN114422513A (en) | Block chain consensus method based on Raft-PBFT | |
| JP2022523217A (en) | Topology Driven Byzantine Fault Tolerant Consensus Protocol with Voting Aggregation | |
| CN115134086A (en) | Method and device for dynamic committee secret sharing and updating of asynchronous network | |
| CN114140233A (en) | Safe cross-slice view conversion method and device for partitioned block chain | |
| CN111064813B (en) | Method and device for synchronizing processing messages during block chain consensus processing | |
| CN116258609B (en) | Electric power system transaction cooperation method, device and storage medium | |
| Liu et al. | Flexible Advancement in Asynchronous BFT Consensus | |
| CN114499874B (en) | Bayesian-busy-family fault-tolerant consensus optimization method applied to industrial Internet | |
| CN116232893A (en) | Consensus method and device of distributed system, electronic equipment and storage medium | |
| CN113609229B (en) | Method and device for fast log replication in Fabric block chain | |
| CN115002111B (en) | Block chain consensus method based on group tree structure | |
| CN114466034B (en) | Block chain consensus method based on anonymous main node | |
| Dai et al. | LightDAG: A Low-latency DAG-based BFT Consensus through Lightweight Broadcast | |
| CN114640500B (en) | Service-based alliance chain efficient consensus method | |
| Peng et al. | Petrichor: An Efficient Consensus Protocol Leveraging DAG and Sharding for Asynchronous BFT | |
| Jiang et al. | An efficient Byzantine fault-tolerant consensus mechanism based on threshold signature |
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 |