An efficient consensus method for large-scale nodes

Abstract

The present invention discloses a large-scale node efficient consensus method, which relates to the field of information security technology. The nodes in the network are divided into multiple groups, each group processes non-overlapping data in parallel, and runs an improved scalable PBFT consensus algorithm in each group to process and store block information. Each group divides the nodes into two layers, and calculates aggregate public keys and member keys for nodes in each layer, and enables multiple BLS aggregate signatures in the consensus process. The upper-layer nodes first perform the pre-preparation and preparation process of the consensus, and then the lower-layer nodes perform the pre-preparation, preparation and confirmation process in turn. Finally, the upper-layer nodes complete the confirmation process and end the two-layer consensus. The present invention can be used for efficient consensus between large-scale nodes, which is safer and more efficient than traditional PBFT-type consensus methods.

Description

Technical Field

[0001] The present invention relates to the field of information security technology, and in particular to a large-scale node efficient consensus method. Background Art

[0002] As a data structure that stores data in chronological order, blockchain can support different consensus algorithms. Consensus algorithm is an important component of blockchain technology. It solves the mutual trust problem between nodes and plays a vital role in maintaining the security and efficiency of blockchain. Using the right algorithm can significantly improve the performance of blockchain system. Although blockchain technology has been widely researched and developed, it has not been widely used. One of the main reasons is that most blockchain systems cannot provide high throughput and high scalability to meet the data processing needs of large-scale nodes. Therefore, the efficient consensus method of large-scale nodes is specifically designed to solve such problems.

[0003] According to the different node access mechanisms, traditional consensus algorithms include private chain consensus, public chain consensus and alliance chain consensus. The consensus algorithm of private chain uses the consensus algorithm in traditional distributed systems, and the main representative algorithms are Paxos, Raft, etc. This type of algorithm does not consider the Byzantine fault tolerance problem, and generally only considers failures caused by the node itself and network reasons (such as node downtime, network failure, etc.) without considering the situation where there are malicious nodes in the cluster; the public chain consensus algorithm is the most decentralized, and the main representative algorithms are PoW, PoS, etc. This type of algorithm is open to the outside world, can resist malicious attacks of 1 / 2 computing power, and has strong scalability, but the mining calculation overhead is large, and the algorithm performance is poor; the alliance chain consensus algorithm restricts the access of nodes, and the main representative algorithms are PBFT and PBFT improved algorithm, etc., which have the characteristics of low energy consumption and high performance, and can provide 1 / 3 fault tolerance. However, in order to achieve data consistency, the PBFT algorithm adopts a multi-stage interaction method, and in the process of one round of consensus, the entire network reaches a communication complexity of O(n2) (n is the number of nodes participating in the consensus). The existing PBFT message diffusion protocol has poor scalability and is not suitable for consensus among large-scale nodes. Therefore, how to efficiently reach consensus among large-scale nodes is a problem worth solving. Summary of the invention

[0004] In view of the problems existing in the prior art, the present invention proposes an efficient consensus method for large-scale nodes, which can realize the horizontal expansion of the network scale by grouping, and when the number of groups reaches the upper limit, the existing PBFT consensus algorithm is improved to expand vertically within the group. The algorithm expands the PBFT algorithm into multiple layers to reduce the communication overhead required for single-layer consensus, and introduces aggregate signatures in each round of PBFT consensus to further reduce the number of required communications, making the consensus between large-scale nodes safe and efficient.

[0005] In order to achieve the above object, the present invention adopts the following technical solutions:

[0006] A large-scale node efficient consensus method, comprising the following steps:

[0007] Step 1. Divide all network nodes into multiple groups. All block data is divided into each group. Each group only processes and stores block information associated with this group.

[0008] Step 2. Divide the nodes of each group into two layers, the upper network forms a partition, and the lower network contains multiple independent partitions;

[0009] Step 3. Calculate and distribute the key information required for the aggregate signature in each partition of the upper and lower layers of the network;

[0010] Step 4. In each group, the upper-layer network master node receives the block data, and uses the secret key information to first perform the consensus pre-preparation and preparation process on the upper-layer network node, and then the lower-layer network nodes perform the pre-preparation, preparation and confirmation process in turn. Finally, the upper-layer node completes the confirmation process and ends the two-layer consensus.

