Introduction

Due to the characteristics of blockchains (such as decentralization, persistence, anonymity, and auditability) [1] and the exploration and development of many applicable scenarios, blockchain technology has received more attention increasingly from the industry and the research communities. With digital currencies represented by Bitcoin and the development of related technologies and scenarios, such as smart contracts, financial services, supply chains, the Internet of Things (IoT), and security services, blockchain technology is becoming one of the most promising next-generation technologies [2, 3]. According to the different access mechanisms, blockchains can be classified into three types: public, consortium, and private [4]. The consortium blockchain, which only serves members of a particular group, and where members can read-and-write accounting operations on the blockchain only after obtaining the permissions, is the most widely used type [5]. However, with the continuous exploration and development of the applications of consortium blockchains, their performance has become an important bottleneck for the promotion and applications. Specifically, the consortium blockchain’s current performance cannot support most large commercial applications [6].

Currently, the factors affecting blockchain performance are broadcast communication, information encryption and decryption, the consensus mechanism, and the transaction verification mechanism [7, 8]. Among them, the goal of the consensus mechanism is to make the information of the participating nodes consistent, but reaching consensus in a highly decentralized system is time-consuming. Moreover, accounting for “bad” nodes increases the time complexity.

The genetic algorithm [9] is a randomized search and optimization technique guided by evolution and natural genetics principles. It performs searches in complex, large, and multimodal landscapes and provides near-optimal solutions [10]. The distributed character of the genetic algorithm is suitable for the distributed node structure of blockchains, and some experts have applied the genetic algorithm to improve blockchain performance. Li, Wu, and Chen [11] proposed a blockchain-based security architecture for distributed cloud storage that customized a genetic algorithm to solve the file block replica placement between multiple users and data centers in a distributed cloud storage environment. Hussein et al. [12] proposed a scalable and robust system for managing medical records and information using blockchain technology. The system uses genetic algorithm technology to reduce the transaction node time and improve reliability during the verification request phase.

In this paper, we aim to address the low-performance problem of the consortium blockchain consensus. By adopting the most widely used practical Byzantine fault tolerance (PBFT) consensus mechanism, we seek to select high-performance nodes to participate in the consensus to optimize this problem. We propose a genetic algorithm-based blockchain consensus algorithm improvement scheme to formulate the blockchain node fitness function, iterate the high-quality consensus node group, and limit the consensus to a small part. The genetic algorithm is applied to the nodes to increase the speed and efficiency of the consensus, block generation, and computation. We design controlled experiments based on the FISCO BCOS [13], an open consortium blockchain platform built on BCOS by the Financial Blockchain Shenzhen Consortium (FISCO) Taskforce Team (prominent team members include WeBank, Tencent Cloud, and Shenzhen Securities Communication). Two experiments are conducted using the same node network environment as the FISCO BCOS platform, one utilizing the node selection scheme proposed in this paper and one randomly selecting nodes to form a blockchain network. By analyzing and comparing the obtained experimental data, we test the safety and practicability of our method.

The main contributions of this paper are summarized as follows.

  1. 1.

    We develop a novel blockchain consensus scheme that allows the optional nodes to participate in the consensus based on the PBFT consensus algorithm. This can achieve lower computational costs and improve performance.

  2. 2.

    We use a genetic algorithm to screen the consensus algorithm participation nodes and minimize the complexity of the blockchain users.

  3. 3.

    We design control experiments to compare the operational data of the consortium blockchain with or without our node selection scheme. Our results show that the proposed blockchain consensus with the genetic algorithm performs better than when all the nodes participate in the consensus or some nodes participate without the genetic algorithm screening node. In addition, we show that our proposed algorithm can achieve lower computational costs than other solutions.

The rest of the paper is organized as follows. “Related work” provides a literature review of related work on the methods and techniques used to implement the system. “Architecture design” presents the problem formulation and the algorithm description. “Design of the experiment” provides the simulation results and the comparison between all the nodes participating in the consensus and some nodes participating without the genetic algorithm screening node. The conclusions are summarized in “Conclusion and future work”.

Related work

A blockchain is a distributed system whose purpose is to support multiple participants to implement system functions [14] in a decentralized fashion. It is limited by the proven CAP principle [15]; that is, distributed computing systems cannot simultaneously ensure the following three characteristics: consistency, availability, and partition tolerance [16]. In a distributed design, weakening the guarantee for a certain feature is often necessary. Therefore, the current blockchain scalability is limited by performance issues [17]. Currently, the factors affecting the performance of a blockchain include broadcast communication, information encryption and decryption, the consensus mechanism, and the transaction verification mechanism [8]. The current methods that address previous performance problems and improve the performance and scalability of blockchain systems include sharding [18], scalable consensus [19], direct acyclic graphs (DAGs) [20], optimization system implementation methods [21], off-chain computing [22], and sidechains [23]. In this section, we focus on the performance issues of the consortium blockchain consensus mechanism, explore its performance problems, and analyze the proposed solutions. In addition, we will introduce consortium blockchains, the consensus agreement, the PBFT concept, and the genetic algorithm used in this paper.

Consortium blockchain consensus performance

