Skip to main content

Performance Evaluation of Private Ethereum Networks

Abstract

This paper provides a performance evaluation of private blockchain networks based on Ethereum, an open-source blockchain platform. Different sectors with stringent blockchain security, privacy, and auditability requirements have adopted Ethereum private networks to keep their data exclusive within a permission group. However, the concrete performance of private Ethereum networks—i.e., transactions or smart contract interactions—has received limited attention. We have set an Ethereum private network to study the following configuration parameters: (1) distinct transaction complexity; (2) different block sizes; (3) two consensus algorithms, namely Proof-of-Work and Proof-of-Authority; and (4) multiple network nodes. Our evaluation has employed time series datasets from the pharma industry, where high levels of security, privacy, and auditability are always required. However, this evaluation approach is domain-agnostic being valid for other fields. We have observed an inverse correlation between the amount of transactions per block and the block period. In this context, we have determined linear models for the simple (low gas limit) and the complex transactions (high gas limit). The model enables to calculate the block period for a specific amount of transactions to be committed in a block. We also include predictive modelling for an optimal configuration taking into account the amount of transactions to commit into a blockchain network.

Introduction

As a promising technology with intrinsic properties such as security, authenticity, immutability, and transparency, blockchain started to be popularly used in cryptocurrencies at the dawn of the last decade [14]. Blockchain is especially suitable for environments that require temporal order storage with the assurance that data records will remain unaltered and private, given that storage is certified by distributed entities rather than a single central authority. This initial cryptocurrency phase to eliminate a centralised authority is widely adumbrated as Blockchain 1.0. Then, with the introduction of smart contracts—computer code distributedly executed and automatically enforced by the consensus mechanism—the automation of financial transactions was enabled in Blockchain 2.0. Subsequently, in Blockchain 3.0, there is now support to differentiate user bases and configurable algorithms and policies [8].

This paper provides a performance analysis of Ethereum [4, 6] private networks. While public Ethereum networks are open to everyone, private Ethereum networks are only accessible to authorised entities, e.g., a consortium, a defined group of individuals, or a given organisation. Specifically, private networks are used to store and manipulate data that cannot be made public, whereby adopting a Blockchain 3.0 approach. Private Ethereum networks allow the configuration and deployment of different consensus algorithms, block sizes, and smart contracts to effectively configure their performance and associated throughput. Therefore, this paper aims to find an optimal configuration for Ethereum private networks according to the amount of transactions required by a concrete network.

The performance of private Ethereum networks is explored using time series datasets to find an optimal configuration. Obtained from real production manufacturing lines at a European pharma manufacturer, these datasets involve two different machines with multiple environmental sensors. We consider these datasets particularly relevant as, in the pharma industry, all manufacturing process should be auditable and authentic. Consequently, blockchain offers a solution that ensures the immutability and traceability of the process. However, our evaluation approach is domain-agnostic and is applicable to other data-intensive domains.

This evaluation takes into account: (1) different cost constraints represented by distinct fixed and dynamic block gas limits; (2) two different consensus algorithms, namely Proof-of-Work (PoW) [12] and Proof-of-Authority (PoA) [7]; and (3) different number of network nodes. In addition, we have employed linear regression and multiple linear regression to predict the optimal block period and block gas limit to be used in a given network configuration.

As its main contribution, this paper provides support to find an optimal configuration for a given number of transactions required by a blockchain-related use case. Our results indicate that the Ethereum configuration parameters play a crucial role in the overall performance and associated throughput. The transaction and block gas limit as well as the consensus algorithm must always be adequately set to optimise the Ethereum performance.

The rest of this paper is organised as follows. Section 2 presents a literature review regarding the performance analysis of Ethereum networks. Section 3 describes the implementation including the configuration of the network, the Application Programming Interface (API), the smart contract, and the evaluation metrics. Section 4 presents the experimental setup, and discussion of the results. Section 5 presents conclusions, analysis, and directions for future work. Appendix A provides a brief introduction to the background Ethereum concepts required for this study. Namely, (1) transactions and gas; (2) consensus algorithms; (3) block composition; (4) smart contracts; and (5) Ethereum clients.

Related Work

As sequences of blocks with tamper-proof data records handled by a decentralised peer-to-peer network, blockchains benefit from a decentralised authority which validate blocks using consensus algorithms. Blocks are hashed using cryptographic techniques [1, 24] where each block contains the hash of the previous block, creating a ledger. The cryptographic techniques in blockchain ensure that the information contained in a block can only be altered by modifying all subsequent blocks. The data are stored in the blockchain through data transactions.

Blockchain technology can be adopted using public or private peer-to-peer networks. Blockchains coupled with smart contracts aim to interact directly with the final user eliminating intermediary entities. Specifically, blockchain employs a decentralised authority using consensus algorithms making the process faster and with low cost [13]. Gatteschi et al. [10] outline the main data privacy and security advantages of blockchain in different domains. Specifically, new blockchain-based approaches have been explored by: (1) finance; (2) notary services; (3) management of personal data; (4) industrial sector; (5) automotive and mobility; (6) healthcare, education, and government; (7) software, Internet, and Internet of Things (IoT); and (8) sharing economy. These domains have accrued thousands of datasets requiring a sustained throughput from blockchain, i.e., consistent number of transactions per minute. In the foreseeable future, there will arguably be a continuous requirement for blockchain-based applications which can continually handle large amounts of transactions per second [16].

The performance of Ethereum as well as the remaining blockchain platforms has been identified as one of the main disadvantages of this technology [15]. Baset et al. [2] report that, despite its increasing popularity, the Ethereum platform is not mature yet and has some inherited performance issues from earlier cryptocurrency applications. On one hand, by allowing the participation of any node, public blockchain networks require a significant amount of time to propagate transactions, since the network is composed of a large number of nodes [25]. In this context, the latency is high and, consequently, the throughput is low. On the other hand, by enforcing a permission or identity validation from the existing network nodes, private blockchain networks are more efficient and suitable for enterprise applications, as they are typically open to selected users and composed of a lower number of validating nodes.

