A consortium chain consensus method and system based on weighted incentive master node election

Abstract

The present invention proposes a consortium chain consensus method and system based on weighted incentive master node election, which relates to the technical field of blockchain consensus. A client requests a transaction to be put on the chain, and all nodes in the consortium chain receive the request and perform consensus master node verification and consensus sub-node verification. Then each consensus sub-node verifies the consistency of the verification result, compares the number of reply contents in the verification result information with the number of malicious nodes, and determines whether the transaction is written into the block in combination with the consensus master node verification result. When no malicious nodes appear, the operation speed is fast and the efficiency is high, which improves the consensus performance of the consortium chain. When malicious nodes appear, the PBFT consensus protocol is used for consensus to improve the robustness of the consortium chain. However, there is also a limit to the number of malicious nodes that the PBFT consensus protocol can tolerate. In combination with the view replacement protocol, a weighted incentive mechanism is used to re-elect the master consensus node, reduce the possibility of malicious nodes being elected as master nodes, and further improve the consensus performance of the consortium chain.

Description

Technical Field

[0001] The present invention relates to the technical field of blockchain consensus, and more specifically, to a consortium chain consensus method and system based on weighted incentive master node election. Background Art

[0002] In blockchain technology, consensus algorithm is one of the core components. A consortium chain refers to a blockchain jointly managed by several institutions. Each institution runs one or more nodes. The data in the blockchain is only allowed to be read, written and sent by different institutions in the system, and the transaction data is recorded together. It is also called "shared authentication blockchain". In traditional consortium blockchains, PBFT (Practical Byzantine Fault Tolerance) consensus algorithm or variant PBFT consensus algorithm is usually used to achieve consistent storage of data on the blockchain.

[0003] The traditional PBFT consensus algorithm operates as a state machine, including node status and message status. The master node leads other nodes to process messages in a unified pace. Whether the message continues to migrate to the next state, how many nodes reach a consensus, and finally the message reaches the processed state, is divided into 5 stages: Request, Pre-prepare, Prepare, Commit and Reply. First, in the Request stage, the client sends a transaction chain request to the master node. The request contains the transaction content, transaction summary and message signature, and then enters the Pre-prepare stage. The master node receives the client's transaction chain request. The master node verifies whether the signature of the client's request message is correct. If there is no problem with the verification, it broadcasts the Pre-prepare message to other sub-nodes, and then enters the Prepare stage. The sub-node receives the Pre-prepare message from the master node and performs the following verification: the master node The Pre-prepare message signature is correct, and the calculated transaction content summary is consistent with the transaction summary. If there is no problem in the verification, the Prepare message is broadcast to other consensus nodes, and then enters the Commit phase. After the master node and the slave node receive the Prepare message, they verify whether the Prepare message signature is correct and whether the transaction summary in the Prepare message is consistent with the transaction summary in the Pre-prepare message. If a consensus node receives and successfully verifies 2f+1 Prepare messages (f represents the number of malicious nodes), it broadcasts the Commit message to other consensus nodes, and finally enters the Reply phase. The master node and the slave node receive the Commit message and verify 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.

[0004] Compared with the traditional PBFT consensus algorithm, on June 18, 2021, a consensus method, device and electronic device in a consortium chain were disclosed in a Chinese invention patent (publication number CN112991066A). This scheme improves the traditional PBFT consensus algorithm and proposes to add a broadcast stage between Request and Pre-prepare. The client can send a transaction chain request to any blockchain consensus node, and then the node that receives the request broadcasts the transaction to all consensus nodes in the blockchain. After receiving the broadcast message, the master node executes subsequent Pre-prepare, Prepare, Commit, and Reply stages to avoid the situation where the blockchain consensus cannot be completed when the client has no network connection with the master node or the master node is a malicious node. The other stages are consistent with the traditional PBFT consensus algorithm, but the maximum TPS (system throughput, which is also the number of system processing per second) of the consortium chain blockchain system of the PBFT consensus algorithm is generally above 10,000 TPS, and as the number of consensus nodes increases, the maximum TPS decays at a polynomial level. At this time, this scheme will cause low blockchain consensus efficiency and difficulty in supporting the normal operation of businesses with high TPS requirements. In the Prepare and Commit phases, each consensus node must perform summary calculations and message broadcasts, with a message complexity of O(n 2 ). When the number of consensus nodes in the network increases, all consensus nodes must perform two-stage summary calculation and message broadcast operations, causing the performance of the traditional PBFT consensus algorithm to drop rapidly as the number of consensus nodes increases. When the performance of the alliance chain drops to a certain level, it may cause the business running on the alliance chain to be interrupted.

[0005] In addition, the traditional PBFT consensus algorithm requires the replacement of the master node regularly, or the master node will be replaced when the master node is malicious. The operation of replacing the master node is calculated by the formula p = v MOD R (p is the master node number, v is the view number, R is the total number of consensus nodes, and MOD is the remainder operation), that is, when no consensus node joins or exits the alliance chain, all consensus nodes will take turns to serve as the master node in the order of their own numbers. It is fair for all nodes that all consensus nodes take turns to serve as the master node, but its disadvantage is that this method cannot avoid the possibility of electing a malicious node as the master node, resulting in the failure of this election process and the need for re-election. Summary of the invention

[0006] In order to solve the problem that in the traditional PBFT consensus method of the alliance chain, as the number of consensus nodes increases, the consensus performance decreases, the present invention proposes an alliance chain consensus method and system based on weighted incentive master node election, which reduces the probability of electing malicious nodes as master nodes and improves the consensus performance of the alliance chain.

[0007] In order to achieve the above technical effects, the technical solution of the present invention is as follows:

[0008] A consortium chain consensus method based on weight-based incentive master node election, including:

[0009] S1. Calculate the number of malicious nodes f that the alliance chain can tolerate, and identify the initial consensus master node and consensus sub-node in the alliance chain nodes;

[0010] S2. The consensus master node and consensus sub-node in the alliance chain receive the transaction on-chain request message sent by the client, and perform consensus master node verification and consensus sub-node verification;

