A byzantine fault-tolerant raft consensus method based on deputy leader and threshold BLS signature

Abstract

This invention belongs to the field of blockchain and distributed system technology, specifically providing a Byzantine fault-tolerant RAFT consensus method based on a deputy leader and threshold BLS signatures. The method includes: fixing a trusted authorizing institution as the deputy leader, which coordinates the collection, normalization calculation, and score broadcasting of performance indicators from all follower nodes, providing a performance basis for election; after a follower's heartbeat times out, it becomes a candidate and initiates an election request to the deputy leader; the deputy leader generates and divides signature shares using the threshold BLS signature system, generates commitment values ​​for each share using the Pedersen commitment scheme, and distributes them; after a candidate initiates a voting request, each node returns its share after multi-dimensional verification; the candidate collects sufficient shares to generate an aggregate signature and submits it to the deputy leader; the deputy leader completes the final verification and decision and broadcasts the leader confirmation message; after all nodes in the network synchronize and update their roles, the new leader leads the heartbeat and log synchronization. This solution ensures the performance reliability of the leader node, improves the cryptographic security of the election signature, standardizes and simplifies the election process, effectively improves the efficiency, fault tolerance, and overall availability of the distributed system consensus process, and adapts to the application needs of large-scale heterogeneous node distributed systems.

Description

Technical Field

[0001] This invention belongs to the field of blockchain and distributed system technology, specifically relating to a Byzantine fault-tolerant RAFT consensus method based on deputy leader and threshold BLS signature. Background Technology

[0002] In distributed systems, consensus algorithms are the core technology for ensuring data consistency across multiple nodes and improving system fault tolerance and availability. Raft, as a mainstream consensus algorithm, is widely used in distributed storage, blockchain, cloud-native middleware, and other fields due to its simple logic and ease of engineering implementation. With the increasing scale of distributed systems, the growing heterogeneity of node performance, and the increasing complexity of network environments, higher demands are placed on the election efficiency, leader performance reliability, and signature security of the Raft algorithm. Optimizing the Raft election mechanism and introducing a cryptographically secure signature system have become key research directions for improving the consensus efficiency and security of distributed systems.

[0003] Current Raft consensus algorithms primarily trigger elections through random node timeouts. Candidates then request votes from other nodes, and voting and leader election are completed based on the freshness of log entries. Some improved schemes introduce simple performance metric screening or conventional digital signature mechanisms. Regarding signature applications, single-node signatures or ordinary multi-signature methods are commonly used, lacking threshold-based signature splitting and aggregation mechanisms. In leader selection, either the actual performance differences between nodes are not considered, or only simple metric judgments are made, and there is no dedicated node responsible for unified calculation and verification of performance metrics. Furthermore, the election process lacks cryptographic commitment schemes to prevent tampering of signature shares, making it susceptible to problems such as signature share tampering and low-performance nodes being elected as leaders, leading to a decrease in system consensus efficiency.

[0004] The aforementioned design of existing technologies leads to several shortcomings in the Raft algorithm's practical applications: First, the leader election lacks a unified performance evaluation and screening mechanism, making low-performance nodes prone to becoming system performance bottlenecks after election, affecting log replication and consensus efficiency. Second, the signature mechanism lacks security and flexibility; single-node signatures pose a single point of failure risk, and ordinary multi-signature methods struggle to achieve threshold aggregation and secure distribution of signature shares. Third, the signature shares lack effective anti-tampering verification methods during the election process, making them susceptible to data tampering that could affect the legitimacy of the election. Furthermore, the lack of a dedicated trusted node to coordinate the election process results in fragmented election verification logic and low efficiency. Therefore, there is an urgent need to design an improved Raft consensus method that balances performance screening, threshold-secure signatures, and trusted node coordination to address the technical problems of low election efficiency, unreliable leader performance, and insufficient security of the signature system in existing algorithms. Summary of the Invention

[0005] To address the problems existing in the background technology, this invention provides a Byzantine Fault-Tolerant RAFT consensus method based on deputy leader and threshold BLS signatures, comprising:

[0006] S1: The trusted authorized authority is designated as the deputy leader node, and the remaining nodes are designated as follower nodes. Each follower node periodically collects local performance metrics and sends them to the deputy leader node. The deputy leader node analyzes the local performance metrics of each follower node, calculates the performance score of each follower node, and broadcasts the results.

[0007] S2: Each follower node listens to the leader node's heartbeat in real time. If a follower node does not receive the leader node's heartbeat for a preset time, it enters the candidate state.

[0008] S3: The candidate node sends an election request to the deputy leader node, and the deputy leader node distributes the signature share to each node according to the election request through the threshold BLS signature key system and the Pedersen cryptographic commitment scheme.

[0009] S4: After obtaining the signature share distribution information from the deputy leader, the candidate node sends a voting request to each node. After receiving the voting request from the candidate node, each node votes and returns the signature share to the candidate node.

[0010] S5: Candidate nodes collect the signature shares returned by each node and generate a threshold BLS aggregate signature, and submit the BLS aggregate signature and election message to the deputy leader;

[0011] S6: The deputy leader receives the BLS aggregated signature and election message from each candidate node, performs final verification and adjudication, and broadcasts the leader confirmation message;

[0012] S7: After each node receives the leader's confirmation message broadcast by the deputy leader, it updates its own role to a follower node;

[0013] S8: The leader node periodically sends heartbeat and log synchronization requests to all follower nodes. Each follower node continuously listens for the leader node's heartbeat and completes log synchronization.

[0014] The present invention has at least the following beneficial effects

[0015] This invention coordinates the collection, calculation, and broadcasting of performance indicators through a trusted authorized institution, and ensures the performance reliability of the leader node by combining performance thresholds and priority screening, thereby improving the overall consensus and log synchronization efficiency of the distributed system. It also overcomes the shortcomings of existing signature mechanisms, such as single point of failure and lack of threshold aggregation capabilities. Leveraging the share splitting and aggregation characteristics of threshold BLS signatures, it achieves secure distribution and effective verification of election signatures. Combined with the Pedersen commitment scheme for tamper-proof verification of signature shares, it further enhances the cryptographic security of the election process. Simultaneously, with a trusted authorized institution acting as the deputy leader to coordinate the entire election process, uniformly completing signature issuance, share distribution, and final decision-making, it solves the problems of fragmented and inefficient traditional election verification logic, making the election process more standardized and verification more efficient. Overall, it improves the fault tolerance, security, and availability of the distributed system consensus process, adapting to the application needs of large-scale heterogeneous node distributed systems. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the method flow of the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] Please see Figure 1 This invention provides a Byzantine Fault-Tolerant RAFT consensus method based on deputy leader and threshold BLS signatures, comprising:

[0019] S1: The trusted authorized authority is designated as the deputy leader node, and the remaining nodes are designated as follower nodes. Each follower node periodically collects local performance metrics and sends them to the deputy leader node. The deputy leader node analyzes the local performance metrics of each follower node, calculates the performance score of each follower node, and broadcasts the results.

[0020] Preferably, the calculation of the performance score of each follower node includes:

[0021] S11: Follower Nodes In each statistics window Internally, local performance metrics are periodically collected and reported to the deputy leader node in real time; these local performance metrics include: computing power. Log processing throughput Stable online rate Average response time for log replication Heartbeat round-trip delay ;

[0022] S12: The secondary leader node receives the metric reports from all follower nodes, summarizes them to obtain the entire set of follower nodes N, and processes the metrics. , and Perform positive normalization on the indicators and Perform reverse normalization;

[0023] S13: The secondary leader node performs a weighted fusion of the normalized performance indicators of each follower node according to the preset weight parameters to obtain the initial performance score of each follower node.

[0024] S14: Apply an exponential moving average to smooth the initial performance scores of each follower node to obtain the performance score of each follower node:

[0025]

[0026] in, Represents follower nodes Performance score; Indicates the previous statistics window Inner follower node Performance score; Represents follower nodes The initial performance score; Indicates the smoothing coefficient;

[0027] S15: The deputy leader node generates a structured performance score table. :

[0028]

[0029] in, Represents the set of follower node IDs. This represents the set of performance scores for follower nodes; Indicates the version number of the statistics window;

