Fragmentation alliance chain redistribution method based on reputation mechanism and node network conditions

Abstract

The invention provides a fragment alliance chain redistribution method based on a reputation mechanism and node network conditions. According to the method, the operation process of the block chain system is divided according to time periods epoch, and each epoch comprises two stages: a consensus block-out stage and a redistribution stage; the node reputation score is calculated in the consensus block-out stage; in the redistribution stage, the nodes exchange reputation scores, and node redistribution is carried out according to the reputation scores; during redistribution, division is performed according to node reputation scores, and the node reputation scores are divided into high reputation scores, medium reputation scores and low reputation scores; removing low-reputation partial nodes; clustering the high-reputation sub-nodes according to network conditions to obtain a preliminary node redistribution scheme; and randomly distributing the reputation sub-nodes to the initial node redistribution scheme to obtain a final node redistribution scheme. By using the method, the nodes can be redistributed according to the node network condition while the security is ensured, the on-chip transaction delay of the fragment alliance chain is finally reduced, and the throughput is improved.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a sharded alliance chain redistribution method based on a reputation mechanism and node network conditions. Background Art

[0002] A consortium blockchain is a permissioned blockchain, somewhere between public and private blockchains. Unlike public chains, which are open to all members and allow nodes to join and leave freely, private chains are limited to individuals or organizations, have fewer nodes, and are subject to strict permission controls. Consortium chains allow permissioned nodes to join and are often deployed across multiple organizations. Consortium chains are also less expensive than public chains, and their consensus efficiency is far higher. Therefore, while public chains are often used for virtual currencies, and private chains are often subject to censorship, consortium chains are widely used in banking, insurance, and corporate collaboration.

[0003] As network scale and transaction volume increase, traditional single chains encounter performance bottlenecks. Sharding technology has been proposed as a solution. State sharding has been widely adopted due to its high performance and scalability. Sharding divides the system into multiple small sub-divisions, or shards. Each shard contains only a portion of the state data and a subset of nodes. Each shard can independently process a portion of transactions, known as intra-shard transactions. Transactions that cannot be processed independently are handled collaboratively by multiple shards, known as cross-shard transactions. Because each shard can process intra-shard transactions in parallel, sharding significantly improves throughput and offers excellent scalability.

[0004] However, during system operation, transaction hotspots may shift, leading to an increase in the proportion of cross-shard transactions requiring collaboration across multiple shards. This can gradually become a scalability bottleneck for blockchain systems and compromise system throughput. A common state redistribution approach currently used is to record and model the correlation between data during transaction execution. Using a variety of redistribution algorithms, closely related data is redistributed to the same shard, increasing the proportion of intra-shard transactions, reducing the proportion of cross-shard transactions, and improving system throughput. For example, in a transfer transaction, the number of transfers between accounts is recorded. Accounts are treated as nodes, transfers as edges, and the number of transfers as edge weights. This is modeled as an undirected graph. Using a graph partitioning algorithm, the data is partitioned and redistributed in a way that maximizes edge weights within a subgraph, minimizes edge weights between subgraphs, and maintains as equal edge weights within a subgraph.

[0005] However, current redistribution methods fail to account for the varying network conditions of nodes, treating them as peers and assigning them randomly. In reality, however, some nodes often have excellent network conditions, while others have poorer conditions. For example, nodes A and B have high bandwidth and low latency, while nodes A and C have low bandwidth and high latency. Randomly assigning nodes results in nodes with poor network conditions being assigned to the same shard, increasing transaction latency within the shard and even compromising system throughput. Reassigning nodes based on network conditions, assigning nodes with good network conditions to the same shard, can reduce transaction latency within the shard and improve system throughput. However, sharded systems require regular random node assignment to ensure system security. Directly assigning nodes based on network conditions results in a loss of randomness, compromising system security. Therefore, ensuring security while performing node redistribution based on network conditions is a pressing issue. Summary of the Invention

[0006] In view of this, the present invention provides a sharded consortium chain reallocation method based on a reputation mechanism and node network conditions. While ensuring security, nodes are reallocated according to the node network conditions, ultimately reducing the intra-chip transaction delay of the sharded consortium chain and improving throughput.

[0007] In order to achieve the above purpose, the technical solution of the present invention is:

[0008] A sharded consortium chain redistribution method based on a reputation mechanism and node network conditions. This method divides the operation process of the blockchain system into epochs. Each epoch consists of two phases: the consensus block generation phase and the redistribution phase.

[0009] Phase 1: The consensus block generation phase calculates the node reputation score. Nodes that contribute positively to the consensus will have their reputation score increased, while nodes that contribute negatively to the consensus will have their reputation score reduced.

[0010] Phase 2: Redistribution phase, nodes exchange reputation scores and are redistributed based on their reputation scores. During redistribution, nodes are divided into high reputation, medium reputation, and low reputation scores according to their reputation scores. Nodes with low reputation scores are eliminated. Nodes with high reputation scores are clustered according to network conditions to obtain a preliminary node redistribution plan. Nodes with different reputation scores are randomly assigned to the preliminary node redistribution plan to obtain the final node redistribution plan.

