A consortium chain consensus method and system based on an improved three-stage consensus

Abstract

The application discloses a kind of alliance chain consensus method and system based on improved three-stage consensus.The consensus mechanism of the present application includes the following steps: alliance chain initialization;Alliance chain selects suitable leader according to current round number and system preset parameter;After receiving the transaction request of client, the leader initiates improved three-stage consensus;After the nodes in the alliance chain reach consensus, the transaction is packaged into block;After the system performs several times consensus, configuration discovery protocol is executed;To ensure system recoverability, the system performs checkpoint protocol every certain period of time.The present application optimizes the consensus process under the dynamic change of system node, improves the consensus efficiency of consensus mechanism to a certain extent under the condition that node scale is larger, and guarantees the expansibility of system.Configuration discovery protocol is realized between system nodes, and node configuration remains dynamic consistent for a long time, so as to improve the consensus efficiency between nodes.

Description

TECHNICAL FIELD

[0001] The application relates to a consortium chain consensus method and system based on an improved three-stage consensus, and belongs to the field of blockchains. BACKGROUND

[0002] A blockchain is a decentralized distributed ledger, and its main features are decentralization, trustlessness and non-tamperability. These features make the blockchain technology have a wide application prospect in the field of supply chains.

[0003] According to the different access methods, the blockchain is divided into public chains, consortium chains and private chains. The public chain is a blockchain in which everyone can participate, such as Bitcoin and Ethereum. The private chain is a blockchain controlled by a single organization or enterprise for internal use. The consortium chain is a blockchain jointly constructed by several organizations or enterprises, and only authorized nodes can participate in consensus. Among them, the consortium chain is the most suitable for the supply chain mechanism.

[0004] Due to the node network environment, the blockchain system needs a consensus mechanism to reach consensus on each transaction among all the accounting nodes, so as to ensure the safety of the transaction. The practical Byzantine fault tolerance algorithm (PBFT) guarantees the safety and correctness of the system and provides (N-1) / 3 fault tolerance, but the consensus time of the mechanism is long, the network overhead in the consensus process is large, and the consensus efficiency is not high in the case of large node scale.

[0005] At present, some improved consensus mechanisms based on consortium chains have been proposed, among which the better ones are: (1) the consensus mechanism DPoS based on proxy proof of stake, which greatly improves the system throughput and enhances the controllability of the system by specifying a small group of nodes; (2) the consensus mechanism VPBFT based on the voting mechanism and the POV mechanism, which does not need to restart the system when the number of nodes changes; (3) the consensus mechanism EBFT based on RSA encryption consensus, which improves the performance bottleneck of the BFT algorithm in the case of excessive number of nodes by clustering and grouping and forming a multi-layer topology. Although the above methods have achieved good results, these methods still have the following problems: (1) when the nodes in the consortium chain change dynamically, the node information configuration problem of the new nodes, and the other nodes do not know when the nodes exit the system. (2) The existing consensus mechanism ignores the network splitting situation, and the information and configuration status of the nodes in the consensus group may not be consistent. SUMMARY

[0006] Purpose of the invention: In view of the shortcomings of the prior art, the purpose of this invention is to provide a consortium blockchain consensus method and system based on an improved three-phase consensus, so as to solve the problem of inconsistent configuration status between nodes in the consortium blockchain during system operation, as well as the problem of consensus efficiency of the consortium blockchain consensus mechanism.

[0007] Technical Solution: To achieve the above objectives, this invention provides a consortium blockchain consensus method based on an improved three-phase consensus mechanism, comprising the following steps:

[0008] Step 1: Consortium blockchain initialization; including the Membership Manager (MsM) and the information multiset M of each node. mul ;

[0009] Step 2: Select a leader based on the current round number and system preset parameters; if the leader malfunctions, select a suitable leader node based on the current round number and system preset parameters.

[0010] Step 3: After receiving a transaction request from the client, the leader initiates a three-phase consensus request. After the consensus is completed, a new round of consensus begins. The three-phase consensus consists of a proposal phase, an attempt consensus phase, and a randomization phase. After each phase is completed, the round number is incremented by one. If a node fails to recover the transaction set information in the proposal phase or does not receive a sufficient number of approval messages in the attempt consensus phase, it enters the randomization phase and randomly selects the transaction set that has received the most approvals in the approval multiset or an empty transaction set.

