GT-NRSM: efficient and scalable sharding consensus mechanism for consortium blockchain

Blockchain is an innovative application of distributed storage, consensus mechanism, cryptographic algorithm, and other computer technologies. As the underlying architecture of blockchain, consensus is the key to realizing service-oriented applications of blockchain in terms of its security, efficiency, and scalability optimization. In some high-complexity consensus, such as Practical Byzantine Fault Tolerance (PBFT), throughput is severely reduced as the number of nodes increases. Even in low-complexity algorithms such as Raft, the load on the leader is severely affected as the network size increases, negatively affecting consensus efficiency. To solve these problems, we propose a node reliable shard model based on guarantee tree that achieves high scalability while maintaining a certain degree of decentralization and security based on consortium blockchain. Firstly, we create a guarantee mechanism to represent the trust relationship between nodes, and then, we design a reliable node selection strategy based on the guarantee mechanism to evaluate the node guarantee results and consensus behavior, determine the node trust status, and identify malicious nodes and choose a list of trusted leaders. Secondly, we propose a Dual-Leaders supervision mechanism, in which the deputy senses the heartbeat of leader while the deputy activity is detected by consensus nodes. Finally, we use a guarantee mechanism and reliable node selection strategy to design a network partitioning method to achieve high concurrent consensus for multiple partitions and significantly improve consensus efficiency. Subsequent experiments show that the throughput of the proposed algorithm improves by 48% over Raft and is significantly greater than PBFT, which has better throughput but lower consensus latency.


Introduction
Blockchain is a revolutionary technology that receives strategic attention from various countries [1,2].It is a traceable and growing distributed ledger database that relies on a cryptographic algorithm, consensus mechanism, and peer-to-peer (P2P) network technology to link blocks together in a chain-like structure [3].With the combination of blockchain technology with several scenarios such as finance, trade, law, and the Internet of Things, blockchain research and applications have shown an explosive growth trend and became an emerging technology with equal influence and prospect as big data, artificial intelligence, cloud computing, and autonomous driving [4].
According to different application scenarios of blockchain systems, it is generally divided into public blockchain, private blockchain, and consortium blockchain.As a decentralized and distributed system, blockchain has decision-making power dispersed among various nodes.Each node must agree upon the block data.Widely used consensus mechanisms in consortium blockchain mainly include PBFT and Raft [5].Although the consensus applied in consortium blockchain shows good performance in terms of delay, resource demand, and node complexity, since it depends on the communication between nodes, the problem of efficiently dealing with interactions of large number of nodes still needs to be solved.Among them, how to achieve a balance between decentralization, security, scalability, and trust is an indispensable consideration in designing algorithms.
It is generally believed that the most critical issue of blockchain is the trilemma of decentralization, security, and scalability [6].However, with the advent of the concept of trust, trust has become highly crucial for blockchain scalability, and there is a trade-off between trust and decentralization [7].A blockchain system with trusted nodes can bring great assurance to the system security [8].Thus, the impossibility triangle theory of distributed systems can be expanded to a quadrilateral in blockchain systems, increasing trust [9].The issue of blockchain scalability requires a deeper study.
Scalability is the main obstacle facing the implementation of blockchain applications [10].Existing approaches can be divided into off-chain and on-chain solutions to improve the scalability of blockchain systems further.Off-chain solutions are currently divided into payment channels, side chains, off-chain computing, and cross-chains [11].Off-chain can avoid the computational costs of traditional blockchain systems that require each honest node to receive, store, and send relevant data to agree among all nodes while ensuring the order of the total amount of valid data.The solution has applicability in some cases, but in many application scenarios, the solution is needed, i.e., to record, verify and save all data.Lightning network [12] and Raiden network [13] are examples of off-chain solutions.
On-chain solutions differ from off-chain solutions, where the chain handles the main chain structure by modifying some aspects.They do not introduce another chain or perform any task outside the main chain but focus on the blockchain's consensus, network, and data structure.The main on-chain solutions are block 1 3 GT-NRSM: efficient and scalable sharding consensus mechanism… data processing [14], directed acyclic graph (DAG) [15], sharding techniques [16], and concurrent solutions [17].
In a sharding blockchain system, the nodes in the network are dynamically partitioned into shards (subsets), where each shard is responsible for managing its blockchain.As new nodes join the network, the cumulative transaction throughput can grow by increasing the number of shards [18].The main idea in sharding is to split the network into small groups and process the transactions in parallel.Elastico [19], RapidChain [20], and Omniledger [21] are some examples of sharding.
One of the main problems of sharding technology is that it neglects the importance of trust in nodes participating in consensus.Sharding technology brings significant security challenges to consensus.The original solution to this technique, such as Elastico, does not consider node trust.If the trust model is not introduced, malicious network nodes will reduce the attack cost and leave the blockchain network untrustworthy.
This paper proposes an on-chain solution for consortium chains that aims to improve the scalability of traditional blockchain systems by weakening a certain degree of security and decentralization.In summary, the main contributions of this paper are as follows: • We put forward a node-guarantee mechanism that applies the idea of nodeguarantee and designs a maximum guarantee tree (MG-Tree) to visualize the trust relationship between nodes.• We propose a reliable node selection strategy based on node evaluation with guarantee mechanism, which can evaluate node behavior and calculate Trust_Value , including leader election scheme and an anomalous node deter- mination and elimination scheme.This reduces both the number of anomalous nodes and the possibility of anomalous nodes becoming the leader so that the total number of malicious nodes does not exceed the maximum number tolerable by the network.• Dual-Leaders supervision mechanism is proposed, which can quickly achieve leader's rotation when leader is abnormal and reduce the impact of leader abnormalities on the consensus process.In this mechanism, the deputy detects the heartbeat of the leader, while the deputy is detected by consensus nodes.This paper compares the dual-leaders supervision mechanism with Raft's leadership election.The experiments show that the consensus latency of the Dual-Laders supervision mechanism is improved by 9% compared to Raft.• We design a consensus partitioning model based on guarantee mechanism and reliable node selection strategy, which divides the shards according to node reliability and trust relationship between nodes, and ensures that the number of nodes between shards is approximately equal.It can effectively improve the transaction processing speed while ensuring shard's reliability.• We put forward a node reliable shard model based on guarantee tree (GT-NRSM) applied to consortium blockchain with high performance as well as high scalability, and the communication complexity of the algorithm is O(N).
• We conduct experiments in terms of throughput, node anomaly model, leader's rotation delay, horizontal and vertical of sharding, and block scalability, and compared the experimental results.
The rest of this paper is organized as follows: Section 2 reviews the research results related to blockchain consensus algorithms, trust model, and consensus partitioning techniques.Section 3 introduces the current consensus model.Section 4 describes and analyzes the proposed algorithm in detail.We evaluate the performance of our proposed algorithm in Sect. 5. Finally, we conclude the paper and discuss future work in Sect.6.

