A method for byzantine fault tolerance consensus of double master nodes based on a reputation evaluation model

Abstract

This invention relates to the field of blockchain consensus and discloses a dual-master node Byzantine Fault-Tolerant Consensus method based on a reputation evaluation model. This method aims to solve the problems of centralized power among master nodes and privacy leaks in communication in the traditional PBFT algorithm. The technical solution includes establishing a multi-dimensional reputation evaluation model and dynamically electing master nodes P1 and P2 based on node reputation. Master node P1 is responsible for generating and broadcasting pre-prepared messages, while master node P2 is responsible for receiving replica votes and performing threshold judgments, achieving mutual checks and balances through a power separation mechanism. A linkable ring signature technology is introduced into the consensus interaction; replica nodes generate key mirrors and vote anonymously, and the verification master node deduplicates votes based on the key mirror set to prevent duplicate voting. This method effectively improves the security and privacy protection capabilities of the consensus system, reduces centralization risks, and is suitable for consortium blockchains and distributed systems with high security requirements.

Description

[0001] This invention relates to the field of blockchain consensus algorithm performance optimization technology, and in particular to a dual-master node Byzantine fault-tolerant consensus method based on a reputation evaluation model. Background Technology

[0002] Blockchain is a distributed ledger technology that replicates and shares data across all nodes in a decentralized manner, ensuring data transparency, security, and immutability. Since blockchain systems typically operate in open or semi-open network environments, node failures, network latency, or malicious attacks are possible. Therefore, a consensus mechanism capable of tolerating Byzantine Fault Tolerance (BFT) is required. BFT consensus algorithms can guarantee system consistency even when some nodes exhibit malicious behavior or failures, and are widely used in consortium blockchains and permissioned blockchain systems. Practical Byzantine Fault Tolerance (PBFT) is one of the most representative BFT consensus algorithms. PBFT uses a five-phase message exchange to enable consensus among nodes in the network even with a maximum of f Byzantine nodes. Theoretically, PBFT can guarantee system security and consistency, and is therefore widely used in consortium blockchain systems. However, traditional PBFT consensus mechanisms still have many shortcomings in practical applications.

[0003] The PBFT algorithm employs a single master node structure, where the master node is responsible for sorting all transaction requests and initiating the consensus process. As the system scales or transaction requests increase, the master node can easily become a performance bottleneck. If the master node is attacked or malfunctions, it will cause frequent view switching, increasing communication overhead and reducing system throughput. Therefore, reducing the load on the master node and improving system robustness are crucial factors for PBFT improvement. Furthermore, traditional PBFT algorithms do not consider node history and reputation information when nodes participate in consensus. In real-world network environments, the reliability of different nodes varies; some nodes may exhibit malicious behavior, delayed responses, or frequent erroneous commits. However, traditional PBFT protocols assume all nodes have the same trustworthiness, which may lead to low-reputation nodes still participating in critical consensus steps, impacting overall system efficiency and security. In traditional PBFT protocols, messages sent by nodes during the Prepare and Commit phases typically contain node identity information, making node voting behavior directly identifiable. In some application scenarios, node identity information may involve sensitive data, and publicly revealing voting identities may pose privacy risks. Malicious nodes may also launch targeted attacks on the master node or critical nodes by analyzing message sources. Therefore, introducing an anonymous authentication mechanism into the consensus process, which hides the true identity of nodes while ensuring the legitimacy of messages, has significant research value.

[0004] To address the aforementioned issues, researchers have proposed several improved PBFT consensus schemes in recent years. These schemes distribute the load on the master node by improving the rotating master node mechanism, introduce a reputation evaluation model to score node behavior and thus select more reliable nodes to participate in the consensus, and achieve anonymous node authentication through linkable ring signatures, allowing nodes to participate in voting without revealing their true identities. While these methods have improved the performance and security of the traditional PBFT algorithm to some extent, existing technologies still have some shortcomings. For example, some improved schemes only optimize the master node election mechanism without simultaneously considering node reputation evaluation; some schemes, while introducing anonymous signature mechanisms, fail to effectively integrate them with the voting deduplication mechanism in the consensus process; furthermore, most existing research still uses a single master node structure, which cannot adequately alleviate the master node load problem.

