An efficient Raft leader election method combining proof-of-work and proof-of-stake

Abstract

The present invention relates to the field of distributed consistency and discloses an efficient Raft leader election method combining proof-of-work and proof-of-stake. The main purpose of the present invention is to solve the problem that the shortcomings of the existing technology affect the consensus efficiency and fault tolerance of the Raft consensus algorithm. The main scheme includes modifying the status field information of the Raft node and adding the required node status information; defining the proof-of-work problem of the node's equity value, and selecting an alternative leader node based on the proof-of-work and proof-of-stake; scoring the priority of the node according to the status indicator data, calculating the priority score, and the leader node establishing a node priority model based on the node's priority score; and providing an improved leader election mechanism based on the node priority model and combining proof-of-work and proof-of-stake.

Description

Technical Field

[0001] The present invention relates to the field of distributed consistency, and in particular to an efficient Raft leader election method combining proof-of-work and proof-of-stake. Background Art

[0002] The Raft consensus algorithm was designed from the outset for ease of implementation and clear principles. In just a few years, it has become widely adopted in various distributed environments. As a simplified version of the Paxos protocol, the Raft algorithm sacrifices some performance. For practical applications in different scenarios, specific improvements can be made to the algorithm based on the specific circumstances. When a leader node in a distributed system fails and is unable to handle cluster services, a leader re-election is required to restore system operation. In the Raft consensus algorithm, some nodes cannot communicate with other nodes due to network failures, which significantly increases consensus time. Furthermore, the leader node in the Raft algorithm possesses strong leadership capabilities. If a leader node fails, the consensus time of the entire distributed system will be significantly increased.

[0003] In summary, the existing Raft algorithm leader election has the following shortcomings:

[0004] 1. As the number of system server nodes increases, the number of candidate nodes that can vote in the leader election process will also increase accordingly, which will cause the leader node election speed to decrease.

[0005] 2. Before the election, if a follower node cannot communicate with other nodes due to network problems, isolation will occur. However, these nodes can continue to trigger timeout elections, causing the Term value to continue to increase. After the isolation is removed, the node can continue to participate in the election, but because the node does not communicate with other nodes, the log queue is too old and the Term value is larger than that of other nodes in the cluster. If these outdated nodes win the election, the consensus time of the entire system will increase;

[0006] 3. Raft uses a strong leader mechanism to ensure data consistency. That is, the leader node undertakes much more tasks than the follower. It not only undertakes all log replication work in the system, but also needs to periodically send heartbeats to the follower nodes to maintain its leadership position. Therefore, the performance of the leader node and the network communication status are key factors affecting the overall performance of the system. Once the leader node is located on a slow node for a period of time, the performance of the entire system will slow down.

[0007] 4. If the leader node goes down due to a fault or network communication fails, the system will trigger a heartbeat check and re-elect. Due to the random timeout mechanism used by the Raft algorithm, multiple nodes may time out and become candidate nodes at the same time. In extreme cases, due to the division of votes, a single election may not be able to successfully select a leader node. Therefore, the system will experience multiple timeout elections, which will waste a lot of time.

[0008] The shortcomings of the above-mentioned existing technologies affect the consensus efficiency and fault tolerance of the Raft consensus algorithm. Therefore, the present invention proposes an efficient Raft leader election method that combines proof of work and proof of stake. Summary of the Invention

[0009] The purpose of the present invention is to solve the problem that the shortcomings of the existing technology will affect the consensus efficiency and fault tolerance of the Raft consensus algorithm.

[0010] An efficient Raft leader election method that combines proof-of-work and proof-of-stake, including:

[0011] Step S1: Add the required Raft node status information, Raft node is referred to as node, and modify the AppendEntries request message and response message;

[0012] Step S2: Define the proof-of-stake and proof-of-work problems of the node, solve the proof-of-work problem to obtain the proof-of-work, and the leader node selects a candidate leader node from the nodes based on the proof-of-work and proof-of-stake;

