CN115002111B

CN115002111B - Block chain consensus method based on group tree structure

Info

Publication number: CN115002111B
Application number: CN202210564115.8A
Authority: CN
Inventors: 胡凯; 万季; 任旖航
Original assignee: Beihang University
Current assignee: Beihang University
Priority date: 2022-05-23
Filing date: 2022-05-23
Publication date: 2022-12-27
Anticipated expiration: 2042-05-23
Also published as: CN115002111A

Abstract

The invention relates to a block chain consensus method based on a group tree structure, wherein nodes participating in consensus communicate in a tree topology, a block chain link point group tree divides block chain link points into a plurality of different groups, and consensus and broadcast are independently performed in each group, so that the block chain system consistency consensus is realized, the algorithm has higher performance and expandability, n-n broadcast among the nodes is avoided, the number of message communication is reduced, and the system performance is improved through the tree topology. And the block chain consensus method comprises four stages of a preparation stage, an proposing stage, a confirming stage and a determining stage, so that the block consistency consensus is realized, n-n broadcasting among nodes is avoided, the communication of tree node topology is realized, the network communication and the calculation amount of related nodes are reduced through the parallel broadcasting of groups, and the algorithm has higher performance and expandability.

Description

Block chain consensus method based on group tree structure

Technical Field

The invention relates to a block chain consensus method based on a group tree structure.

Background

The block chain is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, consensus algorithm, encryption algorithm and the like. The block chain is formed by a single block, each block records the state change of the database at the current time, all blocks can be combined into complete historical data, in order to prevent the splitting or the forging of the block chain state, the blocks are linked by using a hash value, and the linear sequence formed among the blocks is not changeable. It is the special block structure and operation mechanism that makes the blockchain technique possess decentralization, anonymity, non-tampering, security and stability characteristics. The block chain solves the trust problem in the open network environment, can be used as an important support technology in the business field needing to construct wide trusted relationship, and can be combined with the industries of payment settlement, data sharing, electronic evidence storage, traceability, food and the like for expansion and application.

The consensus algorithm is an algorithm for enabling all participants to achieve agreement on task execution results in a multi-party collaborative environment, is mostly applied to ensuring data consistency of a distributed system, and is the basis and core of a block chain technology. 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, the decision weight is dispersed in each node, and trust is not needed between the nodes, so that the effectiveness of the block data of each node is consistent by using a consensus algorithm for achieving the purpose of joint accounting. The consensus algorithm, as a key technology in the blockchain, directly affects the transaction processing capability, expandability and security of the blockchain, and thus becomes a hotspot of research on the blockchain technology.

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.

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 means that the replication service satisfies linear consistency, the distributed system performs operations atomically like a centralized system, and all clients will eventually receive replies to their requests as long as the number of failed replicas does not exceed (n-1)/3 and the delay (t) does not grow indefinitely. 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.

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 the majority of the 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 copy 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 from different nodes. In the confirmation phase, after the preparation phase is completed, the received information is firstly verified, and if the received information passes the verification, the confirmation information is broadcasted to other nodes, and then the confirmation phase is entered. After the node enters the confirmation stage, when confirmation messages sent by other nodes are received, the signature of the message is judged, the validity of the view to which the message belongs is verified, after 2f +1 confirmation messages are received, the confirmation stage is finished, the confirmation messages are fed back to the client, and therefore the whole algorithm process is finished.

The message communication complexity of the PBFT consensus algorithm is O (n) ² ) And the nodes need to advance a consensus step through n-n interaction, and as the number of the nodes increases, the throughput tends to decline rapidly.

The fragmentation technology is to divide the network into different groups, and to ensure that each group processes different transactions by a certain distribution means, and finally to achieve the result that the common computer simultaneously solves the transactions of high order of magnitude. Scalability is an important performance indicator of blockchains, meaning that as the number of nodes in a blockchain network increases, the processing performance of the system for transactions also increases. The sharding technique is a commonly used technical solution for improving performance in distributed databases, such as the Spanner of Google.

In the field of block chains, fragmentation is only an idea introduced in the field of distributed systems, and there are three fragmentation modes in the specific practical process: network fragmentation, transaction fragmentation, and status fragmentation. The implementation difficulty of the three slices and the segmentation degree of the block chain system architecture are gradually increased. The first two fragments are firstly proposed and implemented, are the basic implementation specifications of the fragment scheme, and are called as a partial fragment scheme, because the partial fragment scheme only fragments the nodes and the transaction which are elements in the consensus process, the parallelization of the consensus process is realized, but the nodes of the whole network are still required to share the same complete global account book. The state fragmentation also fragments the storage state of the ledger, which is also called a full fragmentation scheme, the global ledger is segmented into each fragmentation, and each fragmentation only maintains part of ledger data related to own user.