[0011] S3. Each consensus secondary node verifies the consistency between the verification result of the consensus primary node and the verification result of the current node, and obtains the verification result information, which includes the reply content r ACK Or reply content non-ACK , each consensus secondary node replies the verification result information to the consensus primary node;

[0012] S4. Set the reply content r in the verification result information ACK The number of replies is α or the reply content r non-ACK The number is β. When α≥2f or β≤f, if the consensus master node succeeds in verification, the transaction is allowed to be written into the latest block of the consensus master node, and the consensus master node replies to the client with a "transaction successful" message; if the consensus master node fails in verification, the transaction is rejected, and the consensus master node replies to the client with a "transaction failed" message;

[0013] When f≤α<2f or f<β≤2f, the consensus master node broadcasts to all consensus slave nodes to enter the PBFT consensus protocol and re-consensus on the transaction using the PBFT consensus protocol;

[0014] When 0≤α<f or β>2f, the consensus master node notifies all consensus slave nodes to trigger the view change protocol. All consensus slave nodes calculate the election weight score of their own nodes based on the records verified by the consensus slave nodes, elect the node with the highest weight score as the new consensus master node, and return to step S2 for re-consensus.

[0015] In this technical solution, the traditional PBFT consensus algorithm is used as the basic starting point, and the nodes of the alliance chain are subjected to a "three-step" consensus. For the client's transaction chain request, the "simple consensus protocol" is used as the starting point: all nodes in the alliance chain receive the request and perform consensus master node verification and consensus sub-node verification, and then each consensus sub-node verifies the consistency of the verification result. According to the comparison between the number of feedbacks of the reply content in the verification result information and the number of malicious nodes, combined with the verification result of the consensus master node, it is determined whether the transaction is written into the block. The algorithm complexity of the "simple consensus protocol" is O(n), and it runs fast and efficiently, which can improve the consensus performance of the alliance chain. However, when malicious nodes appear, the number of feedbacks of the reply content in the verification result information and the number of malicious nodes do not meet the "simple consensus protocol", and the security and credibility of the alliance chain cannot be guaranteed. The PBFT consensus protocol is used for consensus to improve the robustness of the alliance chain consensus, but the number of malicious nodes that the PBFT consensus protocol can tolerate is limited. Therefore, combined with the view replacement protocol, a weight incentive mechanism is used to re-elect the main consensus node to ensure the appropriateness of the main consensus node election, reduce the probability of malicious nodes appearing, and further improve the consensus performance of the alliance chain.

[0016] Preferably, the expression for calculating the number f of malicious nodes that the alliance chain can tolerate in step S1 is:

[0017]

[0018] Where N represents the total number of consensus nodes in the alliance chain; Indicates rounding down.

[0019] Preferably, the consensus master node and consensus sub-node in the alliance chain receive the transaction chain request message sent by the client as msg request ,msg request Contains transaction content m, transaction summary D(m) and client signature Sign c ;

[0020] The consensus master node verification described in step S2 includes:

[0021] The consensus master node calculates the summary D′(m) of the transaction content m, and combines the summary D′(m) with the transaction on-chain request message msg sent by the client. request The transaction summary D(m) in the table is used to verify whether the two are equal, and the verification result is marked as r verification , forming a consensus master node verification result message msg verification , verification result message msg verification Included: verification result mark r verification , transaction content m, transaction summary D(m) and node signature Sign node k ;

[0022] The consensus node verification includes: each consensus node calculates the summary D′(m) of the transaction content m, and compares the summary D′(m) with the transaction on-chain request message msg sent by the client. request The transaction summary D(m) in is verified to see if the two are equal, thus forming the verification result message of this node.

[0023] Preferably, the consensus master node will verify the result message msg verification Sent to each consensus secondary node, each consensus secondary node receives the verification result message msg verification , verify the consistency between the verification result of the consensus master node and the verification result of this node, and obtain the verification result information;

[0024] If the verification results are consistent, the content r will be replied ACK Encapsulate the verification result information, otherwise, reply content r non-ACK Encapsulated into verification result information; the verification result information also includes transaction content m, transaction summary D(m) and node signature Sign node k .

[0025] Preferably, in step S4, when α≥2f or β≤f, if the verification result mark r verification for:

[0026] D′(m)=D(m)

[0027] The consensus master node verifies successfully, and the consensus master node encapsulates the "execute transaction" message msg sbft-commit , and sent to all consensus sub-nodes, and the consensus sub-nodes received the "execute transaction" message msg sbft-commit , decides to execute the transaction and writes the transaction into the latest block of this node. The consensus master node replies to the client with a "transaction successful" message; if the verification result is marked r verification for:

[0028] D′(m)≠D(m)

[0029] If the consensus master node verification fails, the consensus master node encapsulates the "do not execute transaction" message msg sbft-commit , sent to all consensus sub-nodes, and the consensus sub-nodes received the "do not execute transaction" message msg sbft-commit , the transaction is not executed and the block is not written, and the consensus master node replies to the client with a "transaction failed" message.

[0030] Here, after the consensus master node replies with a "transaction successful" message to the client or the consensus master node replies with a "transaction failed" message to the client, for the next transaction on-chain request sent by the client, it still returns to step S2 to continue executing the next round of consensus.

[0031] Preferably, in step S4, when f≤α<2f or f<β≤2f, the consensus master node broadcasts to notify all consensus slave nodes to enter the PBFT consensus protocol, and the process of re-consensus on the transaction using the PBFT consensus protocol is as follows:

[0032] The client sends a transaction on-chain request message to the consensus master node;

[0033] The consensus master node verifies the message sent by the client, and after passing the verification, broadcasts the transaction Pre-prepare message to all consensus slave nodes;

[0034] Each consensus slave node verifies the received transaction Pre-prepare message, and after passing the verification, broadcasts the transaction Prepare message to other consensus slave nodes and consensus master nodes except itself;

[0035] The consensus master node and consensus sub-node verify the received transaction Prepare message. If the verification passes and the number of consistent verifications is ≥ 2f+1, the transaction Commit message is broadcast to other consensus sub-nodes and the consensus master node except themselves.

