A parallel strategy-based blockchain PBFT consensus implementation method

Abstract

This invention discloses a blockchain PBFT consensus implementation method based on a parallel strategy, comprising: S1, after sending a consensus message, before receiving several message votes, the primary replica generates a block at regular intervals within the consensus window and broadcasts it; S2, when the primary replica receives voting messages for the consensus block from several different replicas, after successful verification, aggregates the signatures into a complete LockedQC signature and generates a Diss message, which is broadcast to all backup replicas; S3, when a backup replica receives the Diss message, after successful verification, votes on the consensus and sends the voting result of the Agg message to the primary node; S4, in the event of consensus failure, the primary replica is switched using a view switching protocol, and the view-change process and the new-view process are executed to complete the view switch. This invention achieves parallel consensus and improves consensus efficiency.

Description

Technical Field

[0001] This invention belongs to the field of cyberspace security technology, and in particular relates to a blockchain PBFT consensus implementation method based on a parallel strategy. Background Technology

[0002] PBFT consensus was initially built upon State Machine Replication (SMR), encompassing a consensus protocol and a view switching protocol. In the PBFT consensus algorithm, the primary replica sorts the collected requests, meaning the requests are already ordered before consensus is reached. However, the consensus process for requests is unordered; a node might reach consensus and submit a request with a higher sequence number before receiving a request with a lower sequence number. If a Byzantine fault occurs in the primary replica or network instability occurs, the new primary replica in the view switching protocol transmits the submitted requests to the new view, while other unsubmitted requests are ignored and replaced with empty requests. Unlike the PBFT message execution queue, the blockchain's block queue is connected by hash values; each block header contains a hash digest of the parent block header. This hash value connection is a characteristic of blockchain, utilizing the collision resistance of hash functions to ensure the blockchain's immutability and non-forgeability. Directly applying the PBFT algorithm to blockchain inevitably leads to compatibility issues. SMR-based PBFT allows replacing lost requests with no-operation requests during view switching, a strategy that is intolerable for blockchains, which do not allow the loss of intermediate blocks. Therefore, resolving this compatibility issue is crucial in PBFT-based consensus algorithms. In most current work, this compatibility problem has been overlooked and never explicitly addressed. This paper compares the complete execution processes of the PBFT algorithm and blockchain consensus to identify the root cause. PBFT comprises six phases, with the pre-preparation, preparation, and commit phases being out of order. In the execution phase, requests are only executed in an ordered manner after all previous requests have been committed. Simultaneously, in the commit phase, requests can be passed across views and committed on non-Byzantine copies of subsequent views. Therefore, it is precisely this out-of-order cross-view characteristic in the commit phase that can lead to the loss of preceding requests. Blockchains, due to their chain-like structure, are ordered from block generation onwards. Therefore, the blockchain consensus process is ordered across all phases; that is, the blockchain waits for the consensus of the previous block to be uploaded before starting the consensus process for the next block. This is simply called a serial consensus process.

[0003] Therefore, to ensure the PBFT consensus process is compatible with the characteristics of blockchain consensus, it needs to degenerate from a globally parallel execution process to a serial consensus process. A serial consensus can be achieved by allowing the entire PBFT execution process to run in an orderly manner; we call this type of PBFT "serial PBFT." This allows for direct integration of serial PBFT into the blockchain without any empty operation requests. This method is also implicitly adopted by most current PBFT-based blockchain solutions. However, serial PBFT-based blockchain consensus algorithms clearly suffer from inefficiency. How to restore the parallelism of serial PBFT blockchain consensus algorithms and improve consensus efficiency is a crucial problem that urgently needs to be solved. Summary of the Invention

[0004] To address the aforementioned technical issues, this invention proposes a blockchain PBFT consensus implementation method based on a parallel strategy. By utilizing a threshold signature scheme, a pipeline strategy, and a consensus window strategy, parallel consensus is achieved, thereby improving consensus efficiency.

[0005] To achieve the above objectives, this invention provides a blockchain PBFT consensus implementation method based on a parallel strategy, comprising:

[0006] S1. After the primary replica sends out the Dis consensus message, before receiving several Agg consensus message votes, it generates a block at regular intervals in the consensus window and broadcasts it out. Several blocks are generated in the consensus window. The consensus message is for the last block in the consensus window to start consensus. The other blocks in the consensus window use a hash chain to ensure security.