Different studies compare the performance of blockchain platforms and evidence their limitations for large-scale data processing [9, 17, 23]. Specifically, production lines in pharma involve large amounts of data generated by non-stop sensors from multiple machines, whereby performance control is fundamental to integrate private blockchain networks into their manufacturing lines. Unless adequately tuned, these networks will only support a limited amount of transactions per second, which may prevent its adequate application in pharma and other similarly demanding domains.

Scant research has been conducted on the performance and optimisation of private Ethereum network configurations. Schäffer et al. [18] explore the impact of computational power on performance of both PoW and PoA consensus algorithms. As expected, PoW requires more computing power which translates into more energy, money, and hardware. The authors also explore the network performance of PoW with different block frequencies and block sizes. Hao et al. [11] evaluate the performance of PoW and Practical Byzantine Fault Tolerance (PBFT) [5] consensus algorithms using different Ethereum platforms, since PBFT is not supported by all Ethereum clients. Specifically, PBFT is derived from the Byzantine Fault Tolerant (BFT) algorithm class, which reaches the consensus even when some of the nodes fail or provide false information. Their analysis showed that PBFT outperforms PoW in terms of latency and throughput. Moreover, Di Angelis et al. [7] compare PoA and PBFT consensus methodologies. PoA also belongs to the BFT algorithms, although using less messages exchanges and, consequently, outperforming PBFT in terms of latency and throughput. Concerning Ethereum configuration parameters, Spain et al. [20] study the relationship between transaction fees, throughput, and latency, concluding that these parameters are inversely correlated. Table 1 depicts a critical comparison of the surveyed approaches in terms of block gas limit, consensus algorithms, PoA block period, and transaction gas limit.


Contributions  This paper presents an evaluation of private Ethereum networks by exploring: (1) fixed and dynamic block gas limit configurations; (2) different consensus algorithms; (3) transaction gas limit; and (4) configurations with different number of network nodes. While the surveyed approaches concentrate the analysis on consensus algorithms and computational power, our proposal explore the Ethereum configuration settings, mainly, the gas limit of blocks and transactions. In particular, to the best of our knowledge, there are no research studies exploring the impact of fixed and dynamic block gas limit configuration, transaction complexity, and block period in the private Ethereum network performance. Therefore, this paper contributes with an empirical analysis that enables to find an optimal configuration for private Ethereum networks taking into account the amount of transactions to be committed into the network.

Table 1 Comparison of performance evaluation approaches for private Ethereum networks

Implementation

Figure 1 illustrates the implemented infrastructure which involves two different machines composed of six different sensors. The sensor values are sent to the blockchain which holds a smart contract with the machines data structure. Each transaction is composed of: (1) timestamp; (2) identification of the asset which was produced in that timestamp; and (3) values of the six sensors.

Fig. 1
figure1

High-level diagram of the system used to analyse the performance of a private Ethereum network in an industrial environment

The blockchain technologies employed are: (1) Geth as Ethereum client; (2) Web3J as Java Application Programming Interface (API); and (3) solidity as a smart contract language. To evaluate the performance of this infrastructure, we use latency and throughput as evaluation metrics. Additionally, to find an optimal configuration in terms of block gas limit, consensus algorithm, and blocks period, we employ linear regression and multiple linear regression.

Geth Node Configuration

These experiments are using a receiver node, i.e., just one node is receiving transactions from the machines in a network with two nodes. The performance of the network was evaluated using PoW and PoA consensus algorithms. In this context, the network was tested with two different genesis blocks.


Genesis Block configuration determines the starting point behaviour of the network. In the case of PoW, i.e., ethash, the difficulty, and nonce defined in the genesis block will be the starting values for the cryptographic problem. We start with difficulty and nonce set to 0, since the network will dynamically update these values to keep the mining time between 15 and 20 s. In the case of PoA, i.e., clique, it is possible to configure the block period. As PoA does not rely on any cryptographic problem, the difficulty and nonce will remain 0 over time. Finally, the block gas limit used was 0x8000000. However, the Ethereum client will determine if this value will be overwritten or dynamically adjusted.


Geth Nodes were configured as miners. Each node will accept to mine transactions which present a minimum gas price of 1 wei. This enables to explore the network behaviour concerning transactions with low gas prices. In addition, we explore the performance of the network under fixed and dynamic block gas limit, i.e., via the targetgasLimit. We have fixed the block gas limit using the default value, i.e., 0x47E7C4 and 0x8000000. Geth nodes use a targetgasLimit configuration expressed in hexadecimal. The nodes were initialised using the following command.

figurea

Web3J

We have used Web3JFootnote 1 to auto-generate Java smart contract function wrappers from Solidity binary files, i.e., it creates a Java API to communicate with the blockchain network. The library provides a complete implementation of Ethereum JSON-RPC which works over HTTP. Additionally, it contains an Ethereum wallet support to manage the Ethereum accounts. Finally, Web3J supports the Geth clients facilitating the communication with Ethereum networks. However, there are other libraries available, such as web3.pyFootnote 2 for Python and web3.jsFootnote 3 for Java Script.

In our approach, we use Web3J to deploy smart contracts, commit transactions, and call smart contract methods. Web3j has a default gas price for the transactions of 22,000,000,000 wei each is 0.000000022 eths. In our experiments, we commit transactions to the network using: (1) the default gas price of Web3J for the transactions; (2) 30,000 units of gas as gas limit. Therefore, in our experiments, each transaction has a fee of \(30,000 \times 0.000000022 = 0.00066\) eths.

Smart Contract

Listing 1 presents the code of the smart contract. Smart contract structures the data in the blockchain. Listing 1 lines 5-14 present the data structure used to encode and store the sensor values involved in an asset manufacturing. Listing 1 also shows two functions, namely addAsset() and getAsset() that facilitate interactions with the blockchain. The transactions are committed using the addAsset() function. Each transaction is composed of: (1) asset identifier; (2) timestamp; and (3) six sensor values. These transactions once stored in the blockchain cannot be deleted. Therefore, each asset is auditable and all the corresponding values can be traced. The getAsset() function enables to retrieve information from the blockchain.

This smart contract was deployed in our private Ethereum network, and has been used to structure, store, and read data from the blockchain. It is used to simulate the manufacturing process and, thus, explore the optimal performance of private Ethereum networks under multiple scenarios of configuration.