[0005] In conclusion, designing a dual-master node Byzantine fault-tolerant consensus method based on a reputation evaluation model remains a critical issue that urgently needs to be addressed in the field of consensus mechanism technology. Summary of the Invention

[0006] The purpose of this invention is to propose a dual-master node Byzantine fault-tolerant consensus method based on a reputation evaluation model. This method quantifies the historical behavior of nodes by constructing a node reputation evaluation model, and combines this with a verifiable random function to elect dual master nodes. Furthermore, a linkable ring signature mechanism is introduced during the consensus process to anonymize node identities and deduplicate votes, thereby improving the system's security, reliability, and consensus efficiency.

[0007] The method includes the following steps:

[0008] S1: Construct a multi-dimensional dynamic reputation evaluation model, calculate the comprehensive score of nodes, and classify candidate nodes, ordinary nodes, and abnormal nodes according to the comprehensive score;

[0009] S2: Elect master nodes P1 and P2 based on comprehensive scoring; P1 is responsible for generating and broadcasting Pre-prepare messages, and P2 is responsible for vote collection, deduplication, and threshold determination; a linkable ring signature is introduced in the consensus process, and replica nodes generate ring signature votes with link tags for Check messages; P2 identifies and deduplicates duplicate votes from the same node, and broadcasts a Commit message to complete consensus after the number of valid unique votes reaches the threshold; within the consensus view, the system can still reach consensus even if at most one of the two master nodes P1 and P2 is a Byzantine fault node; when both P1 and P2 are faulty, the current view is terminated and two master nodes are re-elected.

[0010] S3: After consensus is reached, the comprehensive score is updated based on node behavior, and the candidate node set is reconstructed based on the update results for the next round of master node election.

[0011] Furthermore, in S1, the multi-dimensional dynamic reputation evaluation model is constructed based on the node's historical transaction records and average latency to obtain four indicators: malicious behavior, lazy behavior, transaction accuracy, and response time. Malicious behavior refers to malicious operations such as nodes tampering with transaction data or failing to send messages within timeout periods. Lazy behavior refers to the network latency or intentional delays that occur during the consensus process. Transaction accuracy refers to the proportion of correctly verified transactions by a node. Response time refers to the average latency between a node receiving a network request and returning a valid response. The comprehensive score of each node is calculated using entropy values. ;

[0012] Comprehensive score for each node The nodes are sorted and divided into three levels—candidate nodes, normal nodes, and malicious nodes—based on preset thresholds; the first level is candidate nodes, where a node... Overall rating Exceeding the candidate threshold ,Right now When a node is added to the master node candidate list, the candidate node participates in the master node election through a verifiable random function; the second level consists of ordinary nodes, when a node... Overall rating Exceeding the minimum consensus threshold ,Right now At level 1, a node is considered a regular node. Regular nodes do not participate in the primary node election but still participate in consensus as replica nodes. The third level consists of malicious nodes. Overall rating Less than the minimum consensus threshold ,Right now At this time, the node is considered a malicious node and will not participate in the master node election or consensus; wherein, the candidate list contains at least two candidate nodes, and the candidate threshold is... and minimum consensus threshold satisfy: ;

[0013] Using a verifiable random function, nodes are randomly selected from the candidate nodes as master nodes P1 and P2. Each candidate node generates a key pair. Each node uses parameter m and its private key as input to generate a random number and a corresponding verifiable proof, and broadcasts the result to other nodes. Other nodes use their public keys to verify the validity of the result, ensuring that it has not been tampered with and is authentic and reliable. The two nodes with the smallest random output values ​​are selected as master nodes.

[0014] Furthermore, in step S2, the client sends a request message to both master node P1 and master node P2, with the following message format:

[0015]

[0016] REQUEST is the request message type identifier. Here, t is the client identifier that sent the request, and t is the timestamp of the transaction request. Digital signature for the client;

[0017] During the Pre-prepare phase, after receiving a message from the client, master node P1 verifies the signature and content, signs the message using a ring signature, and sends it to other nodes as a Pre-prepare message. The message format is as follows:

[0018]