The consortium blockchain refers to a blockchain in which several organizations participate in its management. Each organization controls one or more nodes to record transaction data; only these organizations can read, write, and send data to consortium blockchains [6]. When multiple hosts form a network through asynchronous communication, this asynchronous network is considered unreliable (according to FLP impossibility) [24]. Then a mechanism must be used in these unreliable hosts to ensure that the status of each host finally reaches the same consistency state. For this collaboration, the blockchain must have a consensus mechanism. A blockchain or a distributed ledger protocol can be summarized as a secure distributed protocol that achieves certain tasks satisfying targeted consistency (typically atomicity or total order) and liveness (or availability) semantics [25]. A consortium blockchain can be regarded as “partially decentralized” compared to a public chain. Since it is an enterprise-level application, the consortium blockchain requires more transactions to be confirmed per second with higher security and performance requirements. Due to its security and performance requirements, the consortium blockchain cannot adopt most of the consensus algorithms used in the public chain.

The Byzantine fault-tolerant (BFT) consensus mechanism is commonly used in the consortium blockchain [26]. Since if the number of malicious nodes does not exceed the limit, the BFT algorithm can support higher throughput, and its correctness and activity can be rigorously proven; this is very suitable for enterprise system requirements [27]. The PBFT algorithm [28] and its variants are the most common consortium blockchain consensus algorithms. The original intention was to design a low-latency storage system to reduce the algorithm’s complexity. The process is divided into three phases: pre-preparation, preparation, and commitment. The service operation will be valid if more than 2/3 of the nodes have been approved. PBFT can contain f Byzantine malicious nodes in a fault-tolerant blockchain network, where f = (N − 1)/3, and N is the total number of nodes. It solves the problem where the original BFT algorithm is not efficient and reduces the complexity of the algorithm from exponential to polynomial, making the BFT algorithm feasible in practical system applications. The most widely used consortium blockchain platforms, such as Hyperledger’s Fabric platform [29] and the FISCO BCOS platform [13], all support the PBFT consensus.

On the other hand, BFT and state-machine replication are generally perceived as protocols with poor scalability (Brewer’s CAP theorem) [30, 31]. BFT protocols have been developed by replicating traditional applications, such as databases, for fault tolerance. However, their scalability has never been thoroughly tested beyond these initial applications, particularly in light of many blockchain applications’ reasonably modest performance targets [32]. Communication in the consensus process largest impacts its performance (latency, throughput, and power consumption) [33, 34].

Improved blockchain BFT consensus algorithms

Several improved versions of the BFT consensus algorithm have been proposed that extend the consensus protocol to improve the efficiency of the consortium blockchain. There are two common approaches to solving the Byzantine problem: reducing the number of participating nodes or the number of consensus steps. This subsection lists the research results of the studies adopting these two approaches, comparing them with the improved blockchain consensus algorithm based on a genetic algorithm to illustrate the innovative aspect of our work.

Reducing the number of nodes participating in consensus

Ripple [35] uses the Ripple Protocol Consensus Algorithm (RPCA), a high-performance algorithm with high BFT. Ripple’s consensus is reached only between verification nodes, and each verification node is preconfigured with a list of trusted nodes called the Unique Node List (UNL). The nodes on the list can vote on the conclusion of the transaction. The BFT capability of the Ripple consensus algorithm is (n-1)/5, which means it can tolerate Byzantine errors in 20% of nodes in the network without affecting the correctness of the consensus.

Stellar [36] uses the Stellar Consensus Protocol (SCP) to reach consensus without relying on closed systems to record financial transactions accurately. The SCP has a set of verifiable security attributes optimized according to the method of safely maintaining vitality. Once a partition or misbehaving node occurs, it will be removed from the network process until reached a consensus. The SCP has four attributes: decentralized control, low latency, a flexible trust mechanism, and progressive security. In this system, the nodes on the network process the smaller units of the blockchain called “slices,” which select the nodes they trust and then combine their transactions with other “slices” until network confirmation is achieved.

Hyperledger Indy [37] uses a consensus algorithm called Plenum, which implements the Redundant Byzantine Fault Tolerance (RBFT) algorithm [38]. RBFT allows all instances to order requests, but only ordered by one of the instances, the master instance, are executed. The performance of the different instances is closely monitored to ensure that the master instance provides adequate performance. If that is not the case, the primary replica of the master instance is considered malicious and replaced. Plenum’s consensus round (3-phase commit) has some differences from RBFT. RBFT describes a distinct 3-phase commit for each request, but in Plenum, a 3-phase commit occurs on a batch of requests. Since a 3-phase commit involves n2 communications (n being the number of nodes), Plenum will be more efficient.

Some research efforts support the sharding protocol leading to a considerable amount of research and development. Luu et al. [39] provide a new blockchain protocol called ELASTICO, which achieves a sweet spot between the classical byzantine consensus and Nakamoto consensus protocols. The key idea in their approach is to partition the network into smaller committees, each of which processes a disjoint set of transactions (or a “shard”). Specifically, the number of committees grows nearly linearly as the total computational power of the network increases. Karlsson et al. [40] present “Vegvisir,” a blockchain designed specifically for the low-connectivity, low-power IoT setting. It tolerates network partitions well and uses a low-power consensus mechanism. The downside is that the types of applications that can be implemented with the blockchain are limited to those that only require a partial ordering of logged events.

