Improved alliance blockchain consensus method based on PBFT

Abstract

The present invention discloses a consensus method of alliance blockchain based on PBFT improvement, specifically: before consensus is reached, nodes have a unified initial throughput index, the initial consensus node is generated by a configuration file, and whether there is a node change is checked and the total number of nodes is changed; the master node sends a legal request signature to all nodes, and executes the improved PBFT consensus. If the master node is detected to be a malicious node, the consensus is temporarily interrupted, and then it is checked whether a view change is required. If an attempt is made to change, the ViewChange process is executed to update the view round; if the master node is not detected to be abnormal, the node generates a reply message and sends it to the client, and the client completes the consensus after receiving f+1 reply messages. The method of the present invention can improve the efficiency of consensus, realize the dynamic addition and exit of nodes when the cluster is not shut down, eliminate malicious nodes, ensure the security of the blockchain and reduce communication overhead.

Description

Technical Field

[0001] The present invention belongs to the technical field of blockchain, and in particular relates to an improved alliance blockchain consensus method based on PBFT. Background Art

[0002] Blocks are the basic data storage units, and each blockchain is composed of several blocks. Blocks contain block headers and block bodies. The header contains the hash value, timestamp, random number, Merkle root (a hash binary tree, the root of the tree is the Merkle root) of the previous block, and the block body mainly contains a large amount of ordered transaction information. Cryptography, distributed storage, P2P, consensus algorithm and other related technologies are used to generate a block. Among them, the consensus algorithm is one of the core technologies of blockchain technology.

[0003] The blockchain network is a multi-node distributed network. How to reach a consensus on the transaction order among multiple nodes is solved by the consensus algorithm. Existing consensus algorithms that have been put into practical use, such as the proof of work (PoW) consensus mechanism used by Bitcoin, have defects such as excessive resource consumption, high transaction latency, and low throughput; Proof of Stack (PoS) also has the above shortcomings; the fabric blockchain uses the Raft consensus protocol, which cannot resist Byzantine attacks (nodes are attacked by the network and become malicious nodes). Therefore, it is necessary to improve the existing consensus algorithm to increase throughput, reduce latency and resource consumption while ensuring security.

[0004] The PBFT (Practical Byzantine Fault Tolerance) algorithm can take into account both practicality and security, supports Byzantine fault tolerance (malicious nodes will send inconsistent information to each node in order to obstruct the transmission of real information and the achievement of effective consensus) and can be applied to various application scenarios. Therefore, the PBFT algorithm has been widely used in consortium chains. However, the PBFT protocol still has many defects, mainly in three aspects: First, when the number of nodes in the network increases, the communication overhead is large, and the time complexity of the entire consensus process is O(N 2 )(N is the total number of nodes in the network), especially when switching views (the process of replacing the master node when the master node is down), the time complexity is O(N 3 ); second, the number of nodes in the network is fixed, and the increase or decrease of nodes requires the initialization of the consensus network; third, there is no punishment mechanism for malicious nodes. Summary of the invention

[0005] The purpose of the present invention is to provide an improved alliance blockchain consensus method based on PBFT, to achieve dynamic addition and exit of nodes and remove malicious nodes, and to improve consensus efficiency.

[0006] The technical solution adopted by the present invention is a consortium blockchain consensus method improved based on PBFT, which is specifically implemented in the following steps:

[0007] Step 1: Before the first consensus, all nodes have a unified initial throughput indicator. The initial consensus node is generated by the configuration file. Check whether there is a node change. If there is a change, go to step 2, otherwise go to step 3.

[0008] Step 2: If a new node joins the consensus cluster, start the AddNode process to accept the new node and change the total number of nodes N; if a node wants to leave the consensus cluster, start the DeleteNode process to delete the node to be left from the cluster and change the total number of nodes N;

[0009] Step 3: The master node checks whether the request received from the client is legal. If it is legal, it jumps to step 4. If it is not legal, it replies to the client and ends.

