Alliance chain consensus system and method based on Byzantine fault-tolerant C-Raft algorithm

Abstract

The invention relates to the technical field of block chains, and discloses an alliance chain consensus system and method based on a Byzantine fault-tolerant C-Raft algorithm, and the system comprises a reputation-represented committee upgrading and degrading module, a Byzantine fault-tolerant C-Raft log copying module, a reputation-represented committee upgrading and degrading module, a Byzantine fault-tolerant C-Raft log copying module, a Byzantine fault-tolerant C-Raft log copying module and a Byzantine fault-tolerant C-Raft log copying module. And the C-Raft log copying module is used for constructing a unified reputation subsystem among multiple subjects, comprehensively calculating activity, a consensus completion rate, a historical contribution degree and a periodic contribution degree as reputation scores, then constructing a committee according to the reputation scores, avoiding vote counterfeiting by combining a digital signature technology, and performing Byzantine fault tolerance, and is used for copying logs of the consensus system. According to the method, malicious nodes can be effectively prevented from being selected as cluster leaders in a mode of counterfeiting votes, stable and reliable participants are selected into committees by constructing multi-weight reputation values, the probability of errors in the log copying process is reduced, and the stability and safety of clusters are improved.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a consortium chain consensus system and method based on a Byzantine fault-tolerant C-Raft algorithm. Background Art

[0002] With the development of emerging technologies such as big data, cloud computing, the Internet of Things, and artificial intelligence, many fields are showing a trend of explosive growth in data. However, due to the existence of "data islands" between enterprises, a large amount of data cannot be used correctly and efficiently. How to integrate multiple isolated centralized databases and promote effective information sharing has become one of the urgent problems to be solved in the digital development of enterprises. Blockchain technology has the characteristics of decentralization, immutability, and traceability, which has attracted widespread attention and application in the enterprise community. Alliance chain is a type of blockchain technology. It is a jointly managed network composed of multiple organizations or institutions. Different from public chains and private chains, alliance chains have both the decentralization and credibility of public chains and the efficiency and controllability of private chains. They are widely accepted and used by enterprises. However, at present, alliance chains widely use the Byzantine fault tolerance (PBFT) mechanism to maintain data consistency. This algorithm can resist certain malicious node attacks, but the communication complexity is high. Although the Raft algorithm has high execution efficiency, its fault tolerance mechanism only supports faulty nodes, not malicious nodes, and uses a shared timeout to achieve termination, so it cannot resist Byzantine attacks, etc., and is therefore widely used in private chains.

[0003] In order to enable the efficient RAFT consensus algorithm to be applied to the alliance chain, the present invention introduces the committee promotion and demotion mechanism based on reputation representation and the log verification mechanism based on incremental hashing into the traditional Raft consensus mechanism, and proposes a Byzantine fault-tolerant C-Raft algorithm based on reputation representation, providing users with an efficient, Byzantine fault-tolerant alliance chain consensus mechanism and information sharing solution. Summary of the invention

[0004] 1. Technical issues to be resolved

[0005] In view of the shortcomings of the prior art, the present invention provides a consortium chain consensus system and method based on the Byzantine fault-tolerant C-Raft algorithm, which aims to solve the problem that the existing consortium chain PBFT consensus algorithm has low efficiency and high communication complexity, while the efficient RAFT algorithm cannot resist Byzantine attacks and cannot be directly applied to consortium chains with Byzantine nodes.

[0006] (II) Technical solution

[0007] To achieve the above technical objectives, the present invention provides the following technical solutions: a consortium chain consensus system and method based on the Byzantine fault-tolerant C-Raft algorithm, including a committee promotion and demotion system module for reputation representation and a log replication module for Byzantine fault-tolerant C-Raft;

[0008] The committee promotion and demotion module of the reputation representation is used to build a unified reputation point system among multiple subjects, comprehensively calculate the activity, consensus completion rate, historical contribution and periodic contribution indicators as the reputation point, and then build a committee based on the reputation point, combine digital signature technology to avoid ballot fraud, and select Leader and Monitor to be responsible for the coordination and supervision of log replication respectively.