[0011] Preferably, the reputation score is calculated based on additional reputation information; the additional reputation information is the contribution of the current shard node to the previous consensus and any evidence of possible malicious behavior in the previous consensus.

[0012] Preferably, the node reputation score calculation in the first stage is calculated independently by each node. Each node only calculates the reputation score of the consensus-participating nodes in its own shard, and the calculation is performed once for each consensus. The first stage includes the following steps:

[0013] Step 1.1: When a node packages a block, it attaches additional reputation information; the additional reputation information includes the contribution of the node in the previous consensus and any evidence of malicious behavior.

[0014] Step 1.2: When a node receives a block for verification, it performs an additional verification step: verifying the additional credibility information in the block, that is, whether the contribution of the shard node to the previous consensus meets the set requirements and whether the evidence of malicious behavior is true; if not, the block is rejected from passing the consensus;

[0015] Step 1.3: Determine whether the block has passed consensus; if the block has passed consensus, jump to step 1.4; otherwise jump to step 1.5;

[0016] Step 1.4: After the block passes consensus, the nodes calculate the reputation score of each node based on the additional reputation information in the block;

[0017] Step 1.5: If the block fails to pass consensus, the node will record the evidence of malicious behavior in this consensus in the next consensus block.

[0018] Preferably, in step 1.2, the verification step is: determining whether the deviation between the additional credibility information in the block and the additional credibility information of the previous consensus received by the node is within an error range; if the deviation exceeds the error, the block is rejected from passing the consensus.

[0019] Preferably, the step of determining whether the deviation between the additional credibility information in the block and the additional credibility information of the previous consensus received by the node is within an error range comprises: comparing the voting information of the shard node in the prepare and commit stages received by the node in the previous consensus with the voting information of the additional credibility information in the block, and determining whether the number of different votes is within an error range; if the number exceeds the error, the block is rejected from passing the consensus.

[0020] Preferably, in step 1.4, the credit score is calculated as follows:

[0021] score=baseScore*(baseTxScore+log2(txLen))*leaderScore

[0022] Among them, score is the reputation score; baseScore is the basic score used to control the growth rate of the reputation score; baseTxScore+log2(txLen) is the reward score coefficient for the number of block transactions; baseTxScore is the basic reward score for completing consensus; txLen is the number of transactions in a block; the log function provides reputation rewards to nodes that continuously contribute to consensus in the transaction reward part; leaderScore is the restriction coefficient that limits the leader node from obtaining too high a reputation score; when the node is an ordinary node, leaderScore is 1; when the node is a leader node, leaderScore is a value less than 1;

[0023] For malicious behavior, determine the base penalty coefficient base and punish the reputation score:

[0024]

[0025] r new =2 t

[0026] Among them, r new is the node reputation score after punishment, and t is the intermediate value.

[0027] Preferably, the basic penalty coefficient base automatically increases with the number of times the node commits malicious acts:

[0028] base=cnt+initBase

[0029] Where cnt is the number of times the node has committed evil, and initBase is the initial minimum penalty coefficient.

[0030] Preferably, in the second stage, the nodes exchange reputation points by establishing a reputation blockchain in which all nodes participate, and the process is as follows:

[0031] Step 2.1: All nodes broadcast their local node reputation scores;

[0032] Step 2.2: The node receives the same reputation score from a set number of different nodes in the same shard and considers the same reputation score as a provisional result;

[0033] Step 2.3: The packaging node packages the tentative result into a reputation block and adds it to the reputation blockchain for consensus;

[0034] Step 2.4: The node verifies based on the reputation block and local tentative results;

[0035] Step 2.5: If the reputation block passes consensus, jump to step 2.7, otherwise jump to step 2.6;

[0036] Step 2.6: Change the packaging node and return to step 2.3;

[0037] Step 2.7: The node uses the reputation block content as the reputation score of all nodes in this epoch.

[0038] Preferably, in the step of redistributing nodes based on the reputation score, when processing nodes with medium reputation scores, different nodes use the same random algorithm to determine the allocation scheme for nodes with medium reputation scores.

[0039] Preferably, in the step of redistributing nodes based on reputation score, the high reputation score nodes are clustered according to network conditions into:

[0040] Step a1: Randomly select k*m nodes to establish initial clusters, with one node in each cluster; k is a pre-determined multiple, and m is the number of shards; all initial clusters are the first candidate clusters in step a2;

[0041] Step a2: Node merging: add the remaining nodes to the first candidate cluster in sequence;

[0042] In this step, for a node to be processed, the cost of joining each first candidate cluster is calculated; the cost is defined as a function of network bandwidth and network delay; the greater the network bandwidth and the lower the network delay, the lower the cost; the smaller the network bandwidth and the higher the network delay, the higher the cost; the node is added to the first candidate cluster with the lowest cost; if there are multiple first candidate clusters with the lowest cost, one of the first candidate clusters with the lowest cost is randomly selected to join; if the number of nodes in the first candidate cluster has reached the set upper limit, it is no longer included in the first candidate cluster of step a2; this step a2 is repeated until all remaining nodes have been processed;

[0043] Step a3: Cluster merging: Randomly select m clusters from all the clusters obtained in step a2 as the second candidate clusters, and process the other clusters in turn and merge them into the second candidate clusters;

