A high-speed consensus method based on blockchain

Abstract

The application relates to a high-speed consensus method based on a blockchain, which sequentially comprises a Request stage, a Pre-prepare stage, a Prepare stage, a Commit stage and a Reply stage, the Pre-prepare stage and the Prepare stage are reconstructed, a master node puts a transaction into a cache pool; the master node polls a secondary node and selects an optimal secondary node; the master node generates a cache pool access token and sends the token to the optimal secondary node; the optimal secondary node finds the transaction in the cache pool by means of the cache pool access token; the optimal secondary node downloads the transaction, carries out transaction digest calculation, transaction digest comparison and comparison result broadcast work; after the optimal secondary node completes the work, the master node is replied, and the master node deletes the corresponding transaction in the cache pool; then, the next round of consensus is carried out. The computer algorithm power consumption and the network resource consumption of the stage are reduced, so that the time consumption of the stage can be reduced, the consensus performance of the blockchain can be improved, and the number of concurrent transactions of the blockchain can be improved.

Description

Technical Field

[0001] This invention relates to the field of blockchain, and more specifically, to a high-speed consensus method based on blockchain. Background Technology

[0002] In traditional consortium blockchains, PBFT (Practical Byzantine Fault Tolerance) or its variants are typically used to achieve consistent data storage on the blockchain. The traditional PBFT consensus algorithm consists of five phases: Request, Pre-prepare, Prepare, Commit, and Reply, and its workflow is as follows: Figure 6 As shown, C is the client requesting the transaction to be uploaded to the blockchain, 0 is the master node, and 1 to 3 are the three slave nodes.

[0003] The working principle of the traditional PBFT (Practical Byzantine Fault Tolerance) consensus algorithm is as follows:

[0004] Request: The client sends a transaction upload request to the master node. The request includes the transaction content, transaction summary, and message signature.

[0005] Pre-prepare: When the master node receives a transaction upload request from a client, it verifies the signature of the client's request message. If the verification is successful, the master node broadcasts a Pre-prepare message to other consensus nodes.

[0006] Prepare: Upon receiving the Pre-prepare message from the master node, the secondary node performs the following checks: whether the master node's Pre-prepare message signature is correct, and whether the calculated transaction digest matches the transaction digest. If the checks are successful, the secondary node broadcasts the Prepare message to other consensus nodes.

[0007] Commit: Upon receiving the Prepare message, the primary and secondary nodes perform the following checks: whether the Prepare message signature is correct, and whether the transaction digest in the Prepare message matches the transaction digest in the Pre-prepare message. If a consensus node receives and successfully verifies 2f+1 Prepare messages, it broadcasts a Commit message to other consensus nodes.

[0008] Reply: Upon receiving the Commit message, the primary and secondary nodes perform the following verification: whether the Commit message signature is correct. If a consensus node receives and successfully verifies 2f+1 Commit messages, it executes the client's request operation and returns a Reply message to the client.

[0009] Among existing technologies, Chinese invention patent CN112991066A discloses a "Consensus Method, Device, and Electronic Equipment in Consortium Blockchain," published on June 18, 2021. This invention improves the traditional PBFT (Practical Byzantine Fault Tolerance) consensus algorithm and elucidates the basic principles of the improved PBFT consensus algorithm. Compared to the traditional PBFT consensus algorithm, this invention adds a broadcast phase between the Request and Pre-prepare phases. The client can send a transaction upload request to any blockchain consensus node, and the receiving node then broadcasts the transaction to all consensus nodes in the blockchain network. The master node, upon receiving the broadcast message, then executes the subsequent Pre-prepare, Prepare, Commit, and Reply phases. This avoids situations where the client and master node have no network connection or the master node is malicious, preventing the blockchain consensus from being completed.