Related works
Related work areas covered by GT-NRSM: blockchain consensus mechanism, trust model, sharding technology.

Blockchain consensus algorithms
A blockchain is essentially a distributed ledger that requires consistency through interactions between nodes.All users in a distributed network can record in the ledger through consistency protocols [22].There are various kinds of consistency protocols, and consensus algorithms are an umbrella term for these consistency protocols.It is the consensus algorithm that ensures the trust and confidentiality of the generated block [23].Consensus algorithms can be broadly classified into two classes: proof class and voting class.
The most famous proof of consensus algorithm is the Proof of Work (PoW) mentioned by Satoshi Nakamoto in the Bitcoin white paper.In PoW, all users have the same bookkeeping rights.The first user to figure out the PoW problem gets the correct bookkeeping rights [24] and also receives a certain amount of bitcoins as a reward.PoW bookkeeping requires a large amount of computing power resources for value-free computations.In Proof of Stake (PoS) [25], the block producer is determined by the value of equity the user holds.The higher the value of equity, the more likely it is to become a billing node, but a few users still control the vast majority of equity resources; therefore, the rich get richer.
Unlike proof algorithms, voting algorithms do not require a lot of hashing operations or communication between nodes.Raft consensus algorithm [26] is an early distributed consistency algorithm that achieves consensus from the perspective of multi-replica state machines by managing the log replication of multi-replica state machines.However, it only considers fault tolerance for erroneous nodes and has no Byzantine fault tolerance.Wang et al. [27] propose a consensus algorithm HHRaft that improves Raft in high real-time and high adversarial environments.HHRaft is superior to the Raft algorithm in terms of consensus throughput and anti-Byzantine failure capability by introducing new monitor roles to optimize the Raft consensus process.Wang et al. [28] put forward a Byzantine-free fault-tolerant Kademlia-Raft 1 3 GT-NRSM: efficient and scalable sharding consensus mechanism… (KRaft) algorithm with high throughput and scalability.The KRaft is a consensus algorithm similar to Raft, which retains the logic of the Raft consensus algorithm part.The K-Bucket node relationship established in the Kademlia protocol is used to optimize Raft's leader election and consensus process, which improves the speed and throughput of leader election.
The PBFT consensus algorithm is first implemented in Fabric v0.6.0 [29].This consensus algorithm selects a leader from the whole network nodes responsible for creating blocks and then excludes malicious nodes from influencing the consensus after three stages of voting, but the O(N 2 ) communication complexity makes the sys- tem performance degrade as the network size increases.Gao et al. [30] provide a novel optimized practical Byzantine fault-tolerant consensus algorithm EigenTrustbased practical Byzantine fault tolerance (T-PBFT) based on the EigenTrust model, where the algorithm evaluates node trust through transactions between nodes to select high-quality nodes in the network to build consensus groups.It can optimize Byzantine fault tolerance and reduce the probability of perspective change and communication complexity.The consensus algorithm makes the blockchain very useful in many scenarios.Li et al. [31] provide an improved Raft-based consensus mechanism for PBFT.The group uses the Raft mechanism for consensus, and the leaders selected by each group use the PBFT mechanism for consensus.It is more scalable than PBFT and Raft in large-scale network environments.Table 1 compares the consensus algorithms mentioned above and analyzes the advantages and disadvantages of each consensus algorithm from different aspects.

Trust models
The trust model is systematically discussed by Marsh [32], who first formalized trust with a mathematical model and proposed a model for trust metrics regarding relevant attributes such as the content and degree of trust.Trust models can be classified into centralized and distributed trust models based on the presence or absence of thirdparty management.The EngenTrust [33] and PeerTrust [34] are two classical trust evaluation models in distributed networks for trust evaluation of distributed network nodes to avoid untrustworthy transaction objects and improve the security of transactions.EngenTrust iteratively calculates the global trust value based on the direct trust value between nodes and proposes that the recommendation behavior of nodes with high trust is biased and trustworthy; PeerTrust calculates the direct reputation of nodes based on the interaction evaluation between nodes and uses the feedback evaluation between nodes, the number of transactions, the trustworthiness of the feedback evaluation, the transaction time, the amount and the environment as calculation factors to calculate the reputation value of nodes.
Song et al. [35] provide a Multidimensional Trust index system and evaluation mechanism (MDTEM) for fintech built on blockchain to design a blockchain-based index system and evaluation mechanism for direct trust, indirect trust, recommendation trust, and feedback trust in fintech, which can effectively improve the secure application of fintech trust mechanism.Pal et al. [36] propose a blockchain-based trust management framework that allows independent trust providers to implement  GT-NRSM: efficient and scalable sharding consensus mechanism… different trust metrics on a standard set of trust evidence and provide individual trust values.They use geographic location as proof of interaction.Zhang et al. [37] propose a sharding model to optimize fault tolerance, the number of cross-sharding transactions, and sharding trust.Its application to a blockchain system can improve the trustworthiness of its shared transaction processing and reduce its transaction latency, thus enhancing the scalability of existing technologies.Lahbib et al. [38] design an IoT-based blockchain trust architecture to evaluate device trustworthiness, define trust scores for each device, and securely store and share them with other devices in the network by embedding them in blockchain transactions.It can effectively ensure system resilience against tampering and attacks, reliability, and low complexity of IoT scenarios and applications.Shala et al. [39] provide a new approach to integrate blockchain technology into the trust assessment process and presented the concept of using blockchain for decentralized machine-to-machine (M2M) application service delivery within the system.The data integrity is verified by introducing a P2P overlay combined with a blockchain network.Table 2 compares the advantages and disadvantages of different trust models.