[0010] Step 4: The master node signs the legal request and sends it to all nodes in the consensus cluster to start executing the improved PBFT consensus. During the entire consensus execution process, if the master node is detected to be a malicious node, the consensus is temporarily interrupted and jumps to step 5. If no master node abnormality is detected, go to step 6.

[0011] Step 5, check whether the view needs to be changed. If it is necessary to try to change it, execute the ViewChange process to update the view round. After completion, jump to step 4, otherwise jump to step 6;

[0012] Step 6, Reply phase; the node generates a reply message and sends it to the client. The client completes the consensus after receiving f+1 reply messages.

[0013] The present invention is also characterized in that:

[0014] In step 2, specifically:

[0015] Step 2.1: The new node needs to obtain a certificate issued by a certificate authority, and then send an AddNode request message to all nodes in the cluster, including the new node ID, node number, message type, and new node signature;

[0016] Step 2.2: After each node confirms its agreement, it will broadcast the agreement to other nodes in the cluster. When a node receives 2f+1 AgreeAdd replies, it will establish a connection with the new node, where f is the number of malicious nodes that can be accommodated.

[0017] Step 2.3: After the new node establishes a connection with Nf nodes, the active recovery algorithm recovery can be executed to synchronize the latest status of the blockchain alliance members; N is the total number of consensus cluster nodes;

[0018] Step 2.4: After the new node completes the state synchronization, each node will broadcast AggreeUpdate to other nodes in the cluster. After all nodes verify Update, the total number of nodes N is updated, and the new node joins the consensus process.

[0019] Step 2.5: The master node sends a DeleteNode request to all nodes in the cluster, including the node ID, node number, message type, and signature of the exiting node.

[0020] Step 2.6: After confirmation, each node will broadcast to other nodes in the cluster. When a node receives 2f+1 AgreeDel replies, it will disconnect from the new node.

[0021] In step 2.7, each node will broadcast AggreeUpdate to other nodes in the cluster. After that, all nodes will verify Update and complete the update of the total number of nodes N.

[0022] In step 3, the request includes: O--operation type, operation; T--timestamp, timestamp; C--client tag, client; δ c —Client signature; the way to determine whether it is legal is to check whether the client signature is correct.

[0023] In step 4, the details are as follows:

[0024] Step 4.1, Pre-prepare phase; the master node generates a pre-prepare message and broadcasts it to each replica node;

[0025] The pre-prepare message includes: pre-prepare--message type, v--view number, d--request message summary, that is, a fixed-length string obtained by hashing the request, n--request message number, which is assigned when the master node generates the pre-prepare message, δ i --The master node signs the pre-prepare message, where i is the node id;

[0026] Step 4.2, enter the Prepare phase, the replica node receives the pre-prepare message broadcast by the master node; the pre-prepare message is verified;

[0027] Specifically include: verifying the signature of the pre-prepare messageδ i Is it correct? Has a request with sequence number n and different digest d been received? If the check fails, go to step 5. If the check passes, the replica node writes the pre-prepare message to the local message log, and then generates a prepare message and broadcasts it to other nodes in the cluster. After receiving the prepare message sent by other nodes, it checks whether d in the prepare message is the same as d in the pre-prepare message, and whether the signature in the prepare message is correct. If the check fails, it proves that the master node is a malicious node, and the consensus is temporarily interrupted, and go to step 5. If the check passes, go to step 4.3.

[0028] Step 4.3, Commit phase; after the replica node receives 2f+1 verified prepare messages, f=n / 3, n is the total number of nodes, it generates a confirmation message commit, and uses the random matching algorithm, that is, each node signs the commit message it generates and randomly sends it to another node for verification. Each node can only send one commit message and can only receive one commit message from another node;

[0029] Verification content: whether d in the commit message is the same as d in the pre-prepare message, and whether the signature in the commit message is correct; if the commit message is verified successfully, proceed to step 6; if the verification fails, the commit message received by itself is broadcast to other nodes for secondary verification. After the secondary verification is completed, proceed to step 6.

