A consensus method and system for selecting consortium blockchain leader nodes based on historical performance evaluation.

Abstract

This invention discloses a consensus method and system for selecting leader nodes in a consortium blockchain based on historical performance evaluation, belonging to the field of blockchain consensus protocol technology. At the beginning of each consensus round, the method locally records and updates the participation behavior of each node in previous rounds, extracts reference data from historical records, and combines this with the node determination criteria for the current round. After proposal verification, each node checks candidate nodes one by one; if the criteria are met, the node is determined as the voting target node. The target node collects valid votes, aggregates proof information, generates a new block, and drives the process into the next round. The system implementing the method includes five core modules: a state maintenance module, a proposal processing module, a candidate node determination module, a vote aggregation and block generation module, and a blockchain network layer. This invention improves the system's operational stability and execution efficiency in complex environments without increasing additional communication overhead.

Description

Technical Field

[0001] This invention relates to the field of blockchain consensus protocol technology, and in particular to a consensus method and system for selecting consortium blockchain leader nodes based on historical performance evaluation. Background Technology

[0002] Blockchain technology, as a highly promising technology, has become a hot research topic in the field of computer science. Currently, blockchain-related theories and methods have been widely applied in engineering and scientific fields. The consensus mechanism is the core module of a blockchain system and also a major target for malicious node attacks. Its task is to ensure that all nodes reach a consensus on the system state in an untrusted network environment. Based on their tolerance for different types of failures, consensus protocols can be divided into two main categories: Crash Fault Tolerance (CFT), which can cope with node downtime or non-malicious failures; and Byzantine Fault Tolerance (BFT), which can defend against malicious behaviors such as node forgery, deception, and denial-of-service attacks.

[0003] Compared to CFT, BFT-based consensus mechanisms are more suitable for scenarios requiring high security, and are therefore widely used in consortium blockchain systems. Mainstream BFT protocols typically employ a leader-based paradigm, where a leader is elected each round to initiate proposals, and the remaining nodes vote to confirm them. Protocol performance is highly dependent on the behavior and availability of the leader node. Since elections are usually rotational, malicious nodes can be elected at a fixed frequency and can block the consensus process, trigger frequent view switching, or even cause transaction rollbacks by delaying proposals, thus severely impacting system throughput and stability. Summary of the Invention

[0004] The purpose of this invention is to provide a consensus method and system for selecting leader nodes in consortium blockchains based on historical performance evaluation. By locally recording the historical participation performance of nodes in each round of consensus and combining it with round-related judgment conditions, candidate leader nodes are selected, so that nodes with more stable historical performance take on the responsibility of proposal in the consensus process, thereby reducing the adverse effects on system throughput, confirmation efficiency and operational stability caused by abnormal nodes entering key dominant positions.

[0005] To achieve the above objectives, this invention provides a consensus method for selecting consortium blockchain leader nodes based on historical performance evaluation, comprising the following steps: S1. Round Initialization and Status Update: At the beginning of each round of consensus, each node obtains the node participation information recorded in the previous round, accumulatively updates it to form the node historical performance data; writes the historical performance data into a historical record sequence with a fixed capacity, extracts reference data, and calculates the node decision threshold in combination with the current round number, and clears the temporary record of the previous round; S2. Proposal Generation and Validity Verification: The node responsible for proposing in this round generates a new block and broadcasts a proposal message, and the remaining nodes receive the proposal message and verify the legality of the proposal; if the verification passes, the proposal behavior is recorded in the node temporary record, and if the verification fails, the proposal is rejected; S3. Candidate Node Determination and Vote Forwarding: After the node completes the proposal verification, it checks the candidate nodes for the subsequent rounds within a preset range, compares the candidate node reference data with the decision conditions of the current round, and if the candidate node meets the decision conditions, it is determined as the voting target node and voting information is sent to the candidate node; S4. Vote Aggregation, Proof Generation and Block Advancement: The target node receiving the vote verifies the validity of the vote. When the number of valid votes reaches the preset threshold before timeout, the votes are aggregated and proof information is generated, and a new block is generated and broadcast based on the proof information, thus completing the consensus of this round; if the number of valid votes still does not reach the preset threshold until timeout, the node generates and broadcasts a new block according to the original protocol process, completing the consensus of this round.