[0010] The traditional PBFT consensus algorithm and the improved PBFT consensus algorithm disclosed in patent CN112991066A typically consume over 50% of the time in the Pre-prepare and Prepare phases of a consensus operation. This phase consumes significant computing power and network resources because each consensus node needs to calculate a digest of the transaction content, compare the transaction digest received from the Pre-prepare message with the digest calculated by the node, and broadcast the verification result to all consensus nodes in the blockchain network. The larger the number of consensus nodes in the blockchain network, the greater the computing power and network resource consumption of this phase. Furthermore, the efficiency of this phase is constrained by the one or a few servers with the lowest computing power in the blockchain network, as all consensus nodes must wait to receive the Prepare message from the one or a few servers with the lowest computing power before proceeding to the next phase. Therefore, the Prepare phase of the traditional PBFT (Practical Byzantine Fault Tolerance) consensus algorithm significantly restricts the performance growth of consortium blockchains, i.e., TPS (transactions per second). As the number of consensus nodes in a consortium blockchain increases, blockchain performance deteriorates, and performance improvement becomes increasingly difficult. Summary of the Invention

[0011] This invention addresses the technical shortcomings of the existing PBFT consensus algorithm, which requires a large amount of computing and network resources in the Prepare phase, making it difficult to improve the performance of blockchains using the PBFT consensus algorithm. It provides a high-speed consensus method based on blockchain.

[0012] To achieve the above-mentioned objectives, the technical solution adopted is as follows:

[0013] A high-speed consensus method based on blockchain includes a Request phase, a Pre-prepare phase, a Prepare phase, a Commit phase, and a Reply phase. The Pre-prepare and Prepare phases are reconstructed so that the master node polls the slave nodes based on their current workload and computing resources, and distributes the transaction digest calculation, comparison, and result broadcasting tasks to the optimal slave node. The single optimal slave node completes the transaction digest calculation, transaction digest comparison, and comparison result broadcasting tasks.

[0014] In the above scheme, the present invention reconstructs the Pre-prepare and Prepare stages of the PBFT consensus algorithm, no longer requiring all consensus nodes in the blockchain network to perform transaction digest calculation, transaction digest comparison, and comparison result broadcasting. This reduces the computing power and network resource overhead of this stage, thereby reducing the time consumption of this stage, improving the consensus performance of the blockchain, and increasing the number of concurrent transactions in the blockchain.

[0015] The reconstruction method in the Pre-prepare phase includes: the master node receives the client's transaction upload request, and the master node verifies whether the signature of the client's request message is correct.

[0016] Preferably, the reconstruction method in the Prepare stage includes a polling operation process and a verification operation process in sequence.

[0017] The polling operation process includes the following steps:

[0018] S1: The master node puts the transactions to be verified into the cache pool in its local memory. All transactions in the cache pool are sorted by Seq number. Only the master node has the authority to write and delete transactions in the cache pool.

[0019] S2: Master node confirms N, n i h i T max Check if the value has been updated; if so, update it; otherwise, proceed to the next step.

[0020] S3: The master node updates q based on real-time messages. i j;

[0021] S4: The master node calculates i = jMOD(N-1);

[0022] S5: Master Node Calculation

[0023] S6: Master node comparison tq i and If tq i Less than Then jump to S9, if tqi Greater than or equal to Then proceed to S7;

[0024] S7: Master Node Calculation (k = 1, 2, 3Λ, N and k ≠ i);

[0025] S8: The master node compares all tqs. k Choose the smallest tq value. k Value, record the value of k; if there are multiple smallest tq k Choose the smallest k that satisfies ki > 0, and record the value of k. Let i = k.

[0026] S9: After completing S1-S8 above, the master node polls the counter j = j + 1; the master node randomly generates the verification string char and puts the verification string char into the transaction header with the cache pool number Seq.

[0027] The verification operation process includes the following steps:

[0028] S10: The master node encapsulates the transaction number Seq to be verified and the verification string char into an access token T. Seq Then, put the access token T in the middle. Seq Send to secondary node n i ;

[0029] S11: Secondary node n i Send access token T Seq The transaction ID Seq to be verified is retrieved from the cache pool of the primary node. If the transaction exists, the secondary node n... i Send access token T Seq The verification string char is given to the master node, and the master node compares it with the access token T. Seq The verification string char in the transaction header is checked against the verification string char stored in the cache pool. If they match, the complete transaction Seq is sent to the slave node n. i ;

[0030] S12: Secondary node n i After receiving a transaction, the system replies with an "ACK" message to the master node. Upon receiving the "ACK" message, the master node clears the transaction with the number Seq from the cache pool.

[0031] S13: Secondary node n i Execute verification: Calculate the digest D'(m) of transaction content m with ID Seq, and compare D'(m) with the transaction digest D(m) in the complete transaction. If they match, the verification is considered successful. After successful verification, the secondary node n... iThe verification result is encapsulated into a Prepare message and broadcast to all consensus nodes in the blockchain network.