figureb

Performance Analysis and Evaluation Metrics

The performance analysis explores different types of configurations to achieve an optimal performance for a given number of transactions. For this purpose, we adopt the latency and throughput metrics as follows.

Latency of a transaction \(t_x\) is the time between the submission of \(t_x\) by the Ethereum client and the creation of the block which includes \(t_x\).

Throughput indicates the number of transactions per second tps successfully committed in the blocks. Specifically, throughput relies on two constraints (Eq. 1): (1) number of transactions per block; and (2) block period:

$$\begin{aligned} tps = \frac{\mathrm{Number} \; \mathrm{of} \; \mathrm{Transactions}}{\mathrm{Block} \; \mathrm{Period}} \end{aligned}$$
(1)

These metrics will enable to identify linear behaviours of the network by changing block periods and gas limits. In particular, PoA allows the block period configuration enabling to explore the latency and throughput of multiple periods. Then, we employ linear regression and multiple linear regression to identify the optimal period and block gas limit, knowing in advance the number of transactions to be committed per block.

Linear Regression (LR) models the relationship between an explanatory variable and a dependent variable. In our scenario, we employ LR to model the relationship between the transactions per block \(T_{\mathrm{pb}}\) and the block period \(P_{\mathrm{block}}\) as depicted in Eq. 2, where \(\beta _0\) is the intercept and \(\beta _1\) is the regression coefficient:

$$\begin{aligned} P_{\mathrm{block}} = \beta _0 + \beta _1 T_{\mathrm{pb}}. \end{aligned}$$
(2)

Multiple Linear Regression (MLR) is employed to multivariate contexts attempting to predict one or more continuous variables based on other attributes [21]. This paper relies on MLR to predict the optimal block gas limit \(G_{limit}\) based on transactions per block \(T_{\mathrm{pb}}\) and the block period \(P_{\mathrm{block}}\) as represented in Eq. 3, where \(\beta _0\) is the intercept and \(\beta _i\) (\(i=1\) to k) are the partial regression coefficients:

$$\begin{aligned} G_{\mathrm{limit}} = \beta _0 + \beta _1 T_{\mathrm{pb}} + \beta _2 P_{\mathrm{block}}. \end{aligned}$$
(3)

This performance analysis will enable to identify not only the best configuration for a given amount of transactions but also the behaviour of a private Ethereum network in different scenarios.

Experiments and Results

Our empirical evaluation considers four main scenarios: (1) fixed and dynamic block gas limit configuration; (2) comparison of PoW and PoA consensus algorithms; (3) multiple PoA block period; and (4) configurations with different number of network nodes. The experiments were conducted on OpenStack cloud instances with 16 GB RAM, 8 CPU, and 160 GB of hard-disk space. This implementation has been tested and deployed in the OpenStack platform with Java Development Kit version 13.0.2, Solidity version 0.6.7, Web3J version 4.5.18, and Geth version 1.9.13. These experiments are using a receiver node, i.e., just one node is receiving transactions from the machines in a network with two nodes as miners. In addition, the front-end client which interacts with the Ethereum network is sending transactions with a latency of 0.012 s.

Dataset

The dataset contains data from two different machines (M1 and M2) from pharmaceutical manufacturing product lines. Each machine generates raw data from non-stop sensors. Specifically, the machines are composed of: (1) two temperature sensors; (2) one sensor for pressure; and (3) three velocity sensors. An effective medicine manufacturing highly depends on these values measured by multiple sensors.

Table 2 describes the dataset composition. Specifically, each blockchain transaction is composed of: (1) a batch or asset identifier (ID); (2) timestamp of the sensors data records; (3) two values for the temperature sensors; (4) one value for the pressure sensor; and (5) three values for the multiple velocity sensors. The sensors values are recorded at the same time holding the same timestamp.

Table 2 Dataset composition

Performance Results

The experiments analyse the behaviour of the network considering: (1) the fixed and dynamic block gas limit configuration; (2) different transaction gas limit; (3) PoW and PoA consensus algorithms; and (4) different number of nodes. All transactions were configured to use the default gas price of Web3J, namely 22,000,000,000 wei.

Fixed and Dynamic Block Gas Limit Analysis

Fig. 2
figure2

Fixed default gas limit

Fig. 3
figure3

Dynamic default gas limit

The block gas limit identifies the maximum amount of gas to be used per block, and determines the number of transactions that can be included into a block. According to the node configuration, the gas amount per block can be configured to be fixed (with —targetgaslimit command) or dynamic (without —targetgaslimit command). By default, targetgaslimit is 0x47E7C4. Therefore, we explore: (1) the fixed and dynamic configuration settings; and (2) the performance of PoW and PoA consensus algorithms in both configurations. These experiments were performed using a mining time of 16 s for PoA, since PoW needs a mining time between 15 and 20 s.

The Fixed and Dynamic Gas Limit Configurations impact the network behaviour. First, we investigate the behaviour of the network under fixed and dynamic configurations using the default block gas limit. Figures 2 and 3 present the relationship between the number of transactions and latency for fixed and dynamic configuration, respectively, using the default block gas limit. The figures also include the linear trending line for PoW and PoA consensus algorithms. It shows an intersection point at (159, 0.13) and (320, 0.10) for the fixed and dynamic configurations, respectively. The first element in the ordered pair (i.e., intersection point) indicates the maximum number of transactions per block, and the second element represents the corresponding latency.

Next, we investigate the behaviour of the network under fixed and dynamic configurations using 0x8000000 as block gas limit. Figures 4 and 5 explore the relationship between the number of transactions and latency for the fixed and dynamic configuration, respectively. The figures also include the linear trending line for PoW and PoA. In this case, the intersection point of PoW and PoA is (1930, 0.08) and (309, 0.12) for the fixed and dynamic configuration, respectively. Similarly as in the other figures, the first element in the ordered pair (i.e., intersection point) shows the maximum number of transactions per block, and the second element represents the corresponding latency. These results demonstrate that the block gas limit play a significant role in the performance. With a dynamic configuration, the network adjusts the gas limit according to the transactions included in the previous block. Therefore, when the network is not receiving transactions, the gas limit decreases, constantly. Then, as soon as the queue of new transactions is generated, the gas limit starts to increase. Thus, the dynamic configuration is not the best option in the cases where there is a large window between the submission of transactions.