This article reduces the number of consensus nodes to improve blockchain performance. Our approach does not conflict with the above research efforts, which are complementary. Compared with the above research results, our work focuses more on the node selection process and aims at selecting the optimal node to participate in the consensus. The above research efforts are also committed to using fewer nodes. The method proposed in this article can provide technical support and the optional node strategy for constructing the blockchain, thereby improving the actual blockchain performance.

Reducing the consensus process or information

Tendermint Core [41] is a BFT protocol best described as a variant of PBFT. Tendermint implements a proof of stake for the POS where each generated block requires every validator to vote. There are different voting weights according to the currency holdings and a monetary punishment mechanism for malicious nodes. Tendermint uses PBFT to reach a consensus on the agreement. It generates a set of validators via weighted polling and uses the selected validators to generate consensus proposals and perform the BFT process. It is optimized for the PBFT algorithm and requires only two rounds of voting to reach a consensus.

BFT-SMART [42] is an open-source Java-based library implementing robust BFT state-machine replication. Some of the critical features of this library that distinguish it from similar works (e.g., PBFT and UpRight) are improved reliability, modularity as a first-class property, multicore awareness, reconfiguration support, and a flexible programming interface. Compared to other SMR libraries, BFT-SMART achieves better performance and can withstand many real-world faults that previous implementations cannot.

The Quorum [43] mechanism is a commonly used mechanism in distributed systems to ensure data redundancy and the eventual consistency of the voting algorithm. The main idea comes from the drawer principle, often used for the read-and-write access control of distributed systems. This type of consensus protocol does not require nodes to communicate with each other, and the requests from clients are directly executed and responded to by nodes. After receiving sufficient responses, the client will finally submit the results. However, when a Byzantine error occurs, there is usually a hefty price to solve it. In addition, due to the lack of a sorting mechanism for requests, the Quorum method cannot handle contention.

Zyzzyva [44] is a protocol that uses speculation to reduce costs and simplify the design of BFT state-machine replication. In Zyzzyva, replicas respond to a client’s request without first running an expensive three-phase commitment protocol to reach an agreement on the order in which the request must be processed. Instead, they optimistically adopt the order proposed by the primary and respond immediately to the client. Replicas can thus become temporarily inconsistent with one another. Still, clients detect inconsistencies, help correct replicas so that they converge on a single total ordering of requests, and only rely on responses consistent with this order.

Genetic algorithm

The genetic algorithm [9, 45, 46] is a random search and optimization technique guided by the principles of evolution and natural genetics with a large amount of implicit parallelism. This algorithm was first defined and developed by Holland [47]. It is often used in complex, large, and multimodal environments. In addition, the algorithm can provide an approximate optimal solution for the objective or fitness function of the optimization problem.

The genetic algorithm takes all individuals in a group as objects and uses a randomization technique to search the coded parameter space efficiently. Selection, crossover, and mutation constitute the genetic operations of the algorithm. The five elements of parameter coding, initial group setting, fitness function design, genetic operation design, and control parameter setting constitute the core of the genetic algorithm [48].

The algorithm begins with a population that represents a potential set of solutions, while a population consists of a group of individuals encoded by genes. Each individual is an entity with a characteristic chromosome. Chromosomes, the primary carrier of genetic material, are a collection of multiple genes. Their internal representation is a combination of genes that determines the external representation of the shape of the individual. Therefore, in the beginning, it is necessary to realize mapping from phenotype to genotype in the coding. Since the work of gene encoding is complicated, we often simplify it, such as using binary encoding.

After the initial generation of the population, according to the principle of survival of the fittest, the evolution of generations produces increasingly better approximate solutions. The fitness function selects the individual in each generation and performs crossover and mutation, eventually generating a new population.

This process makes the population evolve like in nature, and the offspring population is more adaptive to the environment than the previous generation. After decoding, the optimal individual in the last generation population can be used as an approximate optimal solution.

Genetic algorithm applied to the blockchain

In the recent past, an increasing number of researchers have discovered the compatibility of blockchain and genetic algorithms.

Wu [49] introduced computer technology into English teaching and studies and designed an English online test system for English subjects, using the genetic algorithm for analysis. Guruprakash and Koppu [50] developed high-performance hashing using SHA-384 with the genetic algorithm while focusing on encrypting transaction transmission, improving transaction flow, block validation, hash quality, hash rate, and storage cost to increase security and performance. To expand the blockchain capacity for each peer, Xu et al. [51] designed a nondominated sorting genetic algorithm with clustering (NSGA-C), which changes the method of selecting individuals from the critical dominance layer by adding clustering to ensure diversity. A suitable solution can be selected from the Pareto set to fulfill the requirements of different users. Liu et al. [52] proposed a storage balancing problem for nonlocal data storage in a blockchain network and proved that the problem is NP-hard. In the proposed scheme, the criterion of the storage balance is established by a balanced coefficient, a customized heuristic matching algorithm (HMA), a genetic algorithm (GA), and a tabu search algorithm (TSA) to solve the problem of imbalanced storage. Wilczyński et al. [53] describe a novel model for security-aware task scheduling in cloud computing based on blockchain technology. Unlike other blockchain-based solutions, the proposed model uses Proof of Stake, not requiring high computing power.