[0030] S16: Secondary Leader Node Pair Perform digital signature, and then digitally sign the document. Broadcast to all follower nodes; each follower node verifies the validity of the digital signature and caches the latest version. and .

[0031] In this embodiment, the trusted authorization authority is fixed as the deputy leader node, and the remaining nodes are follower nodes. Each follower periodically collects local performance indicators such as computing power and log throughput according to a statistical window and reports them to the deputy leader. The deputy leader first performs positive and negative normalization on the indicators, then obtains the original performance score through weighted summation. After smoothing by exponential moving average to suppress short-term jitter, a PerfTable containing the node ID, performance score, and version number is generated. After signing, it is broadcast to all nodes, and each node caches the table after verification. This step, through the trusted authorization authority, achieves unified collection, standardized calculation, and authoritative distribution of network-wide performance indicators. It eliminates differences in indicator dimensions and ensures the stability of performance scores through smoothing. This provides an objective, unified, and effective data basis for subsequent performance threshold judgment and priority ranking in the election. At the same time, the signature broadcast method ensures the immutability of performance data, ensuring the fairness and accuracy of the performance screening process in the election from the source.

[0032] S2: Each follower node listens to the leader node's heartbeat in real time. If a follower node does not receive the leader node's heartbeat for a preset time, it enters the candidate state.

[0033] Preferably, step S2 includes: when the leader node is working normally, it continuously sends heartbeat packets to all follower nodes at a fixed period; each follower node maintains an independent heartbeat timer to monitor the leader's heartbeat in real time; if a follower node's heartbeat timer reaches a preset timeout threshold and does not receive a valid heartbeat packet from the leader during this period, the leader node is determined to be faulty / out of contact; the follower node whose heartbeat timeout has occurred performs a local state update and officially enters the candidate state, as follows:

[0034] Character Update: ;

[0035] Term of office update: ; This indicates the current term number cached locally.

[0036] In this embodiment, each follower node continuously listens for the leader node's heartbeat in real time. Each node independently maintains a heartbeat timer. When a follower node fails to receive a valid heartbeat from the leader within a preset time, it determines that the leader node is faulty or out of contact. The follower node then updates its local term number and switches its role to that of a candidate, formally triggering a new round of leader election. This step maintains the simplicity and effectiveness of the Raft algorithm's heartbeat mechanism. Accurate heartbeat timeout detection enables rapid detection of leader faults, ensuring the timeliness of the election process. Simultaneously, the updating of the term number and the dedicated switching of candidate status ensure that the election always proceeds in an orderly manner within the latest term, avoiding interference from old term information. This lays the foundation for the standardized execution of subsequent election processes and effectively improves the fault tolerance and rapid recovery capabilities of the distributed system.

[0037] S3: The candidate node sends an election request to the deputy leader node, and the deputy leader node distributes the signature share to each node according to the election request through the threshold BLS signature key system and the Pedersen cryptographic commitment scheme.

[0038] Preferably, step S3 includes:

[0039] S31: Candidate node A sends an election request to the deputy leader node. ;

[0040]

[0041] in, Indicates the term of office. Represents candidate nodes ID; This represents the index of the last log entry on the candidate node's local machine. This represents the term number in the last log entry on the candidate node's local machine.

[0042] S32: The deputy leader node receives an election request. Then, from the local cache Read the performance score of candidate A With the present Constructing a unique election message that prevents replay. :

[0043]

[0044]

[0045] in, Represents a random number. Represents a timestamp;

[0046] S33: The secondary leader node uses a threshold BLS signature private key to... Obtain by signing According to the total number of follower nodes use Secret sharing algorithm will Cut into Individual signature share Threshold BLS signatures require at least the following collections: Individual shares can be aggregated into a valid signature. The preset threshold value;

[0047] S34: The deputy leader node, based on the Pedersen cryptographic commitment scheme, assigns a share of signatures to each node. Calculate the corresponding commitment value separately. ;

[0048] S35: The deputy leader is each follower node in the network. Distribute unified data packets:

[0049]

[0050] in, for The hash value.