[0009] The Byzantine fault-tolerant C-Raft log replication module is used for log replication in this consensus system. The Monitor supervises whether the Leader actively processes transaction requests, and then the Followers verify the incremental hash table together to ensure the immutability of log replication. When the Leader collects more than half of the Followers' signatures, the log is officially written into the consortium chain ledger to achieve consistency in log replication in the presence of downtime or Byzantine nodes.

[0010] Preferably, the committee upgrade and downgrade module of the reputation representation includes the following steps:

[0011] Step A1, periodic credit score calculation;

[0012] Step A2, committee replacement;

[0013] Step A3: Leader election.

[0014] Preferably, the Byzantine fault-tolerant C-Raft log replication module comprises the following steps:

[0015] Step B1, initiating a log copy request;

[0016] Step B2: Leader log replication based on the Monitor supervision mechanism;

[0017] Step B3: Follower log verification based on hash chain;

[0018] Step B4: Follower confirms receipt and signs;

[0019] Step B5: Leader log copies, confirms and publishes the signature set.

[0020] Preferably, the step A1 comprises the following steps:

[0021] A1.1. Calculate the node activity of the participant θ(n) = exp(-α, n), that is, the frequency of the participant's participation in consensus within a certain period of time, α is used to adjust the growth rate, and n is the number of times the participant participates in log replication;

[0022] A1.2. Calculate the consensus completion rate of participants ρ = s / n, that is, the completion rate of participants participating in consensus within a certain period of time, s represents the number of successful consensuses;

[0023] A1.3. Calculate the historical contribution σ of the participants online =log(T current -T on ) and period contribution σ T =log(T current -T start ), namely the historical online time contribution of the participant and the online time contribution within the period, T current Indicates the log timestamp of the latest block, T on The timestamp indicating when the participant joined the system;

[0024] A1.4. Calculate the latest reputation score of the participant C = β·σ online ·C'+(1-β)·σ T ·θ(n)·ρ, C' represents the score of the last credit score update, and β (0<β<1) is used to adjust the proportion of historical time contribution and periodic time contribution.

[0025] The longer the participant is online and the higher the consensus activity and completion rate, the higher the credit score will be. If the participant goes down, the corresponding time contribution will be reduced and the credit score will increase slowly. When a participant is detected to have malicious behavior, the credit score will be reset to zero.

[0026] Preferably, the step A2 is specifically implemented as follows:

[0027] Set a reputation score calculation time interval with a period of T. When the time interval is reached and the reputation score update is completed, the participants ranked in the top 1 / 2 will be selected into the committee, and the participants with relatively lower rankings will become ordinary followers, completing the promotion and demotion of the committee. The reputation score lists of each participant are synchronized through log replication. By setting the fault tolerance rate of (n-1) / 2 as the replacement threshold, the error probability of the committee can be effectively reduced and the system robustness can be increased.

[0028] Preferably, step A3 comprises the following steps:

[0029] A3.1. Pre-voting request: The node in the committee that intends to become a leader becomes a candidate and sends a pre-voting request to other followers. The request includes the number of the previous term and the leader number, as well as relevant information about itself.

[0030] A3.2, Pre-voting response: Each Follower verifies the relevant information of the previous term in the request content to determine whether the situation is true. If the heartbeat of the leader of the term is still received, it will not be processed; if the candidate's identity is true and there is no leader at present, check whether the candidate is in the top 1 / 2 in the local reputation list. If it passes, use the private key to sign the pre-voting;

[0031] A3.3. Publicity of signature collection: When a candidate collects more than 1 / 2 of the pre-voting signatures, he / she will integrate the signature collection, which includes the follower number, public key, signature and timestamp, to prove the legitimacy of his / her vote;

[0032] A3.4. Casting a confirmation ballot: The Follower verifies the signature set based on the Follower's signature and public key in the signature set. If it is correct, the Follower casts a confirmation ballot;

[0033] A3.5. Leader information disclosure: After a Follower collects more than 1 / 2 of the confirmation votes, it declares itself the Leader and starts sending heartbeats to the Followers.