Sharding technologies
Traditional blockchains have serious throughput issues.Originally a technique used for databases, the great advantage of sharding is that each sub-shard is parallel to the others, and different transactions are processed between the shards.Blockchain mainly includes three types of sharding: network sharding, transaction sharding, and state sharding, among which network sharding is the foundation and state sharding is the bottleneck [40].Network sharding divides the whole network into different shards by a particular organization.Each shard processes some transactions in the whole blockchain in parallel.Each part of the transaction is entirely different so multiple transactions can be verified simultaneously.Transaction sharding gives each network shard a more robust processing capability for transactions.It divides the client's cross-sharding transactions into several related sub-transactions, and the cross-sharding transactions of different shards can be processed in parallel.In order to reduce the pressure of storing the ledger in each node, state sharding stores each part of the entirely different ledger in each shard, and the whole shard network forms a complete ledger.Under the current technical conditions, both network sharding and transaction sharding have a more desirable implementation, while there are still many technical problems in implementing state sharding.
Since 2016, Luu et al. [19] propose a sharding Elastico algorithm to expand the capacity in the database, in which the node sharding technology is combined with blockchain technology, and PoW sharding with Byzantine fault tolerance (BFT) consensus is used to reduce the number of consensus users and improve the transaction processing speed.Zamani et al. [20] propose a RapidChain public blockchain sharding protocol that does not require a trusted initial setup and enables parallel transaction processing, storage, and communication, which can tolerate up to 33% of failed nodes across the network species, uses a cross-sharding communication protocol that avoids relaying transactions to the entire network nodes, and uses GT-NRSM: efficient and scalable sharding consensus mechanism… Visual_Secret_Sharing (VSS) to achieve randomness and ultimately greater throughput and scalability.Since then, blockchain sharding technology has become one of the mainstream methods of blockchain scaling.Kokoris-Kogias et al. [21] design Omniledger add committee refactoring to Elastico and propose an anti-locking solution for cross-slice transactions, which effectively solved the problems of low Elastico operational efficiency and cross-sharding transactions.Dang et al. [41] put forward attested hyper ledger (AHL), a dynamic sharding protocol tested flexibly according to Byzantine and non-Byzantine nodes.Amiri et al. [42] propose licensing blockchains that use a shard combined with a DAG-distributed ledger structure.Each shard holds a ledger, intra-chip transactions are linked separately within the chip, and related shards jointly maintain cross-chip transactions.Wang et al. [43] provide a fragmentation algorithm using the asynchronous consensus zone to spread the blockchain horizontally.Fragmentation is realized by running multiple independent and parallel instances of a single-chain consensus system in a region without affecting centralization or security.Chen et al. [44] propose an SSChain that supports transaction and state sharding, which can freely select sharding according to user requirements and algorithm allocation.Table 3 compares the performance of different sharding techniques.

The framework and models
This section provides problem statements for the algorithmic framework of GT-NRSM, network model and node model.

The system framework
As shown in Fig. 1, GT-NRSM is a state machine replication algorithm.The client distributes a transaction, and Leader generates a block and distributes it to the consensus nodes within the shard.The consensus nodes verify the block, cast a ballot, and execute a log replication request if the block is valid.Otherwise, they will discard the block.GT-NRSM aims to achieve data consistency across state machines efficiently and securely for client-side transactions.GT-NRSM consists of three parts: (1) a reliable node selection strategy, (2) a Dual-Leaders supervision mechanism, and (3) a consensus partitioning model.The reliable node selection algorithm is mainly used for malicious node identification and leader selection, the Dual-Leaders supervision mechanism is mainly used to ensure Leader availability and achieve consistent and robust data consensus within a shard, and the consensus partitioning model is mainly used to divide the consensus domain and achieve reliable and efficient high concurrent consensus.
The reliable node selection strategy achieves node evaluation by calculating Trust_Value , which is implemented based on the guarantee mechanism.The guaran- tee mechanism establishes a link between all consensus nodes and other nodes once before the consensus cycle starts, tests the link duration as the communication cost, calculates the guarantee value to other nodes based on the communication cost and RapidChain [20] No permission chain X/K

Synchronous consensus
Committee election

N
OmniLedger [21] No permission chain No permission chain GT-NRSM: efficient and scalable sharding consensus mechanism… the consensus behavior of the target node, and finally generates an MG-Tree according to the maximum guarantee principle.The Dual-Leaders supervision mechanism is to add Deputy instead of Leader in each shard.Leader is responsible for receiving client-initiated transactions, packaging the transactions, and initiating consensus requests to the consensus nodes in the shard.Deputy periodically receives heartbeats from Leader, and if there is a significant delay in the heartbeat or no heartbeat is received, deputy then directly broadcasts instead of Leader.The consensus node within the shard then initiates a new Deputy campaign request.This mechanism improves the system's reliability and ensures that consensus does not block due to Leader performance issues.
The consensus partitioning model provides a network shard partitioning method, which first delineates the list of Leaders and the number of shards by a reliable node selection algorithm, and then introduces a guarantee mechanism in which each shard is connected to a consensus node according to the maximum guarantee principle while ensuring that the number of nodes in each shard is approximately equal.This mechanism reduces the communication pressure of the system and effectively improves the consensus speed.

The network model
The system model defines the number of nodes as n ≥ 3f + 1 .The system can be guaranteed to operate correctly with no more than f malicious nodes and f down nodes.Malicious nodes are subject to interference with consensus decisions or downtime, such as not sending or sending error messages.Network communication is a reliable p2p communication network.Consensus nodes can receive messages from other nodes.Broadcast messages cause the sender to send the message to all nodes in the network, including itself.In this paper, a semi-synchronous network model is used.An upper bound is set on the message transmission time △t .It is the time interval between sending and receiving.The message is no longer processed if the communication time exceeds △t.