[0051] In this embodiment, the node that switches to the candidate position after a heartbeat timeout sends an election request containing the term of office, node ID, and local log information to the deputy leader, who acts as the trusted authorizing body. The deputy leader reads the candidate's performance score and version number from the cached performance score table, constructs a unique election message containing a replay-protected random number / timestamp, generates a signature for the election message using a threshold BLS signature system, and divides it into n independent signature shares. Simultaneously, based on the Pedersen cryptographic commitment scheme, a corresponding commitment value is generated for each share. Finally, the election message hash, signature share, commitment value, and term of office are packaged and distributed to each node in the cluster, and each node caches the message according to the rules. This step, with the trusted deputy leader as the sole issuer, achieves standardized construction of the election message and secure distribution of signature shares. The segmentation of the threshold BLS signature lays the cryptographic foundation for subsequent aggregated signature verification, while the Pedersen commitment scheme binds a dedicated verification basis to the signature shares, preventing tampering of the signature shares from the source. Furthermore, the replay-protected design prevents the reuse of election messages, ensuring the legality, uniqueness, and security of the election request and signature shares.

[0052] S4: After obtaining the signature share distribution information from the deputy leader, the candidate node sends a voting request to each node. After receiving the voting request from the candidate node, each node votes and returns the signature share to the candidate node.

[0053] Preferably, step S4 includes:

[0054] S41: After obtaining the relevant information on the distribution of signature shares from the deputy leader, candidate node A sends a voting request to all nodes in the cluster. :

[0055] ;

[0056] S42: Each node receive Then, the verification will be strictly carried out in the following order. If any step fails, the application will be rejected directly and the share will not be returned:

[0057] S4-01 Term-of-Service Check: If requested Refuse; if Update local ;

[0058] S4-02 Share Validation: Retrieve from local cache and Through Pedersen commitment value verify Whether or not If the match is valid and has not been tampered with, the verification will be rejected if it fails.

[0059] When verifying the signature share, each node will first check the random number / timestamp in ElectionMsg: the timestamp is checked to see if it is within the valid window, and the random number is checked to see if it has been used. If they do not match, the share will be rejected directly.

[0060] S4-03Raft log age determination: Compare the candidate node log with the local log. First, compare the term number of the last log entry. If the term numbers are the same, compare the index. If the candidate log is outdated, reject it.

[0061] S4-4 Performance Threshold Determination: From Local Cache Read Check The version number should match the one in the ElectionMsg; if , Set a preset performance threshold for the system and reject the request.

[0062] S4-5 Priority Assessment for Candidates: Priority is calculated for candidates according to the following rules: Priority given to those with higher experience levels → Priority given to those who update the logs → The smaller one takes priority; if the local best candidate is empty, or A has a higher priority than the local best candidate, then the local best candidate is updated to A, and the voter is A; each node has only one voting opportunity during each term, so the priority of each candidate will be compared during the term, and the best local candidate A will be selected for voting.

[0063] S43: After all verification steps are passed, the node The signature share cached locally Return the share to candidate node A; if verification fails, reject the application directly and do not return any share.

[0064] In this embodiment, after a candidate node obtains the signature share distribution information from the deputy leader, it sends a voting request containing its term of office, node identifier, and log information to all nodes in the cluster. Upon receiving the request, each node performs multi-layered verification in a fixed order: term check, share validity verification, Raft log freshness judgment, performance threshold judgment, and priority judgment within the same term. Only when all verification steps pass is the locally cached signature share returned to the candidate; if any step fails, the candidate is directly rejected. This step, through a progressive multi-dimensional verification logic, ensures the timeliness of the election by relying on term checks, completes the anti-tampering verification of signature shares by using Pedersen commitment values, ensures the consistency of consensus logs by following Raft log rules, eliminates low-performance candidates by screening performance thresholds, determines the optimal candidate within the same term by prioritizing, and uses the return of signature shares as an expression of voting intention, deeply integrating voting behavior with cryptographic verification. This ensures the scientific rigor and scientific nature of the election selection process, enhances the cryptographic security of the voting process, fundamentally avoids invalid candidates from participating in the competition, and lays a reliable foundation for subsequent election decisions.

[0065] S5: Candidate nodes collect the signature shares returned by each node and generate a threshold BLS aggregate signature, and submit the BLS aggregate signature and election message to the deputy leader;

