Block chain consensus method giving consideration to efficiency and security

Abstract

The invention provides a block chain consensus method considering efficiency and security, and belongs to the technical field of block chain consensus algorithms. The balance problem of a traditional block chain Raft consensus algorithm in the aspects of efficiency and Byzantine fault tolerance is solved; comprising the following steps: a leader election stage: in the leader election stage of a traditional Raft algorithm, combining a Schnorr protocol and a counting comparison mechanism to strengthen the leader election security, and the implementation steps are as follows: when a follower node votes to a candidate node, signing on a vote through the Schnorr protocol; in one round of election, the candidate node initiates counting comparison RPC so as to determine a final leader; in the differential log copying stage, the log copying stage of a traditional Raft algorithm is replaced with safe differential log copying, the leader node calculates the difference between the leader node and a follower node log copy and generates a differential log, and the follower node uses the differential log to update a local log copy; the method is applied to the alliance chain with numerous nodes.

Description

Technical Field

[0001] The present invention provides a blockchain consensus method that takes into account both efficiency and security, and belongs to the technical field of blockchain consensus algorithms. Background Art

[0002] To date, many consensus algorithms have emerged in the blockchain field, which can be divided into Byzantine Fault Tolerance (BFT) and Crash Fault Tolerance (CFT) protocols. Due to the open nature of the blockchain network, the blockchain consensus protocol needs to resist interference from malicious nodes, so it belongs to the BFT protocol. The Raft algorithm proposed in 2014 belongs to the CFT protocol. Because it is easy to understand, highly available and highly consistent, it is often used to help enterprises maintain data consistency among nodes in the blockchain, especially in private chains. However, the Raft algorithm has certain limitations.

[0003] First, as the number of nodes increases, split votes may lead to election delays and increased communication overhead, reducing the efficiency of blockchain consensus. Second, the Raft algorithm cannot tolerate Byzantine errors and may suffer from fraud by malicious nodes, affecting the authenticity of elections and log entries. Therefore, although the Raft algorithm has good performance and application in private chains, its limitations become more significant when it comes to consortium chains, especially when there are potential Byzantine nodes.

[0004] In terms of improving the Raft algorithm, there is still a balance between efficiency and Byzantine fault tolerance, and it is difficult to ensure efficient operation while effectively preventing Byzantine attacks. On the one hand, optimizing the Raft algorithm to improve efficiency will lead to insufficient Byzantine fault tolerance; on the other hand, although adding a BFT module can enhance the algorithm's defense against malicious nodes, it will increase computing and communication costs, affecting the overall performance of the algorithm. Summary of the invention

[0005] In order to solve the balance problem of the traditional blockchain Raft consensus algorithm in terms of efficiency and Byzantine fault tolerance, the present invention proposes a blockchain consensus method that takes into account both efficiency and security.

[0006] In order to solve the above technical problems, the technical solution adopted by the present invention is: a blockchain consensus method that takes into account both efficiency and security, based on the Raft algorithm, comprising the following steps: S1: Leader election phase: In the leader election phase of the traditional Raft algorithm, the Schnorr protocol and vote comparison mechanism are combined to enhance the security of leader election. The implementation steps include: S1.1: When a follower node votes for a candidate node, it signs the ballot using the Schnorr protocol. S1.2: In a round of election, the candidate node initiates a vote counting and comparison RPC to determine the final leader; S2: Differential log replication phase: Secure differential log replication is used to replace the log replication phase of the traditional Raft algorithm. The leader node calculates the difference between the log copy and the follower node and generates a differential log. The follower node applies the differential log to update the local log copy.

[0007] The specific implementation steps of step S1.1 are as follows: The system starts or triggers the Raft algorithm leader election event; Node initialization: Initialize all nodes; Schnorr generates key pairs: All nodes use the Schnorr signature algorithm to generate key pairs for subsequent encryption and decryption operations; when a follower node votes for a candidate node, it needs to sign the ballot and broadcast the node public key on the blockchain network; Node legitimacy verification: When a follower node votes for a candidate node, it needs to sign the ballot and broadcast the node public key on the blockchain network; then verify whether the signature is legitimate, which is used to discover Byzantine nodes in the cluster and exclude them from the leader election.