The network fragmentation is to distribute nodes in the network into different fragments by using an algorithm, and data stored between different fragments is consistent. It is not enough to simply use a random algorithm to assign nodes to different pieces, and we must also ensure the consistency of opinions of different members of one piece of the network. The transaction fragment is to distribute the transaction to different fragments for processing according to different transaction types, for example, the transaction is classified and divided according to Hash, type, characteristics and the like of the transaction, and data consistency still needs to be maintained among different fragments. The state fragmentation divides the whole storage area, and different fragments store different parts, so that each node is only responsible for hosting own fragmentation data, but not storing the complete block chain state.

In most of the existing block chain consensus algorithms, when a new block is generated, nodes participating in consensus need to communicate with all other nodes, message communication needs to be performed between the nodes through n-n broadcasting, the number of message communication between the nodes is exponentially increased along with the increase of the number of the nodes, and the message communication complexity is high. In addition, the blockchain master node often needs to collect messages of all nodes participating in consensus and pack transaction information in all nodes into a new block, and network communication and calculation amount borne by the master node is large, which becomes a bottleneck of performance and expandability of the blockchain system.

Disclosure of Invention

In order to solve the above technical problems, the present invention provides a block chain consensus method based on a group tree architecture.

The invention adopts the following technical scheme:

a blockchain consensus method based on a group tree architecture, the group tree architecture including three levels of nodes, namely a root node, a child node and a leaf node, the child node being a next level node of the root node, the leaf node being a next level node of the child node, the blockchain consensus method comprising:

a preparation stage: the leaf node generates and sends a first preparation message to a corresponding child node according to a received command sent by a user, wherein the first preparation message comprises related data of a block requested to be generated; the child nodes process the received first preparation messages from different leaf nodes, generate and send second preparation messages to the root node;

a proposal phase: traversing the self group tree by the root node, and sending a first block proposal message to all child nodes; the child node receives the first block proposal message from the root node and then carries out relevant verification, and if the verification is passed, the child node sends a second block proposal message to a corresponding leaf node;

and (3) confirmation stage: the leaf node carries out validity verification of the block proposal according to the second block proposal message, and if the verification is passed, the leaf node sends a first confirmation message to the corresponding child node; the child node collects first confirmation messages of all corresponding leaf nodes, and if the first confirmation messages of all the corresponding leaf nodes are received, the child node generates and sends second confirmation messages to the root node;

a decision phase; the root node verifies the validity according to the second confirmation message, and if the second confirmation message passes the verification, a first block proposal decision message is generated and sent to the child node; the child node receives the first block proposal decision message and then carries out validity verification, and if the verification is passed, a second block proposal decision message is generated and sent to the leaf node; the leaf node verifies the validity of the second block proposal decision message, and if the verification is passed, the leaf node executes a corresponding command.

As a specific embodiment, the first prepare message includes a command list that the leaf node takes from the command buffer pool in time sequence, a timestamp of a transmission transaction corresponding to the leaf node, a view of a leaf node request generation block, a height of the leaf node request generation block, and a hash value corresponding to the leaf node, where the hash value corresponding to the leaf node is calculated from the timestamp of the transmission transaction corresponding to the leaf node, the view of the leaf node request generation block, the height of the leaf node request generation block, and the command list that the leaf node takes from the command buffer pool in time sequence;

the child node processes the received first preparation message from different leaf nodes, generates and sends a second preparation message to the root node, and the method comprises the following steps:

the second preparation message comprises a command list corresponding to the child node, a timestamp of a sending transaction corresponding to the child node, a view of a block requested to be generated by the child node, the height of the block requested to be generated by the child node and a hash value corresponding to the child node;

the command list corresponding to the child node is the superposition of command lists taken by all leaf nodes corresponding to the child node from the command buffer pool according to the time sequence;

the hash value corresponding to the child node is obtained by calculating a timestamp of a sending transaction corresponding to the child node, a view of a block requested to be generated by the child node, the height of the block requested to be generated by the child node and a command list corresponding to the child node.

As one embodiment, the first block proposal message includes a root node proposed block, a root node proposed view, a root node proposed block height, and a root node corresponding signature; the signature corresponding to the root node is obtained according to the block proposed by the root node, the view proposed by the root node and the height of the block proposed by the root node;