[0013] Step S3: Scoring the node's priority based on the status indicator data to obtain the node's priority score. The leader node then establishes a node priority model based on the node's priority score. (The status indicator data is calculated by the node itself, based on its current memory usage, network bandwidth usage, number of service requests, and the message sending time in the received heartbeat message.)

[0014] Step S4: Based on the node priority model, an improved leader election mechanism is given by combining proof of work and proof of stake.

[0015] In the above technical solution, in step S1, adding node status information includes the following steps:

[0016] S11: The node's status information is used to measure its priority as a leader node. It takes into account the node's performance, current working status, and network communication status. The status information includes: the node's remaining computing resources, the node's network communication status, the number of write service requests received by the node, and the node's priority value.

[0017] S12: While sending the Append Entries RPC request message to the follower node, where state information is involved, the follower node first updates its own state information, calculates the node priority value, and returns the result to the leader node. After receiving the log submission message, the leader node starts to update its own state information and calculate the priority value, and finally obtains the node priority score;

[0018] S13: Add relevant node status information to the Append Entries RPC request message and the Append Entries RPC response message, and add a strategy corresponding to the added node status information in the message processing algorithm to make a decision. The specific implementation is as follows: (The corresponding one is the recipient of the message, for example, the one that receives the heartbeat request message is the follower node, and the one that receives the heartbeat response message is the leader node; these decisions are mentioned in S4).

[0019] S131: Modify the Append Entries RPC request message, add the timestamp of the message, which is used to measure the heartbeat message delay between the follower node and the leader node, and add the network communication status N network , used for priority value calculation of leader node.

[0020] S132: Modify the Append Entries RPC response message and add a node priority value field;

[0021] S133: After receiving the Append Entries RPC request message from the leader, the follower node updates and calculates its own status information and calculates the priority value N based on the status information. value ;

[0022] S134: After receiving the Append Entries RPC response message from the follower node, the leader node records the priority value of the node.

[0023] In the above technical solution, in S2, selecting a candidate leader node from the nodes based on proof of work and proof of stake includes the following steps:

[0024] S21: Define the node's stake value logvalue. The greater the node's stake value, the lower the difficulty of becoming a candidate leader node. Under the same computing power, the probability of becoming a candidate leader node is higher. The calculation formula of the stake value logvalue is shown in (1):

[0025] logvalue=logterm*10 k +logindex (1)

[0026] Where logterm is the term number of the last log entry of the node, longindex is the index value of the last log entry of the node, and k represents the order of magnitude of the difference between different logterms. The calculation formula of k is shown in (2):

[0027] k=m-leaderterm+logterm (2)

[0028] Where leaderterm represents the current leader term number, and m represents the maximum difference between the term numbers of the last log entries of all nodes, that is, the maximum term number minus the minimum term number;

[0029] S22: Define the proof-of-work problem. The proof-of-work problem is used to implement verifiable computing tasks. Solving the proof-of-work problem involves two roles: the prover and the verifier. The prover provides the verifier with a proof-of-work, which is used to prove that the prover has completed a specified number of computing tasks within a period of time. The number of computing tasks depends on the node's stake value and a preset target value. The probability of each node completing the problem and becoming a candidate leader node can be determined by its computing resources.

[0030] S221: The node continuously tries to hash the random value Nonce to find a random value Nonce that meets the conditions, so that the hash value NodeHash calculated by the node is less than the preset target value Target. At the same time, the proof of stake is improved by multiplying the target value unified by all nodes by the node's stake value, so that the hash difficulty of each node is different. The expression of the improved proof of work problem is shown in (3):

[0031] NodeHash=Hash(Nonce)<Target*logvalue (3)

[0032] Hash represents hash calculation. The first n bits of the hash value are zero. The size of n is equal to the size of the difficulty value. Different nodes have different calculation difficulties. The larger the equity value, the lower the calculation difficulty.