[0036] The consensus master node and consensus slave node verify the received transaction Commit message. When the number of correct Commit message verification results is ≥ 2f+1, the transaction is written into the latest block of the node and a Reply message msg is returned. reply = "Transaction successful" to the client.

[0037] Here, when f≤α<2f (or f<β≤2f), malicious nodes appear, and the number of feedbacks in the reply content in the verification result information and the number of malicious nodes do not meet the basic consensus. The security and credibility of the alliance chain cannot be guaranteed. The PBFT consensus protocol is used for consensus to improve the robustness of the alliance chain consensus. reply = After "transaction successful" is sent to the client, for the next transaction on-chain request sent by the client, it will still return to step S2 to continue executing the next round of consensus; when the number of correct Commit message verification results is less than 2f+1, the Reply message msg is returned reply = "Transaction failed" is sent to the client. For the next transaction on-chain request sent by the client, the process returns to step S2 to continue the next round of consensus.

[0038] Preferably, in step S4, when 0≤α<f or β>2f, the consensus master node broadcasts the message msg vc Notify all consensus sub-nodes to trigger the execution of the view change protocol, message msg vcIncludes: view number v+1, the last stable consensus block number BS and node signature Sign node k ; All consensus secondary nodes receive the message msg vc After that, all consensus nodes calculate the election weight P of node k according to the records verified by the consensus nodes. node k The process is:

[0039] 1) Calculate the accuracy, the expression is:

[0040]

[0041] Among them, Tk L The latest transaction number verified by consensus secondary node k; Tk o The first transaction number verified by the k-th consensus secondary node; Tk E The transaction sequence number set of the k-th consensus secondary node verification error, expressed as: Tk E ={Tk 1 , Tk 2 , Tk 3 , …, Tk n}, E=1, 2, 3,..., n, Tk 1 Tk is the transaction number of the first verification error of consensus node k. n The transaction sequence number of the nth verification error of consensus node k; when Correctness>99%, the consensus node is eligible to be elected as the consensus master node;

[0042] 2) Compute node basic points B , the expression is:

[0043] P B =A×Correctness

[0044] Among them, A represents the modifiable weight reference coefficient;

[0045] 3) Calculate the reward P for correct continuous correction SC , the expression is:

[0046]

[0047] 4) Calculate the historical penalty P for verification errors EH , the expression is:

[0048]

[0049] 5) Calculate the consecutive check error penalty P EC , the expression is:

[0050] a=0.05×(TkL -Tk o +1), C = 1.57 × A × a, x = Tk n -Tk n-1

[0051]

[0052] Among them, a and C represent intermediate parameters;

[0053] 6) Calculate the election weight P of node k node k , the expression is:

[0054] P node k =P B +P SC +P EH -P EC

[0055] Among them, P node k Indicates the election weight of consensus secondary node k.

[0056] Preferably, the consensus secondary node calculates the election weight P of the node k according to the record verified by the consensus secondary node in step S2. node k After that, P node k Encapsulate into reply message msg pre-vote , broadcast view switch reply message msg Pre - vote To the alliance chain, the message msg Pre-vote It includes the view number v+1, the last stable consensus block number BS, and the node election weight P node k And node signature Sign node k ;

[0057] All consensus nodes in the alliance chain receive the message msg Pre-vote , comparing each election weight P node 1 ~P node N Make an election, N represents the total number of consensus nodes in the alliance chain; each node in the alliance chain encapsulates the election result into the election message msg vote , broadcast election message msg vote To the alliance chain, election message msg vote It includes: view number v+1, the last stable consensus block number BS, the election result voteresult and the node signature Sign node k ;

[0058] Each consensus node in the alliance chain receives the election message from other consensus nodes, selects the consensus node with the most votes to become the new consensus master node, and other consensus nodes send confirmation result message msgpost-vote To the new master node, message msg post-vote It includes: view number v+1, the last stable consensus block number BS, the new consensus master node number node k and the node signature Sign node k ;

[0059] Message msg received on the new consensus master node post-vote When the number is ≥ 2f+1, reply to all secondary consensus nodes with a message confirming that they have become the new consensus master node. vc-commit , notify all nodes to synchronize blocks to the last stable consensus block BS.

[0060] Here, a weighted incentive mechanism is used to re-elect the main consensus node. The election weight score is calculated through a series of incentive and penalty formulas based on the node verification accuracy, verification success, error history, continuous verification success, and error record. The node with the highest weight score is selected as the main node to ensure the suitability of the main consensus node election, reduce the probability of malicious nodes appearing, and further improve the consensus performance of the alliance chain.

[0061] Preferably, if the new consensus master node receives the message msg post-vote If the number is less than 2f+1, the election fails, and the original consensus master node notifies all consensus slave nodes to re-trigger the view change protocol.

[0062] The present invention also proposes a consortium chain consensus system based on weight-incentive master node election, the system comprising:

[0063] Malicious node calculation module, used to identify the initial consensus master node in the alliance chain nodes and calculate the number of malicious nodes f that the alliance chain can tolerate;

[0064] Request receiving and verification module: the consensus master node and consensus sub-node in the alliance chain receive the transaction on-chain request message sent by the client, and perform consensus master node verification and consensus sub-node verification;

[0065] Verification result sending module, each consensus secondary node verifies the consistency of the consensus primary node verification result and the verification result of this node, and obtains the verification result information, which includes the reply content r ACK Or reply content non-ACK , each consensus secondary node replies the verification result information to the consensus primary node;

[0066] Request response processing module, set the reply content r in the verification result information ACK The number of replies is α or the reply content r non-ACKThe number is β. When α≥2f or β≤f, if the consensus master node succeeds in verification, the transaction is allowed to be written into the latest block of the consensus master node, and the consensus master node replies to the client with a "transaction successful" message; if the consensus master node fails in verification, the transaction is rejected, and the consensus master node replies to the client with a "transaction failed" message;

