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.

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

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, Solidity⁴ 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 ⁵ (Geth) or Parity ⁶. Other Ethereum client implementations include Hyperledger Besu ⁷, Trinity⁸, and Aleth ⁹. 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