A method for constructing a grouped HotStuffRaft consensus mechanism based on full-process multi-dimensional dynamic reputation

Abstract

The present invention relates to a method for constructing a grouped HotStuff Raft consensus mechanism based on full-process, multi-dimensional dynamic reputation, and belongs to the field of blockchain technology. The method comprises: designing a node scoring mechanism based on full-process, multi-dimensional dynamic reputation to monitor and evaluate each node's behavior and performance in real time; designing a new cross-grouping strategy to group different nodes within a candidate node set; nodes in each group are responsible for collecting transactions from clients and aggregating them to the group leader node of the corresponding node's group; aggregating transactions from the group leader node during the HotStuff consensus phase, rapidly verifying and reaching consensus on the transactions, notifying clients that the transactions have been uploaded to the blockchain, and having the Raft consensus leader node distribute the consensus message to the HotStuff consensus group leader node; and returning the consensus message to the corresponding group node. This method addresses the problems of low throughput, insufficient security, and high consensus costs of existing consensus mechanisms.

Description

Technical Field

[0001] The present invention belongs to the field of blockchain technology, and in particular relates to a method for constructing a grouped HotStuff Raft consensus mechanism based on full-process multi-dimensional dynamic reputation. Background Art

[0002] As an advanced distributed ledger technology, blockchain has been widely used in a variety of fields, including financial services, energy trade, supply chain management, and the Internet of Things, demonstrating tremendous potential. The core of blockchain technology includes consensus mechanisms, distributed storage, cryptography, and smart contracts. Consensus mechanisms are crucial for blockchain technology, primarily addressing consistency issues within distributed systems and ensuring that all participating nodes in the network agree on the correctness of stored data, thereby avoiding information asymmetry and inconsistencies between data copies.

[0003] Consensus mechanisms are implemented through a variety of algorithms, such as Proof-of-Work (PoW), Proof-of-Stake (PoS), Delegated Proof-of-Stake (DPoS), and Byzantine Fault Tolerance (BFT). Each algorithm aims to improve network reliability, security, and efficiency. Consensus algorithms play a crucial role in addressing potential dishonest nodes or malicious attacks. In modern blockchain implementations, these consensus algorithms not only support transaction processing and data verification, but also enhance the overall network's resilience to attacks and fault tolerance.

[0004] Raft is another widely used consensus protocol that uses an election mechanism to ensure consistency across multiple nodes in the replicated log files. Designed to be easy to understand and implement, Raft simplifies the consensus process through a clear leader and log replication mechanism. However, Raft focuses primarily on network partitions and failure recovery, making it less resilient to Byzantine nodes (i.e., potentially malicious nodes).

[0005] HotStuff is a Byzantine fault-tolerant consensus protocol adopted by Facebook's Libra project. Its key innovation lies in the introduction of a module called "PaceMaker," which decouples safety and liveness, allowing the system to more flexibly handle diverse network conditions and attack scenarios. HotStuff ensures efficient and responsive consensus through a three-phase commit process (Prepare, Pre-Commit, Commit), but this also introduces additional communication overhead and latency.

[0006] While HotStuff and Raft each excel in their respective application scenarios, they still have limitations in handling a wider range of network security threats, node dynamics, and system scalability. Especially in large-scale and dynamically changing network environments, a single consensus mechanism often struggles to meet the dual requirements of efficiency and security. Furthermore, existing consensus mechanisms often fail to fully utilize historical node behavior data, such as node reliability and reputation, which, if properly utilized, can significantly improve the overall performance and security of the system. To address these shortcomings, it is necessary to develop a new consensus mechanism that addresses the shortcomings of existing technologies in handling node diversity, system scalability, and security. Summary of the Invention

[0007] The purpose of the present invention is to address the problem of poor scalability of blockchain and provide a method for constructing a grouped HotStuff Raft consensus mechanism based on full-process multi-dimensional dynamic reputation. The constructed consensus mechanism has the advantages of optimizing transaction propagation paths and reducing the consensus latency of the blockchain system, thereby solving the problems of low throughput, insufficient security and high consensus cost of existing consensus mechanisms.