[0067] When f≤α<2f or f<β≤2f, the consensus master node broadcasts to all consensus slave nodes to enter the PBFT consensus protocol and re-consensus on the transaction using the PBFT consensus protocol;

[0068] When 0≤α<f or β>2f, the consensus master node notifies all consensus slave nodes to trigger the view change protocol. All consensus slave nodes calculate the election weight score of their own nodes based on the records verified by the consensus slave nodes, and elect the node with the highest weight score as the new consensus master node. The new consensus master node inputs the request receiving verification module and restarts the consensus.

[0069] Compared with the prior art, the present invention has the following beneficial effects:

[0070] The present invention proposes a consortium chain consensus method and system based on weighted incentive master node election. For a transaction on-chain request from a client, all nodes in the consortium chain receive the request and perform consensus master node verification and consensus sub-node verification. Then, each consensus sub-node verifies the consistency of the verification result. According to the comparison between the number of feedbacks of reply content in the verification result information and the number of malicious nodes, combined with the consensus master node verification result, it is determined whether the transaction is written into the block. When no malicious nodes appear, the method has low complexity, fast running speed and high efficiency, which can improve the consensus performance of the consortium chain, provide higher TPS, and support the operation of businesses with high TPS requirements. However, when malicious nodes appear, the comparison result between the number of feedbacks of reply content in the verification result information and the number of malicious nodes does not meet the original consensus requirements, and the security credibility of the consortium chain cannot be guaranteed. The PBFT consensus protocol is used for consensus to improve the security and robustness of the consortium chain. However, the number of malicious nodes that the PBFT consensus protocol can tolerate also has a limit. Combined with the view replacement protocol, a weighted incentive mechanism is used to re-elect the master consensus node to ensure the suitability of the election of the master consensus node, reduce the possibility of the malicious node being elected as the master node, and further improve the consensus performance of the consortium chain. BRIEF DESCRIPTION OF THE DRAWINGS

[0071] Figure 1 A schematic diagram showing a flow chart of a consortium chain consensus method based on weight-incentive master node election proposed in Embodiment 1 of the present invention;

[0072] Figure 2 The entire structure diagram of the alliance chain consensus system based on weighted incentive master node election proposed in Example 2 of the invention is shown. DETAILED DESCRIPTION

[0073] The drawings are for illustrative purposes only and should not be construed as limiting the present patent;

[0074] In order to better illustrate the present embodiment, some parts of the drawings may be omitted, enlarged or reduced, and do not represent the actual size;

[0075] It is understandable to those skilled in the art that descriptions of certain well-known contents in the drawings may be omitted.

[0076] The positional relationships described in the drawings are only for illustrative purposes and should not be construed as limiting the present patent.

[0077] The technical solution of the present invention is further described below in conjunction with the accompanying drawings and embodiments.

[0078] Example 1

[0079] Considering that the maximum TPS (system throughput, which is also the number of system processing per second) of the alliance chain blockchain system using the traditional PBFT consensus algorithm is generally more than 10,000 TPS, and as the number of consensus nodes increases, the maximum TPS decays at a polynomial level. At this time, the blockchain consensus efficiency is low and it is difficult to support the normal operation of businesses with high TPS requirements. That is, sometimes the PBFT consensus algorithm is not necessarily used immediately, and in the Prepare and Commit stages, each consensus node must perform summary calculations and message broadcasts, and the message complexity is O(n 2 ). When the number of consensus nodes in the network increases, all consensus nodes must perform two-stage summary calculations and message broadcast operations, causing the performance of the traditional PBFT consensus algorithm to drop rapidly as the number of consensus nodes increases. When the performance of the alliance chain drops to a certain level, it may cause business interruptions on the alliance chain. In addition, the traditional PBFT consensus algorithm needs to regularly replace the master node, or replace the master node when the master node behaves maliciously. When no consensus node joins or exits the alliance chain, all consensus nodes will take turns serving as master nodes in order of their own numbers. It is fair for all nodes for all consensus nodes to take turns serving as master nodes, but the disadvantage is that this method cannot avoid the possibility of electing malicious nodes as master nodes, resulting in the failure of the current election process and the need for re-election, affecting the efficiency and overall performance of the alliance chain consensus. For this reason, an alliance chain consensus method based on weighted incentive master node election is proposed in Example 1 of the present invention, and its flow chart is shown as follows. Figure 1 As shown, the method includes:

[0080] S1. Calculate the number of malicious nodes f that the alliance chain can tolerate, and identify the initial consensus master node and consensus sub-node in the alliance chain nodes;

[0081] The expression for calculating the number of malicious nodes f that the alliance chain can tolerate is:

[0082]

[0083] Where N represents the total number of consensus nodes in the alliance chain; In addition, in the specific implementation, the selection of the initial consensus master node in the alliance chain node is usually a node that is initially considered to be highly reliable and will not tamper with the message.

[0084] S2. The consensus master node and consensus sub-node in the alliance chain receive the transaction on-chain request message sent by the client, and perform consensus master node verification and consensus sub-node verification;

[0085] Assume that the consensus master node and consensus sub-node in the alliance chain receive the transaction chain request message sent by the client as msg request ,msg request Contains transaction content m, transaction summary D(m) and client signature Sign c ; Among them, the consensus master node verification includes:

[0086] The consensus master node calculates the summary D′(m) of the transaction content m, and combines the summary D′(m) with the transaction on-chain request message msg sent by the client. request The transaction summary D(m) in the table is used to verify whether the two are equal, and the verification result is marked as r verification , forming a consensus master node verification result message msg verification , verification result message msg verification Included: verification result mark r verification , transaction content m, transaction summary D(m) and node signature Sign node k ;

[0087] The consensus node verification includes: each consensus node calculates the summary D′(m) of the transaction content m, and compares the summary D′(m) with the transaction on-chain request message msg sent by the client. request The transaction summary D(m) in is verified to see if the two are equal, thus forming the verification result message of this node.

[0088] S3. Each consensus secondary node verifies the consistency between the verification result of the consensus primary node and the verification result of the current node, and obtains the verification result information, which includes the reply content r ACK Or reply content non-ACK , each consensus secondary node replies the verification result information to the consensus primary node;