[0030] In step 4.3, the random function used in the random process is as follows:

[0031] p=(View⊕hash⊕Id)modN

[0032] Among them, the node ID, the total number of nodes N, the current view View (round), the client message request summary Hash, and the ⊕ symbol represents the operation method; since the Hash of each transaction is different, the validator of the commit message in each round of consensus is also different, so as to avoid the situation where two malicious nodes collude;

[0033] Let N be the total number of nodes and f be the number of malicious nodes. According to the PBFT protocol requirement, N ≥ 3f + 1, the probability P of two malicious nodes in the cluster colluding with each other is:

[0034]

[0035] And f ≥ 0, so P ≤ 0.79%, so the design can prevent two malicious nodes from colluding with a probability higher than 99.21%.

[0036] In step 4.3, the secondary verification process is as follows: the first node receives the commit message from another node for verification. If the verification fails, the first node broadcasts the commit message sent by the other node to other nodes for secondary verification; if the secondary verification of other nodes passes, it means that the first node is a malicious node, and the first node is recorded as a malicious node. If it fails, it means that the commit message of the other node is a malicious node, and the other node is recorded as a malicious node; after identifying the malicious node, the DeleteNode process is started to delete the malicious node before the next round of verification begins; until all nodes are verified, then go to step 6.

[0037] In step 5, specifically:

[0038] Step 5.1: After the replica node detects the above abnormal situation of the master node or receives ViewChange messages from other f+1 nodes, it will broadcast the ViewChange message to the entire network;

[0039] Step 5.2: When the new master node receives 2f+1 ViewChange messages, it sends a NewView message;

[0040] Step 5.3: After receiving the NewView message, the replica node verifies the message and then broadcasts the VCReset of each node to continue the unfinished transaction before the switch attempt. The ViewChange is officially changed, thus completing the entire ViewChange process and jumping to step 4.

[0041] In step 6, the reply message content includes: reply--message type, v--view number, d--request message digest, that is, a fixed-length string obtained by hashing the request, n--request message number, which is assigned when the master node generates the pre-prepare message, δ i --The node's signature on the reply message, i is the node id.

[0042] The beneficial effects of the present invention are:

[0043] (1) Adding the AddNode process and the DeleteNode process can dynamically add and delete nodes in the consensus cluster, improving the defect of the original PBFT protocol that the number of nodes initialized is fixed;

[0044] (2) In the commit phase of the PBFT protocol, a random matching verification method is designed to replace the original PBFT protocol's full-network broadcast verification mechanism of all nodes, reducing communication complexity;

[0045] (3) A deletion mechanism is added for malicious nodes and the throughput of the master node is monitored to ensure the efficiency of reaching consensus overall;

[0046] (4) The probability of Byzantine failures caused by replica nodes in the network is reduced, thereby improving the security performance of the consensus network;

[0047] (5) Punish inaction or malicious master nodes to improve the security of the network and increase the efficiency of blockchain production;

[0048] (6) The improved PBFT method can reduce the energy consumption of the alliance blockchain and can cope with the Byzantine problem. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] Figure 1 It is a flow chart of the improved alliance blockchain consensus method based on PBFT of the present invention;

[0050] Figure 2 It is a flow chart of PBFT consensus in the alliance blockchain consensus method improved based on PBFT in the present invention;

[0051] Figure 3 It is a flow chart of AddNode in the improved alliance blockchain consensus method based on PBFT of the present invention;

[0052] Figure 4 It is a flow chart of DeleteNode in the alliance blockchain consensus method improved based on PBFT of the present invention;

[0053] Figure 5 It is a schematic diagram of random matching results in the alliance blockchain consensus method improved based on PBFT of the present invention;

[0054] Figure 6 It is a view switching flow chart in the improved alliance blockchain consensus method based on PBFT of the present invention;

[0055] Figure 7 It is a bar chart comparing fabric transaction throughput before and after in the method of the present invention. DETAILED DESCRIPTION

[0056] The present invention is described in detail below with reference to the accompanying drawings and specific embodiments.

