Method for collaborative optimization of reputation-driven layered consensus and adaptive sharding

Abstract

The application relates to a collaborative optimization method based on a reputation-driven layered consensus and adaptive sharding, and belongs to the field of blockchains. Firstly, a node reputation evaluation model based on multiple-dimensional indexes such as response performance is constructed. In view of the characteristics of heterogeneous and dynamic changes of nodes of a consortium chain, relevant features such as network topology, business semantics and organizational trust are extracted, spectrum clustering and a greedy optimization architecture are adopted to dynamically divide sharding, layered consensus driven by reputation is taken as a collaborative auxiliary, and a consortium chain performance optimization framework with deep fusion of consensus and sharding is constructed. Through multi-dimensional feature fusion and adaptive adjustment of nodes, efficient consensus and load balancing of a large-scale consortium chain network are realized. The collaborative optimization method proposed by the application has important significance for improving the throughput and expansibility of the consortium chain, and the constructed framework achieves higher transaction throughput and lower cross-sharding communication overhead than a baseline model in a dynamic network environment.

Description

Technical Field

[0001] This invention relates to the field of blockchain, and in particular to a collaborative optimization method based on reputation-driven hierarchical consensus and adaptive sharding. Background Technology

[0002] Blockchain technology, as a decentralized distributed ledger system, relies on cryptographic mechanisms to ensure the immutability and traceability of data. Its core lies in guaranteeing data consistency among multiple nodes through a consensus mechanism. In consortium blockchain scenarios, Byzantine fault-tolerant consensus algorithms are often used to meet the business requirements of high reliability and low latency. However, as the number of nodes increases, the multiple rounds of interaction between nodes during the consensus process lead to significant communication and computational overhead. Meanwhile, to overcome the limitations of single-chain structures in terms of throughput and scalability, sharding technology has been introduced to achieve parallel processing. By dividing the network into multiple subsets, different shards can concurrently execute transaction verification and block generation, thereby improving the overall system performance.

[0003] Existing research on consortium blockchain performance optimization addresses several issues. In terms of consensus, while methods like grouping, reputation assessment, and process optimization reduce communication complexity, achieving a balance between dynamic node changes and system stability remains challenging. Regarding sharding, methods such as random sharding and graph partitioning enhance parallelism, but these generally suffer from high cross-shard communication overhead, uneven load distribution, and security vulnerabilities. Furthermore, most existing research focuses on optimizing either the consensus mechanism or the sharding mechanism individually, lacking a unified design approach that simultaneously addresses consensus efficiency and sharding quality. Especially in the dynamic network environment of consortium blockchains, traditional sharding methods often fail to adapt to the post-sharding consensus structure, and traditional consensus optimization methods struggle to fully leverage the performance advantages of sharding parallelism, resulting in limitations on overall system throughput, latency, and scalability. Therefore, developing a collaborative optimization method that reduces consensus communication complexity while decreasing the proportion of cross-shard transactions, and further improves overall consortium blockchain throughput and system robustness, remains a pressing technical challenge. Summary of the Invention

[0004] The purpose of this invention is to provide a collaborative optimization method based on reputation-driven hierarchical consensus and adaptive sharding, which solves the technical difficulties of traditional consortium blockchains, such as low consensus efficiency, high cross-shard communication overhead, and easy confusion due to uneven load distribution, when scaling up. It also effectively addresses the technical challenges of high communication complexity and difficulty in ensuring security in dynamic environments inherent in traditional consensus algorithms. This invention constructs a multi-dimensional node reputation evaluation model, realizing dynamic hierarchical management and reliability measurement of consortium blockchain nodes. It fully considers the important role of node heterogeneity and multi-dimensional correlation characteristics in the system's parallel processing capabilities, and employs spectral clustering and greedy optimization architecture to analyze the business semantics and organizational trust correlations between different nodes. Simultaneously, it uses hierarchical consensus tasks as a collaborative aid, effectively improving the transaction throughput and scalability of large-scale consortium blockchain systems.

[0005] The above-mentioned objective of the present invention is achieved through the following technical solution:

[0006] Based on a reputation-driven, hierarchical consensus and adaptive sharding collaborative optimization method, this paper first constructs a multi-dimensional node reputation evaluation model covering response performance, transaction completion rate, and activity, classifying node reputation levels. Then, using appropriate algorithms, it extracts network topology features, business semantic features, and organizational trust features among nodes in the consortium blockchain network, designing a consortium blockchain performance optimization framework that deeply coordinates hierarchical consensus and dynamic adaptive sharding. The steps include:

[0007] Step 1: Construct a multi-dimensional node reputation assessment model: The system conducts a comprehensive reputation assessment of each node in the entire network at a fixed period. The assessment indicators include response performance, transaction completion rate, and activity. The comprehensive reputation value of a node is defined as the weighted sum of each sub-indicator, which is then normalized and smoothed.

[0008] Step 2: Implement a hierarchical consensus mechanism based on reputation assessment (CBG-PBFT). Based on the comprehensive reputation value of the nodes obtained in Step 1, a hierarchical consensus mechanism is designed to reduce communication complexity and enhance security.

[0009] Step 3: Implement Dynamic Adaptive Sharding HADS Based on Reputation and Multidimensional Association: Use the comprehensive reputation value of the nodes in Step 1 as the core input of "organizational trust association degree", and integrate network topology and business semantics to construct a comprehensive node association degree model for dynamic sharding;

[0010] Step 4: Construct a collaborative optimization framework and multi-task processing flow, deeply integrating the consensus mechanism of Step 2 with the sharding method of Step 3 to form a complete consortium blockchain performance optimization framework.

[0011] The comprehensive credit assessment described in step 1 has the following response performance indicators. The calculation formula is:

[0012]

[0013] In the formula, This indicates the response time of a node in processing a single request, in milliseconds. This represents the average response time of the node within the statistics window. The standard deviation of node response time. This indicates the time interval since the last valid response. For smoothing factor and decay factor, It is a very small positive number;

[0014] The transaction completion rate metric The calculation formula is:

[0015] In the formula, This indicates the number of transactions successfully processed by the node. This represents the total number of transactions the node participated in; Assign weights based on the importance of the transaction; , is the slope control parameter of the Sigmoid curve; , is the sample size threshold; The maximum penalty coefficient;

[0016] The activity index The calculation formula is:

[0017]

[0018] In the formula, This indicates the cumulative online time of a node within the statistical period. Indicates the total duration of the statistical period. This indicates the number of times a node went offline abnormally within the statistical period. This is the penalty coefficient for a single offline transaction.

[0019] The overall credit score is the weighted sum of three indicators:

[0020]

[0021] In the formula, This represents the weighting coefficient of each indicator, satisfying... ;

[0022] Perform Min-Max normalization on all nodes in the entire network:

[0023]

[0024] In the formula, This represents the minimum and maximum original reputation values ​​of all nodes. It is a very small positive number;

[0025] Reputation score is updated using an exponential moving average:

[0026]

[0027] In the formula, This represents the smoothed credit score from the previous period. As a smoothing factor, This represents the final reputation value for the current period.

[0028] The layered consensus mechanism described in step 2 further includes:

[0029] Step 2.1: Reputation Grouping Strategy: The total number of nodes in the network is... The expected number of groups is Nodes are sorted in descending order of reputation value, and then distributed using a round-robin method. In the groups, each group has a size of ;

[0030] Step 2.2: Intra-group Reputation-Driven Communication Tree Construction: Within each group g, a binary tree communication topology is constructed based on reputation values. Specifically...

[0031] (1) Sort the nodes in the group in descending order of reputation value;

[0032] (2) The first node (with the highest reputation) is the root node;

[0033] (3) For the i-th node after sorting (i starts from 1), its left child node index is 2i and its right child node index is 2i+1 (if the index does not exceed the number of nodes in the group).

[0034] Step 2.3: Reputation-Weighted Voting Mechanism: In intra-group and inter-group consensus voting, node weights are introduced. These weights are proportional to the node's reputation value, and the formula is as follows:

[0035]

[0036] In the formula, Represents a node Voting weight, Represents a node Current reputation value Represents the set of nodes participating in the vote;

[0037] Representing nodes Represents a node The current reputation value.

[0038] The weighted voting threshold required to reach a consensus is:

[0039]

[0040] In the formula, The set of nodes that voted in favor;

[0041] Step 2.4: Consensus process: including local consensus within a group, global consensus between groups, and result write-back and state update;

[0042] Step 2.5: Dynamic Node Management: This includes mechanisms for adding new nodes, handling faulty or malicious nodes, and reputation restoration.

[0043] The reputation restoration described in step 2.5 adopts a linear recovery model:

[0044]

[0045] In the formula, This indicates that the initial reputation value has been restored. Indicates the recovery rate. Indicates the number of recovery steps (rounds).

[0046] The dynamic adaptive sharding described in step 3 further includes:

[0047] Step 3.1: Node Relationship Model Definition: The consortium blockchain network is a graph. ,in A set of nodes; nodes and Overall correlation between Defined as a weighted sum of three components:

[0048]

[0049] In the formula, , For structural correlation, For business semantic relevance, To assess organizational trust and relevance;

[0050] The structural correlation The calculation formula is:

[0051]

[0052] In the formula, Represents a node The set of neighboring nodes, Represents a node The set of neighboring nodes, Indicates the number of common neighbors. Represents a node and The frequency of direct communication between them.

[0053] The business semantic relevance The calculation formula is:

[0054]

[0055] In the formula, Represents a node Process the frequency vector of transaction types over a period of time; Represents a node Process the frequency vector of transaction types over a period of time.

[0056] The organizational trust correlation The calculation formula is:

[0057]

[0058] In the formula, Indicates the organization identifier to which the node belongs. Represents a node Organizational identifier For a predefined cooperation trust coefficient, As the attenuation factor, This represents a comprehensive score based on the node reputation value obtained in step 1, where and They are nodes and The final reputation value calculated in step 1 .

[0059] Step 3.2: Formalizing the partitioning problem: Transform the node set... Divided into Each segment The goal is to maximize the sum of the comprehensive correlation within each shard while satisfying load balancing constraints, organizational distribution constraints, and minimum shard size constraints.

[0060] Step 3.3: Initial partitioning: Initial partitioning is generated using a spectral clustering algorithm that integrates correlations;

[0061] Step 3.4: Dynamic adjustment: Online adjustment based on greedy optimization of modularity gain.

[0062] The objective function for piecewise optimization described in step 3.2 is:

[0063]

[0064] In the formula, This represents a sharding scheme, that is, a set of nodes. A type of division, denoted as ,in Indicates the first Each shard represents all possible sharding schemes. In the process, find the solution that maximizes the objective function. For sharded indexes, from arrive This is used to iterate through each shard; This represents any two distinct nodes; Represents a node With nodes The overall correlation between them.

[0065] The load balancing constraints are as follows:

[0066]

[0067] In the formula, This represents the allowable load deviation rate, typically taken as... ;

[0068] The organizational distribution constraint is:

[0069]

[0070] In the formula, Indicates the maximum number of nodes in the organization; Refers to a specific organization.

[0071] The minimum fragment size constraint is:

[0072]

[0073] In the formula, This represents the minimum number of nodes required for a shard, which must be satisfied when using a PBFT-type consensus protocol. ,in, The number of fault-tolerant nodes is typically taken as... .

[0074] The spectral clustering algorithm using fusion correlation degree described in step 3.3 includes:

[0075] (1) Constructing the association matrix:

[0076]

[0077] In the formula, Indicates tissue-enhancing factors, Indicates the overall correlation between nodes;

[0078] (2) Calculate the normalized Laplace matrix:

[0079]

[0080] In the formula, Degree matrix ; : Identity matrix.

[0081] (3) Construction of spectral embedding representation: Solving The former The eigenvectors corresponding to the smallest eigenvalues Constructing a matrix , its first Rows represent nodes Spectral embedding vector;

[0082] (4) Constrained clustering: clustering of matrices The row vectors are subjected to constrained K-means clustering algorithm, and the constraints in step 3.2 must be satisfied in each iteration.

[0083] The greedy optimization based on modularity gain described in step 3.4 includes:

[0084] (1) Definition of modularity: For fragmentation Its modularity The calculation formula is:

[0085]

[0086] In the formula, Represents a node The sum of the comprehensive correlations, This represents the sum of the correlation degrees of all nodes in the graph; Represents a node The sum of the comprehensive correlation degree and the nodes The product of the sum of the comprehensive correlations.

[0087] (2) Boundary node identification: For each node Its boundary degree is defined as:

[0088]

[0089] In the formula, Represents a node Contribution to the modularity of the current shard. Indicates will Migration to Shards Potential contributions afterward Indicates the current shard where the node is located; Select The nodes constitute the boundary node set ;

[0090] (3) Greedy migration strategy: traversal Try to migrate it to an adjacent shard. Calculate the modularity gain:

[0091]

[0092] In the formula, Indicates target fragment At the admission node The subsequent new module degree; Indicates target fragment At the admission node The original module degree; Represents a node Current partition At the removed node The subsequent new module degree; Represents a node Current partition At the removed node The original module degree was previously selected; The largest and positive migration operation is selected, and the migration is verified to ensure that the constraints in step 3.2 are met. If they are met, the migration is executed.

[0093] The collaborative optimization framework described in step 4 further includes:

[0094] Step 4.1: System initialization and sharding deployment, specifically generating an initial sharding scheme based on step 3.3; within each shard, constructing a hierarchical consensus structure based on steps 2.1 and 2.2. If the shard size is less than a threshold... If so, then merge into the adjacent fragment;

[0095] Step 4.2: Standard Transaction Processing Flow: The client calculates the business semantic similarity between the account address or contract involved in the transaction and each shard, and sends the transaction to the most relevant shard. The master node of the target shard receives the transaction, initiates the intra-group local consensus process and inter-group global consensus process in Step 2.4, and generates a block within the shard. After the block within the shard is confirmed by consensus, it is submitted by the shard master node to the main committee. The main committee performs global hash verification, appends the block header to the global chain, and broadcasts it to the entire network.

[0096] Step 4.2.1 The client calculates the business semantic similarity between the account address or contract involved in the transaction and each shard, and sends the transaction to the most relevant shard. If there is no obvious correlation, the transaction is sent to the main committee.

[0097] Step 4.2.2: The master node of the target shard receives the transaction, initiates the intra-group local consensus process and inter-group global consensus process in Step 2.4, and generates blocks within the shard.

[0098] Step 4.2.3: After the blocks within a shard are confirmed by consensus, the shard master node submits them to the main committee. The main committee performs global hash verification, appends the block header to the global chain, and broadcasts it to the entire network.

[0099] Step 4.3: Cross-shard transaction processing flow: In the preparation phase, the master node of shard A sends a cross-shard request to the main committee. The committee notifies all target shards to lock relevant resources and collects weighted votes from each shard indicating "readiness." In the commit / abort phase, if the committee receives more than... If the weighted vote responds with "ready", a "global commit" command is broadcast, all relevant fragments will have their execution status updated and resources unlocked; otherwise, a "global abort" command is broadcast.

[0100] Step 4.4: Dynamic Adaptive Closed Loop: The system monitors throughput, consensus latency, cross-shard transaction ratio, and shard load standard deviation; when the indicators deteriorate beyond the preset threshold, it sequentially triggers local view switching, dynamic greedy adjustment in step 3.4, and full resharding in step 3.3; the reputation assessment model (step 1) is updated every 5 rounds of consensus to provide real-time data for the above adjustments.

[0101] The aforementioned collaborative optimization method based on reputation-driven hierarchical consensus and adaptive sharding further includes: Step 5: Designing evaluation metrics and experimental parameters;

[0102] Step 6: Design a comparative experiment to verify the benefits of the collaborative optimization method of reputation-driven hierarchical consensus and adaptive sharding.

[0103] The beneficial effects of this invention are as follows: This invention provides a collaborative optimization method based on reputation-driven hierarchical consensus and adaptive sharding. It considers the collaborative relationship between consensus and sharding mechanisms in consortium blockchain networks, integrating multi-dimensional node reputation assessment, hierarchical consensus, and dynamic adaptive sharding mechanisms. It employs an optimized two-phase commit protocol and a dynamic adaptive closed loop to achieve multi-task processing and collaborative optimization. Consortium blockchain performance optimization is a crucial foundation for overcoming the limitations of single-chain structures in terms of throughput and scalability, and for meeting the needs of high-reliability and low-latency services. Based on the collaborative optimization method of this invention, the comprehensive performance of nodes can be effectively evaluated and resources dynamically allocated, thereby constructing a large-scale consortium blockchain network foundation with high throughput, strong scalability, and high robustness.

[0104] This invention presents a multi-dimensional node reputation evaluation model based on response performance, transaction completion rate, and activity level, and constructs a framework to achieve deep integration of hierarchical consensus and adaptive sharding. This is of great significance for improving the performance of large-scale consortium blockchains. Compared with existing technologies, this invention has the following advantages: First, it fully considers node heterogeneity and dynamic performance, using a comprehensive reputation value for hierarchical division and weighted voting mechanism, effectively solving the technical difficulties of high communication complexity and security challenges in dynamic environments inherent in traditional consensus algorithms. Second, it considers the comprehensive correlation between network topology, business semantics, and organizational trust, minimizing cross-shard communication overhead through dynamic adaptive sharding, and combining it with a two-phase commit protocol coordinated by high-reputation shard master nodes, which helps solve the problems of uneven load distribution, high cross-shard communication overhead, and low inter-shard coordination efficiency in existing sharding technologies. Attached Figure Description

[0105] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate the invention and are used to explain it, but do not constitute an undue limitation of the invention.