[0089] The consensus master node will verify the result message msg verification Sent to each consensus secondary node, each consensus secondary node receives the verification result message msg verification, verify the consistency between the verification result of the consensus master node and the verification result of this node, and obtain the verification result information;

[0090] If the verification results are consistent, the content r will be replied ACK Encapsulate the verification result information, otherwise, reply content r non-ACK Encapsulated into verification result information; the verification result information also includes transaction content m, transaction summary D(m) and node signature Sign node k .

[0091] The steps between S1 and S3 are a simple consensus protocol. When no malicious nodes appear, the efficiency of the consensus process is guaranteed, higher TPS is provided, and the business operation with high TPS requirements is supported. Next, the content r is replied according to the verification result information. ACK or non-ACK Compare the number of nodes with the number of malicious nodes, and combine the verification result of the consensus master node to determine whether the transaction is written into the block, and execute step S4. Figure 1 , Considering that the security and credibility of the alliance chain cannot be guaranteed when malicious nodes appear, the PBFT consensus protocol is used for consensus to improve the robustness of the alliance chain consensus. However, there is a limit to the number of malicious nodes that the PBFT consensus protocol can tolerate. Therefore, combined with the view replacement protocol, the weight incentive mechanism is used to re-elect the main consensus node to ensure the suitability of the main consensus node election, reduce the probability of malicious nodes appearing, and further improve the consensus performance of the alliance chain. Execute step S4:

[0092] S4. Set the reply content r in the verification result information ACK The number of replies is α or the reply content r non-ACK The number is β. When α≥2f or β≤f, if the consensus master node succeeds in verification, the transaction is allowed to be written into the latest block of the consensus master node, and the consensus master node replies to the client with a "transaction successful" message; if the consensus master node fails in verification, the transaction is rejected, and the consensus master node replies to the client with a "transaction failed" message;

[0093] When f≤α<2f or f<β≤2f, the consensus master node broadcasts to all consensus slave nodes to enter the PBFT consensus protocol and re-consensus on the transaction using the PBFT consensus protocol;

[0094] When 0≤α<f or β>2f, the consensus master node notifies all consensus slave nodes to trigger the view change protocol. All consensus slave nodes calculate the election weight score of their own nodes based on the records verified by the consensus slave nodes, elect the node with the highest weight score as the new consensus master node, and return to step S2 for re-consensus.

[0095] At this point, there are three situations:

[0096] (I) When α≥2f or β≤f, if the verification result is marked r verification for:

[0097] D′(m)=D(m)

[0098] The consensus master node verifies successfully, and the consensus master node encapsulates the "execute transaction" message msg sbft-commit , and sent to all consensus sub-nodes, and the consensus sub-nodes received the "execute transaction" message msg sbft-commit , decides to execute the transaction and writes the transaction into the latest block of this node. The consensus master node replies to the client with a "transaction successful" message; if the verification result is marked r verification for:

[0099] D′(m)≠D(m)

[0100] If the consensus master node verification fails, the consensus master node encapsulates the "do not execute transaction" message msg sbft-commit , sent to all consensus sub-nodes, and the consensus sub-nodes received the "do not execute transaction" message msg sbft-commit , the transaction is not executed and the block is not written, and the consensus master node replies to the client with a "transaction failed" message. After the consensus master node replies to the client with a "transaction successful" message or the consensus master node replies to the client with a "transaction failed" message, for the next transaction on-chain request sent by the client, it still returns to step S2 to continue executing the next round of consensus.

[0101] (II) When f≤α<2f or f<β≤2f, the consensus master node broadcasts to all consensus slave nodes to enter the PBFT consensus protocol. The process of re-consensus on the transaction using the PBFT consensus protocol is as follows:

[0102] The client sends a transaction on-chain request message to the consensus master node;

[0103] The consensus master node verifies the message sent by the client, and after passing the verification, broadcasts the transaction Pre-prepare message to all consensus slave nodes;

[0104] Each consensus slave node verifies the received transaction Pre-prepare message, and after passing the verification, broadcasts the transaction Prepare message to other consensus slave nodes and consensus master nodes except itself;

[0105] The consensus master node and consensus sub-node verify the received transaction Prepare message. If the verification passes and the number of consistent verifications is ≥ 2f+1, the transaction Commit message is broadcast to other consensus sub-nodes and the consensus master node except themselves.

[0106] The consensus master node and consensus slave node verify the received transaction Commit message. When the number of correct Commit message verification results is ≥ 2f+1, the transaction is written into the latest block of the node and a Reply message msg is returned. reply = "Transaction successful" to the client.

[0107] The above process of re-consensus using the PBFT consensus protocol is as follows:

[0108] Request phase: The client sends a transaction on-chain request message to the consensus master node request , message msg request Includes: transaction content m, transaction summary D(m) and client signature Sign c ;

[0109] Pre-prepare stage: the consensus master node receives the client's message msg request , the consensus master node verifies the message msg request Client signature within Sign c Is it correct?

[0110] If the verification result of the client signature is correct, the Pre-prepare message msg is broadcast to other consensus nodes pre-prepare , Pre-prepare message msg pre-prepare Includes: transaction content m, transaction summary D(m) and consensus master node signature Sign node k ; If the verification result of the client signature is incorrect, it is recorded as a consensus failure and a "transaction failure" is sent to the client.

[0111] Prepare phase: The consensus secondary node receives the message msg from the consensus primary node pre-prepare , perform Prepare phase verification: message msg pre-prepare Consensus master node signature in Sign node k Is it correct? Calculate the summary D′(m) of the transaction content m and msg pre-prepare Whether the transaction summary D(m) in the

[0112] If the verification result is consistent prepare = "consistent", that is, D'(m) == D(m), then broadcast the Prepare message msg to other consensus nodes prepare , message msg prepare Includes: transaction content m, transaction summary D(m) and the signature of this consensus sub-node Sign node k ; If the verification result is inconsistent r′ prepare= "inconsistent", that is, D′(m)≠D(m), then broadcast the Prepare message msg to other consensus nodes prepare =<transaction content m, transaction summary D(m), r′ prepare 、Signature of this secondary node node k >.