[0011] Step 4: If a node wants to join or leave the system, it changes the node information in MsM, executes a JOIN or QUIT operation, and executes the configuration update protocol.

[0012] Step 5: After completing a certain number of three-phase consensus operations, execute the configuration discovery protocol;

[0013] Step 6: After the system has been running for a period of time, execute the checkpoint protocol.

[0014] After the configuration update protocol, configuration discovery protocol, and checkpoint protocol are executed, a new round of consensus begins.

[0015] Furthermore, the node membership manager MsM in step 1 is used to register node information, modify membership relationships between nodes, deregister node information, save current configuration information, assign node serial numbers, and verify node information; the node information multiset M mul It is used to verify the authenticity of received messages, store transaction sets that have not yet been recorded in the ledger, store messages that have been authenticated and formatted, and recover information using error correction codes.

[0016] Further, the selection of the initial leader in step 2 is determined by the system preset.

[0017] The system preset parameter in step 2 It will change during the operation of the system, and the setting method is as follows:

[0018] ;

[0019] Wherein, k is the current leader node number, is a randomly generated hash value.

[0020] The leader selection method is:

[0021] ;

[0022] Wherein, L is the selected leader node number, R is the current round number, is the system preset parameter in decimal representation, and n is the current number of nodes in the system.

[0023] Further, the three-stage consensus process in step 3 is as follows:

[0024] Proposal stage: After receiving the transaction request from the client, the leader proposes a set of transactions, and broadcasts the transaction set to all nodes. The detailed steps of this stage are as follows:

[0025] Step P1: Divide the transaction set into multiple information blocks, and send them to other nodes along with error correction codes;

[0026] Step P2: After receiving the information, the node broadcasts it to other nodes;

[0027] Step P3: After receiving all the information blocks, the node recovers them through multiple set verification. If the complete transaction set can be recovered, execute step P5; otherwise, execute step P4;

[0028] Step P4: The node's multiple set deletes the current transaction set and sleeps until the randomization stage is executed;

[0029] Step P5: Execute the attempt consensus stage;

[0030] Attempt consensus stage: All trusted nodes broadcast the received transaction set, approve and finally confirm the information according to the received approval information. The detailed steps of this stage are as follows:

[0031] Step AC1: After recovering the transaction set from the proposal, the node approves the transaction set and broadcasts it to other nodes through the multiple set. If it is from the randomization stage to this stage, only the approved transaction set and the approval information need to be broadcast to other nodes;

[0032] Step AC2: When the node receives more than n-f pieces of confirmation information of the transaction set, execute step AC3; otherwise, execute step AC5; f is the number of Byzantine nodes;

[0033] Step AC3: The node sends confirmation information to the leader;

[0034] Step AC4: When the leader receives more than n-f pieces of confirmation information, the consensus is completed; otherwise, execute step AC6; if the transaction set agreed upon in the received confirmation information is not the one proposed by the leader, the leader also needs to replace the transaction set to complete the consensus;

[0035] Step AC5: The node records the transaction set in the ledger, and the multi-set deletes the current transaction set, and executes step AC6;

[0036] Step AC6: Execute the randomization phase;

[0037] Randomization phase: Process the nodes that failed to reach agreement in the attempt consensus phase, and the detailed steps of this phase are:

[0038] Step R1: The node executes different behaviors according to the Coin function, if the value is 1, execute step R2; otherwise, execute step R3;

[0039] Step R2: The multi-set of the node selects the transaction set that has obtained the most agreement, and the node agrees to the transaction set;

[0040] Step R3: The multi-set of the node agrees to the empty transaction set, and the node stops until it resumes in the next randomization phase;

[0041] Step R4: Execute the attempt consensus phase.

[0042] Further, in the three-phase consensus process, the round number is increased by one each time a consensus phase is completed, and the round number is recalculated after the leader node is replaced; when the round numbers of multiple nodes are inconsistent, the leader will take the longest round number in the nodes as the round number of this round consensus after completing the consensus; when the round number exceeds the upper limit of 8, the view switching protocol is executed.

[0043] Further, the joining and exiting of the node in step 4 need to send a join request message or an exit request message to the current leader and MsM, and the leader needs to verify the request to MsM after receiving the message. After verification, the node successfully joins or exits the alliance chain system, and the node number in MsM is updated. The JOIN operation and QUIT operation of the node need to be executed after the consensus is completed, and cannot be executed during the consensus process.