the second block proposal message comprises the first block proposal message and a signature corresponding to the child node, and the signature corresponding to the child node is obtained according to the block proposed by the root node, the view proposed by the child node and the block height proposed by the child node.

As an embodiment, in the proposal phase, after receiving the first block proposal message from the root node, the child node performs relevant verification, including:

verifying the validity of a signature corresponding to a root node in the first block proposal message, if the validity verification is passed, judging whether the identity of the root node is consistent with the identity of the root node in the group tree of the user, if so, judging whether a view proposed by the root node is consistent with a view of a block requested to be generated by a child node, and judging whether the height of the block proposed by the root node is consistent with the height of the block requested to be generated by the child node, if so, judging that the final verification is passed.

As a specific embodiment, the first confirmation message includes a view of the leaf node request generation block, a height of the leaf node request generation block, and a partial threshold signature vote generated by the leaf node for the proposed block of the root node;

the second confirmation message comprises a view of the child node requesting generation of the block, a height of the child node requesting generation of the block, and a partial threshold signature vote within the group; the partial threshold signature votes within the group are a superposition of the partial threshold signature votes generated for the proposed block of the root node for all leaf nodes.

As an embodiment, in the validation stage, the leaf node performs validity verification of the block proposal according to the second block proposal message, including:

if the command list chronologically fetched by the leaf node from the command buffer pool is contained in the block proposed by the root node, and the view of the block requested to be generated by the leaf node is consistent with the view proposed by the root node and the height of the block requested to be generated by the leaf node is consistent with the height of the block proposed by the root node, the validity verification is passed.

As a specific implementation manner, in the decision phase, the root node performs validity verification according to the second acknowledgement message, including: if the root node receives second confirmation messages of effective department threshold signature votes exceeding a first preset threshold value, the validity verification is passed;

the first block proposal decision message comprises a block proposed by a root node, a view proposed by the root node, a block height proposed by the root node and a complete threshold signature, and the complete threshold signature is obtained by voting and synthesizing partial threshold signatures valid in the second confirmation message;

the child node performing validity verification after receiving the first block proposal decision message, comprising:

and the child node judges whether the sender of the first block proposal decision message is the root node in the self group tree, if so, the validity of the complete threshold signature in the first block proposal decision message is verified, and if the validity is verified, the verification is passed.

As one embodiment, the second block proposal decision message includes the first block proposal decision message and a signature corresponding to the child node; the signature corresponding to the child node is obtained according to the block proposed by the root node, the view proposed by the child node and the height of the block proposed by the child node;

the leaf node validates the second block proposal decision message, and if the validation is passed, executes a command, including:

the leaf node determining whether a height of a root node proposed block in the second block proposal decision message is consistent with a height of a leaf node request generation block, and whether a view of the root node proposed block in the second block proposal decision message is consistent with a view of a leaf node request generation block;

if the root node proposed block height in the second block proposal decision message is consistent with the leaf node request generated block height, and the root node proposed view in the second block proposal decision message is consistent with the leaf node request generated block view, then execute the corresponding command.

The block chain consensus method based on the group tree structure provided by the invention designs the block chain link point group tree structure, nodes participating in consensus communicate in a tree topology, the block chain link point group tree divides block chain links into a plurality of different groups, consensus and broadcasting are independently performed inside each group, the block chain system consistency consensus is realized based on a three-layer structure of the group tree, so that the algorithm has higher performance and expandability, n-n broadcasting among the nodes is avoided, broadcasting and calculation tasks are distributed to each group by the tree topology structure to be executed, the number of message communication is reduced, and the system performance is improved by the tree topology. In addition, in the block chain consensus process based on the group tree structure, block consistency consensus is realized through four stages, namely a preparation stage, an proposing stage, a confirming stage and a determining stage, n-n broadcasting among nodes is avoided, tree node topology communication is realized, network communication and calculation amount of related nodes are reduced through group parallel broadcasting, and the algorithm has high performance and expandability.

Drawings

In order to more clearly illustrate the technical solution of the embodiment of the present invention, the drawings needed to be used in the embodiment will be briefly described as follows:

FIG. 1 is a block diagram of a group tree architecture provided in an embodiment of the present application;

fig. 2 is a flowchart illustrating four stages of a block chain consensus method based on a group tree structure according to an embodiment of the present disclosure.

Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular system structures, techniques, etc. in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.

It will be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It should also be understood that the term "and/or" as used in this specification and the appended claims refers to any and all possible combinations of one or more of the associated listed items and includes such combinations.