Michalewicz [54] suggested that evolution programs borrow heavily from genetic algorithms. However, evolution programs incorporate problem-specific knowledge using “natural” data structures and problem-sensitive “genetic” operators. The primary difference between GA and evolutionary programming (EP) is that the former is classified as weak, problem-independent methods, which is not the case for the latter. Therefore, the GA should be able to solve any problem solved by the EP/evolutionary algorithm (EA), but EP/EA will not be able to solve all problems solved by the GA. Of course, the generality of GA comes at the expense of efficiency. Additionally, if the candidate solutions exchange information directly, it seems that the algorithm is not EA/EP [55].

The GA chromosome structure is naturally adapted to the consensus node structure of the blockchain, and the chromosome hybridization process is required in this paper to achieve better results. At the same time, the algorithm proposed in this paper is applied in front of the consensus algorithm of the consortium blockchain, not participating in the specific consensus computation and not affecting the consensus computation’s speed. This paper chooses to use GA instead of EA for these reasons.

Architecture design

This section introduces a genetic algorithm-based blockchain consensus algorithm improvement procedure. Figure 1 is a simple consortium blockchain architectural diagram. The consortium blockchain comprises eight nodes, and the nodes marked in blue are consensus nodes. The genetic algorithm of the consensus node selection proposed in this paper is applied to all nodes participating in the consortium blockchain network. Through the execution of the algorithm, the optimal consensus nodes are selected to form a complete consortium blockchain network. The method is based on the PBFT consensus algorithm, not involving specific consensus algorithm details, thus ensuring that the Byzantine problem is solvable and its security is not destroyed. This algorithm is applied before the alliance blockchain consensus algorithm, not interfering with the regular operation of commercial alliance blockchains such as Ripple, Stellar, and Hyperledger Indy. Our algorithm pays more attention to the node selection process and is committed to selecting the optimal node to participate in the consensus algorithm, thus improving the actual blockchain performance. The method uses the genetic algorithm to formulate the blockchain node fitness function, iteratively outputs the consensus node group, and limits the consensus to a small number of nodes, thus accelerating the consensus process and block generation efficiency. The algorithm helps select the consortium blockchain consensus node used before the consortium blockchain is officially run; therefore, the consortium blockchain builder can effectively determine the high-efficiency consensus node to build the consortium blockchain, which improves the overall consensus performance of the consortium blockchain.

Fig. 1
figure 1

Consortium blockchain architecture

Full size image

The algorithm takes the consensus achievement rate, the consensus achievement time, and the cost as the factors of the fitness value and encodes the genes into one chromosome according to the choice of nodes. The fitness value of each chromosome is analyzed based on whether the genetic algorithm selects the consensus node. Next, the chromosomes are screened according to the size of the fitness value, and then the next-generation population is produced through the crossover and mutation operations. The above steps will be iterated, and finally, the chromosome with the best fitness value will be obtained. Then, the final chromosome is decoded, and the consensus node is accordingly selected to get the optimal solution of the consensus node optimization scheme.

Model pre-preparation

Data and characteristics

After reviewing many papers, we concluded that despite efforts to develop blockchain performance evaluation indicators [33, 34], there are no standardized indicators. Thus blockchain performance testing is still in need of research. This paper refers to the indicators evaluated by the three major platforms BTC [56], Ethereum [57], and Fabric [29], which are widely used by the research community and industry. We selected the throughput (the number of consensuses completed in a unit of time) and the single consensus time indicator to conduct the evaluation. In addition, we consider the performance impacts of different machine configurations in an actual production environment. Therefore, we introduce the cost characteristics of the node unit time, representing the machine configuration level. The data are dynamically acquired during the pre-preparation stage and are input into the algorithm after preprocessing. Table 1 shows the node data required by the algorithm. At the beginning of the algorithm, we first extract the cost information of the node and the total time of each node. Then, during the operation of the algorithm, it is necessary to obtain real-time data on the node consensus participation information, including the following: the number of nodes participating in the consensus, the number of times the node completed a consensus, and the time to form each consensus from start to end. Accurate data are the premise of correct algorithm results, and data acquisition is the critical first step.

Table 1 Algorithm data variables
Full size table

Fitness function

In the genetic algorithm, the fitness function is the main index used to describe individual performance [47]. An individual is screened according to the degree of fitness. By mapping the objective function of the problem to the fitness of the individual, the objective function of the optimization problem can be optimized during the population evolution process. The fitness function also called the evaluation function, is a criterion for distinguishing the quality of individuals in a group according to the objective function. It is always non-negative, and in any case, the value should be as significant as possible [58]. The greater the fitness is, the more suitable the individual. The genetic algorithm selects individuals according to their degree of fitness, ensuring that individuals with good adaptability have more opportunities to breed offspring so that those good characteristics are inherited.