The node model
As shown in Fig. 1, we illustrate the relationship between the nodes by defining the architecture diagram.The node states in the traditional consensus algorithm are mainly divided into Leader and consensus nodes.In GT-NRSM designed in this paper, Monitor concept is added, and the detailed description of each definition is as follows.
Definition 1 (Consensus nodes) The replicas in the system that participate in consensus are called consensus nodes.For the node numbered i sent by Leader is defined as N i .As shown in Eq. 1, the set of all nodes involved in consensus is denoted by the symbol G.
As shown in Eq. 2, where G i denotes the consensus node ID and IP list saved by the node except itself, st i denotes the state the node itself is in, where st i ∈ (leader, deputy, consensus node), and the tasks of each node in different states will be introduced in detail in Sect. 4. h i indicates the height of the block whose node has reached the latest state.v i indicates the view number.The view will be updated when the con- sensus cycle ends and Leader pair changes.l i indicates Leader index, and the value may change only when the consensus cycle ends or when Deputy initiates a campaign.S i denotes the list of shards in which the node is located, and the consensus node only makes decisions on the transactions initiated within the shard.C i denotes the guarantee value of consensus node for other nodes and updates the guarantee value for other nodes whenever consensus node receives a guarantee request from Monitor.
Definition 2 (Leader) Leader is selected from the consensus nodes, and Leader is divided into two types of Leaders as well as Deputy, such as Leader of the shard is defined as l i_1 and Deputy is defined as l i_2 , and the set of all Leaders is represented by L. As shown in Eq. 3, Leader l i ( i = [1, n], l i ∈ L ) is maintained by Deputy and kept consistent with other nodes. (1) GT-NRSM: efficient and scalable sharding consensus mechanism… As shown in Eq. 4, where N i is the variable built-in for Leader as the consensus node, and B i is the malicious node behavior judgment made by Leader based on the final consensus result for the decision of the consensus node within the shard.SB i is the number of correct decisions made by consensus nodes within the shard in the cycle, and FB i is the number of malicious interference or wrong decisions made by the shard consensus nodes in the cycle.△t is the upper limit time for Deputy to receive heartbeats from Leader.Definition 3 (Monitor) In order to implement node evaluation and consensus sharding, the GT-NRSM algorithm introduces the concept of Monitor, which is not involved in a consensus decision, but only responsible for generating Leader_List and Shard_List , and Monitor is defined as M.
As shown in Eq. 5, where G denotes the list of IP addresses of consensus nodes, L denotes the node index of Leader, GM denotes the guarantee matrix composed of guarantee values, which is reset and updated by Monitor when requesting guarantee values from consensus nodes, B denotes the node consensus behavior, which is identified by Leader for consensus node decisions after each round of consensus in the cycle and broadcasted uniformly by Monitor, TV denotes nodes' Trust_Value , which is updated after the consensus cycle based on the guarantee tree and consensus behavior, S denotes the shard's index list where each node is located, based on which each node determines its own shard index and consensus node list within the shard.

The proposed algorithm
Existing blockchain consensus algorithms, such as PBFT, use multiple N-N broadcasts to experiment with data consistency, and this approach makes the blockchain consensus algorithm communication complexity of O(N 2 ) and up to O(N 3 ) for PBFT if view transformation occurs [45].Then, the distributed system consensus algorithm Raft, although the algorithm communication complexity is O(N), does not operate in a untrusted environment.Its Leader needs to meet the high concurrent broadcasting conditions.Leader downtime resulting in leader rotation still slows down the consensus process, which in turn affects the average efficiency of the blockchain system [46].
In order to solve the problems of insufficient security and inefficiency of the existing blockchain consensus layer, first, we propose a node guarantee mechanism to represent the trustworthy relationship between nodes.We design a reliable node selection strategy based on this to establish a node evaluation model, which can effectively evaluate nodes based on their performance and behavior.Secondly, we put forward a Dual-Leaders supervision mechanism, in which Dual-Leaders supervision mechanism each other to perform transaction distribution operations.We also propose a consensus partitioning model, which selects Leader based on a reliable node selection strategy and implements partitioning through a guarantee mechanism.Finally, we put forward a GT-NRSM secure and scalable consensus algorithm with O(N) time complexity, which can support concurrent consensus while implementing malicious node identification and screening.We can effectively solve the problem of low consensus throughput and security.