[0019] Where v is the consensus view number, s is the request sequence number, and t is the timestamp. It is a message summary. It is the ring signature generated by the master node P1, and L is the set of ring public keys;

[0020] During the Check phase, after receiving the Pre-prepare message from the master node P1, the replica node verifies the ring signature of the Pre-prepare phase based on the ring member public key set 𝐿. If the verification is successful, it sends a check message to the master node P2; if the verification fails, the message is considered invalid, the node discards the message and records the abnormal behavior for subsequent reputation deduction. The check message format is:

[0021]

[0022] in This indicates that the request message verification was invalid. This indicates that the request message has been verified as valid;

[0023] During the Commit phase, the master node P2 receives Check messages from the replica nodes, performs ring signature verification on each Check message to ensure that the signature was generated by a legitimate replica node, and extracts the link tags. Used to detect duplicate voting; if When a message appears repeatedly, it is considered a duplicate vote from the same node. Only one Check message is retained and counted as a valid vote; the remaining duplicate messages are discarded, and the corresponding node is marked as an abnormal node. When the vote count is greater than [a certain value], [the sentence is incomplete]. When the total number of system nodes n≥3f+1, and 𝑓 is the tolerable number of Byzantine nodes), master node P2 determines that the proposal has passed the Check phase, generates and broadcasts a Commit message, the message format of which is:

[0024]

[0025] Replica nodes receive the Commit message and update their state. Upon receiving the Commit message, each replica node verifies the validity of the signature; if verification is successful, it updates its local state, marks the proposal as committed, and prepares to send a Reply message to the client. The message format is as follows:

[0026]

[0027] During the view switching phase, if P1 is a Byzantine node, and the replica node times out without receiving a message from P1, it determines P1 is invalid and sends a re-election message to P2. P2 initiates the view switch after collecting at least 2f+1 valid re-election messages. If P2 is a Byzantine node, and the replica node times out without receiving a message from P2, it determines P2 is invalid and sends a re-election message to P1. P1 initiates the view switch after collecting at least 2f+1 valid re-election messages. If both primary nodes are Byzantine nodes, and the replica node times out without receiving messages from P1 and P2, it determines that the current dual-primary node is invalid and broadcasts a view switching request to all nodes. When the system collects at least 2f+1 valid re-election messages, the replica node completes the view switch based on the updated view number and candidate list, and re-elects new dual-primary nodes. The re-election message format is:

[0028]

[0029] Where reason is the timeout or exception reason code. This serves as an identifier for the abnormal master node. Sign the node;

[0030] When entering the view switching phase, the abnormal nodes are comprehensively scored and corrected based on the abnormal records of this round, the candidate list is updated, the view number is incremented by 1, and dual master nodes are re-elected, and then the consensus process is re-executed.

[0031] Furthermore, in S3, after the consensus process is completed, the system collects the behavioral data of each node in this round of consensus process. The behavioral data includes the node's participation in voting, the correctness of transaction processing, message response time, and whether there is any abnormal behavior.

[0032] Based on the behavioral data, the malicious behavior index, lazy behavior index, transaction accuracy index, and response time index of the node in this round of consensus process are calculated respectively, and each index is normalized.

[0033] Based on the behavioral index values ​​of each node, the reputation increment of the node in the current consensus round is calculated through a preset weight function, and the original comprehensive score of the node is updated to obtain a new comprehensive score of the node.

[0034] The node set is updated based on the updated node level information to provide a basis for the next round of master node election.

[0035] It should be noted that, compared with the prior art, the present invention has the following beneficial effects:

[0036] 1. By constructing a multi-dimensional dynamic reputation evaluation model, we can achieve quantitative evaluation of node behavior, thereby selecting trustworthy nodes to participate in consensus and improving system security;

[0037] 2. A dual-master node structure is adopted, in which master nodes P1 and P2 work together to reduce the load on a single master node and increase system throughput.

[0038] 3. Use verifiable random functions for master node election to improve the randomness and unpredictability of master node election and reduce the risk of node attacks;

[0039] 4. Introduce a linkable ring signature mechanism in the consensus process to enable anonymous voting by nodes, and use link tags to deduplicate votes to ensure vote uniqueness. Attached Figure Description

