404
Views
0
CrossRef citations to date
0
Altmetric
Research Article

A reputation-based dynamic reorganization scheme for blockchain network sharding

, , , &
Article: 2327438 | Received 28 Nov 2023, Accepted 03 Mar 2024, Published online: 12 Mar 2024

Abstract

While sharding technology helps solve performance bottlenecks in traditional blockchain networks, it also introduces new challenges. Random node allocation may lead to uneven distribution of malicious nodes, causing performance differences and security risks. Existing reputation-based sharding schemes often overlook node performance characteristics and fail to address security concerns related to leader election. In addition, full sharding reorganisation drastically reduces the performance of the entire blockchain, both in terms of overhead and time. In this paper, we propose a reputation-based sharding dynamic reorganisation network sharding scheme, which integrates node performance and behavioural characteristics into the reputation computation, and at the same time adds alternative leaders to maintain the stability of the sharding system. Based on this, through the partial reorganisation algorithm of the sharding, the nodes are reasonably allocated to balance the computing power of each shard, effectively stimulating the liveness of the sharding system and improving overall safety and performance. Simulation results show that this sharding scheme effectively reduces the consensus failure probability, solves the collusion attack problem caused by the aggregation of malicious nodes within shards, and reduces the latency of the blockchain system. This provides strong support for the reliability and performance of the blockchain sharding system.

1. Introduction

Blockchain, as one of the key technologies of distributed ledgers, has been widely used in the fields of financial services, supply chain technology, government governance, and gaming services (An et al., Citation2019; Ferrag et al., Citation2021; Mizrahi & Rottenstreich, Citation2021; Zhang et al., Citation2022). It has achieved significant successes and achievements with its decentralised, anonymous, and non-tamperable characteristics. However, current blockchain technologies face serious scalability challenges (Bez et al., Citation2019; Qi et al., Citation2020)]. To ensure the reliability and security of transactions, the blockchain systems require all nodes to validate and store all transactions. This results in its low throughput and high latency. For example, Bitcoin (Nakamoto, Citation2008) and Ethereum (Buterin, Citation2014) can only process 7 and 15 transactions per second (tps), respectively. The performance severely limits their development and applicability. Blockchain sharding (Jia et al., Citation2021), a common method of expansion on the chain, divides the entire blockchain network into different shards, and the nodes within each shard are responsible for processing transactions within their respective shard and storing the state of the shard. Through parallelising transaction validation, it can overcome the scalability issues faced by blockchain.

Although sharding has the potential to significantly enhance overall throughput, it also introduces a set of new challenges. After sharding, each shard contains only a limited number of nodes, thereby diluting trusted nodes in it. Yet this greatly decreases the cost for an attacker to perform malicious behaviour (Zhang & Zhou, Citation2020) within a single shard, thus increasing the risk of 51% attacks and single shard takeover (Ray, Citation2019). As a result, malicious nodes can easily control a sufficient number of shard nodes to gain control of more than half of them to launch a collusion attack (Zhang et al., Citation2024). Even though the proportion of malicious nodes in the blockchain system is much less than 50%, if the network nodes are not allocated properly, it may still lead to system damage. Existing sharding schemes such as Elastico (Luu et al., Citation2016), Omniledger (Kokoris-Kogias et al., Citation2018), and RapidChain (Zamani et al., Citation2018) are mostly based on random sharding. They determine the shard to which a node belongs through unpredictable allocation, which only avoids the problem of collusion attacks caused by malicious nodes aggregating to the same shard with a certain probability. They often overlook the differences between nodes, resulting in performance gaps between shards. If a large number of malicious nodes are randomly assigned to a particular shard, it will pose significant challenges to the security and stability of the blockchain shard.

After the introduction of the reputation concept, the reputation value is used to evaluate the behaviour of the nodes, which provides a basis for sharding. By reasonably allocating nodes to balance the computing power of each shard to improve the security and performance of the overall system. However, these reputation calculations often focus on the behavioural performance of nodes within the network, ignoring the inherently different performance characteristics of each node. Furthermore, given the crucial role of leader nodes in the work process, any security risks within these leader nodes can pose a significant threat to the entire system. Therefore, in reputation sharding, the reputation calculation method and the security of the leader node still need our serious treatment. Furthermore, to mitigate the risk of nodes engaging in malicious behaviour, numerous sharding schemes necessitate substantial time and resources for shard reconfiguration once a sharding epoch has concluded. In this way, the entire network experiences a halt in transaction verification, as the entire network must transition between new and old ledgers before and after reconfiguration (Tian et al., Citation2023). This significantly reduces the overall performance of the entire blockchain.

To address the current shortcomings, this paper presents a reputation-based dynamic reorganisation scheme for network sharding. The scheme integrates both the performance and behavioural characteristics of nodes and designs a comprehensive reputation calculation method to improve the comprehensiveness and accuracy of reputation evaluation. The election of leaders and alternative leaders within shards to enhance the security of the system. In addition, we have designed a sharding reconfiguration algorithm that divides shards into trusted shards and normal shards based on their reputation scores, extracts some nodes from the trusted shard, and unifies the allocation with the newly joined nodes. This approach effectively enhances the liveness of the sharding system, addressing the heightened security risks and low consensus efficiency problems after blockchain sharding. The main contributions of this paper are as follows:

  1. We propose an architecture consisting of a supervisory committee and regular shards. By introducing an election mechanism for leaders and alternative leaders to enhance the security of the blockchain network and facilitate orderly transaction allocation and consensus synchronisation.

  2. We introduce a reputation calculation scheme that comprehensively considers both the performance characteristics and behaviour characteristics of validation nodes to more comprehensively evaluate the credibility and value of nodes. By setting a threshold, nodes with scores below it can be eliminated. This approach establishes a foundation for node allocation and management.

  3. We propose a dynamic shard reorganisation algorithm that ensures an even distribution of computing power among shards through reasonable node allocation. By preventing the aggregation of malicious nodes within a single shard to launch collusion attacks, the credibility and liveness of the entire sharding system are significantly enhanced.