[0066] Preferably, step S5 includes:

[0067] S51: Candidate node A receives the signature shares returned by each node. For each share, perform format and source validation one by one, filter out invalid shares, and record the set of valid shares. ;

[0068] S52: Real-time statistics of the number of valid shares ,when At that time, the candidate invokes the threshold BLS aggregation signature algorithm, taking the effective share set and the original election message as input, to generate a valid aggregation signature. :

[0069]

[0070] Candidate node A packages the election message and aggregate signature, and submits the final election request to the deputy leader node. The submission content is as follows: The deputy leader is requested to carry out the final verification and ruling.

[0071] In this embodiment, the candidate node receives the signature shares returned by each node. It first performs a validity check on the format and source of each share, filtering out invalid shares and recording the set of valid shares. When the number of valid shares reaches the preset threshold value of the threshold BLS signature, it calls the aggregation algorithm to combine the valid shares with the original election message to generate a threshold BLS aggregate signature. Finally, it submits the election message and the aggregate signature together to the deputy leader, who acts as the trusted authorizing body, requesting final verification and adjudication. This step, by verifying the validity of the signature shares, ensures that all shares participating in the aggregation are valid votes from legitimate nodes. Relying on the aggregation characteristics of the threshold BLS signature, it achieves the transformation of multi-signature shares into a valid aggregate signature. This satisfies the cryptographic signature validity requirements and ensures that the election receives the approval of enough nodes in the cluster through the threshold mechanism. Furthermore, submitting the aggregate signature and the election message together provides a complete and verifiable core basis for the deputy leader's final adjudication, ensuring the continuity and effectiveness of the election process from voting to adjudication.

[0072] S6: The deputy leader receives the BLS aggregated signature and election message from each candidate node, performs final verification and adjudication, and broadcasts the leader confirmation message;

[0073] Preferably, step S6 includes: the deputy leader receiving the candidate's submission. Then, the following steps will be strictly reviewed; if any step fails, the candidate will be rejected:

[0074] S61: Verification using threshold BLS public key PK If the signature of ElectionMsg fails to be verified, it will be rejected outright.

[0075] When verifying the aggregate signature, the deputy leader will again check the uniqueness and timeliness of the random number / timestamp to ensure that the ElectionMsg has not been submitted repeatedly.

[0076] S62: From the latest local version Read candidate nodes Check and The version numbers in the two files are consistent; if ;

[0077] S63: The deputy leader maintains a cache of candidate priorities for the current term. If the best priority candidate node has been recorded, and the current candidate node has a higher priority than the recorded best priority candidate, then the current candidate node is updated to the best priority candidate node; otherwise, it is rejected. Finally, the candidate node with the highest priority for the current term is retained as the leader node.

[0078] S64: For the leader node that passed the final ruling. The deputy leader broadcasts a leader confirmation message to all nodes in the cluster. :

[0079]

[0080] in, express The hash value.

[0081] In this embodiment, the deputy leader, acting as the trusted authorizing body, receives the election message and threshold BLS aggregate signature submitted by the candidates. It then conducts a full-process verification in the order of aggregate signature validity verification, performance threshold review, and final priority decision for candidates in the same term. First, the threshold BLS public key is used to verify the legitimacy of the aggregate signature for the election message. Next, the performance scores of the candidates are reviewed to ensure they meet the threshold requirements. Finally, the priorities of all candidates in the same term are comprehensively determined, and only the candidate with the highest priority is retained as the new leader. Subsequently, a leader confirmation message containing information such as the term, leader ID, and aggregate signature digest is broadcast to the entire cluster. This step, with the trusted deputy leader acting as the sole final arbiter, ensures the validity of the aggregate signature from a cryptographic perspective through rigorous multi-dimensional review. It also re-verifies the performance compliance of the candidates and determines the optimal leader for the same term through final priority decision, avoiding the chaos of multiple candidate competition. Furthermore, the broadcast aggregate signature digest improves the verification efficiency of subsequent nodes, ensuring the legitimacy, uniqueness, and performance reliability of the leader election results. This provides an authoritative and effective basis for the unified update of node roles across the entire network.

[0082] S7: After each node receives the leader's confirmation message broadcast by the deputy leader, it updates its own role to a follower node;