[0034] Preferably, step B2 is specifically implemented as follows:

[0035] Through step B1, the task publisher initiates a log replication request to the committee. Based on the leader log replication of the monitor supervision mechanism, the committee consists of the leader and the monitor. After the committee receives the request from the task publisher, the leader in the committee replicates the message to the follower and initiates the AppendEntries RPC, which includes {Term, LeaderID, prevLogInde x, prevLogTerm, prevLogHash, LogHash-Value, Entries, leaderCommit}, which respectively represent the leader's term number, identity number, log index before the log being backed up, term and hash chain value, hash value and specific content of the log being backed up, and index of the last log item submitted by the leader;

[0036] At the same time, the Monitor in the committee monitors the log replication behavior of the Leader and sets up a log replication clock. If the Leader is not detected replicating the log, a Leader election is initiated.

[0037] Preferably, step B3 comprises the following steps:

[0038] B3.1. List missing check: If the Follower fails to add the log item to the local log list due to its own downtime or network fluctuations, the Follower compares prevLogHashValue with its current hash chain value. If they are inconsistent, the leader performs a hash chain rollback check and returns False and the backed-up log index LogIndex. The leader searches for the log item corresponding to the index and sends AppendEntries requests one by one starting from the log item to synchronize the log to the Follower. The Follower performs a hash chain log check until the hash chain values ​​are consistent. If prevLogHashValue is consistent with its current hash chain value, the leader performs a log tampering check.

[0039] B3.2, Log tampering verification: The current Leader is a Byzantine node and has modified the log. The Follower calculates the hash value of the Entries, generates the latest hash chain value with its own hash chain value, and compares it with the LogHashValue in the AppendEntries message. If they are inconsistent, it is determined that the Leader has tampered with the log and a new round of Leader election is initiated. If they are consistent, True is returned.

[0040] Preferably, in step B4, after completing the log verification, the Follower returns the corresponding received information, including its own signature.

[0041] Preferably, step B5 comprises the following steps:

[0042] B5.1. Confirmation of receipt: After the Leader has collected confirmation receipt information and signatures from more than 1 / 2 of the Followers, it returns confirmation receipt information to the task publisher;

[0043] B5.2, Data submission: Leader integrates the signature collection, which includes the Follower number, public key, signature and timestamp, and publicizes the signature collection when the log data is submitted.

[0044] At this point, the log is officially written into the alliance chain, and the corresponding log hash value and incremental hash value are written into the incremental hash table, becoming the only log verification standard.

[0045] The traditional Raft consensus algorithm only conducts leader election voting when the leader is down, and cannot resist Byzantine attacks.

[0046] Compared with the prior art, the present invention provides a consortium chain consensus system and method based on the Byzantine fault-tolerant C-Raft algorithm, which has the following beneficial effects:

[0047] 1. The method of the present invention can effectively prevent malicious nodes from becoming cluster leaders by forging votes, thereby disrupting the cluster.

[0048] 2. The present invention constructs a multi-weight reputation value to select stable and reliable participants into the committee, thereby reducing the probability of errors in the log replication process and improving the stability and security of the cluster.

[0049] 3. The log replication process of the present invention has the ability to tolerate Byzantine faults. If more than half of the participants recognize the log items, consensus can be successfully reached. Incremental hashing provides a unique, reliable, and unforgeable verification standard for log verification.

[0050] 4. The present invention has wide applicability and can provide a reliable, efficient and secure consensus system for application scenarios such as data interaction and information sharing in different industries.

[0051] In summary, the method of the present invention designs a consortium chain consensus system based on the reputation representation and the Byzantine fault-tolerant C-Raft algorithm. By constructing a multi-weight reputation value, the system periodically screens reliable participants to be elected as committees, which are responsible for the supervision and coordination of log replication; combined with digital signature technology, the legitimacy of Leader elections and the immutability of ballots are ensured; combined with incremental hashing technology, a unique, traceable, and tamper-proof log verification standard is provided for participants; on the basis of node crash tolerance, a Byzantine fault-tolerant consensus scheme is provided for the consensus system. Therefore, the scheme is an efficient, secure and reliable consortium chain consensus scheme. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] Figure 1 It is a schematic diagram of the module structure of the present invention.