[0008] The specific implementation steps of step S1.2 are as follows: Candidate nodes initiate vote comparison requests: Candidate nodes in the election initiate vote comparison requests to other candidate nodes to obtain their own support status; Other candidate nodes process requests: Other candidate nodes process received vote comparison requests; Voting: Each legitimate follower node votes based on the support of the candidate node; Receive responses and count votes: Collect the votes from all follower nodes and count them to determine the winner of the election; Elected legitimate leader: Based on the voting results, the candidate node whose votes meet the requirements is elected as the legitimate leader node.

[0009] When a voting request is initiated, the candidate node will use the private key to sign the voting request message, obtain the signature, and send the signature to other candidate nodes in the cluster in parallel. Other candidate nodes receive the voting request from the follower node and verify the signature. If the verification is true, it means that the signature is valid and the legitimacy of the follower node is true. The follower node continues to vote, and the number of votes of the requester increases. There will be four election results in the end: 1) The candidate node is legitimate and obtains more than half of the votes to win the election and become the leader node; 2) Other candidate nodes are legitimate and win the election. After receiving the heartbeat of the new leader node, if the term number of the new leader node is not less than its current term number, it returns from the candidate state to the follower state; 3) If there is no winner, a new round of voting will begin. If a winner is still not determined after a period of waiting, each candidate node will increase its term number after a random election timeout and start a new round of voting; 4) The candidate node is judged to be illegal, the cluster excludes the illegal node, and other legal nodes continue the leader election process.

[0010] In step S1.2, in one round of election, the candidate node is allowed to actively compare votes with other candidate nodes to determine the winner in advance after obtaining the majority of votes, which is used to determine the qualification review of the final candidate node.

[0011] The specific implementation steps of step S2 are as follows: Receiving client commands: Once a legitimate leader node is elected, the leader node will assume the important responsibility of receiving and processing instructions from the client; the leader node converts the client command into a new log entry, each of which contains the command, term number and corresponding index; Log entry hash calculation: The leader node calculates a hash value for each log entry, which is a hash of the content and metadata of the log entry; Log entry batch signing: The leader node uses its own private key to sign a log batch containing log entries and their hash values, and sends the signature and the log to the follower nodes; Generate differential logs: When a follower node requests log replication, the leader node calculates the difference with the follower node's log copy and generates a differential log; Follower nodes receive differential logs: Follower nodes receive differential logs and their signatures from leader nodes; Differential log verification: Follower nodes verify the signature using the leader node’s public key to ensure the authenticity and integrity of the differential log; Follower nodes calculate the hash of the received log entry and compare it with the hash in the signature to ensure that the data has not been tampered with during transmission; Log update and synchronization: Follower nodes apply the verified differential log entries to their own log copies, and then follower nodes send synchronization confirmation messages to the leader node, indicating that they have successfully updated their log copies; Log consistency check and fault handling: The leader node continues to listen to client requests and internal state changes, and generates new differential logs for replication; if the leader node fails or loses contact, the system will trigger a new leader election process.

[0012] A blockchain consensus device that takes into account both efficiency and security, including an enhanced leader election module and a secure differential log replication module, wherein the enhanced leader election module is used to determine a leader node on a server side in a blockchain based on a Schnorr election security mechanism and a vote counting comparison mechanism, and the secure differential log replication module is used to perform differential log replication on received client instructions according to the elected leader node; The Schnorr election security mechanism is as follows: when a follower node votes for a candidate node, it needs to sign the ballot; The vote counting and comparison mechanism is: in one round of election, a candidate node is allowed to actively compare votes with other candidate nodes after obtaining a majority of votes.