[0044] In this step, for a cluster to be merged, the first cost of all nodes in the cluster to be merged to join a candidate cluster C is calculated in turn, and the sum is used to obtain the second cost of merging the cluster to be merged into the candidate cluster C; the second cost of merging the cluster to be merged into each candidate cluster is calculated in turn; finally, the cluster to be merged is merged into the candidate cluster with the lowest second cost. If there are multiple options with the lowest cost, one of them is randomly selected; if the number of nodes in the candidate cluster has reached the upper limit, or exceeds the upper limit after merging, it will not be used as a candidate cluster for this time; if there is no best candidate cluster for merging, the current cluster to be merged is split, and the nodes are merged according to step a2; and step a3 is repeated until all clusters are processed.

[0045] Beneficial effects:

[0046] (1) To avoid the drawbacks of existing technologies that use random redistribution schemes or redistribution schemes based entirely on network conditions, the present invention classifies nodes according to their reputation scores. Nodes with higher reputations are considered to have relatively high credibility and are redistributed based on clustering according to network conditions. Nodes with medium reputations are considered to have average credibility and are randomly allocated to avoid malicious nodes being assigned to the same shard, thereby ensuring system security. Nodes with low reputation scores, i.e., malicious nodes, are formally removed from the system, further ensuring system security.

[0047] (2) The present invention provides a reputation score calculation method that not only ensures that all nodes that contribute positively to the consensus receive reputation scores, but also reduces the reputation scores of nodes that contribute negatively to the consensus. It also ensures that the reputation scores obtained by nodes that propose blocks are slightly lower than those of nodes that contribute positively to the consensus.

[0048] (3) The present invention also provides a penalty method when calculating the reputation score, which can significantly reduce the node's reputation score, while satisfying the following: the higher the node's reputation score, the greater the penalty, and the more times the node commits malicious acts, the greater the penalty. Therefore, the following are achieved: 1. Malicious nodes are punished. 2. When a malicious node disguises itself as an honest node to obtain a high reputation score and then commits malicious acts, its reputation score can be quickly reduced and it can be quickly identified. 3. When a malicious node repeatedly commits malicious acts at intervals, the intervals will be rapidly extended due to the gradual increase in the penalty intensity, so that the interval is too long to commit malicious acts or be identified. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] Figure 1 This is the epoch flow chart of this system;

[0050] Figure 2 This is the flow chart of the reputation part of the on-chip consensus of this system;

[0051] Figure 3 This is a block diagram of the system;

[0052] Figure 4 This is a flowchart of node redistribution according to network conditions for this system;

[0053] Figure 5 Clustering flow chart. DETAILED DESCRIPTION

[0054] The present invention is described in detail below with reference to the accompanying drawings and embodiments.

[0055] First, let’s introduce the system model of the sharded consortium chain:

[0056] The system uses state sharding, with m shards and n nodes per shard. PBFT and its variants are used within each shard. For ease of presentation, PBFT consensus is used below. There are no specific requirements for cross-shard consensus; consensus algorithms such as Pyramid, BrokerChain, and Sharper can be used.

[0057] The system consists of two blockchains: one for storing data required by sharding, and the other for a reputation chain. The reputation chain is participated in by all nodes and is used to store reputation information, node redistribution plans, node public key correspondence information, etc., using Sharper cross-shard consensus.

[0058] Nodes use peer-to-peer connections, resulting in varying network conditions such as bandwidth and latency. This can manifest as multiple clusters. Nodes within a cluster have high bandwidth, low latency, and good network conditions. Nodes between clusters have low bandwidth, high latency, and poor network conditions. For example, nodes A and B have high bandwidth and low latency, while nodes A and C have low bandwidth and high latency.

[0059] The system security model is as follows:

[0060] Nodes joining the system require permission from an authorized authority, such as a CA. Nodes have unique public and private keys that identify them, and signatures cannot be forged. The system assumes that the adversary is slowly corrupting the system, and that all nodes are initially honest.

[0061] The system divides the execution process into epochs, and each epoch process is as follows Figure 1 As shown in the epoch flow chart. Each epoch is divided into two phases: consensus block generation phase and redistribution phase. Specifically:

[0062] Phase 1: Calculate node reputation scores during the consensus block generation phase.

[0063] Here, the consensus block generation phase refers to the phase of system packaging, consensus, blockchain upload, and execution. In this phase, nodes normally receive transactions, package blocks for blockchain upload through consensus, verify and execute transactions, and calculate reputation scores. This phase is repeated multiple times until the time limit for this phase is reached.

[0064] Phase 2: Redistribution phase: Nodes exchange reputation points and are redistributed based on their reputation points. Nodes that contribute positively to consensus have their reputation points increased, while nodes that contribute negatively to consensus have their reputation points decreased.

[0065] The redistribution phase is divided into two stages: exchanging reputation scores and redistributing nodes based on network conditions. The reputation exchange phase packages the reputation scores for the epoch and stores them in the reputation chain through consensus. When redistributing nodes based on reputation scores, nodes are divided into high, medium, and low reputation scores. Low-reputation nodes are removed. High-reputation nodes are clustered based on network conditions to generate a preliminary node redistribution plan. Nodes with different reputation scores are randomly assigned to the preliminary node redistribution plan to obtain the final node redistribution plan.