[0113] Commit phase: The consensus master node and consensus slave node receive the message msg prepare , perform Commit phase verification:

[0114] Verify msg prepare Sub-node signature in Sign node k Is it correct, msg prepare The transaction summary D(m) and msg in pre-prepare Whether the transaction summary D(m) in is consistent.

[0115] If the verification result of the node Commit phase is consistent, and the received r prepare = "consistent" number ≥ 2f+1, then broadcast Commit message msg to other consensus nodes commit , message msg commit Includes: transaction content m, transaction summary D(m) and the node signature Sign node k ; If the verification result of the node Commit phase is consistent, and the received r prepare = "consistent" number < 2f+1, it is recorded as a consensus failure and a "transaction failure" is sent to the client.

[0116] Reply stage: the consensus master node and consensus slave node receive the msg commit , perform reply phase verification and verify msg commit The node signature in node k Is the signature correct? If: the node receives and verifies the msg in the reply phase. commit If the number is ≥ 2f+1, the transaction will be written into the latest block of the node and a reply message msg will be returned. reply = "Transaction successful" to the client; if the node receives and verifies the result is correct in the Reply phase, commit If the number is less than 2f+1, it is recorded as a consensus failure and a "transaction failure" message is sent to the client. Then the simple consensus protocol is returned.

[0117] Here, when f≤α<2f (or f<β≤2f), malicious nodes appear, and the number of feedbacks in the reply content in the verification result information and the number of malicious nodes do not meet the basic consensus. The security and credibility of the alliance chain cannot be guaranteed. The PBFT consensus protocol is used for consensus to improve the robustness of the alliance chain consensus. reply = After "transaction successful" is sent to the client, for the next transaction on-chain request sent by the client, it will still return to step S2 to continue executing the next round of consensus; when the number of correct Commit message verification results is less than 2f+1, the Reply message msg is returned reply = "Transaction failed" is sent to the client. For the next transaction on-chain request sent by the client, the process returns to step S2 to continue the next round of consensus.

[0118] (III) When 0≤α<f or β>2f, the consensus master node broadcasts the message msg vc Notify all consensus sub-nodes to trigger the execution of the view change protocol, message msg vc Includes: view number v+1, the last stable consensus block number BS and node signature Sign node k ; All consensus secondary nodes receive the message msg vc After that, all consensus nodes calculate the election weight P of node k according to the records verified by the consensus nodes. node k The process is:

[0119] 1) Calculate the accuracy, the expression is:

[0120]

[0121] Among them, Tk L The latest transaction number verified by consensus secondary node k; Tk O The first transaction number verified by the k-th consensus secondary node; Tk E The transaction sequence number set of the k-th consensus secondary node verification error, expressed as: Tk E ={Tk 1 , Tk 2 , Tk 3 , …, Tk n}, E=1, 2, 3,..., n, Tk 1 Tk is the transaction number of the first verification error of consensus node k. n The transaction sequence number of the nth verification error of consensus node k; when Correctness>99%, the consensus node is eligible to be elected as the consensus master node;

[0122] 2) Compute node basic points B, the expression is:

[0123] P B =A×Correctness

[0124] Among them, A represents the modifiable weight reference coefficient;

[0125] 3) Calculate the reward P for correct continuous correction SC , the expression is:

[0126]

[0127] 4) Calculate the historical penalty P for verification errors EH , the expression is:

[0128]

[0129] 5) Calculate the consecutive check error penalty P EC , the expression is:

[0130] a=0.05×(Tk L -Tk O +1), C = 1.57 × A × a, x = Tk n -Tk n-1

[0131]

[0132] Among them, a and C represent intermediate parameters;

[0133] 6) Calculate the election weight P of node k node k , the expression is:

[0134] P node k =P B +P SC +P EH -P EC

[0135] Among them, P node k The consensus node calculates the election weight of node k based on the records verified by the consensus node in step S2. node k After that, P node k Encapsulate into reply message msg Pre-vote , broadcast view switch reply message msg Pre-vote To the alliance chain, the message msg Pre-vote It includes the view number v+1, the last stable consensus block number BS, and the node election weight P node k And node signature Sign node k ;

[0136] All consensus nodes in the alliance chain receive the message msg Pre-vote , comparing each election weight P node 1 ~P node N Make an election, N represents the total number of consensus nodes in the alliance chain; each node in the alliance chain encapsulates the election result into the election message msg vote , broadcast election message msg vote To the alliance chain, election message msg vote It includes: view number v+1, the last stable consensus block number BS, the election result voteresult and the node signature Sign node k ;

[0137] Each consensus node in the alliance chain receives the election message from other consensus nodes, selects the consensus node with the most votes to become the new consensus master node, and other consensus nodes send confirmation result message msg post-vote To the new master node, message msg post-vote It includes: view number v+1, the last stable consensus block number BS, the new consensus master node number node k and the node signature Sign node k ;

[0138] Message msg received on the new consensus master node post-vote When the number is ≥ 2f+1, reply to all secondary consensus nodes with a message confirming that they have become the new consensus master node. vc-commit , notify all nodes to synchronize blocks to the last stable consensus block BS. If the new consensus master node receives the message msg post-vote If the number is less than 2f+1, the election fails, and the original consensus master node notifies all consensus slave nodes to re-trigger the view change protocol.

[0139] A weighted incentive mechanism is used to re-elect the main consensus node. The election weight score is calculated through a series of incentive and penalty formulas based on the node verification accuracy, verification success, error history, continuous verification success, and error record. The node with the highest weight score is selected as the main node to ensure the suitability of the main consensus node election, reduce the probability of malicious nodes appearing, and further improve the consensus performance of the alliance chain.

[0140] Example 2

[0141] like Figure 2 As shown, the present invention also proposes a consortium chain consensus system based on weight incentive master node election, which is used to implement the method described in Example 1, see Figure 2 , the system includes:

[0142] Malicious node calculation module 101, used to identify the initial consensus master node in the alliance chain nodes and calculate the number f of malicious nodes that the alliance chain can tolerate;

[0143] The request receiving and verification module 102, the consensus master node and the consensus sub-node in the alliance chain receive the transaction on-chain request message sent by the client, and perform consensus master node verification and consensus sub-node verification;

[0144] Verification result verification and sending module 103, each consensus secondary node verifies the consistency of the consensus primary node verification result and the verification result of the node, and obtains verification result information, which includes the reply content r ACK Or reply content non-ACK , each consensus secondary node replies the verification result information to the consensus primary node;

[0145] Request response processing module 104, set the reply content r in the verification result information ACK The number of replies is α or the reply content r non-ACK The number is β. When α≥2f or β≤f, if the consensus master node succeeds in verification, the transaction is allowed to be written into the latest block of the consensus master node, and the consensus master node replies to the client with a "transaction successful" message; if the consensus master node fails in verification, the transaction is rejected, and the consensus master node replies to the client with a "transaction failed" message;

[0146] When f≤α<2f or f<β≤2f, the consensus master node broadcasts to all consensus slave nodes to enter the PBFT consensus protocol and re-consensus on the transaction using the PBFT consensus protocol;

[0147] When 0≤α<f or β>2f, the consensus master node notifies all consensus slave nodes to trigger the view change protocol. All consensus slave nodes calculate the election weight score of their own nodes based on the records verified by the consensus slave nodes, and elect the node with the highest weight score as the new consensus master node. The new consensus master node inputs the request receiving verification module and restarts the consensus.

[0148] The positional relationships described in the drawings are only for illustrative purposes and should not be construed as limiting the present patent.

[0149] Obviously, the above embodiments of the present invention are only examples for clearly illustrating the present invention, and are not intended to limit the embodiments of the present invention. For those skilled in the art, other different forms of changes or modifications can be made based on the above description. It is not necessary and impossible to list all the embodiments here. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the protection scope of the claims of the present invention.

Claims

1. A consortium chain consensus method based on weighted incentive master node election, characterized in that: include: S1. Calculate the number of malicious nodes f that the alliance chain can tolerate, and identify the initial consensus master node and consensus sub-node in the alliance chain nodes; S2. The consensus master node and consensus sub-node in the alliance chain receive the transaction on-chain request message sent by the client, and perform consensus master node verification and consensus sub-node verification; S3. Each consensus secondary node verifies the consistency between the verification result of the consensus primary node and the verification result of the current node, and obtains the verification result information, which includes the reply content r ACK Or reply content non-ACK , each consensus secondary node replies the verification result information to the consensus primary node; S4. Set the reply content r in the verification result information ACK The number of replies is α or the reply content r non-ACK The number is β. When α≥2f or β≤f, if the consensus master node succeeds in verification, the transaction is allowed to be written into the latest block of the consensus master node, and the consensus master node replies to the client with a "transaction successful" message; if the consensus master node fails in verification, the transaction is rejected, and the consensus master node replies to the client with a "transaction failed" message; When f≤α﹤2f or f﹤β≤2f, the consensus master node broadcasts to all consensus slave nodes to enter the PBFT consensus protocol and re-consensus on the transaction using the PBFT consensus protocol; When 0≤α﹤f or β﹥2f, the consensus master node notifies all consensus slave nodes to trigger the view change protocol. All consensus slave nodes calculate the election weight score of their own nodes based on the records verified by the consensus slave nodes, elect the node with the highest weight score as the new consensus master node, and return to step S2 for re-consensus; Among them, all consensus sub-nodes calculate the election weight P of node k based on the records verified by the consensus sub-nodes. node The process is: 1) Calculate the accuracy, the expression is: Among them, Tk L The latest transaction number verified by consensus secondary node k; Tk O The first transaction number verified by the k-th consensus secondary node; Tk E The transaction sequence number set of the k-th consensus secondary node verification error, expressed as: Tk E ={Tk1,k2,k3,…,k n }, E = 1, 2, 3, ..., n, Tk1 is the transaction number of the first verification error of the k-th consensus node, Tk n The transaction sequence number of the nth verification error of consensus node k; when Correctness>99%, the consensus node is eligible to be elected as the consensus master node; 2) Compute node basic points B , the expression is: P B =A×Correctness Among them, A represents the modifiable weight reference coefficient; 3) Calculate the reward P for correct continuous correction SC , the expression is: 4) Calculate the historical penalty P for verification errors EH , the expression is: 5) Calculate the consecutive check error penalty P EC , the expression is: <h2 style=";text-align:left;direction:ltr">a = 0.05×(Tk<h2 style=";text-align:left;direction:ltr"> L <h2 style=";text-align:left;direction:ltr"> -Tk<h2 style=";text-align:left;direction:ltr"> o <h2 style=";text-align:left;direction:ltr"> +1),C=1.57×A×a,x=Tk<h2 style=";text-align:left;direction:ltr"> n <h2 style=";text-align:left;direction:ltr"> -Tk<h2 style=";text-align:left;direction:ltr"> n-1 Among them, a and C represent intermediate parameters; 6) Calculate the election weight P of node k node k , the expression is: P node k =P B +P SC +P EH -P EC Among them, P node k Indicates the election weight of consensus secondary node k.

2. The alliance chain consensus method based on weighted incentive master node election according to claim 1 is characterized in that: The expression for calculating the number of malicious nodes f that the alliance chain can tolerate in step S1 is: Where N represents the total number of consensus nodes in the alliance chain; Indicates rounding down.

3. The alliance chain consensus method based on weighted incentive master node election according to claim 1 is characterized in that: Assume that the consensus master node and consensus sub-node in the alliance chain receive the transaction chain request message sent by the client as msg request ,msg request Contains transaction content m, transaction summary D(m) and client signature Sign c ; The consensus master node verification described in step S2 includes: The consensus master node calculates the summary D′(m) of the transaction content m, and adds the summary D′(m) to the transaction on-chain request message msg sent by the client. request The transaction summary D(m) in the table is verified to see if they are equal, and the verification result is marked as r verification , forming a consensus master node verification result message msg verification , verification result message msg verification Included: verification result mark r verification , transaction content m, transaction summary D(m) and node signature Sign node ; The consensus node verification includes: each consensus node calculates the summary D′(m) of the transaction content m, and compares the summary D′(m) with the transaction on-chain request message msg sent by the client. request The transaction summary D(m) in is verified to see if the two are equal, thus forming the verification result message of this node.