[0011] Furthermore, the specific implementation process of step 2 is as follows:

[0012] The nodes of each group are divided into two layers, the upper network consists of a partition, including 1 master node and p replica nodes, m of the replica nodes are master nodes of the lower network, where p≥m and p≥3; the lower network contains m partitions, each partition contains 1 master node and n replica nodes, the master node of the lower network is also a replica node of the upper network, where n≥3.

[0013] Furthermore, the specific implementation process of step 3 is as follows:

[0014] Set the total number of nodes in the upper network to 3f1+1, f1≥1, and the number of nodes in each partition of the lower network to 3f2+1, f2≥1, and then perform initialization settings in each layer of the network. The initialization process is: the upper network and the lower partition network construct (2f1+1, 3f1+1) and (2f1+1, 3f2+1) multi-signatures respectively. In each partition of the upper network and the lower network, the public keys of all nodes in the partition are used to calculate the aggregate public key. Each node uses its own private key to calculate the member key, and the aggregate public key and member key are shared in each partition.

[0015] Furthermore, the specific implementation process of step 4 is as follows:

[0016] Step 401, upper layer pre-preparation phase; before entering a new round of consensus, the upper layer master node counts the confirmation information of the previous round of consensus confirmation phase of this layer. If the upper layer master node collects no less than 2f1+1 confirmation information before timeout, it enters a new round of consensus; if 2f1+1 confirmation information is not collected within the timeout, the completed consensus result is resent to the remaining replica nodes of this layer, and then a new round of consensus process is carried out;

[0017] When a new round of consensus begins, the upper-layer master node collects transactions in the transaction memory pool, packages the transactions into blocks and broadcasts them to all replica nodes in this layer; the broadcast message is <<pre-prepare,v,h,d> ,block>, where pre-prepare indicates the protocol stage of the current message, v indicates the view number of the current message, h is the block height, d is the signature of the upper master node on the block, and block is the entire block content;

[0018] Step 402, upper layer preparation stage; the upper layer preparation process is divided into two stages:

[0019] Phase 1: After receiving the broadcast message from the master node of this layer, the upper-layer replica node first verifies the message, checks the signature, block height, and view number, and then verifies all transactions in it. After the verification is correct, it sends a<prepare1,v,h,d,i> To the master node of this layer, prepare1 indicates the protocol stage of the current message, v indicates the view number of the current message, h is the block height, d is the signature of the upper-layer replica node on the block, and i is the replica node number;

[0020] Phase 2: The upper master node keeps listening to the prepare1 information sent by the replica node of this layer. The upper master node verifies each prepare1 information, collects the verified ones, and verifies each signature after collecting no less than 2f1+1 signatures. It aggregates the signatures of 2f1+1 different nodes that have passed the verification to form the aggregated signature information of the block and broadcasts a<prepare2,v,h,aggrsignature,node> The message is sent to all replica nodes of this layer, where prepare2 indicates the protocol stage of the current message, v indicates the view number of the current message, h is the block height, aggrsignature is the aggregate signature of the upper-layer master node on the block block, and node is the ID list of all nodes participating in the aggregate signature. The signatures collected by the upper-layer master node include its own signature;

[0021] Step 403, lower layer pre-preparation phase; when the upper layer replica node receives the prepare2 message from the upper layer master node, it generates the synthetic public key of all nodes participating in the aggregate signature according to the node information provided by the upper layer master node, and uses the locally stored block information as the input of the signature verification algorithm to perform the aggregate signature verification process. When the aggregate signature, view number and block height verification fail or the verification times out, the upper layer replica node broadcasts the view switching information to all nodes in this layer. When the replica node in this layer receives no less than 2f1+1 view switching requests, it re-elects the master node in this layer. If the verification passes within the specified time, the upper layer replica node waits for the lower layer consensus to be completed and enters the upper layer confirmation phase. The nodes in the upper layer replica node that also serve as the master nodes of the lower layer partitions broadcast a <<pre-prepare,v,h,d,d’> ,block> information, where pre-prepare indicates the protocol stage of the current message, v indicates the view number of the current message, h is the block height, d is the signature of the partition master node on the block, d' is the signature of the upper master node on the block in the upper pre-preparation stage, and block is the entire block content;