[0032] Preferably, the operation process of the cache pool includes:

[0033] In step S1, the client submits the transaction upload application to the master node, and the master node assigns a number to the transaction: the first transaction uploaded by the client is numbered Seq=1, and Seq is incremented by 1 for each subsequent transaction uploaded by the client. The number is not reset and is not cleared. The master node puts the transaction into the cache pool in its local memory.

[0034] In step S9, the master node completes the polling operation, generates a verification string char, puts the verification string char into the cache pool, and encapsulates it into the access token T. Seq Issuing access token T Seq Give secondary node n i .

[0035] Preferably, the operation process of the cache pool includes: in steps S11 and S12, the secondary node n i With token T Seq The transaction is retrieved from the master node; in step S13, the slave node n... i Verify the transaction with the number Seq.

[0036] Preferably, in the Prepare phase, the known conditions obtained by the master node include:

[0037] Each on-chain transaction is assigned a unique number, denoted as Seq. The first transaction uploaded by the client is assigned Seq=1. For each subsequent transaction uploaded by the client, Seq is incremented by 1, and this number is not reset.

[0038] The total number of secondary nodes is denoted as N-1. This number is only updated when the view is transformed, i.e., when the primary node is switched.

[0039] Each secondary node is numbered, denoted as n. i =1,2,3,Λ,(N-1), this number is only updated when the view is transformed, that is, when the master node is switched;

[0040] Let q be the length of the verification task queue for secondary node i. i This data is updated in real time and reported to the master node in real time;

[0041] The reference computing power of the i-th secondary node is denoted as h. i This data is only updated when the corresponding consensus node joins the blockchain;

[0042] The master node polling operation counter, denoted as j, increments by 1 each time the master node performs a polling operation. After the master node is replaced, the value is reset to zero.

[0043] The maximum TPS of a blockchain is denoted as T. max This data needs to be configured in the blockchain settings.

[0044] Preferably, in the master node calculation, MOD is the remainder operator.

[0045] The Request phase includes the following steps: the client sends an on-chain transaction request to the master node. The complete transaction includes the transaction content m, the transaction digest D(m), and the message signature.

[0046] The Commit phase includes the following steps: When the master node and slave node receive the Prepare message, they perform the following checks: whether the Prepare message signature is correct, whether the transaction digest in the Prepare message is consistent with the transaction digest in the Pre-prepare message, and if a consensus node receives and successfully checks 2f+1 Prepare messages, it broadcasts the Commit message to other consensus nodes.

[0047] The Reply phase includes the following steps: When the master node and slave node receive the Commit message, they perform the following verification: whether the Commit message signature is correct. If a consensus node receives and successfully verifies 2f+1 Commit messages, it runs the client's request operation and returns a Reply message to the client.

[0048] Compared with the prior art, the beneficial effects of the present invention are:

[0049] This invention provides a high-speed consensus method based on blockchain. This invention reconstructs the Pre-prepare and Prepare phases of the PBFT consensus algorithm, eliminating the requirement for all consensus nodes in the blockchain network to perform transaction digest calculation, transaction digest comparison, and comparison result broadcasting. This reduces the computing power and network resource overhead of this phase, thereby reducing the time consumption of this phase, improving the consensus performance of the blockchain, and increasing the number of concurrent transactions in the blockchain. Attached Figure Description

[0050] Figure 1 This is a flowchart of the reconstruction method in the Prepare stage of the present invention;

[0051] Figure 2 This is a flowchart of the polling operation of the present invention;

[0052] Figure 3 This is a flowchart of the verification operation of the present invention;

[0053] Figure 4 This is a flowchart illustrating the cache pool architecture and process involved in the Prepare phase of this invention.

[0054] Figure 5 This is a diagram of the transaction structure stored in the cache pool of the present invention;

[0055] Figure 6 This is a flowchart illustrating the workflow of the traditional PBFT consensus algorithm of this invention. Detailed Implementation

[0056] The accompanying drawings are for illustrative purposes only and should not be construed as limiting the scope of this patent.

[0057] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0058] Example 1