[0008] To achieve the above objectives, the technical solution of the present invention is: a method for constructing a grouped HotStuff Raft consensus mechanism based on full-process multi-dimensional dynamic reputation, comprising the following steps:

[0009] S1. Design a node scoring mechanism with full-process multi-dimensional dynamic reputation to monitor and evaluate the behavior and performance of each node in real time;

[0010] S2. Based on the node scoring mechanism of multi-dimensional dynamic reputation in the whole process, a new cross-grouping strategy is designed to group different nodes in the candidate node set;

[0011] S3, HotStuff consensus phase: Nodes in each group are responsible for collecting transactions from clients and aggregating the transactions to the group leader node of the corresponding node group;

[0012] S4, Raft consensus phase: Aggregate transactions from the group leader nodes of the HotStuff consensus phase, quickly verify the transactions and reach consensus, notify the client that the transaction has been on-chain, and the leader node of the Raft consensus phase distributes the consensus message to the group leader node of the HotStuff consensus phase;

[0013] S5. The leader node of the group in the HotStuff consensus phase returns the consensus message to the corresponding nodes in the group.

[0014] In one embodiment of the present invention, in step S1, the node scoring mechanism of the whole process multi-dimensional dynamic reputation uses the node historical behavior reputation as the node measurement standard. The node historical behavior reputation calculation formula is:

[0015]

[0016] Among them, f t represents the behavior score at time t, β is the decay coefficient, which is used to balance the influence of historical behavior and the latest behavior, n is the size of the measurement time window, which represents the latest n behaviors considered in the reputation calculation, α is the behavior weighting factor, which assigns different weights to different types of behaviors according to their importance, τ is the time period, which is defined as the period length of the node behavior evaluation, γ is the shape parameter, which controls the curvature of the function, μ is the reputation baseline, and b t-i+1 is the behavior score from t-n+1 to t, α i is the weight factor of the corresponding behavior, R t is the node’s historical behavior reputation at time t, R t ’ is the node historical behavior reputation finally calculated, R min 、R max They are respectively the lowest node historical behavior reputation and the highest node historical behavior reputation among the calculated node historical behavior reputations at all times.

[0017] In one embodiment of the present invention, in step S2, different nodes in the candidate node set are grouped, that is, based on the node historical behavior reputation, different nodes in the candidate node set are divided into top-level consensus nodes, middle-level consensus nodes and bottom-level consensus nodes.

[0018] In one embodiment of the present invention, step S2 is specifically implemented as follows:

[0019] Sort all nodes by their historical behavior reputation from high to low to initialize G groups, each group is an empty list, and assign nodes to each group alternately by their historical behavior reputation from high to low; specifically, for each node i, assign it to the (i mod G)+1th group; each group will obtain nodes with high node historical behavior reputation and low node historical behavior reputation, among which the node with the highest node historical behavior reputation is selected as the top-level consensus node, the node with the highest node historical behavior reputation in each group is selected as the middle-level consensus node, and the remaining nodes are bottom-level consensus nodes; the bottom-level consensus nodes participate in the HotStuff consensus phase, that is, participate in basic transaction verification and data recording. After each round of consensus, the next round of leaders will be rotated according to the group data and node reputation information sent by the top-level consensus node. In the first round of consensus, the middle-level consensus nodes are the group leader nodes of each group; the middle-level consensus nodes participate in the Raft consensus phase, that is, dominate daily operations and decision support, and the middle-level consensus The node is also a participating node in the HotStuff consensus phase; the top-level consensus node has global data decision-making power. The top-level consensus node is the leader node in the Raft consensus phase and is also a participating node in the HotStuff consensus phase. In the leader rotation in the HotStuff consensus phase, the top-level consensus node plays the role of a middle-level consensus node or a bottom-level consensus node (in the first round of consensus, the top-level consensus node plays the role of a middle-level consensus node. In the second to Nth rounds of consensus, due to the selection of group leader nodes, the top-level consensus node may not be the group leader node of its own group, that is, it is not a middle-level consensus node. At this time, the top-level consensus node plays the role of a bottom-level consensus node).