[0022] Step 404, lower layer preparation stage; the lower layer preparation process is divided into two stages:

[0023] Phase 1: After receiving the pre-prepare message from the master node of this layer, the lower-level replica node first verifies the message, checks the signature, block height, and view number, and then verifies all transactions in it. After verification, it sends a<prepare1,v,h,d,i> To the master node of this layer, prepare1 indicates the protocol stage of the current message, v indicates the view number of the current message, h is the block height, d is the signature of the lower-layer replica node on the block, and i is the replica node number;

[0024] Phase 2: The master node of the lower partition keeps listening to the prepare1 information sent by the replica node of this layer. The master node of the lower partition verifies each prepare1 information and collects the verified ones. After the master node of the lower partition collects no less than 2f2+1 signatures, it verifies each signature separately and aggregates the signatures of 2f2+1 different nodes that have passed the verification to form the aggregated signature information of the block and broadcasts a<prepare2,v,h,aggrsignature,node> The message is sent to all replica nodes of this layer, where prepare2 indicates the protocol stage of the current message, v indicates the view number of the current message, h is the block height, aggrsignature is the aggregate signature of the master node of the lower partition on the block block, and node is the ID list of all nodes participating in the aggregate signature. The signatures collected by the master node of the lower partition include its own signature;

[0025] Step 405, lower-layer confirmation phase; when the lower-layer replica node receives the prepare2 message from the lower-layer partition master node, it generates the synthetic public key of all nodes participating in the aggregate signature according to the provided node information, and uses the locally stored block information as the input of the signature verification algorithm to perform the aggregate signature verification process. When the aggregate signature, view number and block height verification fail or the verification times out, the lower-layer replica node broadcasts the view switching information to all nodes in this layer. When the replica node in this layer receives no less than 2f2+1 view switching requests, it re-elects the master node in this layer. If the verification passes within the specified time, the lower-layer replica node links the locally stored block to the end of the blockchain to complete the synchronization, and sends a message to the master node in this layer.<commit,v,h,d,i> The message is used as a reply, where commit indicates the protocol stage of the current message, v indicates the view number of the current message, h is the block height, d is the signature of the replica node on the consensus confirmation message digest, and i is the replica node number;

[0026] Step 406, upper layer confirmation phase; when entering the upper layer confirmation phase, only the node that serves as the upper layer replica node sends a<commit,v,h,d,i> The node that serves as both the upper-level replica node and the lower-level partition master node first counts the commit messages sent by the replica nodes in this partition. If 2f2+1 confirmation messages are not collected within the timeout, the completed consensus result will be resent to the replica nodes in this partition to re-conduct the consensus of this layer. If the lower-level partition master node collects more than 2f2+1 confirmation messages before the timeout, it means that the consensus of this partition has been completed. At this time, the lower-level partition master node sends a<commit,v,h,d,i> The message is used as a reply, where commit identifies the protocol stage of the current message, v identifies the view number of the current message, h is the block height, d is the signature of the upper-level replica node on the consensus confirmation message digest, and i is the master node number of the lower-level partition.

[0027] Compared with the prior art, the present invention has the following advantages:

[0028] The present invention adopts a hierarchical partitioned consensus architecture to divide large-scale nodes into multiple groups, and each group processes non-overlapping data in parallel. An improved PBFT consensus algorithm is run in each group, and the PBFT algorithm is expanded to multiple layers to reduce the communication overhead required for a single-layer consensus, and aggregate signatures are introduced in each round of PBFT consensus to further reduce the number of required communications. Compared with the traditional PBFT consensus algorithm, it can significantly reduce communication overhead, increase the node capacity of a single group, and make consensus secure and efficient; compared with the PBFT consensus algorithm based on aggregate signatures, it can reduce the number of nodes participating in multiple aggregate signatures through hierarchical partitioning, reduce the verification time of aggregate signatures, and improve consensus efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 It is a flow chart of a large-scale node efficient consensus method of the present invention.

[0030] Figure 2 This is a network structure diagram of a large-scale node efficient consensus method of the present invention.

[0031] Figure 3 It is a schematic diagram of an algorithm for a large-scale node efficient consensus method of the present invention.

[0032] Figure 4 It is a structural diagram of an example of an implementation of the present invention. DETAILED DESCRIPTION