Reliable node selection strategy
Most of the traditional consensus mechanisms are implemented based on weak centralized ideas, that is, the implementation of random Leader rotation.A leader is a core role in the consensus process.Leader sends and receives transactions.Consensus nodes to verify transactions.If there are malicious nodes in the network to interfere with the consensus, there is a probability of affecting the final decision.Even in extreme cases, if the malicious node is elected Leader, the system will have a great security vulnerability, resulting in the consistency of the blockchain system failure.
The existing trust models are mainly divided into engentrust and peertrust.The direct trust model only judges whether a node is a malicious node based on its behavior, which is difficult to prevent the untrusted model with strategy; the indirect trust model is influenced by the network and subjective influence to form an objective evaluation of nodes.Therefore, this paper designs a multidimensional node evaluation system in which node trust is not only influenced by its own behavior but also influenced by other nodes in a trusted way.
First, we put forward a guarantee mechanism among nodes, where all consensus nodes will calculate the guarantee value to other nodes and finally generate an adjacency matrix containing the guarantee values of all consensus nodes to other nodes, and finally find a critical path with maximum guarantee sum in this matrix to form an MG-Tree.The guaranteed value represents the trust of nodes in other nodes.In the network, ordinary consensus nodes do not have the ability to judge whether other nodes are trustworthy.This paper stipulates that in the case that nodes do not show incorrect behavior, nodes give priority to trust nodes with similar addresses or shorter communication time, and in unstable network conditions, nodes will be down or malicious behavior in the consensus process, and then the consensus behavior is added to one of Trust_Value measurement parameters.Firstly, the communication cost is calculated as follows: As shown in Eq. 6, t is the time when consensus node initiates the link request, and the consensus node replies to Trust_Value after receiving the request from other nodes, and the time when Trust_Value is received is t i .The guarantee value is calcu- lated as follows: As shown in Eq. 7, where m i denotes the guarantee value to node i, and T S is the deadline for receiving true, i.e., consensus node is not processing link replies after T S time. is the influence factor of node consensus behavior on the guarantee.The larger the value of , the greater the influence of consensus behavior on the (6) GT-NRSM: efficient and scalable sharding consensus mechanism… guarantee value.m i decreases as t i increases.If the node does not receive the link reply message, or the received message times out again, or the node has too many wrong consensus times resulting in a negative guarantee value, the guarantee value of the node is set to 0. After that, Monitor collects the guarantee value of each node to generate the guarantee matrix as shown in Eq. 8, and the guarantee tree is generated with the guarantee matrix M as an example.
In the guarantee matrix, each row of values represents the evaluation made by the node to other nodes.For example, m ij represents the evaluation made by node i to node j.The node cannot generate the guarantee value for itself.Monitor adjusts the guarantee adjacency matrix before calling the MG-Tree generation algorithm, resetting the main diagonal element, i.e., m ii element, to 0. A reliable node selection strategy generates a collateral mechanism, and the behavior of each node affects its guaranteed node reputation value, so each consensus node will eventually guarantee only one consensus node.But each consensus node can be guaranteed by multiple consensus nodes at the same time, and it is necessary to try to ensure that the node guaranteed by each node is the node with the largest guarantee value.The MG-Tree generation process is shown in Fig. 2. The algorithm first selects the consensus node with the largest guaranteed value as the source, then establishes the graph topology sequence, links the consensus node with the largest guaranteed value for that node into the tree, and sequentially finds the node with the largest guaranteed value for the node on the guaranteed tree into the guaranteed tree.Finally, forming an MG-Tree with all nodes out of degree 1.The pseudo-code is as follows.
To avoid the appearance of mutual guarantees, MG-Tree is generated based on the maximum guarantee principle, i.e., the sum of the guarantee values of all nodes accessed is guaranteed to be the maximum instead of guaranteeing the maximum 1 3 GT-NRSM: efficient and scalable sharding consensus mechanism… guarantee value of each node accessed.i.e., each node has the possibility to guarantee a node that is not the node with the maximum guarantee value.The reliable node selection strategy determines the reliability of each node by the guarantee value made by the node before consensus and the behavior of the node in the consensus phase, which is called Trust_Value .If the guaranteed node is a consensus node and has no abnormal behavior in the consensus process, then both the guaranteed node and the guaranteed node will be rewarded with the corresponding Trust_Value ; on the contrary, if the node has abnormal behavior, then a chain effect will be formed, and the abnormal node and its children will be punished by reducing their corresponding Trust_Value .If a node behaves abnormally, a chain effect is formed, and both the abnormal node and its children will be penalized by reducing its Trust_Value .If the guaranteed node is only a normal consensus node in the consensus cycle, guaranteed nodes are rewarded with Trust_Value.
The change in Trust_Value of node A is shown in Eq. 9: where T A is Trust_Value of node A, F A is the guarantee function, G B is the influ- ence function of A's guarantee node B, and G A is the influence function of node A's own behavior on the Trust_Value during the consensus process, the model con- siders Trust_Value change from two directions: node itself and guarantee node.
For the newly joined nodes, Trust_Value will be initialized, and the nodes whose Trust_Value drops to 0 will be relegated to observer nodes, and to prevent the nodes from growing without limit, Trust_Value reward for the nodes with high Trust_Value will be reduced and the penalty will be increased.The guarantee function for Trust_Value of node is shown in Eq. 10: where P denotes the guarantee value given by node A to the previous node in the maximum guarantee spanning tree, and MAX denotes the upper limit of the guarantee value.In this formula, the larger the value of P, the larger the F A , while con- trolling the size of F A between 0.3 and 0.75 can solve the problem of reducing the usability of the model due to the implication of too large guarantee weight or too small guarantee weight.
The node A's own consensus behavior affects the function G A as shown in Eq. 11: where R A represents the normal consensus reward for consensus set nodes and P A represents the penalty function for downtime and malicious behavior of consensus set nodes during the consensus process.The node's Trust_Value reward function R A is shown in Eq. 12: (9) To ensure the balance of node's Trust_Value , the reward function needs to ensure that the normal consensus node's Trust_Value will not grow indefinitely.So the design is limited by the number of consensus cycle rounds that nodes participate in to limit Trust_Value growth, the more nodes participate in consensus conversely the lower node's Trust_Value reward.The node's Trust_Value penalty function P A is shown in Eq. 13: This function is cleared by the consensus node evil and Leader evil in two cases.If a single or a small number of consensus nodes are down or malicious behavior has a small impact on the consensus process, ARCSIN accumulates the penalty according to the number of node evils, and the higher the number of node evils, the higher penalty.If the node has continuous evil behavior, then the algorithm will increase the penalty according to the number of continuous evil behaviors.In order to control the balance of node Trust_Value , the algorithm will penalize the node according to the percentage of existing Trust_Value , so the higher Trust_Value of the node, the more Trust_Value will be deducted when it does evil, and if all the consensus behaviors of the node in the consensus cycle show abnormal behaviors, then Trust_Value will be cleared to 0.
The case of Leader failure has a greater impact on the consensus process because the view conversion slows down the consensus efficiency.So the penalty is larger for Leader to do evil, and the Monitor increases the penalty exponentially as the number of consensus increases.
In the consensus of a transaction, the more times a node is guaranteed, the more its trust value floats, and the guarantee result will affect both guaranteeing parties.The guarantee mechanism enables consensus nodes to achieve dynamic changes in trust value through the act of guaranteeing.Nodes with high trust value and communication efficiency in the blockchain network are more likely to be guaranteed by other nodes, and their trust value will rise at a higher rate accordingly, but they will also be punished at a higher rate if they engage in malicious behavior.Nodes with bad behavior and the MG-Tree are unpredictable, i.e., consensus nodes cannot know which node they will eventually guarantee, and even if a consensus node obtains the guarantee values of multiple nodes, it cannot recover the complete guarantee tree.
The reliable node selection strategy is based on the principle of high penalty and low reward, and the cost of node failure or evil is high.In the design of the node evaluation algorithm, in order to prevent misjudgment that normal nodes are wrongly identified as malicious nodes, only nodes with frequent abnormalities in a single consensus cycle will be denoted due to Trust_Value clearing 0. As long as the node's Trust_Value is not clear 0, it still has the right to participate in the guarantee and consensus as a consensus node. (13) GT-NRSM: efficient and scalable sharding consensus mechanism…