[0007] S2. When the primary replica receives Agg voting messages for the consensus block from several different replicas, it aggregates the signatures into a complete LockedQC signature after successful verification and generates a Diss message to broadcast to all backup replicas. The LockedQC signature is contained in the Diss message.

[0008] S3. When the backup replica receives the Dis message, it verifies the success and votes on the consensus, and sends the voting result of the Agg message to the master node.

[0009] S4. In the event of consensus failure, switch the primary replica using the view switching protocol and execute the view-change and new-view processes to complete the view switch.

[0010] According to the PBFT consensus implementation method based on parallel strategy provided by the present invention, when the primary replica receives Agg voting messages for the consensus block from several different replicas, after successful verification, the signatures are aggregated into a complete LockedQC signature, and a Diss message is generated and broadcast to all backup replicas.

[0011] The primary replica verifies each received Agg voting message. The primary replica aggregates the voting signatures from several different replicas into a complete LockedQC signature using a threshold signature aggregation function. It then generates a Diss message based on the last broadcast block and broadcasts the Diss message to all backup replicas.

[0012] According to the PBFT consensus implementation method based on parallel strategy provided by the present invention, when the backup replica receives the Dis message, after successful verification, it votes on the consensus and sends the voting result of the Agg message to the master node, the method includes:

[0013] When the backup copy receives the Diss message, it checks block B. i The system checks if the preceding block is complete. If it is incomplete, other copies are accepted. Once the blockchain is complete, it proceeds to block B. i During the voting process, an Agg message is generated and sent to the primary replica. After the message is sent, the backup replica continues to generate transactions, accept transactions, receive and verify blocks. When the primary replica has collected a number of voting signatures, it enters the broadcast phase.

[0014] According to the parallel strategy-based blockchain PBFT consensus implementation method provided by the present invention, the method for switching the primary replica using the view switching protocol includes:

[0015] After the backup replica sends the Agg message to the primary replica, it starts a consensus timer. When it receives the Diss message, it stops the consensus timer. If the consensus timer times out, the backup replica starts a view switch. When the view switch starts, a switch timer is started. The switch timer only stops when the switch ends. If it times out, the next round of view switch begins.

[0016] According to the PBFT consensus implementation method based on parallel strategy provided by the present invention, the timing time of the switching timer needs to meet the condition that the timing time of the switching timer in each round of view switching is longer than the time of the previous round.

[0017] According to the parallel strategy-based blockchain PBFT consensus implementation method provided by the present invention, the method for executing the view-change process includes:

[0018] If the consensus timer of the backup copy of the current view times out, the backup copy of the current view enters the view switching process and switches the view to the next view. The backup copy of the current view only accepts view-change messages and new-view messages, and sends a view-change message to the primary copy of the next view, while starting the switching timer.

[0019] According to the parallel strategy-based blockchain PBFT consensus implementation method provided by the present invention, the method for executing the new-view process includes:

[0020] When the primary replica of the next view receives several valid view-change messages from other replicas, it selects the LockedQC with the largest view size or the largest N when the views are the same from the several view-change messages and message logs, and becomes the MaxLockedQC; the primary replica of the next view generates and broadcasts the next block according to the block corresponding to the MaxLockedQC, and then broadcasts a new-view message to all other replicas.

[0021] According to the PBFT consensus implementation method based on parallel strategy provided by the present invention, after the backup replica receives the new-iew message, it needs to calculate the MaxLockedQC using QCs and check whether the next block is based on the block corresponding to MaxLockedQC. The determination method includes:

[0022] If the correspondence is correct, the backup copy enters the consensus protocol collection process for the next view and sends the Agg message, where the new-view message is equivalent to the Diss message of the consensus protocol; if the correspondence is incorrect, it is rejected and continues to wait; if the consensus timer for switching times out, the next round of view switching is started and the switching timer is restarted.

[0023] Technical effects of the invention:

[0024] (1) This invention explicitly points out the compatibility problems that arise from the integration of blockchain and PBFT consensus, analyzes the underlying principles, and provides ideas for solutions.