[0006] Preferably, in S1, the node participation information includes the records of the node's effective participation behaviors in the processes of proposal generation, proposal verification and voting; the historical record sequence is maintained in a first-in-first-out manner, and is used to reflect the node's historical participation in multiple rounds.

[0007] Preferably, in S2, the passing of the proposal legality verification includes at least: successfully generating a valid proposal, successfully verifying the proposal, and participating in a correct vote.

[0008] Preferably, in S3, the process of checking candidate nodes is: traversing the candidate nodes corresponding to a finite number of rounds backward within a preset range, and performing a matching judgment on the decision conditions for each candidate node; the node decision condition is a comparison rule constructed based on the node historical performance data, and is used to judge whether the candidate node is qualified to undertake the subsequent proposal responsibility.

[0009] Preferably, in S4, in a system with a total of n nodes, at most f nodes exhibit Byzantine faults, satisfying f < n / 3, and the preset threshold is the number of nodes not less than 2f + 1.

[0010] Preferably, in S1, the node historical performance data, reference data and decision threshold are all independently calculated and maintained by each node locally, without network synchronization and dissemination.

[0011] The present invention also provides a consortium chain leader node screening consensus system based on historical performance evaluation, including: A status maintenance module, which is used to update the historical performance data of nodes at the beginning of each round of consensus and generate the node determination conditions for the current round; A proposal processing module, which is used to generate block proposals, verify the legality of the proposals, and record the effective participation behaviors of nodes; A candidate node determination module, which is used to determine the voting target nodes within a preset range according to the historical performance data of nodes and the determination conditions after the proposal verification; A voting aggregation and block generation module, which is used to verify and aggregate votes, and generate a new block when the effective votes reach the preset threshold; A blockchain network layer, as the basic network architecture, is used to build a trusted computing environment for distributed nodes and provide consistent read and write services externally through a consensus algorithm.

[0012] Preferably, in a system with a total of n nodes, at most f nodes exhibit Byzantine faults, and the remaining nodes are normal nodes, satisfying f < n / 3. Each node completes identity identification and message verification through a public key and a private key pair.

[0013] Preferably, the candidate node determination module determines multiple candidate nodes one by one within a preset range, and under the condition of satisfying the majority constraint, ensures that a certain node converges enough votes and continues to promote the consensus process.

[0014] Therefore, the present invention adopts the above-mentioned consortium chain leader node screening consensus method and system based on historical performance evaluation, and has the following beneficial effects: 1) Improve the system stability and reduce the interference ability of abnormal nodes. By introducing the historical performance records of nodes and the round-based determination conditions, the probability of a node assuming the leadership responsibility in subsequent rounds is restricted by its historical participation; this mechanism effectively reduces the possibility of abnormal nodes becoming the leader node periodically, reduces the consensus stagnation, frequent timeouts or rollbacks caused by them, and makes the system show stronger stability and continuity during continuous operation.

[0015] 2) Make decisions based on local information and avoid additional communication overhead. The historical performance records of nodes, the extraction of reference quantities, and the generation of leader node determination conditions are all independently maintained and calculated by each node locally, which will not increase the message complexity in the original consensus protocol, nor introduce new communication paths or protocol stages, avoiding the bandwidth occupation and latency problems caused by communication volume inflation; even in the case of network fluctuations or some nodes being disconnected, the system can still operate with the original communication structure, which is beneficial to maintaining stable consensus efficiency in a complex network environment.

[0016] 3) It has good versatility and can be used in conjunction with various consensus protocols. The proposed leader node determination method constructs a historical performance record based on the common behaviors of nodes during the consensus process, and then determines candidate nodes based on this record. Therefore, this method can be embedded as an independent functional module into different types of Byzantine fault-tolerant consensus protocols. By replacing or enhancing the leader node generation method in the original protocol, it is possible to effectively avoid abnormal nodes and improve overall performance without compromising the security and consistency of the original protocol.