[0066] After the redistribution phase, nodes exchange state data and other information based on the redistribution results, reorganizing shards and preparing for the next epoch. Once preparation is complete, the system enters the next epoch and repeats the process.

[0067] This paper avoids the drawbacks of existing technologies that employ random redistribution schemes or redistribution schemes based solely on network conditions. By categorizing nodes based on their reputation scores, the present invention prioritizes nodes with high reputations, assuming they are relatively trustworthy, and performs cluster-based redistribution based on network conditions. Nodes with medium reputations, however, are considered trustworthy and are randomly assigned to prevent malicious nodes from being assigned to the same shard, thereby ensuring system security. Nodes with low reputation scores, i.e., malicious nodes, are formally removed from the system, further ensuring system security.

[0068] In addition, nodes use a unique public key to participate in the reputation chain consensus. However, if the intra-shard consensus uses methods such as aggregate signatures, another set of public and private keys is required. Nodes need to apply to an authorized institution such as a CA to obtain the corresponding public and private keys. The correspondence between the unique public key and the intra-shard consensus public key is packaged after the node redistribution phase and saved to the reputation chain through consensus to ensure that all nodes can obtain this information.

[0069] The specific implementation process of the present invention, as well as key links such as the reputation mechanism and the node reallocation mechanism according to network conditions are introduced in detail below.

[0070] The reputation mechanism needs to introduce additional steps to the original consensus mechanism, mainly in the three parts of block packaging, consensus voting and execution, such as Figure 2 As shown in the figure, additional reputation information is required when packaging a block. During the consensus voting phase, nodes need to check whether the reputation information deviates from the local result. If the discrepancy is too large, the block will be rejected from consensus. During the execution phase, nodes calculate the reputation score of each node based on the block's reputation information and update the local result.

[0071] In Phase 1, node reputation scores are calculated independently. Each node only calculates the reputation scores of the consensus nodes in its own shard, and the calculation is performed once for each consensus. Phase 1 includes the following steps:

[0072] Step 1.1: When a node packages a block, it attaches additional reputation information. This additional reputation information includes the contribution of the node in this shard to the previous consensus and any evidence of possible malicious behavior. For example, in consensuses such as PBFT, the attached information includes the voting information of the node in this shard during the perpare and commit phases of the previous consensus.

[0073] Step 1.2: When a node receives a block for verification, it performs an additional verification step: verifying whether the additional credibility information in the block, i.e., the contribution of the node to the previous consensus, meets the set requirements and whether the evidence of malicious behavior is genuine; if not, the block is rejected from consensus. In this embodiment, the deviation between the additional credibility information in the block and the additional credibility information received by the node from the previous consensus is checked to ensure that it is within the error range. For example, in a consensus similar to PBFT, the node compares the voting information of the node in the prepare and commit phases of the previous consensus to ensure that the number of differences between the votes in the additional credibility information in the block is within the error range. Malicious behavior verification includes but is not limited to node forgery of messages and node packaging of multiple different blocks in the same consensus.

[0074] Step 1.3: Determine whether the block has passed consensus; if the block has passed consensus, jump to step 1.4; otherwise jump to step 1.5;

[0075] Step 1.4: After the block passes consensus, the nodes calculate the reputation score of each node based on the additional reputation information in the block;

[0076] Step 1.5: If the block fails to pass consensus, the node will record the evidence of malicious behavior in this consensus in the next consensus block.

[0077] In the above process, step 1.1 is the block packaging step. Compared with the existing technology, the modifications to the block packaging are as follows:

[0078] The reputation mechanism modifies the block and adds additional information, such as Figure 3 Compared to ordinary blocks without a reputation mechanism, this block has a reputation section in its header. This section records locally retained voting information for nodes that have not yet reached consensus on the blockchain, as well as penalty information such as evidence of malicious behavior. Furthermore, when nodes sign the block header, they must also factor this reputation information into the signature.

[0079] To reduce the size of the extra information, voting messages in the prepare and commit phases are represented using bitmaps. Assuming there are n nodes in this shard, a voting message for each phase requires only n bits, and a consensus voting message requires a total of 2n bits, or n / 4 bytes. When the system is operating normally, a block typically only requires a single consensus voting message, which can be ignored. Due to the admission and reputation penalties, it can be assumed that the number of times a node misbehaves is relatively small. Therefore, most of the time, the penalty information is empty. In summary, reputation information has a minimal impact on block size, adding only approximately n / 4 bytes when no nodes are misbehaving. The additional overhead of signatures and consensus is negligible.

[0080] In the above process, steps 1.2 to 1.3 are the consensus phase, where nodes need to verify whether the reputation information in the block and the local voting information are within the error range. Assuming that the error range of the vote for a consensus is x bits, the calculation method is as follows:

[0081] Step 1: Perform a bitwise AND operation on the prepare and commit phase votes of the reputation information in the block to obtain the result b1.

[0082] Step 2: Perform a bitwise AND operation on the local prepare and commit votes at the corresponding height to obtain the result b2.