[0013] The secure differential log replication module adopts a secure differential log replication method to replace the complete log entry replication method of the traditional Raft algorithm. The specific steps are as follows: (1) The leader node calculates a hash value for each log entry and signs a log batch containing the log entry and its hash value; (2) When a follower node requests log replication, the leader node calculates the difference between the follower node’s log copy and generates a differential log. The differential log contains the necessary log entries and their hash values, but does not contain a signature. (3) The leader node sends the differential log and the corresponding signature to the follower node; (4) After receiving the differential log and signature, the follower node uses the leader node’s public key and the Schnorr protocol’s verification function to verify the validity of the signature. If the signature verification succeeds, the follower node applies the differential log to update the local log copy to ensure that it remains consistent with the leader node’s log copy.

[0014] An electronic device comprises: a processor; and a memory arranged to store computer executable instructions, wherein when the executable instructions are executed, the processor executes the blockchain consensus method that takes into account both efficiency and security.

[0015] A computer-readable storage medium stores one or more programs, which, when executed by an electronic device including multiple application programs, enable the electronic device to execute the blockchain consensus method that takes into account both efficiency and security.

[0016] The beneficial effects of the present invention compared to the prior art are as follows: by integrating the Schnorr digital signature and the vote comparison mechanism into the Raft algorithm, not only the security of leader election is enhanced, but also the election efficiency is significantly improved. The adoption of secure differential log replication effectively reduces the consensus delay in the log replication stage, ensures the security of log replication, and improves system throughput compared to the traditional full log entry replication. This enables the SDRaft algorithm to achieve a better balance between Byzantine fault tolerance and communication overhead, and is particularly suitable for alliance chain environments with many nodes and Byzantine malicious nodes. The SDRaft algorithm takes into account the scalability of the system, allowing it to be adapted to a wider range of blockchain application scenarios without sacrificing performance and security. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The present invention will be further described below in conjunction with the accompanying drawings: Figure 1 It is a structural schematic diagram of the system of the present invention; Figure 2 Flow chart of the method of the present invention. DETAILED DESCRIPTION

[0018] like Figure 1-2 As shown, the present invention provides a blockchain consensus method that takes into account both efficiency and security, which is an improvement on the Raft consensus algorithm. The present invention refers to the improved algorithm as the SDRaft algorithm. The SDRaft algorithm is built on the traditional Raft consensus mechanism and retains the core characteristics of the Raft algorithm, such as the role allocation of leaders, candidates, and followers, as well as the consistency guarantee of log replication and state machines. SDRaft mainly improves the Raft algorithm in two modules: strengthening the leader election module and the secure differential log replication module. First, in the leader election stage, the SDRaft algorithm combines the Schnorr protocol and the vote comparison mechanism to strengthen the security of leader election and optimize its efficiency; secondly, in the log replication stage, secure differential log replication is used to replace the traditional complete log entry replication, and is committed to achieving efficient replication while ensuring data security.

[0019] The implementation process of the method of the present invention is as follows Figure 2 As shown, the following steps are included: S1: Leader election phase. The specific implementation steps are as follows: 1) The system starts or triggers the Raft algorithm leader election event.

[0020] 2) Node initialization: At the beginning of the election process, all nodes can be considered legal, that is, they meet the qualifications and conditions for participating in the election. All nodes are initialized, including necessary status updates, etc.

[0021] 3) Schnorr generates key pairs: All nodes use the Schnorr signature algorithm to generate key pairs for subsequent encryption and decryption operations.

[0022] 4) Node legitimacy verification: When a follower node votes for a candidate node, it needs to sign the ballot and broadcast the node public key on the blockchain network. The signature is then verified to be legitimate, which is used to discover Byzantine nodes in the cluster and exclude them from the leader election.

[0023] 5) Candidates initiate vote comparison requests: Candidate nodes in the election initiate vote comparison requests to other candidate nodes to obtain their own support status.

[0024] 6) Other candidate processing requests: Other candidate nodes process the received vote comparison requests.

[0025] 7) Voting: Each legitimate follower node votes based on the support for the candidate.

[0026] 8) Receive responses and count votes: Collect the voting results of all nodes and count them to determine the winner of the election.

[0027] 9) Elected as a legitimate leader: Based on the voting results, the candidate node whose votes meet the conditions (such as votes ≥ (N+1) / 2) is elected as the legitimate leader node.