[0017] 4) Low implementation cost and strong adaptability to complex adversarial environments. This invention only introduces limited data structures and simple decision logic locally on the node, without requiring modifications to the underlying network communication mechanism or cryptographic module, making it easy to deploy and integrate into existing systems. At the same time, by accumulating node behavior characteristics over a long period, this method makes it difficult for abnormal nodes to maintain stable performance in continuous rounds, gradually reducing their chances of entering a key dominant position.

[0018] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0019] Figure 1 This is a flowchart of the consensus system operation of the present invention; Figure 2 This is an architectural block diagram of the consensus system of this invention. Detailed Implementation

[0020] The technical solution of the present invention will be further described below with reference to the accompanying drawings and embodiments.

[0021] Unless otherwise defined, the technical or scientific terms used in this invention shall have the ordinary meaning understood by one of ordinary skill in the art to which this invention pertains. The terms "first," "second," and similar terms used in this invention do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0022] Example 1 The consensus method described in this embodiment is applied to a consortium blockchain system composed of n nodes. The system satisfies the Byzantine fault tolerance constraint: at most f Byzantine faulty nodes exist, where f < n / 3, and in the classical implementation, n = 3f + 1; each node holds an independent public-private key pair, uses the public key as the identity identifier, and completes message signing and verification; messages between correct nodes in the network can be finally delivered and the validity check can be completed.

[0023] The method flow of this embodiment is as Figure 1 shown, and it includes four core steps: round initialization and state update, proposal generation and validity verification, candidate node determination and vote forwarding, and vote aggregation and block advancement. The specific execution process is as follows: S1. Round initialization and state update.

[0024] At the beginning of each round of consensus, the system first reads the participation records of each node in the previous round and inputs them into the node history processing unit. Based on the effective participation of each node in the proposal generation, proposal verification, voting and other links in the previous round, the processing unit calls the state sorting function, and statistically analyzes the effective behaviors recorded in the previous round through the behavior accumulation function inside it, and accumulates them into the existing historical records of each node, so as to form the updated node historical performance data.

[0025] Subsequently, the updated historical performance data is written into a historical record sequence with a fixed capacity, and the historical record sequence runs in a first-in-first-out update manner. In the current round, a set of earlier formed historical records are taken out from this sequence as the reference quantity used for the current judgment. At the same time, the system generates corresponding node judgment conditions according to the current round number for use in the subsequent candidate node determination process. After completing the above operations, the temporary behavior records reserved in the previous round are cleared for use in the new records of the current round. Through this step, the node historical performance data, reference quantity and judgment conditions can be continuously updated as the consensus round progresses and be consistent with the consensus execution process.

[0026] S2. Proposal generation and validity verification.

[0027] After completing round initialization and local state update, depending on the current node's role, the node enters one of two parallel paths: (a) Leader node processing path: If the current node is responsible for proposing in this round, it packages the transactions to be processed, generates a new block, constructs a proposal message containing the new block and its preceding proof information, and then sends the proposal message to other nodes in the network; (b) Non-leader node processing path: If the current node is not responsible for proposing in this round, it receives the proposal message from the leader node and performs a legality check on the proposal message. The check includes at least sender authentication, block content integrity verification, block association verification, and consensus rule compliance verification. Passing the proposal legality verification includes at least: successfully generating a valid proposal, successfully verifying the proposal, and participating in the correct voting.

[0028] When a non-leader node confirms that a proposal message is valid, it records the valid proposal action in a local temporary record to indicate that the corresponding leader node has completed a valid advancement action in this round of consensus. When a proposal message fails to pass verification, the proposal is not accepted, and no positive record is added for the corresponding leader node in this round.

[0029] S3, Candidate Node Determination and Voting Forwarding.

[0030] After the non-leadership node completes the verification of valid proposals, the process of determining the candidate leader node is executed.