[0033] In order to make the purpose and advantages of the present invention more clearly understood, the following Figure 1 , Attachment Figure 2 , Attachment Figure 3 , Attachment Figure 4 It should be understood that the following text is only used to describe one or several specific embodiments of the present invention, and does not strictly limit the protection scope of the specific claims of the present invention.

[0034] An embodiment of a large-scale node efficient consensus method, the implementation of the method is completed by a sending unit, a receiving unit and a consensus unit; the embodiment structure diagram is as follows Figure 4 shown.

[0035] The sending unit is the sender of information, generating information that needs to be processed and stored between consensus units;

[0036] Consensus units are blockchain nodes that run the consensus mechanism, ensuring the clear order of sent information and guaranteeing the integrity and consistency of the ledgers stored between consensus units;

[0037] The receiving unit is the receiver of the information, accesses the blockchain ledger data from the consensus unit, and extracts the required information.

[0038] Further, such as Figure 1 As shown, the specific implementation process includes the following steps:

[0039] Step 1. Divide the consensus unit into multiple groups, and each group only processes and stores the block information associated with this group;

[0040] Step 2. Divide the consensus units in each group into two layers, the upper network forms a partition, and the lower network contains multiple independent partitions; Figure 2 As shown, the specific implementation process is as follows:

[0041] The nodes of each group are divided into two layers, the upper network consists of a partition, including 1 master node and p replica nodes, m of the replica nodes are master nodes of the lower network, where p≥m and p≥3; the lower network contains m partitions, each partition contains 1 master node and n replica nodes, the master node of the lower network is also a replica node of the upper network, where n≥3.

[0042] Step 3. Calculate and distribute the key information required for the aggregate signature in each partition of the upper and lower layers of the network; the specific implementation process is as follows:

[0043] Set the total number of nodes in the upper network to 3f1+1, f1≥1, and the number of nodes in each partition of the lower network to 3f2+1, f2≥1, and then perform initialization settings in each layer of the network. The initialization process is: the upper network and the lower partition network construct (2f1+1, 3f1+1) and (2f2+1, 3f2+1) multi-signatures respectively. In each partition of the upper network and the lower network, the public keys of all nodes in the partition are used to calculate the aggregate public key. Each node uses its own private key to calculate the member key, and the aggregate public key and member key are shared in each partition.

[0044] Step 4. The sending unit generates the business information to be sent, encapsulates the information into a transaction format that can be processed by the blockchain network, and sends the transaction to the nearby consensus unit, which broadcasts it to a specific group according to the transaction identifier;

[0045] Step 5. In each group, the upper-layer consensus unit first performs the consensus pre-preparation and preparation process, and then the lower-layer consensus unit performs the pre-preparation, preparation and confirmation process in turn. Finally, the upper-layer consensus unit completes the confirmation process, ends the two-layer consensus, and stores the block information to the local blockchain; Figure 3 As shown, the specific implementation process is as follows:

[0046] Step 401, upper layer pre-preparation phase; before entering a new round of consensus, the upper layer master node counts the confirmation information of the previous round of consensus confirmation phase of this layer. If the upper layer master node collects no less than 2f1+1 confirmation information before timeout, it enters a new round of consensus; if 2f1+1 confirmation information is not collected within the timeout, the completed consensus result is resent to the remaining replica nodes of this layer, and then a new round of consensus process is carried out;

[0047] When a new round of consensus begins, the upper-layer master node collects transactions in the transaction memory pool, packages the transactions into blocks and broadcasts them to all replica nodes in this layer; the broadcast message is <<pre-prepare,v,h,d> ,block>, where pre-prepare indicates the protocol stage of the current message, v indicates the view number of the current message, h is the block height, d is the signature of the upper master node on the block, and block is the entire block content;

[0048] Step 402, upper layer preparation stage; the upper layer preparation process is divided into two stages:

[0049] Phase 1: After receiving the broadcast message from the master node of this layer, the upper-layer replica node first verifies the message, checks the signature, block height, and view number, and then verifies all transactions in it. After the verification is correct, it sends a<prepare1,v,h,d,i> To the master node of this layer, prepare1 indicates the protocol stage of the current message, v indicates the view number of the current message, h is the block height, d is the signature of the upper-layer replica node on the block, and i is the replica node number;