[0106] Figure 1 This is a diagram of the overall architecture of the present invention;

[0107] Figure 2 This is a flowchart of the hierarchical consensus method of the present invention;

[0108] Figure 3 This is a flowchart of the dynamic adaptive fragmentation method of the present invention;

[0109] Figure 4 This is a flowchart illustrating the consensus and fragmentation collaborative optimization process of this invention. Detailed Implementation

[0110] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0111] See Figures 1 to 4As shown, the collaborative optimization method of reputation-driven hierarchical consensus and adaptive sharding of this invention first proposes a multi-dimensional node reputation evaluation model covering response performance, transaction completion rate, and activity, realizing dynamic hierarchicalization and reliability measurement of consortium blockchain nodes. Secondly, a consortium blockchain performance optimization framework that deeply coordinates hierarchical consensus and dynamic adaptive sharding is designed. This framework extracts network topology features, business semantic features, and organizational trust features between nodes in the consortium blockchain network through corresponding algorithms, and then effectively fuses the multi-dimensional association features of nodes to obtain a rich representation of the comprehensive association degree of nodes. Finally, a reputation-weighted hierarchical consensus mechanism and a modularity gain-based dynamic adaptive sharding mechanism are designed to achieve deep collaboration between consensus and sharding in a large-scale dynamic network environment and closed-loop optimization of the overall system performance. Specifically, it includes the following steps:

[0112] Step 1: Construct a multi-dimensional node reputation assessment model: The system conducts a comprehensive reputation assessment of each node in the entire network at fixed intervals. The assessment indicators include response performance, transaction completion rate, and activity level. The comprehensive reputation value of a node is defined as the weighted sum of each sub-indicator, followed by normalization and smoothing.

[0113] Step 1.1: Response Performance Metrics Calculation: Response performance reflects the real-time and stable processing of requests by a node. The calculation formula is as follows:

[0114]

[0115] in, This indicates the response time of a node in processing a single request, in milliseconds. This represents the average response time of the node within the statistics window. The standard deviation of node response time. This indicates the time interval since the last valid response. For smoothing factor and decay factor, It is a very small positive number, used to prevent division by zero errors.

[0116] Step 1.2: Transaction Completion Rate Indicator Calculation: The transaction completion rate reflects the success rate of a node in executing transactions and verification tasks, taking into account the sample size confidence level. The formula is as follows:

[0117]

[0118] in, This indicates the number of transactions successfully processed by the node. This represents the total number of transactions the node participated in. As a weight for the importance of transactions, This is the slope control parameter for the Sigmoid curve. This is the sample size threshold. This represents the maximum penalty coefficient.

[0119] Step 1.3: Activity Metrics Calculation: Activity level is characterized by two aspects: online rate and frequency of abnormal offline occurrences. The formula is as follows:

[0120]

[0121] in, This indicates the cumulative online time of a node within the statistical period. Indicates the total duration of the statistical period. This indicates the number of times a node went offline abnormally within the statistical period. This represents the penalty coefficient for a single offline occurrence.

[0122] Step 1.4: Calculation and normalization of the comprehensive credit score. The original comprehensive credit score is a weighted sum of three indicators:

[0123]

[0124] in, This represents the weighting coefficient of each indicator, satisfying... Typical .

[0125] Perform Min-Max normalization on all nodes in the entire network:

[0126]

[0127] in, This represents the minimum and maximum original reputation values ​​of all nodes. It is a very small positive number, used to prevent division by zero.

[0128] Step 1.5: Reputation Smoothing and Rating: The reputation value is updated using the Exponential Moving Average (EMA), and the formula is as follows:

[0129]

[0130] in, This represents the smoothed credit score from the previous period. As a smoothing factor, This represents the final reputation value for the current period.

[0131] Nodes are divided into four levels based on their final reputation score:

[0132] Step 2: Implement a hierarchical consensus mechanism based on reputation assessment (CBG-PBFT). Based on the reputation value obtained in Step 1, design a hierarchical consensus mechanism to reduce communication complexity and enhance security.

[0133] Step 2.1: Reputation Grouping Strategy: Let the total number of nodes in the network be n, and the desired number of groups be k. Sort the nodes in descending order of reputation value, and use a round-robin method to assign the nodes to k groups, ensuring that the proportion of high-reputation nodes in each group is similar. The size of each group is approximately... .

[0134] Step 2.2: Construction of the reputation-driven communication tree within the group:

[0135] (1) Node sorting and root node selection: Sort all nodes in the current group g according to their reputation value from high to low to obtain an ordered list Sorted(G). Select the node with the highest reputation value as the root node of the communication tree, which is responsible for receiving client requests and distributing proposals to child nodes.

[0136] (2) Tree structure construction rules: Use the index mapping method of a complete binary tree to avoid explicitly maintaining complex topology.

[0137] For the i-th node after sorting (i starts from 1): the index of its left child node is 2i, and the index of its right child node is 2i+1. If the child node index does not exceed the total number of nodes in the group, n... g Then a parent-child communication channel is established.

[0138] (3) Message propagation mechanism: The master node (root node) broadcasts the proposal downwards along the tree structure, and the message is forwarded layer by layer. After the child node completes the verification, it returns upwards along the original path to prepare or commit the vote. This structure reduces the communication complexity of intra-group broadcasting from O(n log n) to O(n log n). g 2 Reduced to O(n) g ⋅logn g This significantly reduces redundant messages.

[0139] (4) Dynamic update of the communication tree: When the reputation value of a node in the group changes significantly (such as when a node is downgraded or restored) or when a node joins or leaves, the above tree building process is re-executed. The update frequency is consistent with the reputation assessment cycle (such as every 5 rounds of consensus) to balance the overhead of structural adjustment and communication efficiency.

[0140] Step 2.3: Reputation-Weighted Voting Mechanism: In intra-group and inter-group consensus voting, node weights are introduced. These weights are proportional to the node's reputation value, and the formula is as follows:

[0141]

[0142] in, Represents a node Voting weight, Represents a node Current reputation value This represents the set of nodes that participated in the vote.

[0143] The weighted voting threshold required to reach a consensus is:

[0144]

[0145] in, This is the set of nodes that voted in favor.

[0146] Step 2.4: Consensus Process

[0147] (1) Reputation Assessment. Before each round of consensus begins, a multi-dimensional reputation calculation is performed on all nodes, taking into account indicators such as node response performance, transaction completion rate, and activity. A sliding time window mechanism is used to suppress short-term fluctuations and make the reputation assessment results more stable. High-reputation nodes will be given priority to be selected into the core layer of the consensus group, while low-reputation or malicious nodes will be isolated or downgraded to ensure consensus security.

[0148] (2) Reputation Grouping. After the reputation assessment is completed, nodes are divided into k groups based on their reputation values. High-reputation nodes are candidate master nodes and play a key consensus role; medium-reputation nodes constitute auxiliary nodes and mainly perform transaction verification and message forwarding; low-reputation nodes are limited to passively synchronizing the system state and do not participate in decision-making. Different groups assume different consensus responsibilities.

[0149] (3) Leader node selection. The leader node selection follows three principles: "reputation priority, dynamic rotation, and fault-tolerant replacement". That is, the node with the highest reputation value in the group is selected as the master node first to improve system stability and anti-attack capability; to prevent long-term control, the master node will be automatically rotated after multiple rounds of consensus; when the master node exhibits abnormal behavior, the system immediately triggers view switching, and the node with the second highest reputation value takes over.

[0150] (4) Request Distribution. Client requests are first received by the master node and broadcast preferentially within high-reputation groups to reduce communication complexity. After verifying the signature and calculating the hash digest of the request, the master node generates a transaction proposal and broadcasts it to all members of the group. Since CBG-PBFT adopts a reputation-driven communication tree topology, high-reputation nodes are located at the top of the tree and are responsible for forwarding messages downwards, while leaf nodes are responsible for performing verification and signature operations. This structure makes message passing hierarchical. At the same time, the master node registers the request digest in the group cache to support subsequent result verification and anti-counterfeiting and deduplication operations, thereby enhancing the security of transaction processing.

[0151] (5) Preparation Phase. This corresponds to the Pre-Prepare and Prepare processes in traditional PBFT. After the master node broadcasts the signed proposal, all slave nodes verify the proposal's legitimacy (including signature validity and hash consistency). If the verification passes, they broadcast a preparation confirmation message. When a node collects preparation messages from more than two-thirds of the weighted voting rights, it enters the commit preparation state.

[0152] (6) Submission Phase. After completing the preparation phase within each group, the master node submits the local consensus result to all consensus groups for global confirmation. Participating consensus members collect and cross-validate proposals, performing consistency checks on the hash values, timestamps, and signatures of each group's results. If more than two-thirds of the members vote in favor, the global consensus result is confirmed as valid. This phase transforms the originally centralized network-wide verification process into cross-group collaboration between high-reputation nodes, reducing communication complexity from O(n^2) to O(n^2). 2 ) decreases to O(k 2 It also uses a reputation constraint mechanism to prevent collusion and forgery by committee nodes.