[0031] Specifically, the node first generates signed voting information to be sent for the proposals that have been verified in the current round. Then, it checks each of the predetermined candidate nodes for subsequent rounds in a pre-defined order. During the check, a node determination function is called to compare the reference value corresponding to the candidate node with the leader node determination criteria used in the current round: (a) if the reference value corresponding to the candidate node does not meet the current determination criteria, the candidate node is considered unsuitable to assume subsequent leadership responsibilities, and the check continues with other candidate nodes in subsequent rounds; (b) if the reference value corresponding to the candidate node meets the current determination criteria, the candidate node is determined as the recipient of this vote, and the check stops.

[0032] After the candidate nodes are determined, the node sends the aforementioned signature voting information to the determined target node. Different nodes may produce different candidate judgment results based on their locally maintained historical performance records, but under the majority constraint, the system can still gather enough votes from nodes in a subsequent round to drive the subsequent consensus to continue.

[0033] Once the target node receives the vote and verifies its validity, if the vote is confirmed to be valid, the node's valid participation in this round will be recorded in its local record to update the node's subsequent historical performance results.

[0034] S4, Voting Convergence, Proof Generation, and Block Advancement.

[0035] After receiving and verifying votes from other nodes, the target node counts the valid votes. If the number of valid votes reaches the consensus confirmation threshold 2f+1 before timeout, the target node aggregates the valid votes, generates new legal proof information, writes this proof information into subsequent proposals, forms a new block proposal message, and broadcasts it, completing this round of consensus. If the number of valid votes has not reached the preset threshold before timeout, the node generates and broadcasts a new block according to the original protocol process, completing this round of consensus.

[0036] During the voting aggregation process, although different nodes may choose different candidate nodes as voting targets based on their local states, since normal nodes constitute the majority of the system and each node only sends a valid vote to a single candidate node in the same round, there must be at least one candidate node in all vote sets that can aggregate votes from the majority of normal nodes. Based on a voting threshold requirement of no less than 2f+1, different vote sets overlap, thus ensuring that there are no multiple conflicting candidate nodes that all meet the threshold conditions simultaneously.

[0037] Once a new block proposal is accepted by subsequent nodes, the new block is added to the chain structure, and the system then enters the next round of consensus process, re-executing the round initiation and local state reorganization steps, thus forming a continuous loop consortium blockchain consensus execution process.

[0038] Example 2 This embodiment provides a consensus system for selecting consortium blockchain leader nodes based on historical performance evaluation, such as... Figure 2 As shown, this is the implementation architecture of the method in Embodiment 1. The system is divided into a state layer, a logic layer, and an output layer, and includes five core modules: a state maintenance module, a proposal processing module, a candidate node determination module, a vote aggregation and block generation module, and a blockchain network layer. The functions and collaborative processes of each module are as follows: 1. Core module functions (1) State maintenance module (state layer) This module is the core of the system's state management. It is automatically triggered and executed when each round of consensus is started. It is the initialization entry point for this round of consensus. It runs only locally on the node and does not generate any network communication overhead.

[0039] Core functions: Read the temporary behavior records from the previous round; use state processing and behavior accumulation functions to statistically analyze the effective participation behaviors of each node in the proposal, verification, and voting stages of the previous round; accumulate the effective behavior data into the historical performance records of the corresponding nodes and update the node's historical performance data; write the updated historical performance data into a fixed-capacity first-in-first-out historical record sequence; extract the earliest generated historical records from the sequence as reference data for candidate node determination; generate the node determination conditions for this round based on the round number; clear the temporary records from the previous round. Output data: node historical record sequence, current round decision conditions, and initialized temporary record structure.

[0040] (2) Proposal processing module (logic layer) This module is the core of the system's proposal generation and verification. It receives the output data from the state maintenance module and is responsible for creating, broadcasting, and verifying the legality of block proposals, while also recording the effective participation behavior of nodes.