[0040] Figure 1 This is a flowchart illustrating the dual-master node Byzantine fault-tolerant consensus method based on a reputation evaluation model provided in an embodiment of the present invention.

[0041] Figure 2 A node classification diagram for a dual-master node Byzantine fault-tolerant consensus method based on a reputation evaluation model provided in an embodiment of the present invention;

[0042] Figure 3 A schematic diagram of the consensus process of the dual-master node Byzantine fault-tolerant consensus method based on a reputation evaluation model provided in an embodiment of the present invention;

[0043] Figure 4 A comparative diagram of communication overhead for the dual-master node Byzantine fault-tolerant consensus method based on a reputation evaluation model provided in an embodiment of the present invention;

[0044] Figure 5 A schematic diagram showing the throughput comparison of the dual-master node Byzantine fault-tolerant consensus method based on a reputation evaluation model provided in this embodiment of the invention;

[0045] Figure 6 This diagram illustrates the consensus latency comparison of the dual-master node Byzantine fault-tolerant consensus method based on a reputation evaluation model, as provided in this embodiment of the invention. Detailed Implementation

[0046] To better explain and facilitate understanding of the present invention, the embodiments of the present invention will be described in detail below with reference to the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solutions of the present invention and should not be used to limit the scope of protection of the present invention.

[0047] Example 1: As Figure 1 As shown, this invention provides a dual-master node Byzantine fault-tolerant consensus method based on a reputation evaluation model, specifically including the following steps:

[0048] S1: Construct a multi-dimensional dynamic reputation evaluation model to calculate the comprehensive score of nodes, which serves as the basis for master node election;

[0049] In this step, the system first performs a reputation assessment on the nodes participating in the consensus. Based on the nodes' historical transaction records and average latency, four metrics are derived: malicious behavior, lazy behavior, transaction accuracy, and response time. The malicious behavior metric describes whether a node has sent illegal messages or tampered with data. The lazy behavior metric describes whether a node has failed to participate in voting or delayed its response. The transaction accuracy metric reflects the correctness of a node's transaction verification process. The response time metric measures the node's average communication latency in the network.

[0050] For n nodes and m indicators, construct the original data matrix. :

[0051]

[0052] Calculated using the range transformation method :

[0053]

[0054]

[0055] Calculate the ratio of each node under each indicator. :

[0056]

[0057] Calculate the entropy value of each indicator. :

[0058]

[0059] Calculate weights using entropy values. :

[0060]

[0061] Calculate the overall score for each node. :

[0062]

[0063] like Figure 2 As shown, nodes are divided into different levels based on their comprehensive scores. The first level consists of candidate nodes. When the comprehensive score of node i is... Exceeding the candidate threshold ,Right now When a node is selected, it is added to the master node candidate list. Candidate nodes participate in the master node election using a verifiable random function. The second level consists of ordinary nodes, where node i's overall score... Exceeding the minimum consensus threshold ,Right now At level 1, a node is considered a regular node. Regular nodes do not participate in the primary node election but still participate in the consensus process as replica nodes. Level 3 consists of malicious nodes, where node i's overall score... Less than the minimum consensus threshold ,Right now In such cases, the node is considered malicious and will not participate in master node election or consensus. This node screening mechanism effectively reduces the probability of malicious nodes participating in consensus, thereby improving the overall security of the system.

[0064] Using a verifiable random function, nodes are randomly selected from the candidate nodes as master nodes P1 and P2. Each candidate node generates a key pair. Each node uses parameter m and its private key as input to generate a random number and a corresponding verifiable proof, and broadcasts the result to other nodes. Other nodes use their public keys to verify the validity of the result, ensuring that it has not been tampered with and is authentic and reliable. The two nodes with the smallest random output values ​​are selected as master nodes.

[0065] S2: Based on the comprehensive node score, elect master nodes P1 and P2 from the candidate node set and reach a consensus;

[0066] Consensus phase, such as Figure 3 As shown, in the Request phase, the client sends a request message to master nodes P1 and P2, with the following message format:

[0067]

[0068] REQUEST is the request message type identifier. Here, t is the client identifier that sent the request, and t is the timestamp of the transaction request. Digital signature for the client;