This section uses the evaluation indicators selected above as features to construct the genetic algorithm’s fitness function. Thus, the algorithm takes the consensus achievement rate, the consensus achievement time, and the cost as the factors of the fitness value. We list the formulas of the three factors separately and combine them into a single formula as the fitness function. The fitness function aims to find the minimum value to realize the selection of more suitable nodes for participating in the consensus. Then, the genetic algorithm based on the function is used in the consortium blockchain consensus process to perform node screening.

The following equations calculate the fitness and characteristics:

$$P\left(X\right)={N}_{X}/\sum_{j=1}^{{N}_{X}}\frac{{S}_{X,j}}{{C}_{X,j}}$$
(1)

In Eq. (1), P(X) is the reciprocal of the consensus completion rate, calculated using the consensus nodes selected from chromosome X. NX is the number of consensus nodes selected in chromosome X, SX,j is the number of times that the jth consensus node successfully finishes a consensus in chromosome X, and CX,j is the number of consensuses in which the jth consensus node participates for chromosome X

$$T\left(X\right)=\sum_{j=1}^{{N}_{X}}{at}_{X,j}/{N}_{X}$$
(2)

In Eq. (2), T(X) is the average time of one consensus consumed by the nodes selected from chromosome X. NX has the exact definition here as in Eq. (1), and atX,j is the average time of each consensus taken by the jth node in chromosome X.

$$C\left(X\right)=\sum_{j=1}^{{N}_{X}}{\mu }_{X,j}{t}_{X,j}$$
(3)

In Eq. (3), C(X) is the total cost of the consensus nodes selected from chromosome X. NX has the exact definition here as in Eq. (1), μX,j is the unit cost of the jth node in the selection of chromosome X, and tX,j is the runtime of the jth node selected from chromosome X.

$$F\left(X\right)=1/\left[a\times P\left(X\right)+b\times C\left(X\right)+c\times T\left(X\right)\right]$$
(4)

In Eq. (4), X represents a chromosome; F(X) is the fitness value of the consensus node selected from chromosome X; and a, b, and c are coefficients set before the experiment. P(X) is the reciprocal of the consensus completion rate calculated by the consensus nodes selected from chromosome X. C(X) is the total cost of the consensus nodes selected from chromosome X. T(X) is the average time of one consensus consumed by the nodes selected from chromosome X. The fitness function F(X) will be applied to the algorithm proposed in this paper.

Genetic algorithm

The structure of chromosomes in the GA is naturally compatible with the consensus node structure of the blockchain, and the algorithm proposed in this paper requires the process of chromosome hybridization to achieve better results.

Before the consortium blockchain is officially used, the algorithm is first used in the test stage. With the genetic algorithm, the optimal performance consensus node lists, which consist of a consortium blockchain, are obtained to provide a node selection scheme for the consortium blockchain’s construction. The algorithm will run in real time during the consortium blockchain test stage, and the fitness function will be calculated using data obtained by the real-time node consensus.

The hierarchy of the algorithm in the consortium blockchain system is shown in Fig. 2. First, we build a consortium blockchain network. The sequence of the consensus node selection results is regarded as a chromosome, and the genetic algorithm is used in it. The chromosome selection binary coding of the genetic algorithm generates the initial population. Then, we determine the fitness function, select the operator strategy before the initial operation, and screen the initial population. The next step is crossover and mutation, which generates new node combinations. After that, according to the convergence degree of the population, that is, the consistency of the individual fitness values in the population, we judge whether terminate the operation. If the process has converged, we output the consortium blockchain consensus node optimized selection results. Otherwise, we continue to iterate the genetic algorithm. The algorithm is based on the PBFT consensus algorithm, not changing the specific PBFT consensus algorithm process, thus ensuring that the Byzantine problem is solvable and its security is not destroyed. The algorithm does not change the blockchain system process and only needs to provide some relevant consensus data, which are usable, and available to calculate the algorithm.

  1. 1.

    Initialization The m chromosomes form a population, and each chromosome initializes the genes. Every chromosome uses the genes to calculate fitness values via the following fitness function:

    $${\mathrm{Pl}}_{0}=\left\{\{{\mathrm{chr}}_{1},{\mathrm{fv}}_{1}\},\{{\mathrm{chr}}_{2},{\mathrm{fv}}_{2}\},\dots ,\{{\mathrm{chr}}_{m},{\mathrm{fv}}_{m}\}\right\}$$
    (5)

    In Eq. (5), Pl0 is the 0th generation population; chri and fvi are the \(i\)th chromosome, calculated the fitness value according to the gene; chi = {g1, g2, …, gN}, where gj represents the jth gene of chromosome i, and binary code indicates whether the node is selected; N is the total number of consensus nodes; gj indicates the mark of the jth consensus node, which is a Boolean quantity initialized to a random value; and m is a preset constant.

  2. 2.

    Consensus This step is the consensus of the consortium blockchain. In each round of consensus, a chromosome will be selected from the current population Pl0 in order and according to the gene expression of the chromosome to participate in the consensus. One chromosome only determines q consensuses in the step. A population performs a total of q × m consensuses. After the m consensus rounds, Eq. (4) calculates the fitness value for every chromosome in the current population Pl0.

  3. 3.

    Generating a new population According to the fitness value from small to large, the current population Pl0 of chromosomes is divided into three groups: G1, G2, and G3. For the three groups, the chromosomes are selected randomly according to their selection probabilities, Pro1, Pro2, and Pro3, respectively, then added to the population Pl1. If population Pl1 does not reach the expected number of rounds m, the unselected chromosomes in the three groups with the highest fitness value will be selected. In addition, if population Pl1 still does not reach the expected number of rounds m, the remaining chromosomes will be calculated using the two chosen chromosomes in population Pl0 via the crossover method, which is the widely used single-point crossover method.

  4. 4.

    Termination condition The current population Pl1 is evaluated, and the difference in the fitness values S2 of the population is calculated, which is the variance of the population’s chromosome fitness values:

    $${S}^{2}=\frac{1}{m}\sum_{i=1}^{m}{\left[{F\left(x\right)}_{i}-M\right]}^{2}$$
    (6)
    $$M=\frac{1}{m}\sum_{i=1}^{m}{F\left(X\right)}_{i}$$
    (7)