[0044] Specifically, when a node wants to join the consensus, the node information is registered in the MsM, the MsM audits the information, if it passes the audit, a serial number is assigned to it, and the current round leader is informed to join the new node, and then the JOIN protocol is executed.

[0045] Further, the execution process of the JOIN protocol is as follows:

[0046] Step J1: The node sends a join request to the leader of the current round;

[0047] Step J2: The leader of the current round receives the join request sent by the new node, after the consensus of the current round is ended, the leader verifies the information of the new node using the record in the MsM;

[0048] Step J3: After the leader verifies, the information of the new node joining is informed to all nodes;

[0049] Step J4: After the node receives the information of the new node joining, the node broadcasts the confirmation message to other nodes after confirming the receipt of the message;

[0050] Step J5: When the node receives the confirmation information sent by other n-f nodes, the node sends the confirmation information to the leader;

[0051] Step J6: After the leader receives the confirmation information of n-f nodes, the configuration update protocol is executed;

[0052] Step J7: After the configuration update is completed, the new node formally joins the system and is allowed to participate in the consensus.

[0053] Further, when a node wants to exit the alliance chain system, the node executes the QUIT protocol. The execution process of the QUIT protocol is as follows:

[0054] Step Q1: The node broadcasts the exit request to all other nodes, but still needs to participate in and complete the current round consensus;

[0055] Step Q2: After the node receives the exit request, the node confirms and sends the confirmation information to other nodes;

[0056] Step Q3: After the node receives the confirmation information of n-f nodes, the node sends the confirmation information to the leader;

[0057] Step Q4: After the leader receives the confirmation information sent by n-f nodes, the configuration update protocol is executed;

[0058] Step Q5: After the configuration update is completed, the node information is deregistered in the MsM, and the old node formally exits the system.

[0059] Further, the purpose of the configuration update protocol in step 4 is to ensure that all node configuration information is consistent when the node relationship changes. The execution process of the configuration update protocol is as follows:

[0060] Step CU1: the leader sends a configuration update request to the MsM, and the MsM audits the uniformity;

[0061] Step CU2: the leader sends the configuration after the change of the node relationship to all nodes, including the new node;

[0062] Step CU3: after receiving the new configuration, the node broadcasts the new configuration to other nodes;

[0063] Step CU4: after receiving n-f same configuration information, the node sends a confirmation information to the leader, and updates the configuration of itself; (the node that does not receive n-f configuration information will solve the configuration problem in the configuration discovery protocol)

[0064] Step CU5: after receiving n-f confirmation information, the leader sends the current configuration to the MsM, and the configuration update ends. Otherwise, step CU2 is executed.

[0065] Further, the purpose of the configuration discovery protocol in step 5 is to ensure that the nodes in the alliance chain can maintain the same configuration status for a long time, thereby improving the consensus efficiency and reducing the influence of the Byzantine error on the consensus. The specific process of the configuration discovery protocol is as follows:

[0066] Step CD1: the leader broadcasts a DISCOVER command to all nodes;

[0067] Step CD2: after receiving the DISCOVER command, all nodes broadcast their current configuration status to other nodes;

[0068] Step CD3: the multiple sets of nodes compare the received configuration status, and if the configuration status is not the latest, the node updates the configuration of itself.

[0069] Based on the same inventive concept, the present application provides a computer system, which comprises a memory, a processor and a computer program stored on the memory and capable of running on the processor, wherein the computer program, when loaded into the processor, implements the steps of the alliance chain consensus method based on the improved three-phase consensus.

[0070] Beneficial effects: the application gives a kind of alliance chain consensus mechanism based on improved three-stage consensus, which can reduce the communication pressure of leader node, so as to reduce the communication overhead, especially in large-scale alliance chain, can effectively improve the consensus speed.In order to solve the dynamic change of nodes in the chain and the corresponding configuration problem, JOIN protocol, QUIT protocol and configuration update protocol are used to solve the joining, exiting and configuration problem of nodes.In order to improve the problem of complex execution steps of original PBFT consensus, three-stage consensus protocol is proposed to improve the node consensus efficiency.Compared with the prior art, the application has the following advantages:

[0071] (1) The application provides a kind of alliance chain consensus mechanism based on improved three-stage consensus, by improving the consistency protocol in PBFT to three-stage consensus protocol, rely on randomization phase to force node to recognize a transaction set, thereby effectively reducing the number of rounds required to reach consensus, thereby reducing the time required for consensus, in some large node size, still can guarantee good performance.

[0072] (2) The application adds configuration update protocol for the dynamic change of nodes in improved PBFT, which can realize the fast configuration update of nodes in the system and improve the reliability of the system.

[0073] (3) The application provides a kind of alliance chain consensus mechanism based on improved three-stage consensus, by introducing configuration discovery protocol, node configuration is executed with multiple consensus stages as a period of configuration update operation, which can further improve the consensus speed.

[0074] (4) The application provides a kind of alliance chain consensus mechanism based on improved three-stage consensus, by changing the way of sending transaction set of proposal phase leader, improving the information throughput of leader node, transferring the throughput pressure of leader to other nodes, so as to guarantee the performance in large-scale node environment. BRIEF DESCRIPTION OF DRAWINGS

[0075] Figure 1 It is the overall flowchart of the embodiment of the application.

[0076] Figure 2 It is the process diagram of consensus in ideal state of the embodiment of the application. DETAILED DESCRIPTION

[0077] The application will be further illustrated in conjunction with specific embodiments, and it should be understood that these embodiments are only used to illustrate the application and not to limit the scope of the application, and after reading the application, those skilled in the art can modify various equivalent forms of the application, which all fall within the scope defined by the claims attached hereto.

[0078] The embodiment of the application discloses a consortium chain consensus method based on an improved three-stage consensus, as shown in the figure, mainly comprising the following steps: Figure 1

[0079] Step 1: consortium chain initialization, MsM (Membership Manager, membership manager) is responsible for registering node information, assigning node serial numbers, and initializing information multiple sets M mul (Multiple Message) of all nodes.

[0080] The responsibilities of MsM are: registering node information, modifying the membership relationship between nodes, canceling node information, saving current configuration information, assigning node serial numbers (node serial numbers start from 0), and verifying node information. The information multiple set M mul is responsible for verifying the authenticity of received messages, storing transaction sets that have not been recorded in the ledger (after consensus is reached, the transaction set will be recorded in the ledger of the node), storing messages that have been authenticated and format-verified, recovering information using error correction codes, and the like. All nodes n register identity information in MsM and are assigned serial numbers, wherein f is the number of Byzantine nodes; all nodes are managed by MsM, and all nodes register identity information such as node ID, node serial number, public key, etc. in MsM. Each node has its corresponding information multiple set , which is responsible for processing and verifying the information received in the current round.

[0081] Step 2: selecting a leader according to the current round number and system preset parameters, since a consortium chain system is used, the access nodes have been audited and qualified, so the leader can be selected through system preset parameters. The system sends a search request , wherein R is the current round number, is a system preset parameter set. Such a selection method can ensure that a suitable leader is selected at a faster speed and ensure the reliability of the leader. Therefore, the method for selecting a leader in this embodiment is:

[0082] ;

[0083] , wherein L is the selected leader node serial number, is a system preset parameter represented in decimal, and n is the current number of nodes in the system.

[0084] The system preset parameter will change during system operation, and the setting method is as follows:

[0085] ;​

[0086] wherein k is the current leader node sequence number, is a randomly generated hash value.

[0087] If the leader node is abnormal, a suitable leader node is selected according to the current round number and system preset parameters.

[0088] Step 3: After receiving the transaction request from the client, the leader initiates a three-phase consensus request, and after all nodes reach a consensus, the transaction consensus ends.

[0089] In combination Figure 2 , step 3 of the embodiment improves the consistency protocol in the original PBFT algorithm, including the proposal phase, the attempt consensus phase, and the randomization phase. The specific process is as follows:

[0090] The client sends a transaction request to the leader in the consortium chain. After receiving the transaction request, the leader starts the proposal phase:

[0091] Step P1: Divide the transaction set into n information blocks and send them to other nodes along with error correction codes;

[0092] Step P2: After receiving the information, the node broadcasts it to other nodes;

[0093] Step P3: After receiving the n information blocks, the node recovers them through multiple set verification. If the complete transaction set can be recovered, execute step P5; otherwise, execute step P4;