[0153] (7) Result Confirmation. Once the global consensus result is determined, the committee will broadcast the result to all nodes in the group through a tree-like communication structure, and all nodes will update their local ledger status accordingly. Subsequently, the system triggers a reputation feedback mechanism to adjust the reputation values ​​of the nodes participating in this round of consensus: nodes with good performance will have their reputation values ​​appropriately increased, while nodes with delayed responses or malicious behavior will have their reputation values ​​penalized and reduced.

[0154] Step 2.4.1: Local consensus within the group: The master node (the node with the highest reputation in the group) receives the client request, forms a proposal, and broadcasts it along the communication tree; child nodes verify the proposal and return to prepare and submit votes along the tree; a weighted voting system is used to determine whether consensus has been reached. A weighted threshold is set; if this threshold is reached, consensus is achieved within the group.

[0155] Step 2.4.2: Global consensus among groups: The master nodes of each group form a committee (size) The committee runs CBG-PBFT to reach consensus on cross-group transactions or global state, with a communication complexity of O(n). .

[0156] Step 2.4.3: Result write-back and state update: The global consensus result is broadcast by the committee to all groups; each node updates its local ledger based on the consensus result.

[0157] Step 2.5: Dynamic Node Management:

[0158] (1) New node addition: initial reputation value These are marked as ordinary nodes and will not participate in consensus for the time being. They will be adjusted based on their performance after an observation period.

[0159] (2) Handling of faulty or malicious nodes: When a node is offline for more than a threshold, its reputation value drops rapidly; when it drops to a certain level... The following events will trigger the isolation and punishment mechanism (revocation of consensus permissions, blacklisting).

[0160] (3) Reputation Recovery: If a penalized node behaves normally during the cooling-off period, its reputation can be restored using a linear model, the formula of which is:

[0161]

[0162] in, This indicates that the initial reputation value has been restored. Indicates the recovery rate (typically taken as...) / wheel), Indicates the number of recovery steps (rounds).

[0163] Step 3: Implement Dynamic Adaptive Sharding Based on Reputation and Multidimensional Association (HADS): This involves integrating the node reputation data from Step 1... As a direct source of "organizational trust correlation", and by integrating network topology and business semantics, a comprehensive node correlation model is constructed for dynamic sharding.

[0164] Step 3.1: Node Relationship Model Definition: Let the consortium blockchain network be a graph. , A set of nodes. Nodes With Overall correlation between Defined as the weighted sum of the three components, its formula is:

[0165]

[0166] in, Represents the weighting coefficients, satisfying , Indicates the degree of structural correlation. Indicates the degree of semantic relevance in business context. This indicates the degree of trust and affinity within an organization.

[0167] Step 3.1.1: Structural Relevance Based on historical communication topology calculations, the formula is as follows:

[0168]

[0169] in, Represents a node The set of neighboring nodes, Indicates the number of common neighbors. Represents a node and The frequency of direct communication between them.

[0170] Step 3.1.2: Business Semantic Relevance The cosine similarity of transaction type vectors processed by nodes is calculated using the following formula:

[0171]

[0172] Among them, Represents a node The frequency vector of transaction types is processed over a period of time, where each dimension corresponds to a transaction type.

[0173] Step 3.1.3: Organizational Trust Relationship This reflects the trust relationship between the organizations to which the nodes belong, and the calculation formula is:

[0174]

[0175] in, Indicates the organization identifier to which the node belongs. For a predefined cooperation trust coefficient, As the attenuation factor, This represents a comprehensive score based on the node reputation value obtained in step 1, where and They are nodes and The final reputation value calculated in step 1 The minimum value strategy can effectively prevent low-reputation nodes from obtaining unreasonably high organizational trust ratings by establishing associations with high-reputation nodes, thereby improving the overall credibility of nodes within a shard.

[0176] Step 3.2: Formalizing the partitioning problem: Transform the node set... Divided into Each segment The goal is to optimize the sum of the comprehensive correlations within each partition while satisfying multiple constraints, as follows:

[0177] Step 3.2.1: The objective function formula is as follows:

[0178]

[0179] in, This represents a sharding scheme, that is, a set of nodes. A type of division, denoted as ,in Indicates the first Each segment. Indicates all possible sharding schemes In the process, we search for the solution that maximizes the objective function. For sharded indexes, from arrive This is used to iterate through each shard. This represents any two distinct nodes. Represents a node With nodes The overall correlation between them.

[0180] Step 3.2.2: Load Balancing Constraints: The size of each shard must be approximately the same to prevent skewed allocation of computing and storage resources and to avoid a single shard becoming a performance bottleneck. The calculation formula is as follows:

[0181]

[0182] in, Indicates the allowable load deviation rate (typically taken as...). ).

[0183] Step 3.2.3: Organizational Distribution Constraints: To prevent a single organization from dominating a shard and thus affecting the dispersion and fairness of consensus, it is necessary to restrict the organizational distribution of nodes within the same shard. The calculation formula is as follows:

[0184]

[0185] in, Indicates the maximum number of nodes in the organization; Refers to a specific organization.

[0186] Step 3.2.4: Minimum Shard Size Constraint: To ensure consensus security and system activity, each shard must meet a minimum number of nodes to resist Byzantine attacks. The calculation formula is as follows:

[0187]

[0188] in, This represents the minimum number of nodes required for a shard, which must be satisfied when using a PBFT-type consensus protocol. ,in Number of fault-tolerant nodes (typically taken as) ).

[0189] Step 3.3: Initial Segmentation – Spectral Clustering of Relationships:

[0190] (1) Construct the association matrix W: Calculate the comprehensive association degree of all node pairs. And it enhances the aggregation tendency of nodes within the same organization. The calculation formula is as follows:

[0191]

[0192] in, This indicates an enhancing factor within the organization.

[0193] (2) Calculate the normalized Laplace matrix:

[0194]

[0195] in, Degree matrix ; : Identity matrix.

[0196] (3) Feature mapping: Solving The former The eigenvectors corresponding to the smallest eigenvalues Constructing a matrix , its first Row corresponding node The spectral embedding representation.

[0197] (4) Constrained clustering: for The row vectors are run with a constrained K-means algorithm, which checks and satisfies the three constraints in step 3.2 in each iteration; if not, the cluster centers are backtracked and adjusted.

[0198] Step 3.4: Dynamic Adjustment – ​​Greedy Optimization Based on Modularity Gain: The system periodically adjusts (or when the cross-shard transaction ratio exceeds a threshold) When = 0.15), online adjustment is triggered.

[0199] Step 3.4.1: Modularity Definition: For fragmentation Its modularity The calculation formula is:

[0200]

[0201] In the formula, Represents a node The sum of the comprehensive correlations, This represents the sum of the correlation degrees of all nodes in the graph; Represents a node The sum of the comprehensive correlation degree and the nodes The product of the sum of the comprehensive correlations.

[0202] Step 3.4.2: Boundary node identification, calculating each node Boundary degree :

[0203]

[0204] in, Represents a node Contribution to the modularity of the current shard. Indicates will Migration to Shards Potential contributions afterward Indicates the current shard where the node is located; Select The nodes constitute the boundary node set .

[0205] Step 3.4.3: Greedy traversal: Traversal Try to migrate it to an adjacent shard. Calculate the modularity gain:

[0206]

[0207] in, Indicates target fragment At the admission node The subsequent new module degree; Indicates target fragment At the admission node The original module degree; Represents a node Current partition At the removed node The subsequent new module degree; Represents a node Current partition At the removed node The original module degree. Select to make The largest and positive migration operation is selected, and the migration is verified to ensure that the constraints in step 3.2 are met. If they are met, the migration is executed.

[0208] Step 3.4.4: Iterate and trigger re-sharding. Repeat the above steps until no positive gain can be obtained or the maximum number of iterations is reached. If any of the following conditions are met, re-execute the initial sharding in Step 3.3:

[0209] (1) The cross-segment transaction ratio is higher than the average for several consecutive periods. ;

[0210] (2) The set of nodes changes by more than 10%;

[0211] (3) The governance committee voted to approve the proposal to further divide the area.

[0212] Step 4: Construct a collaborative optimization framework and multi-task processing flow, deeply integrating the consensus mechanism of Step 2 with the sharding method of Step 3 to form a complete consortium blockchain performance optimization framework.

[0213] Step 4.1: System initialization and sharding deployment, specifically, generating the initial sharding scheme based on step 3.3;

[0214] Within each shard, a hierarchical consensus structure is constructed according to steps 2.1 and 2.2. If the shard size is less than a threshold... If so, it will be merged into the adjacent fragment.

[0215] Step 4.2: Standard Transaction Processing Flow: For transactions involving only a single account or contract within a shard, the system executes an efficient in-shard processing flow.