As used in this specification and the appended claims, the term "if" may be interpreted contextually as "when", "upon" or "in response to" determining "or" in response to detecting ". Similarly, the phrase "if it is determined" or "if a [ described condition or event ] is detected" may be interpreted contextually to mean "upon determining" or "in response to determining" or "upon detecting [ described condition or event ]" or "in response to detecting [ described condition or event ]".

Furthermore, in the description of the present application and the appended claims, the terms "first," "second," "third," and the like are used for distinguishing between descriptions and not necessarily for describing or implying relative importance.

Reference throughout this specification to "one embodiment" or "some embodiments," or the like, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the present application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," or the like, in various places throughout this specification are not necessarily all referring to the same embodiment, but rather "one or more but not all embodiments" unless specifically stated otherwise. The terms "comprising," "including," "having," and variations thereof mean "including, but not limited to," unless expressly specified otherwise.

In order to explain the technical means described in the present application, the following description will be given by way of specific embodiments.

Before describing the block chain consensus method based on the block chain structure in detail, the block chain node point group tree structure is introduced first, and hereinafter referred to as a group tree for short. The group tree includes three levels of nodes, which are a root node, a child node and a leaf node, respectively, the child node is a next level node of the root node, and the leaf node is a next level node of the child node. As shown in fig. 1, the root node identity is the leader, and therefore, the root node is also referred to as the leader node. The child nodes are forwarder nodes and the leaf nodes are listener nodes. All child nodes and leaf nodes share a unique root node. In this embodiment, each group includes one forwarder node and several listener nodes. The node functions of the group and the individual identities are as follows:

group (2): n nodes in the node set are divided into k groups with similar sizes<C ₁ ,C ₂ ,..,C _k >Each group C _k Therein at least comprises

And each block chain node. Each group contains a unique forwarder node and several listener nodes.

The leader node: the system is a root node of a group tree, only one leader node exists in the system at the same time, and the leader node is only communicated with a forwarder node. The leader node has two roles: (1) It is responsible for proposing new blocks and sending the proposed blocks to the forwarder node; (2) It verifies the partial threshold signature message sent by the forwarder node. If a partial threshold signature is received that is valid beyond the threshold value, it may combine the partial threshold signatures into a complete threshold signature.

The forwarder node: each group C _k There is one and only one forwarder node, which has two roles: (1) The method comprises the steps that the method communicates with a leader node, verifies a message signature sent by the leader, and sends a message or a block proposal containing a complete threshold signature sent by the leader to nodes in a group; (2) It is related to the audiences in the groupThe nodes communicate, collect partial threshold signatures or transaction information of the nodes of the audiences in the group and send the partial threshold signatures or the transaction information to the leader.

The listener node: the slave listening node does not communicate directly with the leader node, it communicates directly with the forwarder node, and updates its own state based on the message. The follower node has two roles: (1) It collects the order information sent by the user and sends it to the forwarder node; (2) It determines whether the message sent by the forwarder node is valid and whether to send a partial threshold signature to the forwarder node as voting information.

In this embodiment, a threshold signature mechanism is used to vote on a message. All nodes hold the same single public key and verification function, node N _i A partial signature of a message may be generated using a private key and a signature function. If the node receives partial threshold signatures of at least threshold t messages, a complete threshold signature can be synthesized by a signature function. Other nodes may verify the validity of the full threshold signature using the public key and a verification function.

As shown in FIG. 1, assume that the blockchain system consists of 14 nodes, divided into 3 groups<C ₁ ,C ₂ ,C ₃ >Node N ₁ Is the leader node, node N ₂ 、N ₆ 、N ₁₀ If it is a forwarder node and the other nodes are listener nodes, the group C ₁ ＝<N ₂ ,N ₃ ,N ₄ ,N ₅ >Group C ₂ ＝<N ₆ ,N ₇ ,N ₈ ,N ₉ >Group C ₃ ＝<N ₁₀ ,N ₁₁ ,N ₁₂ ,N ₁₃ ,N ₁₄ >. User 1 sends transaction 3 to the listener nodes in group 1, users 2, 3 send transactions 6, 9 to the listener nodes in group 2, and users 4, 5 can still download complete block information containing transaction 3, transaction 6 and transaction 9, although not sending transactions to the listener nodes in group 3. The block information downloaded by the user from different groups is the same, and the same block contains the complete transaction information from different groups.

After nodes participating in consensus are constructed into a tree topology to communicate, how to collect command information received by a user and sent by a listener to enable a system to continuously generate new blocks and achieve efficient data consistency consensus of different nodes is still a problem to be solved, and then the block chain consensus method based on the group tree architecture is introduced to achieve data consensus based on the block chain link point group tree architecture.