[0083] Step 3: Perform a bitwise XOR operation on b1 and b2 to obtain b3. If the number of 1s in b3 is less than x, then a "yes" is returned. Otherwise, a "no" is returned.

[0084] For evidence of node maliciousness, we verify whether it is issued by the corresponding malicious node and whether it is indeed a malicious behavior. For example, the leader proposes multiple different blocks of the same height, which is a malicious behavior.

[0085] In the above process, steps 1.4 to 1.5 are modified as follows for the execution phase:

[0086] Nodes update the reputation scores of nodes in their shards in turn based on the block reputation information. For nodes that voted in favor during both the prepare and commit phases, when the block is not empty, the reputation score is calculated using the following reward function:

[0087] score=baseScore*(baseTxScore+log2(txLen))*leaderScore

[0088] The baseScore is the base score used to control the rate of reputation score growth. It can typically be set to 1. baseTxScore + log2(txLen) is the reward score coefficient for the number of transactions in a block. The baseTxScore is the base score, serving as the baseline reward for achieving consensus, to prevent reputation rewards from being too low when there are fewer transactions. txLen is the number of transactions in a block. This ensures that the more transactions a node has, the greater its contribution, resulting in higher reputation rewards. Furthermore, to prevent nodes from only voting in a few blocks with a high number of transactions, while refraining from voting in most blocks with fewer transactions and still achieving high reputation scores, a logarithmic reward function is used as the reward function for the number of transactions. The logarithmic reward function exhibits near-linear growth when the number of transactions is low, but slows down when the number of transactions is high. This allows the transaction reward to provide reputation rewards for nodes that consistently contribute to consensus. The leaderScore is the leader coefficient. For an ordinary node, this value can be 1. When a node is a leader, this value should be less than 1, such as 0.9. Since the leader always participates in consensus during normal consensus, it is more likely to gain reputation points than other nodes. If this is not restricted, the leader's reputation score may be much higher than that of other nodes. Therefore, the leader value in the leader coefficient should be slightly lower than that of ordinary nodes to avoid this phenomenon. The method of determining reputation points in this embodiment ensures that all nodes that contribute positively to consensus receive reputation points, while reducing the reputation points of nodes that contribute negatively to consensus. It also ensures that the reputation points obtained by nodes proposing blocks are slightly lower than those of nodes that contribute positively to consensus.

[0089] When the block is empty, the credit reward is 0.

[0090] At the same time, to prevent the leader from launching censorship attacks during the block process and refusing to include certain nodes’ votes in the block’s reputation information, thus preventing some nodes from receiving reputation rewards, the consensus leader should be rotated.

[0091] For malicious behavior, the following algorithm is used to punish:

[0092] Assume that the reputation of the node to be punished is r and the basic penalty coefficient is base, then

[0093]

[0094] r new =2 t

[0095] Among them, r new is the node reputation score after punishment.

[0096] The penalty mechanism will greatly reduce the node's reputation score. After multiple penalties, the node's reputation score will drop to an extremely low state, that is, a low reputation score state, and will eventually be removed from the system. Moreover, the higher the node's reputation score, the greater the penalty intensity of the penalty mechanism, and the more reputation points will be deducted. However, this also brings another problem, that is, the malicious node maintains a reputation score slightly higher than the low reputation score state after being punished, disguises itself as an honest node after committing evil, waits for the reputation score to return to the state at the beginning, and repeats the evil again. Since the penalty mechanism deducts fewer points when the reputation score is low, the interval between committing evil is shorter than the interval between committing evil with a high reputation score and then waiting for the high reputation score to be restored before committing evil again. In order to solve this problem, this method changes the fixed basic penalty coefficient in the evil penalty to a basic penalty coefficient that automatically increases with the number of times the node commits evil. The basic penalty coefficient of each node is calculated independently:

[0097] base=cnt+initBase

[0098] Where cnt is the number of times the node has committed evil, and initBase is the initial minimum penalty coefficient.

[0099] So the final penalty calculation method is

[0100]

[0101] It's easy to see that this reputation penalty method can significantly reduce a node's reputation score, while also ensuring that higher node reputations lead to greater penalties, and that the more times a node commits malicious acts, the greater the penalties. This achieves the following: 1. Malicious nodes are penalized. 2. When a malicious node disguises itself as an honest node to gain a high reputation and then commits malicious acts, its reputation score can be quickly lowered, allowing it to be quickly identified. 3. If a malicious node repeatedly commits malicious acts over a period of time, the intervals between acts will rapidly lengthen as the penalties gradually increase, effectively preventing it from committing malicious acts or being identified.

[0102] In summary, the reputation mechanism enables honest nodes to obtain higher reputation scores. Malicious nodes' reputation scores drop significantly when they engage in malicious activities, and they are forced to maintain their lowered reputation scores. Furthermore, it can identify malicious nodes that repeatedly engage in malicious activities and remove them from the system. The combined effect of the reputation mechanism and the consortium chain's access mechanism significantly increases the cost of malicious behavior, thereby reducing malicious behavior, improving system security, and providing a foundation for node reallocation based on network conditions.