[0069] During the pre-prepare phase, after receiving a message from the client, the master node P1 verifies the signature and content. System parameters are initialized, and... Given a cyclic group with group order q, define a hash function. and H1 is used to generate challenge values, and H2 is used to map the ring public key set to group elements;

[0070] Each node selects a random number. As your private key, your public key can be represented as:

[0071]

[0072] All consensus node public keys are sorted by node identifier to form a ring public key set. And ensure that all nodes use a consistent set of rings and a consistent sorting rule;

[0073] Master node P1 calculates h based on the ring set:

[0074]

[0075] And calculate the link tags in the Pre-prepare stage:

[0076]

[0077] Generate ring signature proof, with master node P1 randomly selected. ,calculate:

[0078]

[0079] Where π is the index of the main node P1 in the ring set L, and the members i in the ring except for the index π are randomly selected sequentially. and calculate until obtained :

[0080]

[0081] Finally, calculate the response value corresponding to master node P1:

[0082]

[0083] And obtain the ring signature for the Pre-prepare stage:

[0084] The master node P1 sends a pre-prepare message to other nodes, with the following message format:

[0085]

[0086] Where v is the consensus view number, s is the request sequence number, and t is the timestamp. It is a message summary. It is the ring signature generated by the master node P1, and L is the set of ring public keys;

[0087] During the Check phase, after receiving the Pre-prepare message from the master node, the replica node verifies the ring signature from the Pre-prepare phase based on the ring member public key set 𝐿. The replica node calculates the following based on the ring set:

[0088]

[0089] and with private key Calculate the link tags for the Check phase:

[0090]

[0091] The replica nodes are computed in cyclic order for i=1,2,…,n-1:

[0092]

[0093]

[0094]

[0095] The replica node determines the signature verification result and executes the processing. If the closed-loop consistency condition is met... If the verification is successful, the replica node accepts the proposal and enters the Check voting process; if the closed-loop consistency condition is not met, the message is considered illegal, the node discards the message and records the abnormal behavior for subsequent reputation deduction.

[0096] Replica nodes are selected randomly. Calculate the initial challenge value and recursively calculate the challenge chain along the ring to obtain the ring signature for the Check phase:

[0097] The replica node encapsulates the signature into a Check message and sends it to the master node P2. The message format is as follows:

[0098]

[0099] in This indicates that the request message verification was invalid. This indicates that the request message has been verified as valid.

[0100] During the Commit phase, the master node P2 receives Check messages from the replica nodes, performs ring signature verification on each Check message to ensure that the signature was generated by a legitimate replica node, and extracts the link tags. Used to detect duplicate voting; if When a message appears repeatedly, it is considered a duplicate vote from the same node. Only one Check message is retained and counted as a valid vote; the remaining duplicate messages are discarded, and the corresponding node is marked as an abnormal node. When the number of valid unique votes is greater than... When the total number of system nodes n ≥ 3f + 1, and 𝑓 is the tolerable number of Byzantine nodes, master node P2 determines that the proposal has passed the Check phase, generates and broadcasts a Commit message, the message format of which is:

[0101]

[0102] During the Reply phase, after each replica node receives and verifies the Commit message, it updates its local state to "committed" and sends a Reply message to the client. The message format is as follows:

[0103]

[0104] During the view switching phase, if P1 is a Byzantine node, and the replica node times out without receiving a message from P1, it determines P1 is invalid and sends a re-election message to P2. P2 initiates the view switch after collecting at least 2f+1 valid re-election messages. If P2 is a Byzantine node, and the replica node times out without receiving a message from P2, it determines P2 is invalid and sends a re-election message to P1. P1 initiates the view switch after collecting at least 2f+1 valid re-election messages. If both primary nodes are Byzantine nodes, and the replica node times out without receiving messages from P1 and P2, it determines the current dual-primary node is invalid and broadcasts a view switching request to all nodes. When the system collects at least 2f+1 valid re-election messages, the replica node completes the view switch based on the updated view number and candidate list, and re-elects new dual-primary nodes. The re-election message format is:

[0105]

[0106] Where reason is the timeout or exception reason code. This serves as an identifier for the abnormal master node. Sign the node;