[0083] Preferably, step S7 includes:

[0084] S71: Any node receives a broadcast from the secondary leader. Then, first compare the messages in the message. With local ;like If a message is deemed expired, it will be discarded without further processing.

[0085] S72: After the term verification is valid, all nodes perform a local state update: Synchronization is in the message And permanently record the leader's identity during this term. ;

[0086] S73: If the node's own identifier is... In unison, each node updates its own role to leader, and all other nodes are uniformly updated to follower;

[0087] S74: All nodes clear the temporary cache related to the election during the current term, release resources and prepare for the subsequent election.

[0088] In this embodiment, after each node in the cluster receives the leader confirmation message broadcast by the deputy leader, it first verifies the validity of the term in the message and its current local term. If the term in the message has expired, it is discarded directly. If it is valid, the local term and leader identifier are updated synchronously, the candidate node switches to the leader role, and all other nodes are uniformly updated to the follower role. At the same time, each node clears the temporary cache of signature shares, best candidate, etc. generated in this round of election, completing the unified synchronization of roles across the entire network. This step avoids interference from expired election messages through term validity verification, achieves efficient unification of leader identifiers and roles across all nodes in the network, completely ends the election process, and at the same time, clearing the temporary cache not only releases system resources but also prepares for possible subsequent election processes, ensuring a smooth transition of the cluster from the election phase to the stable log replication phase, allowing the distributed system to quickly recover to a unified consensus state, and improving the efficiency and stability of post-election state synchronization.

[0089] S8: The leader node periodically sends heartbeat and log synchronization requests to all follower nodes. Each follower node continuously listens for the leader node's heartbeat and completes log synchronization.

[0090] Step S8 includes:

[0091] S81: The new leader node A sends heartbeats and log append requests to all follower nodes at fixed intervals; the heartbeat is used to maintain its leader status and let follower nodes confirm that the leader is working properly; the log append request carries the latest log information and leads the log synchronization of the entire network.

[0092] S82: After receiving the log append request from the leader node, each follower node immediately performs log verification: if the local log is consistent with the leader log, it responds to the heartbeat normally and maintains the follower state; if the local log is missing or inconsistent, it actively sends a log synchronization request to the leader to obtain the missing log entries and appends them to the local log.

[0093] In this embodiment, the newly elected leader node sends heartbeat packets and log synchronization requests to all follower nodes at fixed intervals. Each follower node continuously maintains a heartbeat timer to listen for the leader's heartbeat. Upon receiving a request, each follower node compares its own log with the leader's log. If any entries are missing or inconsistent, the follower node proactively requests synchronization, appends the missing log entries to its local machine, and applies the changes, ensuring log consistency across the entire network. If a follower subsequently detects that the leader's heartbeat has timed out again, it triggers step S2 to start a new round of election. This step continues and optimizes the core log replication mechanism of the Raft algorithm. It maintains the leader's identity and cluster connectivity through periodic heartbeats and achieves network-wide data consistency through log synchronization requests, ensuring business continuity during the stable operation phase of the distributed system. It also retains the fault-tolerant mechanism of re-entering the election after a heartbeat timeout, allowing the system to quickly detect leader failures and initiate disaster recovery procedures. This achieves both high efficiency and accuracy in data consensus and improves the long-term reliability and fault tolerance of the system, ensuring efficient operation and rapid fault recovery of the distributed system during the stable phase.