[0059] like Figure 1 As shown, the master node puts the transaction into the cache pool; the master node polls the slave nodes and selects the optimal slave node; the master node generates a cache pool access token and sends it to the optimal slave node; the optimal slave node uses the cache pool access token to search for the transaction in the cache pool; the optimal slave node downloads the transaction, performs transaction digest calculation, transaction digest comparison, and broadcasts the comparison result; after the optimal slave node completes its work, it replies to the master node, and the master node deletes the corresponding transaction from the cache pool; then the next round of consensus is carried out.

[0060] Example 2

[0061] like Figure 2 and Figure 3 As shown, the reconstruction method in the Prepare phase includes a polling operation process and a verification operation process in sequence.

[0062] The polling operation process includes the following steps:

[0063] S1: The master node puts the transactions to be verified into the cache pool in its local memory. All transactions in the cache pool are sorted by Seq number. Only the master node has the authority to write and delete transactions in the cache pool.

[0064] S2: The master node checks whether the values ​​of N, ni, hi, and Tmax have been updated. If they have, they are updated; otherwise, the next step is performed.

[0065] S3: The master node updates q based on real-time messages. i j;

[0066] S4: The master node calculates i = jMOD(N-1);

[0067] S5: Master Node Calculation

[0068] S6: Master node comparison tq i and If tq i Less than Then jump to S9, if tq i Greater than or equal to Then proceed to S7;

[0069] S7: Master Node Calculation (k = 1, 2, 3Λ, N and k ≠ i);

[0070] S8: The master node compares all tqs. k Choose the smallest tq value. k Value, record the value of k; if there are multiple smallest tq k Choose the smallest k that satisfies ki > 0, and record the value of k. Let i = k.

[0071] S9: After completing S1-S8 above, the master node polls the counter j = j + 1; the master node randomly generates the verification string char and puts the verification string char into the transaction header with the cache pool number Seq.

[0072] The verification operation process includes the following steps:

[0073] S10: The master node encapsulates the transaction number Seq to be verified and the verification string char into an access token T. Seq Then, put the access token T in the middle. Seq Send to secondary node n i ;

[0074] S11: Secondary node n i Send access token T Seq The transaction ID Seq to be verified is retrieved from the cache pool of the primary node. If the transaction exists, the secondary node n... i Send access token T Seq The verification string char is given to the master node, and the master node compares it with the access token T. Seq The verification string char in the transaction header is checked against the verification string char stored in the cache pool. If they match, the complete transaction Seq is sent to the slave node n. i ;

[0075] S12: Secondary node n i After receiving a transaction, the system replies with an "ACK" message to the master node. Upon receiving the "ACK" message, the master node clears the transaction with the number Seq from the cache pool.

[0076] S13: Sub-node ni performs verification: Calculates the digest D'(m) of transaction content m with number Seq, compares D'(m) with the transaction digest D(m) in the complete transaction, and if they match, the verification is considered successful. After the verification is successful, sub-node ni encapsulates the verification result into a Prepare message and broadcasts the message to all consensus nodes in the blockchain network.

[0077] Example 2

[0078] like Figure 4 and Figure 5 As shown, the operation process of the cache pool includes:

[0079] ① The client submits the transaction upload application to the master node, and the master node assigns a number to the transaction: the first transaction uploaded by the client is numbered Seq=1, and Seq is incremented by 1 for each subsequent transaction uploaded by the client. This number is not reset.

[0080] ② The master node places the transaction into its local memory cache pool;

[0081] ③ The master node completes the polling operation, generates a verification string (char), puts the verification string (char) into the cache pool, and encapsulates it into the access token (T). Seq Issuing access token T Seq Give secondary node n i .

[0082] ④ Secondary node n i With token T seq Retrieve the transaction from the master node;

[0083] ⑤ Secondary node n i Verify the transaction with the number Seq.

[0084] Numbers ①-⑤ correspond to Figure 3 Steps ①-⑤ of the cache pool operation process.

[0085] Example 3

[0086] In this embodiment, the following entities are assumed to exist in the blockchain network:

[0087] Client C

[0088] Blockchain consensus nodes n1, n2, n3, n4

[0089] Assume the following other known conditions are required for the master node:

[0090] Seq = 1501

[0091] N-1=3

[0092] q1=10, q2=100, q3=1000

[0093] h1=10000, h2=20000, h3=30000

[0094] j-5