[0107] When entering the view switching phase, the abnormal nodes are comprehensively scored and corrected based on the abnormal records of this round, the candidate list is updated, the view number is incremented by 1, and the two master nodes are re-elected, entering a new round of consensus process.

[0108] S3: Consensus ends, node comprehensive score is updated.

[0109] After the consensus process concludes, the system collects behavioral data from each node during this round of consensus. This data includes node participation in voting, transaction processing correctness, message response time, and the presence of any abnormal behavior. Based on this data, the system calculates indicators for malicious behavior, lazy behavior, transaction accuracy, and response time for each node during this round of consensus, and normalizes these indicators. Based on each node's behavioral indicator values, the system calculates the node's reputation increment for the current consensus round using a preset weighting function, and updates the node's original comprehensive score to obtain a new comprehensive node score. The updated node score information is then used to update the node set, providing a basis for the next round of master node election.

[0110] Example 2: Example 2 of the present invention considers testing different performance indicators on different numbers of nodes n to verify the usability and effectiveness of the proposed technical method.

[0111] Figure 4 This diagram illustrates a comparison of communication overhead for a dual-master node Byzantine Fault-Tolerant Consensus (DPBFT) method based on a reputation evaluation model under different numbers of nodes. Communication overhead reflects the total communication volume consumed by nodes exchanging messages during a consensus round; the less communication volume generated during consensus, the lower the system operating cost. As the number of nodes n increases, the communication complexity of the PBFT algorithm grows exponentially; RC-PBFT is a parallel PBFT algorithm for random clusters, with a communication complexity of O(n). (where c is the cluster size, and c is less than n); the DPBFT consensus method of the present invention separates the proposal broadcasting and voting statistics functions by setting master nodes P1 and P2, thereby reducing the number of messages transmitted and effectively reducing communication overhead.

[0112] Figure 5 This diagram illustrates the throughput comparison of a dual-master node Byzantine Fault-Tolerant Consensus (DPBFT) method based on a reputation evaluation model under different numbers of nodes, according to the present invention. Throughput refers to the number of transactions that the system can process per second, which can be expressed as transactions per second. Higher throughput indicates better system transaction processing capabilities.

[0113] Figure 6 This diagram illustrates a comparison of consensus latency for a dual-master node Byzantine Fault-Tolerant Consensus (DPBFT) method based on a reputation evaluation model, according to the present invention, under different numbers of nodes. Consensus latency refers to the time required for a client to send a request to a node in the system to complete a consensus. Consensus latency reflects the time elapsed from when a client initiates a request to when the system completes consensus and returns a confirmation result. The lower the consensus latency, the faster the system responds to transaction requests.

[0114] The above description is merely a preferred embodiment of the present invention and is not intended to further limit the present invention. All equivalent changes made based on the description and drawings of the present invention are within the protection scope of the present invention.

Claims

1. A dual-master node Byzantine fault-tolerant consensus method based on a reputation evaluation model, applicable to a distributed system with n nodes, where n ≥ 3f + 1, and f is the number of Byzantine nodes the system can tolerate, characterized in that... Includes the following steps: S1: Calculate a comprehensive score for nodes participating in consensus based on malicious behavior indicators, lazy behavior indicators, transaction accuracy indicators, and response time indicators, and classify nodes into candidate nodes, ordinary nodes, and malicious nodes based on the comprehensive score. S2: Elect master nodes P1 and P2 based on comprehensive scoring; where P1 is used to generate and broadcast Pre-prepare messages, and P2 is used to receive Check messages sent by replica nodes, identify duplicate votes based on link tags, and count valid unique votes; after the replica nodes verify the Pre-prepare messages, they generate linkable ring signature Check messages with link tags and send them to P2; after the number of valid votes reaches 2 / 3 of the consensus nodes, P2 broadcasts a Commit message, enabling the replica nodes to complete the commit and return a Reply message to the client; S3: After this round of consensus is completed, the node comprehensive score is updated based on the node behavior, and the candidate list is reconstructed based on the updated node level information; when a view switch occurs in this round, the abnormal event that triggers the view switch will be used as the basis for reputation correction and will be used for the next round of dual master node election.