[0094] Step P4: The node deletes the current transaction set and sleeps until the randomization step is executed;

[0095] Step P5: Execute the attempt consensus phase;

[0096] Attempt consensus phase:

[0097] Step AC1: The node recovers the complete transaction set and approves the current received intersection set. Send the approval information to other nodes through the information multiple set , wherein T is the current transaction set, M is the information summary, L is the current round leader, t is the timestamp of the information, and i is the node number; if it is from the randomization phase to this phase, only the transaction set and the approval information need to be broadcast to other nodes.

[0098] Step AC2: After receiving n-f approval information from other nodes, execute step AC3; otherwise, execute step AC5;

[0099] Step AC3: Send to the leader;

[0100] Step AC4: After receiving n-f accept messages, the leader ends the consensus, and the transactions are packaged into a block The block is stored in the chain.

[0101] Step AC5: The node records the transaction set in the ledger, and the multiple sets delete the current transaction set, and performs step AC6;

[0102] Step AC6: Perform the randomization phase.

[0103] Randomization phase:

[0104] Step R1: The node performs different behaviors according to the value of the Coin function. If the value is 1, perform step R2; otherwise, perform step R3;

[0105] Step R2: The multiple sets of the node select the transaction set that has obtained the most agreement, and the node agrees with the transaction set;

[0106] Step R3: The multiple sets of the node approve the empty transaction set, and the node stops acting until it resumes at the next randomization phase;

[0107] Step R4: Perform the attempt consensus phase.

[0108] Step 4: After a certain number of three-phase consensus is completed, the configuration discovery protocol is executed. The execution of the configuration discovery protocol is related to the number of nodes in the current system, and the relationship between the number of consensus required by the configuration discovery protocol and the number of nodes is:

[0109] .

[0110] Step 5: After the system runs for a period of time, the checkpoint protocol is executed (save the current working state, clear the previous operation records, etc. Similar to the existing consensus method, not described again).

[0111] In an ideal case, consensus can be reached in two rounds. Considering the actual alliance chain network condition is partially synchronized, that is, only a part of the nodes can achieve synchronization. Therefore, in general, consensus needs 6 rounds (1 round + 2 rounds + 2 rounds + 1 round). Therefore, the upper limit of the number of rounds is set to 8, and if the number of rounds exceeds 8, the view switching protocol is started.

[0112] Based on the above consensus mechanism, if a node i wants to join the system, it needs to register identity information in MsM. MsM audits the information of the node, and after passing the audit, assigns a serial number to it, and notifies the leader that a new node has joined. The leader executes the JOIN protocol. The specific process of the JOIN protocol is as follows:

[0113] Step J1: Node i sends a join request message to the leader of the current round ;

[0114] Step J2: The leader of the current round receives the join request message sent by the new node, and does not immediately process the join request. After the consensus of the current round ends, the leader verifies whether the information of the new node is correct using the records in the MsM;

[0115] Step J3: After the leader verifies, the information of the new node joining is notified to all nodes;

[0116] Step J4: After the nodes receive the information of the new node joining, the nodes broadcast the confirmation message to other nodes after confirming receipt of the message;

[0117] Step J5: When the nodes receive the confirmation information sent by other n-f nodes, the nodes send the confirmation information to the leader;

[0118] Step J6: After the leader receives the confirmation information of n-f nodes, the leader executes the configuration update protocol;

[0119] Step J7: After the configuration update is completed, the new node formally joins the system and is allowed to participate in consensus.

[0120] Based on the above consensus mechanism, when a node wants to exit the alliance chain system, it needs to cancel the identity information in the MsM. The MsM audits the information of the node, and after passing the audit, the leader is notified that the node exits, and the node executes the QUIT protocol. The specific process of the QUIT protocol is as follows:

[0121] Step Q1: The node broadcasts the exit request information to all other nodes, but cannot immediately exit the system and needs to participate in completing the consensus of the current round;

[0122] Step Q2: After the node receives the exit request, the node confirms and sends the confirmation information to other nodes;

[0123] Step Q3: After the node receives the confirmation information of n-f nodes, the node sends the confirmation information to the leader;

[0124] Step Q4: After the leader receives the confirmation information sent by n-f nodes, the leader executes the configuration update protocol;