[0103] After the epoch consensus block generation phase concludes, Phase 2 begins. Nodes broadcast their reputation scores to each other and package the consensus into the reputation chain. This then leads to node allocation based on network conditions. To ensure that nodes can independently calculate the same results based on the reputation chain and verify the results of other nodes, the following method uses a verifiable delay function to provide a random seed. This ensures that the random results of each node are consistent and verifiable, and prevents malicious nodes from pre-emptively obtaining them.

[0104] The node exchange reputation and node allocation stages in Phase 2 are described below.

[0105] Nodes exchange reputation points by establishing a reputation blockchain in which all nodes participate. This is done by following the steps below:

[0106] Step 2.1: All nodes broadcast their local node reputation scores;

[0107] Step 2.2: When a node receives the same reputation score from a set number of different nodes in the same shard, it considers the same reputation score as a provisional result. If the result is the same from at least 2 / 3 of the shard nodes in the PBFT-like consensus, it is considered a provisional result.

[0108] Step 2.3: The packaging node packages the tentative result into a reputation block and adds it to the reputation blockchain for consensus;

[0109] Step 2.4: The node verifies based on the reputation block and local tentative results;

[0110] Step 2.5: If the reputation block passes consensus, jump to step 2.7, otherwise jump to step 2.6;

[0111] Step 2.6: Change the packaging node and return to step 2.3;

[0112] Step 2.7: The node uses the reputation block content as the reputation score of all nodes in this epoch.

[0113] Figure 4 This is a flowchart for node redistribution based on network conditions in Phase 2. First, all nodes are assigned a reputation level based on their reputation score. Nodes with high reputation scores are considered relatively trustworthy and are clustered according to network conditions. Nodes with medium reputation scores are considered average trustworthiness and are randomly assigned to prevent malicious nodes from being assigned to the same shard. Nodes with low reputation scores, considered malicious, are formally removed from the system to ensure security.

[0114] For high credibility scores, the clustering process is as follows: Figure 5As shown in the figure, we first select k*m initial clusters and perform preliminary clustering. Then, we merge these k*m clusters to obtain the final clustering result with a high credibility score. The following will describe the detailed steps in turn.

[0115] Step a1: Assume the target is m shards, each with n nodes, and k is the initial coefficient, resulting in a total of N high-reputation nodes. The first step is to shuffle the N high-reputation nodes and randomly select k*m nodes as initial clusters, with one node in each cluster. These initial clusters have two upper limits: a soft upper limit during the initial clustering process, i.e., before cluster merging, to reduce the possibility of exceeding the n-node limit after merging clusters. The other is a hard upper limit during cluster merging, which limits each shard to no more than n nodes. The soft upper limit is n / k, rounded down + 1.

[0116] Step a2: Node merging step:

[0117] After generating k*m nodes, the remaining nodes with high reputation scores are processed in order. For each cluster, the cost of joining a node is calculated. This cost is defined as a function of network bandwidth and network latency. The cost is lower when the network bandwidth is greater and the latency is lower, while the cost is higher when the network bandwidth is smaller and the latency is higher.

[0118] The cost is calculated as follows: if the cluster reaches the soft cap, the cost is infinite; otherwise, the cost of joining the cluster is calculated. The cluster cost of a node joining is the sum of the node pair costs between each node in the cluster and the node to be joined. For a node pair in the cluster, the following cost function is used:

[0119]

[0120] Where len(nodes) is the number of nodes in the cluster, blockAvgSize is the average block size, sendRate is the sending rate between two nodes, i.e., the network bandwidth, and sendLatency is the sending latency between the two nodes. The cost function approximates the cost of sending a block due to network overhead, while the cost function approximates the cost due to latency.

[0121] Therefore, the cost function for a node to join a cluster is:

[0122] clusterCost = sum(nodeCost)

[0123] Finally, the node selects the cluster with the lowest cost to join. Since the number of clusters is k*m, and the soft cap is n / k rounded down + 1, the maximum number of nodes that can be included while meeting the soft cap is n*m+k. This is greater than n*m, and therefore greater than the number of high-reputation nodes, N. Therefore, all high-reputation nodes can join the cluster without exceeding the soft cap.

[0124] Step a3: Cluster merging step.

[0125] This step consists of two parts. The first is to merge clusters, and the second is to process clusters that failed to merge in the first step, splitting them and attempting to merge them again. In the first step, m clusters are randomly selected from the k*m clusters as candidates. The remaining clusters are then randomly shuffled and processed in turn. When merging a cluster, the cost between the two clusters is calculated for each candidate. Similar to the cost calculation when a node joins a cluster, the cost is calculated in two ways: exceeding the upper limit and not exceeding the upper limit. That is, if the number of nodes after the merger exceeds the hard upper limit, n, the cost is infinite. When not exceeding the upper limit, the cost between the two clusters is defined as: for each node in the first cluster, the cost of the node with respect to the second cluster is calculated in sequence, and the sum of the costs of all nodes is the cost between the two clusters. If the final lowest cost is still infinite, meaning that merging the current cluster into any candidate cluster would exceed the hard upper limit, the cluster is retained and proceeds to the second step of the cluster merging step. Otherwise, the cluster is merged into the cluster with the lowest cost.