2. The dual-master node Byzantine fault-tolerant consensus method based on a reputation evaluation model according to claim 1, characterized in that, The specific steps of step S1 are as follows: S11: Based on the node's historical transaction records and average latency, four indicators are obtained: malicious behavior, lazy behavior, transaction accuracy, and response time. Malicious behavior refers to malicious operations such as nodes tampering with transaction data or failing to send messages within a preset timeout threshold. Lazy behavior refers to the behavior of nodes experiencing network latency or intentional delays during the consensus process. Transaction accuracy refers to the proportion of nodes that correctly verify data. Response time refers to the average latency between a node receiving a network request and the node returning a valid response. S12: For n nodes and m indicators, construct the original data matrix. : Calculated using the range transformation method : Calculate the ratio of each node under each indicator. : Calculate the entropy value of each indicator. : Calculate weights using entropy values. : Calculate the overall score for each node. : S13: Comprehensive scoring of each node The nodes are sorted and divided into three levels—candidate nodes, normal nodes, and malicious nodes—based on preset thresholds; the first level is candidate nodes, where a node... Overall rating Exceeding the candidate threshold ,Right now At that time, the node is added to the list of candidate master nodes; Candidate nodes participate in the master node election through a verifiable random function; The second level consists of ordinary nodes, when a node... Overall rating Exceeding the minimum consensus threshold ,Right now At that time, it is a regular node. Regular nodes do not participate in the election of the master node, but still participate in the consensus process as a replica node. The third level is malicious nodes, when a node... Overall rating Less than the minimum consensus threshold ,Right now At this time, the node is considered a malicious node and will not participate in the master node election or consensus; wherein, the candidate list contains at least two candidate nodes, and the candidate threshold is... and minimum consensus threshold satisfy: ; S14: Use a verifiable random function to randomly select nodes from the candidate nodes as master nodes P1 and P2; the candidate nodes generate a pair of keys, each node uses parameter m and private key as input to generate a random number and corresponding verifiable proof, and broadcasts the result to other nodes, which use their public key to verify the legality, ensuring that the result is not tampered with and is true and reliable, and select the two nodes with the smallest random output value as master nodes.

3. The dual-master node Byzantine fault-tolerant consensus method based on a reputation evaluation model according to claim 1, characterized in that, The specific steps of step S2 are as follows: S21: In the Request phase, the client sends a request message to master nodes P1 and P2. The message format is as follows: REQUEST is the request message type identifier. Here, t is the client identifier that sent the request, and t is the timestamp of the transaction request. Digital signature for the client; S22: In the Pre-prepare phase, after receiving the message from the client, the master node P1 verifies the signature and content, signs the message using a ring signature, and sends it to other nodes as a pre-prepare message. The message format is as follows: Where v is the consensus view number, s is the request sequence number, and t is the timestamp. It is a message summary. It is the ring signature generated by the master node P1, and L is the set of ring public keys; S23: In the Check phase, each replica node receives a message from the master node P1 and verifies its validity. If the verification is successful, it sends a check message to the master node P2. The message format is as follows: in This indicates that the request message verification was invalid. This indicates that the request message has been verified as valid; S24: In the Commit phase, master node P2 counts the number of valid votes. When the number of votes reaches 2 / 3 of the consensus nodes, master node P2 generates and broadcasts a Commit message. The message format is as follows: S25: In the Reply phase, after each replica node receives and verifies the Commit message, it updates its local state to "committed" and sends a Reply message to the client. The message format is as follows: S26: During the view switching phase, if P1 is a Byzantine node, and the replica node does not receive a message from P1 within the preset timeout threshold, it determines P1 is invalid and sends a re-election message to P2. P2 initiates a view switch after collecting at least 2f+1 valid re-election messages. If P2 is a Byzantine node, and the replica node does not receive a message from P2 within the preset timeout threshold, it determines P2 is invalid and sends a re-election message to P1. P1 initiates a view switch after collecting at least 2f+1 valid re-election messages. If both primary nodes are Byzantine nodes, and the replica node does not receive messages from P1 and P2 within the preset timeout threshold, it determines that the current dual primary nodes are invalid and broadcasts a view switching request to all nodes. When the system collects at least 2f+1 valid re-election messages, the replica node completes the view switch based on the updated view number and candidate list, and re-elects new dual primary nodes. The re-election message format is: Where reason is the timeout or exception reason code. This serves as an identifier for the abnormal master node. Sign the node; When entering the view switching phase, the abnormal nodes are corrected by comprehensive scoring based on the abnormal records of this round, the candidate list is updated, the view number is incremented by 1, and dual master nodes are re-elected. Then, the S21 to S25 process is re-executed.