The remaining sections of this paper are organised as follows. Section II discusses related work. Section III introduces the proposed model and Section IV provides a detailed explanation of the system design. Section V summarises the results of simulation experiments and Section VI concludes the paper.

2. Related work

In this section, we will delve into the development of blockchain sharding technology and explore existing literature about reputation-based sharding systems, which emerge as reputation increasingly infiltrates the blockchain.

2.1. Sharding technology

Sharding technology is continuously evolving through updates and iterations, These advancements focus on improving throughput, reducing latency, and refining consensus protocols. As a result, the robustness (Eyal et al., Citation2015) and practicality of sharding technology are significantly enhanced. Omniledger, drawing upon Byzcoin (Kogias et al., Citation2016), adopts the Atomix technology based on lock verification to enhance node validation security. Monoxide (Wang & Wang, Citation2019) introduces shard-based asynchronous consensus zones and proposes Chu-ko-nu mining, which elevates the minimum computing power required to launch a 51% attack within a single shard to 51% of the overall network’s computational capacity. However, it still relies on PoW for block generation, which may not be the ideal balance between security and energy efficiency. To prevent node collusion, in contrast to the secondary fully randomised sharding, Rapidchain (Zamani et al., Citation2018) employs the Cuckoo rule to periodically conduct partial node redistribution. The age of the k-region is designed to indicate the amount of time that has elapsed since the node joined the committee, but it may be more convincing to base it on the reputation of the node.

2.2. Reputation blockchain

In recent years, the concept of reputation has gradually infiltrated the blockchain. CertChain (Chen et al., Citation2018), proposes a consensus and incentive mechanism based on dependability-rank, which takes into account a combination of economic benefits and bad behaviours. B-IoT (Huang et al., Citation2019) and PoT (Bahri & Girdzijauskas, Citation2019) both propose credit-based Proof of Work (PoW) systems to reduce the high computational costs. They achieve this by assigning mining tasks with lower difficulty to nodes with higher trust levels. Similarly, RepuCoin (Yu et al., Citation2019) proposes a reputation-based weighting scheme consensus. However, their reputation scores are accumulated from the very beginning of the chain and are the total number of valid transactions without decay, so collusion of high reputation users could potentially lead to monopolisation and double-spending attacks.

2.3. Reputation and sharding

With the introduction of the reputation-based sharding scheme, in dealing with malicious nodes, unlike the Practical Byzantine Fault Tolerant (PBFT) protocol (Castro & Liskov, Citation2002) which can only tolerate malicious nodes without appropriate measures, this could potentially result in a crash of the distributed system. Previously, Hao and Jiang introduced the concepts of Participation Degree (PD) (Hao et al., Citation2018) and Health status (Jiang & Lian, Citation2019) to identify the nodes to be expelled. The nodes are judged whether to be expelled or not by full voting, which increases the communication consumption of the system (Shen, Citation2022). Yun et al. (Citation2019) propose a trust-based shard distribution (TBSD) scheme, which prevents malicious miners from gathering on a single shard by integration of a trust management system and genetic algorithm (GA). However, it does not consider the difference in communication delay between shards, which will lead to inefficiency as the number of nodes increases. Zhang, Guo, Liu, et al. (Citation2023) consider the communication delay between shards and differences in the number of nodes and propose a sharding algorithm based on Differential Evolution (SDE), which is iteratively adjusted to obtain an optimised node allocation.

The proposal of a reputation-based sharding scheme involves the calculation of reputation scores, taking into account the transaction time and the accuracy of the relevant information (Wang et al., Citation2019), which reflect the capabilities and reliability of the validators. These reputation calculations are often based on the behavioural characteristics of the nodes, overlooking the inherent different levels of computation among nodes. However, it is not reasonable to consider only a single influencing factor in the performance characteristics and behavioural characteristics of nodes in network sharding. If only node performance characteristics are considered, malicious nodes may potentially gather in a single shard and there is a risk of a potential single shard takeover. Conversely, if only the behaviour characteristics of nodes are considered while ignoring the performance characteristics of nodes, it may result in significant performance differences between different shards, ultimately affecting the overall system performance.

The election of shard leaders is based on reputation score by verifiable random function (VRF) (Huang et al., Citation2021; Zhang, Li, and Zhao, Citation2023). However, the security of the shard leaders has a significant impact on system performance. When a dishonest leader engages in malicious behaviour, the process of honest nodes in the shard initiating a trace-back procedure and re-selecting a new leader incurs significant performance overhead (Zhang, Li, Chen, et al., Citation2023).

In summary, while sharding can improve blockchain performance, it also raises the issue of sharding vulnerability. After sharding, node performance differences are often ignored, and malicious nodes are unevenly distributed in the system thus increasing the risk of collusion attacks. There is a critical need for an improved reputation management mechanism, and we need to take the reputation calculation method and the security of the leader node seriously. In addition, full sharding reorganisation drastically reduces the performance of the entire blockchain, both in terms of overhead and time. There is still a lack of a complete and systematic sharding scheme that can balance consensus efficiency as well as security.

3. Model and overview

3.1. System model

This paper elucidates the concept of an epoch as the designated time interval within which network nodes are assigned to shards for processing transactions. We assume that all nodes in the network join the system in an epoch by submitting a POW puzzle solution. This measure aims to prevent potential Sybil attacks. By requiring nodes to solve puzzles, the system ensures that it is difficult for nodes to enter and reduces the likelihood that dishonest nodes can influence the system by creating multiple identities. In an epoch denoted as t, for a blockchain with a total of n nodes, V = v1,v2, … ,vn, the network nodes are sharded into k subsets, represented as C = c1,c2, … ,ck. Each shard includes one leader and one alternate leader, with the rest serving as validator nodes. The reputation score of each node is r(vi).