[0126] After the first part is complete, there will be very few clusters remaining that require processing in the second part. These remaining clusters will be processed one by one. For a specific cluster, it will be directly split and its nodes will be processed one by one. The processing of each node is similar to the steps for adding nodes to candidate clusters one by one, the only difference being the calculation method for whether the upper limit has been reached when calculating the cost. In the previous step, the upper limit used was the cluster's soft upper limit. In this part, the cost is infinite only when the hard upper limit of n nodes is reached in the cluster. If the upper limit is not reached, the cost calculation method is the same, and the node finally chooses the cluster with the lowest cost to join.

[0127] Since the number of high-reputation nodes N is less than m*n, all high-reputation nodes can eventually be added to the corresponding cluster, and there are a total of m clusters, and the number of nodes in each cluster is less than or equal to n.

[0128] Nodes with high reputation scores pay a higher price for malicious activity and are therefore more trustworthy. This method estimates the cost of intra-shard consensus after assigning nodes to the same shard, i.e., the aforementioned cost, and selects the lowest-cost allocation method. This allows high-reputation nodes with better network conditions to be assigned to the same shard. As epochs increase, the number of high-reputation nodes increases, achieving a better allocation.

[0129] Nodes with medium reputation scores are assigned randomly. The random assignment of medium reputation nodes must also ensure that it does not exceed the upper limit of the number of nodes in the shard. First, all medium reputation nodes are randomly shuffled and processed in turn. The medium reputation nodes are randomly added to m clusters unless the cluster has reached the hard limit. Since the sum of the number of high reputation nodes and medium reputation nodes is less than or equal to m*n, this process can be completed. In order to ensure that each honest node can independently obtain the same result, the node should use methods such as delayable functions and the hash value of the last reputation block to obtain a consistent random seed, and use the same random method to make all random methods in this method deterministic, that is, when the input is the same, the output must be the same.

[0130] Randomly assigning nodes with medium reputation scores ensures a certain degree of randomness, preventing malicious nodes from obtaining advance knowledge of node reallocation results, thereby launching targeted joint attacks and reducing the security of the next shard. Since random assignments are unpredictable, malicious nodes cannot learn and manipulate node allocation results in advance, making it difficult for them to launch targeted attacks.

[0131] Nodes with low reputation scores are not assigned to any cluster and are removed from the system to avoid participating in the next epoch.

[0132] Nodes with low reputation scores are identified as malicious nodes and can be blacklisted when they are identified during the consensus block generation phase. They are removed here to prevent slow nodes from syncing in time, blacklist malicious nodes, and record them.

[0133] Since the random numbers used above can be seeded by a verifiable delay function, the same random number generation method ensures consistent and verifiable random numbers. All other steps are deterministic, and all nodes have the same inputs. Therefore, the final node redistribution result can be independently generated and verified by each node.

[0134] Finally, the nodes package the results, pass consensus, and verify them on the reputation chain, ending the node redistribution phase. Each node needs to complete state migration and other preparations according to the node redistribution plan to start the next epoch.

[0135] As epochs increase, node redistribution based on network conditions gradually allocates nodes with better network conditions to the same shard, improving the efficiency of intra-shard consensus and ultimately reducing transaction latency and increasing system throughput. At the same time, the reputation mechanism reduces the cost of malicious nodes, quickly detecting persistent malicious nodes and ensuring the security of node redistribution based on network conditions.

[0136] The above specific embodiments merely illustrate the design principles of the present invention. The shapes and names of the components described herein may vary and are not limiting. Therefore, those skilled in the art may modify or substitute equivalents for the technical solutions described in the above embodiments. Such modifications and substitutions, without departing from the inventive spirit and technical solutions of the present invention, shall fall within the scope of protection of the present invention.

Claims

1. A sharded alliance chain redistribution method based on reputation mechanism and node network conditions, characterized in that: This method divides the operation process of the blockchain system into epochs. Each epoch consists of two stages: the consensus block generation stage and the redistribution stage. Phase 1: The consensus block generation phase calculates the node reputation score. Nodes that contribute positively to the consensus will have their reputation score increased, while nodes that contribute negatively to the consensus will have their reputation score reduced. Phase 2: Redistribution phase, nodes exchange reputation points and are redistributed based on reputation points. During redistribution, nodes are divided into high reputation points, medium reputation points, and low reputation points according to their reputation points. Eliminate nodes with low reputation scores; cluster high reputation score nodes according to network conditions to obtain a preliminary node reallocation plan; randomly assign reputation score nodes to the preliminary node reallocation plan to obtain the final node reallocation plan.

2. The method according to claim 1, wherein The reputation score is calculated based on additional reputation information; the additional reputation information is the contribution of the shard node to the previous consensus and any evidence of possible malicious behavior.