The user first needs to establish a connection with a blockchain link point in order to send commands to the blockchain system or to obtain commands from the blockchain system. The user broadcasts a connection establishment request to the listener nodes, and selects an appropriate listener node to establish connection according to network delay of the user and the listener nodes and resource consumption conditions of the listener nodes. The listener nodes are in a one-to-many relationship with the users, each listener node can serve multiple users, but each user can only be connected with one listener node. Suppose that at this time, user and listener nodes N _k A connection is established.

The block chain consensus method based on the group tree structure provided in this embodiment includes four phases during the algorithm execution, which are a preparation Phase (preparation Phase), a proposed Phase (forward Phase), a confirmation Phase (Commit Phase), and a decision Phase (decision Phase), as shown in fig. 2. Each stage will be specifically described below.

Preparatory Phase (prep Phase): the leaf node generates and sends a first preparation message to a corresponding child node according to a received command sent by a user, wherein the first preparation message comprises related data of a block requested to be generated; the child node processes the received first prepare message from a different leaf node, generates and sends a second prepare message to the root node.

Sleeper node N _k Gathering commands sent by the user or responding to command inquiry requests of the user. When receiving a sending command from a user, classifying the received command from the user according to a sending user account, and sequencing transactions initiated by the same user account according to the sending time. In this embodiment, the listener node N _k Corresponding forwarder nodePoint to forwarder node N _j . The command sent by the user may be a command for generating a tile, or may be other related commands, such as a transaction command. Sleeper node N _k According to the received command sent by the user, generating and sending the command to the forwarder node N _j Sending a first Prepare message, i.e. Prepare _k A message. As an embodiment, when the listener node timer expires or the number of commands in the command buffer pool reaches the maximum value of the number of commands contained in a single block, the listener node N _k To the forwarder node N _j Sending Prepare _k Message, prepare _k The message specifically consists of:

Prepare _k ＝(Trans _k ,v′ _k ,h′ _k ,t _k ,Hash _k )

wherein, trans _k Representing listener node N _k Lists of commands, t, taken chronologically from a command buffer pool _k Node N being the listener _k Corresponding timestamp of the transmitted transaction, v' _k Node N being the listener _k Request to generate View, h 'of tiles' _k Node N being the listener _k Requesting the height of the generating block, hash _k Node N for the listener _k The corresponding hash value. According to listener node N _k Time stamp t of the corresponding send transaction _k Node N of listening follower _k Request to generate view v 'of tile' _k Node N of listening and receiving _k Requesting to generate height h 'of tile' _k And listener node N _k Trans-list of commands taken from a buffer pool of commands in chronological order _k Calculating Hash _k 。

Thus, prepare _k The message comprises a slave node N _k Time stamp t of the corresponding send transaction _k Node N of listening and receiving _k Request to generate view v 'of tile' _k Node N of listening and receiving _k Requesting to generate height h 'of tile' _k Node N of listening and receiving _k Trans command list chronologically taken from a command buffer pool _k And Hash _k 。

Forwarder node N _j Prepare received from corresponding different listener nodes _k The message is processed to obtain a second prepared message, i.e. Prepare _j A message. The specific treatment process is as follows:

Prepare _j the message specifically consists of:

representing a forwarder node N _j The corresponding command list is known by the calculation formula, and the forwarder node N _j The corresponding command list is associated with the forwarder node N _j Superposition of the list of commands chronologically taken from the command buffer pool by all the corresponding slave listening nodes, | C _m I denotes the forwarder node N _j The number of listener nodes in the group; t is t _j Representing a forwarder node N _j Corresponding timestamp, v 'of the transmitted transaction' _j Representing a forwarder node N _j Request to generate view, h 'of tile' _j Representing a forwarder node N _j Requesting the height of the generating block, hash _j Representing a forwarder node N _j The corresponding hash value. It should be understood that the forwarder node N _j Corresponding Hash value Hash _j By forwarder node N _j Time stamp t of the corresponding send transaction _j Forwarder node N _j Request to generate view v 'of tile' _j Forwarder node N _j Requesting to generate height h 'of tile' _j And forwarder node N _j Corresponding command list

And (4) calculating.

Thus, prepare _j The message comprises: forwarder node N _j Corresponding command list

Forwarder node N _j Corresponding Hash value Hash _j Forwarder node N _j Time stamp t of the corresponding send transaction _j Forwarder node N _j Request to generate view v 'of tile' _j And forwarder node N _j Requesting height h 'of a generated tile' _j 。