[0057] The present invention is based on the improved alliance blockchain consensus method of PBFT, such as Figure 1 As shown, the specific implementation steps are as follows:

[0058] Step 1: Before the first consensus, all nodes have a unified initial throughput index. The initial consensus node is generated by the configuration file, and the master node is generated according to the formula P = VmodN, where V is the view round and N is the total number of nodes in the consensus cluster. Check whether there is a node change (node ​​joining / exiting). If there is a change, go to step 2, otherwise go to step 3;

[0059] Step 2: If a new node joins the consensus cluster, start the AddNode process to accept the new node and change the total number of nodes N; if a node wants to exit the consensus cluster, start the DeleteNode process to delete the node to be exited from the cluster and change the total number of nodes N; specifically:

[0060] Step 2.1, such as Figure 3 As shown, first, the new node needs to obtain a certificate issued by a certificate authority, and then send an AddNode request message to all nodes in the cluster, including the new node ID, node number, message type, and new node signature;

[0061] Step 2.2: After each node confirms its agreement, it will broadcast the agreement to other nodes in the cluster. When a node receives 2f+1 (f is the number of malicious nodes that can be accommodated) AgreeAdd replies, it will establish a connection with the new node.

[0062] Step 2.3: After the new node establishes a connection with Nf (N is the total number of consensus cluster nodes) nodes, the active recovery algorithm recovery can be executed to synchronize the latest status of the blockchain alliance members;

[0063] Step 2.4: After the new node completes the state synchronization, each node will broadcast AggreeUpdate to other nodes in the cluster. After all nodes verify Update, the total number of nodes N is updated, and the new node joins the consensus process.

[0064] Step 2.5, such as Figure 4 As shown, the master node sends a DeleteNode request to all nodes in the cluster, including the node ID, node number, message type, and signature of the exiting node;

[0065] Step 2.6: After confirmation, each node will broadcast to other nodes in the cluster. When a node receives 2f+1 AgreeDel replies, it will disconnect from the new node.

[0066] Step 2.7, each node will then broadcast AggreeUpdate to other nodes in the cluster, and then all nodes will verify Update to complete the update of the total number of nodes N;

[0067] Step 3: The master node checks whether the transaction information (request) received from the client is legal. If it is legal, it jumps to step 4. If it is not legal, it replies to the client and ends.

[0068] Transaction information (request) includes: O (operation type, operation), T (timestamp, timestamp), C (client tag, client), δ c (Client signature); The way to determine whether it is legal is to check whether the client signature is correct;

[0069] Step 4: The master node signs the legal transaction information and sends it to all nodes in the consensus cluster to start executing the improved PBFT consensus. During the entire consensus execution process, if the master node is detected to be a malicious node, the consensus is temporarily interrupted and jumps to step 5. If no master node abnormality is detected, go to step 6.

[0070] like Figure 2 As shown, the details are as follows:

[0071] Step 4.1, Pre-prepare phase; the master node generates a pre-prepare message and broadcasts it to each replica node;