[0053] Figure 2 This is the leader election process in the committee promotion and demotion system module of the credibility representation of the present invention.

[0054] Figure 3 This is the log replication process of the Byzantine fault-tolerant C-Raft of the present invention.

[0055] Figure 4 This is the process of generating the incremental hash table in the log replication of the present invention.

[0056] Figure 5It is the node initialization information in the embodiment of the present invention.

[0057] Figure 6 This is the Leader election pre-voting process in the embodiment of the present invention.

[0058] Figure 7 This is the process of confirming the ballot for the Leader election in the embodiment of the present invention.

[0059] Figure 8 This is the log replication process in an embodiment of the present invention. DETAILED DESCRIPTION

[0060] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0061] The present invention is further described below with reference to the accompanying drawings and examples.

[0062] like Figure 1 As shown, a consortium chain consensus system based on the reputation representation and Byzantine fault-tolerant C-Raft algorithm includes a reputation representation committee promotion and demotion system module and a Byzantine fault-tolerant C-Raft log replication module.

[0063] The reputation representation committee upgrade and downgrade module is used to build a unified reputation system among multiple entities, comprehensively calculate activity, consensus completion rate, historical contribution and periodic contribution indicators as reputation points, and then build a committee based on the reputation points, combine digital signature technology to avoid vote fraud, select Leader and Monitor, who are responsible for the overall coordination and supervision of log replication respectively. The Leader election process is as follows: Figure 2 shown.

[0064] The Byzantine fault-tolerant C-Raft log replication module is used for log replication in this consensus system. The Monitor supervises whether the Leader actively processes transaction requests, and then the Followers verify the incremental hash table together to ensure the immutability of log replication. When the Leader collects more than half of the Followers' signatures, it officially writes the log into the consortium chain account book to achieve consistency in log replication in the event of downtime or Byzantine nodes. The log replication process is as follows: Figure 3 As shown, the incremental hash table process is as follows Figure 4 shown.

[0065] This embodiment simulates 4 nodes for illustration. Registration and initialization are as follows: Figure 5 shown.

[0066] The reputation representation committee promotion and demotion system module specifically includes the following steps:

[0067] Step 1: Periodic reputation score calculation (randomly select the committee at the beginning, and then calculate it at a certain time interval and use it as the basis for committee election), specifically:

[0068] 1.1. Calculate the node activity of the participant θ(n) = exp(-α, n), that is, the frequency of the participant's participation in consensus within a certain period of time, α is used to adjust the growth rate, and n is the number of times the participant participates in log replication;

[0069] 1.2. Calculate the consensus completion rate of participants ρ = s / n, that is, the completion rate of participants participating in consensus within a certain period of time, s represents the number of successful consensuses;

[0070] 1.3. Calculate the historical contribution of participants σ online =log(T current -T on ) and period contribution σ T =log(T current -T start ), namely the historical online time contribution of the participant and the online time contribution within the period, T current Indicates the log timestamp of the latest block, T on The timestamp indicating when the participant joined the system;

[0071] 1.4. Calculate the latest reputation score of the participant C = β·σ online ·C'+(1-β)·σ T ·θ(n)·ρ, C' represents the score of the last credit score update, and β (0<β<1) is used to adjust the proportion of historical time contribution and periodic time contribution.

[0072] The longer the participant is online and the higher the consensus activity and completion rate, the higher the credit score will be. If the participant goes down, the corresponding time contribution will be reduced and the credit score will increase slowly. When a participant is detected to have malicious behavior, the credit score will be reset to zero.

[0073] Step 2: Committee replacement. The system will set a reputation score calculation time interval of period T. When the time interval is reached and step 1 is completed, the participants ranked in the top 1 / 2 will be selected into the committee, and the participants with relatively lower rankings will become ordinary followers. The reputation score lists of each participant will be synchronized through log replication. By setting the (n-1) / 2 fault tolerance rate as the replacement threshold, the error probability of the committee can be effectively reduced and the system robustness can be increased.