[0041] Core functions: On the leader node side, the unprocessed transactions are packaged, a new block is generated, and a proposal message containing the new block and its preceding proof information is constructed and broadcast to all nodes in the network; on the non-leader node side, the proposal legality is verified, including at least the sender's identity verification, block content integrity verification, block association verification, and consensus rule compliance verification; valid proposal / verification behaviors are recorded, generating the current round node behavior record; Output data: Verified proposal data, and records of valid behaviors of newly added nodes in this round.

[0042] (3) Candidate Node Determination Module (Logical Layer) This module is executed after the proposal processing module completes the verification, breaking the traditional fixed rotation rule and selecting qualified voting target nodes based on the historical performance of the nodes.

[0043] Core functions: Generate voting information with node signatures based on valid proposals; traverse candidate nodes within a preset round range, compare the reference value corresponding to the candidate node with the leader node judgment condition used in the current round through the node judgment function, and complete the judgment and screening; after the candidate nodes are determined, the node sends the aforementioned signed voting information to the determined target node; after receiving the vote, the target node verifies the voting signature and validity, and updates the node's historical performance.

[0044] (4) Voting aggregation and block generation module (output layer) This module is responsible for completing the vote aggregation, proof generation, and block uploading, marking the final completion of a single round of consensus.

[0045] Core functions: Verify the validity of each vote and count the number of valid votes. When the number of valid votes reaches the 2f+1 threshold, aggregate the votes to generate legal proof information; generate a new block based on the legal proof information and broadcast it; after the block is verified, append it to the ledger and trigger the next round of consensus.

[0046] (5) Blockchain network layer This module serves as the foundational support layer of the system, acting as the runtime environment for all functional modules and providing underlying communication and a trusted environment for distributed nodes.

[0047] Core functions: Build a network communication architecture for distributed nodes in the consortium blockchain to achieve reliable message transmission between nodes; provide cryptographic support for each module, such as identity verification, data encryption, and message signing; and as the underlying infrastructure, ensure the stable operation of the consensus algorithm and provide globally consistent ledger read and write services to the outside world.

[0048] The above-mentioned system-level collaborative operation process is as follows: State layer initialization: At the start of each consensus round, the state maintenance module is executed first, completing the updating of historical data, generation of judgment conditions and clearing of temporary records, providing the core judgment basis for the logic layer; Logic layer processing: The proposal processing module first generates and verifies block proposals, and outputs valid proposals and behavior records; then the candidate node determination module filters voting targets based on historical performance, and completes vote forwarding and verification; Output layer closed loop: The voting aggregation and block generation module gathers valid votes, generates proofs and new blocks after reaching the 2f+1 threshold, completes the on-chain process and triggers the next round of consensus; End-to-end support: The blockchain network layer provides communication, verification, and data transmission support for all modules throughout the process, ensuring stable system operation.

[0049] Therefore, this invention adopts the aforementioned consensus method and system for selecting consortium blockchain leader nodes based on historical performance evaluation. By constraining the selection of consortium blockchain leader nodes through the historical performance of nodes, it reduces interference from abnormal nodes, avoids consensus stagnation, frequent view switching, and block rollback, and improves system stability. Historical data and judgment logic are completed independently by the node locally, without additional network synchronization and communication overhead, and without increasing protocol complexity. The solution has strong versatility and can be seamlessly embedded into various Byzantine fault-tolerant consensus mechanisms without modifying the underlying communication and cryptographic modules, resulting in low deployment costs. Even in malicious node environments, it can still ensure efficient consensus progress, improving system throughput and confirmation efficiency.

[0050] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit them. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the technical solutions of the present invention, and these modifications or equivalent substitutions cannot cause the modified technical solutions to deviate from the spirit and scope of the technical solutions of the present invention.

Claims