Performance of PoW and PoA is better when: (1) using a dynamic configuration for the default block gas limit; or (2) using a fixed configuration for a higher block gas limit. Table 3 contains the performance results concerning the latency, throughput, and total number of blocks for both configurations. The results show that the fixed configuration provides better performance when using a higher block gas limit. Specifically, the latency of PoA is better than the latency of PoW by 8% and 23% for machine M1 and M2, respectively. Consequently, the throughput of PoA, when compared with PoW, is higher 13% and 25% for machine M1 and M2, respectively.

Fig. 4
figure4

Fixed 0x8000000 gas limit

Fig. 5
figure5

Dynamic 0x8000000 gas limit

Table 3 Comparison of private Ethereum network behaviour for two consensus algorithms (CA) using two configurations (Config), namely a fixed gas limit and a dynamic gas limit. The gas limit was set to 0x47E7C4 (Default) and 0x8000000

PoA Period Block Analysis

The previous results show that PoA has better performance when compared with PoW. In this context, it is important to further investigate the different configuration parameters for PoA. Therefore, this section explores the behaviour of the network when configured with different block periods and with different transaction gas limits. These experiments use: (1) a fixed configuration adopting 0x8000000 as the target gas limit; (2) simple transactions with a gas limit of 30,000 unit of gas; and (3) complex transactions with a gas limit of 4,712,388 units of gas.

Minimum Transaction Gas Limit in Ethereum is 21, 000 units of gas. However, this value depends on the complexity of the transaction and the interaction with the smart contract. In our experiments, this minimum value of 21,000 is not enough; therefore, we set the transaction gas limit to 30,000 to perform these experiments. Table 4 compares the behaviour of the network when receiving simple transactions. This comparison is done using different block periods. The results indicate that for a period higher than 38 s, the network starts to mine empty blocks. It means that at that point, the transactions are not broadcasted to the network, and just the receiver node is validating the transactions.

Table 4 Analysis of private Ethereum network behaviour under different PoA period (P) for the low transaction gas limit

The period and the transactions per block present a linear behaviour. As maximum, a network which receive simple transactions allows an average of 4000 transactions per block, using a block gas limit of 0x8000000. Therefore, employing an LR, as depicted in Eq. 2, we can calculate the block period \(P_{\mathrm{block}}\) for a given amount of transactions per block \(T_{\mathrm{pb}}\). Figure 6 shows that there is a linear relationship between the block period and the number of transactions per block up to a period of 38 s. The LR presents a \(R^2\) of 0.96 for both machines.

Fig. 6
figure6

Block period analysis employing a Linear Regression where \(P_{\mathrm{block}}\) is the period and \(T_{\mathrm{pb}}\) is the number of transactions per block

High Transaction Gas Limit ensures that a transaction will be accepted in the blockchain, mainly, when the transaction is complex or has some smart contracts interactions. However, a transaction gas limit set too high will influence the behaviour of the network. Table 5 compares the behaviour of the network using different PoA periods in terms of: (1) number of transactions per block; (2) latency; (3) throughput; (4) number of blocks needed to store all transactions; and (5) number of empty blocks.

The results show that the network starts to mine empty block, with a period higher than 22 s increasing the latency, and, consequently, decreasing the throughput. Similarly as in the case of simple transactions, the transactions are not being broadcasted into the network. However, with complex transactions, the throughput reduces by a factor of 2, since the baseline of our network is composed of two nodes. Thus, with this configuration, the maximum period without compromising the performance is 22 s.

Table 5 Analysis of private Ethereum network behaviour under different PoA period (P)

The results indicate a linear behaviour concerning the period and the transactions per block, and, consequently, the latency and throughput. As maximum, the network allows an average of 2 000 transactions per block for a gas limit of 0x8000000. Therefore, employing a LR, as depicted in Eq. 2, we can calculate the block period \(P_{\mathrm{block}}\) for a given amount of transactions per block \(T_{\mathrm{pb}}\). Figure 7 shows that there is a linear relationship between the block period and the number of transactions per block up to a period of 22 s. For each machine, we created a model which enables to calculate the period according to a given number of transactions per block. The LR presents a \(R^2\) of 0.98 for machine M1 and 0.96 for machine M2.

Fig. 7
figure7

Block period analysis employing a Linear Regression where \(P_{\mathrm{block}}\) is the period and \(T_{\mathrm{pb}}\) is the number of transactions per block

Block Gas Limit Analysis

Block Gas Limit defines the size of each block. So far, we have used the value 0x8000000 for the block gas limit. However, as uncovered, a wrong block gas limit configuration decreases the network performance. In this context, we have conducted several experiments with multiple block gas limit configurations to understand the behaviour of the network. To investigate the behaviour of the network using higher block gas limit values, we have conducted these experiments simulating complex transactions.

Table 6 compares multiple block gas limits in terms of transactions per block, mining time, and empty blocks. The results show that the network with a block gas limit smaller than 0x1000000 starts to mine empty blocks, decreasing the performance. It happens with a period of 1 s when receiving transactions with a high gas limit. In addition, it is important to mention again that, by default, the gas limit is 0x47e7c4. According to our results, the default block gas limit when receiving complex transactions requires at least a period of 2 s. Additionally, we can conclude that the maximum block gas limit should be between 0x8000000 and 0x10000000. In that gas limit, the network when configured with a period higher than 28 s starts to mine empty blocks, independently of how high the block gas limit is.

Table 6 Analysis of private Ethereum network behaviour under different gas limit values

Figure 8 shows that there is a linear relationship between the period, transactions per block, and the block gas limit. The scale-up happens until 0x10000000. In the scenario, knowing the transactions per block and the period, the block gas limit can be calculated employing MLR depicted in Eq. 4 where \(P_{\mathrm{block}}\) is the period, and \(T_{\mathrm{pb}}\) is the number of transactions per block. This model presents a \(R^2\) of 0.72 which indicates a good accuracy:

Fig. 8
figure8

Gas limit analysis