[0216] Step 4.2.1 Transaction Routing and Distribution: The client SDK or gateway node calculates the business semantic similarity between the transaction and each shard based on the account addresses or contract information involved in the transaction. Specifically, it extracts the transaction type feature vector and calculates the cosine similarity with the shard business semantic feature center defined in Step 3.1.2, then directs the transaction to the target shard with the highest similarity. If there is no obvious correlation, the transaction is sent to the main committee for forwarding.

[0217] Step 4.2.2: Local Consensus within a Shard: The master node of the target shard (i.e., the root node of the consensus group with the highest reputation value within that shard) receives the transaction. This master node, acting as the master node, initiates the local consensus process within the group in Step 2.4.1 and the global consensus process between groups in Step 2.4.2 to generate blocks within the shard.

[0218] Proposal Phase: The master node verifies the transaction, packages it into a proposal (Pre-Prepare), and broadcasts the proposal along the reputation-driven communication tree of its consensus group.

[0219] Preparation Phase: Upon receiving the proposal, the child node verifies it. If the verification is successful, it returns to the Prepare stage for voting along the communication tree. This process utilizes a reputation-weighted voting mechanism, where each node's voting weight is proportional to its reputation value.

[0220] Commit Phase: When the number of weighted votes collected by the master node exceeds... When the threshold is reached, consensus is achieved within the group, a commit message is broadcast, and blocks within the shard are generated.

[0221] Step 4.2.3: Global Confirmation and Ledger Update: After a block within a shard is confirmed through consensus, the master node of that shard submits the block hash and state root metadata to the main committee. The main committee performs global hash verification; if correct, it appends the block header to the global chain and broadcasts the confirmation information to all nodes in the network. Each node then updates its local ledger accordingly.

[0222] Step 4.3: For transactions involving multiple shards (cross-shard transaction processing flow):

[0223] Step 4.3.1: Prepare Phase: The master node that initiates shard A sends a cross-shard request to the main committee. The committee notifies all target shards (such as B and C) to lock the relevant resources and collects weighted votes from each shard to indicate that it is "ready".

[0224] (1) Initiating a request: After completing its intra-shard consensus, the master node of shard A sends a cross-shard transaction preparation request to the main committee. The request includes the transaction content, the list of target shards involved (such as shards B and C), and the necessary locked resource information.

[0225] (2) Resource Locking and Local Preparation: After verifying the legitimacy of the request, the main committee sends "preparation" instructions to the master nodes of all target shards (B, C) in parallel. Upon receiving the instructions, the master nodes of each target shard lock the local resources involved in the transaction and perform local pre-operations.

[0226] (3) Collecting Weighted Votes: After completing local preparation, each target shard collects weighted votes indicating "readiness" from the nodes within its shard. Only when the weighted votes within the shard exceed [a certain threshold] will the shard be considered ready. When the threshold is reached, the fragment is considered ready and a "ready" response is returned to the main committee.

[0227] Step 4.3.2: Commit / Abort Phase: If the committee receives more than [number missing] [units missing] If the weighted vote responds with "ready", a "global commit" command is broadcast; all relevant fragments are updated in their execution status and resources are unlocked; if any fragment fails to prepare, a "global abort" command is broadcast.

[0228] (1) Global decision: The main committee collects the "ready" responses from all relevant fragments (A, B, C). If all fragment responses are received within the timeout period and the committee verifies them by a simple majority, a "global commit" decision is made; otherwise, a "global abort" decision is made.

[0229] (2) Broadcast instructions: The main committee broadcasts the final “Global commit” or “Global abort” instruction to all relevant segments.

[0230] (3) Execution and unlocking: After receiving the "Global Commit" instruction, each shard master node executes the formal state update and unlocks the resources. If it receives the "Global Abort" instruction, it directly terminates the pre-operation and unlocks the resources.

[0231] Step 4.3.3: Atomicity Guarantee and Fault Tolerance: This invention guarantees the atomicity of cross-shard transactions through the following mechanism:

[0232] (1) Reputation-driven coordinator: The role of the main committee consists of the high-reputation shard master nodes selected in step 2.4.2. Their own high reputation reduces the probability of the coordinator acting maliciously.

[0233] (2) Reliability of weighted voting: The determination of "ready" within a shard depends on reputation-weighted voting, ensuring that only state changes recognized by the majority of high-reputation nodes can enter the commit phase.

[0234] (3) Retry and adjudication mechanism: If the main committee does not receive a response from a certain shard, it will designate the surviving node with the highest reputation as a temporary coordinator to retry or initiate a status query to avoid transaction blockage due to a single point of failure.

[0235] Step 4.4: Dynamic Adaptive Closed Loop

[0236] Step 4.4.1: Monitoring metrics: throughput, consensus latency, cross-shard transaction ratio, shard load standard deviation.

[0237] Step 4.4.2: Triggering Mechanism and Response Actions: When the indicators deteriorate beyond the preset threshold, the following actions are triggered in sequence: local view switching (master node replacement), dynamic greedy adjustment in step 3.4, full resharding in step 3.3, and the reputation assessment model (step 1) is updated every 5 rounds of consensus to provide real-time data for the above adjustments.

[0238] (1) Local view switching: If only the master node in a single consensus group responds to a timeout or its reputation declines, the view switching described in step 2.5 is triggered, and the second highest reputation node in the group takes over as the master node. This does not involve global adjustments.

[0239] (2) Dynamic Sharding Adjustment: If the cross-shard transaction ratio increases or the shard load is uneven, the greedy optimization based on modularity gain described in step 3.4 is triggered. This process only migrates boundary nodes, has low cost, and can be executed online.

[0240] (3) Full repartitioning: Full spectral clustering repartitioning in step 3.3 is triggered when any of the following severe conditions occur:

[0241] The cross-shard transaction ratio has been higher than a high threshold for several consecutive periods (e.g.) =0.3).

[0242] The network node set changed by more than 10% (e.g., a large number of nodes joined or left). The overall system performance continued to deteriorate, and local adjustments were ineffective. The governance committee passed a proposal to proactively initiate resharding.

[0243] (4) Continuous updating of the reputation model: Regardless of whether the above adjustments are triggered, the reputation assessment model described in step 1 will continue to run at a fixed period (e.g., every 5 rounds of consensus), updating the reputation values ​​of all nodes in the network in real time. These reputation values ​​provide the most basic and dynamic data support for the adjustment decisions of the above layers (e.g., master node election). Through this closed loop, the system can perceive environmental changes and adaptively optimize its own structure to achieve long-term performance stability.

[0244] Step 5: Design evaluation indicators and experimental parameters

[0245] Step 5.1: Definition of Core Evaluation Indicators