[0095] T max =10000

[0096] The consensus steps for improving this invention patent are as follows:

[0097] Blockchain client C uploaded a transaction "Transaction" to master node n1. "Transaction" contains...<m,D(m),Sign> , m is the transaction content, D(m) is the transaction summary, and Sign is the digital signature of client C.

[0098] Master node n main Assign the transaction number "Seq 1501" and add this number to the transaction header "Seq1501+Transaction".

[0099] The master node puts the transaction "Seq 1501+Transaction" into the cache pool in the order of Seq number.

[0100] The master node calculation is i = j MOD(N-1) = 5 MOD3 = 2

[0101] Master node computation

[0102] The master node compares tq2 = 0.005 with... achievable

[0103] Master node computation

[0104] The master node compares tq1, tq2, and tq3, and selects the minimum value as tq1, i.e., k = 1. Let i = k = 1.

[0105] The master node calculates j = j + 1 = 5 + 1 = 6. The master node generates a random verification string (char). This verification string is added to the transaction header in the cache pool: "Seq 1501 + char + Transaction".

[0106] The master node encapsulates the Seq 1501 and the verification string char into the access token T. 1501 Send access token T 1501 Assign secondary node n1;

[0107] Secondary node n1 uses access token T 1501The transaction ID Seq 1501 to be verified is searched in the cache pool, and the transaction is found to exist. Secondary node n1 sends access token T. 1501 The verification string char is given to the master node, and the master node compares it with the access token T. 1501 The verification string char in the cache pool is consistent with the verification string char stored in the transaction body. The master node sends the complete transaction "Seq 1501+Transaction" to the slave node n1.

[0108] Secondary node n1 retrieves transaction "Seq 1501+Transaction" and replies to the primary node with an "ACK" message. Upon receiving the "ACK" message, the primary node deletes transaction "Seq 1501+Transaction" with the ID Seq1501 from the cache pool.

[0109] Secondary node n1 performs verification: It calculates the digest D'(m) of transaction content m in transaction "Seq 1501+Transaction", compares D'(m) with the digest D(m) in transaction "Seq 1501+Transaction", and if they match, the verification passes. After successful verification, secondary node n1 encapsulates the verification result into a Prepare message and broadcasts the message to all consensus nodes in the blockchain network.

[0110] Obviously, the above embodiments of the present invention are merely examples for clearly illustrating the present invention, and are not intended to limit the implementation of the present invention. Those skilled in the art can make other variations or modifications based on the above description. It is neither necessary nor possible to exhaustively describe all embodiments here. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the claims of the present invention.

Claims

1. A high-speed consensus method based on blockchain, comprising, in sequence, a Request phase, a Pre-prepare phase, a Prepare phase, a Commit phase, and a Reply phase, characterized in that, The Pre-prepare and Prepare phases are restructured. The master node polls the slave nodes based on their current workload and computing resources, and dispatches the tasks of transaction digest calculation, transaction digest comparison, and comparison result broadcasting to the optimal slave node. The optimal slave node then completes the transaction digest calculation, transaction digest comparison, and comparison result broadcasting. The reconstruction method in the Prepare phase includes a polling operation process and a verification operation process in sequence; The polling operation process includes the following steps: S1: The master node puts the transactions to be verified into the cache pool in its local memory. All transactions in the cache pool are sorted by Seq number. Only the master node has the authority to write and delete transactions in the cache pool. S2: The master node confirms the total number of nodes N and the i-th secondary node n. i The reference computing power h of the i-th secondary node i The maximum TPS value of the blockchain max If there is an update, update it; otherwise, proceed to the next step. S3: The master node updates the length q of the verification task queue of the i-th slave node based on real-time messages. i Master node polling operation counter j; S4: The master node calculates i = j MOD(N-1), where MOD is the remainder symbol, and i is the remainder when j is divided by N-1; S5: Master Node Calculation ; S6: Master node comparison tq i and If tq i Less than Then jump to S9, if tq i Greater than or equal to Then proceed to S7; S7: Master Node Calculation ; S8: The master node compares all tqs. k Choose the smallest tq value. k Value, record k The value of tq; if there exist multiple smallest tq values. k Choose the smallest value that satisfies ki > 0. k and record k Let i = k; S9: After completing S1-S8 above, the master node polls the counter j=j+1; the master node randomly generates a verification string char and puts the verification string char into the transaction header with the cache pool number Seq.

