Abstract
Blockchain is characterized by privacy, traceability, and security features as a novel framework of distributed ledger technologies. Blockchain technology enables stakeholders to conduct trusted data sharing and exchange without a trusted centralized institution. These features make blockchain applications attractive to enhance trustworthiness in very different contexts. Due to unique design concepts and outstanding performance, blockchain has become a popular research topic in industry and academia in recent years. Every participant is anonymous in a permissionless blockchain represented by cryptocurrency applications such as Bitcoin. In this situation, some special incentive mechanisms are applied to the permissionless blockchain, such as “mined” native cryptocurrency to solve the trust issues of the permissionless blockchain. In many use cases, permissionless blockchain has bottlenecks in transaction throughput performance, which restricts further application in the real world. A permissioned blockchain can reach a consensus among a group of entities that do not establish an entire trust relationship. Unlike permissionless blockchains, the participants must be identified in permissioned blockchains. By relying on the traditional crash fault-tolerant consensus protocols, permissioned blockchains can achieve high transaction throughput and low latency without sacrificing security. However, how to balance the security and consensus efficiency is still the issue that needs to be solved urgently in permissioned blockchains. As the core module of blockchain technology, the consensus algorithm plays a vital role in the performance of the blockchain system. Thus, this paper proposes a new consensus algorithm for permissioned blockchain, the Risk Assessment-based Consensus (RAC) protocol, combined with the decentralized design concept and the risk-node assessment mechanism to address the unbalance issues of performance in speed, scalability, and security.
1. Introduction
Bitcoin is a type of digital money that has taken the world by storm. A scholar first proposed Bitcoin in 2008 under the pseudonym of Satoshi Nakamoto, and then the Bitcoin system was released on the Internet [1]. There are no centralization management servers and third-party credit endorsement organizations. Bitcoin has been operating stably for more than ten years. These characteristics demonstrate the potential advantage of the blockchain technology behind the Bitcoin system. Blockchain is a decentralized distributed ledger that generates and stores data in blocks and constructs a chain structure in chronological order. The security and immutability of blockchain are grounded in cryptography, smart contract, P2P network, and consensus protocol [2]. Blockchain has brought hope to solve the issues such as privacy, security, and trustworthiness in distributed ledger technologies [3]. In recent years, more and more researchers have applied blockchain to other scenarios, such as supply chain [4], information security [5], data security [6], and Internet of things [7]. With the development of blockchain technology, a new business model is emerging based on blockchain to help a group of entities eliminate the dependence on centralization certification organizations [8]. It is foreseeable that blockchain will gradually become an indispensable part of the future Internet.
There is no central organization to undertake the data verification work. Every stakeholder must record the same correct data because a peer-to-peer architecture was used in the decentralized distributed system like blockchain. However, it is difficult to maintain the same content and sequence of transactions in all the participants due to the different status of the participants and the network environment in which they are located [9]. In addition, some participants may be attacked as Byzantine nodes to obstruct transmission. Therefore, blockchain technology also brings new problems to the system. The solution to these problems relies heavily on the consensus algorithm because the consensus algorithm plays a vital role in the performance of the blockchain system [10].
For example, permissionless blockchain such as Bitcoin employs the methods that “mined” the cryptocurrency using their computing powers to mitigate the absence of trust. PoW (Proof-of-Work) [1], PoS (Proof of Stake) [11], and DPoS (Delegated Proof of Stake) [12] are classified as permissionless blockchain consensus protocols. However, PoW has limitations in computing power consumption and small throughput. In addition, the PoW consensus may suffer the tailored attack behavior such as 51% attacks [13]. Although the PoS and DPoS solve the waste of resources in PoW, there are still problems such as low efficiency [14]. Permissioned blockchain is more suitable for high real-time applications due to its high transaction throughput performance and low transaction confirmation latency [15]. Permissioned blockchain can use classic consensus algorithms, such as Raft [16] and PBFT [17], to reach the consensus among entities because all participants must be identified. PBFT has not been widely used in real-world projects due to high consensus cost and poor scalability in many use cases. The raft can only be used in non-Byzantine environments with only honest network nodes [18]. The above examples all show that the many consensus algorithms unable to meet the Quality of Service (QoS) demands of specific scenarios are an important reason that hinders the broad application.
Therefore, to meet the requirements of high scalability and security as much as possible under the premise of decentralization performance, a new consensus algorithm for Permissioned blockchain put forward in this article is appropriable, called RAC (Risk Assessment-based Consensus protocol). The main contributions of our work are as follows. (1)There is no centralized endorsement organization in the blockchain system. The participant with strong computing power or high-stake rights is often the accountant node that packs transactions into a block and sends the block to other participants, weakening the blockchain system’s decentralized characteristics. We have designed a new decentralized consensus model to avoid monopolistic behavior caused by excessive concentration of authority. In our model, achieving consensus relies on cooperation between all roles. At the same time, different roles can achieve conversion under certain conditions(2)It will immeasurably impact the blockchain system when the accountant node is maliciously controlled. We have designed an efficient accountant node election strategy to ensure that only honest participants can act as the accountant to generate new blocks, combined with the risk-node assessment mechanism to identify the malicious nodes that may exist in the network(3)The distributed connectivity of the blockchain exposes the systems to Byzantine attacks. The compromised participants will further decrease the trust level among cooperative organizations by generating false data to obstruct consensus. We have designed an efficient block addition and transaction confirmation strategy to prevent possible Byzantine behavior and collusion attacks in the network. The process achieves a credible consensus by combining the reward and punishment mechanism and addressing the unbalance performance issues in speed, scalability, and security in the consensus algorithm proposed
The remainder of this article is organized as follows. Chapter 2 reviews the research related to the blockchain consensus algorithm. Chapter 3 introduces the basic definition and system model of the RAC algorithm. Chapter 4 describes the detailed implementation process of the RAC algorithm. Chapter 5 demonstrates the performance of the RAC algorithm through theoretical analysis and experiments. Chapter 6 summarizes the research work and provides an outlook for future work.
2. Related Work
There have been several works on blockchain and consensus algorithms in recent years, and some previous studies have motivated our work on the consensus model. In this section, we present a brief literature review from three aspects.
2.1. Overview of Blockchain
A blockchain is a tamper-evident ledger supported by a consensus algorithm. Peer to Peer (P2P) networks, cryptographic hash, digital signatures, and smart contracts are core blockchain technologies. Every node in the blockchain maintains a copy of the ledger verified by a consensus protocol, as shown in Figure 1. The ledger exists in blocks, each linked to the previous block by a hash [19] . Since each node in a P2P network has equal status, there is no need for a central server to exchange information in the blockchain system [20]
2.1.1. Blockchain Transaction Process
As shown in Figure 2, the transaction process of any blockchain system can be classified into three stages: accountant selection, block addition, and transaction confirmation [14].
Accountant selection is the first stage of the transaction process. Accountant nodes are responsible for collecting and generating blocks from the client then packaging transactions into blocks and sending blocks to other nodes in the blockchain network. Accountant nodes can be caused by competing (e.g., PoW, PoS), polling (e.g., PBFT), or voting (e.g., Raft) approaches.
Block addition is the second stage of the transaction process. Since each node maintains a copied ledger locally, a node adds the block into the local ledger after the block verification is passed. In a few consensus algorithms, such as PBFT, block addition requires a majority vote of the nodes. Therefore, these consensus algorithms generally suffer from a lack of scalability and high consensus cost.
Transaction confirmation is the third stage of the transaction process. The purpose of transaction confirmation is to confirm the transaction’s validity based on the blockchain held by each node in the blockchain network. However, most consensus algorithms do not require real-time voting by the nodes during the block addition phase. Hence, the confirmation efficiency relies on the consensus algorithm’s characteristics used in the blockchain system. For example, confirming a transaction in the Raft algorithm requires that more than 50% of the nodes complete the block addition.
2.1.2. Types of Blockchains
Blockchain can be divided into permissionless and permissioned [21]. Bitcoin, Ethereum, and other cryptocurrencies issued to the public have been divided into permissionless blockchains. Any anonymous individual can freely join and maintain the blockchain network. There is no trust until the blockchain state reaches an immutable block depth. The measures of “mining” to provide financial incentives were used to compensate for the trust issues and offset Byzantine fault tolerance costs. So, the permissionless blockchain has weak concurrent transaction capability, high transaction fees, and a long confirmation time. In addition, participants in the permissionless blockchain are impossible to be identified.
However, some requirements must be considered in many cases, such as transaction throughput performance, transaction confirmation latency, the confidentiality of transactions, and participant identity [22]. These characteristics are the performance requirement of use cases and regulations that must be followed. Know-Your-Customer (KYC) is one of the essential principles in an actual financial transaction, which cannot be achieved in a permissionless blockchain.
Permissioned blockchains, on the other hand, provide a way to achieve the interactions between entities that do not establish an entire trust relationship. Since the participants’ identities are known, permissioned blockchains can use a more efficient consensus algorithm to drive smart contracts, such as crash fault-tolerant (CFT) or Byzantine fault-tolerant (BFT) protocols. As a result, permissioned blockchain has lower transaction costs and higher efficiency than permissionless blockchain, which uses an “incentive mechanism” to reach a consensus.
Table 1compares permissionless blockchains and permissioned blockchains in terms of various parameters. To sum up, transactions are executed on every node in the permissionless blockchain network, which can be problematic for many use cases, such as supply chain, and the securities industry, because none of the partners would want their competitors to know confidentiality information in these businesses. On the contrary, permissioned blockchain systems have adopted various approaches to address the lack of privacy and further improve efficiency. These characteristics make permissioned blockchain acceptable in many enterprises’ use cases.
2.1.3. The Challenge in Blockchain-Based Applications
Permissionless blockchains are more suitable for cryptocurrency applications in open and anonymous environments. The number of users in such a case is enormous. On the other side of the coin, permissioned blockchains are more suitable for cooperation between a certain scale of organizations without a centralized authority party. All stakeholders of permissioned blockchain must be identified and identifiable.
Although blockchain has been applied in many aspects, including in the area of IoT, smart city, supply chain, vehicular ad-hoc networks, and so on, it is still a technology that is under development, which means there are some obstacles exist in blockchain-based applications that need to be improved [19]. From what has been analyzed in some previous work, the contradiction between decentralization, security, and scalability is the main reason that restricts the development of blockchain-based applications.
The three properties, consistency, availability, and partition tolerance, can only satisfy most two simultaneously in a distributed system, which was named the “CAP theorem” and proved in 2002 by Seth Gilbert and Nancy Lynch [23]. CAP provides a guiding principle for the design of consensus algorithms. From this, researchers no longer pursue that can satisfy all three properties simultaneously. Based on the CAP theorem, Vitalik Buterin proposed the DSS conjecture in the Ethereum system: the blockchain system cannot be enhanced in terms of decentralization, security, and scalability at the same time [24]. From the DSS conjecture, we can conclude that the transaction throughput of permissioned blockchains where total decentralization is not provided is much higher than permissionless blockchains. For example, a decentralized bitcoin system is much smaller than Hyperledger Fabric with partial decentralization in throughput performance.
Decentralization means that the accountant node is fairly generated throughout all nodes in the blockchain network rather than being centralized by a small number of users. The degree of decentralization and the control of the blockchain network are closely related. It is essential to ensure the fair participation of users.
Security means the main security issues and corresponding protection mechanisms in blockchain systems, including cryptographic security, network security, data security, and consensus algorithm security. These include Collusion, Double Spending, Sybil, and Targeted attack.
Scalability refers to the ability of the blockchain system to process the transaction. Three main aspects influence the performance of scalability. First, network latency of the distributed system; the network latency of a distributed system is more limited than that of a traditional distributed system due to an uncontrollable network environment. Second, the consistency of all users in blockchain requires necessary confirmation computation to maintain the consistency among nodes, resulting in additional computational cost. Third, constraints in computational performance of blockchain nodes, especially in IoT applications; many nodes cannot process some consensuses that needs a large amount of energy and computational consumption, such as PoW.
Although the DSS conjecture is only a way to analyze the blockchain performance of Ethereum, it is not theoretically rigorous. Still, it provides an entry point for researchers to improve the performance of the consensus algorithm. From what has been analyzed above, developing suitable consensus algorithms to balance the performance between decentralization, security, and scalability is the key to solving the challenge in blockchain-based applications [25].
2.2. Proof-Based Consensus Algorithm
PoW [1] algorithm is used in permissionless blockchain systems. Participants compete for accounting rights by solving a complex but easily verifiable mathematical problem with their computing power. The first node to solve such a problem is rewarded with a certain amount of cryptocurrency. This process is described as “mining,” and the feature of open access makes PoW more scalable and decentralized. However, there is the problem of computing power consumption in PoW. It is unfair that the competition for accounting rights is closely related to the computing power of nodes because nodes with low CPU capacity are difficult to obtain accounting rights of PoW. In addition, a transaction in a block must wait for the confirmation of six additional blocks before consensus can be achieved to prevent Double Spending attacks in the consensus process. Studies have shown that the PoW algorithm can only reach consensus for seven transactions per second and may suffer tailored attack behavior such as 51% attacks. The low consensus efficiency limits the application of PoW in blockchain systems other than Bitcoin [26].
Researchers have proposed the PoS consensus to solve the problem of computing power consumption in the PoW algorithm, which has been applied in Ethereum [11]. In the PoS algorithm, each node is given a new metric called coinage. PoS algorithm assumes that rational high-asset nodes will not disrupt the consensus process because the potential loss of assets will outweigh the gain from their malicious deeds. The PoS algorithm achieves higher TPS performance compared to the PoW algorithm, but there are also shortcomings. The risk of monopoly is introduced in PoS. Low-asset nodes cannot compete fairly with high-asset nodes for accounting rights, and it can lead to a tendency to centralize the system. Researchers have proposed the DPoS algorithm to mitigate this monopoly risk in PoS, which is currently used in projects such as EOSIO and Cosmos [12]. Each node can vote for a representative based on their stake, and the accounting rights will be given to the node that receives the highest number of votes. Although the PoS and DPoS solve the waste of resources in PoW, there are still problems such as low efficiency.
The proof-based consensus algorithm is designed for cryptocurrency systems like Bitcoin and Ethereum. Although the efficiency of the proof-based consensus algorithm is low, it is worth mentioning that these algorithms make some attack behavior for blockchain systems impractical. We provided a summary comparison in Table 2 about its pros and cons.
2.3. Voting-Based Consensus Algorithm
Permissioned blockchain has higher requirements for transaction throughput than permissionless blockchain, and it is more suitable to adopt the voting-based consensus mechanism. This section will introduce some voting-based consensus mechanisms and their improvement algorithms. The voting-based consensus mechanism can be divided into Byzantine Fault Tolerance algorithms that can tolerate Byzantine Failure and Crash Fault Tolerance algorithms that can only handle Fail-stop Failure. Byzantine General Problem proposed by Lamport et al. in 1982 is how the participants can complete consensus in the presence of malicious node interference in the network [27].
The differences between the two consensus algorithms are shown in Table 3. It should be noted that all the data of TPS in the table are the result under ideal experimental conditions.
2.3.1. Byzantine Fault Tolerance Algorithms
As a classical BFT algorithm based on the state machine replication mechanism, the PBFT algorithm was proposed by M. Castro and B. Liskov et al. [27]. PBFT algorithm can reach consensus with the number of malicious nodes accounting for less than 1/3. However, the PBFT algorithm requires mutual communication and confirmation of every two nodes in each consensus, and the algorithm’s complexity is . Thus, the application scenario of PBFT is minimal due to its high consensus cost and poor scalability performance. PBFT has not been used in real-world engineering applications. For example, the famous open-source project of permissioned blockchain, Hyperledger Fabric, has only used the PBFT algorithm in the early v0.6 version.
Lei et al. proposed a reputation-based Byzantine fault-tolerant algorithm, RBFT, in 2018 [28]. RBFT evaluates the behavior of each node in the consensus process through a reputation model. If a malicious node is detected, its reputation value and voting weight will be reduced. In addition, the view change phase is improved by adding an incentive mechanism so that the nodes with higher reputation value have a higher chance of becoming the accountant node. The experimental results show that the RBFT algorithm can quickly and effectively identify malicious nodes through the reputation model. Compared with PBFT, the RBFT algorithm can eventually improve the transmission throughput by 15% and reduce the latency metric by 10%.
Rong et al. proposed an improved BFT algorithm, ERBFT, in 2019 [29]. ERBFT algorithm uses the backup nodes in the network to identify whether the accountant node is a malicious node through a new request ordering mechanism (Order-Match). Suppose the accountant node does not pass the verification of the Order-Match mechanism. In that case, the backup node will trigger the suspicious protocol (suspect protocol) to confirm further whether the accountant node is under malicious attack. The experimental results show that the ERBFT algorithm performs better than the PBFT algorithm in throughput and scalability and can improve the transaction throughput by 30%.
Tendermint is a blockchain project of the Cosmos network, known for simplicity, high performance, and fork accountability. As the consensus protocol of the Tendermint, Tendermint BFT is a simplified version of the PBFT algorithm. The relationship between Tendermint BFT and PBFT is similar to the relationship between Raft and Paxos. Tendermint BFT can be used in a Byzantine environment. Although Tendermint BFT can tolerate the failure of only 1/3 of the nodes in the system, it can tolerate any fault, including hacking and malicious attacks [30].
The core idea of the above study can be summarized as optimizing the traditional Byzantine fault-tolerant algorithm by improving the transaction throughput and scaling performance. Although the current research results have improved the performance and scalability of the traditional Byzantine fault-tolerant algorithm, the transaction efficiency is still far from that of the Crash Fault Tolerance algorithm.
2.3.2. Crash Fault Tolerance Algorithms
The Raft algorithm [16] is an improvement of the Paxos algorithm; the Raft algorithm completes the consensus through the leader election phase and logs replication phase. The nodes of the Raft cluster do not need to confirm each other for the transmitted data. The transmission throughput of the Raft algorithm in the experimental environment is more than five times that of the PBFT algorithm. The Raft algorithm has been used in many practical projects such as ETCD and BRAFT due to their easy-to-understand and excellent performance. However, the Raft algorithm can only be used in a non-Byzantine network environment without malicious nodes, which cannot restrict the behavior of malicious nodes, so it will bring incalculable impact to the whole consensus system once the leader node is maliciously controlled [18].
Chen et al. proposed a CRaft consensus algorithm based on the node trust mechanism based on the Raft algorithm in 2018 [31], which enables the algorithm to be used in the Byzantine network environment. CRaft is divided into the trust evaluation phase and consensus phase. It establishes trust evaluation criteria by the OC-SVM algorithm. The prediction accuracy of Craft for Byzantine nodes is up to 100% (there is still a 17.89% false-positive rate in CRaft). Compared with the PBFT algorithm, the throughput of CRaft can still be maintained at good performance when the number of nodes is expanded to 60. So, it is more suitable for a permissioned blockchain environment than PBFT.
Wang et al. developed the Beh-Raft algorithm in 2021, which divides blockchain nodes into groups as parallel shadings to improve scalability at the cost of increased communication and storage per node [32]. Beh-Raft introduces the Proof of Behavior (PoB) algorithm for incentivizing honest behavior, which ensures that the probability of an honest node being selected as an accountant node is greatly increased by combining the PoB with the Raft algorithm. The Beh-Raft algorithm is Byzantine fault-tolerant while maintaining better scalability.
The hhraft algorithm was proposed by Wang et al. in 2021 [33]. In response to the problem that the RAFT algorithm cannot use in a real-world network, hhraft introduces a new monitor mechanism to optimize the Raft consensus process, which is used to monitor the network for “Sybil nodes” that fake their identities maliciously and accountant nodes that tamper with the original data. The hhraft has been experimentally proven to outperform the Raft algorithm in terms of transaction throughput, consensus latency, and resistance to Byzantine failures. It is suitable for real network environments with high real-time and high adversarial performance.
Although the current research results can determine the malicious nodes in the network, there are still some shortcomings. Most of the present improved algorithms select malicious nodes in a “static” method, meaning they need to design adversarial node models or reputation value determination criteria in advance. They cannot be adjusted according to dynamically to network environment changes. However, the imbalance between normal and malicious nodes’ behavior makes it challenging to construct an accurate classifier in a Byzantine network environment.
3. The System Model
3.1. Problem Description
In order to realize some business goals without centralized institutions and meet the demands of traceability and verifiability, such as data sharing or commercial paper exchange, a permissioned blockchain is usually established by several companies or organizations without a complete trust relationship based between them. In this blockchain network, everyone wants administrative privileges because everyone fears losing rights and profits in decentralized networks. It is an acceptable solution for all participants to monitor each other to prevent the organization that masters the power to dominate the system from gaining illegal benefits. In such a case, the participants do not subjectively destroy to cause Byzantine behavior to the permission blockchain unless they are maliciously controlled because everyone wants to benefit from the blockchain system. In addition, the participants are abstracted as nodes. Nodes are computational devices such as sensors, computers, and servers in the real environment. The lowest possible consumption of computational resources is what every stakeholder of the permission blockchain expects to achieve due to computational resources and economic costs being closely linked. Therefore, it is essential to find a suitable consensus algorithm to meet the demand of such a consortium blockchain.
From what has been analyzed in Section 2.1, the evaluation system of the consensus algorithm can be established based on decentralization, security, and scalability. More detailed, each evaluation criteria can be measured by several sub-indicators [25], so the main parameters of the evaluation consensus algorithm system can be summarized in Table 4.
Number of consensus nodes: In some consensus algorithms, not all nodes can participate in the election of accountant nodes because some consensus nodes need to undertake other tasks such as supervising the consensus process’s realization. On the contrary, all nodes can be selected as accountant nodes due to no additional roles in the consensus algorithm. Number of consensus nodes is the Qualitative and Beneficial Indicator; we set to indicate the , respectively.
Accountant selection method: In general, voting and polling are two of the most widely used in permissioned blockchain. Compared to polling, the voting is somewhat less decentralized because nodes may not have an equal probability of getting a vote under different network environments. Accountant selection method is the Qualitative and Beneficial Indicator; we set to indicate the , respectively.
Consensus nodes weight: The probability of a consensus node that is honest becoming an accountant node depends on the presence of constraints. For example, the credit evaluation standard that includes the node performance is set in CRAFT. Only the node that meets this credit evaluation standard can be selected. However, some consensus algorithm does not have constraints, which means that honest nodes have the same probability of being the accountant node. Consensus nodes weight is the Qualitative and Beneficial Indicator; we set to indicate the , respectively.
Byzantine fault tolerance: The authors summarize this metric in their respective papers. Byzantine fault tolerance is the Qualitative and Beneficial Indicator. We assign a value to Byzantine fault tolerance with reference in Table 5.
Byzantine node controllability: In some consensus algorithms, identified malicious nodes can continue to compete for the accountant node. Reducing the impact of malicious nodes is one of the essential metrics for measuring security. In RAC, reducing the weight of malicious nodes can also prevent them from becoming accountant nodes because they cannot get more than half of the votes under the Risk-Node Assessment Mechanism. Byzantine node controllability is the Qualitative and Beneficial Indicator; we set to indicate the , respectively.
Attack behavior costs: This metric indicates the cost consumed by attackers needed to malicious control the whole permissioned blockchain. Attack behavior costs include the following two areas: malicious control of the accountant node or enabling permissioned blockchain to reach consensus under the attackers’ intentions. Attack behavior costs are the Qualitative and Beneficial Indicator. We assign a value to attack behavior costs according to Table 6.
Resource consumption: The communication complexity of consensus can measure this metric. The authors summarize the communication complexity of proposed consensus algorithms in their respective papers. Resource consumption is the Qualitative and Cost Indicator. We assign a value to resource consumption according to Table 7.
We can describe the problem that development of appropriate consensus algorithm based on some indicators as a mathematical model. Let eigenvector indicate to the consensus algorithms that need to be compared. Assume that there indicators in evaluation system, then is denoted as the value of corresponding indicator observation of decentralization, security, and scalability. The evaluation indicator is preprocessed by normalization and dimensionless method, and the evaluation matrix is constructed.
Positive ideal solution denotes an ideal consensus algorithm that not existed in real world (each indicator of is the best value among all the consensus algorithms). Set the value of the th indicator in is ,
On the contrary, negative ideal solution denotes another ideal consensus algorithm (each indicator of is the worst value among all the consensus algorithms). Set the value of the th indicator in is ,
Our objective is to find the consensus algorithm that has maximum proximity between ideal solution. Therefore, the objective problem is defined as where and are calculated as follows
3.2. Basic Definitions
The participants of permissioned blockchain are abstracted as nodes, either from the same organization or from different organizations, and will carry a certain amount of assets or stake interests. First, we need to introduce some basic definitions to help the reader better understand the proposed consensus algorithm. (1)Byzantine node and honest node: Byzantine nodes are defined as nodes that malicious attackers may compromise to hinder consensus in participants. Byzantine nodes are also referred to as risk or malicious nodes in this paper. On the contrary, the honest node indicates the node making the right decision on the consensus. The definition of a right decision is determined by the behavior of nodes under different states. The introduction of the states and behaviors will be given in Sections 3.3 and 4.3(2)RNL: The node in the risk node list (RNL) means that the node is not trusted anymore because the Byzantine General Problem or other malicious behavior has occurred in these nodes. RNL is continuously updated during the consensus process according to the behavior of every node in the network(3)Term: RAC uses the term as the logical timestamp to ensure that the nodes have correct timestamps under their different physical environments. The term is numbered using consecutive integers, and the term is updated to a larger term number when a new accountant is generated. The description of the term as shown in Figure 3(4)Basic operations: This definition is mainly applied in the description of the RAC process in Section 4.1, which is divided into the sub-definition as follows(i). The set of nodes in the participating organization , where denotes the total number of nodes in organization (ii). The set of evaluator nodes in the permissioned blockchain network, i.e., the group of evaluator nodes(iii). The set of nodes that is participating of the RAC consensus in the permissioned blockchain network, that is, the consensus node group(iv). Send the message quest from node to node (v). An accountant node is elected from the consensus node group (vi). The interaction between node and node through an interaction function to complete the verification of a block, where node is the client of and node is the server of (vii). The accountant node packages the message from client of permissioned blockchain into a new block that can be broadcasted and stored in the blockchain(viii). Block update function. The accountant node broadcasts the new block to all participating organizations in the network through the interactive function .
3.3. The States in Consensus Algorithm
Permissioned blockchain is established by a certain number of companies or organizations. It is an acceptable solution that all participators monitor each other to prevent the organization from gaining illegal benefits. When joining the network, each node in the permissioned blockchain is verified and registered through the membership service provider and is assigned a unique ID and key pair to indicate its identity. All nodes may experience four different roles in RAC: follower, candidate, accountant, and evaluator. (1)Follower: All nodes are labeled as followers after joining the permissioned blockchain. They can only passively receive the message about blocks that need to be added to the blockchain. When receiving requests from clients, followers need to forward these requests to the accountant for packaging because they do not have the authority to package blocks(2)Candidate: The candidate is the intermediate state between the follower and accountant and will not exist in the network long. Any follower node can become a candidate node when it finds that the accountant node cannot serve properly. The candidate node can initiate votes to other follower nodes and need to get the voting support of enough follower nodes before it can be converted into an accountant node(3)Accountant: Accountant nodes are elected from candidate nodes. Packing client requests into a block and sending them to the evaluator nodes for validation is the responsibility of the accountant node(4)Evaluator: Evaluator node has two tasks in the RAC. First, based on the performance of follower nodes, the evaluator node can determine whether a node to be maliciously controlled through the risk-node assessment mechanism. Second, monitor the performance of accountant nodes and terminate the term of accountant node with abnormal behavior in time. They are high-asset nodes of each participant in the permissioned blockchain, which can primarily reduce the possibility of them actively causing damage to the blockchain system
The state of a node is temporary, and no one can work in a specific role permanently. Different roles can be converted under certain conditions, and the conversion relationship is shown in Figure 4.
4. Algorithm Design
4.1. The Description of Details in RAC Algorithm
The RAC is divided into six phases: Generation of Evaluator, Update of the RNL, Generation of Candidate and Election of Accountant, New Blocks addition, Judgment of New Blocks, New Blocks confirmation. Nodes use Remote Procedure Call (RPC) to communicate in the network. The consensus process of RAC is shown in Figure 5.
Each organization selects a certain number of nodes with more assets or computational power as evaluator nodes to represent the interests of the organization, and together they form the evaluator node group. To prevent possible collusion attacks in the subsequent consensus process, the evaluator node group needs to be composed from different organizations. . Initialize the evaluator nodes of each participating organization into evaluator node groups.
①
All nodes send the sequence of system calls in the last term to the evaluator after the evaluator group is created to decide whether there are Byzantine nodes in the consensus node group that are not suitable for having accounting rights.
②
The evaluator node calculates the potential risk nodes in the network through the Risk-Node Assessment Mechanism and generates and updates a list of risk nodes (RNL) to broadcast to all nodes in the network. RNL updates are implemented through RiskCompute RPC between the node and the evaluator. The description of RiskCompute RPC is shown in Table 8.
③
A follower node that is not selected as evaluator does not receive a heartbeat message from the accountant node in a period (randomly selected in the interval of 150-300 milliseconds), and it indicates that the accountant node of the current term can no longer provide adequate services, which means the accountant node may be offline due to network delay or system failure. At which time, the node that first discovers this situation becomes a candidate node and initiates an election for a new term accountant and sends a RequestVote RPC to all nodes in the network except itself. The nodes that receive a RequestVote RPC from the candidate node only respond to the vote request usually when the candidate node is not matched with RNL. The description of RequestVote RPC is shown in Table 9. When a candidate node gets half or more voting responses, the node changes from candidate state to accountant state and sends a heartbeat message to other nodes in the network. The purpose of this action is to prove that there is already an accountant node that can provide adequate services.
④
The accountant node packages the requests from the client into a block with the structure shown in Figure 1. A complete block message can be represented as < BlockNum, prehash, TimeStamp, Merkle-root, Entries[ ]>, together with the previous hash value, the timestamp, and other necessary messages, where Entries[ ] including the client transaction request. The block is then broadcast to the evaluator group to validate the block information. It is important to note that the original transaction request from the client is sent to the accountant node as well as to evaluator group at the same time.
⑤
The evaluator node verifies the block information from the accountant node. The purpose of this step is to determine whether a Byzantine event has occurred. The evaluator node first checks the block legitimacy information such as the hash value in the block. Secondly, it matches the Entries[ ] in the block to determine whether it is consistent with the transaction request from the client. Phase ⑤ is implemented through Judgment RPC between the node and the evaluator. The description of Judgment RPC is shown in Table 10.
⑥
If the block is determined as invalid in phase ⑤, then the block information will be set to empty (more than 50% of the evaluator nodes respond to “Fail” to the accountant node in the Judgment RPC). The block information will be broadcast to all nodes after verification by the evaluator node. This process has interacted through AppendEntries RPC (the description of AppendEntries RPC is shown in Table 11). All nodes that receive the AppendEntries RPC will respond “success” to the accountant node, indicating that the transaction request has been correctly added. When the block has been securely copied to more than 50% of the nodes, the account node will return the execution result to the client, thus completing the consensus of the request. The follower node will decide that the current accountant node is a Byzantine node when they find an empty block added to the blockchain. Then, the node will add the current leader node into their RNL and restart a new term of accountant node election.
We now give a full version of RAC to help better understand their decentralized design concepts, and the pseudocodes are presented in Algorithm 1.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
4.2. Risk-Node Assessment Mechanism
It is necessary to evaluate and update the Byzantine nodes in the network to prevent Byzantine nodes from becoming accountant nodes. RAC describes the trustworthiness of a node by introducing the concepts of risk value and reliability. The risk value reflects the probability of Byzantine events occurring in a node during a specific term compared to other nodes in the network. Reliability reflects the probability of a Byzantine event occurring at the accountant node during their term. To improve the identification of malicious behavior, the Risk-Node Assessment Mechanism designed in this paper uses systemcall sequences as the source of data analysis. The system call represents the original interaction between the program and the host system, and there is no data abstraction in this process; the use of systemcall for intrusion detection system was first proposed by Forrest and assumes that program operation affects the system and that all exceptions leave traces in the system calls executed by the kernel [34] . Thus, the most significant advantage of our method is that it can find the occurrence of malicious behavior intuitively and locate malicious nodes with abnormal systemcall sequences quickly.
We offer some assumptions about the permissioned blockchain in order to set the stage for the discussion of the Risk-Node Assessment Mechanism.
Assumption 1. The number of honest nodes is always greater than that of Byzantine nodes in the network.
Assumption 2. The malicious behavior of Byzantine nodes cannot be predicted because attackers can use a variety of attack methods or tools to reach their goal of interfering with consensus individually or collusively.
Assumption 3. All nodes run on the same operating system, and the behavior of honest nodes is similar universally because they try to reach the consensus according to their responsibilities, which means that their systemcall sequence is also similar.
Based on the above assumptions, this section will use a short sequence-based technique to model the subsequence of system call sequences for honest nodes, and the node that deviates significantly from it will be considered malicious. The sequence of system calls for each node is first modeled. The sequence of system calls for all nodes is represented as a matrix, say , where indicates the number of nodes in the network and each row in represents the entire sequence of system calls for a node in the previous term. Thus, the matrix is the matrix consisting of the short sequence of system calls of all nodes in the network. Combining the sequence of system calls with their frequency of occurrence is also necessary to highlight the significant differences in behavior between malicious nodes and honest nodes. We set to indicate the specific index of a sequence of system calls, is derived from Equation (5), and denotes the frequency of occurrence of in the matrix .
Second, based on Assumption 3, normal nodes behave very similarly in the consensus process. To further reflect the deviation between the short sequence matrix composed of frequently used system call sequences and the short sequence matrix composed of less regularly used system call sequences, it is also necessary to pay attention to some system call sequences with low frequency but tremendous value because the critical information such as malicious attack is likely to be hidden in them. Therefore, the process of inverse document frequency is also required, and the detail is shown in Equation (8).
In Equation (8), denotes the number of nodes; is the number of nodes containing the specific system call sequence . Finally, the original matrix is obtained as shown in Equation (9) after the processing of frequency and inverse document rate to obtain the matrix .
Assumption 1 and Assumption 2 can analyze the risk value using an unsupervised outlier detection algorithm. In this paper, we use the isolated forest algorithm [35] for malicious node determination. The purpose of the isolation forest algorithm is to rank each node by its anomaly score. The isolation forest consists of many binary trees, each of which is called an isolation tree. The construction of an isolation tree is an entirely random process. Let there be nodes in the network; the method of estimating the average path length of the leaf nodes of an isolation tree can be referred to as the unsuccessful search of a binary tree because they have a very similar structure, as shown in Equation (10). where is the Euler–Mascheroni constant, ). It can be used to normalize the path length because is the average of the path length. The anomaly score of a node can be calculated by Equation (11), where is the path length of node in the isolated tree.
The risk-node assessment mechanism can calculate the risk values of each node by analyzing the sequence of system calls of the nodes in the previous term. The node will be judged as a Byzantine node when its risk value is significantly greater than other honest nodes.
4.3. Punishments Mechanism
This section will focus on the penalty mechanisms in the consensus algorithm. The symbol glossary is listed in Table 12 to facilitate expressing the penalty mechanisms. We use DFA (Deterministic Finite Automaton) to describe the Byzantine node. A DFA is a quintuple , where is a finite set of states, is the initial state, is a set of acceptable states, is a finite set of alphabets, and is conversion function; can be expressed as .
As shown in Figure 6(a), we define the Distinguishing Automaton for the behavior of an accountant node, in which the initial state is 0 (), acceptable states are [4, 5] (), and is the action, where “receive” indicates the receive the transaction request from the client, “generate new block” is the action of the convert transaction request to new block, “broadcast” means broadcast the new block to the evaluator group according to the description of phase ③, “valid block” and “empty block” represent the result of the block generated after verification of evaluator group ().
(a) The state graph of accountant node
(b) The state graph of evaluator node
(c) The state graph of follower node
As shown in Figure 6(b), we define the Distinguishing Automaton for the behavior of an evaluator node, in which the initial state is 0 (), acceptable states are [3, 4] (), and is the action (), where “receive” indicates receive the transaction request from the client and the block from the accountant node in phase ⑤, “verify” means verify the block from the accountant node, “success” is thought that the evaluator has made a right decision, and “fail” represents the decision of a new block by an evaluator is wrong because their judgment is the opposite of that of the majority.
As shown in Figure 6(c), we define the Distinguishing Automaton for the behavior of a follower node, in which the initial state is 0 (), acceptable states are [4, 5] (), and is the action, where “receive” indicates receive the block that from the accountant node and verified by the evaluator group, “addition new block” means that add this block to the local blockchain of the follower node in phase ⑥ and the behavior of honest nodes is similar universally in this phase, “send systemcall” is the action that sends systemcall of previous to the evaluator group in phase ①, and “abnormal” and “normal” represent the result of risk-node assessment mechanism executed by the evaluator group in phase ①, where .
Criterion 1: Byzantine behavior of accountant. Let denote the behavior of accountant node 1. It will be considered that node 1 is a Byzantine node when node 1 reaches state 5 because the new block generated by the accountant node is judged to be invalid in phase ⑤, which may indicate that the transaction request from the client was maliciously tampered with by accountant.
Criterion 2: Byzantine behavior of evaluator. Let denote the behavior of evaluator node 1. It will be considered that node 1 is a Byzantine node when node 1 reaches state 4 because their judgment is the opposite of that of the majority in phase ⑤, which may indicate that collusion attacks happened in the accountant node and the evaluator node.
Criterion 3: Byzantine behavior of follower. Let denote the behavior of follower node 1. It will be considered that node 1 is a Byzantine node when node 1 reaches state 4 because their behavior of block addition is different from that of the majority in phase ⑥, which will be decided in the risk-node assessment mechanism.
Node was judged as a Byzantine node according to Criterion 1, Criterion 2, and Criterion 3. The Byzantine node will be added in RNL to prevent it from causing more significant losses to the blockchain system, which means that it can only serve as the follower node. It is an acceptable solution that the organization of the Byzantine nodes needs to pay a portion of stake interests or fines to reward those who had honest nodes. In addition, some compensation mechanisms can be added based on agreements reached between organizations in permissioned blockchain. For example, the organizations of the honest nodes can remove the Byzantine node from RNL through the smart contract after receiving the reward.
5. Performance and Evaluations
5.1. Theoretical Analysis
5.1.1. Complexity of Consensus
Every two nodes’ communication between each other and a three-stage commit process was required in the PBFT algorithm before adding blocks to the blockchain, which leads to a high communication complexity of PBFT. However, the state classification mechanism of the RAC algorithm makes it possible to add blocks without high communication costs.
We divide the RAC algorithm into three main phases to facilitate the analysis: accountant selection stage (including phase ①, phase ②, and phase ③ of RAC algorithm), block addition stage (including phase ④ and phase ⑤ of RAC algorithm), and transaction confirmation stage (including phase ⑥ of RAC algorithm). Let denote the number of nodes, indicates the number of evaluator nodes, and is the number of follower nodes.
In the accountant selection stage, the follower node needs to go through two steps of sending systemcall to the evaluator group and sending voting request to the rest of the follower nodes when it becomes an accountant node, so the communication complexity of this stage is . In the block addition stage, only the accountant node needs to send messages to the evaluator node and the follower node to reach consensus. No communication is needed between the evaluator nodes and follower nodes, so the communication complexity of the RAC algorithm at this stage is . The communication complexity of RAC algorithm in the transaction confirmation stage is because only more than half of the follower nodes are required to complete the verification. Therefore, the communication complexity of the RAC algorithm is , which is smaller than in PBFT.
5.1.2. Security Analysis
Some malicious attacks can threaten the permissioned blockchain. In this section, we situate our discussion about the security ability of the RAC algorithm.
Collusion attack and Double Spending attack: It would have an unpredictable impact on the blockchain system if the consensus protocol was not protected against Double Spending attacks. The consensus result of the RAC algorithm is deterministic rather than probabilistic, which can avoid Double Spending attacks to a certain extent. However, a Double Spending attack occurs when the accountant and the malicious evaluator collude in the RAC algorithm. Thus, the defense mechanism for the Double Spending attack can also be equivalent to that for the collusion attack. Collusion and Double Spending attacks cannot occur if the percentage of malicious evaluator nodes does not exceed 50% in the RAC algorithm because blocks can only be added after more than 50% of the evaluator nodes have passed the checksum, which also means that the RAC algorithm can tolerate at most 49% of Byzantine evaluator nodes in the network. In the blockchain network, the attacker may use the 51% attack as a sub-attack of the double-spend or collusion attack.
Sybil attack: Sybil attack indicates that the attacker attempts to control the network by creating many fraudulent identities, which can be used to help the attacker gain voting power or broadcast false messages in the blockchain system. No node of the decentralized system can know how many nodes are involved in the peer network; they can only judge the global situation by the data they receive. The attackers can take the means to maliciously control the honest nodes by disguising themselves as multiple nodes and influencing the behavior of the honest nodes. Two approaches are used in the RAC algorithm to defend against Sybil attacks. On the one hand, nodes need to complete registration in the identity authentication mechanism and be assigned a unique identity before joining the permissioned blockchain. Registration needs to be endorsed by a specific organization, which can enhance the cost for attackers to register multiple identities in the network maliciously. On the other hand, the RAC algorithm uses Risk-Node Assessment Mechanism to defend against Sybil attack. When the attacker bypasses the identity authentication mechanism, the node where the abnormal behavior of forging identity occurs will be readily determined by the Risk-Node Assessment Mechanism because there will be a massive difference between the Byzantine node and the honest node in their system call record.
Targeted attack: Some consensus algorithms are vulnerable to Targeted attacks because the accountant node can be inferred. For example, an attacker launches a DOS attack on the current accountant node, causing it to be inoperative until a malicious node controlled by the attacker becomes the accountant. Thus, the periodic or irregular accountant replacement method used to defend against Targeted attacks is only valid under the assumption that the attacker cannot immediately damage the accountant node. RAC algorithm can achieve defense against Targeted attacks in an effective way due to the function of term.
The accountant node cannot be directly generated from follower nodes but needs to go through the candidate state and be voted by more than half of the nodes before becoming an accountant node. A term is divided into accountant election and regular operation. Only one accountant node existed in a certain term. The term can keep the real identity of the accountant uncertain in the accountant election stage until the accountant provides services for blockchain networks in the normal operation stage. But when the accountant node is elected successfully, it is too late to attack the accountant in this term because the accountant node has been able to serve normally without malicious control by the attacker. If an attacker wants to perform a Targeted attack on the permissioned blockchain, the only thing it can do is corrupt the node randomly before the next term. The randomness of different network environments and latency of each node makes it impossible for the attacker to predict which node will become the accountant node in the RAC algorithm. Therefore, it is a random behavior with a probability that can be calculated in Equation (12).
In addition, an attacker who wants to take malicious control of a node will generate some traces of the attack chain in this node, such as Reconnaissance (use social engineering to understand the target), Weaponization (Targeted attack tool creation), Delivery (delivery of the attack tool to the target node), Exploitation (the attack tool is triggered on the node to realize control based on the system’s application or operating system vulnerabilities), Installation (remote control program of the installation), and Command & Control (the C2 channel be established between the compromised node and internet controller server).
Therefore, an attacker’s successful malicious control of a node will cause the system call of that node to be completely different from other nodes in the permissioned blockchain. Node assessment mechanism in the RAC algorithm can detect malicious behavior because the system call sequence of all nodes needs to be analyzed by the evaluator group before the accountant node election in the new term. The probability can be calculated by Equation (13), where indicates the number of nodes that be maliciously controlled to becoming accountant nodes by attackers.
5.1.3. Summary of Theoretical Analysis
We assume that there are nodes in the network and indicates the -th transaction in the -th block. is the number of failed nodes due to downtime or network errors. The function is used to denote the result of consensus, where 0 presenting invalid and 1 presenting valid of each transaction to reach a consensus. We can draw the following conclusions about the theoretical performance of the RAC algorithm and summarize them in Table 13 based on the previous analysis. (i)Agreement. Consensus can be reached normally when the number of failed nodes is less than 50% of the total number of nodes in the RAC algorithm. .(ii)Efficiency. The communication complexity required to reach consensus in the RAC algorithm is .(iii)Security. The RAC algorithm can form an effective defense against Sybil attack, Targeted attack, Collusion attack, and Double Spending attack when the number of malicious nodes is satisfied to be smaller than 50%.
5.1.4. Comparison with the Improved Consensus Algorithms
This section compares RAC with some improved consensus algorithms of permissioned blockchains, such as Beh-Raft, HHRAFT, CRAFT, and Tendermint BFT, in terms of decentralization security and scalability under the evaluation system introduced in Section 3.1 to highlight the advantages of RAC.
We set there are nodes in the permissioned block network. The preliminary evaluation results are shown in Table 14. An explanation of each indicator can be found in Section 2.1.
Based on the analysis results in Table 10, combined with the quantitative evaluation criteria introduced in Section 3.1, evaluation matrix is constructed as follows.
Positive ideal solution is and negative ideal solution is . We compared the proximity between ideal solution of Beh-Raft, HHRAFT, CRAFT, Tendermint BFT, and RAC. The experimental results are shown in Figure 7.
Under the mathematical model of blockchain evaluation proposed in Section 3.1, the RAC algorithm has a more significant advantage over other improved consensus algorithms.
5.2. Experiment Analysis
The performance of RAC algorithms can be experimentally compared and analyzed. The RAC algorithm combines Byzantine fault tolerance and high transaction efficiency, making it applicable to real-world network environments. We conducted the experiments using an Intel Core i5 and 16 GB RAM running macOS operating system. The construction of the RAC algorithm is implemented using Golang1.14.7. To further test the performance of the proposed approach in a cluster environment, we use the technology of container, thread, and virtual machine to represent the different network nodes, and the technology of container, thread, and virtual machine is implemented with goreman0.3, docker18.09, and VMware fusion11.5.5. We compare the RAC with consensus algorithms such as Tendermint BFT and Raft, which are widely used in blockchain platforms available today in efficiency performance.
5.2.1. The Comparison of Election Cost
Accountant selection is the first phase in the consensus algorithm. The accountant selection of RAC and Raft is based on voting. Figure 8 depicts the comparison between Raft and RAC algorithms for different network sizes in the accountant election cost. The RAC algorithm consumes more cost of accountant election than the Raft algorithm due to the risk-node assessment mechanism. The cost of accountant selection has been experimented within a network environment with 10, 20, and 30 nodes and different percentages of Byzantine nodes. The results show that as the network sizes and the proportion of Byzantine nodes increase, the cost of the RAC increases more than that of the Raft algorithm.
5.2.2. The Comparison of Transaction Confirmation Latency
Transaction confirmation latency is when a specific transaction reaches consensus in all nodes, which is one of the essential indicators of a consensus algorithm. It is calculated as shown in Equation (15). where denotes the timestamp when a transaction reach consensus, and indicates the timestamp when the transaction is initiated. The few slow nodes in both RAC and Raft algorithms do not affect the overall latency performance of the algorithm. However, the RAC algorithm needs to add a message forwarding process compared to the Raft algorithm. Due to their unique judgment mechanism of the new block, some latency performance was affected. Figure 9 depicts the latency performance of RAC and Raft algorithms with the different numbers of nodes. The overall latency performance of the RAC algorithm is reduced by about 50% in a network environment with 5-30 nodes.
5.2.3. The Comparison of Transaction Throughput
Throughput indicates the ability to process the number of client requests per unit time, and Equation (16) is the formula for calculating throughput, which can measure the efficiency of the blockchain system.
The value of is taken as 1000, and the experimental results of throughput performance comparison of different consensus algorithms are shown in Figure 10. In a network environment with 5-30 nodes, the results show that the RAC algorithm loses about 10% of throughput performance due to its security mechanism compared to the Raft algorithm. However, compared with the Byzantine fault-tolerant consensus algorithm such as PBFT, the RAC algorithm still has an advantage in terms of throughput performance.
5.2.4. The Comparison of Time Efficiency
We compare the time efficiency of different consensus algorithms under the simulation environment that uses a 100-node to generate concurrency transactions, and the size of every block generated is 256 KB. As shown in Figure 11, the time efficiency of RAC at a better level than Tendermint BFT. Under the same size of blocks, RAC are superior to Tendermint BFT due to communicational complexity of Tendermint BFT is up to , while RAC have reduced it to a smaller value; as a result, the time consumed of Tendermint BFT is more than RAC with the large number of transactions.
5.2.5. Summary of Experiment Analysis
Compared to the Raft algorithm, the RAC requires an additional security mechanism, so there is a loss of efficiency in the simulation environment. However, RAC has advantages in latency and throughput performance compared to the Byzantine fault-tolerant consensus algorithm like Tendermint BFT. Thus, our results show that the RAC algorithm proposed in this paper can reach a better performance balance in efficiency and security.
6. Conclusions and Future Works
6.1. Conclusions
This paper proposes a consensus algorithm, RAC, for permissioned blockchain. First, we introduce the implementation process of the RAC algorithm, which focuses on the detailed phases, Risk-Node Assessment Mechanism, Reward and Punishments Mechanism of the algorithm. Second, we theoretically analyze the performance of the RAC algorithm and compare the RAC algorithm with other improvement consensus algorithms. The result shows that the RAC algorithm has high scalability (the communication complexity of the RAC algorithm is ) and can provide better protection against blockchain attacks such as Sybil attacks and Targeted attacks. Finally, we experimentally compare the efficiency performance of the RAC algorithm with the consensus algorithms (Raft and Tendermint BFT) that are widely used in real-world blockchain systems. The results show that the RAC algorithm can achieve lower latency performance and higher throughput under a Byzantine network environment (the RAC algorithm loses about 10% of throughput performance compared to the Raft algorithm; however, Raft can be only used in a non-Byzantine environment; RAC algorithm still has an advantage in terms of throughput performance compared with Tendermint BFT under Byzantine network environment). In summary, RAC can reach a better balance in the performance of decentralization, security, and scalability.
6.2. Future Work
From what has been concluded in theoretical and experimental analyses, RAC can be well applied to the new business model based on blockchain to help a group of entities under cooperation and wants to eliminate the dependence on centralization certification organization. Table 15 lists some real-world applications of permissioned blockchain where RAC can be selected as the consensus algorithm. These scenarios are characterized by fixed node size and the presence of a certain number of light nodes but with certain security and time efficiency performance requirements. In the future, we will further use RAC in some complex scenarios and explore the performance of RAC on different real-world applications.
Even though RAC is an improved consensus solution in permissioned blockchain, it still has some limitations: (1)RAC has a lower processing speed than traditional centralized systems, which may limit the application of the RAC algorithm(2)Reputation-based incentive mechanism should be established and enforced to reduce the technical barriers and costs of the punishments mechanism we proposed in RAC(3)The security of RAC needs to improve by developing some new technologies. The Risk-Node Assessment Mechanism of RAC introduces the threat of re-centralization, which destroys the distributed security features of the blockchain system to a certain extent, which is conducive to implementing 51% attacks and Double Spending attacks
Data Availability
All data included in this study are available upon request by contact with the corresponding author.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This research work was supported by the Ministry of Education Industry-University Cooperation Collaborative Education Project.