[0074] Step 3: Leader election. Steps 3.1 to 3.3 are as follows: Figure 6 , steps 3.4 to 3.5 Figure 7 As shown, the specific steps are as follows:

[0075] Step 3.1 Pre-voting request. The node in the committee that intends to become a leader becomes a candidate and sends a pre-voting request to other followers. The request includes the number of the previous term and the leader number, as well as relevant information about itself.

[0076] Step 3.2 Pre-voting response. Each Follower verifies the relevant information of the previous term in the request content to determine whether the situation is true. If the heartbeat of the leader of the term is still received, it will not be processed; if the candidate's identity is true and there is no leader at present, check whether the candidate is in the top 1 / 2 in the local reputation list. If it passes, use the private key to sign the pre-voting.

[0077] Step 3.3: Publicity of signature collection: When a candidate collects more than 1 / 2 of the pre-voting signatures, he / she will integrate the signature collection (including Follower ID, public key, signature and timestamp) to prove the legitimacy of his / her vote.

[0078] Step 3.4 Cast the confirmation vote. Follower verifies the signature set based on the Follower's signature and public key in the signature set. If it is correct, cast the confirmation vote.

[0079] Step 3.5 Leader information announcement: After a Follower collects more than 1 / 2 of the confirmation votes, it declares itself the Leader and starts sending heartbeats to the Followers.

[0080] Byzantine fault-tolerant C-Raft log replication module, such as Figure 8 As shown, the details are as follows:

[0081] Step 1: Initiate a log replication request. The task publisher initiates a log replication request to the committee.

[0082] Step 2: Leader log replication based on the Monitor supervision mechanism. The committee consists of the Leader and the Monitor. After the committee receives the request from the task publisher, the Leader in the committee replicates the message to the Follower and initiates the AppendEntries RPC, which includes {Term, LeaderID, prevLogIndex, prevLogTerm, prevLogHash, LogHash-Value, Entries, leaderCommit}, which respectively represent the Leader's term number, identity number, log index before the log being backed up, term and hash chain value, hash value and specific content of the log being backed up, and index of the last log submitted by the Leader.

[0083] At the same time, the Monitor in the committee monitors the log replication behavior of the Leader and sets up a log replication clock. If the Leader is not detected replicating the log, a Leader election is initiated.

[0084] Step 3: Follower log verification based on hash chain.

[0085] Step 3.1 List missing check. The Follower did not add the log item to the local log list in time due to a period of downtime or network fluctuations. The Follower compares prevLogHashValue with its current hash chain value. If they are inconsistent, it performs a hash chain rollback check and returns False and the backed-up log index LogIndex. The Leader looks for the log item corresponding to the index and sends AppendEntries requests one by one starting from the log item to synchronize the log to the Follower. The Follower performs a hash chain log check until the hash chain value is consistent; if prevLogHashValue is consistent with its current hash chain value, a log tampering check is performed.

[0086] Step 3.2 Log tampering verification: The current Leader is a Byzantine node and has modified the log. The Follower calculates the hash value of the Entries, generates the latest hash chain value with its own hash chain value, and compares it with the LogHashValue in the AppendEntries message. If they are inconsistent, it is determined that the Leader has tampered with the log and a new round of Leader election is initiated. If they are consistent, True is returned.

[0087] Step 4: Follower confirms receipt and signs. After completing the log verification, the Follower returns the corresponding receipt information, including its own signature.

[0088] Step 5: Leader log copy confirmation and publicize the signature set.

[0089] Step 5.1: Confirmation of receipt. After the Leader has collected more than 1 / 2 of the Followers’ confirmation receipt information and signatures, it returns the confirmation receipt information to the task publisher.

[0090] Step 5.2: Data submission. The Leader integrates the signature collection (including Follower ID, public key, signature and timestamp) and publishes the signature collection while submitting the log data.

[0091] At this point, the log is officially written into the alliance chain, and the corresponding log hash value and incremental hash value are written into the incremental hash table, becoming the only log verification standard.

