Grouping HotStuff Raft consensus mechanism construction method based on whole-process multi-dimensional dynamic reputation

Abstract

The invention relates to a grouping HotStuff Raft consensus mechanism construction method based on whole-process multi-dimensional dynamic reputation, and belongs to the technical field of block chains. Comprising the following steps: designing a node scoring mechanism of whole-process multi-dimensional dynamic reputation, and monitoring and evaluating the behavior and performance of each node in real time; designing a new cross grouping strategy, and grouping different nodes in the candidate node set; the nodes of each group are responsible for collecting transactions from the client and gathering the transactions to the grouped leader nodes of the group where the corresponding nodes are located; transactions of the grouped leader nodes in the HotStuff consensus stage are summarized, the transactions are quickly verified, a consensus is achieved, a client is informed that the transactions are linked, and the leader nodes in the Raft consensus stage distribute messages of achieving the consensus to the grouped leader nodes in the HotStuff consensus stage; and the grouped leader nodes in the HotStuff consensus stage return a consensus reaching message to the corresponding intra-group nodes. The method solves the problems that an existing consensus mechanism is low in throughput, insufficient in safety and high in consensus cost.

Description

Technical Field

[0001] The present invention belongs to the technical field of blockchain, 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 is widely used in many fields such as financial services, energy trade, supply chain management, and the Internet of Things, showing great application prospects and potential. The core of blockchain technology includes consensus mechanism, distributed storage, cryptography, and smart contracts. Among them, the consensus mechanism is the key to blockchain technology, which is mainly responsible for solving the consistency problem in the distributed system and ensuring that all participating nodes in the network reach a consensus on the correctness of the stored data, thereby avoiding information asymmetry and inconsistency between data copies.

[0003] The consensus mechanism is 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 of which aims to improve the reliability, security, and efficiency of the network. In particular, consensus algorithms play a vital role in dealing with 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 anti-attack capability and fault tolerance of the entire network.

[0004] Raft is another widely used consensus protocol that uses an election mechanism to ensure that all replicated log files are consistent across multiple nodes. Raft is designed to be easy to understand and implement, and it simplifies the consensus process through a clear leader and log replication mechanism. However, Raft focuses mainly on network partitions and failure recovery, and has weak resistance to Byzantine nodes (i.e. nodes that may behave maliciously).

[0005] HotStuff is a consensus protocol based on Byzantine fault tolerance, adopted by Facebook's Libra project. Its main innovation is the introduction of a module called "PaceMaker", which decouples security and liveness, allowing the system to handle different network conditions and attack scenarios more flexibly. HotStuff ensures efficient and responsive consensus through a three-phase submission process (Prepare, Pre-Commit, Commit), but it also introduces additional communication overhead and latency.

[0006] Although HotStuff and Raft each perform well in their respective application scenarios, they still have limitations in dealing with 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 finds it difficult to meet the dual needs of efficiency and security. In addition, existing consensus mechanisms often fail to fully utilize node historical behavior data, such as node reliability and reputation, which, if used reasonably, can significantly improve the overall performance and security of the system. In view of the above defects, it is necessary to develop a new consensus mechanism to address the shortcomings of existing technologies in dealing with node diversity, system scalability, and security. Summary of the invention

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

[0008] To achieve the above purpose, 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 multi-dimensional dynamic reputation throughout the entire process 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: The nodes in each group are responsible for collecting transactions from the client and aggregating the transactions to the group leader node of the corresponding node group;

[0012] S4, Raft consensus stage: Summarize the transactions of the group leader nodes in the HotStuff consensus stage, quickly verify the transactions and reach consensus, notify the client that the transaction has been uploaded to the chain, and the leader node in the Raft consensus stage distributes the consensus message to the group leader node in the HotStuff consensus stage;

[0013] S5. The leader node of the group in the HotStuff consensus phase returns the consensus message to the corresponding node 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, and 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 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 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 of all time.