Proposed Phase (pro Phase): traversing the self group tree by the root node, and sending a first block proposal message to all child nodes; and after receiving the first block proposal message from the root node, the child nodes carry out relevant verification, and if the verification is passed, the child nodes send second block proposal messages to corresponding leaf nodes.

Leader node N _i Traversing the self group tree, and sending a first block proposal message, namely a block proposal prompt, to all the forwarder nodes _i A message. Block proposal Propose _i The message specifically consists of:

representing leader node N _i Proposed Block, v' _i Representing leader node N _i Proposed View, h' represents leader node N _i The height of the proposed block is such that,

representing leader node N _i The corresponding signature. Wherein the leader node N _i Corresponding signature

According to leader node N _i Proposed Block

Leader node N _i Proposed View v' _i And leader node N _i Proposed Block height h' _i The obtained and obtained light-emitting diode is, moreover,

is by the leader node N _i Generated using a private key and a signature function.

Thus, block proposal Propose _i The message comprises: leader node N _i Proposed Block

Leader node N _i Proposed View v' _i Leader node N _i Proposed Block height h' _i And signatures

Forwarder node N _j Receiving node N from leader _i Block proposal (2) of (1) _i A message. In this embodiment, the forwarder node N _j Receiving node N from leader _i Block proposal (2) of (1) _i And carrying out related verification after the message, wherein the verification process comprises the following steps: propose is proposed for a certificate block _i Signing in messages

If the validity is verified, whether the identity of the forwarder node is consistent with the identity of the forwarder node in the self group tree is judged, and if so, the leader node N is judged _i Proposed view v' _i And forwarder node N _j Request to generate view v 'of tile' _j Whether consistent, and leader node N _i Proposed Block height h' _i And forwarder node N _j Requesting height h 'of a generated tile' _j Is consistent, i.e. v 'is satisfied' _i ＝v′ _j And h' _i ＝h′ _j And if so, judging that the final verification is passed. After the verification is passed, the forwarder node N _j Searching the self group tree, and sending a second block proposal message, namely a block, to all the listener nodes in the self groupBlock proposal Propose _j Message, block proposal Propose _i The message specifically consists of:

is a forwarder node N _j Corresponding signature, signature

According to leader node N _i Proposed block

Forwarder node N _j Requesting to generate view v 'of tile' _j And leader node N _i Proposed Block height h' _h And (6) obtaining. Furthermore, a forwarder node N _j V 'to View Using its own private Key and signature function' _j And height h' _j Block proposal of (2)

Signing to obtain a signature

Thus, block proposal Propose _j The message comprises: block proposal Propose _i Message and signature

Signature

And from the leader node N _i Transmitted Propose _i Message composition of new Propose _j The message is sent to the listener slave node.

And a confirmation stage: the leaf node carries out validity verification of the block proposal according to the second block proposal message, and if the verification is passed, the leaf node sends a first confirmation message to the corresponding child node; and the child nodes collect the first confirmation messages of all corresponding leaf nodes, and if the first confirmation messages of all corresponding leaf nodes are received, the child nodes generate and send second confirmation messages to the root node.

Slave node N _k Propose the Propose according to the block _j The message performs validity verification of the block proposal, and as one embodiment, the following gives a specific verification process: if the slave node N _k Trans command list chronologically taken from a command buffer pool _k Is included in the leader node N _i Proposed Block

I.e. the ordered command list of the self-proposal is included in the block proposal, i.e.

And listener node N _k Request to generate view v 'of tile' _k With leader node N _i Proposed View v' _i Coincident and listen follower node N _k Requesting to generate height h 'of tile' _k With leader node N _i Proposed Block height h' _i Consistent, meaning that the listening node considers the leader node N _i Proposed Block

If the verification result is valid, the verification is passed. If the verification is passed, the node N of the listener _k To the forwarder node N _j Sending a first acknowledgement message, commit _k Message, representing consent in corresponding View v' _k And a height h' _k The block proposal of (1). Commit _k The specific composition of the message is as follows:

wherein

Representing listener node N _k Generated for leader node N _i Proposed Block

The partial threshold signature votes. Sleeper node N _k Can be generated using private keys and signature functions

Therefore, commit _k The message comprises: slave node N _k Request to generate view v 'of tile' _k Node N of listening and receiving _k Requesting to generate height h 'of tile' _k And partial threshold signature voting

Forwarder node N _j Collecting Commit sent by each listener node in the group _k Message, if receiving Commit sent by all the listener nodes _k Message, then forwarder node N _j Generating and directing leader node N _i Sending a second acknowledgment message, commit _j A message. Commit _j The message is specifically composed as follows:

indicating partial threshold signature votes within a group, partial threshold signature votes within a group

Including all corresponding slave listening nodes, for the leader node N _i Proposed Block

Partial threshold signature voting

And (4) superposing.

Then Commit _j The message comprises: forwarder node N _j View v' of request generation Block, forwarder node N _j Height N' of request generation block and partial threshold signature voting within group

Hence, the forwarder node N _j Part of collected threshold signature in group is transferred to Commit _j In a message, sent to the leader node N _i 。

A decision phase; the root node carries out validity verification according to the second confirmation message, and if the verification is passed, a first block proposal decision message is generated and sent to the child node; the child node receives the first block proposal decision message and then carries out validity verification, and if the verification is passed, a second block proposal decision message is generated and sent to the leaf node; the leaf node verifies the validity of the second block proposal decision message, and if the verification is passed, the leaf node executes a block generation command.

Leader node N _i Receiving Commit _j After the message, according to Commit _j The message is validated, and as a specific implementation, a validation process is given as follows:

judging leader node N _i Whether valid department threshold signature votes exceeding a first predetermined threshold are received

Since each Commit _j All messages correspond to a department threshold signature vote

Then the leader node N _i Receiving valid department threshold signature votes exceeding a first predetermined threshold

Equivalent as leader node N _i Receiving votes exceeding a first predetermined threshold with valid department threshold signatures

Commit of _j A message. In this embodiment, the first preset threshold value is t, t ≧ 2f, and f denotes the number of nodes which may fail. Then, if leader node N _i Receiving more than t valid department-threshold signature votes

Representing leader node N _i More than 2f views v 'are gathered' _i And a height h' _i Is considered to agree with the block proposal by most forwarder nodes

And (5) passing the verification. After the verification is passed, the leader node N _i Generating a complete threshold signature by signature function

And broadcasting a first block proposal decision message, i.e., block proposal delete, to the forwarder node _i Message, block proposal Decide _i The message specifically consists of:

complete threshold signature

By Commit _j And voting and synthesizing the effective partial threshold signatures in the message.

Thus, block proposalDecide _i The message comprises: leader node N _i Proposed Block

Leader node N _i Proposed View v' _i Leader node N _i Proposed Block height h' _i And full threshold signature

Forwarder node N _j Receiving a block proposal Decide _i After the message, validity verification is performed, and as a specific implementation, a validity verification process is given as follows: forwarder node N _j Decision block proposed Decide _i Whether the sender of the message is a leader node in the group tree of the sender, if so, verifying that the block proposes the Decide _i Validity of the full threshold signature in the message may be verified using a public key and a verification function. And if the validity verification passes, the verification is passed. If the verification is passed, the forwarder node N _j Searching the self-group tree, sending a second block proposal decision message, i.e. a block proposal delete, to all the listener nodes in the self-group _j Message, block proposal Decide _i The message specifically consists of:

thus, the block proposal Decide _j The message includes a block proposal Decide _i And signatures

Forwarder node N _j Pair view v 'using its own private key and signature function' _j And height h' _j Block proposal of (2)

Carry out signatureTo sign a signature

And from the leader node N _i Transmitted Decide _i Message composition of new Decide _j The message is sent to the listener slave node.

Slave node N _k For Decide _j The validity of the message is verified, and as a specific implementation, a specific verification process is given as follows: slave node N _k Determination of Decide _j Leader node N in a message _i Proposed Block height h' _i And listener node N _k Requesting to generate height h 'of tile' _k Whether consistent, and leader node N _i Proposed view v' _i And listener node N _k Requesting to generate view v 'of tile' _k Is consistent, namely, is h 'satisfied' _k ＝h′ _i And v' _k ＝v′ _i If h is satisfied' _k ＝h′ _i And v' _k ＝v′ _i Indicating listener node N _k Dee as Decide _j If the height and view of the requested production block in the message are consistent with the self-verification, executing corresponding command, specifically executing block proposal

Updating node N in response to the command _j Height of (a) and self block chain structure.

Therefore, the application provides a group tree structure of block chain nodes, wherein the nodes participating in consensus communicate in a tree topology, the block chain link point group tree divides the block chain link points into a plurality of different groups, and the consensus and broadcast are independently performed in each group, so that n-n broadcast among the nodes is avoided. The tree topology structure disperses the broadcast and calculation tasks into each group for execution, thereby reducing the number of message communication. Moreover, the application provides a block chain consensus method based on a group tree structure, four-stage consensus algorithms including a preparation stage (Prepare Phase), a proposal stage (dispose Phase), a confirmation stage (Commit Phase) and a decision stage (delete Phase) are designed based on the group tree, and the communication of tree node topology is realized through a threshold signature algorithm message signature mechanism, so that the algorithm has high performance and expandability.