[0020] Generally, the top-level consensus node does not rotate. However, if the top-level consensus node itself times out or crashes, the middle-level consensus node will elect itself as the new top-level consensus node based on the Raft heartbeat timeout mechanism.

[0021] In one embodiment of the present invention, in step S3, after completing a round of consensus by aggregating transactions to the group leader node of the group where the corresponding node is located, the leader rotation mechanism will be triggered, that is, the group leader node of each group in the next round will be reselected. At this time, the group leader node of each group will serve as the new middle-level consensus node.

[0022] In one embodiment of the present invention, in step S3, the method for selecting the group leader node of each group in the next round is: the probability of the corresponding node being selected as the group leader node is calculated based on the node's node historical behavior reputation, and the group leader node is selected using the roulette method. The probability formula for the i-th node in each group being selected as the group leader node is:

[0023]

[0024] Among them, P i represents the probability that the i-th node becomes the leader node of the next group, and η is a tuning parameter used to control the node’s historical behavior reputation R t 'Influence on election probabilities.

[0025] In one embodiment of the present invention, step S3 is specifically implemented as follows:

[0026] Prepare phase: Top-level consensus nodes package received transactions into blocks, sign them, and broadcast them to all group leader nodes. Group leader nodes then distribute them to lower-level consensus nodes within the group. Blocks include transaction data and status information from the previous consensus cycle. This phase ensures that all nodes have sufficient information to verify the validity of proposals, including verifying the legitimacy of transactions and the consistency of proposals.

[0027] Pre-Commit phase: The underlying consensus nodes begin to reach consensus on the received block proposals and lock the proposals. This locking mechanism ensures that even if the leader changes, proposals accepted by the majority of nodes will still be considered valid, thus preventing potential forks and state inconsistencies. Each group of consensus nodes sends its decision back to the group leader node, including evidence for or against the proposal.

[0028] Commit phase: If the proposal passes the Pre-Commit phase, the underlying consensus node will send a message supporting the proposal to the group leader node. The underlying consensus node will record the confirmed proposal in the local log and prepare to apply it to the state machine.

[0029] In one embodiment of the present invention, step S4 is specifically implemented as follows:

[0030] After both the middle-level consensus node and the top-level consensus node receive the proposal request from step S3, these nodes will verify whether the signature content of the block is correct;

[0031] If the signature is missing or incorrect, the middle-layer consensus node and the top-layer consensus node will report the group leader node to the member management service MMS. MMS is part of the consortium chain and is responsible for issuing certificates and managing members.

[0032] If the verification signature passes, the top-level consensus node will broadcast the block to other nodes in its group. Subsequently, after receiving confirmation messages from half or more of the nodes in the group, it will confirm that the block is on the chain and notify the client and the group leader node. The group leader node will then notify the bottom-level consensus nodes in each group of the information that the block is on the chain.

[0033] In one embodiment of the present invention, a fault-tolerance mechanism is also constructed for automatically performing the following operations when a node failure or data inconsistency is detected:

[0034] 1) The system monitors the status and performance indicators of each node and regularly checks the availability and responsiveness of the node using a predefined health check protocol;

[0035] 2) When a node fails to respond or the response time exceeds the set threshold, the node is automatically marked as unreliable and the node's historical behavior reputation is reduced. When the node's historical behavior reputation falls below the minimum threshold, it is isolated from the current consensus process;

[0036] 3) Based on the node's historical behavior reputation and historical performance, a node with higher historical behavior reputation is selected from the backup nodes to replace the isolated node to ensure the integrity of the consensus layer and the continuity of operations;

[0037] 4) In the case of data inconsistency, a multi-version concurrency control mechanism is adopted to resolve data conflicts by retaining the historical versions of data modifications. At the same time, nodes with high node historical behavior reputation are used to verify and correct data to ensure the ultimate consistency of the data.