[0028] S2: Secure differential log replication: After the leader election is completed, the secure differential log replication phase begins. The specific implementation steps are as follows: 1) Receiving client commands: Once a legitimate leader node is elected, the leader node will assume the important responsibility of receiving and processing instructions from clients. The leader node converts these instructions into a new log entry, each of which contains a command, term number, and corresponding index.

[0029] 2) Log entry hash calculation: The leader node calculates a hash value for each log entry, which is a hash of the content and metadata of the log entry.

[0030] 3) Log entry batch signing: The leader node uses its own private key to sign a log batch containing log entries and their hash values, and sends the signature and the log to the follower nodes.

[0031] 4) Generate differential log: When a follower node requests log replication, the leader node calculates the difference with the follower node's log copy and generates a differential log.

[0032] 5) Followers receive differential logs: Follower nodes receive differential logs and their signatures from leader nodes.

[0033] 6) Differential log verification: Follower nodes verify the signature using the leader node’s public key to ensure the authenticity and integrity of the differential log. Follower nodes calculate the hash of the received log entry and compare it with the hash in the signature to ensure that the data has not been tampered with during transmission.

[0034] 7) Log update and synchronization: Follower nodes apply the verified differential log entries to their own log copies. Follower nodes send synchronization confirmation messages to the leader node, indicating that they have successfully updated their log copies.

[0035] 8) Log consistency check and fault handling: The leader node continues to listen to client requests and internal state changes, and generates new differential logs for replication. If the leader node fails or loses contact, the system will trigger a new leader election process. During the election, the system will enter read-only mode or suspend new write operations.

[0036] The present invention also proposes a blockchain consensus device that takes into account both efficiency and security, including an enhanced leader election module and a secure differential log replication module. The enhanced leader election module has made two key improvements in the leader election stage: first, the Schnorr election security mechanism is introduced to enhance the security of the election process. Second, a vote counting comparison mechanism is designed to improve the efficiency of the election. Specifically: (1) Schnorr election security mechanism When a follower node votes for a candidate node, it needs to sign the ballot. This mechanism requires the node to first generate a Schnorr signature key pair, and then broadcast its public key to other nodes in the cluster to declare its legitimacy. When a voting request is initiated, the candidate node will use the private key to sign the voting request message, obtain the signature, and send the signature to other candidate nodes in the cluster in parallel. Other candidate nodes receive the voting request from the follower node and verify the signature. If the verification is true, it means that the signature is valid and the legitimacy of the follower node is true. The follower node can continue to vote, and the number of votes of the requester increases. There will be four election results in the end: 1) The candidate node is legitimate and obtains more than half of the votes to win the election and become the leader node.

[0037] 2) Other candidate nodes are legitimate and win the election. After receiving the heartbeat of the new leader node, if the term number of the new leader node is not less than its current term number, it returns from the candidate state to the follower state.

[0038] 3) If there is no winner, a new round of voting will begin. If a winner is still not determined after a period of waiting, each candidate node will increase its term number after a random election timeout and start a new round of voting.

[0039] 4) The candidate node is judged to be illegal. The cluster excludes the illegal node, and other legal nodes continue the leader election process.

[0040] (2) Vote counting and comparison mechanism In the SDRaft algorithm, a vote comparison RPC (VoteComparison RPC) initiated by a candidate node is designed: in a round of elections, a candidate node is allowed to actively compare votes with other candidate nodes after obtaining a majority of votes to determine the winner in advance, thereby avoiding unnecessary ballot transfers and timeout waiting, and is used to determine the final candidate node qualification review.

[0041] When candidate C thinks that he may have won the election, he will initiate a VoteComparison RPC request to all other candidates. The request contains the ID of the initiator C, the current number of votes VC, and the set of nodes S that have received votes. When a candidate D receives a VoteComparison RPC request from C, if D has not voted yet, it will update its own voting status and reply:<IDD,VD,S∪IDD> , where IDD is the ID of candidate D, VD is the number of votes for candidate D, and S∪IDD represents the updated set of nodes that have received votes, including D's own ID. When candidate C receives enough vote count comparison responses, it recalculates its own vote count. If it receives a majority of votes, C declares itself the new leader and other candidates accept its leadership; otherwise, the election continues.