The above-mentioned embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications and substitutions do not substantially depart from the spirit and scope of the embodiments of the present application and are intended to be included within the scope of the present application.

Claims

1. A blockchain consensus method based on a group tree structure, wherein the group tree structure comprises three levels of nodes, namely a root node, a child node and a leaf node, the child node is a node next to the root node, and the leaf node is a node next to the child node, the blockchain consensus method comprising:

a proposal stage: traversing the self group tree by the root node, and sending a first block proposal message to all child nodes; after receiving the first block proposal message from the root node, the child node performs related verification, and if the verification is passed, the child node sends a second block proposal message to a corresponding leaf node;

a decision phase; the root node carries out validity verification according to the second confirmation message, and if the verification is passed, a first block proposal decision message is generated and sent to the child node; the child node receives the first block proposal decision message and then carries out validity verification, and if the verification is passed, a second block proposal decision message is generated and sent to the leaf node; the leaf node verifies the validity of the second block proposal decision message, and if the verification is passed, the leaf node executes a corresponding command.

2. The block chain consensus method based on the group tree architecture as claimed in claim 1, wherein the first preparation message includes a command list taken by a leaf node from a command buffer pool in time sequence, a timestamp of a transmission transaction corresponding to the leaf node, a view of a leaf node request generation block, a height of the leaf node request generation block, and a hash value corresponding to the leaf node, and the hash value corresponding to the leaf node is calculated from the timestamp of the transmission transaction corresponding to the leaf node, the view of the leaf node request generation block, the height of the leaf node request generation block, and the command list taken by the leaf node from the command buffer pool in time sequence;

3. The group tree architecture-based blockchain consensus method of claim 1, wherein the first block proposal message comprises a root node proposed block, a root node proposed view, a root node proposed block height, and a root node corresponding signature; the signature corresponding to the root node is obtained according to the block proposed by the root node, the view proposed by the root node and the height of the block proposed by the root node;

4. The method of claim 3, wherein the performing the related verification after the child node receives the first block proposal message from the root node in the proposal phase comprises:

verifying the validity of a signature corresponding to a root node in the first block proposal message, if the validity verification is passed, judging whether the identity of the root node is consistent with the identity of the root node in the group tree of the root node, if so, judging whether a view proposed by the root node is consistent with a view of a block requested to be generated by a child node, and judging whether the height of the block proposed by the root node is consistent with the height of the block requested to be generated by the child node, if the view proposed by the root node is consistent with the view of the block requested to be generated by the child node, and the height of the block proposed by the root node is consistent with the height of the block requested to be generated by the child node, judging that the final verification is passed.

5. The group tree architecture-based block chain consensus method of claim 1, wherein said first acknowledgement message comprises a leaf node request to generate a view of a block, a leaf node request to generate a height of a block, and a leaf node generated partial threshold signature vote for a proposed block of a root node;

the second confirmation message comprises a view of the child node requesting generation of the chunk, a height of the child node requesting generation of the chunk, and a partial threshold signature vote within the group; the partial threshold signature votes within the group are a superposition of the partial threshold signature votes generated for the proposed block of the root node for all leaf nodes.

6. The method of claim 5, wherein the group tree based block chain consensus is performed,

in the validation stage, the leaf node performs validity verification of the block proposal according to the second block proposal message, including:

if the command list taken by the leaf node from the command buffer pool in time sequence is contained in the block proposed by the root node, and the view of the block requested to be generated by the leaf node is consistent with the view proposed by the root node and the height of the block requested to be generated by the leaf node is consistent with the height of the block proposed by the root node, the validity verification is passed.

7. The method of claim 1, wherein the validating by the root node in the determining step according to the second acknowledgement message comprises: if the root node receives second confirmation messages of effective department threshold signature votes exceeding a first preset threshold value, the validity verification is passed;

the child node performs validity verification after receiving the first block proposal decision message, and the method comprises the following steps:

8. The group tree based block chain consensus method of claim 7, wherein said second block proposal decision message comprises said first block proposal decision message and a signature corresponding to a child node; the signature corresponding to the child node is obtained according to the block proposed by the root node, the view proposed by the child node and the height of the block proposed by the child node;

if the height of the root node proposed block in the second block proposal decision message is consistent with the height of the leaf node request generation block, and the view proposed by the root node in the second block proposal decision message is consistent with the view of the leaf node request generation block, executing the corresponding command.