[0050] Phase 2: The upper master node keeps listening to the prepare1 information sent by the replica node of this layer. The upper master node verifies each prepare1 information, collects the verified ones, and verifies each signature after collecting no less than 2f1+1 signatures. It aggregates the signatures of 2f1+1 different nodes that have passed the verification to form the aggregated signature information of the block and broadcasts a<prepare2,v,h,aggrsignature,node> The message is sent to all replica nodes of this layer, where prepare2 indicates the protocol stage of the current message, v indicates the view number of the current message, h is the block height, aggrsignature is the aggregate signature of the upper-layer master node on the block block, and node is the ID list of all nodes participating in the aggregate signature. The signatures collected by the upper-layer master node include its own signature;

[0051] Step 403, lower layer pre-preparation phase; when the upper layer replica node receives the prepare2 message from the upper layer master node, it generates the synthetic public key of all nodes participating in the aggregate signature according to the node information provided by the upper layer master node, and uses the locally stored block information as the input of the signature verification algorithm to perform the aggregate signature verification process. When the aggregate signature, view number and block height verification fail or the verification times out, the upper layer replica node broadcasts the view switching information to all nodes in this layer. When the replica node in this layer receives no less than 2f1+1 view switching requests, it re-elects the master node in this layer. If the verification passes within the specified time, the upper layer replica node waits for the lower layer consensus to be completed and enters the upper layer confirmation phase. The nodes in the upper layer replica node that also serve as the master nodes of the lower layer partitions broadcast a <<pre-prepare,v,h,d,d’> ,block> information, where pre-prepare indicates the protocol stage of the current message, v indicates the view number of the current message, h is the block height, d is the signature of the partition master node on the block, d' is the signature of the upper master node on the block in the upper pre-preparation stage, and block is the entire block content;

[0052] Step 404, lower layer preparation stage; the lower layer preparation process is divided into two stages:

[0053] Phase 1: After receiving the pre-prepare message from the master node of this layer, the lower-level replica node first verifies the message, checks the signature, block height, and view number, and then verifies all transactions in it. After verification, it sends a<prepare1,v,h,d,i> To the master node of this layer, prepare1 indicates the protocol stage of the current message, v indicates the view number of the current message, h is the block height, d is the signature of the lower-layer replica node on the block, and i is the replica node number;

[0054] Phase 2: The master node of the lower partition keeps listening to the prepare1 information sent by the replica node of this layer. The master node of the lower partition verifies each prepare1 information and collects the verified ones. After the master node of the lower partition collects no less than 2f2+1 signatures, it verifies each signature separately and aggregates the signatures of 2f2+1 different nodes that have passed the verification to form the aggregated signature information of the block and broadcasts a<prepare2,v,h,aggrsignature,node> The message is sent to all replica nodes of this layer, where prepare2 indicates the protocol stage of the current message, v indicates the view number of the current message, h is the block height, aggrsignature is the aggregate signature of the master node of the lower partition on the block block, and node is the ID list of all nodes participating in the aggregate signature. The signatures collected by the master node of the lower partition include its own signature;

[0055] Step 405, lower-layer confirmation phase; when the lower-layer replica node receives the prepare2 message from the lower-layer partition master node, it generates the synthetic public key of all nodes participating in the aggregate signature according to the provided node information, and uses the locally stored block information as the input of the signature verification algorithm to perform the aggregate signature verification process. When the aggregate signature, view number and block height verification fail or the verification times out, the lower-layer replica node broadcasts the view switching information to all nodes in this layer. When the replica node in this layer receives no less than 2f2+1 view switching requests, it re-elects the master node in this layer. If the verification passes within the specified time, the lower-layer replica node links the locally stored block to the end of the blockchain to complete the synchronization, and sends a message to the master node in this layer.<commit,v,h,d,i> The message is used as a reply, where commit indicates the protocol stage of the current message, v indicates the view number of the current message, h is the block height, d is the signature of the replica node on the consensus confirmation message digest, and i is the replica node number;

