Layering and pipeline-based Byzantine fault-tolerant improved consensus protocol implementation method and system

Abstract

The invention discloses a Byzantine fault-tolerant improved consensus protocol implementation method and system based on layering and pipeline, and the method comprises the following specific steps: S1, a preparation stage PREPARE: a master node generates and broadcasts a new proposal Bv, and after a common node votes and accepts, a group leader collects a signature and aggregates the signature into a partial aggregation signature, and then sends the partial aggregation signature to the master node; s2, pre-submission stage PRECOMMIT: after aggregating a set number of preparation votes, the main node generates and broadcasts a pre-submission message; after the common nodes vote and approve, the group leader collects and partially aggregates signatures again, and then sends the signatures to the main node; s3, COMMIT in a submission stage: after the main node aggregates a set number of pre-submission tickets, broadcasting a final submission message; and the common node submits the block after verification, and jointly triggers the view to be switched to the next main node. Through the aggregation signature technology, the communication complexity is reduced, signature aggregation is changed from original leader aggregation to excitation node primary aggregation and leader secondary aggregation, and the verification process is accelerated.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of blockchains, and particularly relates to a layered and pipelined Byzantine Fault Tolerance (BFT) improved consensus protocol implementation method and system. BACKGROUND

[0002] In a distributed system such as a blockchain, consensus is used to ensure the consistency of information, data or state, that is, to ensure that all nodes reach an agreement on the same information, data or state. At the same time, the consensus mechanism should have a certain fault tolerance, that is, it can still reach a consensus under the condition that there are a small number of Byzantine malicious nodes in the system. The malicious behavior of Byzantine nodes includes sending incorrect information, refusing to respond or exhibiting other unpredictable behavior.

[0003] In a Byzantine Fault Tolerance (BFT) consensus algorithm, nodes promote the progress of the consensus process by sending messages to each other. To ensure the integrity and uniqueness of the message, a hash function is often used to map an input of arbitrary length to an output of fixed length as a data identifier. At the same time, to prevent the message from being tampered with during transmission, a public-private key cryptography system is also introduced: the node uses a private key to generate a digital signature for the message, and other nodes use the corresponding public key to verify the signature to prove that the message was indeed generated by the signer and has not been modified. In addition, aggregate signature (AS) is also commonly used to reduce the overhead of the consensus process, which can aggregate multiple digital signatures into one signature, reducing storage and transmission overhead. In the verification stage of the aggregate signature, first, each original signature and its corresponding public key are aggregated to obtain an aggregate signature and an aggregate public key. Then, it can be judged whether the given message is valid under the aggregate public key through one verification operation, which is equivalent to verifying all original signatures one by one in terms of verification effect.

[0004] There are two key indicators of consensus algorithms: latency and throughput. Latency refers to the time from request to response, and throughput refers to the number of requests processed per unit of time. BFT consensus algorithms can improve the performance of the protocol through layering or pipelining techniques. Generally speaking, the more nodes participating in the consensus, the more communication messages generated in the consensus process, resulting in longer consensus latency. The node layering technique solves the message complexity problem of cross-group message transmission and state synchronization, which can reduce the number of messages generated in the consensus process (i.e. reduce the communication complexity of the consensus), thereby reducing the latency; the pipelining technique realizes the partial overlap of multiple consensus in time, which can realize the parallel processing of multiple consensus, thereby improving the throughput of the consensus.

[0005] When the BFT consensus method adopts the hierarchical optimization idea, the consensus nodes are generally divided into three roles: system master node, group leader and ordinary node. The basic idea is to first reach the group consensus through the group leader and ordinary nodes, then reach the inter-group consensus between the group leaders and the master nodes through related message transmission, and finally all nodes reach the global consensus. The pipeline consensus technology usually adopts a pipeline parallel architecture, which divides the consensus process into multiple stages such as receiving, verifying, sorting, executing and state submission, and each stage is handled by a special node group. The nodes in different stages form a pipeline collaboration. When a certain stage completes the specified consensus processing, its output is immediately passed to the next stage, while the new consensus processing is started.

[0006] Although the current hierarchical technology can reduce the complexity of message communication and improve the consensus efficiency, the consensus stage is generally increased after traditional hierarchical, which leads to an increase in consensus delay, which has room for optimization. The pipeline consensus constructs the consensus process itself (such as request broadcast, pre-preparation, preparation, submission, etc.) into a processing pipeline, so that different batches of client requests can be pushed forward in parallel in different consensus stages, thereby significantly improving the protocol throughput. However, the typical hierarchical BFT algorithm at the present stage usually adopts a strict serial dependence structure: the algorithm must first reach a consensus on a certain global state or checkpoint at the top node set, and then each lower consensus group can perform independent BFT consensus process on the specific request sequence based on the result, and finally realize global confirmation. The strong sequential dependence relationship of "upper consensus - group consensus - global confirmation" makes the consensus process cannot be simply decoupled into overlapping pipeline stages, so the existing hierarchical BFT architecture cannot be directly migrated to the efficient pipeline consensus mode. SUMMARY

[0007] In view of the problems existing in the prior art, the present application discloses an improved Byzantine fault-tolerant consensus protocol implementation method and system based on hierarchy and flow, referred to as HPBFT.

[0008] The object of the present application is achieved by the following technical solutions: The present application is based on the following scenario: the consensus system is composed of N nodes that can communicate with each other, wherein the number of Byzantine malicious nodes does not exceed f , which satisfies the fault-tolerant condition of N ≥ 3 f + 1; the message transmission between nodes in the network adopts a semi-synchronous communication model, and after the global stabilization time (GST), the delay can be considered to be limited and the upper bound is known.

[0009] The N nodes in the system are evenly divided into KGroups. According to the difference in their functions in the consensus process, nodes are defined as the following three roles: Primary Node: In each round of consensus, the unique global leader generated by the system through the election mechanism, responsible for receiving client requests, generating consensus proposals, and driving the entire consensus process.

[0010] Group Leaders: A representative node elected in each consensus group, responsible for collecting votes from ordinary nodes in the group to form a partial aggregate signature, and sending the partial aggregate signature to the primary node; responsible for receiving proposals from the primary node and broadcasting them to ordinary nodes in the group.

[0011] Ordinary Nodes: Other nodes in the group except the leaders, responsible for verifying the primary node's proposal and signing the vote. Each ordinary node in the system has a unique ID, denoted as n n ij , {1 ≤ i ≤ N , 1 ≤ j ≤ K}, i is the node's global unique identifier, j is the node's group identifier (i.e., which group it belongs to). Each group elects a node as the group leader, denoted as P i,j , and one of the K group leaders is selected as the system primary node, denoted as P s .

[0012] To ensure the integrity and credibility of messages during asynchronous transmission, the protocol requires that all messages to be transmitted must be digitally signed by the sending node before transmission. Therefore, a standard message containing a signature includes the following fields: message type MsgType , view number ViewNo , sender identifier SenderID , message content Content , and its digital signature σ . Define Msg = MsgType||ViewNo|| SenderID||Content| , Msg _ σ = E sk (H( Msg )), where H(·) represents the hash function, and E sk (·) represents digital signature using a private key. Therefore, the form of the message transmitted in the consensus process is Msg , Msg _ σ ​.