[0033] S222: The leader node is used as the verifier and the follower node as the prover. After the leader node is successfully elected and starts working, it continuously broadcasts the proof-of-work puzzle, including the message of starting to solve the puzzle and the target value unified by all nodes. After receiving the proof-of-work puzzle, the follower node solves the puzzle and replies to the leader node after completing the solution, returning the random value Nonce.

[0034] S23: When the leader node receives the reply from the follower node that the problem is solved, it verifies it. If expression (3) is satisfied and the candidate leader node is empty, the node that passes the verification is set as the candidate leader node, and the identity of the candidate leader node is informed to all follower nodes. The follower nodes stop solving the problem.

[0035] In the above technical solution, in S3, a detailed description of establishing a node priority model is as follows.

[0036] S31: Update the remaining memory size R of the node n , the remaining computing resources N of the computing node calculate ;

[0037] S311: Calculate the remaining memory of the nth node in the total memory S n Percentage Z in n , and its formula is shown in (4):

[0038]

[0039] S312: Calculate the remaining computing resources N of each node caculate , and its calculation formula is shown in (5):

[0040]

[0041] S32: Update network bandwidth usage P n , calculate the network communication status index N of the node network ;

[0042] S321: Calculate the i-th heartbeat message delay D between the follower node and the leader node i , the calculation formula is shown in (6):

[0043] D i =F i -L i (6)

[0044] Among them L i is the sending time of the leader node i, F i is the time received by the follower node;

[0045] S322: Calculate the heartbeat message delay variation V n , the calculation formula is shown in (7):

[0046] V n =|D last -D new | (7)

[0047] Among them D lastis the previous heartbeat message delay, D new This is the heartbeat message delay.

[0048] S323: Calculate the network communication status index N of each node network , the calculation formula is shown in (8):

[0049]

[0050] Among them B n is the bandwidth of the node;

[0051] S33: Update the number of write service requests N received by the node rwTimes , calculate the node priority value N according to the above status data indicators value , the calculation formula is shown in (9):

[0052] N value =α*N calculate +β*N network +γ*N rwTimes (9)

[0053] The coefficients α, β, and y represent the proportional coefficients of different node performance indicators. The proportional coefficients of different indicators can be adjusted according to actual conditions, where α+β+γ=1.

[0054] S34: After receiving the Append Entries RPC response message from the follower, the leader node records the priority value of the node and establishes a node priority model;

[0055] S341: After receiving the write service from the client, the leader node appends the instruction to its local log. At this time, the log is in the uncommitted state. Then the leader sends an Append Entries RPC request message to all follower nodes. After waiting for half of the messages to succeed, the local log will become committed.

[0056] S342: When a log becomes committed, it means that the priority values ​​of more than half of the follower nodes have been updated. At this time, the leader updates its own priority value, and the leader's network communication status N network The calculation formula is shown in (10):

[0057]

[0058] Among them, Ni network Indicates the network communication status of the i-th follower node, m is the number of follower nodes;

[0059] S343: Convert the priority value of the i-th node into the corresponding priority score N i score, the calculation formula is shown in (11):

[0060] N i score =N i value / N Max value *100 (11)

[0061] S344: The nodes are divided into four priority levels according to the priority scores, and a node priority model is established.

[0062] In the above technical solution, in S4, the improved Raft leader election mechanism is described in detail as follows.

[0063] S41: If the leader node is empty and the candidate leader node is also empty, the Raft leader election process begins. The node that obtains the majority of votes becomes the leader. If the leader node is empty but the candidate leader node is not empty, the candidate leader node directly becomes the leader.

[0064] S42: After the leader node is selected, the leader node starts sending Append EntriesRPC request messages to all follower nodes as heartbeat messages to maintain its leadership status and append logs to the follower nodes.

[0065] S43: The candidate leader is empty, and the leader node starts to select a candidate leader node;

[0066] S431: Leader node broadcast combined with proof of stake to improve the proof of work problem NodeHash;

[0067] S432: The follower node that receives the proof-of-work puzzle starts solving the puzzle and returns a solution success message to the leader node after successfully solving the puzzle.

