[latexpage]

Lately, there has been a lot of talk about permissioned blockchains, in which only certain entities have the authority to validate transactions and generate blocks. The use of these technologies is currently highly required by different companies, since it allows them to store data in a decentralized way and show complete transparency in all their operations. It also allows creating crowdfunding platforms, in which its users can issue shares of certain assets, and benefit by raising funds from small investors from all over the world (for example, crowdfunding platforms of real estate, automobiles, artistic works and others). In the present article, we analyzed the performance of one of the most used implementations, the Clique algorithm for PoA consensus using Geth client for Ethereum.

Problem Description

The analysis is performed on a private blockchain development based on the Ethereum platform, using Go-Ethereum (Geth) client implementation. Geth allows using two different consensus algorithms: Proof of Work (PoW) and Proof Of Authority (PoA). Since most companies need to keep validation authority on data transmitted through the network, the blockchain will use the PoA consensus algorithm. The PoA Geth implementation is called Clique.

Multiple parameters can affect the network performance. The main parameters CoinFabrik has detected are: Sealers Number, Block Time and Gas Limit.

Sealers Number

In PoA network consensus is achieved by a majority agreement among the sealers nodes. A sealer node is a special client which is allowed to include blocks on the blockchain. Sealers are set in a whitelist in the blockchain genesis block. Once the blockchain is running, new sealers could be added by majority voting. To consider a block as valid, it must be validated by at least 51% of sealers. By increasing the number of sealers the network latency could be also increased. This can generate synchronization problems during the generation of blocks. It is necessary to study how the amount of sealers affects the performance of the network.

Block Time

Clique consensus algorithm divides time into epochs. At the beginning of each epoch, a sealer is selected using a Round Robin algorithm as the leader to propose a new block. During the epoch, the leader validates transactions and includes them in the new block, and once the epoch is finished, it broadcasts the block to the other sealers. If the majority of the sealers accepted it, the block can (finally) be considered as valid. In case that the leader delays in submitting the block, some back-up sealers can take its place and propose another block instead. The time between two consecutive blocks is called block time. Despite the fact that in PoA networks theoretical block time is fixed by configuration, it can fluctuates due to synchronization and network delays. That is why it is interesting to measure real block times given other varying blockchain parameters, e.g. number of sealers and Gas Limit (which determines the block size). The block time configuration parameter can be used to set the maximum network throughput, as evaluated in Gas Limit section.

Gas Limit

Ethereum platform prevents transaction spamming and rewards block miners by charging a gas fee on transactions. Each block contains a maximum amount of gas that can be collected from transactions, defining a maximum block size. That gas limit could be set as a configuration parameter. In the long term, the block gas limit approaches a target gas limit set also as a configuration parameter (it can also be changed at runtime if needed). The theoretical maximum transactions per second (TPS) can be calculated using the following equation:

\begin{equation*}
TPS = \frac{Gas_{Limit}}{Tx_{Gas} * Block_{Time}}
\end{equation*}

where GasLimit is the Block gas limit, TxGas is the gas needed to compute the simplest transaction and Block time is the blockchain block time.

Experimental Setup

The experimental setup consists in a set of virtual machines running on a cloud, in servers set all around the world to add latency to the network and test in the worst scenario it could face in future.

CoinFabrik developed a software tool to:

• loop over network configurations, considering different sealers number, block times and gas limit
• set up sealer nodes using a blockchain Client implementation based on Geth version 1.8.18
• run a private blockchain
• run a spammers bot that submits dummy transactions
• measure network statistics as real block time, throughput, block propagation time and others
• shutdown the blockchain, remove files and restart with the following configuration point

The results are useful to characterize the blockchain functionality using different configuration points.

Test Results

The blockchain is tested using combinations of the following configuration points:

• seales number: 5,10,15,20
• block time [sec]: 2,5,20,15,20,30
• gas limit [wei]: 4000000, 8000000, 16000000

Every configuration point is tested keeping the blockchain running for one hour.

Propagation block time is affected mainly by sealers number as well as by block time. Figures 1, 2 and 3 reports propagation block time in different network configurations, measured as the time since the block is proposed by the leader until it reaches all the other sealers.

Propagation Time vs Sealers