[0013] P s After receiving the message from the client, a proposal is generated, and then the proposal message is sent to each group leader P ij ; group leader P ij The proposal is forwarded to all ordinary nodes in the group, and the ordinary nodes only receive messages from the group leader of the group, verify the correctness of the message, sign the message as a "vote" and reply to the group leader. Group leader P ij At the same time, the votes of the ordinary nodes in the group are collected, and the threshold signature technology is used to aggregate into a group signature, and the group signature is sent to the master node P s After the proposal passes the consensus process and is unanimously approved by most nodes, P s The proposal can be submitted.

[0014] The vote is used to express that the ordinary node has received the message and completed the verification of the message. After the ordinary node completes the verification of the message, it sends a vote on the message. The format of the vote message is: <vote type, vote node ID, message signature>. Among them, the vote type includes "PREPAREVOTE" and "PRECOMMITVOTE", which represent the confirmation of the two kinds of messages respectively. Group leader P ij After receiving a specified number of votes from ordinary nodes, it will aggregate the signatures of ordinary nodes into partial aggregate signatures and send them to the master node. Among them, N_j is the number of nodes in the first j group. The master node P s After collecting a specified number of partial aggregate signatures, the final aggregate signature is generated.

[0015] The present application is based on the hierarchical and flow-based Byzantine fault-tolerant improved consensus protocol implementation method, and the consensus process is divided into three stages: PREPARE, PRECOMMIT and COMMIT stages. The three stages are as follows: S1, preparation stage PREPARE: the master node generates and broadcasts a new proposal B v (v is the view number), and after the ordinary node votes, the group leader collects the signature and aggregates it into a partial aggregate signature, and then sends it to the master node; S2, Precommit Phase: After the master node aggregates a set number of prepared votes, it generates and broadcasts a precommit message; after the ordinary nodes vote in favor, the group leader collects and aggregates some signatures again, and then sends them to the master node; S3, COMMIT phase: After the master node aggregates a set number of pre-commit tickets, it broadcasts the final commit message; after verification, ordinary nodes commit the block and jointly trigger the view switch to the next master node.

[0016] As a preferred option, step S1, the preparation stage: Master node P s Collect “ NEWVIEW” Messages, when the number reaches 2 f After adding 1, " NEWVIEW "In the message" PrepareQC Add to aggregate signature set AggQC In Chinese, its format is AggQC =< PrepareQC 1 , PrepareQC 2 ,… PrepareQC i >, PrepareQC i Indicates that by node i Provided PrepareQC .

[0017] In generation AggQC And received the client's request message ( cmds After that, the master node will aggregate the signature, client request, and new view number. ViewNo ) combined into " PREPARE "Message, i.e. Msg PREPARE =< PREPARE, ViewNo, cmds, AggQC >

[0018] The master node will this " PREPARE The message was broadcast to all group leaders, and the group leaders received it. PREPARE Upon receiving the message, immediately broadcast it to all ordinary nodes within their respective groups. The group leader and ordinary nodes, upon receiving the message... PREPARE "All messages must be accurate." PREPARE The message needs to be verified, and the verification rules are as follows: 1. Aggregated signatures are verified through public key authentication and a specified number of nodes; 2. PREPARE "In the message" ViewNo Must be greater than AggQC All of them ViewNo .

[0019] Ordinary node verification PREPARE "Send after the message is valid" PREPAREVOTE For polls of type "", the message format is: < PREPAREVOTE, i, ViewNo, > ,in, It is a node pair PREPARE "The signature of the message's hash value. Ordinary nodes will..." PREPAREVOTE "Send it to the group leader. After collecting the required number of votes, the group leader generates a partial aggregate signature, which is then sent to the master node. The master node extracts the signature and generates the aggregate signature." PrepareQC .

[0020] As a preferred option, step S2, the PRECOMMIT stage: Master node according to PrepareQC structure" PRECOMMIT The message format is as follows: Msg =< PRECOMMIT, ViewNo, PrepareQC >

[0021] The master node will " PRECOMMIT The message is broadcast to the group leader, who, upon receiving it, immediately forwards it to all ordinary nodes within their group. The ordinary nodes and the group leader receive the message. PRECOMMIT "After the message, the aggregated signature is verified using a public key and a specified number of nodes. Once verified, the message type is set to " PRECOMMITVOTE "The message format for voting for the group leader is: < PRECOMMITVOTE, i, ViewNo, > ,in, It is a node pair PRECOMMIT "The signature of the message's hash value."

[0022] "PRECOMMITVOTE” The voting message indicates that the node commits to establishing the currently proposed block as the unique block at the current height. PREPARE Similar to the previous phases, the group leader aggregates the votes into partial aggregate signatures, and the master node collects these partial aggregate signatures into a single aggregate signature. PRECOMMITQC .

[0023] As a preferred option, step S3, the COMMIT stage: Master node according to PRECOMMITQC generate "COMMIT” The message format is as follows: Msg =< COMMIT, ViewNo, PreCommitQC >

[0024] The master node sends " COMMITThe message is sent to the group leader, who then broadcasts it to the ordinary nodes. Both the group leader and the ordinary nodes receive the message. COMMIT "Submit the current block after verification."

[0025] Then, each regular node will display its known information from the highest view. PrepareQC As proof, packaged into a " NEWVIEW " The message is sent to the group leader, i.e. Msg =< NEWVIEW , PrepareQC , i >, among which i This serves as the node identifier, which is then forwarded by the group leader to the master node. P s .