2. The high-speed consensus method based on blockchain according to claim 1, characterized in that, The reconstruction method in the Pre-prepare phase includes: the master node receives the client's transaction upload request, and the master node verifies whether the signature of the client's request message is correct.

3. The high-speed consensus method based on blockchain according to claim 1, characterized in that, The verification operation process includes the following steps: S10: The master node encapsulates the transaction number Seq to be verified and the verification string char into an access token T. Seq Then, put the access token T in the middle. Seq Send to secondary node n i ; S11: Secondary node n i Send access token T Seq The transaction ID Seq to be verified is retrieved from the cache pool of the primary node. If the transaction exists, the secondary node n... i Send access token T Seq The verification string char is given to the master node, and the master node compares it with the access token T. Seq The verification string char in the transaction header is checked against the verification string char stored in the cache pool. If they match, the complete transaction Seq is sent to the slave node n. i ; S12: Secondary node n i After receiving a transaction, the system replies with an "ACK" message to the master node. Upon receiving the "ACK" message, the master node clears the transaction with the number Seq from the cache pool. S13: Secondary node n i Execute verification: Calculate the digest D'(m) of transaction content m with ID Seq, and compare D'(m) with the transaction digest D(m) in the complete transaction. If they match, the verification is considered successful. After successful verification, the secondary node n... i The verification result is encapsulated into a Prepare message and broadcast to all consensus nodes in the blockchain network.

4. The high-speed consensus method based on blockchain according to claim 1, characterized in that, The operation process of the cache pool includes: In step S1, the client submits the transaction upload application to the master node, and the master node assigns a number to the transaction: the first transaction uploaded by the client is numbered Seq=1, and Seq is incremented by 1 for each subsequent transaction uploaded by the client. The number is not reset and is not cleared. The master node puts the transaction into the cache pool in its local memory. In step S9, the master node completes the polling operation, generates a verification string char, puts the verification string char into the cache pool, and encapsulates it into the access token T. Seq Issuing access token T Seq Give secondary node n i .

5. The high-speed consensus method based on blockchain according to claim 3, characterized in that, The operation process of the cache pool includes: in steps S11 and S12, the secondary node n i With token T Seq The transaction is retrieved from the master node; in step S13, the slave node n... i Verify the transaction with the number Seq.

6. A high-speed consensus method based on blockchain according to claim 1 or 3, characterized in that, During the Prepare phase, the known conditions obtained by the master node include: (1) Number each on-chain transaction and denote it as Seq. Each transaction has a unique number. The first transaction uploaded by the client is numbered Seq=1. After that, Seq is incremented by 1 for each transaction uploaded by the client. This number is not reset. (2) The total number of secondary nodes, denoted as N-1, is updated only when the view is transformed, i.e. when the primary node is switched; (3) Each secondary node is numbered, denoted as This number is only updated when the view changes, i.e., when the master node is switched; (4) The length of the verification task queue of the i-th secondary node is denoted as q. i This data is updated in real time and reported to the master node in real time; (5) The reference computing power of the i-th secondary node is denoted as h. i This data is only updated when the corresponding consensus node joins the blockchain; (6) The master node polling operation counter, denoted as j, increments by 1 each time the master node performs a polling operation. After the master node is replaced, the value is cleared and reset. (7) The maximum TPS of the blockchain, denoted as T max This data needs to be configured in the blockchain settings.

7. The high-speed consensus method based on blockchain according to claim 1, characterized in that, The Request phase includes the following steps: the client sends an on-chain transaction request to the master node, and the complete transaction includes the transaction content. m Summary of the transaction D(m) and message signature; The Commit phase includes the following steps: When the master node and slave node receive the Prepare message, they perform the following checks: whether the Prepare message signature is correct, whether the transaction digest in the Prepare message is consistent with the transaction digest in the Pre-prepare message, and if a consensus node receives and successfully checks 2f+1 Prepare messages, it broadcasts the Commit message to other consensus nodes. The Reply phase includes the following steps: When the master node and slave node receive the Commit message, they perform the following verification: whether the Commit message signature is correct. If a consensus node receives and successfully verifies 2f+1 Commit messages, it runs the client's request operation and returns a Reply message to the client.

Images