[0125] Step Q5: After the configuration update is completed, the node information is cancelled in the MsM, and the old node formally exits the system.

[0126] Based on the above consensus mechanism, when the number of system nodes in the alliance chain changes, such as node joining and node exiting, the configuration update protocol needs to be executed. The specific process of the configuration update protocol is as follows:

[0127] ​Step CU1: The leader updates the configuration information after the node relationship changes. Send to all nodes, including new nodes, where 'c' represents the current configuration. For the current membership relationship;

[0128] Step CU2: After receiving the new configuration, the node will... Broadcast to other nodes;

[0129] Step CU3: After receiving nf identical configurations, the node sends an acknowledgment message to the leader and updates its own configuration at the same time;

[0130] Step CU5: After receiving nf confirmation messages, the leader sends a verification message to MsM. Once MsM verifies the information, the new configuration is successfully deployed.

[0131] Based on the above consensus mechanism, the blockchain executes the configuration discovery protocol after several consensus iterations to ensure that the configurations of nodes within the blockchain remain consistent over the long term. The specific process of the configuration discovery protocol is as follows:

[0132] Step CD1: The leader broadcasts the DISCOVER command to all nodes. ;

[0133] Step CD2: After receiving the DISCOVER command, the node displays its current configuration status. Broadcast to other nodes;

[0134] Step CD3: The node compares the received configuration information. If a mismatch is found, and its own configuration is not up-to-date, it updates its own configuration. This can be determined by the version number in the configuration file, or by updating to the most frequently received identical configuration.

[0135] Based on the same inventive concept, an embodiment of the present invention discloses a computer system, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is loaded onto the processor, it implements the steps of the consortium blockchain consensus method based on the improved three-phase consensus.

[0136] Those skilled in the art will understand that the technical solution of this invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the method described in the embodiments of this invention. The storage medium includes various media capable of storing computer programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A consortium chain consensus method based on improved three-stage consensus, characterized in that, The method comprises the following steps: Step 1: Consortium chain initialization, including membership manager MsM and information multiset M of each node mul ; Step 2: selecting a leader according to the current round number and system preset parameters; If the leader is abnormal, selecting a suitable leader node according to the current round number and system preset parameters; Step 3: after the leader receives a transaction request from a client, initiating a three-stage consensus request, and after the consensus is completed, starting a new round of consensus; the three-stage consensus comprises a proposal stage, a consensus attempt stage and a randomization stage; after executing a stage, the round number is incremented by one; if a node fails to recover transaction set information in the proposal stage or fails to receive a sufficient number of approval information in the consensus attempt stage, entering the randomization stage, and randomly selecting a transaction set with the most approval in the multiple approval set or an empty transaction set; Step 4: a node wants to join or exit the system, changes the node information in the MsM, executes a JOIN operation or a QUIT operation, and executes a configuration update protocol; Step 5: after a set number of consensus is completed, executing a configuration discovery protocol; Step 6: after a set time is run, executing a checkpoint protocol; After the configuration update protocol, the configuration discovery protocol and the checkpoint protocol are executed, a new round of consensus is started.

2. The improved three-stage consensus-based consortium chain consensus method according to claim 1, characterized in that: The node membership manager in the step 1 is used for registering node information, modifying the membership relationship between nodes, unregistering node information, saving current configuration information, assigning node serial numbers and verifying node information; The multiple set of node information is used for verifying the authenticity of received messages, storing transaction sets that have not been recorded in the ledger, storing messages that have passed identity verification and format verification, and recovering information using error correction codes.

3. The improved three-stage consensus-based consortium chain consensus method according to claim 1, characterized in that: The system preset parameter in step 2 The system preset parameter in step 2 ； wherein k is the current leader node sequence number, is a randomly generated hash value.

4. The improved three-stage consensus-based consortium chain consensus method according to claim 1, characterized in that: The leader selection method in the step 2 is as follows: ； Wherein, L is the selected leader node number, R is the current round number, The system preset parameter is a decimal representation, and n is the current number of nodes of the system.