[0056] Step 406, upper layer confirmation phase; when entering the upper layer confirmation phase, only the node that serves as the upper layer replica node sends a<commit,v,h,d,i> The node that serves as both the upper-level replica node and the lower-level partition master node first counts the commit messages sent by the replica nodes in this partition. If 2f2+1 confirmation messages are not collected within the timeout, the completed consensus result will be resent to the replica nodes in this partition to re-conduct the consensus of this layer. If the lower-level partition master node collects more than 2f2+1 confirmation messages before the timeout, it means that the consensus of this partition has been completed. At this time, the lower-level partition master node sends a<commit,v,h,d,i> The message is sent as a reply, where commit identifies the protocol stage of the current message, v identifies the view number of the current message, h is the block height, d is the signature of the upper-level replica node on the consensus confirmation message digest, and i is the master node number of the lower-level partition.

[0057] Step 6. The receiving unit requests block information from nearby consensus units and extracts the required business information from the block.

Claims

1. A large-scale node efficient consensus method, characterized in that: The following steps are involved: Step 1. Divide all network nodes into multiple groups. All block data is divided into each group. Each group only processes and stores block information associated with this group. Step 2. Divide the nodes of each group into two layers, the upper network forms a partition, and the lower network contains multiple independent partitions; Step 3. Calculate and distribute the key information required for the aggregate signature in each partition of the upper and lower layers of the network; Step 4. In each group, the upper network master node receives the block data, and uses the secret key information to first perform the consensus pre-preparation and preparation process, and then the lower network nodes perform the pre-preparation, preparation and confirmation process in turn. Finally, the upper node completes the confirmation process and ends the two-layer consensus; The specific implementation process of step 2 is as follows: The nodes of each group are divided into two layers, the upper network consists of a partition, including 1 master node and p replica nodes, m of which are master nodes of the lower network, where p≥m and p≥3; the lower network contains m partitions, each partition contains 1 master node and n replica nodes, the master node of the lower network is also a replica node of the upper network, where n≥3; The specific implementation process of step 3 is as follows: Set the total number of nodes in the upper network to 3f1+1, f1≥1, and the number of nodes in each partition of the lower network to 3f2+1, f2≥1, and then perform initialization settings in each layer of the network. The initialization process is: the upper network and the lower partition network construct (2f1+1, 3f1+1) and (2f2+1, 3f2+1) multi-signatures respectively. In each partition of the upper network and the lower network, the public keys of all nodes in the partition are used to calculate the aggregate public key. Each node uses its own private key to calculate the member key, and the aggregate public key and member key are shared in each partition.