$$\begin{aligned} \mathrm{Gas}_{\mathrm{limit}} = - 62873138.38 + 95598 T_{\mathrm{pb}} - 54871343 P_{\mathrm{block}}. \end{aligned}$$
(4)

Different Number of Nodes

A private network can be composed of multiple number of nodes. Table 7 compares the performance of a private Ethereum network when configured with PoA, using 12 s as block period, 0x8000000 for block gas limit, and a high transaction gas limit. For this configuration, the results show that with four nodes the network starts to mine empty blocks. Specifically, it was mined 29 and 37 empty blocks for the machine M1 and M2, respectively. That means that one node refused to validate transactions. Therefore, the performance remains unchanged once the number of nodes which are mining is the same.

Table 7 Analysis of private Ethereum network behaviour under multiple network miners nodes (N)

Discussion

The parameters of a private Ethereum network have a strong impact on its performance. In this scenario, this paper aims to predict an optimal configuration for different amounts of transactions. With this purpose, we explore multiple configuration scenarios.

First, we explore the fixed and dynamic block gas limit configuration. This analysis was performed using the default (0x47E7C4) and 0x8000000 block gas limit. While the fixed configuration fixes the target gas limit, in the dynamic, the network updates the gas limit according to the transactions included in the previous block. If the network is receiving transactions, the block gas limit increases, otherwise, decreases by a factor of \(\frac{1}{1024}\). From this analysis, we conclude that working in the limit of the block size, the dynamic configuration provides better results, since it dynamically adjusts the block gas limit according to the transactions included in the previous block of the chain. However, in our experiments, the fixed configuration shows best performance when using 0x8000000 as the target gas limit. This configuration is suitable for use cases that handle large amounts of transactions, but have large windows between transactions. By fixing the gas limit, the network will not adjust the block gas limit being ready to include the maximum amount of transactions at any time. PoW and PoA consensus algorithms were evaluated in terms of latency and throughput. As expected, PoA outperforms PoW being suitable for private networks, since it validates the identity of the network nodes. In this context, we explored further the PoA configuration parameters, i.e., the block period. To understand the block behaviour facing transactions with different gas limits, we have conducted experiments using transactions with 30,000 (minimum transaction gas limit) and 4 712 388 (high transaction gas limit) units of gas. From this analysis, we conclude that the higher the transaction limit, the smaller the block period should be to obtain improved performance and associated throughput from the network. In addition, we observed a linear behaviour between the amount of transactions per block and the block period. In this context, we obtained a linear model for simple (low gas limit) and complex transactions (high gas limit). The model enables to calculate the block period for a specific amount of transactions to be committed in a block.

All analysis show that the block gas limit plays a critical role to obtain a good performance. In this context, we have conducted multiple experiments with block gas limits from 0x800000 and 0x80000000 using complex transactions. We can observe that the block gas limit provides the same performance with limits higher than 0x10000000. Similarly to block period, the network has a linear behaviour for different block gas limits when receiving complex transactions. Therefore, since we are in a multivariate scenario, we have employed an MLR which enables to calculate the block gas limit using as attributes the transactions per block and the block period.

The last evaluation scenario involved varying the number of network nodes. In this context, we have conducted experiments with 2, 3, and 4 nodes. With four nodes, the network starts to mine empty blocks. This behaviour indicates that the configured transaction gas price of 22,000,000,000 wei is not accepted by the network nodes. For faster processing, the gas price should be higher.

Conclusion

Many domains have recognised the advantages of blockchain aiming to harness its characteristics to improve their existing systems in terms of privacy, security, and auditability. Several blockchain-based solutions have been proposed using smart contracts for supply chain, banking, e-commerce, IoT, finance, etc. Mainly, private networks are suitable for enterprises solutions. However, problems as feasibility or performance have been raised hindering the development of blockchain-based solutions.

To explore this problem, we investigate the efficiency of private Ethereum networks using as case study the pharmaceutical industry. This paper presents a performance evaluation of private networks exploring the configuration parameters of Ethereum. The main goal is to find an optimal configuration considering the amount of data to be submitted to a blockchain network. In this context, we have implemented a blockchain infrastructure composed of: (1) Geth as Ethereum client; (2) Web3J API to interact with Ethereum network; and (3) smart contracts methods to simulate not only data structures but also the storing and retrieval of information from blockchain. This infrastructure was evaluated using real-world datasets of pharma-related environmental values captured by different sensors from two machines from medicine manufacturing production lines. This is a clear example where blockchain is important to ensure the auditability and immutability of the process. The Ethereum transactions were composed of six sensor values, corresponding timestamp, and the asset identification. The performance of the blockchain platform was empirically evaluated considering the following scenarios: (1) fixed and dynamic block gas limit configuration; (2) two consensus algorithms, namely PoW and PoA; (3) different PoA block periods for simple transactions (low gas limit) and complex transactions (high gas limit); (4) multiple block gas limit values; and (5) multiple network nodes.

The results show that the Ethereum parameters play a crucial role on the overall network performance. In particular, we have used regression models to calculate and predict the block period as well as the block gas limit based on the amount of transactions to be committed to the network. Therefore, this research study contributes with an empirical evaluation of the performance of private Ethereum networks which includes prediction of optimal configuration of such networks according to the number of transactions required by a specific network.

As future work, we intend to: (1) explore the impact of different transaction latency to the private network; (2) evaluate the effect of different gas prices to the network behaviour; and (3) explore big PoA networks.

Notes

  1. 1.

    https://docs.web3j.io/.

  2. 2.

    https://web3py.readthedocs.io/.

  3. 3.

    https://web3js.readthedocs.io/.

  4. 4.

    https://solidity.readthedocs.io/.

  5. 5.

    https://geth.ethereum.org/.

  6. 6.

    https://www.parity.io/ethereum/.

  7. 7.

    https://www.hyperledger.org/projects/besu.

  8. 8.

    https://trinity.ethereum.org/.

  9. 9.

    https://github.com/ethereum/webthree-umbrella.