3.2. Threat model

In blockchain sharding systems, a collusion attack refers to a scenario in which an attacker gains more than 51% of the computing power, theoretically enabling control of most of the decision-making power of the network. Such attacks may include tampering with transaction records, double spending, conspiring to manipulate consensus algorithms, or initiating denial of service attacks to undermine system performance. Collusion attacks disrupt the trust mechanisms of sharding systems, threatening user assets and rights. Therefore, protecting against such attacks is a critical challenge in the design of blockchain sharding systems.

In this paper, all nodes in the system are represented based on their reputation scores R = {r(v1),r(v2), … ,r(vn)}, which indicate their computational capabilities. We denote the set of malicious nodes as CVMal, and the computing power of the entire network is R(V)=i=1nr(vi). Assuming a uniform distribution of network nodes into various shards based on their computing power, the score for each shard is considered to be R(Vci)=i=1nr(vi)/k. However, in practical network sharding, due to the random allocation of nodes, there is an imbalance in the distribution of nodes across shards. In such a scenario, shards with the lowest reputation are more easily to aggregate malicious nodes and are most vulnerable to collusion attacks.

For any given shard, the ratio of the number of malicious nodes in the shard to the total number of nodes in the shard is referred to as the malicious node ratio of the shard, denoted as Nr. (1) Nr=num(VMali)num(VCi)(1) In reputation-based sharding, for any given shard, the ratio of the computing power controlled by malicious nodes within the shard to the total computing power of the shard is referred to as the collusion computing power ratio of the shard, denoted as Rr. (2) Rr=R(VMali)j=1Vcjr(vj)(2) For any given shard, if Rr ≥ 51%, we call that this shard is subject to collusion attacks. In the case of a blockchain with k shards, the ratio of shards affected by collusion attacks to the total number of shards is called the shard collusion attack ratio, denoted as Mr. (3) Mr=num(Rr51%)k(3) After partitioning nodes using sharding technology, even if malicious nodes with different computing powers aggregate in one shard and their total computing power exceeds 51%, it does not necessarily mean that there is a risk of collusion attack. This is because, in the distributed environment of blockchain, it is very difficult for nodes to cooperate with each other to launch a collusion attack. Therefore, in the security analysis of this system, we assume that all malicious nodes in a shard participate in a collusion attack, which is a worst-case scenario considered for security research.

3.3. System overview

We have introduced a novel sharding scheme where transactions are processed collaboratively by a two-tier sharding architecture with a supervisory committee and regular shards. Within each shard, leaders and alternate leaders are randomly selected based on the cumulative reputation of the nodes. The core components of this scheme include reputation management and shard reconfiguration.

Reputation Management: The supervisory committee calculates the scores of all nodes by considering the performance characteristics and behavioural characteristics of the verified nodes. In addition, nodes that do not reach the threshold score are subject to expulsion after voting by the supervisory committee.

Shard Reconfiguration: At the end of each consensus epoch, trusted and normal shards are partitioned based on shard reputation scores, and shard reconfiguration is performed. Node allocation is based on node reputation, ensuring a balanced distribution of computing power among the shards.

Based on reputation management, this approach effectively improves the liveness of the system through dynamic sharding reconfiguration. By allocating nodes reasonably, computing power is balanced across shards, avoiding security vulnerabilities caused by a reduced number of nodes in individual shards after sharding. This also allows the shard consensus algorithms to balance efficiency and improves the overall security and performance of the system.

4. System design

4.1. System architecture

The system architecture consists of a supervisory committee and regular shards. At the beginning of the first epoch, following the network maturity criteria proposed by Velloso et al. (Wang et al., Citation2019), the oldest nodes in the network are selected as supervisors, forming the supervisory committee. Furthermore, the supervisory committee randomly divides all network nodes into different groups to form multiple regular shards. In subsequent epochs, the shard reconfiguration rules determine the composition of each shard. After the reallocation is complete, the shard with the highest total score is selected to form the supervisory committee. The design of the supervisory committee effectively facilitates communication among different members and guarantees the security of the system. In addition to the supervision work of nodes, the supervisory committee is also involved in tasks such as transaction allocation, consensus synchronisation, and node expulsion. The specific advantages are reflected in the specific details of each operation.

After the formation of shards, we select the nodes with reputation scores in the top 50% as leader intervals in each shard and randomly select the leader and alternate leader in the shard within the interval. Alternate leaders need to monitor the behaviour of their leaders. If a malicious leader engages in activities such as going on strike or withholding messages, honest nodes within the shard will not be able to receive messages from the leader within the response time. As a result, they will broadcast an urgent notification to other nodes in the shard, and the alternate leader reports to the supervisory committee, and request an alternative replacement. It is especially noted that the leader node from the previous epoch is explicitly excluded from the selection interval in the current round.

After completing the sharding configuration, the communication process of the system data is shown in Figure . The following section provides a detailed description of the steps involved.

  1. Upon receiving a transaction, the supervisory committee will appoint the corresponding validation nodes to verify the transaction and broadcast it to all relevant shards across the entire network. Depending on whether the transaction involves a single shard or multiple shards, the consensus can be categorised into intra-shard consensus and cross-shard consensus.

  2. The input shard receiving the validation message uses PBFT consensus within the shard. The leader node sends a list containing the transaction ID, the timestamp (t1) of the sent transaction, and the signatures of the leader to all nodes within the shard. Each node receives the list of transactions, verifies it and makes its own decision Dtxi, and sends it back to the shard leader. Cross-shard consensus is adapted from Omniledger. When the supervisory committee receives a cross-shard transaction, the transaction ID determines a supervisor to oversee the entire process of participation in the transaction by an atomic protocol. This approach reduces the complexity to O(n) compared to full-shard participation and replaces the role of the client by the supervisory committee, effectively facilitating communication between input shards and output shards, thereby reducing the risk of replay attacks and transaction forging attacks.

  3. Each shard leader packages the verification result sets, timestamps, and signatures of the transactions along with the signatures of the senders into mini blocks and sends them to the supervisory committee.

  4. After receiving the transaction blocks and the corresponding results, the supervisory committee aggregates the messages returned by all relevant shards, verifies the validity of the signatures within that data, and generates the new block broadcast to the network.