5. The improved three-stage consensus-based consortium chain consensus method according to claim 1, characterized in that: The steps of the three-stage consensus in the step 3 are as follows: Proposal stage: after the leader receives a transaction request from a client, proposing a set of transactions, and broadcasting the transaction set to all nodes, the detailed steps of this stage are as follows: Step P1: dividing the transaction set into multiple information blocks and sending them to other nodes together with error correction codes; Step P2: after a node receives the information, broadcasting it to other nodes; Step P3: after a node receives all the information blocks, if the complete transaction set can be recovered after multiple set verification and recovery, executing step P5; Otherwise, executing step P4; Step P4: the multiple set of the node deletes the current transaction set and sleeps until the randomization stage is executed; Step P5: executing the consensus attempt stage; Consensus attempt stage: all trusted nodes broadcast the received transaction set, approve and finally confirm the information according to the received approval information, and the detailed steps of this stage are as follows: Step AC1: after the multiple set of a node recovers the transaction set from the proposal, the node approves the transaction set and broadcasts the transaction set and the approval message to other nodes through the multiple set; If it is from the randomization stage to this stage, only the approved transaction set and the approval information need to be broadcast to other nodes; Step AC2: when the node receives approval information of the transaction set greater than n-f, executing step AC3; Otherwise, executing step AC5; n is the current number of nodes in the system, and f is the number of Byzantine nodes; Step AC3: the node sends a confirmation to the leader; Step AC4: after the leader receives more than n-f confirmation information, the consensus is completed; Otherwise, perform step AC6; if the agreed transaction set in the received confirmation information is not proposed by the leader, the leader also changes the transaction set to complete the consensus; Step AC5: the node records the transaction set in the ledger, and the multiple set deletes the current transaction set, and performs step AC6; Step AC6: perform the randomization phase; Randomization phase: processing the nodes that failed to reach agreement in the attempt consensus phase, the detailed steps of this phase are: Step R1: the node performs different behaviors according to the Coin function, if the value is 1, perform step R2; otherwise, perform step R3; Step R2: the multiple set of the node selects the transaction set with the most agreement, and the node agrees to the transaction set; Step R3: the multiple set of the node agrees to the empty transaction set, and the node stops until it resumes in the next randomization phase; Step R4: perform the attempt consensus phase.

6. The improved three-stage consensus-based consortium chain consensus method according to claim 1, characterized in that: In the three-phase consensus process, the round number is increased by one after each consensus phase is completed, and the round number is recalculated after the leader node is replaced; when the round numbers of multiple nodes are inconsistent, the leader will take the longest round number in the nodes as the round number of this round of consensus after completing the consensus; when the round number exceeds the upper limit of 8, the view switching protocol is executed.

7. The improved three-stage consensus-based consortium chain consensus method according to claim 1, characterized in that: The specific process of the configuration discovery protocol in step 5 is as follows: Step CD1: the leader broadcasts a DISCOVER command to all nodes; Step CD2: after all nodes receive the DISCOVER command, they broadcast their current configuration status to other nodes; Step CD3: the multiple set of the node compares the received configuration status, and if the configuration status is not the latest, the node updates its configuration after discovering the mismatch. 8.The improved three-stage consensus-based consortium chain consensus method according to claim 1, characterized in that: The joining and exiting of the nodes in step 4 need to send a join request message or an exit request message to the current leader and MsM, and the leader needs to verify the request to MsM after receiving the message, and the node successfully joins or exits the alliance chain system after the verification is passed, and the node sequence number in MsM is updated; the JOIN operation and QUIT operation of the node need to be performed after the consensus is completed, and cannot be performed during the consensus process. 9.The improved three-stage consensus-based consortium chain consensus method according to claim 1, characterized in that: The specific process of the configuration update protocol in step 4 is as follows: Step CU1: the leader sends a configuration update request to MsM, and MsM audits uniformly; Step CU2: the leader sends the configuration after the relationship of the node is changed to all nodes, including new nodes; Step CU3: after the node receives the new configuration, the node broadcasts the new configuration to other nodes; Step CU4: after the node receives n-f same configuration information, the node sends a confirmation information to the leader, and updates its configuration; n is the current number of nodes in the system, and f is the number of Byzantine nodes; Step CU5: after the leader receives n-f confirmation information, the leader sends the current configuration to MsM, and the configuration update is completed; otherwise, perform step CU2.

10. A computer system comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The computer program is loaded into the processor to implement the steps of the alliance chain consensus method based on the improved three-phase consensus according to any one of claims 1-9.

Images