References

  1. 1.

    Anjum A, Sporny M, Sill A. Blockchain standards for compliance and trust. IEEE Cloud Comput. 2017;4(4):84–90.

    Article  Google Scholar 

  2. 2.

    Baset SA, et al. Blockchain Development with hyperledger: build decentralized applications with hyperledger fabric and composer. Birmingham: Packt Publishing; 2019 (ISBN 13: 978-1838649982).

  3. 3.

    Bertoni G, Daemen J, Peeters M, Van Assche G. Keccak. In: EUROCRYPT 2013, Lecture Notes in Computer Science, vol. 7881. Athens: Springer; 2013. pp. 313–314

  4. 4.

    Buterin V. A next-generation smart contract and decentralized application platform. White Paper Revision: 176, GitHub, N.B This is “an introductory paper to Ethereum, introduced before [its initial 2015] launch, which is maintained”; 2019. https://github.com/ethereum/wiki/wiki/White-Paper. Accessed 13 May 2020.

  5. 5.

    Castro M, Liskov B. Practical byzantine fault tolerance and proactive recovery. ACM Trans Comput Syst. 2002;20(4):398–461.

    Article  Google Scholar 

  6. 6.

    Dannen C. Introducing Ethereum and solidity: foundations of cryptocurrency and blockchain programming for beginners. New York: Springer/Apress; 2017 (ISBN 13: 978-1-4842-2534-9).

  7. 7.

    Di Angelis S, Aniello L, Baldoni R, Lombardi F, Margheri A, Sassone V. PBFT vs proof-of-authority: applying the CAP theorem to permissioned blockchain. In: ITASEC 2018, CEUR-WS.org, Milan, CEUR Workshop Proceedings, vol 2058; 2018 (ISSN: 1613-0073).

  8. 8.

    Di Francesco Maesa D, Mori P. Blockchain 3.0 applications survey. J Parallel Distrib Comput. 2020;138:99–114.

    Article  Google Scholar 

  9. 9.

    Dinh TTA, et al. BLOCKBENCH: A framework for analyzing private blockchains. In: SIGMOD ’17. Chicago: ACM; 2017. pp. 1085–1100.

  10. 10.

    Gatteschi V, Lamberti F, Demartini C. Blockchain technology use cases. Advanced applications of blockchain technology, studies in big data, vol. 60. Singapore: Springer; 2020. p. 91–114.

    Chapter  Google Scholar 

  11. 11.

    Hao Y, Li Y, Dong X, Fang L, Chen P. Performance analysis of consensus algorithm in private blockchain. In: IV’18. Suzhou: IEEE; 2018. pp. 280–285.

  12. 12.

    Jakobsson M, Juels A. Proofs of work and bread pudding protocols. In: CMS’99, IFIP—The International Federation for Information Processing book series IFIPAICT, vol. 23. Leuven: Springer; 1999. pp. 258–272.

  13. 13.

    Lai R, Chuen DLK. Blockchain: From public to private. In: Chuen DLK, Deng R (eds) Handbook of blockchain, digital finance, and inclusion, chap 7, vol. 2. New York: Academic Press. 2018; pp. 145–177.

  14. 14.

    Nakamoto S. Bitcoin: a peer-to-peer electronic cash system. 2008. http://www.bitcoin.org/bitcoin.pdf.

  15. 15.

    Parisi A. Securing blockchain networks like Ethereum and Hyperledger Fabric: Learn advanced security configurations and design principles to safeguard Blockchain networks. Birmingham: Packt Publishing; 2020 (ISBN 13: 978-1838646486).

  16. 16.

    Perera S, Nanayakkara S, Rodrigo M, Senaratne S, Weinand R. Blockchain technology: Is it hype or real in the construction industry? J Ind Inf Integr. 2020;17:100125.

    Google Scholar 

  17. 17.

    Pongnumkul S, Siripanpornchana C, Thajchayapong S. Performance analysis of private blockchain platforms in varying workloads. In: ICCCN ’17. Vancouver: IEEE; 2017. pp. 1–6.

  18. 18.

    Schäffer M, di Angelo M, Salzer G. Performance and scalability of private ethereum blockchains. In: BPM 2019, Lecture Notes in Business Information Processing, vol. 361. Springer, Vienna; 2019. pp. 103–118.

  19. 19.

    Singh A, Parizi RM, Zhang Q, Choo KKR, Dehghantanha A. Blockchain smart contracts formalization: Approaches and challenges to address vulnerabilities. Comput Secur. 2020;88:101654.

    Article  Google Scholar 

  20. 20.

    Spain M, Foley S, Gramoli V. The impact of Ethereum throughput and fees on transaction latency during ICOs. In: Tokenomics 2019, Schloss Dagstuhl–Leibniz–Zentrum für Informatik, Open Access in Informatics, no. 9; 2019. pp. 1–15.

  21. 21.

    Sykes AO. An introduction to regression analysis. In: Posner EA, editor. Chicago Lectures in Law and Economics. New York: Foundation Press; 2000.

    Google Scholar 

  22. 22.

    Wood G. Ethereum: a secure decentralised generalised transaction ledger. Ethereum Proj Yellow Paper. 2014;Version 151(2014):1–32.

    Google Scholar 

  23. 23.

    Xin W, et al. On scaling and accelerating decentralized private blockchains. BigDataSecurity/HPSC’17. Beijing: IEEE; 2017. p. 267–271.

    Google Scholar 

  24. 24.

    Zheng Z, Xie S, Dai H, Chen X, Wang H. An overview of blockchain technology: Architecture, consensus, and future trends. 2017 BigData Congress. Honolulu: IEEE; 2017. p. 557–564.

    Google Scholar 

  25. 25.

    Zheng Z, Xie S, Dai HN, Chen X, Wang H. Blockchain challenges and opportunities: a survey. Int J Web Grid Serv. 2018;14(4):352–375.

    Article  Google Scholar 

  26. 26.

    Zheng Z, et al. An overview on smart contracts: challenges, advances and platforms. Future Gener Comput Syst. 2020;105:475–491.

    Article  Google Scholar 

Download references

Acknowledgements

The technical assistance of the technical team at IDA-Fareva—a core member of the SPuMoNI consortium—is hereby acknowledged.

Author information

Affiliations

Authors

Corresponding author

Correspondence to Fátima Leal.

Ethics declarations

Conflict of Interest