[0025] (2) The threshold signature and pipeline technology used in this invention have only been used in the four-phase consensus hotstuff protocol. Previous studies have not used them in the two-phase consensus serial PBFT protocol. Therefore, this invention uses the threshold signature and pipeline strategy to implement parallel PBFT.

[0026] (3) The parallel strategy adopted in this invention is a comprehensive strategy of threshold signature, pipeline strategy and consensus window strategy. Based on threshold signature and pipeline strategy, it makes full use of the idle time of the primary replica and uses consensus window strategy to improve the parallelism of consensus to a greater extent, solve the problem of low consensus performance and expand the throughput of consensus. Attached Figure Description

[0027] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0028] Figure 1 This is a consensus window diagram of a blockchain PBFT consensus implementation method based on a parallel strategy, according to an embodiment of the present invention.

[0029] Figure 2 This is a consensus phase diagram of a blockchain PBFT consensus implementation method based on a parallel strategy, according to an embodiment of the present invention. Detailed Implementation

[0030] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0031] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0032] This embodiment provides a blockchain PBFT consensus implementation method based on a parallel strategy, including: a block generation and broadcasting phase, a consensus phase broadcasting process, a consensus phase collection process, and a view switching phase. The block generation and broadcasting phase occurs before each round of consensus; blocks are the objects of consensus, and each backup replica needs to collect blocks proposed by the primary replica. The consensus phase is the main work, consisting of two processes: a broadcasting process and a collection process. The broadcasting and collection processes are how the primary replica and backup replicas exchange messages to reach consensus. The view switching phase only occurs when consensus fails, and its main purpose is to switch the primary replica to ensure system liveness. Figure 1 As shown, the implementation method includes the following steps:

[0033] S1. After sending the consensus message, the primary replica will generate a block and broadcast it at regular intervals within the consensus window before receiving 2f+1 message votes. Therefore, several blocks are generated within the consensus window. The consensus message initiates consensus for the last block in the consensus window, and the other blocks in the consensus window utilize a hash chain to ensure security.

[0034] S2, The primary replica receives consensus block B from 2f+1 different replicas. i-1 When a voting message is received, after successful verification, the signature is aggregated into a complete LockedQC signature using a threshold signature aggregation function, and then generated. <DISS,V,N,D(B i ), LockedQC> broadcasts to all backup copies.