[0068] S433: The leader node receives the reply message and verifies it. If the reply message passes the verification, the leader node broadcasts the candidate leader identity to all follower nodes and tells them to stop solving the problem.

[0069] S44: After receiving the heartbeat message from the leader, the follower node updates and calculates its own status information and calculates the priority value N based on the status information. value ;

[0070] S441: The follower node receives the heartbeat message and determines whether the message contains a log entry. If so, it copies the log information and proceeds to the next step. Otherwise, it resets the timeout election timer to 0 and continues to wait for the heartbeat message.

[0071] S442: The follower node copies the log information;

[0072] S443: Calculate the priority value according to S2, reset the election timeout timer to 0, and return an Append EntriesRPC response message;

[0073] S45: After receiving the Append Entries RPC response message from the follower node, the leader node records the priority value of the node;

[0074] S46: When a log entry changes to committed, the leader calculates the priority score, establishes a node priority model, and makes a proactive yielding decision. If there is a node with a higher priority than the leader, the leader proactively yields to the node with the higher priority and hands the node priority model over to the new leader for maintenance.

[0075] S47: When the leader node fails and crashes or network communication fails, and the follower node does not receive the heartbeat message from the leader node within the election timeout, a new round of leader election begins;

[0076] S471: If the candidate leader node is not empty, the candidate leader node directly becomes the leader.

[0077] Start executing step S42;

[0078] S472: Otherwise, step S41 is executed. If a leader is successfully elected within one term, the current leader election ends.

[0079] S473: When there are two or more candidate nodes in the cluster, resulting in a split vote, the priorities of the two nodes are compared, and the node with the higher priority is elected.

[0080] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are:

[0081] 1. This invention defines a new "alternative leader" state, which is selected by solving problems in advance. When the leader fails, it directly becomes the leader of the new term. This solves the problem that as the number of system nodes increases, the number of candidate nodes that can participate in the election increases, resulting in excessively long election times.

[0082] 2. This invention innovatively defines the node's stake value and proof-of-work problem, combining proof-of-work with proof-of-stake. It comprehensively considers the node's computing power and the node's log update rate, significantly reducing the probability of outdated nodes winning elections and shortening the overall system consensus time. Furthermore, the proof-of-work mechanism ensures that a node's computing power is determined by its problem-solving speed, thus preventing malicious node behavior to a certain extent.

[0083] 3. This invention innovatively proposes a scoring strategy that comprehensively considers the node's performance over a period of time, remaining computing resources, and network communication conditions to evaluate the node that is more suitable to become the leader. By actively giving up the leader position, the leader is placed on a fast node as much as possible, maintaining the performance stability of the entire system.

[0084] 4. This invention takes into account the possible splitting of votes during the election process and the solution of multiple re-election of leaders by the system. Based on the node priority model, the leader node can be selected in at most one timeout election. BRIEF DESCRIPTION OF THE DRAWINGS

[0085] Figure 1 A block diagram of an efficient Raft leader election method combining proof-of-work and proof-of-stake provided for the implementation of the present invention;

[0086] Figure 2 Improved Raft node state transition diagram provided for implementation of the present invention;

[0087] Figure 3 A structural diagram of the improved leader election mechanism provided for the implementation of the present invention. DETAILED DESCRIPTION

[0088] The following is a detailed description of the embodiments of the present invention. Although the present invention will be described and illustrated in conjunction with certain specific embodiments, it should be noted that the present invention is not limited to these embodiments. On the contrary, modifications or equivalent substitutions of the present invention are intended to fall within the scope of the claims of the present invention.

[0089] In addition, in order to better illustrate the present invention, numerous specific details are given in the following detailed description. It will be understood by those skilled in the art that the present invention can also be implemented without these specific details.

[0090] The present invention will be further described below in conjunction with specific embodiments.

[0091] Set up a system consisting of five nodes Node1 to Node5.