[0042] The secure differential log replication module uses secure differential log replication to replace the complete log entry replication method of the traditional Raft algorithm. The specific steps are as follows: (1) The leader node calculates a hash value for each log entry (a hash of the log entry’s content and metadata). The SDRaft leader node does not sign each log entry, but rather signs a log batch that contains the log entry and its hash value.

[0043] (2) When a follower node requests log replication, the leader node calculates the difference between the follower node’s log copy and generates a differential log, which contains the necessary log entries and their hash values, but does not contain signatures.

[0044] (3) The leader node sends the differential log and the corresponding signature to the follower node.

[0045] (4) After receiving the differential log and signature, the follower node uses the leader node’s public key and the Schnorr protocol’s verification function to verify the validity of the signature. If the signature verification succeeds, the follower node applies the differential log to update the local log copy to ensure that it remains consistent with the leader node’s log copy.

[0046] The present invention also proposes an electronic device, comprising: a processor; and a memory arranged to store computer-executable instructions, wherein when the executable instructions are executed, the processor executes a blockchain consensus method that takes into account both efficiency and security.

[0047] The present invention also proposes a computer-readable storage medium, which stores one or more programs. When the one or more programs are executed by an electronic device including multiple application programs, the electronic device executes a blockchain consensus method that takes into account both efficiency and security.

[0048] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A blockchain consensus method that takes into account both efficiency and security, based on the Raft algorithm, characterized by: The following steps are involved: S1: Leader election phase: In the leader election phase of the traditional Raft algorithm, the Schnorr protocol and vote comparison mechanism are combined to enhance the security of leader election. The implementation steps include: S1.1: When a follower node votes for a candidate node, it signs the ballot using the Schnorr protocol; S1.2: In a round of election, the candidate node initiates a vote comparison RPC to determine the final leader; S2: Differential log replication phase: Secure differential log replication is used to replace the log replication phase of the traditional Raft algorithm. The leader node calculates the difference between the log copy and the follower node and generates a differential log. The follower node applies the differential log to update the local log copy.

2. A blockchain consensus method that takes into account both efficiency and security according to claim 1, characterized in that: The specific implementation steps of step S1.1 are as follows: The system starts or triggers the Raft algorithm leader election event; Node initialization: Initialize all nodes; Schnorr generates key pairs: All nodes use the Schnorr signature algorithm to generate key pairs for subsequent encryption and decryption operations; when a follower node votes for a candidate node, it needs to sign the ballot and broadcast the node public key on the blockchain network; Node legitimacy verification: When a follower node votes for a candidate node, it needs to sign the ballot and broadcast the node public key on the blockchain network; then verify whether the signature is legitimate, which is used to discover Byzantine nodes in the cluster and exclude them from the leader election.

3. A blockchain consensus method that takes into account both efficiency and security according to claim 2, characterized in that: The specific implementation steps of step S1.2 are as follows: Candidate nodes initiate vote comparison requests: Candidate nodes in the election initiate vote comparison requests to other candidate nodes to obtain their own support status; Other candidate nodes process requests: Other candidate nodes process received vote comparison requests; Voting: Each legitimate follower node votes based on the support of the candidate node; Receive responses and count votes: Collect the votes from all follower nodes and count them to determine the winner of the election; Elected legitimate leader: Based on the voting results, the candidate node whose votes meet the requirements is elected as the legitimate leader node.