[0094] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A Byzantine Fault-Tolerant RAFT consensus method based on deputy leader and threshold BLS signatures, characterized in that, include: S1: Designate a trusted authorized authority as the deputy leader node, and the remaining nodes as follower nodes; Each follower node periodically collects local performance metrics and sends them to the deputy leader node. The deputy leader node analyzes the local performance metrics of each follower node, calculates the performance score of each follower node, and broadcasts the results. S2: Each follower node listens to the leader node's heartbeat in real time. If a follower node does not receive the leader node's heartbeat for a preset time, it enters the candidate state. S3: The candidate node sends an election request to the deputy leader node, and the deputy leader node distributes the signature share to each node according to the election request through the threshold BLS signature key system and the Pedersen cryptographic commitment scheme. S4: After obtaining the signature share distribution information from the deputy leader, the candidate node sends a voting request to each node. After receiving the voting request from the candidate node, each node votes and returns the signature share to the candidate node. S5: Candidate nodes collect the signature shares returned by each node and generate a threshold BLS aggregate signature, and submit the BLS aggregate signature and election message to the deputy leader; S6: The deputy leader receives the BLS aggregated signature and election message from each candidate node, performs final verification and adjudication, and broadcasts the leader confirmation message; S7: After each node receives the leader's confirmation message broadcast by the deputy leader, it updates its own role to a follower node; S8: The leader node periodically sends heartbeat and log synchronization requests to all follower nodes. Each follower node continuously listens for the leader node's heartbeat and completes log synchronization.

2. The Byzantine Fault-Tolerant RAFT consensus method based on deputy leader and threshold BLS signature as described in claim 1, characterized in that, The calculation of the performance score for each follower node includes: S11: Follower Nodes In each statistics window Internally, local performance metrics are periodically collected and reported to the deputy leader node in real time; these local performance metrics include: computing power. Log processing throughput Stable online rate Average response time for log replication Heartbeat round-trip delay ; S12: The secondary leader node receives the metric reports from all follower nodes, summarizes them to obtain the entire set of follower nodes N, and processes the metrics. , and Perform positive normalization on the indicators and Perform reverse normalization; S13: The secondary leader node performs a weighted fusion of the normalized performance indicators of each follower node according to the preset weight parameters to obtain the initial performance score of each follower node. S14: Apply an exponential moving average to smooth the initial performance scores of each follower node to obtain the performance score of each follower node: in, Represents follower nodes Performance score; Indicates the previous statistics window Inner follower node Performance score; Represents follower nodes The initial performance score; Indicates the smoothing coefficient; S15: The deputy leader node generates a structured performance score table. : in, Represents the set of follower node IDs. This represents the set of performance scores for follower nodes; Indicates the version number of the statistics window; S16: Secondary Leader Node Pair Perform digital signature, and then digitally sign the document. Broadcast to all follower nodes; each follower node verifies the validity of the digital signature and caches the latest version. and .

3. The Byzantine Fault-Tolerant RAFT consensus method based on deputy leader and threshold BLS signature as described in claim 1, characterized in that, Step S2 includes: When the leader node is working normally, it continuously sends heartbeat packets to all follower nodes at a fixed period; each follower node maintains an independent heartbeat timer to monitor the leader's heartbeat in real time; if a follower node's heartbeat timer reaches a preset timeout threshold and does not receive a valid heartbeat packet from the leader during this period, the leader node is determined to be faulty / out of contact; the follower node whose heartbeat timeout has occurred performs a local state update and officially enters the candidate state, as follows: Character Update: ; Term of office update: ; This indicates the current term number cached locally.

4. The Byzantine Fault-Tolerant RAFT consensus method based on deputy leader and threshold BLS signature as described in claim 1, characterized in that, Step S3 includes: S31: Candidate node A sends an election request to the deputy leader node. ; in, Indicates the term of office. Represents candidate nodes ID; This represents the index of the last log entry on the candidate node's local machine. This represents the term number in the last log entry on the candidate node's local machine. S32: The deputy leader node receives an election request. Then, from the local cache Read the performance score of candidate A With the present Constructing a unique election message that prevents replay. : in, Represents a random number. Represents a timestamp; S33: The secondary leader node uses a threshold BLS signature private key to... Obtain by signing According to the total number of follower nodes use Secret sharing algorithm will Cut into Individual signature share Threshold BLS signatures require at least the following collections: Individual shares can be aggregated into a valid signature. The preset threshold value; S34: The deputy leader node, based on the Pedersen cryptographic commitment scheme, assigns a share of signatures to each node. Calculate the corresponding commitment value separately. ; S35: The deputy leader is each follower node in the network. Distribute unified data packets: in, for The hash value.