On behalf of all authors, the corresponding author states that there is no conflict of interest.

Additional information

Publisher's Note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

This work has been developed under the auspice of the “Smart Pharmaceutical Manufacturing (SPuMoNI)” research project (www.spumoni.eu) funded from 2019 to 2022 by CHIST-ERA, the Horizon 2020 Future and Emerging Technologies programme of the European Union through the ERA-NET Cofund funding scheme (CHIST-ERA BDSI Call 2017), and the Irish Research Council.

Appendix A: Ethereum

Appendix A: Ethereum

An open-source decentralised computing platform that uses blockchain as trustful framework for transaction-based systems [22], Ethereum has become the most used solution in blockchain-based applications. It provides a cryptocurrency token called Ether which can be exchanged between different accounts and used to compensate nodes for the performed calculations. Each account is identified by an address which is generated using a private key and a public key. These accounts can perform Ethereum tasks, e.g., send Ethers to other accounts, deploy smart contracts, and call smart contracts methods. Each Ethereum action requires an amount of gas, i.e., a computational fee needed to perform specific Ethereum transactions.

Transactions and Gas

Transactions are signed instructions built by entities which use Ethereum accounts. Basically, the transactions incorporate the data of those instructions and the address of the receiver which can be another Ethereum account or a smart contract address. In addition, each transaction has a gas limit and a gas price. The gas limit refers to the maximum computational effort that a transaction may have to be accepted by the Ethereum network. Ethereum has a minimum gas limit for transactions of 21,000 and a maximum of 6,700,000 units of gas. The amount of gas of each transaction depends heavily on the complexity of the data, e.g., complex interactions with smart contracts requires more gas. Ethereum returns an error (i.e. intrinsic gas too low), when configured with a low gas limit. Therefore, it is important to be aware of the amount of gas required by Ethereum to process a transaction. The gas price is the price, in wei, of each unit of gas specified in the transaction by the gas limit. Therefore, the transaction fee is given by the following formula \(\texttt {gas price} * \texttt {gas limit}\).

Transactions are stored into blocks which should be unique and reliable to be chained. The block reliability is agreed by all network nodes using consensus algorithms. Once the consensus is achieved, the blocks are created and tamper proof with multiple parameters and included into the chain. The effectiveness of an Ethereum network relies on key elements such as consensus algorithms, block composition, smart contracts, and Ethereum client configuration. The following sections present an overview of these concepts.

Consensus Algorithms

Consensus algorithms are used to achieve agreement on data transactions in a distributed peer-to-peer environment. These processes ensure that the next block to be added into the chain is unique and reliable. This consensus algorithm property of enabling the network nodes to validate the transactions is called mining. Multiple consensus algorithms have emerged to ensure authenticity, integrity, and consistency of the blockchain technology. Specifically, this paper explores and compares PoW and PoA.

PoW is the first published consensus algorithm, and it is used in Bitcoin—the most popular blockchain implementation—where the network consensus is ensured by solving a cryptographic problem. Once the solution for the problem is found by miners, a new block is added into the chain. PoW has been widely explored, since it is the original consensus algorithm and holds a high resilience against attacks. Basically, PoW, in the original version, relies on the Secure Hash Algorithm 256 (SHA-256) as follows:

  • Transaction list creation to build a block whose size does not exceed 1 MB;

  • SHA-256 application using the block header parameters (i.e., version + previous block hash + merkle root + timestamp + difficulty bits + nonce) to create the block hash;

  • Miner checks if the generated hash for the block contains the right amount of zeros in the beginning, i.e., according to the level of difficulty. If the hash is not correct, the nonce is incremented and a new hash is generated, consecutively.

  • Since the solution is found, the right nonce and the remaining block header are sent to the network which, distributively, will achieve the consensus.

Therefore, a miner should present a proof of work which is validated by all nodes of the network to add blocks to the chain. At the moment, mining a block in Bitcoin takes around 10 min. However, the Ethereum PoW algorithm is slightly different to other blockchain platforms. Ethereum uses Ethash, a memory hard PoW algorithm to be resistant to Bitcoin miners, i.e., Application-Specific Integrated Circuit (ASIC), using Keccak as hashing method [3]. Ethash also relies on nonce for proof of work as follows:

  • Transaction list creation to build the block. The size of the blocks starts with the size configured in the genesis block using the gas limit parameter. However, this limit can be dynamic or fixed using the targetgaslimit of the Ethereum client;

  • Keccak application using the Ethereum block header parameters (i.e., previous block hash + merkle root + timestamp + target + nonce + etc.) to create the block hash. The type of header depends on the Ethereum client;

  • Miner checks if the generated hash is lesser or equal than the target value which is represented by the difficulty. If the hash is not correct, the nonce is incremented and a new hash is generated, consecutively;

  • Once the solution is found, the right nonce and the remaining block header are sent to the network which will achieve the consensus;

  • The miner which solves the problem is awarded Ethers.

Similar to Bitcoin, Ethereum also uses the nonce as the solution of the cryptographic problem. However, Ethereum dynamically adjusts the difficulty in each block to maintain the mining time approximately between 15-20 s.

PoA is a reputation-based consensus mechanism which has been explored by private blockchain networks. Instead of miners, the PoA network is composed of N trusted validators or authorities. A node is able to validate blocks if at least \(\frac{N}{2}{+}{1}\) network authorities have previously identified the current node as honest and reliable. PoA does not require the solution for any cryptographic problem to validate the blocks. Each authority is assigned with a fixed time slot, being the leader for blocks validation. This mining approach fairly distributes the validation responsibility among the multiple network authorities. Specifically, Geth Ethereum client applies Clique as PoA consensus algorithm as follows.

  • A time slot is allocated to the leader node combining the block number and the number of authorities;

  • Each authority is allowed to propose blocks every \(\frac{N}{2}{+}{1}\) blocks. Therefore, the mining frequency of authorities is bounded by \(\frac{1}{\frac{N}{2}{+}{1}}\);

  • In maximum, \({N}{-}(\frac{N}{2}{+}{1})\) authorities are allowed to propose blocks in the same time slot (e.g., with \(N=16\), 7 authorities are allowed to validate blocks);

  • GHOST protocol [22] is applied if multiple authorities are proposing the same blocks at the same time, i.e., if forks have occurred. Specifically, this protocol solves the forks giving the validation power to the leader;

  • The block is sealed by the proposer signature, i.e., private key;

  • Block is sent to the network.