4. A blockchain consensus method that takes into account both efficiency and security according to claim 3, characterized in that: When a voting request is initiated, the candidate node will use the private key to sign the voting request message, obtain the signature, and send the signature to other candidate nodes in the cluster in parallel. Other candidate nodes receive the voting request from the follower node and verify the signature. If the verification is true, it means that the signature is valid and the legitimacy of the follower node is true. The follower node continues to vote, and the number of votes of the requester increases. There will be four election results in the end: 1) The candidate node is legitimate and obtains more than half of the votes to win the election and become the leader node; 2) Other candidate nodes are legitimate and win the election. After receiving the heartbeat of the new leader node, if the term number of the new leader node is not less than its current term number, it returns from the candidate state to the follower state; 3) If there is no winner, a new round of voting will begin. If a winner is still not determined after a period of waiting, each candidate node will increase its term number after a random election timeout and start a new round of voting; 4) The candidate node is judged to be illegal, the cluster excludes the illegal node, and other legal nodes continue the leader election process.

5. A blockchain consensus method that takes into account both efficiency and security according to claim 3, characterized in that: In step S1.2, in one round of election, the candidate node is allowed to actively compare votes with other candidate nodes to determine the winner in advance after obtaining the majority of votes, which is used to determine the qualification review of the final candidate node.

6. A blockchain consensus method that takes into account both efficiency and security according to claim 1, characterized in that: The specific implementation steps of step S2 are as follows: Receiving client commands: Once a legitimate leader node is elected, the leader node will assume the important responsibility of receiving and processing instructions from the client; the leader node converts the client command into a new log entry, each of which contains the command, term number and corresponding index; Log entry hash calculation: The leader node calculates a hash value for each log entry, which is a hash of the content and metadata of the log entry; Log entry batch signing: The leader node uses its own private key to sign a log batch containing log entries and their hash values, and sends the signature and the log to the follower nodes; Generate differential logs: When a follower node requests log replication, the leader node calculates the difference with the follower node's log copy and generates a differential log; Follower nodes receive differential logs: Follower nodes receive differential logs and their signatures from leader nodes; Differential log verification: Follower nodes use the leader node’s public key to verify the signature to ensure the authenticity and integrity of the differential log; The follower node calculates the hash of the received log entry and compares it with the hash in the signature to ensure that the data has not been tampered with during transmission; Log update and synchronization: Follower nodes apply the verified differential log entries to their own log copies, and then follower nodes send synchronization confirmation messages to the leader node, indicating that they have successfully updated their log copies; Log consistency check and fault handling: The leader node continues to listen to client requests and internal state changes, and generates new differential logs for replication; If the leader node fails or loses contact, the system will trigger a new leader election process.

7. A blockchain consensus device that takes into account both efficiency and security, characterized by: It includes an enhanced leader election module and a secure differential log replication module, wherein the enhanced leader election module is used to determine the leader node of the server in the blockchain based on the Schnorr election security mechanism and the vote comparison mechanism, and the secure differential log replication module is used to perform differential log replication on the received client instructions according to the elected leader node; The Schnorr election security mechanism is as follows: when a follower node votes for a candidate node, it needs to sign the ballot; The vote counting and comparison mechanism is: in one round of election, a candidate node is allowed to actively compare votes with other candidate nodes after obtaining a majority of votes.

8. A blockchain consensus device that takes into account both efficiency and security according to claim 7, characterized in that: The secure differential log replication module adopts a secure differential log replication method to replace the complete log entry replication method of the traditional Raft algorithm. The specific steps are as follows: (1) The leader node calculates a hash value for each log entry and signs a log batch containing the log entry and its hash value; (2) When a follower node requests log replication, the leader node calculates the difference between the follower node’s log copy and generates a differential log. The differential log contains the necessary log entries and their hash values, but does not contain a signature. (3) The leader node sends the differential log and the corresponding signature to the follower node; (4) After receiving the differential log and signature, the follower node uses the leader node’s public key and the Schnorr protocol’s verification function to verify the validity of the signature. If the signature verification succeeds, the follower node applies the differential log to update the local log copy to ensure that it remains consistent with the leader node’s log copy.

9. An electronic device, characterized in that: include: processor; And a memory arranged to store computer executable instructions, which, when executed, cause the processor to execute the blockchain consensus method that combines efficiency and security as described in any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores one or more programs, which, when executed by an electronic device including multiple application programs, enable the electronic device to execute the blockchain consensus method that combines efficiency and security as described in any one of claims 1-6.

Images