[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 from high to low according to their historical behavior reputation and initialize G groups, each group is an empty list, and assign nodes to each group alternately according to 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 stage, 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 grouped 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 stage, that is, dominate daily operation and maintenance and decision support, and the middle-level consensus The node is also a participating node in the HotStuff consensus stage; the top-level consensus node has global data decision-making power. The top-level 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-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 round to the Nth round 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, but 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 to which the corresponding node belongs, the leader rotation mechanism will be triggered, that is, the group leader nodes of each group in the next round will be reselected. At this time, the group leader nodes of each group will serve as new middle-level consensus nodes.

[0022] In one embodiment of the present invention, in step S3, the method of 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 according to the node historical behavior reputation of the node, and the group leader node is selected by the roulette method. The probability formula of 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 grouping round, 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: The top-level consensus node packages the received transactions into blocks, signs and broadcasts them to all group leader nodes, which distribute them to the bottom-level consensus nodes in the group. Blocks include transaction data and status information of the previous consensus cycle. This phase ensures that all nodes have enough information to verify the validity of the proposal, including verifying the legitimacy of the transaction and the consistency of the proposal.

[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 is replaced, proposals accepted by the majority of nodes will still be considered valid, thereby preventing potential forks and inconsistent states. Each group of consensus nodes sends its decision back to the group leader node, including evidence for or against the proposal.

[0028] Commit stage: If the proposal passes the Pre-Commit stage, 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 nodes and the top-level consensus nodes 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-level consensus node and the top-level 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 of each group of confirmation 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 uses a predefined health check protocol to regularly detect the availability and responsiveness of the node;

[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 is lower than 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 concurrent control mechanism is adopted to resolve data conflicts by retaining 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 data.

[0038] In one embodiment of the present invention, a dynamic adjustment mechanism is also constructed to optimize the consensus process according to network conditions and node performance by analyzing the interactions and data flows between nodes in real time, 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 node's historical behavior reputation, 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 behavior reputation, so as to reduce the overall delay of the system and improve the 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 prior art, the present invention has the following beneficial effects: the present invention provides significantly improved consensus mechanism efficiency and system scalability, and effectively copes with complex challenges in large-scale network environments:

[0043] The invention introduces reputation scoring as a key mechanism for screening and managing nodes in the consensus process, improves the selection criteria and quality of central nodes in the consensus process, and effectively reduces the risks caused by node failure or malicious behavior. At the HotStuff layer, the leader node is dynamically elected through a real-time reputation scoring mechanism, which not only optimizes the 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 the behavior and performance of nodes, and timely adjust the composition of nodes participating in the consensus, thereby ensuring the security and fairness of the consensus process.

[0044] At the Raft layer, the present invention improves the stability and fault tolerance of the system through a refined leader election and management mechanism. By introducing a leader election based on reputation scoring at the Raft layer, it ensures that only the most reliable and best-performing nodes can play key roles, greatly reducing system interruptions caused by leader node failures or malicious behavior. In addition, combining the mechanisms of HotStuff and Raft at two levels can provide powerful fault recovery and data consistency guarantees while ensuring transaction processing efficiency, especially in the face of network partitions or node failures, it can quickly restore normal operation and maintain 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 is described in detail below in conjunction with 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 multi-dimensional dynamic reputation throughout the entire process 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: The nodes in each group are responsible for collecting transactions from the client and aggregating the transactions to the group leader node of the corresponding node group;

[0053] S4, Raft consensus stage: Summarize the transactions of the group leader nodes in the HotStuff consensus stage, quickly verify the transactions and reach consensus, notify the client that the transaction has been uploaded to the chain, and the leader node in the Raft consensus stage distributes the consensus message to the group leader node in the HotStuff consensus stage;

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

[0055] The following is the 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 historical behavior reputation is used as the node measurement standard. The node multi-dimensional reputation indicators include: node participation, historical performance, and transaction processing speed. The node historical behavior reputation calculation formula 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 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 historical behavior reputation at time t, R t ' is the node historical behavior reputation finally calculated, R min , R maxThey are the lowest node historical behavior reputation and the highest node historical behavior reputation among all the calculated node historical behavior reputations. By adding the decay coefficient and the dynamic weighting of the behavior score, the changing trend of the node behavior over time is more finely depicted, so that the evaluation results can reflect the instantaneous performance and historical reputation of the node. At the same time, normalization is performed so that the reputation value is in the [0,1] interval, which ensures the output range and smoothness of the reputation and is suitable for dynamic consensus environments.

[0060] Step S2: Filter out different nodes according to reputation, including top-level consensus nodes, middle-level consensus nodes, and bottom-level consensus nodes. Grouping is performed according to reputation value. The grouping strategy designed by the present invention aims to allocate 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 allocated 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 stage, that is, participates 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 node is the group leader node of each group; the middle-level consensus node participates in the Raft consensus stage, that is, it leads daily operation and maintenance and decision support. The middle-level consensus node is also a participating node in the HotStuff consensus stage; the top-level consensus node has global data decision-making power. The top-level consensus node is the leader node in the Raft consensus stage and also a participating node in the HotStuff consensus stage. In the leader rotation of the HotStuff consensus stage, 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 round of consensus to the Nth round of consensus, due to the selection of the group leader node, 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 the bottom-level consensus node).

[0061] Generally, the top-level consensus node does not rotate, but 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. The nodes of each group in the HotStuff layer are responsible for collecting transactions from clients and aggregating the transactions to the group leader node of the group to which the node belongs. 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 reputation value of the node, and a new group leader is selected using the roulette method. At this time, the group leader node of each group serves as the new middle-layer consensus node. The probability formula for the 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 grouping round, and η is a tuning parameter used to control the node’s historical behavior reputation R t 'Influence on the probability of election. A high η value will make the probability of high-reputation nodes being selected much greater than that of low-reputation nodes. 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 uploaded to 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 includes the following steps:

[0068] Step 1: Prepare phase: In this phase, the top-level consensus node packages the received transactions into blocks, signs and broadcasts them to all HotStuff layer leader nodes, which distribute them to the bottom-level consensus nodes in the group. Blocks include transaction data and status information of the previous consensus cycle. This phase ensures that all nodes have enough 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: In this phase, the underlying consensus nodes of the HotStuff layer begin to reach consensus on the received block proposals and lock the proposals. This locking mechanism ensures that even if the leader changes, the proposals accepted by the majority of nodes will still be considered valid, thereby preventing potential forks and inconsistent states. The node sends its decision back to the leader node, including evidence for or against the proposal.

[0070] Step 3: Commit stage: In the Commit stage, if the proposal passes the Pre-Commit stage, the underlying consensus node of the HotStuff layer will send a message supporting the proposal to the leader node of the HotStuff layer. Each node of the HotStuff layer will record the confirmed proposal to the 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-level consensus nodes and top-level consensus nodes in the Raft layer have received 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 verification signature is successful, the leader node of the Raft layer (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 of the Raft layer (i.e., the middle-level consensus nodes). The remaining nodes of the Raft layer will then notify the bottom-level consensus nodes of the information that the block is on the chain.

[0075] The present invention adopts the above technical solution, and proposes a grouped HotStuff-Raft consensus mechanism based on the whole process multi-dimensional dynamic reputation to improve the scalability and efficiency of consensus nodes in the field of blockchain. The present invention divides nodes into different levels according to the reputation and behavior history of the nodes: top-level consensus nodes, middle-level consensus nodes and bottom-level consensus nodes. By introducing the HotStuff algorithm at the bottom layer, fast transaction decisions and high-priority transaction processing are achieved; the Raft algorithm is used at the middle layer to provide system stability and high availability, especially in the face of node failures or network instability, normal operation can be quickly restored.

[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 specification 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 in that: The steps include: S1. Design a node scoring mechanism with multi-dimensional dynamic reputation throughout the entire process 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 in the whole process, a new cross-grouping strategy is designed to group different nodes in the candidate node set; S3, HotStuff consensus phase: The nodes in each group are responsible for collecting transactions from the client and aggregating the transactions to the group leader node of the corresponding node group; S4, Raft consensus stage: Summarize the transactions of the group leader nodes in the HotStuff consensus stage, quickly verify the transactions and reach consensus, notify the client that the transaction has been uploaded to the chain, and the leader node in the Raft consensus stage distributes the consensus message to the group leader node in the HotStuff consensus stage; S5. The leader node of the group in the HotStuff consensus phase returns the consensus message to the corresponding node in the group.

2. According to claim 1, a method for constructing a grouped HotStuffRaft consensus mechanism based on full-process multi-dimensional dynamic reputation is 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 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 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 of all time.

3. According to claim 2, a method for constructing a grouped HotStuffRaft consensus mechanism based on full-process multi-dimensional dynamic reputation is characterized in that: 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.

4. According to claim 3, a method for constructing a grouped HotStuffRaft consensus mechanism based on full-process multi-dimensional dynamic reputation is characterized in that: Step S2 is specifically implemented 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-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 stage, 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 grouped 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 stage, that is, they dominate daily operation and maintenance and decision-making support. The middle-level consensus nodes are also participating nodes in the HotStuff consensus stage; the top-level consensus nodes have global data decision-making power. The top-level consensus nodes are the leader nodes in the Raft consensus stage and are also participating nodes in the HotStuff consensus stage. In the leader rotation in the HotStuff consensus stage, the top-level consensus nodes play the role of middle-level consensus nodes or bottom-level consensus nodes.

5. According to claim 4, a method for constructing a grouped HotStuffRaft consensus mechanism based on full-process multi-dimensional dynamic reputation 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 in each round, the leader rotation mechanism will be triggered, that is, the group leader nodes of each group in the next round will be reselected. At this time, the group leader nodes of each group will serve as new middle-level consensus nodes.

6. According to claim 5, a method for constructing a grouped HotStuffRaft consensus mechanism based on full-process multi-dimensional dynamic reputation is characterized in that: In step S3, the method of 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 according to the node historical behavior reputation of the node, and the group leader node is selected by the roulette method. The probability formula of the i-th node in each group being 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 grouping round, and η is a tuning parameter used to control the node’s historical behavior reputation R t 'Influence on election probabilities.

7. According to claim 4, a method for constructing a grouped HotStuffRaft consensus mechanism based on full-process multi-dimensional dynamic reputation 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 and broadcasts them to all group leader nodes, which then distribute them to the bottom-level consensus nodes in the group. The blocks include transaction data and status information from the previous consensus cycle. This phase ensures that all nodes have enough 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 is replaced, the proposals accepted by the majority of nodes will still be considered valid, thereby preventing potential forks and inconsistent states. Each group of underlying consensus nodes sends its decision back to the group leader node, including evidence for or against the proposal. Commit stage: If the proposal passes the Pre-Commit stage, 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.

8. According to claim 7, a method for constructing a grouped HotStuffRaft consensus mechanism based on full-process multi-dimensional dynamic reputation is characterized in that: Step S4 is specifically implemented as follows: After both the middle-level consensus nodes and the top-level consensus nodes 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-level consensus node and the top-level 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 of each group of confirmation that the block is on the chain.

9. 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 uses a predefined health check protocol to regularly detect the availability and responsiveness of the node; 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 is lower than 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 concurrent control mechanism is adopted to resolve data conflicts by retaining 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 data.

10. According to claim 1, a method for constructing a grouped HotStuffRaft consensus mechanism based on full-process multi-dimensional dynamic reputation is characterized in that: A dynamic adjustment mechanism is also built 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: 1) Implement a distributed decision-making framework that dynamically adjusts the roles and responsibilities of nodes based on real-time network conditions and the node's historical behavior reputation, 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 behavior reputation, so as to reduce the overall delay of the system and improve the 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