Dual-leaders supervision mechanism
Leader plays a core role in consensus, responsible for sending and receiving transactions and determining the consensus behavior of nodes in a shard.Suppose the leader has malicious behaviors or goes down.In that case, it may cause the consensus system to crash or content to be maliciously tampered with, and leader rotation may seriously affect the consensus algorithm process.Na et al. [47] propose a Dual-Primary-Node-Derived Practical Byzantine Fault Tolerance (DPNPBFT), in which two primary nodes are selected to reach consensus simultaneously to achieve power decentralization and improve consensus efficiency.However, node verification is only carried out between primary nodes, so preventing the joint evil of primary nodes is difficult.Li et al. [5] design a Scalable Hierarchical Byzantine Fault Tolerance (SHBFT) structure and set a three-level primary node dependency structure to reduce the algorithm consensus delay.However, it will reduce the cost of malicious node attacks.
In order to improve the fault-tolerant ability of consensus, a reliable and efficient Dual-Leaders supervision mechanism is proposed.As shown in Fig. 3, Deputy supervises the activity of Leader, identifies the Leader's malicious behavior, reduces Leader rotation time consumption, and at the same time, the consensus node will supervise its behavior to improve the operating efficiency of the consensus algorithm effectively.The following introduces the supervision and rotation process of Dual-Leaders supervision mechanism.
After the consensus node with index value ID k receives Trust_Value list S L from Monitor, it first updates Trust_value list S L_j of the shard nodes and sorts them and the two nodes with the highest Trust_Value broadcast the node campaign request VoteReq = <State, ID k , LastLog k , term k , S v k > in the shard, where the state is a binary value, with Leader and Deputy representing the primary node campaign type, indexed by ID k after receiving VoteReq, the message is first verified as follows.
The validation process is shown in Eq. 14.If the validation does not pass, it returns a False signal against the vote.If it passes, it returns a True signal.If the node receives the same type of request initiated by multiple nodes simultaneously after each campaign node has passed the validation, it compares the node's Trust_Value .It returns the True signal for the node with the maximum Trust_Value , while the other nodes return the False signal.If the campaign node receives more than 1/3 affirmative votes, it initiates a Leader campaign success notification to the consensus nodes within the shard and Monitor.When the consensus node receives the notification inside the shard, it modifies the local Leader index.It returns True_Value to Leader to indicate that it has accepted that the other party is Leader.After Monitor ( 14) receives 2 * Shard_Num Leader's campaign success notifications, it returns the cli- ent Leader_List.
In the consensus process, the current view needs to decide by consensus whether the message m is up or not.Leader broadcasts <Commit, m, v, n, i> to the nodes in the shard and sends <Proof , LastLog, ID, d, m> for Commit verification to Deputy, d is the digest of the message m.Deputy verified that no digest d of the same message m had been received and that LastLog is correct.Leader's behavior is considered evil if the verification does not pass.
In addition, Deputy within the shard will receive the heartbeat of the sending and receiving transaction leader periodically and broadcast the heartbeat to the consensus nodes within the shard periodically.If Deputy does not receive the heartbeat of the Leader within t time, it will determine that Leader is down.
If Deputy determines that the Leader is abnormal, it will record its abnormal behavior and broadcast the message <Notification, LastLog, ID, ErrorType, e> of the elected Leader to Monitor, client and nodes in the shard, where ErrorType is the previous Leader error type and e is the specific error content.It is sent to each node in the shard for verification.If the consensus nodes do not receive the heartbeat request from Deputy within t time, then Broadcast the node VoteReq within the shard, if it receives more than f + 1 node consensus requests, it broadcasts the notification of elected Deputy, after the consensus node receives the notification, it modifies the index of local Deputy and returns True signal.
When the consensus cycle starts, the node with the highest trust value is first selected as Leader and Deputy to initiate the election through the node election strategy.We analyze three cases when nodes rotate: (1) Leader is down or doing evil, Deputy is normal.At this time, Deputy will confirm Leader's abnormal behavior in heartbeat detection or consensus verification link and send Notification directly to nodes, Monitor, and client within the shard.The consensus node that receives the message first initiates the campaign for Deputy's VoteReq.Leader does not need consensus nodes to vote for the campaign after the malicious behavior is detected; Deputy is directly elected.(2) Normal Leader consensus, Deputy down or evil.At this time, the first node to detect deputy heartbeat stopped, or verification results wrong node will launch the campaign Deputy VoteReq.Since the leader works normally, it will not affect the consensus process.(3) Leader and Deputy are down or evil at the same time.Firstly, the node that detects that Deputy's heartbeat is stopped or GT-NRSM: efficient and scalable sharding consensus mechanism… the verification result is wrong initiates the campaign for Deputy's VoteReq.When a node is successfully elected as Deputy, then it will supervise the behavior of Leader.When Leader's abnormal behavior is detected, it will be replaced by Deputy.Finally, the node that receives Notification first initiates the VoteReq to run for Deputy.
The Dual-Leaders supervision mechanism reduces the complexity of the Leader behavior supervision process to O(N).Deputy as the supervisor can be replaced the first time after detecting Leader's abnormal behavior to avoid losses.In addition, the reliable node selection strategy ensures the unpredictable property of Leader and Deputy, so it is difficult for adversaries to realize the joint evil of Leader and Deputy.

Consensus partitioning model
To solve the problem of the general low scalability of consensus, we put forward a consensus partitioning model based on a guarantee mechanism and dynamic weights.The shard idea is one of the most effective means to enhance the consensus algorithm.The throughput is limited by network bandwidth and communication delay.When the blockchain adds new blocks, the last block must have a specific synchronization rate in the whole network.In transaction verification and execution, Leader must perform state machine replication with every consensus node in the whole network, and each consensus node must store the state associated with every account and every decentralized application (DAPP) in the whole network in memory for access during transaction validation.The "Impossible Triangle" theory of blockchain suggests that scaling horizontally is the most effective way to obtain a design paradigm with high capacity and a high throughput rate.Figure 4 illustrates the network partitioning model designed in this paper.Therefore, this paper proposes a consensus partitioning mode based on node guarantees and dynamic weights.The algorithm follows the principle of maximum credible guarantee within the shard while ensuring a balanced number of nodes.The algorithm selects the node with the highest Trust_Value according to the number of shards by the reliable node selection algorithm and puts it into the shard as the initial node, and then invokes the guarantee mechanism to build a tree topology by linking the guarantee values in each shard.
First, we designed the second guarantee mechanism, pseudo-code, as shown in the figure, assuming that the number of consensus nodes in the network is N and the number of shards is N_S , as shown in the figure to M matrix example in the network in the condition of the provision of two shards sub-tree generation process.After Monitor updates Trust_Value , N_S nodes are selected in descending order and put in each shard, respectively.Finally, in this matrix, assuming the number of nodes is N and the number of shards is N_S , Monitor updates Trust_Value and selects 2 * N_S nodes in descending order and puts them in each shard, respectively.Establish the graph topology sequence in the guaranteed value adjacency matrix generated by the consensus node with N_S nodes with the highest Trust_Value as the tree's root.We link the consensus node with the most giant guaranteed subtree root to the corresponding sub-tree and sequentially find the node with the largest guaranteed value for nodes on all subtrees to link to the tree.The number of nodes in each shard shall not exceed (N∕N_S) + 1 .If the number of nodes exceeds this value, the shard is complete, and no more node access is received.They are finally forming a maximum guaranteed directed tree with all nodes except the root node with degree 1.As shown in Fig. 5, the M matrix is used as an example to specify the generation process when the number of shards is 2.