[0092] 1. The leader node is Node1, and the latest follower node priority value saved by Node1 is The corresponding status indicator data when returning the node priority value is shown in the following table:

[0093]

[0094] Assuming that the memory of the follower nodes is 1GB and the network bandwidth is 10MB / s, the priority value calculation indicator data of each node is calculated as shown in the following table:

[0095]

[0096] Unify the order of magnitude of each indicator, and the remaining computing resources N caculate / 100, network communication status indicator N network *10, number of write service requests N rwTimes *10, let α = 0.4, β = 0.4, γ = 0.2, and calculate the priority value of each follower node as shown in the following table:

[0097] Node2 Node3 Node4 Node5 <![CDATA[Priority value N value > 9.34 13.54 53.00 3.94

[0098] Assume that a log of the leader becomes committed at this time, indicating that the priority values ​​of half of the follower nodes have been updated. At this time, the leader updates its own status indicator and calculates the priority value. The remaining computing resources N after the leader unifies the level caculate =32, network communication status indicator N network =19.8, number of write service requests N rwTimes =100, then the priority value is N value =40.72, convert the node priority value into the corresponding priority score N score As shown in the following table

[0099]

[0100] The priority of [0, 25] is divided into 1, the priority of (25, 50] is divided into 2, the priority of (50, 75] is divided into 3, and the priority of (75, 100] is divided into 4. The node priorities after division are shown in the following table:

[0101] Node1 Node2 Node3 Node4 Node5 Priority 4 1 2 4 1

[0102] The priority of Node1 is 4, and there is no node with a higher priority, so it does not need to give way.

[0103] 2. Assume that the system reconfirms the leader node at this time, and the backup leader node takes office directly. At this time, the backup leader is empty, the leader node is Node3, and the leader term number is 9, that is, leaderterm=9. At this time, there are two follower nodes Node1 and Node2. The last log term number of Node1 is logterm=9, and the index number is Logindex=40. The last log term number of Node2 is logterm=8, and the index number is longindex=5. Assuming that the maximum difference in the term of log entries does not exceed 2, the equity values ​​logvalue of Node1 and Node2 are calculated according to formulas (1) and (2): 940 and 85 respectively.

[0104] Assuming that all nodes have a unified target value of Target = 700, then the target value for Node1 is 658000, which is converted into hexadecimal as OxaOa50, and the target value for Node2 is 59500, which is converted into hexadecimal as Oxe86c. Assuming that the complete hash length is 8 bits, the proof-of-work problems for Node1 and Node2 are:

[0105] Node1=Hash(Nonce)<0x000b7980

[0106] Node2=Hash(Nonce)<0x0000e86c

[0107] As can be seen from the above example, when the term numbers of the last log entries of two nodes differ by 1, the stake values ​​calculated according to formulas (1) and (2) will differ by an order of magnitude, and the target value of the final proof-of-work puzzle will differ by one 0. In this way, under the same computing power conditions, the node with a larger term number will have a greater probability of solving the puzzle and is more likely to be selected as the candidate leader node.

Claims

1. An efficient Raft leader election method combining proof of work and proof of stake, characterized by: include: Step S1: Add the required Raft node status information, and modify the Append Entries request message and response message. Step S2: Define the proof-of-stake and proof-of-work problems of the node, solve the proof-of-work problem to obtain the proof-of-work, and the leader node selects a candidate leader node from the nodes based on the proof-of-work and proof-of-stake; Step S3: Score the priority of the node according to the status indicator data to obtain the priority score of the node. The leader node establishes a node priority model according to the priority score of the node; Step S4: Based on the node priority model, an improved leader election mechanism is given by combining proof of work and proof of stake; In step S2, selecting a candidate leader node from the nodes based on proof of work and proof of stake includes the following steps: Step S21: Define the node's stake value logvalue. The greater the node's stake value, the lower the difficulty of becoming a candidate leader node. Under the same computing power, the probability of becoming a candidate leader node is higher. The calculation formula of the stake value logvalue is shown in (1): (1) Where logterm is the term number of the last log entry of the node, longindex is the index value of the last log entry of the node, and k represents the order of magnitude of the difference between different logterms. The calculation formula of k is shown in (2): (2) Where leaderterm represents the current leader term number, and m represents the maximum difference between the term numbers of the last log entries of all nodes, that is, the maximum term number minus the minimum term number; Step S22: Define a proof-of-work problem. The proof-of-work problem is used to implement a verifiable computing task. Solving the proof-of-work problem involves two roles: the prover and the verifier. The prover provides the verifier with a proof-of-work, which is used to prove that the prover has completed a specified number of computing tasks within a period of time. The number of computing tasks depends on the node's stake value and a preset target value. The probability of each node completing the problem and becoming a candidate leader node is determined by its computing resources. Step S221: The node continuously attempts to hash the random value Nonce to find a random value Nonce that meets the conditions, so that the hash value NodeHash calculated by the node is less than the preset target value Target. At the same time, the proof of stake is improved by multiplying the target value unified by all nodes by the node's stake value, so that the hash difficulty of each node is different. The expression of the improved proof of work problem is shown in (3): (3) Hash represents the hash calculation. The first n bits of the hash value are zero. The size of n is equal to the size of the difficulty value. Different nodes have different calculation difficulties. The larger the equity value, the lower the calculation difficulty. Step S222: The leader node is used as the verifier and the follower node is used as the prover. After the leader node is successfully elected and starts working, it continuously broadcasts the proof-of-work puzzle, including the message of starting to solve the puzzle and the target value unified by all nodes. After receiving the proof-of-work puzzle, the follower node solves the puzzle and replies to the leader node after completing the solution, returning the random value Nonce. Step S23: When the leader node receives the reply from the follower node that the problem is solved, it verifies it. If expression (3) is satisfied and the candidate leader node is empty, the node that passes the verification is set as the candidate leader node, and the identity of the candidate leader node is informed to all follower nodes, and the follower nodes stop solving the problem.

2. An efficient Raft leader election method combining proof of work and proof of stake according to claim 1, characterized in that: In step S1, adding node status information includes the following steps: Step S11: The node's status information is used to measure its priority as a leader node, taking into account the node's performance, current working status, and network communication status. The status information includes: the node's remaining computing resources, the node's network communication status, the number of write service requests received by the node, and the node's priority value; Step S12: While sending the Append Entries RPC request message to the follower node, where state information is involved, the follower node first updates its own state information, calculates the node priority value, and returns the result to the leader node. After receiving the log submission message, the leader node starts to update its own state information and calculate the priority value, and finally obtains the node priority score; Step S13: Add relevant node status information to the Append Entries RPC request message and the Append Entries RPC response message, and add a policy corresponding to the added node status information to the message processing algorithm to make a decision. The specific implementation is as follows: Step S131: Modify the Append Entries RPC request message, add the timestamp of the message, which is used to measure the heartbeat message delay between the follower node and the leader node, and add the network communication status , used for leader node priority value calculation; Step S132: Modify the Append Entries RPC response message and add a node priority value field; Step S133: After receiving the Append Entries RPC request message from the leader, the follower node updates and calculates its own state information and calculates the priority value based on the state information. ; Step S134: After receiving the Append Entries RPC response message from the follower node, the leader node records the priority value of the node.

3. An efficient Raft leader election method combining proof of work and proof of stake according to claim 1, characterized in that: In step S3, a detailed description of establishing a node priority model is as follows: Step S31: Update the remaining memory size of the node , the remaining computing resources of the computing node ; Step S311: Calculate the remaining memory of the nth node in the total memory Percentage of , and its formula is shown in (4): (4) Step S312: Calculate the remaining computing resources of each node , and its calculation formula is shown in (5): (5) Step S32: Update network bandwidth usage , network communication status indicators of computing nodes ; Step S321: Calculate the i-th heartbeat message delay between the follower node and the leader node , the calculation formula is shown in (6): (6) in is the sending time of the leader node i, is the time received by the follower node; Step S322: Calculate the heartbeat message delay change , the calculation formula is shown in (7): (7) in is the previous heartbeat message delay, This is the heartbeat message delay; Step S323: Calculate the network communication status index of each node , the calculation formula is shown in (8): (8) in is the bandwidth of the node; Step S33: Update the number of write service requests received by the node , calculate the node priority value based on the above status data indicators , the calculation formula is shown in (9): (9) in The coefficient represents the proportional coefficient of different node performance indicators. The proportional coefficient of different indicators can be adjusted according to actual conditions. ; Step S34: After receiving the Append Entries RPC response message from the follower, the leader node records the priority value of the node and establishes a node priority model; Step S341: After receiving the write service from the client, the leader node appends the instruction to its local log. At this time, the log is in the uncommitted state. Then the leader sends an Append Entries RPC request message to all follower nodes. After waiting for half of the success messages, the local log will become committed. Step S342: When a log becomes submitted, it means that the priority values ​​of more than half of the follower nodes have been updated. At this time, the leader updates its own priority value, and the leader's network communication status The calculation formula is shown in (10): (10) in Indicates the network communication status of the i-th follower node, m is the number of follower nodes; Step S343: Convert the priority value of the i-th node into the corresponding priority score , the calculation formula is shown in (11): (11) S344: The nodes are divided into four priority levels according to the priority scores, and a node priority model is established.

4. An efficient Raft leader election method combining proof of work and proof of stake according to claim 1, characterized in that: In step S4, the improved Raft leader election mechanism is described in detail as follows: Step S41: If the leader node is empty and the candidate leader node is also empty, the Raft leader election process begins. The node that obtains the majority of votes becomes the leader. If the leader node is empty but the candidate leader node is not empty, the candidate leader node directly becomes the leader. Step S42: After the leader node is selected, the leader node starts sending Append EntriesRPC request messages to all follower nodes as heartbeat messages to maintain its leadership status and append logs to the follower nodes; Step S43: If the candidate leader is empty, the leader node starts to select a candidate leader node; Step S431: The leader node broadcasts the improved proof-of-work problem combined with proof-of-stake ; Step S432: The follower node that receives the proof-of-work puzzle begins solving the puzzle and returns a successful solution message to the leader node after successfully solving the puzzle. Step S433: The leader node receives the reply message and verifies it. If the reply message passes the verification, the leader node broadcasts the candidate leader identity to all follower nodes and tells them to stop solving the problem. Step S44: After receiving the heartbeat message from the leader, the follower node updates and calculates its own status information and calculates the priority value based on the status information. ; Step S441: The follower node receives the heartbeat message and determines whether the message contains a log entry. If so, it copies the log information and proceeds to the next step. Otherwise, it resets the election timer to 0 and continues to wait for the heartbeat message. Step S442: The follower node copies the log information; Step S443: Calculate the priority value according to S2, reset the election timeout timer to 0, and return an Append EntriesRPC response message; Step S45: After receiving the Append Entries RPC response message from the follower node, the leader node records the priority value of the node; Step S46: When a log entry changes to a committed state, the leader calculates the priority score, establishes a node priority model, and makes a proactive yielding decision. If there is a node with a higher priority than the leader, the leader proactively yields to the node with the higher priority and hands the node priority model over to the new leader for maintenance. Step S47: When the leader node fails, causing downtime or network communication failure, and the follower node does not receive the heartbeat message from the leader node within the election timeout period, a new round of leader election begins; Step S471: If the candidate leader node is not empty, the candidate leader node directly becomes the leader and step S42 is executed; Step S472: Otherwise, start executing step S41. If a leader is successfully elected within one term, the current leader election ends. Step S473: When there are two or more candidate nodes in the cluster, resulting in a split vote, the priorities of the two nodes are compared, and the node with the higher priority is elected.

Images