2. According to claim 1, a large-scale node efficient consensus method is characterized in that: The specific implementation process of step 4 is as follows: Step 401, upper layer pre-preparation phase; before entering a new round of consensus, the upper layer master node counts the confirmation information of the previous round of consensus confirmation phase of this layer. If the upper layer master node collects no less than 2f1+1 confirmation information before timeout, it enters a new round of consensus; if 2f1+1 confirmation information is not collected within the timeout, the completed consensus result is resent to the remaining replica nodes of this layer, and then a new round of consensus process is carried out; When a new round of consensus begins, the upper-layer master node collects transactions in the transaction memory pool, packages the transactions into blocks and broadcasts them to all replica nodes in this layer; the broadcast message is <<pre-prepare,v,h,d> ,block>, where pre-prepare indicates the protocol stage of the current message, v indicates the view number of the current message, h is the block height, d is the signature of the upper master node on the block, and block is the entire block content; Step 402, upper layer preparation stage; the upper layer preparation process is divided into two stages: Phase 1: After receiving the broadcast message from the master node of this layer, the upper-layer replica node first verifies the message, checks the signature, block height and view number, and then verifies all transactions in it. After the verification is correct, it sends a<prepare1,v,h,d,i> To the master node of this layer, prepare1 indicates the protocol stage of the current message, v indicates the view number of the current message, h is the block height, d is the signature of the upper-layer replica node on the block, and i is the replica node number; Phase 2: The upper master node keeps listening to the prepare1 information sent by the replica node of this layer. The upper master node verifies each prepare1 information, collects the verified ones, and verifies each signature after collecting no less than 2f1+1 signatures. It aggregates the signatures of 2f1+1 different nodes that have passed the verification to form the aggregated signature information of the block and broadcasts a<prepare2,v,h,aggrsignature,node> The message is sent to all replica nodes of this layer, where prepare2 indicates the protocol stage of the current message, v indicates the view number of the current message, h is the block height, aggrsignature is the aggregate signature of the upper-layer master node on the block block, and node is the ID list of all nodes participating in the aggregate signature. The signatures collected by the upper-layer master node include its own signature; Step 403, lower-layer pre-preparation phase; when the upper-layer replica node receives the prepare2 message from the upper-layer master node, it generates the synthetic public key of all nodes participating in the aggregate signature according to the node information provided by the upper-layer master node, and uses the locally stored block information as the input of the signature verification algorithm to perform the aggregate signature verification process. When the aggregate signature, view number and block height verification fail or the verification times out, the upper-layer replica node broadcasts the view switching information to all nodes in this layer. When the replica node in this layer receives no less than 2f1+1 view switching requests, it re-elects the master node in this layer. If the verification is passed within the specified time, the upper-layer replica node waits for the lower-layer consensus to be completed and enters the upper-layer confirmation stage. The node in the upper-layer replica node that also serves as the master node of the lower-layer partition broadcasts a <<pre-prepare,v,h,d,d’> ,block> information, where pre-prepare indicates the protocol stage of the current message, v indicates the view number of the current message, h is the block height, d is the signature of the partition master node on the block, d' is the signature of the upper master node on the block in the upper pre-preparation stage, and block is the entire block content; Step 404, lower layer preparation stage; The lower layer preparation process is divided into two stages: Phase 1: After receiving the pre-prepare message from the master node of this layer, the lower-level replica node first verifies the message, checks the signature, block height, and view number, and then verifies all transactions in it. After verification, it sends a<prepare1,v,h,d,i> To the master node of this layer, prepare1 indicates the protocol stage of the current message, v indicates the view number of the current message, h is the block height, d is the signature of the lower-layer replica node on the block, and i is the replica node number; Phase 2: The master node of the lower partition keeps listening to the prepare1 information sent by the replica node of this layer. The master node of the lower partition verifies each prepare1 information and collects the verified ones. After the master node of the lower partition collects no less than 2f2+1 signatures, it verifies each signature separately and aggregates the signatures of 2f2+1 different nodes that have passed the verification to form the aggregated signature information of the block and broadcasts a<prepare2,v,h,aggrsignature,node> The message is sent to all replica nodes of this layer, where prepare2 indicates the protocol stage of the current message, v indicates the view number of the current message, h is the block height, aggrsignature is the aggregate signature of the master node of the lower partition on the block block, and node is the ID list of all nodes participating in the aggregate signature. The signatures collected by the master node of the lower partition include its own signature; Step 405, lower-layer confirmation phase; when the lower-layer replica node receives the prepare2 message from the lower-layer partition master node, it generates the synthetic public key of all nodes participating in the aggregate signature according to the provided node information, and uses the locally stored block information as the input of the signature verification algorithm to perform the aggregate signature verification process. When the aggregate signature, view number and block height verification fail or the verification times out, the lower-layer replica node broadcasts the view switching information to all nodes in the same layer. When the replica node in the same layer receives no less than 2f2+1 view switching requests, it re-elects the master node in the same layer. If the verification is successful within the specified time, the lower-level replica node will link the locally stored block to the end of the blockchain to complete the synchronization, and send a<commit,v,h,d,i> The message is used as a reply, where commit indicates the protocol stage of the current message, v indicates the view number of the current message, h is the block height, d is the signature of the replica node on the consensus confirmation message digest, and i is the replica node number; Step 406, upper layer confirmation phase; when entering the upper layer confirmation phase, only the node that serves as the upper layer replica node sends a<commit,v,h,d,i> The node that serves as both the upper-level replica node and the lower-level partition master node first counts the commit messages sent by the replica nodes in this partition. If 2f2+1 confirmation messages are not collected within the timeout, the completed consensus result will be resent to the replica nodes in this partition to re-conduct the consensus of this layer. If the lower-level partition master node collects more than 2f2+1 confirmation messages before the timeout, it means that the consensus of this partition has been completed. At this time, the lower-level partition master node sends a<commit,v,h,d,i> The message is used as a reply, where commit identifies the protocol stage of the current message, v identifies the view number of the current message, h is the block height, d is the signature of the upper-level replica node on the consensus confirmation message digest, and i is the master node number of the lower-level partition.

Images