[0246] Step 5.1.1: Throughput ( (Transaction processing capability) is a core metric for measuring the transaction processing capacity of a blockchain system, defined as the number of transactions successfully confirmed by the system per unit of time. The calculation formula is:

[0247]

[0248] in, Indicates within the time window The total number of successfully confirmed transactions within the period, Indicates the length of the statistical time window (in seconds).

[0249] Step 5.1.2: Consensus latency is a key indicator for measuring system response speed, defined as the time interval from when a client initiates a transaction request to when the transaction is finally confirmed and written into a block, measured in milliseconds (ms). This indicator comprehensively reflects the communication overhead and computational efficiency of the consensus algorithm. This invention will measure the consensus latency of transactions within a single shard and the end-to-end latency involving cross-shard transactions, respectively.

[0250] Step 5.1.3: Cross-shard transaction ratio ( This sharding measure is used to evaluate the effectiveness of the sharding mechanism, reflecting the proportion of transactions that are split into different shards due to business relationships. A lower proportion indicates better shard cohesion and a more accurate node association model. The calculation formula is as follows:

[0251]

[0252] in, Cross-shard transaction count; Total number of transactions.

[0253] Step 5.1.4: Load Balancing This is used to measure the uniformity of node distribution across different shards, preventing some shards from becoming performance bottlenecks. This invention uses the standard deviation of the number of nodes in a shard as the metric, calculated using the following formula:

[0254]

[0255] in, Indicates the number of fragments. Indicates the first The number of nodes in each shard. This indicates the average fragment size.

[0256] Step 5.1.5: Robustness is used to evaluate the system's performance stability in the presence of faulty or malicious nodes. This invention tests the rate of decrease in system throughput relative to an ideal state by injecting different proportions of Byzantine nodes into the network. The lower the performance degradation rate, the stronger the system's robustness. This metric directly verifies the effectiveness of the reputation assessment model and weighted voting mechanism in resisting malicious behavior.

[0257] Step 5.2: Experimental Environment and Parameter Configuration: To ensure the repeatability and fairness of the experiment, this invention establishes a unified simulation testing platform. This platform simulates the node communication, consensus process, and sharding management logic of a consortium blockchain.

[0258] Step 5.2.1: Hardware and Software Environment: The experimental hardware environment is configured as follows: Intel(R) Core(TM) i7-14650HX, 16GB. The operating system is Windows 11. The simulation program is developed in Java and uses discrete event simulation libraries such as Simpy to simulate network communication latency and node behavior.

[0259] Step 5.2.2: Network and Node Configuration: The simulated network is configured by default with 100 consortium blockchain nodes. The network latency between nodes is set to a random value between 10ms and 50ms to simulate a real network environment. Nodes are divided into 4 organizations, each containing 25 nodes. The initial node reputation value is set to 0.3. The reputation evaluation cycle is set to once every 5 rounds of consensus.

[0260] Step 5.2.3: Consensus and Sharding Parameter Configuration

[0261] (1) Consensus protocol parameters: the number of Byzantine fault tolerance parameters for PBFT-type protocols satisfy The weighted voting threshold is set to The default false positive rate of dynamic Bloom filters. Set as .

[0262] (2) Segmentation-related parameters: load deviation rate Minimum fragment size Organizational distribution constraints Cross-shard transaction ratio trigger threshold .

[0263] Step 6: Design comparative experiments to verify the benefits of the method proposed in this invention.

[0264] Step 6.1: To systematically verify the effectiveness and superiority of the reputation-driven hierarchical consensus and adaptive sharding collaborative optimization method proposed in this invention, this embodiment designs a series of comparative experiments. The experiments compare the performance of the method of this invention with representative existing mainstream methods under the same environment in multiple dimensions. To reflect the comprehensiveness and fairness of the comparison, the following three representative consortium blockchain or blockchain performance optimization methods are selected as control groups:

[0265] (1) Classic PBFT method: This method uses the traditional Practical Byzantine Fault Tolerance (PBFT) consensus algorithm without using any grouping or sharding mechanism. All nodes participate in global consensus. This method serves as a performance baseline reference.

[0266] (2) Static Sharding + PBFT Method: The network is divided into a fixed number of shards, and the sharding scheme is not dynamically adjusted according to node status or business characteristics. Each shard runs the standard PBFT consensus, and cross-shard transactions are processed through a two-phase commit protocol. This method is used to verify the advantages of the dynamic adaptive sharding of the present invention.

[0267] (3) Reputation Group Consensus Method (No Sharding Collaboration): This method only adopts the reputation-driven hierarchical consensus (CBG-PBFT) from step 2 of this invention, but does not integrate the dynamic adaptive sharding mechanism from step 3. The entire network operates as a single shard / group. This method is used to verify the necessity of consensus and sharding collaborative optimization.

[0268] Step 6.2: Use the core evaluation indicators defined in Step 5.1, specifically including:

[0269] (1) Throughput (TPS): Calculated according to formula (23), it measures the number of transactions successfully confirmed by the system per unit time.

[0270] (2) Consensus latency: The time interval (milliseconds) from when the client initiates a transaction to when it receives the final confirmation. The latency of intra-shard transactions and cross-shard transactions are measured separately.

[0271] (3) Cross-segment transaction ratio Calculated according to formula (24), it reflects the cohesion of the segments. The lower the ratio, the better the segmentation scheme.

[0272] (4) Load balancing Calculated according to formula (25), the standard deviation of the number of shard nodes is used. The smaller the value, the more uniform the load distribution.

[0273] Step 6.3: Using the default experimental parameters described in Step 5.2 (100 nodes, 4 organizations, transaction sending rate of 1000 TPS, network latency of 10-50ms random value), a quantitative performance comparison is performed between the method of this invention and three comparative methods. The three comparative methods are: classic PBFT (no sharding, no grouping), static sharding + PBFT (fixed 4 shards, sharding scheme not adjusted), and reputation grouping consensus method (only using the layered consensus of Step 2, without sharding). Each experiment is run independently 10 times, and the average value is taken as the final result.

[0274] Step 6.4: Experimental Analysis

[0275] As shown in the table, the throughput of the method of this invention reaches 1150 TPS, which is 40.2% higher than static sharding + PBFT and 69.1% higher than simple reputation group consensus. The average consensus latency is 310ms, the lowest among the four. The cross-shard transaction ratio is only 8.7%, indicating that the comprehensive correlation model effectively gathers nodes with high-frequency interactions in the same shard. The load balancing degree (standard deviation of the number of nodes) is 1.5, which is significantly better than the 3.8 of the static sharding scheme, indicating that the dynamic adjustment mechanism makes the distribution of the number of nodes in each shard more uniform.

[0276] Example 1:

[0277] This embodiment uses a government consortium blockchain comprising 27 departments as an application scenario to elaborate on and verify the performance of the invention. This consortium blockchain aims to achieve secure sharing and business collaboration of enterprise, individual, and asset data among various ministries. The 27 national-level ministries / institutions are: a certain bank, a certain tax bureau, a certain market supervision bureau, a certain finance department, a certain customs department, a certain public security department, a certain development commission, a certain financial supervision bureau, a certain securities regulatory commission, a certain personnel management department, a certain health commission, a certain industry management department, a certain asset management commission, a certain commerce department, a certain transport department, a certain agriculture and rural affairs department, a certain natural resources department, a certain urban and rural construction department, a certain ecological environment department, a certain medical security bureau, a certain livelihood security department, a certain science and technology department, a certain education department, a certain grain bureau, a certain forestry bureau, a certain statistics bureau, and a certain sports bureau. These 27 departments serve as consensus nodes in the consortium blockchain and can communicate with each other.

[0278] This invention relates to a collaborative optimization method for reputation-driven hierarchical consensus and adaptive sharding, belonging to the blockchain field. First, a node reputation evaluation model based on multi-dimensional indicators such as response performance is constructed. Considering the heterogeneous and dynamically changing characteristics of consortium blockchain nodes, correlation features such as network topology, business semantics, and organizational trust are extracted. A spectral clustering and greedy optimization architecture are used to dynamically partition the blockchain, and reputation-driven hierarchical consensus is used as a collaborative aid to construct a consortium blockchain performance optimization framework that deeply integrates consensus and sharding. Through the fusion and adaptive adjustment of multi-dimensional node features, efficient consensus and load balancing are achieved for large-scale consortium blockchain networks. The collaborative optimization method proposed in this invention is of great significance for improving the throughput and scalability of consortium blockchains. Furthermore, the constructed framework achieves higher transaction throughput and lower cross-shard communication overhead than the baseline model in a dynamic network environment.

[0279] Step 1: Node Reputation Assessment. The system conducts a comprehensive reputation assessment of 27 nodes every 7 days. Reputation Value The values ​​∈ [0,1] directly reflect the service reliability and efficiency of each ministry node on the chain. Their reputation values ​​are shown in Table 1-1:

[0280] Table 1-1

[0281] 1. Reputation Value Explanation:

[0282] (1) High-reputation nodes (≥0.7): such as a tax bureau, a market supervision bureau, and a public security bureau. Reason: These departments are the core of high-frequency business (such as enterprise registration, tax declaration, and identity verification). Their systems have a high degree of informatization, fast response speed (average RT < 200ms), transaction completion rate close to 100%, and are online 24 / 7. Therefore, they receive high scores in the evaluation.

[0283] (2) Medium reputation nodes ([0.4, 0.7)): such as a forestry bureau or a grain bureau. Reason: The business is relatively infrequent, the system response speed is average (average RT 200-500ms), or there are short-term offline events caused by planned system maintenance, resulting in slightly lower activity.

[0284] (3) Low-reputation nodes ([0.1, 0.4)): such as a statistics bureau or a sports bureau. The reason is that the business of the sports bureau (such as monthly economic data reporting) has the characteristics of suddenness and large volume, which causes a huge impact on the system within a specific time window, resulting in a surge in response time. (low), or even transaction failure ( (Low). After this problem occurred for several consecutive quarters, the system determined that its behavior pattern was abnormal, and its reputation value was penalized and reduced. As a non-core business node, a certain sports bureau's reputation value naturally declined to a low level due to its long-term low activity and occasional failures in participating in consensus.

[0285] 2. Example of credit score calculation (using a certain bank as an example):

[0286] parameter: .

[0287] Node data: .

[0288] Formula (1):

[0289]

[0290] Formula (2):

[0291]

[0292] Formula (3):

[0293] Formula (4):

[0294]

[0295] Formula (5) (normalized) ):

[0296] Formula (6) (smooth, ):

[0297] Step 2: Calculation of the overall correlation between nodes. Based on the correlation model in Step 3.1, we calculated the overall correlation between the ministerial nodes. We selected some pairs of highly correlated and lowly correlated nodes for display, as shown in Table 1-2:

[0298] Table 1-2

[0299]

[0300] 1. Example of calculating the comprehensive correlation (taking a bank and a financial regulatory bureau as an example):

[0301] Known node reputation value: Take weight .

[0302] Formula 11:

[0303]

[0304] set up:

[0305]

[0306]

[0307]

[0308] because May exceed Normalization is required. Let the normalized result be:

[0309] Formula 12:

[0310]

[0311] set up: The calculation yields:

[0312] Formula 13: Since both nodes belong to the financial management system ( ):

[0313] Formula 10:

[0314]

[0315]

[0316]

[0317] Step 3: During system initialization (Step 3.3), spectral clustering is performed based on the aforementioned correlation matrix W. The goal is to divide the 27 nodes into 4 partitions (k=4), with each partition expected to have approximately 7 nodes. The clustering results and further reputation grouping within each partition are shown in Table 1-3.

[0318] Table 1-3

[0319]

[0320] Grouping Explanation: The core group consists of nodes with the highest reputation within each shard. They are responsible for leading the consensus process, including master node election, proposal generation, and broadcasting. Their weighted voting power is significant and plays a decisive role in reaching the 2 / 3 threshold. The validator group consists of nodes with medium reputation. They are responsible for verifying the legitimacy of proposals and participating in the preparation and submission for voting; they are the main execution force in the consensus process. The synchronization group consists of nodes with lower reputation. They do not participate in consensus voting but only synchronize the finally confirmed blocks and ledger state, ensuring data consistency without affecting consensus efficiency.

[0321] Explanation of the rationality of sharding: This sharding scheme gathers nodes with high relevance into the same shard. For example, Shard1 handles all financial transactions and Shard2 handles all business transactions, which greatly reduces the proportion of cross-shard transactions.

[0322] Step 4: Collaborative consensus process, taking a future company's development and application for listing as an example:

[0323] (1) Transaction Initiation: The company's sponsor submits the "Listing Guidance Acceptance Application" to the main node of Shard2 (Enterprise Business Shard).

[0324] (2) Local consensus within the shard:

[0325] Proposal: The master node generates a "receive and accept application" proposal, which is then broadcast along the reputation-driven binary tree it constructs (the root is a market supervision bureau, and the child nodes are a tax bureau, a customs department, etc.).

[0326] Preparation and Submission: Each verification node (such as a tax bureau verifying tax records for the past three years, or a customs department verifying import and export compliance) returns a weighted vote. Due to the high weight of the core group (a market supervision bureau and a tax bureau), more than 2 / 3 of the weighted votes are quickly collected, reaching consensus within the block and generating a "preliminary approval" block.

[0327] (3) Global consensus across Shards (across Shard1, Shard2, Shard4): Listing involves environmental protection, land, and financial compliance reviews.

[0328] Resource Locking: The Shard2 master node sends a cross-shard request to the main committee (composed of 4 shard master nodes). The committee notifies Shard4 to lock the "Environmental Impact Assessment and Land Use Compliance" status and notifies Shard1 to lock the "Shareholder Contribution and Fund Flow" status.

[0329] Weighted preparation: A Ministry of Natural Resources and a Ministry of Ecology and Environment in Shard4; a bank and a financial regulatory bureau in Shard1 collect weighted votes for "readiness" in their respective segments.

[0330] Global Commit: Once the committee receives "Ready" responses from all target shards (with all weighted votes exceeding 2 / 3), the main committee conducts rapid internal verification and broadcasts the "Global Commit" command. All relevant shards update their status and unlock resources.

[0331] Result write-back: The Shard2 master node packages the joint audit results of "listing application - financial compliance - environmental assessment compliance" into a final block and submits it to the main committee. The main committee appends the block header to the global chain and broadcasts it to all 27 nodes, completing state synchronization.

[0332] Example 2:

[0333] This embodiment comprehensively verifies the method of the present invention in a simulated large-scale consortium blockchain network environment, and compares it with three mainstream methods: classic PBFT, static sharding + PBFT, and reputation group consensus (no sharding), to quantitatively demonstrate the superiority of the present invention. The experimental environment configuration is as follows: Intel Core i7-14650HX, 16GB memory, Java + SimPy simulation. Each consortium blockchain node, network latency , Each organization The node's reputation assessment period is Consensus round, weighted voting threshold is Number of fragments The load deviation rate is The minimum fragment size is Relevance weight , , The transaction load is a hybrid model ( In-film transactions+ Cross-slice transactions), sending rate from Gradually increase to Each group of experiments was run independently. Take the average value each time.

[0334] (1) Comparison of throughput and consensus latency:

[0335] Table 2-1: Comparison of Performance Indicators of Various Methods

[0336] Classic PBFT 350 1250 Static partitioning + PBFT 820 480 Reputation-based group consensus (without sharding) 680 620 Method of the present invention 1150 310

[0337] Results Analysis: Classic PBFT, due to the participation of all nodes in consensus, has a communication complexity of O(n). ,exist A severe bottleneck occurred at the node, only Static partitioning is improved to [a higher level] through parallel processing. However, fixed sharding cannot adapt to business dependencies; while reputation-based group consensus reduces intra-group communication, its non-sharded parallel processing capability is weak. The method of this invention combines hierarchical grouping (intra-chip tree-like communication, with a complexity of O(n)). ) and dynamic fragmentation (inter-fragment committee only) (number of nodes), while grouping highly correlated nodes into the same shard, achieving a throughput of [number of nodes]. The delay is only Improved performance compared to static partitioning %, compared to reputation grouping %.

[0338] (2) Comparison of cross-shard transaction ratio and load balancing: Robustness test: Impact of Byzantine node ratio

[0339] Table 2-2: Cross-shard transaction ratio and load balancing

[0340] Static partitioning + PBFT 22.4 3.8 [8, 6, 9, 5] Method of the present invention 8.7 1.5 [7, 7, 6, 7]

[0341] Results Analysis: Static partitioning, due to random division, resulted in high-frequency interaction nodes being assigned to different partitions, with a cross-partition ratio as high as 22.4%. This invention uses spectral clustering for initial partitioning based on comprehensive correlation and dynamically adjusts the partitioning through greedy optimization of modularity, clustering highly correlated nodes into the same partition, reducing the cross-partition ratio to 8.7%. At the same time, load balancing constraints reduced the partition size standard deviation from 3.8 to 1.5, avoiding overload of a single partition.

[0342] (3) Robustness test: The influence of the proportion of Byzantine nodes

[0343] Table 2-3: Comparison of throughput reduction rate under different proportions of malicious nodes

[0344] 5% 18% 7% 10% 35% 15% 15% 52% 24%

[0345] Results Analysis: Classic PBFT uses equal-weighted voting, and the system fails when malicious nodes reach 1 / 3, and the rate of failure drops by 52% when malicious nodes reach 15%. This invention uses reputation-weighted voting, where low-reputation nodes have extremely low weights and cannot reach the 2 / 3 threshold, thus effectively suppressing malicious behavior: the rate of failure drops by only 24% when malicious nodes reach 15%, demonstrating excellent robustness.

[0346] In summary, the experimental data shows that this method can achieve good performance in large-scale dynamic consortium blockchain networks, breaking through the performance bottleneck of traditional consensus and sharding independent design.

[0347] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the invention by those skilled in the art. Any modifications, equivalent substitutions, or improvements made to the present invention should be included within the scope of protection of the present invention.

Claims

1. A collaborative optimization method based on reputation-driven hierarchical consensus and adaptive sharding, characterized in that: Includes the following steps: Step 1: Construct a multi-dimensional node reputation assessment model: The system conducts a comprehensive reputation assessment of each node in the entire network at a fixed period. The assessment indicators include response performance, transaction completion rate, and activity. The comprehensive reputation value of a node is defined as the weighted sum of each sub-indicator, which is then normalized and smoothed. Step 2: Implement a hierarchical consensus mechanism based on reputation assessment (CBG-PBFT). Based on the comprehensive reputation value of the nodes obtained in Step 1, a hierarchical consensus mechanism is designed to reduce communication complexity and enhance security. Step 3: Implement Dynamic Adaptive Sharding HADS Based on Reputation and Multidimensional Association: Use the comprehensive reputation value of the nodes in Step 1 as the core input of "organizational trust association degree", and integrate network topology and business semantics to construct a comprehensive node association degree model for dynamic sharding; Step 4: Construct a collaborative optimization framework and multi-task processing flow, deeply integrating the consensus mechanism of Step 2 with the sharding method of Step 3 to form a complete consortium blockchain performance optimization framework.

2. The collaborative optimization method for reputation-driven hierarchical consensus and adaptive sharding according to claim 1, characterized in that: The comprehensive credit assessment described in step 1 has the following response performance indicators. The calculation formula is: ； In the formula, This indicates the response time of a node in processing a single request, in milliseconds. This represents the average response time of the node within the statistics window. The standard deviation of node response time. This indicates the time interval since the last valid response. For smoothing factor and decay factor, It is a very small positive number; The transaction completion rate metric The calculation formula is: ； In the formula, This indicates the number of transactions successfully processed by the node. This represents the total number of transactions the node participated in; Assign weights based on the importance of the transaction; , is the slope control parameter of the Sigmoid curve; , is the sample size threshold; The maximum penalty coefficient; The activity index The calculation formula is: ； In the formula, This indicates the cumulative online time of a node within the statistical period. Indicates the total duration of the statistical period. This indicates the number of times a node went offline abnormally within the statistical period. This is the penalty coefficient for a single offline transaction. The overall credit score is the weighted sum of three indicators: ； In the formula, This represents the weighting coefficient of each indicator, satisfying... ; Perform Min-Max normalization on all nodes in the entire network: ； In the formula, This represents the minimum and maximum original reputation values ​​of all nodes. It is a very small positive number; Reputation score is updated using an exponential moving average: ； In the formula, This represents the smoothed credit score from the previous period. As a smoothing factor, This represents the final reputation value for the current period.

3. The collaborative optimization method for reputation-driven hierarchical consensus and adaptive sharding according to claim 1, characterized in that: The layered consensus mechanism described in step 2 further includes: Step 2.1: Reputation Grouping Strategy: The total number of nodes in the network is... The expected number of groups is Nodes are sorted in descending order of reputation value, and then distributed using a round-robin method. In the groups, each group has a size of ; Step 2.2: Intra-group reputation-driven communication tree construction: Within each group, sort nodes in descending order of reputation value, with the first node (the one with the highest reputation) as the root node; then, for the sorted nodes... 1 node Starting from 1, its left child node index is The index of the right child node is ; Step 2.3: Reputation-Weighted Voting Mechanism: In intra-group and inter-group consensus voting, node weights are introduced. These weights are proportional to the node's reputation value, and the formula is as follows: ； In the formula, Represents a node Voting weight, Represents a node Current reputation value Represents the set of nodes participating in the vote; Representing nodes Represents a node Current reputation value; The weighted voting threshold required to reach a consensus is: ； In the formula, The set of nodes that voted in favor; Step 2.4: Consensus process: including local consensus within a group, global consensus between groups, and result write-back and state update; Step 2.5: Dynamic Node Management: This includes mechanisms for adding new nodes, handling faulty or malicious nodes, and reputation restoration.

4. The collaborative optimization method for reputation-driven hierarchical consensus and adaptive sharding according to claim 3, characterized in that: The reputation restoration described in step 2.5 adopts a linear recovery model: ； In the formula, This indicates that the initial reputation value has been restored. Indicates the recovery rate. Indicates the number of recovery steps (rounds).

5. The collaborative optimization method for reputation-driven hierarchical consensus and adaptive sharding according to claim 1, characterized in that: The dynamic adaptive sharding described in step 3 further includes: Step 3.1: Node Relationship Model Definition: The consortium blockchain network is a graph. ,in A set of nodes; nodes and Overall correlation between Defined as a weighted sum of three components: ； In the formula, , For structural correlation, For business semantic relevance, To assess organizational trust and relevance; The structural correlation The calculation formula is: ； In the formula, Represents a node The set of neighboring nodes, Represents a node The set of neighboring nodes, Indicates the number of common neighbors. Represents a node and Frequency of direct communication between them; The business semantic relevance The calculation formula is: ； In the formula, Represents a node Process the frequency vector of transaction types over a period of time; Represents a node Process the frequency vector of transaction types over a period of time; The organizational trust correlation The calculation formula is: ； In the formula, Represents a node Organizational identifier Represents a node Organizational identifier For a predefined cooperation trust coefficient, As the attenuation factor, This represents a comprehensive score based on the node reputation value obtained in step 1, where and They are nodes and The final reputation value calculated in step 1 ; Step 3.2: Formalizing the partitioning problem: Transform the node set... Divided into Each segment The goal is to maximize the sum of the comprehensive correlation within each shard while satisfying load balancing constraints, organizational distribution constraints, and minimum shard size constraints. Step 3.3: Initial partitioning: Initial partitioning is generated using a spectral clustering algorithm that integrates correlations; Step 3.4: Dynamic adjustment: Online adjustment based on greedy optimization of modularity gain.

6. The collaborative optimization method for reputation-driven hierarchical consensus and adaptive sharding according to claim 1, characterized in that: The formal objective function for the piecewise partitioning problem described in step 3.2 is: ； In the formula, This represents a sharding scheme, that is, a set of nodes. A type of division, denoted as ,in Indicates the first Each shard represents all possible sharding schemes. In the process, find the solution that maximizes the objective function. For sharded indexes, from arrive This is used to iterate through each shard; This represents any two distinct nodes; Represents a node With nodes The overall correlation between them; The load balancing constraints are as follows: ； In the formula, This represents the allowable load deviation rate, taken as... ; The organizational distribution constraint is: ； In the formula, Indicates the maximum number of nodes in the organization; Refers to a certain organization; The minimum fragment size constraint is: ； In the formula, This represents the minimum number of nodes required for a shard, which must be satisfied when using a PBFT-type consensus protocol. ,in, The number of fault-tolerant nodes is typically taken as... .

7. The collaborative optimization method for reputation-driven hierarchical consensus and adaptive sharding according to claim 1, characterized in that: The spectral clustering algorithm using fusion correlation degree described in step 3.3 includes: (1) Constructing the association matrix: ； In the formula, Indicates tissue-enhancing factors, Indicates the overall correlation between nodes; (2) Calculate the normalized Laplace matrix: ； In the formula, Degree matrix ; : Identity matrix; (3) Construction of spectral embedding representation: Solving The former The eigenvectors corresponding to the smallest eigenvalues Constructing a matrix , its first Rows represent nodes Spectral embedding vector; (4) Constrained clustering: clustering of matrices The row vectors are subjected to constrained K-means clustering algorithm. In each iteration, the constraints in step 3.2 must be satisfied.

8. The collaborative optimization method for reputation-driven hierarchical consensus and adaptive sharding according to claim 5, characterized in that: The greedy optimization based on modularity gain described in step 3.4 includes: (1) Definition of modularity: For fragmentation Its modularity The calculation formula is: ； In the formula, Represents a node The sum of the comprehensive correlations, This represents the sum of the correlation degrees of all nodes in the graph; Represents a node The sum of the comprehensive correlation degree and the nodes The product of the sum of the comprehensive correlation degrees; (2) Boundary node identification: For each node Its boundary degree is defined as: ； In the formula, Represents a node Contribution to the modularity of the current shard. Indicates will Migration to Shards Potential contributions afterward Indicates the current shard where the node is located; Select The nodes constitute the boundary node set ; (3) Greedy migration strategy: traversal Try to migrate it to an adjacent shard. Calculate the modularity gain: ； In the formula, Indicates target fragment At the admission node The subsequent new module degree; Indicates target fragment At the admission node The original module degree; Represents a node Current partition At the removed node The subsequent new module degree; Represents a node Current partition At the removed node The original module degree was previously selected; The largest and positive migration operation is selected, and the migration is verified to ensure that the constraints in step 3.2 are met. If they are met, the migration is executed.

9. The collaborative optimization method for reputation-driven hierarchical consensus and adaptive sharding according to claim 1, characterized in that: The collaborative optimization framework described in step 4 further includes: Step 4.1: System initialization and sharding deployment, specifically generating an initial sharding scheme based on step 3.3; within each shard, constructing a hierarchical consensus structure based on steps 2.1 and 2.

2. If the shard size is less than a threshold... If so, then merge into the adjacent fragment; Step 4.2: Standard Transaction Processing Flow: The client calculates the business semantic similarity between the account address or contract involved in the transaction and each shard, and sends the transaction to the most relevant shard. The master node of the target shard receives the transaction, initiates the intra-group local consensus process and inter-group global consensus process in Step 2.4, and generates a block within the shard. After the block within the shard is confirmed by consensus, it is submitted by the shard master node to the main committee. The main committee performs global hash verification, appends the block header to the global chain, and broadcasts it to the entire network. Step 4.3: Cross-shard transaction processing flow: In the preparation phase, the master node of shard A sends a cross-shard request to the main committee. The committee notifies all target shards to lock relevant resources and collects weighted votes from each shard indicating "readiness." In the commit / abort phase, if the committee receives more than... If the weighted vote responds with "ready", a "global commit" command is broadcast, all relevant fragments will have their execution status updated and resources unlocked; otherwise, a "global abort" command is broadcast. Step 4.4: Dynamic Adaptive Closed Loop: The system monitors throughput, consensus latency, cross-shard transaction ratio, and shard load standard deviation; when the indicators deteriorate beyond the preset threshold, it sequentially triggers local view switching, dynamic greedy adjustment in step 3.4, and full resharding in step 3.3; the reputation assessment model is updated every 5 rounds of consensus to provide real-time data for the above adjustments.

10. The collaborative optimization method for reputation-driven hierarchical consensus and adaptive sharding according to claim 1, characterized in that: Also includes: Step 5: Design evaluation indicators and experimental parameters; Step 6: Design a comparative experiment to verify the benefits of the collaborative optimization method of reputation-driven hierarchical consensus and adaptive sharding.

Images