Fig. 2
figure 2

Algorithm flowchart

Full size image

where M is the F(X) average of m chromosomes, and i is the maximum number of iterations. rS2 is the variance of the fitness value set in advance. When S2 ≤ rS2 or the number of iterations in the population is greater than the preset value i, the genetic algorithm will end, and the optimal fitness value chromosome is the resulting output. Otherwise, we return to the step 2 “Consensus” to continue to execute the algorithm.

Complexity and scalability analysis

Due to many uncertainties, there is no effective quantitative analysis method for genetic algorithm parameters, such as accuracy, feasibility, and computational complexity. This is one of its drawbacks of the genetic algorithm. This paper analyzes the algorithm’s complexity according to the proposed fitness function. There are m chromosomes in total, and each chromosome needs to perform q consensuses in each round. The algorithm performs at most t rounds, and one consensus of PBFT has O(n2) complexity. In summary, the complexity of this algorithm is as follows:

$$O(n)=m\times q\times O({n}^{2})\times t$$
(8)

The algorithm is scalable to a certain extent. Theoretically, it can be applied to any consortium blockchain with several nodes more significant than 3n + 1. However, the running speed will decrease with the number of nodes. We will further discuss the effect of the number of nodes on the algorithm speed in “Experimental validation and analyses” (Table 4 and Fig. 5 in detail).

Design of the experiment

To verify the consortium blockchain performance optimization ability of our algorithm, we design an experimental platform to test it. We evaluate the performance of our scheme through extensive variable control methods. We run the experiments in the same experimental environment using the improved scheme proposed in this paper and the conventional consortium blockchain not using this scheme as a comparison. We first evaluate the throughputs (TPSs) of the two methods under different numbers of nodes, which is the number of requests processed by the consortium blockchain system in a unit of time. Second, we evaluate the number of successful consensuses per unit of time under the two schemes, and finally, we assess the two schemes’ operating costs for the consortium blockchain. In “Design and evaluation method”, we introduce our experiment’s design and evaluation method. In “Experimental details”, we will provide the experimental details (Tables 2, 3).

Table 2 Basic parameters of the experimental operation
Full size table
Table 3 Node performance parameters
Full size table

Design and evaluation method

The experimental part of the main body deploys consensus nodes on the server through shell scripts. Before each experiment, we set all nodes participating in the consensus and perform a certain number of consensus processes to record the performance data of each node, especially the consensus time. Based on the performance data of each node, we use genetic algorithms to screen out high-quality nodes and randomly select comparative nodes to conduct control experiments. Each group of experiments will automatically configure different numbers of consensus nodes through scripts, automatically send consensus requests through the simulated console, and then record the experimental data screened by genetic algorithms and the experimental data of comparison nodes (Fig. 3).

Fig. 3
figure 3

Overall experimental process

Full size image

The control variable method reduces the estimation mistakes due to unknown quantities using the known amount, which turns multifactor problems into multiple single-factor problems. Each time, only one of the factors is changed, and the several remaining factors are controlled and remain unchanged. This allows one to study the influence of the modified factor on things, analyze them separately then solve them comprehensively. This method is called the control variable method. It is an essential method in scientific inquiry, widely used in various computer science explorations and scientific experimental studies [59].

In this experiment, we set whether the consortium blockchain consensus improvement method is used as a variable. We establish test and control groups to conduct experiments and compare and evaluate the data obtained. Both groups of experiments are run under the same experimental environment. To ensure the uniqueness of the variables of the control variable method, the control group will randomly select the same number of nodes from the 50 nodes built in the experimental environment as the experimental group and conduct a consensus operation to compare their performance in consortium blockchains.

Experimental details

Deployment script instructions

This part of the pseudocode is used to illustrate the process of the automated deployment of consensus nodes on the server. The primary process includes adding relevant dependent files, configuring a consensus environment, and configuring the server node information.

figure a

Interfaces of the genetic algorithm

As for the definitions of genes, chromosomes, and populations in genetic algorithms, when screening nodes, we define nodes as genes, node combinations as chromosomes, and chromosome sets as populations. Therefore, a series of conversion interfaces, including specific genes, chromosomes, population initialization, and calculation of fitness values, will be used to implement this conversion process.