4. The alliance chain consensus method based on weighted incentive master node election according to claim 3 is characterized in that: The consensus master node will verify the result message msg verification Sent to each consensus secondary node, each consensus secondary node receives the verification result message msg verification , verify the consistency between the verification result of the consensus master node and the verification result of this node, and obtain the verification result information; If the verification results are consistent, the content r will be replied ACK Encapsulate the verification result information, otherwise, reply content r non-ACK Encapsulate the verification result information; The verification result information also includes the transaction content m, transaction summary D(m) and node signature Sign nodek .

5. The alliance chain consensus method based on weighted incentive master node election according to claim 3 is characterized in that: In step S4, when α≥2f or β≤f, if the check result mark r verification for: D′(m)=(m) The consensus master node verifies successfully, and the consensus master node encapsulates the "execute transaction" message msg sbft-commit , and sent to all consensus sub-nodes, and the consensus sub-nodes received the "execute transaction" message msg sbft-commit , decides to execute the transaction and writes the transaction into the latest block of this node. The consensus master node replies to the client with a "transaction successful" message; if the verification result is marked r verification for: D′(m)≠D(m) If the consensus master node verification fails, the consensus master node encapsulates the "do not execute transaction" message msg sbft-commit , sent to all consensus sub-nodes, and the consensus sub-nodes receive the "do not execute transaction" message msg sbft-commit , the transaction is not executed and the block is not written, and the consensus master node replies to the client with a "transaction failed" message.

6. The alliance chain consensus method based on weighted incentive master node election according to claim 3 is characterized in that: In step S4, when f≤α﹤2f or f﹤β≤2f, the consensus master node broadcasts to notify all consensus slave nodes to enter the PBFT consensus protocol. The process of re-consensus on the transaction using the PBFT consensus protocol is as follows: The client sends a transaction on-chain request message to the consensus master node; The consensus master node verifies the message sent by the client, and after passing the verification, broadcasts the transaction Pre-prepare message to all consensus slave nodes; Each consensus slave node verifies the received transaction Pre-prepare message, and after passing the verification, broadcasts the transaction Prepare message to other consensus slave nodes and consensus master nodes except itself; The consensus master node and consensus sub-node verify the received transaction Prepare message. If the verification passes and the number of consistent verifications is ≥ 2f+1, the transaction Commit message is broadcast to other consensus sub-nodes and the consensus master node except themselves. The consensus master node and consensus slave node verify the received transaction Commit message. When the number of correct Commit message verification results is ≥ 2f+1, the transaction is written into the latest block of the node and a Reply message msg is returned. reply = "Transaction successful" to the client.

7. The alliance chain consensus method based on weighted incentive master node election according to claim 3 is characterized in that: The consensus node calculates the election weight P of node k based on the records verified by the consensus node in step S2. node k After that, P node k Encapsulate into reply message msg Pre-vote , broadcast view switch reply message msg Pre-vote To the alliance chain; All consensus nodes in the alliance chain receive the message msg Pre-vote , comparing each election weight P node 1 ~P nobe N Make an election, N represents the total number of consensus nodes in the alliance chain; each node in the alliance chain encapsulates the election result into the election message msg vote , broadcast election message msg vote To the alliance chain; Each consensus node in the alliance chain receives the election message from other consensus nodes, selects the consensus node with the most votes to become the new consensus master node, and other consensus nodes send confirmation result message msg post-vote To the new master node; Message msg received on the new consensus master node post-vote When the number is ≥ 2f+1, reply to all secondary consensus nodes with a message msg confirming that they have become the new consensus master node vc-commit， Notify all nodes to synchronize blocks to the last stable consensus block BS.

8. The alliance chain consensus method based on weighted incentive master node election according to claim 7 is characterized in that: If the new consensus master node receives the message msg post-vote If the number is less than 2f+1, the election fails, and the original consensus master node notifies all consensus slave nodes to re-trigger the view change protocol.

9. A consortium chain consensus system based on weighted incentive master node election, applying the consortium chain consensus method based on weighted incentive master node election described in any one of claims 1 to 8, characterized in that: The system comprises: Malicious node calculation module, used to identify the initial consensus master node in the alliance chain nodes and calculate the number of malicious nodes f that the alliance chain can tolerate; Request receiving and verification module: the consensus master node and consensus sub-node in the alliance chain receive the transaction on-chain request message sent by the client, and perform consensus master node verification and consensus sub-node verification; Verification result sending module, each consensus secondary node verifies the consistency of the consensus primary node verification result and the verification result of this node, and obtains the verification result information, which includes the reply content r ACK Or reply content non-ACK , each consensus secondary node replies the verification result information to the consensus primary node; Request response processing module, set the reply content r in the verification result information ACK The number of replies is α or the reply content r non-ACK The number is β. When α≥2f or β≤f, if the consensus master node succeeds in verification, the transaction is allowed to be written into the latest block of the consensus master node, and the consensus master node replies to the client with a "transaction successful" message; if the consensus master node fails in verification, the transaction is rejected, and the consensus master node replies to the client with a "transaction failed" message; When f≤α﹤2f or f﹤β≤2f, the consensus master node broadcasts to all consensus slave nodes to enter the PBFT consensus protocol and re-consensus on the transaction using the PBFT consensus protocol; When 0≤α﹤f or β﹥2f, the consensus master node notifies all consensus slave nodes to trigger the view change protocol. All consensus slave nodes calculate the election weight score of their own nodes based on the records verified by the consensus slave nodes, and elect the node with the highest weight score as the new consensus master node. The new consensus master node inputs the request receiving verification module and restarts the consensus.

Images