[0092] Compared with the prior art, the present invention has the following advantages:

[0093] (1) The present invention designs a committee replacement mechanism based on reputation representation. The node with the highest reputation score in the election committee is the Leader, and the remaining nodes in the committee are given an additional identity Monitor to monitor whether the Leader forwards log replication requests correctly and in a timely manner.

[0094] (2) Since the committee is the recipient of the request message, and the Monitor, as a member of the committee, can perceive the progress of log replication, if the Leader crashes or acts maliciously, the Monitor will elect a new Leader for the next term and complete the log replication tasks that the Leader has not yet completed.

[0095] (3) During the log replication process, Follower ensures the security of log items through a hash chain-based verification mechanism.

[0096] Therefore, a Byzantine fault-tolerant C-Raft algorithm based on reputation representation ensures the consistency, security and activity of consensus.

[0097] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A consortium chain consensus system and method based on the Byzantine fault-tolerant C-Raft algorithm, characterized in that: It includes a committee promotion and demotion system module for reputation representation and a log replication module for Byzantine fault-tolerant C-Raft. The committee upgrade and downgrade module of the reputation representation is used to build a unified reputation system among multiple entities, comprehensively calculate the activity, consensus completion rate, historical contribution and periodic contribution indicators as the reputation score, and then build a committee based on the reputation score, combine digital signature technology to avoid vote fraud, and select Leader and Monitor to be responsible for the coordination and supervision of log replication respectively; The Byzantine fault-tolerant C-Raft log replication module is used for log replication in this consensus system. The Monitor supervises whether the Leader actively processes transaction requests, and then the Followers verify the incremental hash table together to ensure the immutability of log replication. When the Leader collects more than half of the Followers' signatures, the log is officially written into the consortium chain ledger to achieve consistency in log replication in the presence of downtime or Byzantine nodes.

2. According to claim 1, a consortium chain consensus system and method based on the Byzantine fault-tolerant C-Raft algorithm is characterized in that: The committee upgrade and downgrade module of the reputation representation includes the following steps: Step A1, periodic credit score calculation; Step A2, committee replacement; Step A3: Leader election.

3. According to claim 1, a consortium chain consensus system and method based on the Byzantine fault-tolerant C-Raft algorithm is characterized in that: The Byzantine fault-tolerant C-Raft log replication module includes the following steps: Step B1, initiating a log copy request; Step B2: Leader log replication based on the Monitor supervision mechanism; Step B3: Follower log verification based on hash chain; Step B4: Follower confirms receipt and signs; Step B5: Leader log copies, confirms and publishes the signature set.

4. According to claim 2, a consortium chain consensus system and method based on the Byzantine fault-tolerant C-Raft algorithm is characterized in that: The step A1 comprises the following steps: A1.

1. Calculate the node activity of the participant θ(n) = exp(-α, n), that is, the frequency of the participant's participation in consensus within a certain period of time, α is used to adjust the growth rate, and n is the number of times the participant participates in log replication; A1.

2. Calculate the consensus completion rate of participants ρ = s / n, that is, the completion rate of participants participating in consensus within a certain period of time, s represents the number of successful consensuses; A1.

3. Calculate the historical contribution σ of the participants online =log(T current -T on ) and period contribution σ T =log(T current -T start ), namely the historical online time contribution of the participant and the online time contribution within the period, T current Indicates the log timestamp of the latest block, T on The timestamp indicating when the participant joined the system; A1.

4. Calculate the latest reputation score of the participant C = β·σ onlice ·C'+(1-β)·σ T ·θ(n)·ρ, C' represents the score of the last credit score update, and β (0<β<1) is used to adjust the proportion of historical time contribution and periodic time contribution.

5. According to claim 2, a consortium chain consensus system and method based on the Byzantine fault-tolerant C-Raft algorithm is characterized in that: The step A2 is specifically implemented as follows: Set a reputation score calculation time interval with a period of T. When the time interval is reached and the reputation score update is completed, the participants ranked in the top 1 / 2 will be selected into the committee, and the participants with relatively lower rankings will become ordinary followers, completing the promotion and demotion of the committee.