GT-NRSM secure and scalable consensus algorithm
The algorithm applies a reliable node selection strategy, Dual-Leaders supervision mechanism, and consensus partitioning model, which solves the problem of unreliable consensus nodes and inefficient consensus, and the algorithm's time complexity is O(N).It supports node activity detection as well as node fault tolerance.First, we describe the execution logic of each node and then analyze the algorithm's security, activity, and complexity.The flowchart of the algorithm is shown in Fig. 6.The algorithm includes four phases, Request, Feedback, Commit, and Reply, where Request As shown in Fig. 7, the detailed steps for each stage are as follows: • Request phase: we assume that the current state consensus cycle is R i ; in this phase, first the client sends Request 1 <LeaderReq = True> to Monitor to request for Leader_List , Monitor receives the signal and starts to call the node based on the obtained consensus behavior state and the guarantee tree generated by the R i−1 Fig. 4 Consensus partitioning model Fig. 5 The process of shard based on the guarantee mechanism cycle The selection policy updates the node Trust_Value , selects Leader_List of R i cycle and malicious nodes based on updated Trust_Value , stores the list in the cache and initiates the request for guarantee value generation broadcast Request 2 <ID m , R i , B i , M i , GuaranteeReq = True> , sets the timeout time T r , and to reduce the communication consumption, we compressed the communication flow by broadcasting Leader_List as well as the malicious node broadcast simultaneously with the guarantee request.• Feedback phase: After receiving Request 2 message, node N j verifies and pro- cesses the message in three steps, (1) determine whether ID m is correct and whether R i is greater than the latest consensus cycle R j that the node is in, if ID m is less than the locally saved ID j m then return an error processing request Feedback 1 <GuaranteeRespond = False, ErrorID, ErrorT i > eliminate malicious nodes and update the local consensus node list according to the malicious node index provided by Monitor, (2) establish a link with each node by transmitting the true signal, test the link length as the communication cost, and generate a consensus value of the node based on the communication cost and the consensus behavior of the node to other nodes guarantee value, (3) return Monitor ID j and guarantee value list Feedback 1 <GuaranteeRespond = False, ID j , Gu j i > .After receiving Feedback 1 message from ID j , Monitor deposits the guarantee value into the guarantee matrix Gu i in the cache pool according to the node index, and after reaching T r time, Moni- tor stops receiving Feedback 1 message, does the guarantee tree generation algorithm on the guarantee matrix, puts the guarantee tree into the cache, and is called before R i+1 starts.Call shard algorithm to generate the final Shard_List by Leader_List and the guarantee matrix, and broadcast the shard ShardReq<ID m , S L , T V > to the con- sensus node list concurrently, after the consensus node receives the ShardReq, it will update its own shard listS_L j and the shard's node Trust_Value list T_V j , and return the client Leader_List : Feedback 2 <ID m , Le i > .After the consensus node receives Shard_List , it updates its own Shard_List and modifies Leader index.
• Commit and Reply phase: After receiving Feedback 2 , the client takes the transac- tion from the transaction pool, sorts the transaction and starts to concurrently distribute the transaction to the incoming and outgoing transaction nodes in the shard, Leader receives the transaction set, parses the transaction and generates the block, sends the transaction to the consensus nodes in the shard.Reply stage, after receiving the transaction, the node verifies the transaction, if the block passes, it returns True, if the verification fails, it returns False, if Leader receives more than f + 1 passed votes, it means the block is legal, if it receives no more than f + 1 passed votes or no more than f + 1 failed votes, it means the block is not legal and discards the block.After Leader makes the final decision, it counts the consensus node votes, records the consensus node downtime in the shard and whether it is inconsistent with the final decision, sends the node consensus behavior to Monitor, which records it and finally returns the decision to the client.After receiving the return message from all Leaders, the client determines whether the consensus count reaches the upper limit of consensus cycle, if not, it continues to repeat the above steps, and if it reaches the upper limit, it requests a new round of Leader_List from Monitor.

Experimental platform and experimental environment
This section analyzes GT-NRSM from four aspects: throughput comparison, malicious node identification, leader rotation delay, and shard experiment.The specific go language is used to build, Google Remote Procedure Call (GRPC) implements the remote call, MySQL implements the data persistence, and the block generation interval and the node sending heartbeat time are reasonable values.

TPS comparative analysis
Transaction throughput is an important performance metric for distributed systems.The throughput of a system is usually determined by the number of concurrent transactions and the number of transactions per second (TPS), as shown in Eq. 15.We use it to test and compare the performance of several algorithms.
Tran − len is the number of transactions contained in a block.As shown in Eq. 16, 1T is the generation time of a block, and the GT-NRSM protocol requires Trust_Value updates and partitioning outside the consensus cycle, so the communication consumption outside the consensus cycle is calculated in the consensus TPS in the experiment.
Due to the different consensus algorithms, the intervals between blocks are also different.To ensure the experiment's accuracy and the system's stability, we specify consensus on 100 blocks * 1000 simulated transaction data.After the test, the transaction time is calculated uniformly.We experimented by fixing the amount of data and changing the number of nodes, and the experimental results are shown in Fig. 8.The experimental results show that both GT-NRSM and Raft have high throughput for the same data volume and the different number of nodes, and GT-NRSM improves 48% over Raft in terms of throughput and is much higher than PBFT due to the concurrent consensus of sharding.

Malicious node identification analysis
In this paper, the reliability of nodes is ensured by the reliable node election strategy in the GT-NRSM protocol, which determines whether a node is a malicious node based on its cumulative malicious consensus count.When the reliability of a node is lower than the threshold value, the node is judged to be a malicious node, and all consensus nodes remove the node ID from the list of node IDs in the local cache.
In the node reliability experiment, 10 nodes are deployed for Trust_Value testing.We set the consensus cycle to 10, and ten consensuses are performed in each cycle.We modeled node 1 as a continuous evil node, and it makes an entirely different judgment from the normal node in each consensus.Node 8 are discontinuous evil nodes, i.e., they will make wrong behaviors at uncertain times.The result of the generation of the MG-Tree is shown in Fig. 9.The node Trust_Value changes as shown in Fig. 10.
The figure shows that the Trust_Values of normal nodes' difference is insignificant.Among them, node 1 performs malicious behavior in the whole consensus cycle, and the Trust_Value drops to 0 after the last consensus of the cycle, which will be judged as an abnormal node by the system and removed from the network.Node 8 exhibits GT-NRSM: efficient and scalable sharding consensus mechanism… malicious behavior in the 2nd, 5th, and 9th consensus.Its Trust_Value is significantly different from that of normal nodes.The malicious consensus in the 9th decreases at a significantly higher rate than the malicious consensus in the 2nd because the penalty cost of the node increases accordingly with the number of malicious acts.Nodes 2 and 4 guaranteed malicious node 8 and received penalties proportional to the guaranteed value in rounds 2, 5, and 9, respectively.In general, this reliable node selection strategy can satisfy the requirements of malicious node identification and sharding division.