3. The method according to claim 1, wherein The node reputation score calculation in the first phase is performed independently. Each node only calculates the reputation scores of the consensus nodes in its own shard, and the calculation is performed once for each consensus. The first phase includes the following steps: Step 1.1: When a node packages a block, it attaches additional reputation information; the additional reputation information includes the contribution of the node in the previous consensus and any evidence of malicious behavior. Step 1.2: When a node receives a block for verification, it performs an additional verification step: verifying the additional credibility information in the block, that is, whether the contribution of the shard node to the previous consensus meets the set requirements and whether the evidence of malicious behavior is true; if not, the block is rejected from passing the consensus; Step 1.3: Determine whether the block has passed consensus; if the block has passed consensus, jump to step 1.4; otherwise jump to step 1.5; Step 1.4: After the block passes consensus, the nodes calculate the reputation score of each node based on the additional reputation information in the block; Step 1.5: If the block fails to pass consensus, the node will record the evidence of malicious behavior in this consensus in the next consensus block.

4. The method according to claim 3, wherein In step 1.2, the verification step is to determine whether the deviation between the additional reputation information in the block and the additional reputation information of the previous consensus received by the node is within the error range; If the error is exceeded, the block is rejected from consensus.

5. The method according to claim 4, wherein Determining whether the deviation between the additional reputation information in the block and the additional reputation information received by the node in the previous consensus is within the error range is as follows: comparing the voting information of the shard node in the prepare and commit phases received by the node in the previous consensus with the voting information in the additional reputation information in the block, and determining whether the number of different votes is within the error range; If the error is exceeded, the block is rejected from consensus.

6. The method according to claim 3, wherein In step 1.4, the credit score is calculated as follows: score=baseScore*(baseTxScore+log2(txLen))*leaderScore Among them, score is the reputation score; baseScore is the basic score used to control the growth rate of the reputation score; baseTxScore+log2(txLen) is the reward score coefficient for the number of block transactions; baseTxScore is the basic reward score for completing consensus; txLen is the number of transactions in a block; the log function provides reputation rewards to nodes that continuously contribute to consensus in the transaction reward part; leaderScore is the restriction coefficient that limits the leader node from obtaining too high a reputation score; when the node is an ordinary node, leaderScore is 1; when the node is a leader node, leaderScore is a value less than 1; For malicious behavior, determine the base penalty coefficient base and punish the reputation score: r new ＝2 t Among them, r new is the node reputation score after punishment, and t is the intermediate value.

7. The method according to claim 6, wherein The basic penalty coefficient base automatically increases with the number of times the node commits malicious acts: base=cnt+initBase Where cnt is the number of times the node has committed evil, and initBase is the initial minimum penalty coefficient.

8. The method according to claim 1, wherein In the second phase, nodes exchange reputation points by establishing a reputation blockchain in which all nodes participate, following the steps below: Step 2.1: All nodes broadcast their local node reputation scores; Step 2.2: The node receives the same reputation score from a set number of different nodes in the same shard and considers the same reputation score as a provisional result; Step 2.3: The packaging node packages the tentative result into a reputation block and adds it to the reputation blockchain for consensus; Step 2.4: The node verifies based on the reputation block and local tentative results; Step 2.5: If the reputation block passes consensus, jump to step 2.7, otherwise jump to step 2.6; Step 2.6: Change the packaging node and return to step 2.3; Step 2.7: The node uses the reputation block content as the reputation score of all nodes in this epoch.

9. The method according to claim 1, wherein In the node redistribution step based on the reputation score, when processing the nodes with medium reputation scores, different nodes use the same random algorithm to determine the allocation scheme of the nodes with medium reputation scores.

10. The method according to claim 1, wherein In the step of node redistribution based on reputation score, the high reputation score nodes are clustered according to network conditions into: Step a1: Randomly select k*m nodes to establish initial clusters, with one node in each cluster; k is a pre-determined multiple, and m is the number of shards; all initial clusters are the first candidate clusters in step a2; Step a2: Node merging: add the remaining nodes to the first candidate cluster in sequence; In this step, for a node to be processed, the cost of the node joining each first candidate cluster is calculated; The cost is defined as a function of network bandwidth and network delay; the greater the network bandwidth and the lower the network delay, the lower the cost; the smaller the network bandwidth and the higher the network delay, the higher the cost; the node is added to the first candidate cluster with the lowest cost; If there are multiple first candidate clusters with the lowest cost, one of the first candidate clusters with the lowest cost is randomly selected to join; if the number of nodes in the first candidate cluster has reached the set upper limit, it will no longer be used as the first candidate cluster in step a2; Repeat step a2 until all remaining nodes are processed; Step a3: Cluster merging: Randomly select m clusters from all the clusters obtained in step a2 as the second candidate clusters, and process the other clusters in turn and merge them into the second candidate clusters; In this step, for a cluster to be merged, the first cost of all nodes in the cluster to be merged joining a candidate cluster C is calculated in sequence, and the sum is calculated to obtain the second cost of merging the cluster to be merged into the candidate cluster C; Calculate the second cost of merging the cluster to be merged into each candidate cluster in sequence; Finally, the cluster to be merged is merged into the candidate cluster with the second lowest cost. If there are multiple candidates with the lowest cost, one of them is randomly selected. If the number of nodes in a candidate cluster has reached the upper limit, or exceeds the upper limit after merging, it will not be considered as a candidate cluster this time; If there is no optimal candidate cluster for merging, the current cluster to be merged is split and the nodes are merged according to step a2; Repeat step a3 until all clusters are processed.

Images