figure b

Genetic algorithm entity design

Regarding the entity definitions of genes, chromosomes, and populations in genetic algorithms, we need to transform these entity definitions in the program design and define the related parameters, which are used to adjust the accuracy of the experimental process.

figure c

The overall process of the genetic algorithm

After completing the entity and interface definitions of the genetic algorithm, the genetic algorithm will run. This section focuses on gene screening, gene inspection, data recording, and the convergence of the calculation results. In the process, we also need to pay attention to the gene mutation and division strategy settings.

figure d

Experimental validation and analyses

In this section, we will analyze the data obtained from the experiment. After experimental verification, the algorithm can achieve a better TPS in the blockchain built in the cloud environment, complete more transactions within a given time, and reduce deployment costs.

“Architecture design” states that the algorithm’s results are evaluated using three indicators: the average consensus time (s), the blockchain network cost (Yuan), and the consensus success rate. In “Design of the experiment”, we obtain these three indicators as the experimental results data and analyze these data. Through experiments and eliminating abnormal results, we conducted 341 valid experiments and got two sets of data results for the test group and the control group. The results of the experimental grouping times are shown in Fig. 4. The abscissa is the number of nodes selected by the experimental group to participate in the consensus of the consortium blockchain, and the ordinate is the number of experiments. We divide the consortium blockchain nodes and select 5, 10, 15, 20, 30, and 40 nodes for the experiments. Each group takes multiple rounds of experiments to obtain the results. Each group’s test number, no less than 50 times to ensure the experimental data validity, is shown in the figure.

Fig. 4
figure 4

Histogram of the number of experiments

Full size image

This section gives part of the data obtained from the experiment in Table 4. The table lists the average consensus times, average blockchain network costs, average consensus success rates, and standard deviations of the test group and the control group when the number of nodes ranges from 5 to 40.

Table 4 Experimental data results
Full size table

According to the data obtained from the 341 groups of experiments, the consortium blockchain network built by 50 cloud host nodes using the consortium blockchain node selection genetic algorithm proposed in this paper has certain advantages over the consortium blockchain not using the algorithm. In addition, the costs are the same. The overall results are shown in Fig. 5. In the 341 control experiments, 62.5% of the test group had a shorter average consensus time than the control group, and 53.7% of the test group had a higher consensus success rate than the control group. Regarding the costs of building cloud nodes, 48.7% of the test group has lower costs than the control group, and the two groups are not much different. According to these data, it can be reasonably concluded that the algorithm proposed in this paper can improve the performance of the consortium blockchain. In terms of scalability, as shown in Table 4 and Fig. 5, the algorithm supports any consortium blockchain with several nodes greater than 3n + 1 that can be applied.

Fig. 5
figure 5

Experimental results

Full size image

Nevertheless, the running speed will decrease with the increase in nodes and calculations. As the number of nodes increases, the consensus speed of the consortium chain will drop rapidly. Compared with the consortium blockchain platform that does not use this algorithm, the algorithm proposed in this paper can be used at the same cost to obtain high throughput and achieve a higher consensus success rate.

The total data results are compared in Fig. 6. Under the same conditions, using the algorithm proposed in this paper can shorten the consensus time by 0.15 s on average, increase the consensus success rate by 1.7%, and the cost increases only by 4.3 Yuan. It improves the consensus capacity of the consortium blockchain by 13.6%, which significantly improves its capacity. In addition, improving the consensus success rate enhances the performance of the consortium blockchain, and the cost is extremely low or consistent with that of the current.

Fig. 6
figure 6

Comparison of data results

Full size image

Average consensus time

Usually, in the consensus process of the consortium blockchain, the greater the number of nodes participating in the consensus, the longer the consensus process and the greater the cost. The comparison chart of the average consensus time between groups obtained in this experiment is shown in Fig. 7. The abscissa is the number of consensus nodes in the test group, and the ordinate is the single consensus time spent by each group. It can be seen from the figure that this experiment conforms to objective reality and performs well in multiple groups with different numbers of consortium blockchain networks. Under the same network conditions, the average consensus time of the 4 test groups was better than that of the control groups. Second, as the number of network nodes increases, the average consensus time also increases. As the number of nodes increases, the consensus node selection genetic algorithm proposed in this paper plays a more significant role. It can be seen from the figure that when 40 nodes are selected from 50 nodes, the test group reduces the average consensus time by approximately 1 s, which significantly improves the efficiency of the consortium blockchain.

Fig. 7
figure 7

Comparison of the average consensus times

Full size image

It should be noted that when the participating consensus nodes are close to the nodes of the entire network, node selection cannot play a role, and the effect of the algorithm is no longer noticeable. With too few network nodes, the nodes need to receive consensus feedback from the entire network to complete a consensus round, which makes the average consensus time severely dependent on the network environment. This is why the processing time with five nodes is higher than other groups. In this case, any blockage in the node network will significantly affect the average consensus time. In our experiments, abnormal nodes were randomly generated to test this scenario. Therefore, it is reasonable for the consensus time of the 5-node consortium blockchain network to be higher than those of other nodes.