Leader rotation latency comparison analysis
In the Raft consensus protocol, if the consensus node does not receive the heartbeat of the incoming autonomous node, it will determine that it has failed and adjust its identity status to that of a candidate and initiate a leader election request.GT-NRSM protocol applies a dual-leaders supervision mechanism to reduce the communication consumption of leader election.If the supervisor detects the leader, the heartbeat of the supervisor node is detected by the consensus node.If the supervisor node detects Leader, the heartbeat of the supervisor node is detected by the consensus node.Since the time required for leader rotation is extremely short, we put the leader rotation algorithm of Raft's algorithm and the leader rotation algorithm of GT-NRSM in this paper into the same sample to achieve an accurate comparison.We test both algorithms for 20 groups to calculate their time delays, and the experimental results are shown in Fig. 11, where the horizontal coordinates represent the number of rounds and the vertical coordinates represent the time delays.The experimental results show that the dual-leaders supervision mechanism of GT-NRSM outperforms the Raft algorithm regarding running time.GT-NRSM can achieve the principal node turnover in a shorter time after the downtime of Leader and reduce the impact on the consensus process.

Comparative analysis of the effect of shard
Transactions in the fast confirmation network are collected by slicing as transaction blocks.Compared to the long wait time required to confirm a Bitcoin transaction block, the shard can also reach a consensus on the transaction block and add it to the blockchain in a shorter period.As a result, the transactions contained in the transaction block are also confirmed.Both vertical scalability and horizontal scalability [48] are key metrics to consider in the performance of sharding.Vertical scalability is the change of consensus throughput with the same number of shards and the different number of nodes, and horizontal scalability is the change of consensus throughput with the same number of nodes and the different number of sharding.

Vertical scalability analysis
The common problem of current mainstream consensus algorithms is that the consensus process requires many node communications.The GT-NRSM algorithm reduces the number of consensus node communications in a consensus process, but inter-node communications consume many resources.To test the impact of the number of nodes on the performance of the blockchain system, we test TPS variation of the number of consistent nodes within a shard with different block sizes with an endless number of shards, as shown in Fig. 12, where the horizontal coordinates indicate  GT-NRSM: efficient and scalable sharding consensus mechanism… the number of rounds and the vertical coordinates indicate the TPS.It can be found that with a fixed number of shards, the TPS of GT-NRSM is lower as the number of nodes increases, which is because, in GT-NRSM, each additional node increases the thread communication of Leader sending log preparation requests and collecting voting information.So the higher the number of nodes in the shard, the longer the time to maintain inter-node consistency, the higher the communication consumption with Leader, and the longer the time required in the consensus process.

Horizontal scalability analysis
In this paper, GT-NRSM improves the performance of blockchain systems by dividing consistent resources.To test the horizontal scalability of GT-NRSM, we test the relationship between the number of shards and TPS for different numbers of nodes when the block size is 1000.As shown in Fig. 13, the horizontal coordinates indicate the number of rounds, and the vertical coordinates indicate the TPS.It can be found that the consensus speed of GT-NRSM increases as the number of shards increases while TPS increases.However, the increase becomes slower and slower, and TPS tends to be stable.This is because while keeping the number of nodes within a shard constant, each additional shard adds a concurrent consensus process to process the data, thus increasing the consensus speed of the blockchain system in the consensus phase.As the number of shards increases, the time required to Monitor to receive consensus behavior, execute the sharding algorithm, etc., also increases.So the growth of TPS becomes smaller and smaller until it is flat.Therefore, with the constant amount of consensus data, the overall consensus time cost decreases as the

Block scalability analysis
In the GT-NRSM protocol, the number of data entries in a block can be configured according to business needs in order to optimize the efficiency of the blockchain system.In order to study the impact of block size on the processing speed of the blockchain system, the scalability of blocks was tested and analyzed.Specifically, we test the processing speed of different transaction volumes in a block under different conditions.Twenty rounds of testing were conducted for each block size under different conditions.TPS was averaged, and the value of the error bar is the standard deviation value of the throughput of the 20 blocks, as shown in Fig. 14.The horizontal coordinates indicate the different numbers of nodes and shards, and the vertical coordinates indicate TPS.

Conclusion and future work
The scalability issue of the consensus mechanism is currently the main obstacle to implementing coalition chain applications.In this study, we propose the GT-NRSM to solve the current problems of low blockchain scalability, poor node reliability, and balanced quadrilateral.GT-NRSM is a consensus protocol for reliability evaluation and consensus network sharding applied to coalition chains.Firstly, we introduce the concept of guarantee and build the node evaluation model and network shard model based on the guarantee mechanism to ensure the shard's reliability while achieving the blockchain's expansion.Secondly, we propose a Dual-Leaders supervision mechanism to effectively reduce the rotation delay caused by Leader downtime and reduce the impact of Leader downtime on the consensus process.The experimental results show that GT-NRSM has higher fault tolerance, faster consensus efficiency, greater system throughput, and better scalability and has obvious advantages over the applied consensus algorithms.GT-NRSM cannot effectively identify many types of network adversary attacks.Therefore, in future research, we plan to investigate further how to study the sharing model using artificial intelligence techniques to deepen the network sharding scheme.In addition, an optimized scheme will be designed to determine the

Fig. 2
Fig. 2 Example of MG-Tree generation process with M matrix

Fig. 3
Fig. 3 Leader rotation process in the Dual-Leaders supervision mechanism

1 3 GT
-NRSM: efficient and scalable sharding consensus mechanism… and Feedback are executed before the consensus cycle starts, and Commit and Reply will be executed cyclically in the cycle.Monitor, Leader, and consensus nodes in the figure can represent different roles of nodes.

Fig. 8
Fig. 8 Comparison of the average TPS of different consensus algorithms

Fig. 11
Fig. 11 Comparison of leader rotation delay for different consensus algorithms

Table 1
Performance comparison of different consensus algorithms

Table 2
Comparison of the advantages and disadvantages of different trust models

Table 3
Performance comparison of different sharding technology