5. The Byzantine Fault-Tolerant RAFT consensus method based on deputy leader and threshold BLS signature as described in claim 3, characterized in that, Step S4 includes: S41: After obtaining the relevant information on the distribution of signature shares from the deputy leader, candidate node A sends a voting request to all nodes in the cluster. : S42: Each node receive Then, the verification will be strictly carried out in the following order. If any step fails, the application will be rejected directly and the share will not be returned: S4-01 Term-of-Service Check: If requested Refuse; if Update local ; S4-02 Share Validation: Retrieve from local cache and Through Pedersen commitment value verify Whether or not If the match is valid and has not been tampered with, the verification will be rejected if it fails. S4-03Raft log age determination: Compare the candidate node log with the local log. First, compare the term number of the last log entry. If the term numbers are the same, compare the index. If the candidate log is outdated, reject it. S4-4 Performance Threshold Determination: From Local Cache Read Check The version number should match the one in the ElectionMsg; if , Set a preset performance threshold for the system and reject the request. S4-5 Priority Assessment for Candidates: Priority is calculated for candidates according to the following rules: Priority given to those with higher experience levels → Priority given to those who update the logs → The smaller one takes precedence; if the local best candidate is empty, or if A has a higher priority than the local best candidate, then the local best candidate is updated to A, and the voter is A. S43: After all verification steps are passed, the node The signature share cached locally Return the share to candidate node A; if verification fails, reject the application directly and do not return any share.

6. The Byzantine Fault-Tolerant RAFT consensus method based on deputy leader and threshold BLS signature as described in claim 5, characterized in that, Step S5 includes: S51: Candidate node A receives the signature shares returned by each node. For each share, perform format and source validation one by one, filter out invalid shares, and record the set of valid shares. ; S52: Real-time statistics of the number of valid shares ,when At that time, the candidate invokes the threshold BLS aggregation signature algorithm, taking the effective share set and the original election message as input, to generate a valid aggregation signature. : Candidate node A packages the election message and aggregate signature, and submits the final election request to the deputy leader node. The submission content is as follows: The deputy leader is requested to carry out the final verification and ruling.

7. The Byzantine Fault-Tolerant RAFT consensus method based on deputy leader and threshold BLS signature as described in claim 6, characterized in that, Step S6 includes: the deputy leader receiving submissions from candidates. Then, the following steps will be strictly reviewed; if any step fails, the candidate will be rejected: S61: Verification using threshold BLS public key PK If the signature of ElectionMsg fails to be verified, it will be rejected outright. S62: From the latest local version Read candidate nodes Check and The version numbers in the two files are consistent; if ; S63: The deputy leader maintains a cache of candidate priorities for the current term. If the best priority candidate node has been recorded, and the current candidate node has a higher priority than the recorded best priority candidate, then the current candidate node is updated to the best priority candidate node; otherwise, it is rejected. Finally, the candidate node with the highest priority for the current term is retained as the leader node. S64: For the leader node that passed the final ruling. The deputy leader broadcasts a leader confirmation message to all nodes in the cluster. : in, express The hash value.

8. The Byzantine Fault-Tolerant RAFT consensus method based on deputy leader and threshold BLS signature as described in claim 7, characterized in that, Step S7 includes: S71: Any node receives a broadcast from the secondary leader. Then, first compare the messages in the message. With local ;like If a message is deemed expired, it will be discarded without further processing. S72: After the term verification is valid, all nodes perform a local state update: Synchronization is in the message And permanently record the leader's identity during this term. ; S73: If the node's own identifier is... In unison, each node updates its own role to leader, and all other nodes are uniformly updated to follower; S74: All nodes clear the temporary cache related to the election during the current term, release resources and prepare for the subsequent election.

9. The Byzantine Fault-Tolerant RAFT consensus method based on deputy leader and threshold BLS signature as described in claim 8, characterized in that, Step S8 includes: S81: The new leader node A sends heartbeats and log append requests to all follower nodes at fixed intervals; the heartbeat is used to maintain its leader status and let follower nodes confirm that the leader is working properly; the log append request carries the latest log information and leads the log synchronization of the entire network. S82: After receiving the log append request from the leader node, each follower node immediately performs log verification: if the local log is consistent with the leader log, it responds to the heartbeat normally and maintains the follower state; if the local log is missing or inconsistent, it actively sends a log synchronization request to the leader to obtain the missing log entries and appends them to the local log.

Images