[0038] In one embodiment of the present invention, a dynamic adjustment mechanism is also constructed to optimize the consensus process based on network conditions and node performance by analyzing the interactions and data flows between nodes in real time. The details are as follows:

[0039] 1) Implement a distributed decision-making framework that dynamically adjusts the roles and responsibilities of nodes based on real-time network conditions and the reputation of their historical behavior, optimizing the workload of nodes during the consensus process;

[0040] 2) Use a reputation-based load balancing algorithm to direct more requests and data to nodes with high historical reputations, thereby reducing overall system latency and increasing processing speed;

[0041] 3) When network topology or node behavior changes significantly, the system can automatically reconfigure the connection and data routing strategies between nodes to ensure the efficiency and security of data transmission.

[0042] Compared with the existing technology, the present invention has the following beneficial effects: the present invention provides significantly improved consensus mechanism efficiency and system scalability, effectively coping with complex challenges in large-scale network environments:

[0043] By introducing reputation scoring as a key mechanism for screening and managing nodes during the consensus process, this invention improves the selection criteria and quality of central nodes during the consensus process, effectively reducing the risks caused by node failure or malicious behavior. At the HotStuff layer, a real-time reputation scoring mechanism dynamically elects leader nodes, which not only optimizes communication efficiency between nodes but also strengthens the system's ability to adapt to network changes. In addition, the reputation scoring mechanism can continuously monitor node behavior and performance, and promptly adjust the composition of nodes participating in the consensus, thereby ensuring the security and fairness of the consensus process.

[0044] At the Raft layer, this invention improves system stability and fault tolerance through a refined leader election and management mechanism. By introducing reputation-based leader election at the Raft layer, it ensures that only the most reliable and top-performing nodes are selected for key roles, significantly reducing system outages caused by leader node failures or malicious behavior. Furthermore, combining the mechanisms of HotStuff and Raft ensures transaction processing efficiency while providing robust fault recovery and data consistency. This allows for rapid recovery from network partitions or node failures, maintaining high system availability and data consistency.

[0045] The analysis shows that the grouped HotStuff-Raft consensus mechanism based on the whole-process multi-dimensional dynamic reputation of the present invention is more efficient and has better application and promotion effects. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 This is a diagram of the blockchain network node architecture;

[0047] Figure 2 This is a flowchart of the blockchain consensus mechanism based on HotStuff-Raft. DETAILED DESCRIPTION

[0048] The technical solution of the present invention will be described in detail below with reference to the accompanying drawings.

[0049] The present invention provides a method for constructing a grouped HotStuff Raft consensus mechanism based on full-process multi-dimensional dynamic reputation, comprising the following steps:

[0050] S1. Design a node scoring mechanism with full-process multi-dimensional dynamic reputation to monitor and evaluate the behavior and performance of each node in real time;

[0051] S2. Based on the node scoring mechanism of multi-dimensional dynamic reputation in the whole process, a new cross-grouping strategy is designed to group different nodes in the candidate node set;

[0052] S3, HotStuff consensus phase: Nodes in each group are responsible for collecting transactions from clients and aggregating the transactions to the group leader node of the corresponding node group;

[0053] S4, Raft consensus phase: Aggregate transactions from the group leader nodes of the HotStuff consensus phase, quickly verify the transactions and reach consensus, notify the client that the transaction has been on-chain, and the leader node of the Raft consensus phase distributes the consensus message to the group leader node of the HotStuff consensus phase;

[0054] S5. The leader node of the group in the HotStuff consensus phase returns the consensus message to the corresponding nodes in the group.

[0055] The following is a specific implementation process of the present invention.

[0056] like Figure 1 、 2 As shown, the present invention discloses a method for constructing a grouped HotStuff Raft consensus mechanism based on full-process multi-dimensional dynamic reputation, which includes the following steps:

[0057] Step S1: The node's historical behavior reputation is used as a measurement standard for the node. The node's multi-dimensional reputation indicators include: node participation, historical performance, and transaction processing speed. The calculation formula for node historical behavior reputation is:

[0058]

[0059] Among them, f t represents the behavior score at time t, β is the decay coefficient, which is used to balance the influence of historical behavior and the latest behavior, n is the size of the measurement time window, which represents the latest n behaviors considered in the reputation calculation, α is the behavior weighting factor, which assigns different weights to different types of behaviors according to their importance, τ is the time period, which is defined as the period length of the node behavior evaluation, γ is the shape parameter, which controls the curvature of the function, μ is the reputation baseline, and b t-i+1 is the behavior score from t-n+1 to t, α i is the weight factor of the corresponding behavior, R t is the node’s historical behavior reputation at time t, R t ' is the final calculated node historical behavior reputation, R min 、R maxThe lowest and highest node reputations are calculated for all time periods. By incorporating a decay coefficient and dynamically weighted behavior scores, we more precisely depict the changing trends of node behavior over time, allowing the evaluation results to reflect both the node's immediate performance and historical reputation. Normalization is also performed to keep the reputation value within the [0, 1] range, ensuring a smooth and ranged reputation output, suitable for dynamic consensus environments.

[0060] Step S2: Filter out different nodes based on reputation, including top-level consensus nodes, middle-level consensus nodes, and bottom-level consensus nodes. Grouping is performed based on reputation value. The grouping strategy designed by the present invention aims to distribute nodes with high and low reputation values ​​in a cross-wise manner, so as to balance the overall reputation level of each group and reduce the risk of concentrated influence of malicious nodes. First, all nodes are sorted from high to low according to reputation value to initialize G groups. Each group is an empty list, and the nodes are alternately distributed to each group according to reputation value from high to low. Specifically, for each node i, it is assigned to group (i mod G) + 1. Each group will obtain nodes with high and low reputation. For example, the first node (with the highest reputation) is assigned to group 1, the second node is assigned to group 2, until the Gth node is assigned to group G, and the G+1th node returns to group 1 again, and so on. The node with the highest reputation value is selected as the top-level consensus node, the node with the highest reputation value in each group is selected as the middle-level consensus node, and the remaining nodes are bottom-level consensus nodes; the bottom-level consensus node participates in the HotStuff consensus phase, that is, participates in basic transaction verification and data recording. After each round of consensus, the leader of the next round will be rotated based on the group data and node reputation information sent by the top-level consensus node. In the first round of consensus, the middle-level consensus node is the group leader node of each group; the middle-level consensus node participates in the Raft consensus phase, that is, it leads daily operations and decision support. The middle-level consensus node is also a participating node in the HotStuff consensus phase; the top-level consensus node has global data decision-making power. The top-level consensus node is the leader node in the Raft consensus phase and is also a participating node in the HotStuff consensus phase. In the leader rotation of the HotStuff consensus phase, the top-level consensus node plays the role of the middle-level consensus node or the bottom-level consensus node (in the first round of consensus, the top-level consensus node plays the role of the middle-level consensus node. In the second to Nth rounds of consensus, due to the selection of group leader nodes, the top-level consensus node may not be the group leader node of its own group, that is, it is not a middle-level consensus node. In this case, the top-level consensus node plays the role of the bottom-level consensus node).

[0061] Generally, the top-level consensus node does not rotate. However, if the top-level consensus node itself times out or crashes, the middle-level consensus node will elect itself as the new top-level consensus node based on the Raft heartbeat timeout mechanism.

[0062] Step S3: After the grouping is completed, the HotStuff consensus phase begins. Nodes in each group of the HotStuff layer are responsible for collecting transactions from clients and aggregating them to the group leader node of the node's group. When the first-layer consensus is reached, the leader rotation mechanism is triggered. The probability of being selected as the leader in the next round is calculated based on the node's reputation. A roulette wheel method is used to select a new group leader. At this time, the group leader node of each group serves as the new middle-layer consensus node. The probability formula for a node being selected as the leader in the next round is:

[0063]