Figure 1. System architecture and the process of communicating data.

Figure 1. System architecture and the process of communicating data.

In this process, the regulatory committee maintains records for each transaction allocated to every shard and when that shard submits the mini block upon transaction completion. This approach enables monitoring to identify potential congestion resulting from transaction clustering within a particular shard. The regulatory committee dynamically adjusts the transaction distribution strategy based on real-time transaction traffic. When the transaction volume in a shard exceeds a certain threshold, the system prioritises redirecting a portion of the transactions to other shards with relatively lighter loads, aiming to achieve load balancing.

4.2. Reputation management

4.2.1. Reputation calculation

The supervisory committee compares the transaction processing results after receiving the mini block (which also includes the signature of the leader itself, the signatures of all the verifying nodes, and the response time while verifying the transaction) from the leader of the shard. The supervisory committee calculates the reputation score for the nodes in this epoch based on the behaviour and performance characteristics of validators through a reputation evaluation. The formula for calculating the influence factors of node reputation is as follows: (4) δt={0,t=0,l=0ρ×δt1+(1ρ)×(j=1lS(j)×αj×C),t>0(4) Where δt1 is the historical factor of the node, l is the number of verified transactions, and C represents the initially assigned performance capability of the node. αj is the verification result coefficient that compares the transaction results, taking the value of 1 if the node validation result is correct, and conversely taking the value of −1 if it is wrong. S(j) is the reward or penalty coefficient, with the following standard reference settings:

  1. Take v(i) = 1-(i-1)/n as a reference to denote the i-th node that completes the consensus, and the node that completes the verification faster has a greater reward/penalty value;

  2. The reward/penalty strength for the supervisory committee and each shard leader should be greater than that for regular verification nodes. This is because if leader nodes are malicious, they can cause greater damage to the entire system.

A time decay factor ρ is added to the equation to regulate the validity of the historical reputation. ρ takes values in the range of (0, 1), with larger values of ρ meaning that more weight is given to the accumulation of previous periods of the validation node, and conversely a greater emphasis on the computed scores of the current epoch. To prevent nodes from rapidly acquiring high reputation scores within a few brief epochs to engage in malicious activity, ρ > 0.5 is generally set.

To prevent the infinite growth of reputation scores, the influence factor of the node's reputation scores is scaled so that the final scores range from [0,10]. The current maximum score max_score, minimum score min_score are obtained and the final reputation score is calculated as follows: (5) Rt=δtmin_scoremax_scoremin_score×10(5) Under this control, the reputation score will not increase indefinitely, thus avoiding the possibility of monopolisation.

Rather than defining a uniform value for the reputation of newly joined nodes, we combine the fact that the nodes have different performance capabilities. Therefore, the reputation value for a newly joined node is defined as the sum of its performance capability C and the node expulsion threshold.

4.2.2. Node expulsion

After the reputation scores of all validating nodes are computed, nodes with scores below the threshold are expelled after voting by the supervisory committee. Where the threshold can be set specifically for different network environments, as shown in Figure .

  1. All members of the supervisory committee issue voting transactions for nodes with a reputation score below the threshold: Txvote=<pki,pkj,t1,Dj,sj>Where pki is the public key of the malicious node, pkj is the public key of the supervisor, t1 is the timestamp of the vote, Dj is the decision made by the supervisor for this vote, and sj is the signature of the supervisor.

  2. To expel a node from the network, more than half of the supervisors must agree that the node has fallen below the trust threshold. The leading node of the supervisory committee collects all voting information from the supervisors. All voting transaction information is statistically validated and mined in a block. If the number of votes agreeing to expulsion is more than half of the total, node i will start to exit.

  3. The leading node of the supervisory committee issues an expulsion transaction: Txexpulsion=<pki,pkj,t1,t2,sj>where t2 is the timestamp of the node expulsion.

  4. The leading node broadcasts the results of the expulsion, deletes the address of the expelled node, and discards its public key. All nodes update their network views, and the supervisory committee updates the reputation list of the system.

If an expelled node rejoins the network, it has to generate a new key pair and discard all previous reputation accumulations.

Figure 2. The expulsion process of nodes.

Figure 2. The expulsion process of nodes.

This mechanism serves as an incentive for nodes to behave honestly. Compared to a system where all members participate in voting to decide whether a node should be expelled, the voting process involving only the regulatory committee significantly reduces the communication overhead.

4.3. Shard reconfiguration

Compared to full reconfiguration, partial reconfiguration updates committee members more quickly, making it better suited to adapt to dynamic changes in nodes. This reduces the computational and communication overhead of the entire reorganisation process and enhances the flexibility and adaptability of the system. Therefore, to balance system availability and expenses, we will use a partial reconfiguration method at the end of an epoch based on the dynamic sharding reconfiguration algorithm shown in Algorithm 1. The process is illustrated in Figure :

  1. The supervisory committee divides trusted shards and normal shards, each accounting for half of the total based on the total reputation value of each shard. Randomly extract α percentage of trusted shard nodes, including the leader nodes in the shard. All extracted nodes are placed in a distribution list and await allocation.

  2. Newly added nodes are placed in the same list as in the previous step. All nodes are sorted in descending order based on their reputation scores and assigned to shards with lower overall reputation scores, thus maintaining similar performance levels for each shard.

  3. After the redistribution is complete, the shard with the highest total reputation score is selected as the supervisory committee and is connected to the next epoch's leader node election.

    Figure 3. The working principle of dynamic sharding reconfiguration.

    Figure 3. The working principle of dynamic sharding reconfiguration.

5. Evaluation

We use Python to perform simulation tests on ShardEval (https://github.com/vishishtpriyadarshi/ShardEval), a sharding-based blockchain simulator. The experimental platform is an HP server with 64GB RAM, and the hardware and software environment for the experiment is shown in Table . The node performance C set in this paper has three levels as shown in Table , and different levels correspond to different work efficiency. We will first compare the features of the proposed solution with existing work, and then simulate the proposed reputation sharding scheme in experiments. The experiments will include comparative analyses of the node reputation test, the allocation result of sharding, consensus security, and system latency.

Table 1. PC configurations.

Table 2. Performance Capability of experimental node setting.

5.1. Comparison of solution features

We have presented the key metrics of the sharding scheme in Table , which compares our proposed scheme with other blockchain sharding solutions. Compared with the above schemes, our proposed sharding scheme incorporates a comprehensive reputation calculation method, and elects leaders and alternate leaders based on reputation to enhance system security. Finally, nodes are allocated based on the shard reputation value by the committee reorganisation algorithm, which reduces the possibility of malicious nodes clustering in the same shard to launch collusion attacks.

Table 3. Solution feature comparison table.

In terms of system setting, apart from Omniledger and Rapidchain, all other works combine reputation with blockchain sharding in node allocation. This effectively utilises reputation to represent heterogeneity among nodes and elect the leader node of the shard to enhance the security and performance of the system. Considering the critical role of leading nodes in the workflow, their potential security risks pose a significant threat to the system. Hence, we introduce the election of alternative leading nodes to incentivize the leader and serve as emergency substitutes. Regarding committee reconfiguration, both our proposal and Rapidchain involve partial committee reconfiguration. Rapidchain adopts the Cuckoo role and further designs a periodic partial node redistribution based on the node's age in k-regions within the committee. In contrast, our scheme leans toward using node reputation as the basis for reconfiguration and node allocation, rendering it more persuasive. By integrating node allocation methods into the dynamic sharding reconfiguration method, our solution reduces the risk of multiple low-scoring nodes clustering in the same shard to launch collusion attacks.

In terms of reputation management, our proposed scheme, in contrast to existing reputation calculation methods, comprehensively considers both the performance and behavioural characteristics of nodes. This improves the comprehensiveness and accuracy of reputation calculation, offering a more reliable node selection and trust mechanism for blockchain systems. Regarding the handling of malicious nodes, both our scheme and RDSCM propose measures for the expulsion of malicious nodes. Compared to RDSCM, which employs the local outlier factor algorithm (LOF) combined with PBFT for full voting to determine the elimination of nodes, our system significantly reduces communication overhead by involving only the regulatory committee in the voting process.

5.2. Node reputation score

The reputation of the nodes is the core element of this paper, which provides the fundamental basis for the leader election in each round of consensus and ensures the security of the consensus by eliminating the nodes with too low reputation. The main purpose of this test is to verify whether the variation of node reputation scores meets the design requirements. In the experiment, the parameters in Equation Equation(4) are assumed to be ρ = 0.6, the initial score is set to 5, the expulsion threshold of the nodes is set to 4.0, and ten rounds of node reputation score tests are conducted on 6 nodes. Nodes 3, 4, and 6 are normal working nodes with different performance levels, node 1 and node 2 are malicious nodes, and node 5 is a malicious node when it becomes a leader node. The change in the reputation of the nodes is shown in Figure . We can see that since nodes 3, 4, and 6 have different performance capabilities, there is still a different growth rate when the nodes are honest, thus avoiding the nodes with low performance to get high scores in a short time and thus be malicious. Nodes 1, 2 are both malicious nodes, which are judged as abnormal nodes by decreasing their scores to below the threshold in a short period of time, they are eliminated and their scores are reduced to 0. Node 5 operated normally in the first four rounds of consensus but exhibited malicious behaviour when it was selected as the leader node in the fifth round. Its reputation drops sharply, and it is judged as an abnormal node to expel it.

Figure 4. Reputation changes of 6 nodes over 10 epochs.

Figure 4. Reputation changes of 6 nodes over 10 epochs.

5.3. Shard allocation result

(1) Average reputation score: Compare the average reputation score of the nodes in each shard (the ratio of the total score of the nodes in the shard to the number of nodes, R(VCi)num(VCi)) and the average reputation score of all nodes (the ratio of the total score of all nodes in the system to the total number of nodes, R(V)n). The number of nodes is taken into account in the calculation because we need to be aware that the number of nodes in the shard should not vary too much to avoid the risk of a large number of malicious nodes with low scores aggregating to control the shard. The 1200 nodes are divided into 4 shards to run for 10 epochs, and the experimental results are shown in Figure . After the second epoch, the difference in scores between the shards gradually decreases. As malicious nodes are expelled, there is a general trend of increasing scores. Overall, although the final sharding results cannot reach the accuracy of the GA algorithm in TBSD, the inaccuracy is acceptable. Compared to the multiple iterations of GA, this scheme can achieve shard allocation balance more quickly.

Figure 5. Comparison of the reputation of different shards.

Figure 5. Comparison of the reputation of different shards.

(2) Standard deviation: The experiment establishes various ratios of malicious nodes and calculates the percentage Nr of the number of malicious nodes within each shard upon its completion. Subsequently, the maximum and minimum values are extracted to calculate the standard deviation. These values are then compared to the results obtained from Omniledger. Omniledger is the state-of-the-art random sharding method. The test outcomes are depicted in Figure . The percentage of malicious nodes in random sharding fluctuates up and down, and there is no obvious pattern of change. While the malicious node percentage of our algorithm shows a relatively stable trend of change. This demonstrates that our design effectively distributes the malicious nodes across different shards, resulting in a more stable outcome.

Figure 6. The standard deviation of the ratio of the number of different malicious nodes.

Figure 6. The standard deviation of the ratio of the number of different malicious nodes.

5.4. Security

This section simulates and tests our scheme with two scenarios, random sharding Omniledger and classical reputation sharding TBSD. It explores the variation in the probability of failure consensus within a shard and the ratio of collusion attacks within a shard.

(1) The probability of failure consensus: In random sharding, if the number of malicious nodes in a shard is more than 1/3 of the total number of nodes, the shard is considered unable to achieve consensus. In reputation-based sharding, if the cumulative reputation score of malicious nodes within a shard exceeds 1/3 of the total cumulative reputation score, the shard is considered to be unable to achieve consensus. The experiment sets up 4 shards with 200 nodes in each shard, and the ratio of malicious nodes grows from 0% to 50%. The threshold of node expulsion is set to 3.2 in the test of reputation-based sharding, and the newly added nodes in each round still keep the same proportion of malicious nodes set. Each malicious node count case is run through 100 simulations, and the results are shown in Figure .

Figure 7. Failure consensus probability security test.

Figure 7. Failure consensus probability security test.

The results indicate that in Omniledger, as the ratio of malicious nodes increases, the probability of a shard having more than 1/3 of malicious nodes also increases. After the ratio of malicious nodes exceeds 20%, the probability of failure consensus gradually increases, especially after exceeding 30%, the probability of failure consensus increases sharply and finally reaches the probability of 1. In the case of reputation sharding proposed in this paper, the probability of failure consensus is lower than that of the TBSD scheme in general. Even when the ratio of malicious nodes in the whole network is as high as 1/3, the probability of failure consensus still tends to be close to 0. When the ratio of malicious nodes is more than 40%, the probability of failure consensus gradually increases, but the speed is much lower than that of randomised sharding. This is because this paper comprehensively calculates the reputation scores of the nodes to divide the nodes. This strategic distribution effectively disperses malicious nodes throughout various shards, preventing their concentration in a single shard for potential attacks. Additionally, the introduction of alternate leaders for supervision enhances the honesty of leadership roles. These measures collectively contribute to a reduction in the probability of consensus failures.

(2) The ratio of collusion attacks: The ratio Nr of the number of malicious nodes in a shard reflects to some extent whether there is a malicious node aggregation problem in the shard. However, the aggregation of malicious nodes in a shard does not necessarily mean that there is a security attack problem, perhaps the arithmetic sum of multiple malicious nodes is very small, and it is difficult to control the shard to launch collusion attacks. Only when the ratio of the arithmetic power of malicious nodes in the shard exceeds 51%, there is a security risk in the shard. Therefore, the shard collusion computing power ratio Rr can be a good measure of the security of the blockchain shard model.

In the test, we analyze and find that our scheme has an overall low collusion computing power ratio. To further analyze the security of the algorithm, we compare the ratio of collusion attacks Mr under different numbers of shards with random sharding. The ratio of malicious nodes is set to be 40%, and the number of shards is set to be 4, 6, 8, 10, and 12. As shown in Figure , Omniledger consistently exhibits collusion attacks under different numbers of shards, and the highest collusion attack ratio reaches 31% when there are 6 shards. In contrast, the ratio of our scheme is much lower than that of random sharding, with the increase of the number of shards up to 12 shards, the ratio of collusion attacks is also less than 5%. Even though our scheme in node allocation didn't undergo the precise iteration of the TBSD scheme, it still achieves nearly similar effects. This demonstrates that our design in committee reconfiguration effectively disperses malicious nodes across different shards, thereby reducing the ratio of collusion attacks.

Figure 8. Collusion attack ratio security test.

Figure 8. Collusion attack ratio security test.

5.5. Performance testing

In this section, we assess the performance of the sharding scheme from two aspects: network latency and shard delay.

(1) Latency: The experimental setup included 250 nodes per shard, with varying numbers of shards from 0 to 12, as shown in Figure . As the introduction of sharding in a blockchain system increases the parallel processing capacity of the system, the latency of the system decreases as the number of shards increases. Comparing different numbers of shards, it can be seen that our methods are lower than the latency of random sharding Omniledger, especially as the number of shards increases, the advantage increases. This is because our proposed reputation sharding averages the performance level of each shard and efficiently restores the network liveness through partial redistribution to adapt to the dynamic network through sharding, all of which reduces the latency of the system.

Figure 9. Latency testing of the system.

Figure 9. Latency testing of the system.

(2) Shard latency: Shard latency is one of the crucial factors affecting the overall performance of a blockchain network. Longer shard latency can slow down transaction processing, diminishing network efficiency. In contrast to locating the nearest shard based on the hash value of a node, our solution eliminates the need to store node location information. During the partial committee reconfiguration phase, our scheme distributes nodes evenly among shards based on their reputation scores, without centralised allocation. Hence, the shard latency in our scheme mainly revolves around computing the node reputation list. Throughout the committee reconfiguration, our focus remains on new node additions and selected node extractions, resulting in relatively minimal node migration. We varied the number of nodes within shards from 50 to 250, and the experimental results are shown in Figure . We have a short shard latency with less impact on the system while improving the security of the system.

Figure 10. Shard latency of the system.

Figure 10. Shard latency of the system.

5.6. Experimental summary

The network sharding scheme proposed in this paper is based on node reputation scores for shard allocation and incorporates this node allocation algorithm into dynamic partial reorganisation. In our experiments, we can observe that nodes with different behaviours meet the design requirements in terms of reputation score changes. After considering the performance characteristics of the nodes in the calculation, there are still different growth rates even when the nodes are honest. Setting the node allocation rules in dynamic sharding reconfiguration can achieve allocation equalisation faster and thus reduce the percentage of malicious nodes in the shard. Compared to Omniledger and TBSD, our scheme greatly reduces the probability of consensus failures and collusion attacks, effectively decreasing shard system latency and improving overall system efficiency. Therefore, we can conclude that this scheme enhances the performance and security of blockchain in complex network environments compared to random sharding.

6. Conclusions and future work

In this paper, we explain in detail the differences between our proposed method and the existing methods, and we make improvements in the reputation-based sharding scheme: First, computing node reputation scores, we comprehensively consider both performance and behavioural characteristics, thereby providing a more reliable trust mechanism for blockchain shard systems. Secondly, addressing the critical issue of leader security within shards, we introduce alternative leader selection to mitigate potential leader failures or dishonest behaviour, ensuring the continuous operation of the shard and the stability of the system. Finally, we design a dynamic sharding reorganisation based on the reputation scores of nodes. In node allocation, we aim to disperse nodes with low scores to different shards, so that the overall computing power of each shard is at a smooth level, consequently reducing the likelihood of collusion attacks from concentrated malicious nodes. The evaluation shows that this sharding scheme effectively solves the security problem caused by the aggregation of malicious nodes in each shard in the existing sharding scheme, and improves the performance of the blockchain in the complex network environment.

This paper primarily focuses on the concept of network sharding. We propose that a rational allocation of nodes, coupled with the implementation of reputation management, yields improved outcomes in preventing collusion attacks. However, challenges persist in handling transactions, monitoring, and incentivizing node participation in the network. In the complex distributed environment, a secure and efficient consensus mechanism remains crucial for blockchain sharding systems. To further enhance the scalability of blockchain sharding systems, future efforts will delve into transaction sharding. We aim to establish a more equitable and efficient consensus method based on node reputation scores and develop a suitable incentive mechanism to encourage positive node behaviour.

Disclosure statement

No potential conflict of interest was reported by the author(s).

Additional information

Funding

This work was supported by the [Taishan Scholars Program #1] under Grant [number tsqn202312231]; [the National Natural Science Foundation of China #2] under Grant [number 62102209]; [the Shandong Provincial Natural Science Foundation of China #3] under Grant [number ZR2020KF035]; [the Shandong Provincial Key Research and Development Program #4] under Grant [number 2021CXGC010107 ]; and [the New 20 project of higher education of Jinan, China #5] under Grant [number 202228017].

References

  • An, J., Yang, H., Gui, X., Zhang, W., Gui, R., & Kang, J. (2019). TCNS: Node selection With privacy protection in crowdsensing based on twice consensuses of blockchain. IEEE Transactions on Network and Service Management, 16(3), 1255–1267. https://doi.org/10.1109/TNSM.2019.2920001
  • Bahri, L., & Girdzijauskas, S. (2019). Trust mends blockchains: Living up to expectations. In 2019 IEEE 39th International Conference on Distributed Computing Systems (ICDCS) (pp. 1–9). https://doi.org/10.1109/ICDCS.2019.00136.
  • Bez, M., Fornari, G., & Vardanega, T. (2019). The scalability challenge of Ethereum: An initial quantitative analysis. In Proceeding of 2019 IEEE International Conference on Service-Oriented System Engineering (pp. 167–176). https://doi.org/10.1109/SOSE.2019.00031.
  • Buterin, V. (2014). Ethereum’s white paper. https://github.com/ethereum/wiki/wiki/White-Paper.
  • Castro, M., & Liskov, B. (2002). Practical byzantine fault tolerance. ACM Transactions on Computer Systems (TOCS), 20, 398–461. https://doi.org/10.1145/571637.571640
  • Chen, J., Yao, S., Yuan, Q., He, K., Ji, S., & Du, R. (2018). Certchain: Public and efficient certificate audit based on blockchain for TLS connections. In IEEE INFOCOM 2018-IEEE Conference on Computer Communications (pp.2060–2068). https://doi.org/10.1109/INFOCOM.2018.8486344.
  • Eyal, I., Gencer, A. E., Sirer, E. G., & Van Renesse, R. (2015). Bitcoin-NG: A Scalable Blockchain Protocol. CoRR abs/1510.02037.
  • Ferrag, M., Shu, L., & Choo, K. (2021). Fighting COVID-19 and future pandemics with the Internet of things: Security and privacy perspectives. IEEE/CAA Journal of Automatica Sinica, 8(9), 1477–1499. https://doi.org/10.1109/JAS.2021.1004087
  • Hao, X., Yu, L., Zhiqiang, L., Zhen, L., & Dawu, G. (2018). Dynamic Practical Byzantine Fault Tolerance. 2018 IEEE Conference on Communications and Network Security, Beijing, China (pp. 1–8). https://doi.org/10.1109/CNS.2018.8433150.
  • Huang, C., Wang, Z., Chen, H., Hu, Q., Zhang, Q., Wang, W., & Guan, X. (2021). Repchain: A reputation-based secure, fast, and high incentive blockchain system via sharding. IEEE INTERNET OF THINGS JOURNAL, 8(6), 4291–4304. https://doi.org/10.1109/JIOT.2020.3028449
  • Huang, J., Kong, L., Chen, G., Cheng, L., Wu, K., & Liu, X. (2019). B-IoT: Blockchain driven Internet of things with credit-based consensus mechanism. In IEEE 39th International Conference on Distributed Computing Systems (ICDCS) (pp. 1348–1357). https://doi.org/10.1109/ICDCS.2019.00135.
  • Jia, D., Xin, J., Wang, Z. and Wang, G. (2021). Optimized data storage method for sharding-based blockchain. IEEE ACCESS, 9. https://doi.org/10.1109/ACCESS.2021.3077650.
  • Jiang, Y., & Lian, Z. (2019). High Performance and Scalable Byzantine Fault Tolerance. 2019 IEEE 3rd Information Technology, Networking, Electronic and Automation Control Conference (ITNEC), Chengdu, China. https://doi.org/10.1109/ITNEC.2019.8728972.
  • Kogias, E. K., Jovanovic, P., Gailly, N., Khoffi, I., Gasser, L., & Ford, B. (2016). Enhancing bitcoin security and performance with strong consistency via collective signing. In 25th USENIX Security Symposium (USENIX Security) (pp. 279–296).
  • Kokoris-Kogias, E., Jovanovic, P., Gasser, L., Gailly, N., Syta, E., & Ford, B. (2018). OmniLedger: A secure, scale-out, decentralized ledger via sharding. In 2018 IEEE Symposium on Security and Privacy (SP) (pp. 583–598). https://doi.org/10.1109/SP.2018.000-5.
  • Luu, L., Narayanan, V., Zheng, C., Baweja, K., Gilbert, S., & Saxena, P. (2016). A secure sharding protocol for open blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. (pp. 17–30). https://doi.org/10.1145/2976749.2978389.
  • Mizrahi, A., & Rottenstreich, O. (Jun. 2021). Blockchain state sharding with spaceaware representations. IEEE Transactions on Network and Service Management, 18(2), 1571–1583. https://doi.org/10.1109/TNSM.2020.3031355
  • Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. https://bitcoin.org/bitcoin.pdf.
  • Qi, X., Zhang, Z., Jin, C., & Zhou, A. (2020). BFT-Store: Storage Partition for Permissioned Blockchain via Erasure Coding. 2020 IEEE 36th International Conference on Data Engineering (ICDE), Dallas, TX, USA (pp. 1926–1929). https://doi.org/10.1109/ICDE48307.2020.00205.
  • Ray, J. (2019). Sharding introduction R&D compendium [Online]. https://github.com/ethereum/wiki/wiki/Sharding-introductionR&DCompendiuminformation.
  • Shen, T. (2022). Reputation-Driven dynamic node consensus and reliability sharding model in IoT blockchain. Algorithms, 15. https://doi.org/10.3390/a15020028
  • Tian, J., Jing, C., & Tian, J. (2023). CuckChain: A Cuckoo Rule Based Secure, High Incentive and Low Latency Blockchain System via Sharding. 2023 IEEE Symposium on Computers and Communications (ISCC), Gammarth, Tunisia (pp. 1228–1234). https://doi.org/10.1109/ISCC58397.2023.10218300.
  • Wang, J., & Wang, H. (2019). Monoxide scale out blockchain with asynchronized consensus zones. In Proceedings of the 16th Symposium on Networked Systems Design and Implementation (pp. 95–112).
  • Wang, J., Zhou, Y., Li, X., Xu, T., & Qiu, T. (2019). A Node Rating Based Sharding Scheme for Blockchain. 2019 IEEE 25th International Conference on Parallel and Distributed Systems (ICPADS), IEEE. https://doi.org/10.1109/ICPADS47876.2019.00050.
  • Yu, J., Kozhaya, D., Decouchant, J., & Verissimo, P. (2019). Repucoin: Your reputation is your power. IEEE Transactions on Computers, 68(8), 1225–1237. https://doi.org/10.1109/TC.2019.2900648
  • Yun, J., Goh, Y., & Chung, J. (2019). Trust-based shard distribution scheme for fault-tolerant shard blockchain networks. IEEE Access, 7, 135164–135175. https://doi.org/10.1109/ACCESS.2019.2942003
  • Zamani, M., Movahedi, M., & Raykova, M. (2018). RapidChain: Scaling Blockchain via Full Sharding. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (pp. 931–948). https://doi.org/10.1145/3243734.3243853.
  • Zhang, M., Eliassen, F., Taherkordi, A., Jacobsen, H., Chung, H., & Zhang, Y. (2022). Demand–response games for peer-to-peer energy trading with the hyperledger blockchain. IEEE Transactions on Systems, Man, and Cybernetics: Systems, 52(1), 19–31. https://doi.org/10.1109/TSMC.2021.3111135
  • Zhang, M., Li, J., Chen, Z., Chen, H., & Deng, X. (2023). An efficient and robust committee structure for sharding blockchain. IEEE Transactions on Cloud Computing, 11(3), 2562–2574. https://doi.org/10.1109/TCC.2022.3217856
  • Zhang, P., Guo, W., Liu, Z., Zhou, M., Huang, B., & Sedraoui, K. (2023). Optimized blockchain sharding model based on node trust and allocation. IEEE Transactions on Network and Service Management, 20(3), 2804–2816. https://doi.org/10.1109/TNSM.2022.3233570
  • Zhang, P., & Zhou, M. (2020). Security and trust in blockchains: Architecture, key technologies, and open issues. IEEE Transactions on Computational Social Systems, 7(3), 790–801. https://doi.org/10.1109/TCSS.2020.2990103
  • Zhang, X., Li, R., & Zhao, H. (2023). A parallel consensus mechanism using PBFT based on DAG-lattice structure in the internet of vehicles. IEEE Internet of Things Journal, 10(6), 5418–5433. https://doi.org/10.1109/JIOT.2022.3222217
  • Zhang, Z., Yu, G., Sun, C., Wang, X., & Wang, N. (2024). Tbdd: A New Trust-Based, Drl-Driven Framework for Blockchain Sharding in Iot. SSRN: https://ssrn.com/abstract=4665614 or XXXXX.