4. The dual-master node Byzantine fault-tolerant consensus method based on a reputation evaluation model according to claim 3, characterized in that, The specific steps of step S22 are as follows: S221: System parameter initialization, set Given a cyclic group with group order q, define a hash function. and H1 is used to generate challenge values, and H2 is used to map the ring public key set to group elements; S222: Each node selects a random number. As your private key, your public key can be represented as: All consensus node public keys are sorted by node identifier to form a ring public key set. And ensure that all nodes use a consistent set of rings and a consistent sorting rule; S223: Master node P1 calculates h based on the ring set: And calculate the link tags in the Pre-prepare stage: S224: Generate ring signature proof, master node P1 is randomly selected. ,calculate: Where π is the index of the main node P1 in the ring set L, and the members i in the ring except for the index π are randomly selected sequentially. and calculate until obtained : Finally, calculate the response value corresponding to master node P1: And obtain the ring signature for the Pre-prepare stage:

5. The dual-master node Byzantine fault-tolerant consensus method based on a reputation evaluation model according to claim 3, characterized in that, The specific steps of step S23 are as follows: S231: After receiving the Pre-prepare message sent by the master node P1, the replica node verifies the ring signature of the Pre-prepare stage based on the ring member public key set 𝐿; S232: Replica nodes are computed based on ring sets: and with private key Calculate the link tags for the Check phase: S233: The replica nodes are computed in cyclic order for i=1,2,…,n-1: The replica node determines the signature verification result and executes the processing. If the closed-loop consistency condition is met... If the verification passes, the replica node accepts the proposal and enters the Check voting process; if the verification fails, the Pre-prepare message is discarded, the node that sent the message is marked as an abnormal node, and the abnormal event is used as the basis for reputation deduction. S234: Generate a linkable ring signature during the Check phase; replica nodes are randomly selected. Calculate the initial challenge value and recursively calculate the challenge chain along the ring to obtain the ring signature for the Check phase: S235: Send a Check message. The replica node encapsulates the signature into a Check message and sends it to the master node P2.

6. The dual-master node Byzantine fault-tolerant consensus method based on a reputation evaluation model according to claim 3, characterized in that, The specific steps of step S24 are as follows: S241: The primary node P2 receives the Check messages sent by the replica nodes, performs ring signature verification on each Check message to ensure that the signature was generated by a legitimate replica node, and extracts the link tags. Used to detect duplicate voting; if When a message appears repeatedly, it is determined to be a duplicate vote from the same node. Only one Check message is retained and counted as a valid vote, while the remaining duplicate messages are discarded, and the corresponding node is marked as an abnormal node. S242: When the number of valid unique votes is greater than When (where 𝑓 is the tolerable number of Byzantine nodes), the master node P2 determines that the proposal has passed the Check phase, generates and broadcasts the Commit message.

7. The dual-master node Byzantine fault-tolerant consensus method based on a reputation evaluation model according to claim 1, characterized in that, The specific steps of step S3 are as follows: S31: After the consensus process is completed, the system will collect the behavioral data of each node in this round of consensus. The behavioral data includes the node's participation in voting, the correctness of transaction processing, message response time, and whether there is any abnormal behavior. S32: Based on the behavioral data, calculate the malicious behavior index, lazy behavior index, transaction accuracy index, and response time index of the node in this round of consensus process, and normalize each index. S33: Based on the behavioral index values ​​of each node, calculate the reputation increment of the node in the current consensus round through a preset weight function, and update the original comprehensive score of the node to obtain a new comprehensive score of the node. S34: Update the node set based on the updated node level information to provide a basis for the next round of master node election.

Images