Propagation Time vs Sealers

Propagation Time vs Sealers

It can be observed that the propagation time strongly depends on the number of sealers. Higher block times are also related to higher delays. This can be explained considering that higher block times produced higher block sizes in our tests, so propagation of information took more time due to the amount of data transmitted. Gas limit doesn’t affect the propagation time in our tests, since blocks didn’t include a limit in the amount of transactions.

Tables 1 and 2 report measured mean block times and standard deviation respectively, against amount of sealers and theoretical block times in the network configuration, running the blockchain during one hour. Times are reported in milliseconds.

Block times[ms] \ Sealers	5	10	15	20
2000	1999.81	2000.48	2000.01	2004.75
5000	4999.92	5017.92	5013.95	5002.77
10000	10000.04	10000.12	10009.24	10000.16
15000	14999.97	15000.09	15000.06	14999.91
30000	29999.7	30000.5	30000.07	29998.97

Table 1: Mean measured block times against theoretical block time and number of sealers supporting the blockchain.

Block times[ms] \ Sealers	5	10	15	20
2000	63.94	78.72	51.53	122.38
5000	62.74	325	269.78	138.89
1000	69.68	59.94	307.19	54.94
15000	56.44	52.32	63.01	52.33
30000	59.75	64.66	52.32	52.07

Table 2: Standard deviation measured block times against theoretical block time and number of sealers supporting the blockchain.

Propagation delays not only affect real block time but also consensus. When a leader delays in broadcasting its signed block, sealers accept blocks proposed by backup nodes, which are a set of sealers selected in each epoch. So, there are epochs in which the leader proposed blocks are discarded. Figures 4 to 6 reports the amounts of blocks lost in different network configurations, running one hour each one.

Lost Blocks vs Sealers

Lost Blocks vs Sealers

Lost Blocks vs Sealers

The amount of lost blocks strongly depends on block time. There is a big jump measured between 2 seconds block time and 5 seconds block time. The amount of lost blocks per amount of blocks is higher in networks with lower block times. Lost blocks seems to be weakly related to amount of sealers, since at lower amounts of sealers, lost blocks number  increases, but at 20 sealers, the lost blocks number decrease. This behavior remains to us unexplained, and could be tested again in a future research.

Conclusions

Main Results

Blockchain tests allowed us to characterize the blockchain behaviour at different configuration points, considering different amount of sealers, block times and gas limits. Lower block times were found to be strongly related to higher amount of lost blocks per valid blocks, which leads to a bad performance of the blockchain. It would be better if when one of these sealers is selected as a leader, it had higher chances of generating a valid block. For this to take place we recommend not to use lower block times. On the other hand, using 30 seconds block times some delays problems were also reported. Based on these analysis, we propose to use block times between 10 and 15 seconds, to keep a high TPS. Block times between 15 and 20 seconds are also expected to lead to a good performance, but were not tested in this analysis.

Despite the fact that amount of sealers are positive correlated with block propagation times, it was found that it does not degrade the performance of the network in the analyzed configurations. The analysis guarantees the good performance of the network when the blockchain is supported by up to 20 sealers. Analysis with more than 20 nodes were not performed.

Future Steps

The research could be strongly improved considering the following tests:

• Run spammers on the network to submit as much transactions as needed to fulfill the blocks, therefore testing the network at its full capacity.
• Run tests considering more granularity in the configuration points, in particular considering the amount of sealers between 15 and 20, to retest the unexplained lost blocks behavior.
• Run tests considering higher amount of sealers than 20, to test blockchain performance in bigger networks.
• Run tests considering malicious nodes in the network. This will include some Geth client modifications to produce a malicious software.

If you liked this article, you might also like:

• Dogethereum State
• Dogethereum: A Decentralized Blockchain Bridge Between Dogecoin and Ethereum is Born
• An Efficient Algorithm to Exploit Arbitrage Opportunities in Crypto Markets
• What I Have Learned from My Arbitrage Experiences with Cryptoassets.

Disclaimer: CoinFabrik does not provide financial advice. This material has been prepared for educational purposes only, and is not intended to provide, and should not be relied on for, financial advice. Consult your own financial advisors before engaging in any investment.