To observe the distribution of the average consensus time of each group, we plotted a scatter plot to keep the result. Figure 8 is a scatterplot of the average consensus time of the test and control groups. The ordinate is the number of consensus nodes during the experiment, and the abscissa is the average consensus time. The abscissa of the control group is the same as that of the test group. To clearly show the data, we display the overlapping part of the test group and the control group separately. According to the experiment, when the number of experimental nodes is 5, the average consensus time of the genetic algorithm proposed in this paper is slightly dispersed compared to the control experiment. As the number of consensus nodes increases, the consensus time of the test group is more concentrated, indicating that the average consensus time is more stable. The outliers can be seen in the figure. The biggest reason for this phenomenon is network communication. Hence, the impact of network communication on the operations of the consortium blockchain will be the focus of future research.

Fig. 8
figure 8

Scatterplot of average consensus time

Full size image

Figure 9 shows the standard deviation of the average consensus time. The ordinate is the number of experimental consensus nodes, and the abscissa is the standard deviation of the consensus time. As shown in the figure, the results are similar to the average consensus time. In the 5-node, 10-node, 30-node, and 40-node experiments, the test groups’ standard deviations are better than that of the control groups, indicating that the consensus time of the test group is more stable. This means that when the consensus time is shorter, the consensus time of the consortium blockchain using the consensus node genetic algorithm is more compact. The smaller the standard deviation is, the smaller the fluctuation and the greater the stability. The significant standard deviation at 15 nodes and 20 nodes is consistent with the performance of the scatter in Fig. 8; therefore, the standard deviation of the test group is inferior to that of the control group.

Fig. 9
figure 9

Standard deviation of the average consensus time

Full size image

Consensus success rate

In the consortium blockchain, the consensus success rate is a critical performance indicator related to the realization of the entire transaction process. We used random abnormal nodes to cause consensus failure to test the influence of the node selection genetic algorithm proposed in this paper on the consensus success rate. Figure 10 is a line chart showing multiple groups’ average rate of consensus success. The abscissa is the number of consensus nodes in the experimental group, and the ordinate is the observed consensus success rate as a percentage. The experimental data in the figure show that when there are 5 nodes, 10 nodes, and 40 nodes, the consensus success rate obtained using the node selection genetic algorithm is the same as that without the genetic algorithm. In experiments with 15 to 30 nodes, the test group, using the genetic algorithm, completes the consensus of the consortium blockchain and achieves a significantly improved average consensus success rate. It can be observed from the figure that when the number of small nodes increases to multiple nodes, the consensus success rate of the experimental group increases. When the number of nodes grows to 40, the consensus rate begins to decrease. From the experimental results, it can be concluded that the algorithm’s performance is weakened when the number of nodes reaches the boundary in the entire consortium blockchain network. The algorithm performs well when the number of nodes is half the number in the whole network.

Fig. 10
figure 10

Trend of the average consensus success rate

Full size image

Operating costs

The convenience and lightness of cloud services have accelerated the development of consortium blockchains. Today, almost all enterprise consortium blockchains joining the consortium blockchain network choose to deploy blockchain nodes on the cloud. Cloud services will have different prices for renting varied hardware computing resources and network communication resources. Accordingly, we determine the cost of node cloud services to test whether the algorithm relies on hardware and network resource advantages to improve the consensus performance of the consortium blockchain and increase the operating cost. The data on the operating cost obtained from the experiment are shown in Fig. 11. The abscissa is the number of consensus nodes in the experimental group, and the ordinate is the average node cost. It can be seen from the data that as the number of nodes increases, the cloud services leased by the consortium blockchain will also increase, and the average cost is positively distributed. From 5 to 40 nodes, there is no noticeable cost difference between the test group and the control group, and the maximum difference is not more than 5 Yuan. This shows that adopting our algorithm will not increase the cost of consortium blockchain deployment. At the same time, it can improve the efficiency of the consortium blockchain consensus.

Fig. 11
figure 11

Average operation costs

Full size image

Conclusion and future work

This paper proposes a blockchain consensus algorithm improvement scheme based on the genetic algorithm. The algorithm formulates the blockchain node fitness function, iterates out the high-quality consensus node group, and limits the consensus to a small part. The genetic algorithm is applied to the nodes to improve the speed and efficiency of the consensus, block generation, and computation. We have performed controlled experiments on the FISCO BCOS blockchain platform to test the safety and practicability of this method. We built a 50-node consortium blockchain network on the FISCO BCOS platform, obtained the data generated by the operation of each node in the simulated experimental transaction on the platform, and analyzed the experimental results based on this. The results verification shows that this algorithm can achieve a better TPS in the blockchain built in the cloud environment, complete more transactions within a given time, and reduce deployment costs. The experiments in this paper have obtained reliable results based on the experimental setting. However, the experiments have been established under relatively ideal conditions and are limited by specific node scales. In the next step, we will build a complex network environment, study blockchain performance indicators, and establish a systematic blockchain performance indicator system. Further, we will conduct a large-scale blockchain consensus test in a complex environment to verify the theory’s validity in this paper.