[0064] Among them, P i represents the probability that the i-th node becomes the leader node of the next group, and η is a tuning parameter used to control the node’s historical behavior reputation R t 'Influence on the election probability. A high η value will make the probability of high-reputation nodes being selected much greater than that of low-reputation nodes. It is the sum of the reputation values ​​of all nodes that have undergone the same processing, ensuring that P i is a probability distribution.

[0065] Step S4: Entering the Raft consensus phase, the leader node of the Raft layer aggregates the transactions of the leader nodes of each HotStuff group, quickly verifies the transactions and reaches a consensus, notifies the client that the transaction has been put on the chain, and the leader node of the Raft layer distributes the consensus message to the leader nodes of each HotStuff group;

[0066] Step S5: The leader of each HotStuff layer returns the consensus message to the nodes in the group. At this point, the two-stage consensus ends.

[0067] Further: The HotStuff consensus phase consists of the following steps:

[0068] Step 1: Prepare: In this phase, top-level consensus nodes package received transactions into blocks, sign them, and broadcast them to all HotStuff leader nodes. The HotStuff leader nodes then distribute them to the bottom-level consensus nodes within the group. Blocks contain transaction data and state information from the previous consensus cycle. This phase ensures that all nodes have sufficient information to verify the validity of the proposal, including verifying the legitimacy of the transaction and the consistency of the proposal.

[0069] Step 2: Pre-Commit Phase: During this phase, HotStuff's underlying consensus nodes begin reaching consensus on received block proposals and locking them. This locking mechanism ensures that proposals accepted by a majority of nodes remain valid even in the event of a leader change, preventing potential forks and inconsistent states. Nodes send their decisions back to the leader node, including evidence supporting or opposing the proposal.

[0070] Step 3: Commit Phase: In the Commit phase, if the proposal passes the Pre-Commit phase, the HotStuff layer's underlying consensus nodes will send a message supporting the proposal to the HotStuff layer's leader node. Each HotStuff layer node will record the confirmed proposal in its local log and prepare to apply it to the state machine.

[0071] Further: The Raft consensus phase includes the following steps:

[0072] Step 1: After the middle-layer consensus nodes and top-layer consensus nodes in the Raft layer receive the proposal request from the HotStuff layer, these nodes will verify whether the signature content of the block is correct;

[0073] Step 2: If the signature is missing or incorrect, the Raft layer node will report the HotStuff layer leader node to the Member Management Service (MMS). MMS is part of the consortium chain and is responsible for issuing certificates and managing members.

[0074] Step 3: If the signature verification is successful, the Raft layer leader node (i.e., the top-level consensus node) will broadcast the block to other nodes in its group. Subsequently, after receiving confirmation messages from half or more of the nodes in the group, it will confirm that the block is on the chain and notify the client and the remaining nodes in the Raft layer (i.e., the middle-level consensus nodes). The remaining nodes in the Raft layer will then notify the bottom-level consensus nodes of the information that the block is on the chain.

[0075] This paper, employing the above technical solutions, proposes a grouped HotStuff-Raft consensus mechanism based on full-process, multi-dimensional dynamic reputation to improve the scalability and efficiency of consensus nodes in the blockchain field. This mechanism categorizes nodes into different tiers: top-tier consensus nodes, mid-tier consensus nodes, and bottom-tier consensus nodes, based on their reputation and historical behavior. By introducing the HotStuff algorithm at the bottom tier, this mechanism enables rapid transaction decision-making and processing of high-priority transactions. The Raft algorithm at the middle tier provides system stability and high availability, enabling rapid recovery from node failures or network instability.