[0026] Furthermore, HPBFT initialization only needs to be run once throughout the entire protocol. B 0 The initial proposal block (S1 phase) is performed before the leader generates the proposal, and the specific plan is as follows: During HPBFT initialization, the election of the master node and group leader employs a Verifiable Random Function (VRF) scheme. Each consensus node generates a unique VRF public-private key pair upon system establishment, where the private key... SK For a random scalar, the public key PK = SK × G ( G (Base point of the elliptic curve). Election is based on a random seed provided by the genesis block or the initial configuration. S Expand.

[0027] The specific process for electing a group leader is as follows: Each node in the group uses its private key. SK i For the initial seed S and group identifier G id splicing information m group = S || G id Perform VRF calculation. The calculation process is as follows: First, hash... m group to the curve point H = H 1 ( m group ), then calculate Γ i = SK i × H Finally, the VRF output value is obtained.output i = H 2 ( Γ i (A 256-bit integer). Simultaneously, the node will generate a... Γ i And zero-knowledge proof of π i Each node broadcasts its output value and proof within the group. After verifying the validity of the proof, all valid output values ​​are compared, and the node with the largest output value is elected as the leader of the group.

[0028] Master node election proceeds on this basis: each elected group leader becomes a candidate, and again uses their private key to the initial seed. S Information concatenated with the master node election identifier (such as "master"). m master = S The "master" node performs VRF computation. The computation process is similar to that described above, i.e., computation... H′ = H 1 ( m master ), Γ j ′ = SK j × H′ and obtain the output value. output j = H 2 ( Γ j ′) and corresponding proof π j Each candidate group leader broadcasts its output value and proof. After undergoing the same verification process, the group leader with the largest final output value becomes the master node of the entire system.

[0029] Furthermore, HPBFT's aggregate signature scheme is as follows: Aggregate signature public / private key initialization: In traditional asymmetric cryptography, verification N Each signatory N The signature of the message needs to be executed. N Each independent verification operation has increasing computational and communication overhead. NLinear growth. The HPBFT protocol employs an aggregation signature scheme, which merges multiple signatures into a single fixed-length signature (the same length as a single signature) using an aggregation algorithm. Verifiers only need to perform a single verification operation to confirm the validity of all signatures. This invention uses a BLS aggregation signature scheme based on bilinear pairing. Before the system starts running, a security parameter λ needs to be agreed upon. HPBFT runs an initialization function Setup(λ), specifically in the form: Setup(λ)->PP.

[0030] Generate the following common parameter PP: Algebraic structure: Choose three prime numbers of order 3. p cyclic groups G1, G2, G T There exists a bilinear pairing mapping: e: G1×G2→G T .

[0031] Generators: Select a generator g1 from G1 and a generator g2 from G2.

[0032] Hash function: Choose a cryptographically secure hash function H:{0, 1} * →G1. This function maps messages of arbitrary length to elements of group G1.

[0033] Finally, the common parameter is: PP=( p G1, G2, G T (e, g1, g2, H).

[0034] Node public / private key generation: Each node independently runs the key generation function KeyGen(PP) to generate a public-private key pair. sk , pk Private key sk It is a random large number, public key pk It is a cryptographic point calculated from the private key and the system's basic parameter g2, namely pk = sk * g2.

[0035] Message signature generation: When the proposal message m When signing, the node first uses a hash function H to hash the message. m Mapped to a hash point H( m Then use the private key. sk Perform calculations on this hash point to generate the signature σ = sk * H( m The signature is also a point on an elliptic curve.

[0036] Aggregate signature generation: The group leader collects more than two-thirds of the nodes in the group's signatures on the same proposal message m , forming a set of signatures σ 1, σ 2,..., σ n}. Then it simply adds these signature points together to generate a fixed-length partial aggregate signature: σ partial =σ 1 +σ 2 +... +σ n .

[0037] The master node collects more than two-thirds of the group leaders' generated σ partial , generating the final complete aggregate signature σ agg : σ agg = σ partial_1+ σ partial_2 +... +σ partial_L .

[0038] Aggregate signature verification: Any node can verify the aggregate signature after receiving the aggregate signature σ agg , through the verification algorithm Verify(( m i , pk i ) { i =1 to n}, σ agg ), verifying that for each node i , σ i is indeed a valid signature on the message sk i by the user holding the private key m i .

[0039] The verification algorithm receives three parts as input: n original messages m 1 , m 2 ..., m n ; n public keys corresponding to the signatures of the messages pk 1 , pk 2,..., pk n Aggregate signature to be verified σ agg ; For each message m i Use the same hash function as when signing. H Calculate its mapping to the group G 1 Hash point: H(m i ) ; Test whether the bilinear pairing equation holds: e( σ agg , g 2 ) == ∏{i=1 to n} e( H ( m i ), pk i ).

[0040] Furthermore, the present invention provides a pipeline-based parallel consensus scheme that does not require the previous proposal to be submitted before the next stage of consensus can proceed. It allows three proposals to exist simultaneously in the system, but each proposal still needs to execute the preparation phase, the precommit phase, and the commit phase in sequence.

[0041] After the HPBFT protocol is initialized, it enters a stable pipelined operation, or pipelined execution state, starting from the fourth block. At this time, there will be three proposal blocks in the system, denoted as proposal blocks. B n Proposal Block B n+1 and proposal block B n+2 The view where the proposal is submitted is denoted as . V n , V n+1 and V n+2 The proposal has a unique corresponding master node, which is denoted as the master node. Master node and master node .

[0042] The aforementioned pipeline execution refers to any proposal block B nThe proposal can be submitted only after sequentially passing through the steps S1 (preparation), S2 (pre-submission), and S3 (submission), and the three stages are respectively responsible for different master nodes. The specific pipeline execution mode of HPBFT is as follows: View V n : Master node responsible for processing the proposal block B n Step S1 preparation stage; the master node proposes a proposal block B n . The master node collects a specified number of NEWVIEW messages, and generates an aggregated signature set AggQC . After generating AggQC and receiving the request message of the client ( cmds ), the master node combines the aggregated signature, the client request, and the new view number ( ViewNo ) into "PREPARE” message.

[0043] Broadcast this PREPARE message to all group leaders, and the group leader broadcasts it to all ordinary nodes in the respective group after receiving the PREPARE message.

[0044] The ordinary node will perform the following verification after receiving a PREPARE message: 1. The message format is correct; 2. AggQC It needs to be composed of 2f+1 legal signatures; 3. "PREPARE” The new view number in the message needs to be greater than the view number of all AggQC in PrepareQC ; After the ordinary node completes the verification, it sends a B n type of vote for the proposal block PREPAREVOTE to the group leader, and the group leader forwards the vote to the master node .

[0045] View V n+1 : Master node responsible for processing the pre-submission stage of the block B n and proposing a proposal block B n+1 .

[0046] (1) Master node Propose block B n+1 Master node Responsible for processing proposal blocks B n+1 Step S1: Preparation Phase; Collect the specified number of nodes NEWVIEW After the message, an aggregate signature set is generated. AggQC In generating AggQC And received the client's request message ( cmds After that, the master node will aggregate the signature, client request, and new view number. ViewNo ) combined into "PREPARE” Message. This message is referred to as... B n+1 of "PREPARE” information.

[0047] This " PREPARE The message was broadcast to all group leaders, and the group leaders received it. PREPARE The message is then broadcast to all regular nodes within its group. After verification, the regular nodes send their responses to the proposal block. B n+1 of" PREPAREVOTE A vote of type "" is given to the group leader, who will then forward the vote to the master node. .

[0048] (2) Master node Responsible for processing blocks B n The pre-submission phase.

[0049] Master node Also responsible for processing proposal blocks B n+1 The S2 (preparation) phase. This involves collecting a specified number of proposal blocks from various nodes. B n of" PREPARE "Message" PREPAREVOTE "After voting, generate" PREPAREQC and according to PrepareQC structure" PRECOMMIT "information.

[0050] Will" PRECOMMIT The message is broadcast to the group leader, who then immediately forwards it to all ordinary nodes within their group.

[0051] Ordinary nodes receive "PRECOMMIT”The following verification will be performed after the message: 1. Is the message format correct? 2. "PRECOMMIT” The message contains PrepareQC It needs to consist of 2f+1 valid signatures; 3. "PRECOMMIT” The view number of the message must match the proposal block. B n The view numbers in the document should remain consistent. After verification, a regular node sends a response to the proposal block. B n of" PRECOMMITVOTE A vote of type "" is given to the group leader, who will then forward the vote to... .

[0052] view V n+2 : Current master node Responsible for processing proposal blocks B n Submission phase, proposal block B n+1 The pre-submission phase, and the current proposal block is proposed. B n+2 .

[0053] (1) Current master node Propose block B n+2 .

[0054] Master node Responsible for processing blocks B n+2 Step S1: Preparation Phase; Current Master Node Collect the specified number of nodes NEWVIEW After the message, an aggregate signature set is generated. AggQC In generating AggQC And received the client's request message ( cmds After that, the master node will aggregate the signature, client request, and new view number. ViewNo ) combined into "PREPARE” Message. This message is referred to as... B n+2 of "PREPARE” information.

[0055] This " PREPARE The message was broadcast to all group leaders, and the group leaders received it. PREPARE The message is then broadcast to all regular nodes within its group. After verification, the regular nodes send their responses to the proposal block. Bn+2 of" PREPAREVOTE A vote of type "" is given to the group leader, who will then forward the vote to the next master node. .

[0056] (2) Current master node Responsible for processing blocks B n+1 The pre-submission phase.

[0057] Master node Responsible for processing proposal blocks B n+1 Step S2 is the pre-preparation phase; this involves collecting a specified number of proposal blocks from various nodes. B n+1 of" PREPARE "Message" PREPAREVOTE "After voting, generate" PREPAREQC and according to PrepareQC structure" PRECOMMIT "information.

[0058] Will" PRECOMMIT The message is broadcast to the group leader, who, upon receiving it, immediately forwards it to all ordinary nodes within their group. After verification, the ordinary nodes send their responses to the proposal block. B n+1 of" PRECOMMITVOTE A vote of type "" is given to the group leader, who will then forward the vote to the next master node.

[0059] (3) Current master node Responsible for processing blocks B n The submission stage.

[0060] Master node Responsible for processing proposal blocks B n Step S3 is the submission phase; after collecting the required number of proposal blocks from the specified number of nodes. B n of" PRECOMMIT "Message" PRECOMMITVOTE "After voting, generate" PRECOMMITQC and according to PRECOMMITQC structure" COMMIT "information.

[0061] Will" COMMIT The message is broadcast to the group leader, who, upon receiving it, immediately forwards it to all ordinary nodes within their group. The ordinary nodes and the group leader then receive the message. "COMMIT” The following verification will be performed after the message: 1. Is the message format correct? 2. The COMMIT message contains PrepareQC 2f+1 legal signatures; 3. The COMMIT message view number must be consistent with the proposal block B n view number; After receiving and verifying the B n message of the proposal block COMMIT and the B n+1 message of the PRECOMMIT , the ordinary node can submit the proposal block B n .

[0062] The application also discloses a layered and pipelined Byzantine fault-tolerant improved consensus protocol implementation system for executing the method. Preparation module: used for the master node to generate and broadcast a new proposal B v , and after the ordinary node votes to approve, the group leader collects the signatures and aggregates them into partial aggregated signatures, and then sends them to the master node; wherein v is the view number; Pre-commit module: used for the master node to aggregate a certain number of preparation votes, generate and broadcast a pre-commit message; after the ordinary node votes to approve, the group leader collects and partially aggregates the signatures again, and then sends them to the master node; Commit module: used for the master node to aggregate a certain number of pre-commit votes, broadcast a final commit message; after the ordinary node verifies and submits a block, the view is switched to the next master node.

[0063] Compared with the prior art, the application has the beneficial effects that: 1. The application reduces the communication complexity by using the aggregated signature technology, and changes the signature aggregation from the original leader aggregation to the incentive node aggregation once and the leader aggregation twice, thereby accelerating the verification process.

[0064] 2. The application proposes a new Byzantine consensus protocol, adopts a layered architecture to reduce the burden of the master node and improve the consensus efficiency, designs a three-stage consensus process to shorten the consensus time, and thereby significantly improves the system throughput and horizontal scalability.

[0065] 3. The application creates a pipelined operation mode of HPBFT, can realize multi-view parallelism and efficient view switching, maintains the BFT security, and improves the parallel consensus capability. BRIEF DESCRIPTION OF DRAWINGS

[0066] Figure 1 This is a schematic diagram of the node hierarchical structure of a preferred embodiment of the present invention.

[0067] Figure 2 This is a runtime sequence diagram of the HPBFT protocol according to a preferred embodiment of the present invention.

[0068] Figure 3 This is a timing diagram of the HPBFT protocol pipeline operation in a preferred embodiment of the present invention.

[0069] Figure 4 This is a latency growth curve of the consensus protocol HPBFT compared to HotStuff in a preferred embodiment of the present invention.

[0070] Figure 5 This is a block diagram of a preferred embodiment of the present invention for a Byzantine fault-tolerant improved consensus protocol based on layering and pipeline. Detailed Implementation

[0071] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. In addition, the forms of the various structures described in the following embodiments are merely illustrative. The Byzantine Fault-Tolerant Improved Consensus Protocol Implementation Method (HPBFT) and System based on layering and pipelined methods involved in the present invention are not limited to the structures described in the following embodiments. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0072] This embodiment provides a hierarchical and pipelined Byzantine Fault-Tolerant Improved Consensus Protocol (HPBFT) implementation method. In this embodiment, as follows... Figure 1 The topology diagram illustrates the scenarios in which HPBFT's technical solution is implemented: Suppose that the consensus system consists of N nodes that can communicate with each other, where the number of Byzantine malicious nodes does not exceed f, satisfying the fault tolerance condition N ≥ 3f + 1; message transmission between nodes in the network adopts a semi-synchronous communication model, and after the global steady time (GST), the delay can be considered finite and its upper bound is known.

[0073] The N nodes in the system are evenly divided into K groups. Based on their functional differences in the consensus process, nodes are defined as follows: Primary Node: In each round of consensus, the primary node is the sole global leader elected by the system through an election mechanism. It is responsible for receiving client requests, generating consensus proposals, and driving the entire consensus process.

[0074] Group Leaders: A representative node elected within each consensus group, responsible for collecting votes from ordinary nodes within the group to form a partial aggregate signature, and sending the partial aggregate signature to the master node; responsible for receiving proposals from the master node and broadcasting them to ordinary nodes within the group.

[0075] Ordinary Nodes: Other nodes in the group besides the leader, responsible for verifying, signing, and voting on the master node's proposals. Every ordinary node in the system n It has a unique ID, denoted as n ij , {1 ≤ i ≤ N , 1 ≤ j ≤ K}, i It is a globally unique identifier for the node. j This is the node's group identifier (i.e., which group it belongs to). Each group elects a node as the group leader, denoted as . P i,j One of the K group leaders is selected as the system master node, denoted as . P s .

[0076] To ensure message integrity and reliability during asynchronous transmission, the protocol requires that all messages to be transmitted must be digitally signed by the sending node using the message's hash value before transmission. Therefore, a standard signed message includes the following fields: Message Type MsgType View Number ViewNo Sender Identifier SenderID Message content Content and its digital signature σ .definition Msg =< MsgType||ViewNo|| SenderID||Content| >, Msg _ σ =E sk (H( Msg ), where H(·) represents the hash function, E sk (·) represents digital signature using a private key. Therefore, the message format transmitted in the network during the consensus process is < Msg , Msg _ σ >

[0077] P s After receiving a message from the client, a proposal is generated, and then the proposal message is sent to each group leader. L i，j Group Leader Li，j The proposal is forwarded to all ordinary nodes in the group. Ordinary nodes only receive messages from the group leader, verify the message's correctness, sign the message as a "vote," and reply to the group leader. (Group leader) L i，j Simultaneously, votes from ordinary nodes within the group are collected, and threshold signature technology is used to aggregate them into a group signature, which is then sent to the master node. Ps After the proposal goes through the consensus process and ultimately receives unanimous approval from a majority of nodes, Ps You may submit this proposal.

[0078] Voting is used to indicate that a regular node has received and verified a message. After message verification, a regular node sends a vote. The voting message format is: <vote type, voting node ID, message signature>. The vote type includes two options: "PREPAREVOTE" and "PRECOMMITVOTE," representing confirmation of the respective message type. Group Leader L i，j Upon receiving the specified quantity After the ordinary nodes vote, it aggregates the signatures of the ordinary nodes into a partial aggregate signature and sends it to the master node. Here, N_j is the number of nodes in the j-th group. Master node P s The prescribed quantity collected After partial aggregation signatures are generated, the final aggregation signature is produced.

[0079] like Figure 2 As shown, the HPBFT consensus process in this embodiment is divided into three stages: PREPARE, PRECOMMIT, and COMMIT. Each stage is described in detail below: PREPARE phase: The main node of view Vn+1 in the diagram P s For example.

[0080] Master node P s Collect data from the Vn phase of the view, forwarded by different group leaders. NEWVIEW” Messages, when the number reaches 2 f After adding 1, " NEWVIEW "In the message" PrepareQC Add to aggregate signature set AggQC In Chinese, its format is AggQC =< PrepareQC 1 , PrepareQC 2 ,… PrepareQC i >PrepareQC i Indicates that by node i Provided PrepareQC .

[0081] In generation AggQC And received the client's request message ( cmds After that, the master node will aggregate the signature, client request, and new view number. ViewNo ) combined into " PREPARE "Message, i.e. Msg =< PREPARE, ViewNo, cmds, AggQC >

[0082] The master node will this " PREPARE The message was broadcast to all group leaders, and the group leaders received it. PREPARE Upon receiving the message, immediately broadcast it to all ordinary nodes within their respective groups. The group leader and ordinary nodes, upon receiving the message... PREPARE "All messages must be accurate." PREPARE The message needs to be verified, and the verification rules are as follows: 1. Aggregated signatures are verified through public key authentication and a specified number of nodes; 2. PREPARE "In the message" ViewNo Must be greater than AggQC All of them ViewNo .

[0083] Ordinary node verification PREPARE "Send after the message is valid" PREPAREVOTE For polls of type "", the message format is as follows: ,in, It is a node pair PREPARE "The signature of the message's hash value. Ordinary nodes will..." PREPAREVOTE "Send it to the group leader. After collecting the required number of votes, the group leader generates a partial aggregate signature, which is then sent to the master node. The master node extracts the signature and generates the aggregate signature." PrepareQC .

[0084] PRECOMMIT phase: Master node according to PrepareQC structure" PRECOMMIT The message format is as follows: Msg =< PRECOMMIT, ViewNo, PrepareQC >

[0085] The master node will " PRECOMMIT The message is broadcast to the group leader, who, upon receiving it, immediately forwards it to all ordinary nodes within their group. The ordinary nodes and the group leader receive the message. PRECOMMIT"After the message, the aggregated signature is verified using public key verification and a specified number of nodes. Once verified, the message type is '". PRECOMMITVOTE "The message format for voting for the group leader is: < PRECOMMITVOTE, i, ViewNo, > ,in, It is a node pair PRECOMMIT "The signature of the message's hash value."

[0086] "PRECOMMITVOTE” The voting message indicates that the node commits to establishing the currently proposed block as the unique block at the current height. PREPARE Similar to the previous phases, the group leader aggregates the votes into partial aggregate signatures, and the master node collects these partial aggregate signatures into a single aggregate signature. PRECOMMITQC .

[0087] COMMIT phase: Master node according to PRECOMMITQC generate "COMMIT” The message format is as follows: Msg =< COMMIT, ViewNo, PreCommitQC >

[0088] The master node sends " COMMIT The message is sent to the group leader, who then broadcasts it to the ordinary nodes. Both the group leader and the ordinary nodes receive the message. COMMIT "Submit the current block after verification."

[0089] Then, each regular node will display its known information from the highest view. PrepareQC As proof, packaged into a " NEWVIEW " The message is sent to the group leader, i.e. Msg =< NEWVIEW , PrepareQC , i >, among which i This serves as the node identifier, which is then forwarded by the group leader to the master node. P s .

[0090] “ NEWVIEW " Used as the next view Vn+2 master node to generate a new proposal.

[0091] In this embodiment, the HPBFT initialization scheme is as follows: During HPBFT initialization, the election of the master node and group leader employs a Verifiable Random Function (VRF) scheme. Each consensus node generates a unique VRF public-private key pair upon system establishment, where the private key... SK For a random scalar, the public key PK =SK x G ( G For elliptic curve base point). The election is based on a random seed provided by the genesis block or initial configuration S spread.

[0092] The specific process of group leader election is as follows: each node in the group uses its private key SK i The initial seed S and the group identifier G id Splicing information m group = S || G id VRF calculation. The calculation process is as follows: first, hash m group to the curve point H = H 1 ( m group ), then calculate Γ i = SK i x H , and finally get the VRF output value output i = H 2 ( Γ i ) (a 256-bit integer). At the same time, the node generates a proof package containing Γ i and zero-knowledge proof π i for other nodes to verify. Each node broadcasts its output value and proof in the group, and after verifying the validity of the proof, all nodes compare all legal output values, and the node with the largest output value is elected as the leader of the group.

[0093] The master node election is based on this: each elected group leader is a candidate, and again uses its private key to splice the initial seed S and the master node election identifier (such as "master"). m master = S || "master" VRF calculation. The calculation process is similar to the above, that is, calculate H′ = H 1 ( m master ), Γ j ′ = SKj X H′ and get the output value output j = H 2 ( Gamma j ') and the corresponding proof π j Each candidate group leader broadcasts its output value and proof, and after the same verification procedure, the group leader with the largest final output value becomes the master node of the entire system.

[0094] The aggregation signature scheme of HPBFT in this embodiment is as follows: Aggregation signature public and private key initialization: In traditional asymmetric cryptography, verifying N signatures of N messages by N signers requires N independent verification operations, and the calculation and communication overhead increases linearly. The HPBFT protocol uses an aggregation signature scheme, which "fuses" multiple signatures into a fixed-length signature (the same length as a single signature) through an aggregation algorithm. The verifier only needs to perform one verification operation to confirm that all signatures are valid. The present application uses a BLS aggregation signature scheme based on a bilinear pair. Before the system starts running, a security parameter lambda needs to be agreed upon. HPBFT runs an initialization algorithm Setup(lambda) to generate the following public parameters PP: Algebraic structure: Select three cyclic groups G1, G2, G T of prime order p . Among them, there is a bilinear pairing (Bilinear Pairing). e: G1xG2→G T . The bilinear pairing e is a function that takes an element in G1 and an element in G2 as input and outputs an element in G T .

[0095] Generator: Select a generator g1 of G1 and a generator g2 of G2.

[0096] Hash function: Select a cryptographically secure hash function H: {0, 1} * →G1. This function maps messages of any length to elements of the group G1.

[0097] Finally, the public parameters are: PP=( p , G1, G2, G T , e, g1, g2, H).

[0098] Node public and private key generation: Each node independently runs the key generation algorithm KeyGen(PP) to generate a pair of public and private keys sk , pk . The private key sk is a random large number, and the public key pk is a cryptographic point computed from the private key and the system base parameter g2, i.e. pk = sk * g2.

[0099] Message signature generation: When signing a proposal message m , a node first maps the message m to a hash point H( m ) using a hash function H, and then operates on the hash point using the private key sk to generate the signature σ = sk * H( m ). The signature is also a point on the elliptic curve.

[0100] Aggregate signature generation: The group leader collects the signatures of more than two-thirds of the nodes in the group on the same proposal message m , forming a signature set { σ 1, σ 2,..., σ n}. Then, it simply adds these signature points to generate a partial aggregate signature of fixed length: σ partial =σ 1 +σ 2 +... +σ n .

[0101] The master node collects the σ partial generated by more than two-thirds of the group leaders to generate the final complete aggregate signature σ agg : σ agg = σ partial_1+ σ partial_2 +... +σ partial_L .

[0102] Aggregate signature verification: Any node can verify the aggregate signature after receiving the aggregate signature σ agg , through the verification algorithm Verify(( m i , pki ) { i =1 to n}, σ agg ), verify for each node i , σ i It is indeed held by the person who possesses the private key. sk i User messages m i A valid signature.

[0103] The verification algorithm receives three parts as input: n original messages m 1 , m 2 ..., m n ; public keys for n signatures, each corresponding to a message pk 1 , pk 2 ,..., pk n Aggregate signature to be verified σ agg .

[0104] For each message m i Use the same hash function as when signing. H Calculate its mapping to the group G 1 Hash point: H(m i ) .

[0105] Test whether the bilinear pairing equation holds: e( σ agg , g 2 ) == ∏{i=1 to n} e( H ( m i ), pk i ).

[0106] In this embodiment, as Figure 3 As shown, HPBFT provides a pipelined parallel consensus scheme that does not require the previous proposal to be committed before the next stage of consensus can proceed. It allows three proposals to exist in the system simultaneously, but each proposal still needs to execute the preparation phase, the precommit phase, and the commit phase in sequence.

[0107] After the HPBFT protocol is initialized, it enters a stable pipeline running state from the fourth block, at which time there will be three proposal blocks in the system, denoted as proposal block B n , proposal block B n+1 , and proposal block B n+2 ; the view in which the proposal is proposed is denoted as view V n , V n+1 , and V n+2 ; the proposal has a unique corresponding master node, denoted as master node , master node , and master node .

[0108] The specific pipeline execution mode of HPBFT is as follows: View V n : Master node proposes proposal block B n . After the master node collects a specified number of NEWVIEW messages, it generates an aggregated signature set AggQC . After generating AggQC and receiving a request message from the client ( cmds ), the master node combines the aggregated signature, the client request, and the new view number ( ViewNo ) into a "PREPARE” message.

[0109] This PREPARE message is broadcast to all group leaders, and after the group leaders receive the PREPARE message, they broadcast it to all ordinary nodes in their respective groups.

[0110] After an ordinary node receives a PREPARE message, it performs the following verification: 1. The message format is correct; 2. AggQC It needs to be composed of 2f+1 legal signatures; 3. "PREPARE” The new view number in the message needs to be greater than the view number of all AggQC in PrepareQC ; After the ordinary node completes the verification, it sends a PREPAREVOTE message to the proposal block B n .A vote of type "" is given to the group leader, who will then forward the vote to the master node. .

[0111] view V n+1 : Master node Responsible for processing blocks B n The pre-submission phase and the proposal block are submitted. B n+1 .

[0112] Master node Propose block B n+1 .

[0113] Collect the specified number of nodes NEWVIEW After the message, an aggregate signature set is generated. AggQC In generating AggQC And received the client's request message ( cmds After that, the master node will aggregate the signature, client request, and new view number. ViewNo ) combined into "PREPARE” Message. This message is referred to as... B n+1 of "PREPARE" information.

[0114] This " PREPARE The message was broadcast to all group leaders, and the group leaders received it. PREPARE The message is then broadcast to all regular nodes within its group. After verification, the regular nodes send their responses to the proposal block. B n+1 of" PREPAREVOTE A vote of type "" is given to the group leader, who will then forward the vote to the master node. .

[0115] Master node Responsible for processing blocks B n The pre-submission phase.

[0116] Collect a specified number of proposal blocks from the nodes. B n of" PREPARE "Message" PREPAREVOTE "After voting, generate" PREPAREQC and according to PrepareQC structure" PRECOMMIT "information.

[0117] Will" PRECOMMITThe message is broadcast to the group leader, who then immediately forwards it to all ordinary nodes within their group.

[0118] Ordinary nodes receive "PRECOMMIT" The following verification will be performed after the message: 1. Is the message format correct? 2. "PRECOMMIT" The message contains PrepareQC It needs to consist of 2f+1 valid signatures; 3. "PRECOMMIT" The view number of the message must match the proposal block. B n The view numbers in the document should remain consistent. After verification, a regular node sends a response to the proposal block. B n of" PRECOMMITVOTE A vote of type "" is given to the group leader, who will then forward the vote to... .

[0119] view V n+2 : Current master node Responsible for processing proposal blocks B n Submission phase, proposal block B n+1 The pre-submission phase, and the current proposal block is proposed. B n+2 .

[0120] Current master node Propose block B n+2 .

[0121] Current master node Collect the specified number of nodes NEWVIEW After the message, an aggregate signature set is generated. AggQC In generating AggQC And received the client's request message ( cmds After that, the master node will aggregate the signature, client request, and new view number. ViewNo ) combined into "PREPARE" Message. This message is referred to as... B n+2 of "PREPARE" information.

[0122] This " PREPARE The message was broadcast to all group leaders, and the group leaders received it. PREPARE The message is then broadcast to all regular nodes within its group. After verification, the regular nodes send their responses to the proposal block.B n+2 of" PREPAREVOTE A vote of type "" is given to the group leader, who will then forward the vote to the next master node. .

[0123] Current master node Responsible for processing blocks B n+1 The pre-submission phase.

[0124] Collect a specified number of proposal blocks from the nodes. B n+1 of" PREPARE "Message" PREPAREVOTE "After voting, generate" PREPAREQC and according to PrepareQC structure" PRECOMMIT "information.

[0125] Will" PRECOMMIT The message is broadcast to the group leader, who, upon receiving it, immediately forwards it to all ordinary nodes within their group. After verification, the ordinary nodes send their responses to the proposal block. B n+1 of" PRECOMMITVOTE A vote of type "" is given to the group leader, who will then forward the vote to the next master node.

[0126] Current master node Responsible for processing blocks B n The submission stage.

[0127] Collect a specified number of proposal blocks from the nodes. B n of" PRECOMMIT "Message" PRECOMMITVOTE "After voting, generate" PRECOMMITQC and according to PRECOMMITQC structure" COMMIT "information.

[0128] Will" COMMIT The message is broadcast to the group leader, who, upon receiving it, immediately forwards it to all ordinary nodes within their group. The ordinary nodes and the group leader then receive the message. "COMMIT" The following verification will be performed after the message: 1. Is the message format correct? 2. COMMIT The message contained PrepareQC It needs to consist of 2f+1 valid signatures; 3. COMMIT The view number of the message must match the proposal block.B n The view number in the message is consistent with the view number in the message The common node can submit the proposal block B n The message of the common node COMMIT The message of the common node B n+1 The message of the common node PRECOMMIT The message of the common node B n The following experiments are conducted to verify the significant advantages of the technical scheme of the present application.

[0129] The experiment is based on a 13th Gen Intel(R) Core(TM) i5-13500HX (2.50 GHz) processor, 16.0GB memory, and a program written in golang to compare PBFT, HotStuff, and HPBFT in communication experiments under different numbers of nodes. The nodes communicate with each other using TCP, and the transmission bandwidth is set to 100MB.

[0130] The experimental results are shown in Figure 4 From the figure, it can be seen that the latency of PBFT is square level growth far greater than HotStuff and HPBFT. The consensus protocol HPBFT of the present application has a more flat latency growth curve than HotStuff, proving the superiority of the protocol of the present application.

[0131] As shown in Figure 5 The embodiment discloses an improved Byzantine fault-tolerant consensus protocol implementation system based on layering and pipelining, which is used to execute the above method, and includes the following modules: Preparation module: used for the master node to generate and broadcast a new proposal B v After the common node votes and approves, the group leader collects the signatures and aggregates them into partial aggregated signatures, and then sends them to the master node; wherein v is the view number; Pre-commit module: used for the master node to aggregate a certain number of preparation votes, generate and broadcast a pre-commit message; after the common node votes and approves, the group leader collects and partially aggregates the signatures again, and then sends them to the master node; Commit module: used for the master node to aggregate a certain number of pre-commit votes, broadcast a final commit message; after the common node verifies and submits the block, the next master node is triggered together to switch the view.

[0132] Other contents of the present embodiment can refer to the above method embodiment.

[0133] It is readily apparent to a person skilled in the art that the scope of protection of the present application is obviously not limited to the specific embodiments described above. Any equivalent changes or replacements of the relevant technical features made by a person skilled in the art without departing from the principles of the present application shall fall within the scope of protection of the present application.

Claims

1. A layered and pipelined Byzantine fault-tolerant improved consensus protocol implementation method, characterized by: The specific steps are as follows: S1. PREPARE Phase: The master node generates and broadcasts a new proposal. B v After the ordinary nodes vote and approve, the group leader collects the signatures and aggregates them into a partial aggregate signature, which is then sent to the master node; where v is the view sequence number; S2, Precommit Phase: After the master node aggregates a set number of prepared votes, it generates and broadcasts a precommit message; after the ordinary nodes vote in favor, the group leader collects and partially aggregates the signatures again, and then sends them to the master node; S3, COMMIT phase: After the master node aggregates a set number of pre-commit tickets, it broadcasts the final commit message; after verification, ordinary nodes commit the block and jointly trigger the view switch to the next master node.

2. The method for implementing a Byzantine fault-tolerant improved consensus protocol based on layering and pipelining as described in claim 1, characterized in that, Step S1 is as follows: Master node P s Collect new views from different group leaders NEWVIEW Messages, when the number reaches 2 f After +1, NEWVIEW Certificate preparation in the message PrepareQC Add to aggregate signature set AggQC middle, PrepareQC i Indicates that by node i Provided PrepareQC ; In generation AggQC And received the client's request message. cmds Afterwards, the master node will aggregate the signature, client request, and new view number. ViewNo Combined into PREPARE Message, i.e. Msg PREPARE =< PREPARE, ViewNo, cmds, AggQC >; The master node will PREPARE The message is broadcast to all group leaders, and the group leaders receive it. PREPARE After receiving the message, it is broadcast to all ordinary nodes within their respective groups; the group leader and ordinary nodes, upon receiving it... PREPARE All messages must be correct PREPARE Message verification, verification by ordinary nodes. PREPARE Once the message is valid, send a message indicating you are ready to vote. PREPAREVOTE The message format for this type of vote is: ,in, It is a node pair PREPARE The signature of the message's hash value; ordinary nodes will PREPAREVOTE The data is sent to the group leader, who collects a set number of votes and generates a partial aggregate signature. The group leader then sends this partial aggregate signature to the master node, which extracts the signature and generates the aggregate signature. PrepareQC .

3. The method for implementing a Byzantine fault-tolerant improved consensus protocol based on layering and pipelining as described in claim 2, characterized in that the steps are as follows: In S1, the group leader and ordinary nodes... PREPARE The rules for message verification are as follows: 1) Aggregated signatures, with signatures verified through public key authentication and a specified number of nodes; 2) PREPARE In the message ViewNo Must be greater than AggQC All of them ViewNo .

4. The implementation method of the Byzantine fault-tolerant improved consensus protocol based on layering and pipelining as described in claim 2 or 3, characterized in that, Step S2 is as follows: The master node, according to... PrepareQC Constructing precommit PRECOMMIT The message format is as follows: Msg =< PRECOMMIT, ViewNo, PrepareQC >; The master node will PRECOMMIT The message is broadcast to the group leader, who then forwards it to all ordinary nodes within the group; the ordinary nodes and the group leader receive the message. PRECOMMIT After the message is sent, the aggregated signature is verified using a public key and a specified number of nodes; once verified, the message type is "pre-commit vote". PRECOMMITVOTE Vote for the group leader; the message format is: ,in, It is the signature of the node's hash value of the PRECOMMIT message; PRECOMMITVOTE The voting message indicates that the node commits to establishing the current proposal block as the unique block at the current height; the group leader aggregates the votes into partial aggregate signatures, and the master node collects the partial aggregate signatures into a single aggregate signature. PRECOMMITQC .

5. The method for implementing the Byzantine fault-tolerant improved consensus protocol based on layering and pipelining as described in claim 4, characterized in that, Step S3 is as follows: The master node, according to... PRECOMMITQC Generate Submission COMMIT The message format is as follows: Msg = < COMMIT, ViewNo, PreCommitQC >; Master node sends COMMIT The message is sent to the group leader, the group leader broadcasts it to the ordinary nodes, and the group leader and ordinary nodes receive it. COMMIT And submit the current block after verification; Each ordinary node displays what it knows from the highest view. PrepareQC As proof, packaged into one NEWVIEW The message is sent to the group leader, i.e. Msg =< NEWVIEW , PrepareQC , i > Forwarded by the group leader to the master node P s .

6. The method for implementing a Byzantine fault-tolerant improved consensus protocol based on layering and pipelining as described in any one of claims 1-5, characterized in that, Before the master node generates the proposal in step S1 of the initial proposal block, an initialization is performed, as follows: The election of the master node and group leader adopts the Verifiable Random Function (VRF) scheme. Each node in the group uses its private key to calculate the VRF output using the concatenation information of the initial seed and the group identifier. The node with the largest output value is elected as the group leader. Each elected group leader competes for the master node identity again through VRF calculation. Finally, the group leader with the largest output value becomes the master node.

7. The method for implementing a Byzantine fault-tolerant improved consensus protocol based on layering and pipelining as described in claim 6, characterized in that, The aggregate signature process is as follows: Aggregate signature public / private key initialization: Define a safety parameter λ, run the initialization algorithm Setup(λ), and generate the following common parameter PP: Algebraic structure: Choose three prime numbers of order 3. p Cyclic groups G1, G2, G T There exists a bilinear pair mapping: e: G1 × G2 → G T ; Generators: Select one generator g1 from G1 and one generator g2 from G2; Hash function: Choose a cryptographically secure hash function H:{0, 1} * →G1; This function maps messages of arbitrary length to elements of group G1; Finally, the common parameter is: PP=( p G1, G2, G T (e, g1, g2, H); Node public / private key generation: Each node independently runs the KeyGen(PP) key generation algorithm to generate a public-private key pair. sk , pk Private key sk It is a random number, public key pk It is a cryptographic point calculated from the private key and the system's basic parameter g2, namely pk = sk * g2; Message signature generation: When the proposal message m When signing, the node first uses a hash function H to hash the message. m Mapped to a hash point H( m Then use the private key. sk Perform calculations on this hash point to generate the signature σ = sk * H( m The signature is a point on an elliptic curve. Aggregated signature generation: The group leader collects messages from more than a set number of nodes within the group regarding the same proposal. m The signatures constitute a signature set { σ 1, σ 2, ..., σ n }; Add these signature points together to generate a fixed-length partial aggregate signature: σ partial = σ 1 + σ 2 + ... + σ n ; The master node collects more than two-thirds of the group leaders generated. σ partial Generate the final complete aggregate signature. σ agg : σ agg = σ partial_1+ σ partial_2 + ... + σ partial_L ; Aggregate signature verification: The node receives the aggregate signature σ agg The aggregated signature is then verified using the Verify(( m i , pk i ){ i =1 to n }, σ agg ), verify for each node i , σ i It is held by the person who holds the private key sk i User messages m i A valid signature.

8. The method for implementing a Byzantine fault-tolerant improved consensus protocol based on layering and pipelining as described in claim 7, characterized in that, After initialization, execution begins from the fourth block. At this point, there are three proposal blocks, denoted as proposal blocks. B n Proposal Block B n +1 and proposal block B n+2 The view where the proposal is submitted is denoted as . V n , V n+1 and V n+2 The proposal has a unique corresponding master node, which is denoted as the master node. Master node and master node .

9. The method for implementing a Byzantine fault-tolerant improved consensus protocol based on layering and pipelining as described in claim 8, characterized in that, The aforementioned pipelined execution means that any proposal block can only be submitted after passing through three stages: step S1, step S2, and step S3, with each of these three stages being handled by a different master node; specifically as follows: view V n : Master node Responsible for processing proposal blocks B n Step S1: Preparation Phase; Master Node Propose block B n ; The master node collects a specified number of nodes. NEWVIEW After the message, an aggregate signature set is generated. AggQC In the generation AggQC And received the client's request message. cmds Afterwards, the master node will aggregate the signature, client request, and new view number. ViewNo Combined into PREPARE information; This PREPARE The message is broadcast to all group leaders, and the group leaders receive it. PREPARE The message is then broadcast to all ordinary nodes within its respective group; When a normal node receives a message PREPARE Perform the following verification after the message: 1) Is the message format correct? 2) AggQC It needs to consist of 2f+1 valid signatures; 3) PREPARE The new view number in the message needs to be greater than AggQC All PrepareQC The view number; After the ordinary node completes the verification, it sends the proposal block. B n of PREPAREVOTE The vote is sent to the group leader, who then forwards it to the master node. ; view V n+1 : Master node Responsible for processing blocks B n The pre-submission phase and the proposal block are proposed. B n+1 ; (1) Master node Responsible for processing proposal blocks B n+1 Step S1: Preparation Phase; Collect the specified number of nodes NEWVIEW After the message, an aggregate signature set is generated. AggQC In the generation AggQC And received the client's request message. cmds Afterwards, the master node will aggregate the signature, client request, and new view number. ViewNo Combined into PREPARE Message; this message is referred to as B n+1 of PREPARE information; This PREPARE The message is broadcast to all group leaders, and the group leaders receive it. PREPARE The message is then broadcast to all regular nodes within its group; after verification, the regular nodes send a response to the proposal block. B n+1 of PREPAREVOTE The vote is given to the group leader, who then forwards it to the master node. ; (2) Master node Responsible for processing proposal blocks B n , B n+1 The pre-submission phase; Collect a set number of proposal blocks from nodes. B n of PREPARE message PREPAREVOTE After voting, generate PREPAREQC and according to PrepareQC structure PRECOMMIT information; Will PRECOMMIT The message is broadcast to the group leader, who then forwards it to all ordinary nodes within their group. Ordinary nodes receive PRECOMMIT Perform the following verification after the message: 1) Is the message format correct? 2) PRECOMMIT The message contains PrepareQC It needs to consist of 2f+1 valid signatures; 3) PRECOMMIT The view number of the message must match the proposal block. B n The view numbers in the document should remain consistent. After verification, a regular node sends a response to the proposal block. B n of PRECOMMITVOTE The type of vote is given to the group leader, who will then forward the vote to... ; view V n+2 : Current master node Responsible for processing proposal blocks B n Submission phase, proposal block B n+1 The pre-submission phase, and the current proposal block is proposed. B n+2 ; (1) Current master node Responsible for processing blocks B n+2 Step S1: Preparation Phase; Current master node Collect the specified number of nodes NEWVIEW After the message, an aggregate signature set is generated. AggQC In the generation AggQC And received the client's request message. cmds Afterwards, the master node will aggregate the signature, client request, and new view number. ViewNo Combined into PREPARE The message, this message is called B n+2 of PREPARE information; This PREPARE The message is broadcast to all group leaders, and the group leaders receive it. PREPARE The message is then broadcast to all ordinary nodes within its respective group; after verification, the ordinary nodes send their responses to the proposal block. B n+2 of PREPAREVOTE The vote is cast for the group leader, who then forwards it to the next master node. ; (2) Current master node Responsible for processing proposal blocks B n+1 Step S2: Preparatory Stage; Collect a specified number of proposal blocks from the nodes. B n+1 of PREPARE message PREPAREVOTE After voting, generate PrepareQC and according to PrepareQC structure PRECOMMIT information; Will PRECOMMIT The message is broadcast to the group leader, who then forwards it to all ordinary nodes within their group. After verification, the ordinary nodes send their responses to the proposal block. B n+1 of PRECOMMITVOTE The vote is cast for the group leader, who then forwards it to the next master node. (3) Current master node Responsible for processing proposal blocks B n Step S3: Submission Phase; Collect a specified number of proposal blocks from the nodes. B n of PRECOMMIT message PRECOMMITVOTE After voting, generate PRECOMMITQC and according to PRECOMMITQC structure COMMIT information; Will COMMIT The message is broadcast to the group leader, who then forwards it to all ordinary nodes within their group; the ordinary nodes and the group leader receive the message. COMMIT Perform the following verification after the message: 1) Is the message format correct? 2) COMMIT The message contains PrepareQC It needs to consist of 2f+1 valid signatures; 3) COMMIT The view number of the message must match the proposal block. B n The view numbers in the document should remain consistent. Ordinary nodes receive and verify the proposal block B n of COMMIT and B n+1 of PRECOMMIT After the message, submit the proposal block. B n .

10. A system for implementing a hierarchical and pipelining Byzantine fault-tolerant improved consensus protocol, for performing the method as described in any one of claims 1-9, characterized in that, Includes the following modules: Preparation module: Used by the master node to generate and broadcast new proposals. B v After the ordinary nodes vote and approve, the group leader collects the signatures and aggregates them into a partial aggregate signature, which is then sent to the master node; where v is the view sequence number; The pre-commit module is used by the master node to generate and broadcast a pre-commit message after a set number of pre-votes are aggregated. After the ordinary nodes vote in favor, the group leader collects and partially aggregates the signatures again, and then sends them to the master node. The commit module is used by the master node to aggregate a set number of pre-commit tickets and broadcast the final commit message; ordinary nodes verify the commit and commit the block, and jointly trigger the view switch to the next master node.

Images