6. According to claim 2, a consortium chain consensus system and method based on the Byzantine fault-tolerant C-Raft algorithm is characterized in that: The step A3 comprises the following steps: A3.

1. Pre-voting request: The node in the committee that intends to become a leader becomes a candidate and sends a pre-voting request to other followers. The request includes the number of the previous term and the leader number, as well as relevant information about itself. A3.2, Pre-voting response: Each Follower verifies the relevant information of the previous term in the request content to determine whether the situation is true. If the heartbeat of the leader of the term is still received, it will not be processed; if the candidate's identity is true and there is no leader at present, check whether the candidate is in the top 1 / 2 in the local reputation list. If it passes, use the private key to sign the pre-voting; A3.

3. Publicity of signature collection: When a candidate collects more than 1 / 2 of the pre-voting signatures, he / she will integrate the signature collection, which includes the follower number, public key, signature and timestamp, to prove the legitimacy of his / her vote; A3.

4. Casting a confirmation ballot: The Follower verifies the signature set based on the Follower's signature and public key in the signature set. If it is correct, the Follower casts a confirmation ballot; A3.

5. Leader information disclosure: After a Follower collects more than 1 / 2 of the confirmation votes, it declares itself the Leader and starts sending heartbeats to the Followers.

7. According to claim 3, a consortium chain consensus system and method based on the Byzantine fault-tolerant C-Raft algorithm is characterized in that: The step B2 is specifically implemented as follows: Through step B1, the task publisher initiates a log replication request to the committee. Based on the leader log replication of the monitor supervision mechanism, the committee consists of the leader and the monitor. After the committee receives the request from the task publisher, the leader in the committee replicates the message to the follower and initiates the AppendEntries RPC, which includes {Term, LeaderID, prevLogIndex, prevLogTerm, prevLogHash, LogHash-Value, Entries, leaderCommit}, which respectively represent the leader's term number, identity number, log index before the log being backed up, term and hash chain value, hash value and specific content of the log being backed up, and index of the last log item submitted by the leader; At the same time, the Monitor in the committee monitors the log replication behavior of the Leader and sets up a log replication clock. If the Leader is not detected replicating the log, a Leader election is initiated.

8. According to claim 3, a consortium chain consensus system and method based on the Byzantine fault-tolerant C-Raft algorithm is characterized in that: The step B3 comprises the following steps: B3.

1. List missing check: If the Follower fails to add the log item to the local log list due to its own downtime or network fluctuations, the Follower compares prevLogHashValue with its current hash chain value. If they are inconsistent, the leader performs a hash chain rollback check and returns False and the backed-up log index LogIndex. The leader searches for the log item corresponding to the index and sends AppendEntries requests one by one starting from the log item to synchronize the log to the Follower. The Follower performs a hash chain log check until the hash chain values ​​are consistent. If prevLogHashValue is consistent with its current hash chain value, the leader performs a log tampering check. B3.2, Log tampering verification: The current Leader is a Byzantine node and has modified the log. The Follower calculates the hash value of the Entries, generates the latest hash chain value with its own hash chain value, and compares it with the LogHashValue in the AppendEntries message. If they are inconsistent, it is determined that the Leader has tampered with the log and a new round of Leader election is initiated. If they are consistent, True is returned.

9. According to claim 3, a consortium chain consensus system and method based on the Byzantine fault-tolerant C-Raft algorithm is characterized in that: In step B4, after completing the log verification, the Follower returns the corresponding received information, including its own signature.

10. According to claim 3, a consortium chain consensus system and method based on the Byzantine fault-tolerant C-Raft algorithm is characterized in that: The step B5 comprises the following steps: B5.

1. Confirmation of receipt: After the Leader has collected confirmation receipt information and signatures from more than 1 / 2 of the Followers, it returns confirmation receipt information to the task publisher; B5.2, Data submission: Leader integrates the signature collection, which includes the Follower number, public key, signature and timestamp, and publicizes the signature collection when the log data is submitted.

Images