1. A consensus method for selecting consortium blockchain leader nodes based on historical performance evaluation, characterized in that, It includes the following steps: S1. Round initialization and status update: At the beginning of each round of consensus, each node obtains the node participation information recorded in the previous round, accumulatively updates it to form node historical performance data; writes the historical performance data into a historical record sequence with a fixed capacity, extracts reference data and calculates the node decision threshold in combination with the current round number, and clears the temporary record of the previous round; S2. Proposal generation and validity verification: The node responsible for proposal generation in this round generates a new block and broadcasts a proposal message, and the other nodes receive the proposal message and verify the legality of the proposal; if the verification passes, the proposal behavior is recorded in the node's temporary record, and if the verification fails, the proposal is rejected; S3. Candidate node determination and vote forwarding: After the node completes the proposal verification, it checks the candidate nodes for subsequent rounds within a preset range, compares the candidate node reference data with the decision conditions of the current round, and if the candidate node meets the decision conditions, it is determined as the voting target node and voting information is sent to the candidate node; S4. Vote aggregation, proof generation and block advancement: The target node receiving the vote verifies the validity of the vote. When the number of valid votes reaches the preset threshold before timeout, the votes are aggregated and proof information is generated, and a new block is generated and broadcast based on the proof information, thus completing the consensus of this round; if the number of valid votes still does not reach the preset threshold until timeout, the node generates and broadcasts a new block according to the original protocol process to complete the consensus of this round.

2. The consensus method for selecting consortium blockchain leader nodes based on historical performance evaluation according to claim 1, characterized in that, In S1, the node participation information includes the record of the node's effective participation behavior in the process of proposal generation, proposal verification and voting; the historical record sequence is maintained in a first-in-first-out manner and is used to reflect the node's historical participation in multiple rounds.

3. The consensus method for selecting consortium blockchain leader nodes based on historical performance evaluation according to claim 1, characterized in that, In S2, the passing of the proposal legality verification includes at least: successfully generating a valid proposal, successfully verifying the proposal, and participating in a correct vote.

4. The consensus method for selecting consortium blockchain leader nodes based on historical performance evaluation according to claim 1, characterized in that, In S3, the process of checking candidate nodes is: traversing the candidate nodes corresponding to a finite number of rounds backward within a preset range, and performing a matching judgment on the decision conditions for each candidate node; the node decision condition is a comparison rule constructed based on the node historical performance data and is used to determine whether the candidate node is eligible to assume the subsequent proposal responsibility.

5. The consensus method for selecting consortium blockchain leader nodes based on historical performance evaluation according to claim 1, characterized in that, In S4, in a system with a total of n nodes, at most f nodes exhibit Byzantine faults, satisfying f < n / 3, and the preset threshold is the number of nodes not less than 2f + 1.

6. The consensus method for selecting consortium blockchain leader nodes based on historical performance evaluation according to claim 1, characterized in that, In S1, the node historical performance data, reference data and decision threshold are all independently calculated and maintained by each node locally, without network synchronization and dissemination.

7. A consensus system for selecting consortium blockchain leader nodes based on historical performance evaluation, characterized in that, It includes: A status maintenance module, used to update the node historical performance data at the beginning of each round of consensus and generate the decision conditions for the current round of nodes; A proposal processing module, used to generate block proposals, verify the legality of proposals, and record the node's effective participation behavior; A candidate node determination module, used to determine the voting target node within a preset range according to the node historical performance data and decision conditions after the proposal verification; A vote aggregation and block generation module, used to verify and aggregate votes and generate a new block when the number of valid votes reaches the preset threshold; A blockchain network layer, as the basic network architecture, is used to build a trusted computing environment for distributed nodes and provide consistent read and write services externally through a consensus algorithm.

8. The consortium blockchain leader node selection consensus system based on historical performance evaluation according to claim 7, characterized in that, In a system with a total of n nodes, at most f nodes exhibit Byzantine faults, and the remaining nodes are normal nodes, where f < n / 3. Each node completes identity identification and message verification through a public key and private key pair.

9. The consortium blockchain leader node selection consensus system based on historical performance evaluation according to claim 7, characterized in that, The candidate node determination module determines multiple candidate nodes one by one within a preset range, and under the condition of satisfying the majority constraint, ensures that a certain node accumulates sufficient votes and continues to advance the consensus process.

Images