[0072] The pre-prepare message includes: pre-prepare (message type), v (view number), d (request message digest, i.e., a fixed-length string obtained by performing a hash operation on the request), n (request message number, which is assigned when the master node generates the pre-prepare message), δ i (The master node's signature on the pre-prepare message, i is the node id);

[0073] Step 4.2, enter the Prepare phase, the replica node receives the pre-prepare message broadcast by the master node; the pre-prepare message is verified;

[0074] Specifically includes verifying the signature of the pre-prepare message (δ i) is correct, whether a transaction message (request) with sequence number n and different digest (d) has been received. If the check fails, go to step 5; if the check passes, the replica node writes the pre-prepare message to the local message log, and then the replica node generates a prepare message and broadcasts it to other nodes in the cluster. The prepare message content includes: prepare (message type), v (view number), d (request message digest, that is, a fixed-length string obtained by hashing the request), n (request message number, assigned when the master node generates the pre-prepare message), δ i (The node's signature on the prepare message, i is the node id). After receiving the prepare message sent by other nodes, check whether d in the prepare message is the same as d in the pre-prepare message, and whether the signature in the prepare message is correct. If the check fails, it proves that the master node is a malicious node, the consensus is temporarily interrupted, and go to step 5. If the check passes, go to step 4.3;

[0075] Step 4.3, Commit phase; after receiving 2f+1 (f=n / 3, n is the total number of nodes) verified prepare messages, the replica node generates a confirmation message commit, and according to the random matching algorithm, randomly sends the commit message to a node in the cluster for verification, and verifies the received commit message at the same time;

[0076] The content of the commit message includes: commit (message type), v (view number), d (request message digest, that is, a fixed-length string obtained by performing a hash operation on the request), n (request message number, which is assigned when the master node generates a pre-prepare message), δ i (The node’s signature on the commit message, i is the node id).

[0077] Each node signs the commit message it generates and randomly sends it to another node for verification. Each node can only send one commit message and can only receive one commit message from another node.

[0078] The random functions used in the random process are as follows:

[0079] p=(View⊕hash⊕Id)modN

[0080] Among them, the node ID, the total number of nodes N, the current view View (round), the client message request summary Hash (hash value), and the ⊕ symbol represent a calculation method, which can be + or a more complex calculation method. Since the Hash of each transaction is different, the validator of the commit message in each round of consensus is also different, thus avoiding the situation where two malicious nodes collude.

[0081] Let N be the total number of nodes and f be the number of malicious nodes. According to the PBFT protocol requirement, N ≥ 3f + 1, the probability P of two malicious nodes in the cluster colluding with each other is:

[0082]

[0083] And f ≥ 0, so P ≤ 0.79%, so the design can prevent two malicious nodes from colluding with a probability higher than 99.21%;

[0084] like Figure 5 As shown in the figure, node 1 sends the commit message to node 2 for verification (this process is random), and node 2 sends the commit message to another node for verification. Finally, all nodes form a message ring. It is forbidden for a node to send a commit message to itself for verification;

[0085] Verification content: whether d in the commit message is the same as d in the pre-prepare message, and whether the signature in the commit message is correct; if the commit message is verified, it will proceed to step 6 (Reply phase); if the verification fails, the commit message received by itself will be broadcast to other nodes for secondary verification;

[0086] The secondary verification process is as follows: the first node receives the commit message from another node for verification. If the verification fails, the first node broadcasts the commit message from the other node to other nodes for secondary verification. If the secondary verification of other nodes passes, it means that the first node is a malicious node, and the first node is recorded as a malicious node. If it fails, it means that the commit message of the other node is a malicious node, and the other node is recorded as a malicious node. After the malicious node is identified, the DeleteNode process is started to delete the malicious node before the next round of verification begins. After all nodes are verified, go to step 6.

[0087] Step 5: Check whether view changes are required, such as Figure 6 As shown, if an attempt to change is required, the ViewChange process is executed to update the view round, a secondary consensus is performed, and the process jumps to step 4. Otherwise, the process jumps to step 6.

[0088] Step 5.1: After the replica node detects the above abnormal situation of the master node or receives ViewChange messages from other f+1 nodes, it will broadcast the ViewChange message to the entire network;

[0089] Step 5.2: When the new master node receives 2f+1 ViewChange messages, it sends a NewView message;

[0090] Step 5.3, after receiving the NewView message, the replica node verifies the message, and then broadcasts the VCReset (transaction read-write set) of each node, and continues the unfinished transaction before the switch attempt. The ViewChange is officially changed, thus completing the entire ViewChange process and jumping to step 4;

[0091] Step 6, Reply phase. The node generates a reply message and sends it to the client. The reply message content includes: reply (message type), v (view number), d (request message digest, i.e., a fixed-length string obtained by performing a hash operation on the request), n (request message number, which is assigned when the master node generates a pre-prepare message), δ i (The node’s signature on the reply message, i is the node id). The client reaches consensus after receiving f+1 reply messages.

[0092] Assume the number of consensus nodes is n. The original PBFT protocol has two consensus cluster node broadcasts in the Prepare phase and Commit phase, and its time complexity is specifically expressed as O 1 =2n 2 +2n; the method of the present invention has only one consensus cluster node broadcast in the Prepare stage, and its time complexity is specifically expressed as O 2 =n 2 +3n; theoretically, the efficiency is improved by 30% to 50% compared with the original PBFT protocol.

[0093] Experimental analysis: Taking the fabric alliance blockchain as the research object, the consensus algorithm in the fabric was replaced by the original PBFT algorithm and the improved PBFT algorithm respectively. Under the same experimental conditions, the caliper blockchain testing tool was used to perform performance tests, such as Figure 7 As shown in the figure, the experimental results show that the average transaction throughput of fabric is improved by more than 33%.

[0094] The improved alliance blockchain consensus method based on PBFT of the present invention dynamically adjusts the node level according to the mean value of the throughput of all nodes, recovers downtime nodes, removes malicious nodes, and dynamically adds and deletes nodes; a random matching method is proposed for verification to ensure security while reducing network communication overhead.

Claims

1. The improved alliance blockchain consensus method based on PBFT is characterized by: Follow the steps below to implement it: Step 1: Before the first consensus, all nodes have a unified initial throughput indicator. The initial consensus node is generated by the configuration file. Check whether there is a node change. If there is a change, go to step 2, otherwise go to step 3. Step 2: If a new node joins the consensus cluster, start the AddNode process to accept the new node and change the total number of nodes N; if a node wants to leave the consensus cluster, start the DeleteNode process to delete the node to be left from the cluster and change the total number of nodes N; Step 3: The master node checks whether the request received from the client is legal. If it is legal, it jumps to step 4. If it is not legal, it replies to the client and ends. In step 4, the master node signs the legal request and sends it to all nodes in the consensus cluster to start executing the improved PBFT consensus. During the entire consensus execution process, if the master node is detected to be a malicious node, the consensus is temporarily interrupted and jumps to step 5. If no master node abnormality is detected, go to step 6; the details are as follows: Step 4.1, Pre-prepare phase; the master node generates a pre-prepare message and broadcasts it to each replica node; The pre-prepare message includes: pre-prepare--message type, v--view number, d--request message summary, that is, a fixed-length string obtained by hashing the request, n--request message number, which is assigned when the master node generates the pre-prepare message, --The master node signs the pre-prepare message, where i is the node id; Step 4.2, enter the Prepare phase, the replica node receives the pre-prepare message broadcast by the master node; the pre-prepare message is verified; Specifically include: verifying the signature of the pre-prepare message Is it correct? Has a request with sequence number n and different digest d been received? If the check fails, go to step 5. If the check passes, the replica node writes the pre-prepare message to the local message log, and then generates a prepare message and broadcasts it to other nodes in the cluster. After receiving the prepare message sent by other nodes, it checks whether d in the prepare message is the same as d in the pre-prepare message, and whether the signature in the prepare message is correct. If the check fails, it proves that the master node is a malicious node, and the consensus is temporarily interrupted, and go to step 5. If the check passes, go to step 4.

3. Step 4.3, Commit phase; after the replica node receives 2f+1 verified prepare messages, f=n / 3, n is the total number of nodes, it generates a confirmation message commit. According to the random matching algorithm, each node signs the commit message it generates and randomly sends it to another node for verification. Each node can only send one commit message and can only receive one commit message from another node. Verification content: whether d in the commit message is the same as d in the pre-prepare message, and whether the signature in the commit message is correct; if the commit message is verified, go to step 6; if the verification fails, broadcast the commit message received by itself to other nodes for secondary verification. After the secondary verification is completed, go to step 6; Step 5, check whether the view needs to be changed. If it is necessary to try to change it, execute the ViewChange process to update the view round. After completion, jump to step 4, otherwise jump to step 6; Step 6, Reply phase; the node generates a reply message and sends it to the client. The client completes the consensus after receiving f+1 reply messages.

2. The improved alliance blockchain consensus method based on PBFT according to claim 1 is characterized in that: In the step 2, specifically: Step 2.1: The new node needs to obtain a certificate issued by a certificate authority, and then send an AddNode request message to all nodes in the cluster, including the new node ID, node number, message type, and new node signature; Step 2.2: After each node confirms its agreement, it will broadcast the agreement to other nodes in the cluster. When a node receives 2f+1 AgreeAdd replies, it will establish a connection with the new node, where f is the number of malicious nodes that can be accommodated. Step 2.3: After the new node establishes a connection with Nf nodes, the active recovery algorithm recovery can be executed to synchronize the latest status of the blockchain alliance members; N is the total number of consensus cluster nodes; Step 2.4: After the new node completes the state synchronization, each node will broadcast AggreeUpdate to other nodes in the cluster. After all nodes verify Update, the total number of nodes N is updated, and the new node joins the consensus process. Step 2.5: The master node sends a DeleteNode request to all nodes in the cluster, including the node ID, node number, message type, and signature of the exiting node. Step 2.6: After confirmation, each node will broadcast to other nodes in the cluster. When a node receives 2f+1 AgreeDel replies, it will disconnect from the new node. In step 2.7, each node will broadcast AggreeUpdate to other nodes in the cluster. After that, all nodes will verify Update and complete the update of the total number of nodes N.

3. The improved alliance blockchain consensus method based on PBFT according to claim 1 is characterized in that: In step 3, request includes: O--operation type, operation; T--timestamp, timestamp; C--client tag, client; —Client signature; the way to determine whether it is legal is to check whether the client signature is correct.

4. The improved PBFT-based alliance blockchain consensus method according to claim 1 is characterized in that: In step 4.3, the random function used in the random process is as follows: Among them, the node ID, the total number of nodes N, the current view View, the client message request summary Hash, and the ⊕ symbol represents the operation method; since the Hash of each transaction is different, the validator of the commit message in each round of consensus is also different, so as to avoid the situation where two malicious nodes collude; Let N be the total number of nodes and f be the number of malicious nodes. According to the PBFT protocol requirement, N ≥ 3f + 1, the probability P of two malicious nodes in the cluster colluding with each other is: again , so , so the design can prevent two malicious nodes from colluding with a probability higher than 99.21%.

5. The improved PBFT-based alliance blockchain consensus method according to claim 1 is characterized in that: In step 4.3, the secondary verification process is as follows: the first node receives a commit message from another node for verification. If the verification fails, the first node broadcasts the commit message sent by the other node to other nodes for secondary verification. If the secondary verification of other nodes passes, it means that the first node is a malicious node, and the first node is recorded as a malicious node. If the verification fails, it means that the commit message of the other node is a malicious node, and the other node is recorded as a malicious node. After identifying the malicious node, start the DeleteNode process to delete the malicious node before the next round of verification begins; until all nodes are verified, proceed to step 6.

6. The improved PBFT-based alliance blockchain consensus method according to claim 1 is characterized in that: In the step 5, specifically: Step 5.1: After the replica node detects the above abnormal situation of the master node or receives ViewChange messages from other f+1 nodes, it will broadcast the ViewChange message to the entire network; Step 5.2: When the new master node receives 2f+1 ViewChange messages, it sends a NewView message; Step 5.3, after receiving the NewView message, the replica node verifies the message, and then broadcasts the VCReset of each node, continues the unfinished transaction before the switch attempt, formally changes the ViewChange, thereby completing the entire ViewChange process and jumping to step 4.

7. The improved PBFT-based alliance blockchain consensus method according to claim 1 is characterized in that: In step 6, the reply message content includes: reply--message type, v--view number, d--request message digest, that is, a fixed-length string obtained by performing a hash operation on the request, n--request message number, which is assigned when the master node generates a pre-prepare message, --The node's signature on the reply message, i is the node id.

Images