[0035] S3. When the backup replica receives the Dis message, it will vote on this consensus after successful verification, and then... <AGG,V,N,D(B i The voting results are sent to the master node.

[0036] S4. In the event of consensus failure, switch the primary replica using the view switching protocol and execute the view-change and new-view processes to complete the view switch.

[0037] As can be seen from the above technical solution, this invention applies threshold signatures, pipeline strategies, and consensus window strategies to the PBFT consensus mechanism in blockchain. The PBFT consensus implementation method based on a parallel strategy includes a block generation and broadcasting phase, a broadcasting process during the consensus phase, a collection process during the consensus phase, and a view switching phase. First, the master node continuously produces blocks within the consensus window until it collects 2f+1 voting signatures; after collection, it stops producing blocks. Second, the master node generates a DISS consensus message based on the last block in the consensus window and the aggregated LockedQC signature, and broadcasts it. Then, the backup replica generates its own voting message based on the DISS message sent by the master replica, signs it using threshold signature technology, and sends the AGG message to the master replica. The normal working process continuously repeats the above process. Finally, if the system consensus times out, causing the system to become inactive, all replicas will use view switching to complete the master replica rotation.

[0038] This invention presents a blockchain PBFT consensus implementation method based on a parallel strategy. It provides a simple and flexible consensus algorithm, primarily employing a combined parallel strategy of threshold signature, pipelined strategy, and consensus window strategy to achieve consensus, thus solving the inefficiency problem of serial PBFT consensus. The consensus phase process is as follows: Figure 2 As shown. To ensure the liveness of the consensus, a view switching phase was also designed to provide a method for switching the primary replica in the event of consensus failure.

[0039] This invention inherits the PBFT-based blockchain consensus algorithm. During the block consensus phase, the primary replica selects a certain number of transactions from the transaction pool to add to the blocks that need to reach consensus in this round, and generates and broadcasts consensus messages for the blocks. The consensus algorithm ensures that all fault-free replicas upload the same blocks to the chain in the same order. The primary replica and backup replicas will reach consensus on the current block before reaching consensus on the next round of blocks.

[0040] Unlike the cryptographic model used in traditional PBFT, this invention employs a (k, n) threshold signature cryptography scheme. Each of the n replicas holds the same public key K and a distinct private key Si. Each backup replica i can use its private key to sign message m, thus forming a partial signature. <m>If the primary copy collects k distinct partial signatures, these k partial signatures can be aggregated to form the complete signature LockeQC. Other backup copies can then use the public key to verify the validity of the complete signature.

[0041] This invention provides a detailed execution scheme for the block phase, consensus phase, and view switching phase. The blocks generated in the block phase are the objects of consensus in the consensus algorithm. The goal of consensus in this phase is to initiate consensus on the last block in the consensus window. The consensus phase is the normal execution process of the consensus algorithm, utilizing broadcasting and collection processes to complete the task. Each block needs to go through three state transitions: pre-prepared, prepared, and committed, to complete block consensus. The view switching protocol is an abnormal phase of the consensus algorithm. When the primary replica experiences a Byzantine fault or network fluctuations leading to a timeout, the remaining replicas will trigger a view switching to reselect a new primary replica to assume consensus responsibilities.

[0042] Traditional PBFT algorithms employ a garbage collection protocol to prevent the message log from growing indefinitely. If replicas directly discard messages related to executed requests, they may discard LockedQC proofs, which are crucial for consensus security. To ensure secure message discarding, a checkpointing mechanism is needed to guarantee state correctness. This invention does not require the garbage collection protocol (checkpointing mechanism) of traditional PBFT. Because all replicas retain the latest LockedQC signature they receive while discarding all older LockedQC signatures, and due to the blockchain's hash chain structure, a single, up-to-date LockedQC signature ensures the blockchain's security. Specifically, the following steps are included:

[0043] Step 1: While executing the consensus algorithm, the primary replica continuously receives transactions from other replicas and adds them to the transaction pool. During the consensus window, it packages transactions into blocks at regular intervals and broadcasts the blocks. Meanwhile, backup replicas continuously receive blocks from the primary replica and verify their correctness.

[0044] The consensus protocol is accomplished using broadcasting and collection processes. The broadcasting process primarily involves the primary replica transmitting the voting proofs of the previous block's consensus message and the consensus message for the current block. The collection process mainly involves the primary replica collecting the voting messages for the current block. Figure 2 This demonstrates the consensus phase process, in block B. i To B i-1 There are many blocks, but the consensus message only applies to the last block in the consensus window, not to the other blocks.

[0045] Step Two:

[0046] (1) Broadcast process

[0047] Main copy broadcast B i-1 After receiving the Diss message, B was received from 2f+1 replicas. i-1 Before receiving the Agg message, the primary replica continues to complete transaction generation and collection, block generation and broadcasting, etc. When the primary replica receives consensus block B from 2f+1 different replicas... i-1 Upon receiving a voting message, the primary replica interrupts the block generation process and instead executes the consensus broadcast process. First, the primary replica verifies each received voting message. Next, the primary replica aggregates the voting signatures from 2f+1 different replicas into a complete LockedQC signature. Then, based on the last broadcast block B... i A Diss message is generated and broadcast to other backup replicas. The Diss message takes the following form: <DISS,V,N,D(B i ), LockedQC>, where V represents the view number of the sent message, N represents the consensus sequence number, and D(B i ) represents block B i The summary, LockedQC, indicates block B. i-1 The LockedQC signature is obtained. After the broadcast ends, the primary replica continues to generate transactions, collect transactions, generate blocks, and broadcast blocks. The backup replica enters the collection phase after receiving the primary replica's QC signature.

[0048] At this point in the main replica, the different chunks are in the following states:

[0049] For block Bi and its preceding blocks, the message log of the primary replica will be set to the pre-prepared state.

[0050] For block B i-1 Regarding its preceding blocks, since the primary replica received B i-1 With 2f+1 votes, the main copy calculates B. i-1 The LockedQC is set. Therefore, the primary replica's message log will be set to the prepared state. Furthermore, the primary replica will retain the latest LockedQC and its associated message log. <Agg,V,N,D(B i-1 )> Message.

[0051] For block B i-2 Regarding its preceding blocks, since the primary replica receives B i-1 2f+1 votes, and block B i-2 It is block B i-1 If the parent block or ancestor block is the same as the main copy obtaining B, then the main copy will receive B. i-2 The committed QC, therefore the main replica's block B i-2 The message log will be set to committed, and the primary replica will update block B. i-2 Uploaded to the blockchain. Block B i-2 B will be cleared after being added to the blockchain. i-2 The message log will also discard block B. i-2 LockedQC.

[0052] For block B i-3 For both the preceding and preceding blocks, no further processing is required.

[0053] (2) Collection process

[0054] Backup copy sent to block B i-1 After receiving the Agg message, block B was received from the primary replica. i Before receiving the Diss message, the backup replica continues to complete transaction generation and collection, block collection, and other tasks. When the backup replica receives the Diss message, it checks block B. i The preceding block (B) i-1 To B i The system checks if the preceding blocks are complete; if not, it accepts from other copies. Once the blockchain is complete, it proceeds to block B. i The voting process generates an Agg message and sends it to the primary replica. The Agg message takes the following form: <AGG,V,N,D(B i After the transmission is complete, the backup replica continues to generate transactions, accept transactions, and receive and verify blocks. Once the primary replica has collected 2f+1 voting signatures, it enters the broadcast phase.

[0055] At this point, the different blocks in the backup copy are in the following states:

[0056] For block B i For its preceding blocks, the message log of the backup copy will be set to the pre-prepared state.

[0057] For block B i-1 Regarding its preceding blocks, since the backup replica receives the primary replica broadcast B... i-1 LockedQC. Therefore, the message log for backup copies will be set to prepared. Furthermore, all backup copies will retain the latest LockedQC and its... <Agg,V,N,D(B i-1 )> Message.

[0058] For block B i-2 Regarding its preceding blocks, since the backup copy received B i-1 The LockedQC proof, and block B i-2 It is block B i-1 If the parent block or ancestor block is the same as the backup copy, then it is equivalent to obtaining B. i-2 The committed QC, therefore the backup copy of block B i-2 The message log will be set to committed, and the backup copy will include block B. i-2 Uploaded to the blockchain. Block B i-2 B will be cleared after being added to the blockchain. i-2 The message log will also discard block B. i-2 LockedQC.

[0059] For block B i-3 For both the preceding and preceding blocks, no further processing is required.

[0060] Step 3: The view switching protocol allows the system to switch primary replicas in the event of consensus failure, thus continuing operation and providing liveness. The backup replica sends an Agg message to the primary replica and starts a consensus timer. The timer stops upon receiving a Diss message. If the consensus timer times out, the replica initiates a view switch. A switching timer is started when a view switch begins. This timer only stops when the switch is complete; if it times out, the next round of view switches begins. The timing of the switching timer in each round of view switches is longer than the previous round (it can be twice the previous round's timing or some other relationship) to accommodate the Global Steady Time (GST).

[0061] (1) View-Change Process

[0062] If the consensus timer of the backup copy r of view v times out, the backup copy enters the view switching process, switching the view to v+1. Copy r only accepts view-change and new-view messages, and sends a view-change message to the primary copy of view v+1, while simultaneously starting the switching timer. The message format of view-change is as follows:<VIEW-CHANGE,V+1,N,LockedQC> LockedQC represents the latest preparedQC signature of replica r, and N represents the block B that is in the latest LockedQC. i The serial number.

[0063] (2) new-view process

[0064] When the primary replica of view v+1 receives 2f valid view-change messages from other replicas, it selects the LockedQC with the largest view size (or, if views are the same, the one with the largest N) from the 2f view-change messages and its own message log, and this LockedQC becomes MaxLockedQC. The primary replica then generates and broadcasts the next block B based on the block corresponding to MaxLockedQC. i+1 Then, a new-view message is broadcast to all other replicas. The format of the new-view message is as follows: <NEW-VIEW,V+1,N,D(B i+1 QCs>. QCs represents the set of 2f+1 LockedQCs collected by the main replica (including the latest LockedQC of the main replica itself).

[0065] After receiving the new-iew message, the backup copy calculates the MaxLockedQC using QCs and checks block B. i+1 Is it based on the corresponding block Bi of MaxLockedQC? If correct, the replica enters the consensus protocol collection process of view v+1 and sends an Agg message, where the new-view message is equivalent to the Diss message of the consensus protocol. If incorrect, it is rejected and continues to wait. If the switching timer times out, the next round of view switching is started, and the switching timer is restarted.

[0066] The above are merely preferred embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.< / m>

Claims

1. A blockchain PBFT consensus implementation method based on a parallel strategy, characterized in that, include: S1. After the primary replica sends out the Dis consensus message, it receives several Agg voting messages. Before voting, it generates a block at regular intervals in the consensus window and broadcasts it. Several blocks are generated in the consensus window. The consensus message is for the last block in the consensus window to start consensus. The other blocks in the consensus window use a hash chain to ensure security. S2. When the primary replica receives Agg voting messages for the consensus block from several different replicas, it aggregates the signatures into a complete LockedQC signature after successful verification, and generates a Diss consensus message to broadcast to all backup replicas. The LockedQC signature exists in the Diss consensus message. S3. When the backup replica receives the Diss consensus message, it verifies the success and votes on the consensus, and sends the voting result of the Agg voting message to the master node. S4. In the event of consensus failure, switch the primary replica using the view switching protocol and execute the view-change and new-view processes to complete the view switch. When the primary replica receives Agg voting messages for the consensus block from several different replicas, after successful verification, it aggregates the signatures into a complete LockedQC signature and generates a Diss consensus message to broadcast to all backup replicas. The methods include: The primary replica verifies each received Agg voting message. The primary replica aggregates the voting signatures sent by several different replicas into a complete LockedQC signature using a threshold signature aggregation function. It generates a Dis consensus message based on the last broadcast block and broadcasts the Dis consensus message to all backup replicas. Methods for switching primary replicas using the view switching protocol include: After the backup replica sends the Agg voting message to the primary replica, it starts a consensus timer. When it receives the Diss consensus message, it stops the consensus timer. If the consensus timer times out, the backup replica starts a view switch. When the view switch starts, a switch timer is started. The switch timer only stops when the switch ends. If it times out, the next round of view switch is started. The methods for executing the view-change procedure include: If the consensus timer of the backup copy of the current view expires, the backup copy of the current view enters the view switching process and switches the view to the next view. The backup copy of the current view only accepts view-change messages and new-view messages, and sends a view-change message to the primary copy of the next view, while starting the switching timer. The methods for executing the new-view procedure include: When the primary replica of the next view receives several valid view-change messages from other replicas, it selects the LockedQC with the largest view size or the largest N when the views are the same from the several view-change messages and the message log, and becomes MaxLockedQC; the primary replica of the next view generates and broadcasts the next block according to the block corresponding to MaxLockedQC, and then broadcasts a new-view message to all other replicas; After receiving the new-view message, the backup copy needs to calculate the MaxLockedQC using QCs and check whether the next block is based on the block corresponding to MaxLockedQC. The determination method includes: If the correspondence is correct, the backup copy enters the consensus protocol collection process for the next view and sends the Agg voting message, where the new-view message is equivalent to the Diss consensus message of the consensus protocol; if the correspondence is incorrect, it is rejected and continues to wait; if the consensus timer for switching times out, the next round of view switching is started and the switching timer is restarted.

2. The blockchain PBFT consensus implementation method based on parallel strategy as described in claim 1, characterized in that, When the backup replica receives the Dis consensus message, after successful verification, it votes on the consensus and sends the voting result of the Agg voting message to the master node, including the following methods: When the backup replica receives the Diss consensus message, it checks block B. i The preceding block is checked for completeness; if incomplete, it is accepted by other copies. Once the blockchain is complete, it proceeds to block B. i During the voting process, an Agg voting message is generated and sent to the primary replica. After the message is sent, the backup replica continues to generate transactions, accept transactions, receive and verify blocks. When the primary replica has collected a number of voting signatures, it enters the broadcast phase.

3. The blockchain PBFT consensus implementation method based on parallel strategy as described in claim 1, characterized in that, The timing of the switching timer must meet the following condition: the timing of the switching timer for each round of view switching is longer than the timing of the previous round.

Images