[0076] The above descriptions are merely embodiments of the present invention and are not intended to limit the patent scope of the present invention. Any equivalent transformations made using the contents of the present invention's description and drawings, or directly or indirectly applied in related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A method for constructing a grouped HotStuffRaft consensus mechanism based on full-process multi-dimensional dynamic reputation, characterized by: The steps include: S1. Design a node scoring mechanism with full-process multi-dimensional dynamic reputation to monitor and evaluate the behavior and performance of each node in real time; S2. Based on the node scoring mechanism of multi-dimensional dynamic reputation throughout the entire process, a new cross-grouping strategy is designed to group different nodes in the candidate node set. That is, based on the node's historical behavior reputation, different nodes in the candidate node set are divided into top-level consensus nodes, middle-level consensus nodes, and bottom-level consensus nodes. The specific implementation is as follows: Sort all nodes by their historical behavior reputation from high to low to initialize G groups, each group is an empty list, and assign nodes to each group alternately from high to low according to their historical behavior reputation; Specifically, for each node i, it is assigned to the (i mod G)+1th group; each group will obtain nodes with high node historical behavior reputation and low node historical behavior reputation, among which the node with the highest node historical behavior reputation is selected as the top consensus node, the node with the highest node historical behavior reputation in each group is selected as the middle consensus node, and the remaining nodes are bottom consensus nodes; the bottom consensus node participates in the HotStuff consensus stage, that is, participates in basic transaction verification and data recording. After each round of consensus, the leader of the next round will be rotated according to the group data and node reputation information sent by the top consensus node. In the first round of consensus, the middle consensus node is the group leader node of each group; the middle consensus node participates in the Raft consensus stage, that is, dominates daily operation and decision support. The middle consensus node is also a participating node in the HotStuff consensus stage; the top consensus node has global data decision-making power. The top consensus node is the leader node in the Raft consensus stage and is also a participating node in the HotStuff consensus stage. In the leader rotation in the HotStuff consensus stage, the top consensus node plays the role of a middle consensus node or a bottom consensus node; S3, HotStuff consensus phase: Nodes in each group are responsible for collecting transactions from clients and aggregating the transactions to the group leader node of the corresponding node group; S4, Raft consensus phase: Aggregate transactions from the group leader nodes of the HotStuff consensus phase, quickly verify the transactions and reach consensus, notify the client that the transaction has been on-chain, and the leader node of the Raft consensus phase distributes the consensus message to the group leader node of the HotStuff consensus phase; S5. The leader node of the group in the HotStuff consensus phase returns the consensus message to the corresponding nodes in the group.

2. A method for constructing a grouped HotStuffRaft consensus mechanism based on full-process multi-dimensional dynamic reputation according to claim 1, characterized in that: In step S1, the node scoring mechanism of the whole process multi-dimensional dynamic reputation uses the node historical behavior reputation as the node measurement standard. The node historical behavior reputation calculation formula is: Among them, f t represents the behavior score at time t, β is the decay coefficient, which is used to balance the influence of historical behavior and the latest behavior, n is the size of the measurement time window, which represents the latest n behaviors considered in the reputation calculation, α is the behavior weighting factor, which assigns different weights to different types of behaviors according to their importance, τ is the time period, which is defined as the period length of the node behavior evaluation, γ is the shape parameter, which controls the curvature of the function, μ is the reputation baseline, and b t-i+1 is the behavior score from time t-n+1 to t, α i is the weight factor of the corresponding behavior, R t is the node’s historical behavior reputation at time t, R t ’ is the node historical behavior reputation finally calculated, R min 、R max They are respectively the lowest node historical behavior reputation and the highest node historical behavior reputation among the calculated node historical behavior reputations at all times.

3. The method for constructing a grouped HotStuffRaft consensus mechanism based on full-process multi-dimensional dynamic reputation according to claim 1 is characterized in that: In step S3, after completing a round of consensus by aggregating transactions to the group leader node of the corresponding node group, the leader rotation mechanism will be triggered, that is, the group leader node of each group in the next round will be reselected. At this time, the group leader node of each group will serve as the new middle-level consensus node.

4. A method for constructing a grouped HotStuffRaft consensus mechanism based on full-process multi-dimensional dynamic reputation according to claim 3, characterized in that: In step S3, the method for selecting the group leader node of each group in the next round is: the probability of the corresponding node being selected as the group leader node is calculated based on the node's historical behavior reputation, and the group leader node is selected using the roulette method. The probability formula for the i-th node in each group to be selected as the group leader node is: Among them, P i represents the probability that the i-th node becomes the leader node of the next group, and η is a tuning parameter used to control the node’s historical behavior reputation R t 'Influence on election probabilities.