The authorities that present a malicious behaviour, i.e., proposing invalid blocks or in a not allowed time slot, reduce their reputation. Specifically, if the majority of the network votes against an authority, it is excluded from the list of reliable authorities [7].

Block Composition

Figure 9 illustrates the anatomy of a block, and how blocks are chained together via the hash of the previous block in the chain. A block is identified by its header. The header contains: (1) the hash of the previous block header in the chain; (2) the timestamp; (3) the hash of the candidate block’s data; and (4) the nonce used, particularly, by PoW as the solution for the cryptographic problem. However, the header may also include other types of information required by the Ethereum client. The transactions are represented in the blocks as Merkle trees being tamper proof and validated by the distributed authorities of the network.

Fig. 9
figure9

Composition of blocks

Genesis Block is the first block of the chain playing an important role in the network performance. To launch a private Ethereum network, it is necessary to configure the genesis block, accordingly. Table 8 includes a description of multiple parameters that define the starting point of the network. Additionally, the genesis block is also configured the consensus algorithm to be used by the network. The algorithm to be used depends on the Ethereum client installed in the nodes. Specifically, this paper employs Geth where the PoW is configured as ethash and PoA as clique. By default, i.e., if the consensus algorithm is not configured in the genesis block, the network uses PoW. In PoW, parameters such as difficulty and nonce are calculated in each block to keep the mining time between 15-20 s. In the case of PoA, the mining time can be configured using the period parameter. In a network with multiple nodes, the connection between nodes is only possible if the nodes hold exactly the same genesis block.

Table 8 Description of genesis block parameters

Block Gas Limit in the genesis block, is used as a starting point for the block size. It determines how many transactions can be included into a block (e.g., each Ethereum transaction was configured with a gas limit of 60 units of gas. If the block gas limit is 100, each block can fit just 1 transaction.). Therefore, the block gas limit configuration plays an important role in the network performance. As blocks are added to the chain, the block gas limit is dynamically adjusted by a factor of \(\frac{1}{1024}\) according to the gas used in the previous block. To fix and keep the block gas limit high, the Ethereum client allows the —targetgaslimit command. By default, the targetgaslimit is 0x47E7C4.

In Ethereum, the communication with the blocks is done via JavaScript Object Notation (JSON) with Remote Procedure Call (RPC), i.e., JSON-RPC. It allows a front-end system to communicate with the Ethereum blocks. While JSON allows to exchange data between a browser and a server, RPC allows to perform requests in a network. Therefore, JSON-RPC defines the data structure, methods, and rules to communicate with the network [6]. It can be used over sockets, hypertext transfer protocol (HTTP), etc.

Smart Contracts

Ethereum enables the deployment of pieces of software, known as smart contracts, without involving a trusted third-party entity [19]. Smart contracts are computer programs composed of dedicated data structures to accommodate the so-called transactions in the distributed network. In addition, they can execute a set of methods to perform smart decisions in a decentralised manner. The contract code on an Ethereum blockchain is in a specific binary form, which is known as Ethereum virtual Machine (EVM) binary code. EVM is a run-time environment to read and execute smart contracts in Ethereum. To run, the EVM is necessary to install an Ethereum client. After deployed in an Ethereum network, a smart contract cannot be deleted or changed. While there are several languages to develop smart contracts, SolidityFootnote 4 is the most popular. Solidity is an object-oriented, high-level language whose syntax is similar to JavaScript. Additionally, it is designed to target the EVM. To compile a smart contract, it is necessary to use a Solidity compiler—solc—which converts Solidity programs into EVM bytecode. Smart contracts have been explored for Blockchain 3.0 approaches such as IoT, finance, supply chain, and e-voting platforms [26]. In this paper, smart contracts are used as data structures to accommodate the transactions to be committed into blocks.

Ethereum Clients

A public Ethereum network is composed of multiple nodes which run a client with an Ethereum implementation. Current implementations in industry and academia typically use Go-ethereum Footnote 5 (Geth) or Parity Footnote 6. Other Ethereum client implementations include Hyperledger Besu Footnote 7, TrinityFootnote 8, and Aleth Footnote 9. This paper uses Geth which is an official Go implementation of the Ethereum protocol. It holds a stable release recommended for production applications and supports both PoW (ethash) and PoA (clique) as consensus algorithms.

Geth Accounts, also called wallets, contain a private and public key pair required to interact with the corresponding Ethereum nodes. These accounts allow the communication with the network and execute Ethereum tasks. In the case of PoA algorithm, the network needs at least two accounts (one per node). In the Geth client, a voting node is called a Sealer or Signer.

Genesis File is used to initialise the network. After the Ethereum accounts have been created, it is necessary to initiate the chain using the genesis file. This file contains the configuration of the first block. The genesis file should be exactly the same in all nodes of the network, otherwise, it will not work. Then, the client is ready to be launched.

Nodes are started using a set of Geth commands, described in Table 9, which determine a node’s role. Then, JSON–RPC interface will be ready to answer requests to the network. The nodes can be miners or regular nodes. While the miners are able to validate blocks, the regular nodes contain just a copy of the entire chain of the blocks. Once started the Ethereum nodes, the last step is to interconnect them to create a peer-to-peer network. There are two ways to configure the interconnection: (1) via inter-process communication (IPC) interface in the Geth client; and (2) via JSON file (static-nodes.json) with the identification of the node.

Table 9 Description of Geth commands to launch a node

Rights and permissions

Reprints and Permissions

About this article

Verify currency and authenticity via CrossMark

Cite this article

Leal, F., Chis, A.E. & González–Vélez, H. Performance Evaluation of Private Ethereum Networks. SN COMPUT. SCI. 1, 285 (2020). https://doi.org/10.1007/s42979-020-00289-7

Download citation

Keywords

  • Blockchain
  • Performance
  • Gas limit
  • Ethereum
  • Private networks
  • Pharmaceutical manufacturing
  • Auditability