5. The method for constructing a grouped HotStuffRaft consensus mechanism based on full-process multi-dimensional dynamic reputation according to claim 4 is characterized in that: Step S3 is specifically implemented as follows: Prepare phase: The top-level consensus node packages the received transactions into blocks, signs them, and broadcasts them to all group leader nodes. The group leader nodes then distribute them to the bottom-level consensus nodes within the group. Blocks include transaction data and status information from the previous consensus cycle. This phase ensures that all nodes have sufficient information to verify the validity of the proposal, including verifying the legitimacy of the transaction and the consistency of the proposal; Pre-Commit phase: The underlying consensus nodes begin to reach consensus on the received block proposals and lock the proposals. This locking mechanism ensures that even if the leader changes, proposals accepted by the majority of nodes will still be considered valid, thus preventing potential forks and state inconsistencies. Each group of underlying consensus nodes sends its decision back to the group leader node, including evidence for or against the proposal. Commit phase: If the proposal passes the Pre-Commit phase, the underlying consensus node will send a message supporting the proposal to the group leader node. The underlying consensus node will record the confirmed proposal in the local log and prepare to apply it to the state machine.

6. A method for constructing a grouped HotStuffRaft consensus mechanism based on full-process multi-dimensional dynamic reputation according to claim 5, characterized in that: Step S4 is specifically implemented as follows: After both the middle-level consensus node and the top-level consensus node receive the proposal request from step S3, these nodes will verify whether the signature content of the block is correct; If the signature is missing or incorrect, the middle-layer consensus node and the top-layer consensus node will report the group leader node to the member management service MMS. MMS is part of the consortium chain and is responsible for issuing certificates and managing members. If the verification signature passes, the top-level consensus node will broadcast the block to other nodes in its group. Subsequently, after receiving confirmation messages from half or more of the nodes in the group, it will confirm that the block is on the chain and notify the client and the group leader node. The group leader node will then notify the bottom-level consensus nodes in each group of the information that the block is on the chain.

7. The method for constructing a grouped HotStuffRaft consensus mechanism based on full-process multi-dimensional dynamic reputation according to claim 1 is characterized in that: A fault-tolerance mechanism is also built to automatically perform the following operations when a node failure or data inconsistency is detected: 1) The system monitors the status and performance indicators of each node and regularly checks the availability and responsiveness of the node using a predefined health check protocol; 2) When a node fails to respond or the response time exceeds the set threshold, the node is automatically marked as unreliable and the node's historical behavior reputation is reduced. When the node's historical behavior reputation falls below the minimum threshold, it is isolated from the current consensus process; 3) Based on the node's historical behavior reputation and historical performance, a node with higher historical behavior reputation is selected from the backup nodes to replace the isolated node to ensure the integrity of the consensus layer and the continuity of operations; 4) In the case of data inconsistency, a multi-version concurrency control mechanism is adopted to resolve data conflicts by retaining the historical versions of data modifications. At the same time, nodes with high node historical behavior reputation are used to verify and correct data to ensure the ultimate consistency of the data.

8. The method for constructing a grouped HotStuffRaft consensus mechanism based on full-process multi-dimensional dynamic reputation according to claim 1 is characterized in that: We also build a dynamic adjustment mechanism that optimizes the consensus process based on network conditions and node performance by analyzing the interactions and data flows between nodes in real time. The details are as follows: 1) Implement a distributed decision-making framework that dynamically adjusts the roles and responsibilities of nodes based on real-time network conditions and the reputation of their historical behavior, optimizing the workload of nodes during the consensus process; 2) Use a reputation-based load balancing algorithm to direct more requests and data to nodes with high historical reputation, thereby reducing overall system latency and improving processing speed; 3) When network topology or node behavior changes significantly, the system can automatically reconfigure the connection and data routing strategies between nodes to ensure the efficiency and security of data transmission.

Images